Уйти в пентест? Стать devops-инженером или системным администратором? 
Только вам решать, куда расти, если вы знаете Linux.

Курс "Основы Linux" обучит вас тонкостям работы с ОС: от работы в командной строке до создания прикладных программ.

⏺ 80% практики
⏺ сопровождение куратора
⏺ финальный проект для портфолио — курс завершает проектная работа
⏺ сертификат или удостоверение о повышении квалификации

Старт: 17 февраля. Оставьте заявку на сайте или напишите нашему менеджеру @Codeby_Academy

Присоединяйтесь и узнайте все о Linux и смежном ПО: от основ командной строки до развертывания Kubernetes! 

Не новая, но полезная статья для тех, кто все еще прибивает гвоздями.

Используем APT Pinning для закрепления пакетов в Debian и Ubuntu

Достаточно часто при работе с Linux-системами возникает потребность в установке пакетов в версии отлично от той, что находится в репозиториях.

Чаще всего для этих целей используется ручная установка нужной версии пакета с последующей заморозкой (при необходимости) или сборка пакета из исходников.

В тоже время в основанных на Debian дистрибутивах существует штатная система закрепления пакетов APT Pinning, использование которой более предпочтительно, тем более что работать с ней совсем несложно.

https://interface31.ru/tech_it/2016/03/ispolzuem-apt-pinning-dlya-zakrepleniya-paketov-v-debian-ubuntu.html

​​Слишком много изменений…

Новый год – новые изменения, но иногда их бывает слишком много. Так и в этом году. Многочисленные изменения законодательства затронули практически всех и заставили обновлять все что нужно и не нужно.

Возьмем для примера торговую фирму, так как тут данная проблема встает в полный рост. Нужно обновить… Ох, много чего обновить нужно… И когда это все?

Чтобы не быть голословными, скажем, что обновить обычно нужно: платформу 1С:Предприятие, прикладное решение 1С:Предприятие, драйвера торгового оборудования, прошивки торгового оборудования.

Если у вас сеть, то эти обновления еще надо разогнать по сети. В общем – дел хватает. И все это, как обычно, надо было еще позавчера.

И самой большой ошибкой будет долго готовиться и разом обновиться. Сразу по всем направлениям. При этом вы можете сколько угодно гонять изменения в тестовом контуре, но после их раскатки в продакшен неизбежно начнут вылазить проблемы.

А дальше начинается паника, точнее ПАНИКА, потому что все недовольны, все жалуются и абсолютно непонятно куда бежать и за что хвататься.

В общем, даже если вы героически победите все эти проблемы, то никакой благодарности не заслужите, потому что все будут уверенны, что это IT уронил прод всеми этими обновлениями.

И как быть? Просто. Слона нужно есть по частям, равно как и внедрять изменения. Да, это будет не так быстро, не так эффективно, но более-менее мягко и безболезненно для продакшена, ну точно уже без авралов и панических настроений.

Что бывает, когда мы накатываем сразу несколько изменений и получаем после этого проблемы? А бывает то, что мы не знаем, какое именно изменение эти проблемы вызвало и вынуждены отрабатывать массу вариантов. А предприятие все это время работает через пень-колоду.

Кто будет крайним? А тот, кто это все затеял и затеял именно в такой форме.

Поэтому никогда не надо так делать. Разбивайте внесение изменений на этапы. Сегодня изменили то, завтра получили обратную связь, убедились, что все работает как надо. Тогда после завтра можно обновить что-то еще. И снова все проверить.

Это не исключает проблем, но в случае их возникновения вы уже точно будете знать, с чем они связаны и куда смотреть, кому писать.

Ну и не забывайте про моратории. Перед теми же выходными. И вопрос тут даже не в том, что отдохнуть хотите вы. Отдохнуть хотят все и есть очень большой риск, что все проблемы пятницы сотрудники просто заметут под ковер и выкатят вам утром понедельника. Которое окажется очень недобрым.

Поэтому реальный план – это работаем с понедельника по четверг с обязательным тестированием в реальной эксплуатации каждого этапа изменений. И только после получения положительных отзывов от эксплуатантов переходим к следующему этапу.

Но сроки, скажет иной читатель. Как быть, если требуют. А просто, достаточно документировать все обращения и формализировать этапы тестирования. Т.е. если вы сегодня выкатили изменений, то по окончании рабочего дня эксплуатанты должны подтвердить наличие или отсутствие проблем.

К нему прилагаем список выявленных проблем и решений. После чего становится видно, что вы не баклуши били, а весьма напряженно работали в тесной смычке с теми, кто систему эксплуатирует.

Ну это давно известно, чем больше бумаг, тем чище пятая точка. Поэтому не забывайте об этой стороне вопроса, которая иногда может оказаться важнее технической. Просто потому, что эти ваши технические тонкости никому кроме вас не понятны, а язык бюрократии понятен всем управленцам и руководителям.

Владелец ИТ-аутстаффинговой компании дал комментарий о массовом сокращении IT-специалистов в 2025 году

Продолжение здесь 

Реклама. Белякова Е.О. ИНН 621508152445.

​​Никогда такого не было и вот опять… Вторая серия

Началось у нас третьего дня восстание машин, точнее кассовых аппаратов АТОЛ. Внезапно с торговых точек стали поступать сообщения:

❗️Произошла ошибка проверки средствами ККТ по причине: Настройки адреса сервера не заданы.

Как это не заданы? Заходим в настройки ККТ… И действительно, настроек серверов нет. Пусто, как после техобнуления. Удивляемся, вроде бы при прошивке выгружали и загружали настройки.

Ну ладно, записываем заново и вроде бы все снова начинает работать. До следующего дня. Дальше – интереснее. Если несколько касс снова слетели только один раз с утра, то одна из них теряла настройки несколько раз в течении рабочего дня, что навело на самые нехорошие предположения.

Тем более, что эта касса была из другой партии и прошивалась другой цепочкой прошивок. В общем собрали всю информацию и обратились в поддержку.

Ответ пришел самый неожиданный – заполните параметры серверов со стороны 1С, на одной из закладок драйвера.

Закладка эта там довольно давно и, если верить документации, предназначена для оперативного изменения этих самых адресов серверов, не обращаясь к кассе. Если же там никто ничего не менял, то никаких изменений в настройки ККТ не вносилось.

Но так было до релиза Розницы 2.3.21, которая начала заливать в настройки касс пустые параметры с этой закладки, причем выборочно, не во все и со странной периодичностью.

Поддержка АТОЛ про такое поведение знает и кивает в сторону 1С, осталось теперь проверить – знает ли 1С и в какую сторону кивать будет уже она.

И естественно никто нигде ничего про это не написал. Патчей, исправляющих такое поведение тоже нет.

Показывали сегодня коллегам статью про ПУСК и сам этот ПУСК вживую и сразу спросили, а где-то у вас была такая же, но про PgAdmin.

Была и даже есть:

🔹 Установка и настройка pgAdmin 4 в режиме сервера

pgAdmin -- это приложение с открытым исходным кодом для администрирования и разработки баз данных PostgreSQL которое позволяет выполнять множество задач, начиная от мониторинга и обслуживания и заканчивая выполнением SQL-запросов.

pgAdmin 4 можно установить на локальный компьютер, но в наше время, когда доступ может потребоваться в любое время и из любого места, это не очень удобно.

Гораздо удобнее установить pgAdmin 4 в режиме сервера и иметь доступ к нему через браузер из любой точки мира. О том как это сделать мы расскажем в данной статье.

Если в этом году вы решили развиваться, осваивать новые навыки и становиться круче в профессии, мы готовы помочь вам начать уже сейчас!

👉 Забирайте промокод:

potok5

который даёт скидку 5000₽ при оформлении любого из 6 курсов Слёрма.

☑️ Курсы, на которые можно применить скидку — ЗДЕСЬ

Акция проводится до 20 февраля.

#реклама
О рекламодателе
erid: 2W5zFHoNBLc

​​Дружба дружбой, а табачок врозь

Как вы представляете себе типичный опенсорс образца третьего десятилетия 21 века? Как тысячу внимательных глаз и рук, работающих над кодом в свободное время? Или как коммерческие разборки бывших партнеров?

В этой новости прекрасно все:

Компания Automattic, курирующая открытую платформу WordPress и официальный каталог плагинов WordPress.org, приняла решение снизить своё участие в разработке WordPress до примерно 45 часов в неделю, что уравняет её вклад в разработку с компанией WP Engine и другими сторонними участниками. Отмечается, что предоставленных ресурсов скорее всего хватит только на подготовку корректирующих обновлений с устранением проблем с безопасностью и критических ошибок.

Ранее компания Automattic оценивала свой вклад в разработку WordPress в 3915 часов в неделю и высказывала недовольство, что ей в одиночку приходится тянуть весь проект, в то время как компания WP Engine паразитирует на WordPress, вкладывая в разработку примерно 40 часов в неделю при выручке от использования платформы в 500 миллионов долларов.

Действия Automattic объясняются желанием добиться справедливости и устранить дисбаланс вклада участников экосистемы. Снижение участия в разработке также связано с перераспределением ресурсов в связи с судебными исками от компании WP Engine, отражение которых отнимает много времени, денег и энергии.

Отмечается, что, если WP Engine прекратит свои юридические атаки, компания Automattic готова вернуться к активному участию в развитии проектов WordPress, Gutenberg, Playground, Openverse и WordPress.org. До этого Automattic сосредоточится на своих коммерческих продуктах, таких как WordPress.com, Pressable, WPVIP, Jetpack и WooCommerce.

Действия Automattic являются продолжением конфликта между Мэттом Мулленвегом, основателем WordPress и владельцем компании Automattic, и компанией WP Engine, поддерживающей альтернативный каталог WP Engine и предоставляющей хостинг на базе WordPress.

В октябре компания WP Engine подала судебный иск против Automattic, в ответ на появление в интерфейсе администратора WordPress ссылки на статью, порочащую репутацию WP Engine, поступления требования покупки лицензии на товарный знак WordPress, блокировки доступа к ресурсам WordPress.org и замены в каталоге WordPress.org плагина ACF, имеющего 2 млн установок, на форк, поддерживаемый компанией Automattic.

10 декабря суд наложил предварительный запрет на действия, наносящие вред бизнесу WP Engine. Компании Automattic было предписано разблокировать учётные записи сотрудников WP Engine на сайте WordPress.org и вернуть контроль над дополнением ACF. Судебное разбирательство ещё не завершено и предварительный запрет является обеспечительной мерой для прекращения нанесения ущерба бизнесу WP Engine до вынесения окончательного решения.

Позиция Automattic сводится к тому, что компания WP Engine сама нанесла себе ущерб, построив бизнес вокруг сайта WordPress.org. Между WP Engine и Automattic не было договорных отношений, гарантирующих доступ к WordPress.org и возможность загрузки обновлений с этого сайта. Суд счёл подобный довод неубедительным, так как доступ был ограничен только для WP Engine, а действия Automattic восприняты как недобросовестная конкуренция через выборочный запрет конкуренту доступа к общедоступным данным.

Дополнение: Мэтт Мулленвег заблокировал в каталоге WordPress.org учётные записи пятерых участников, продвигавших идеи создания форка WordPress и смены модели управления в сообществе.

❓ А причем тут опенсорс, спросит иной читатель? А при том, что в сообществе реально есть разработчики, верящие в теорию всеобщего равенства и братства, но плоды их усилий используют совсем другие личности и совсем в иных целях.

👉 Так что работать бесплатно может быть и интересно, но только вот чей это будет интерес?

​​Почта и базовые DNS-записи

Как показывает практика многие коллеги откровенно плавают в вопросе правильного назначения DNS-записей для систем электронной почты. Причем с самых-самых базовых, поэтому сегодня мы решили разобрать этот вопрос подробнее.

Жил да был у нас некий сервер с серьезным и многозначительным именем srv283.myorg.example, если его администратора разбудить среди ночи он мог взахлеб рассказывать про все его особенности и чем он отличается от srv282 и почему немного похож на srv189, но все-таки ближе к srv284.

В один прекрасный момент руководство ставит перед админом задачу. Мол чего это у нас этот сервер просто так небо коптит, давай организуем на нем что-нибудь полезное, например, почту.

Да не только для нашей организации, которая имеет домен myorg.example, но и для нашей розничной сети с доменом magazin.example и производства с доменом zavod.example.

Не проблема – ответит админ и пойдет настраивать нужные службы, а заодно рисовать нужные DNS-записи в собственных и контролируемых им DNS зонах.

Прежде всего нужно связать имя сервера с выданным провайдером IP-адресом, и он делает A-запись для узла srv283.myorg.example с адресом 203.0.113.25.

Ну так как тут будет почта, то вместо многозначительного имени srv283 надо что-то попроще и он создает еще одну запись CNAME с именем mail, которая будет указывать на srv283, а потом добавляет MX запись, которая говорит, что почту следует направлять по адресу mail.myorg.example.

Теперь розничный отдел, им все равно и поэтому мы просто добавляем им MX запись со все тем же значением mail.myorg.example. А что, так можно? Конечно можно, никто не мешает серверу в одном домене обслуживать почту для других.

А вот заводу это не понравилось, хотим, говорят, «свой» сервер. Ну да не проблема, делаем еще один CNAME и прописываем MX уже на это CNAME, т.е. mail.zavod.example. Все довольны, а некоторые вообще счастливы.

И вот довольный клиент хочет прислать нам благодарность, он набирает письмо в почтовом клиенте и нажимает кнопку отправить.
Почтовый сервер смотрит кому предназначено письмо? Так, myorg.example, а давайте спросим кто у них принимает почту и запрашивает MX -запись. В ответ получает, что mail.myorg.example.

Хорошо, а давайте узнаем адрес mail.myorg.example, а тут DNS и говорит, мол это не настоящее имя, это псевдоним, на самом деле его зовут srv283.myorg.example.

Не вопрос, какой адрес у srv283.myorg.example? Записываю - 203.0.113.25, все, ждите отправление.

Как видим, в этом процессе отработали все доменные записи нашей инфраструктуры. Тоже самое будет и при обращении на домены магазина и завода.

А вот теперь что будет, если почту решим отправить мы. Скажем мы так прониклись благодарностью клиента, что решили отправить ему подарочный сертификат.

Но наше письмо не дойдет и просто в пути пропадет. А почему? А потому что есть у систем электронной почты такая беда как спам.

Бороться с ним можно по-разному, но еще очень давно решили, что добросовестный отправитель почты должен иметь PTR-запись, указывающую на узел отправителя.

Почем это эффективно и используется до сих пор? Потому что PTR-запись прописывает не отправитель, а провайдер выдавший IP-адрес в своей зоне.

И даже если сервер отправителя взломали, то быстро прописать PTR не получится. Нет, попробовать можно, но большинство получателей сразу будут такие письма помечать как спам.

А чтобы прописать такую запись отправитель должен обратиться с заявкой к провайдеру, соблюдая весь установленный регламент, что дело не быстрое и не поддается автоматизации.

Последний вопрос – а что туда прописывать? Только собственное имя сервера, т.е. srv283.myorg.example и не важно какие он домены обслуживает и какие там красивые псевдонимы прикручены.

Почему, да потому что при установлении сессии ваш сервер сразу, как требуют правила приличия, представится – я srv283.myorg.example.

Получатель глянет, ага - 203.0.113.25, а что нам скажет PTR? Так - srv283.myorg.example, все в порядке, коллега, готов принять от вас отправление.

MongoDB Compass

Недавно в комментариях к материалу о pgAdmin спрашивали что-то такое для MongoDB. Многие тогда посоветовали DBeaver, но «бобер» в свой бесплатной версии не поддерживает MongoDB (тут напрашивается известное польское ругательство). 🦫

В тоже время есть полнофункциональный родной инструмент MongoDB Compass, лицензию которого открыли еще в 2020 году.

Инструмент кроссплатформенный, поддерживает Windows, macOS и Linux. Единственный момент – на территории РФ для его получения вам придется воспользоваться известным сервисом из трех букв по причине территориальной блокировки с той стороны.

Ссылки на скачивание и все необходимые инструкции здесь:

✅ What is MongoDB Compass? - MongoDB Compass

👆 И небольшая мораль всей этой истории: прежде чем искать что-то на стороне посмотрите родные инструменты.

Как видим, почтовая тема остается актуальной, поэтому снова подборка, на этот раз упор на настройку DNS.

🔹 Настраиваем свой почтовый сервер. Что нужно знать. Ликбез

🔹 Почтовый сервер для начинающих. PTR и SPF записи как средство борьбы со спамом

🔹 Как правильно настроить DNS-записи для мультидоменного почтового сервера

​​Обязательное подписывание SMB-пакетов в Windows 11

С выходом Windows 11 24H2 многие пользователи столкнулись с проблемами доступа к сетевым ресурсам при помощи SMB. Виной тому изменение политики подписывания SMB-пакетов, которая по умолчанию стала обязательной.

SMB Signing - это одно из средств безопасности средств протокола общего доступа к файлам SMB/CIFS. Когда оно включено, каждое SMB сообщение подписывается в заголовке цифровой подписью.

Такая подпись позволяет гарантировать, что содержимое сообщение не было изменено и проверить подлинность отправителя. Это позволяет предотвратить реализацию SMB атак типа man-in-the-middle и NTLM relay.

Ранее SMB подписывание требовалось только при доступе к сетевым папкам SYSVOL и NETLOGON на контроллерах домена AD.

В дальнейшем данную политику обещают распространить и на другие версии Windows.

При обращении такого клиента к серверу не использующему подписывание пакетов будет появляться ошибка:

0xc000a000  The cryptographic signature is invalid

Поэтому самое время разобраться с действующими в системе политиками, для этого выполним в консоли PowerShell две команды, которые покажут настройки клиента и сервера SMB:

Get-SmbClientconfiguration | fl *sign*
Get-SmbServerconfiguration | fl *sign*

Например, в версии Windows 11 23H2 для клиента установлены следующие политики:

EnableSecuritySignature  : True
RequireSecuritySignature : False

Политика EnableSecuritySignature для клиента и сервера SMB2+ игнорируется, а так как SMB1 везде по умолчанию отключен, то можем не обращать на нее внимание.

В современных системах для подписывания используется политика RequireSecuritySignature, которая определяет необходимость подписи по принципу логического ИЛИ. Т.е. если хоть одна сторона будет требовать подписывания (клиент или сервер) – пакет будет подписан.

Таким образом, чтобы отключит подписывание, мы должны отключить его и на клиенте, и на сервере.

Для этого можно использовать команды:

Set-SmbClientConfiguration -RequireSecuritySignature $false
Set-SmbServerConfiguration -RequireSecuritySignature $false

Если политику нужно включить, то замените $false на $true.

При этом не следует бежать и отключать требование подписи везде где только можно, потому что это довольно важное средство обеспечения безопасности, а только там, где использование подписи невозможно по техническим причинам.

Так если весь парк ПК состоит из современных систем, то имеет смысл отключать требование подписи только на клиенте, чтобы они могли работать с не умеющими подписывать пакеты серверами и оставлять ее включенной для серверов, что обеспечит использование подписи при наличии такой возможности.

​​Сказка о потерянном времени

В очередной раз помогали коллегам заказчика делать инвентаризацию. И в очередной раз нашли много неиспользуемого, включая то, про что давно забыли и были приятно удивлены количеством освободившихся ресурсов.

А пока мы решили составить свой рейтинг ненужности, возможно у вас он будет другой, ждем ваших комментариев.

1️⃣ На первом месте с огромным отрывом стоят локальные базы знаний, чаще всего выполненные на Wiki-движках, но абсолютно необязательно.

Причина проста – такой базой знаний должен кто-то заниматься, причем заниматься постоянно. Если этого нет, то база утрачивает актуальность и ей просто перестают пользоваться, а если перестают пользоваться, то какой смысл ее пополнять.

Сейчас, на просьбы заказчика сделать им такой сервис мы сразу отвечаем, что сделать его – это только 1% от все работы. Остальное – это наполнение и тут им придется уже как-то самим. Обычно, когда дело доходит до конкретной реализации и назначения ответственных энтузиазм как-то сам утихает.

2️⃣ Второе место – это всякие внутренние порталы. В теории это видится некой точкой консолидации, в которой размещают новости, объявления, внутренние документы, инструкции и т.д. и т.п.

Но, на практике, всем этим снова нужно кому-то заниматься. И если нет специально назначенного за этим человека, то такой портал становится нафиг никому не нужным.

Еще меньше он нужен сотрудникам, что надо – доведет руководство. Да и все остальное легче передать через систему совместной работы, тот же Битрикс 24 или аналоги, им хотя бы ежедневно пользуются.

3️⃣ Третье место по ненужности занимает, как это не странно, мониторинг. Но здесь тоже все достаточно прозаично. Ожидания не совпадают с реальностью. Многие представляют мониторинг как красивые графики и диаграммы, которые можно вывести на отдельный монитор и с гордостью показывать начальству.

А по факту получаем кучу метрик, не меньше алертов, которые приходят по делу и без дела и необходимость серьезно вникать и настраивать продукт. После чего тот же условный Zabbix задвигается на самый дальний сервер и благополучно забывается.

4️⃣ Четвертое место, хотя можно и поменять местами с мониторингом, это системы учета заявок и инцидентов, тот же GLPI. Но мы все-таки вынесли его на четвертое, потому что внедряют его уже более-менее осознанно и данные системы менее популярны у начинающих, нежели мониторинги.

Но чтобы у вас работала система учета заявок, у вас уже должна быть работа с заявками или осознанная необходимость и политическая воля в ее создании и внедрении. Потому как инструмент выбирается для решения задачи, а не наоборот.

Вы же не покупаете отбойный молоток просто так и только потом начинаете искать куда бы его применить.

Если нет системы работы с заявками, равно как и самой культуры такой работы, то данный сервис окажется бесполезен и поигравшись месяц другой о нем все забудут.

5️⃣ На следующее место мы бы поставили различные средства наблюдения и управления инфраструктурой, раздел это довольно обширный и отнести к нему можно много чего, скажем тот же IPAM или Ansible.

Пятое место здесь потому, что внедряются такие вещи хотя бы уже с базовым пониманием что и как, но очень часто их внедрение обусловлено не необходимостью, а желанием админа поиграться с новой «крутой» технологией. Но со временем играться надоедает и все это переходит в разряд ненужного.

Еще один вариант, это когда инструменты явно перерастают потребности и квалификацию персонала. Понятно, что это круто, но нафиг никому не нужно. Чаще всего такие проекты тихо саботируются и тут же сворачиваются после ухода инициатора или потери его интереса к проекту.

👆 А по факту все это – потерянное время и ресурсы. И каждый раз, когда возникнет желание внедрить что-нибудь такое следует спросить себя - а оно мне точно нужно? А зачем? А нужно ли оно еще кому-нибудь кроме меня?

И если вы затрудняетесь дать твердые и аргументированные ответы – оно вам не нужно.

Каждый месяц мы любим читать и анализировать статистику, как канала, так и сайта. И иногда находим там совершенно изумительные вещи.

Так и в этот раз в списке ссылающихся нашли канал нашего коллеги - сисадмина, но пишет он не о работе, а о жизни, а по работе посылает или к нам, или к Владимиру https://yangx.top/srv_admin (вот так вот, на старости лет стал тем, к кому посылают).

Перешел, почитал канал и меня зацепило. Особенно последний пост про авралы и водку. Было что-то такое, расскажу как-нибудь.

👉 https://yangx.top/winvan_true_original/172

Только вот у него всего 42 подписчика. Может мы хотя бы 420 сделаем? Какой моральный заряд будет автору? Сделаем же?

Данная заметка написана нами в поддержку начинающих авторов, почему это важно – можно прочитать здесь: https://yangx.top/interface31/3702

​​Как я внедрял систему учета обращений на бумажном носителе

Я уже рассказывал на данном канале истории из далекой молодости, когда я сразу после окончания высшего учебного заведения попал на работу в сельскохозяйственный НИИ на должность инженера.

Первоначально там предполагались задачи администратора, но постепенно на меня скинули все обязанности типового инженера данной конторы вплоть до газовых баллонов, пневматики и всего такого разного.

Сия организация была бюджетной и руководил ей бывший партийный начальник областного уровня, славный в свое время «подвигами», о которых из уст в уста передавались «легенды».

Контингент той конторы был преимущественно предпенсионного возраста, а «молодежь» были те, кому за тридцать. Ну и я со своими 20 с небольшим числился там за «юношу».

Очень скоро я познал… нет, не дзен, а суровую реальность бюджетной конторы – если можно не работать, то работать не нужно, а ответственность всегда можно спихнуть на кого-то другого.

В результате на собраниях по утрам меня часто вызывали на ковер к директору, потому что какой-то отдел чего-то там вовремя не сделал, а причиной назвал неисправность оборудования.

А дальше был примерно следующий диалог:

- Товарищ инженер, ну что это за дела?
- Товарищ директор, первый раз сейчас слышу.
- А мы тебе говорили!!!
- Когда?
- Когда ты баллон менял в понедельник!!!
- Не было такого!
- Было!!!
- Не было!
- Ты гляди, он еще и огрызается! Я тут 100500 лет работаю, а он без году неделя!!!

В результате подобные совещания заканчивались далеко не в мою пользу и получалось что инженер нефига не делает и вообще крайний.

Понятно, что такое положение дел мне не нравилось. Поэтому я взял толстую тетрадку, разлинеил ее и каждое утро, через полчаса после начала рабочего дня начал делать обход.

Я с этой тетрадкой заходил в каждый кабинет и спрашивал – есть ли вопросы по технике или нарекания. Нет? Отмечал в тетрадке: кабинет – прибор – наличие или отсутствие вопросов, дату и время.

Все обращения записывал туда-же. Дату и время обращения, его суть, коротко причину и принятые меры и время завершения. Или объективную невозможность завершить работы, например, нужно купить запасные части.

Со временем одна тетрадка превратилась во две. Одну я назвал «Журнал учета состояния техники», вторую «Журнал учета обращений». С одной делал обход, в другой фиксировал все заявки.

И потом на подобных совещаниях я просто приходил с тетрадками, открывал их и говорил, что обращений не получал, а если получал, то исправил тогда-то и тогда-то, либо не исправил по объективным причинам, так как…

Вся эта система была выстроена мною где-то за полгода, ну да когда получаешь отнюдь не пряники на каждом совещании – думать и шевелиться начнешь.

А потом она прижилась и тихо стала официальной, теперь уже не только я вел эту тетрадку, но и каждый отдел и расписывались в ней обе стороны.

Я проработал в этом НИИ ровно два года, но эта система осталась там надолго и уже лет через 10-15 при общении с бывшими коллегами я узнавал, что система обходов и журналов там до сих про живее всех живых.

​​Про нетехнические особенности работы в бюджетной сфере

В обсуждениях вчера снова возник интересный вопрос, который очень характерен для бюджетной сферы и нынешних госов. Но также может касаться и крупного бизнеса, который действует по аналогичной схеме.

А называется это освоением бюджетов. Общий смысл такой, что на год, полгода, квартал или месяц формируются бюджеты и выделяется целевое финансирование. Если ты его запросил – то должен потратить. Иначе ты работаешь неэффективно и в следующий раз тебе столько не дадут.

При этом финансирование целевое и ты не можешь статью на сайт потратить на картриджи, а деньги на картриджи для покупки сгоревшего коммутатора.

В целом такая система достаточно грамотная и позволяет эффективно планировать ресурсы предприятия, когда отделы заранее подают заявки на финансирование, но в бюджетке все, как всегда. А как известно, даже самую здравую идею всегда можно довести до абсурда.

Степень абсурда разнится от конторы к конторе, но общий смысл действующего подхода такой: если вы не освоили бюджет, то больше вам столько денег не дадут. И там хоть трава не расти.

А как планировать? Хорошо если можно расписать помесячно и запросить в какой-то месяц побольше, в какой-то поменьше и перераспределить общий бюджет между статьями. А когда нет?

Ну и случиться на протяжении бюджетного периода может всякое, на это тоже надо заложиться. В общем принцип там следующий – проси больше, получишь сколько надо.

А потом получается, что деньги к концу бюджетного периода остались и их срочно надо куда-то потратить. А куда? Ну давайте купим что-нибудь нужное, или не совсем нужное, или совсем ненужное.

Хорошо если это железо, можно закупиться впрок и даже можно у поставщика его забрать только через полгода, после неоднократных напоминаний.

Это приводит к тому, что в отдельных конторах могут накапливаться штабеля нового железа, в заводской упаковке, которое никому не нужно. Почему не нужно? Да потому что под новые проекты берутся новые железки, потому что там тоже бюджет и его тоже надо осваивать.

При этом подобные вещи могут самым чудесным образом сосуществовать с полными дровами у пользователей, которые продолжают работать на древних тормозных ПК, просто потому что на его обновление не выделен бюджет. А зачем, работает ведь.

Но… Но там совсем другое дело, там же цифровизация, импортозамещение и всякие разные программы, начиная от федеральных и за них надо отчитывается, поэтому туда бюджеты находятся.

А если ты скажешь, что есть у нас на складе и сервера и все и остальное, давайте на эти деньги обновим ПК сотрудникам, то тебе быстро и доходчиво объяснят – что это нецелевое расходование бюджетных средств и за это может даже быть «садись кибитка – тюрьма поехали».

Но это еще половина беды, практически везде к этой крайне неэффективной практике добавляется личный фактор, который сводится к такому широко известному в узких кругах слову как откат.

Случайных людей в поставщиках или подрядчиках у бюджетки нет, там все свои. То, что можно протащить без торгов – протаскивается так. Что нельзя – конкурсное задание составляется так, чтобы выиграть его гарантированно мог только один, свой, поставщик.

А дальше представители поставщика и заказчика садятся вместе в тихом укромном месте и решают, как и на что они будут пилить бюджет и сколько из бюджетных денег… ну в общем вы поняли. Зарплаты в бюджетке невысокие, а жене надо новую шубу, себе новый авто, летом на юга и т.д. и т.п.

А дальше все зависит от наглости и ловкости, причем эта схема в бюджете поголовно. Да, кого-то ловят и иногда сажают, но в большинстве товарищи годами сидят на теплых местах и осваивают бюджеты.

Отсюда и возникают такие задачи: а давайте… давайте… давайте… внедрим что-нибудь такое, где и железа купить можно и услуг написать побольше…

Внедрили, освоили, разделили. А что нам теперь с этим делать? Да ничего, задвиньте на дальнюю стойку, пусть стоит, небо коптит. Деньги освоили, наверх красиво отчитались. Надо думать как дальше бюджет осваивать, а не эти ваши Заббиксы и Вики.

Универсальные инструменты 1С для управляемых форм

Несколько дней назад обнаружили интересный и полезный проект для всех, кто связан с 1С. Данный инструмент содержит самые необходимые обработки для разработчика, администратора или опытного пользователя 1С. Причем большинство обработок в наборе предназначены именно последним.

Инструменты распространяются в виде файла конфигурации, расширения или в портативном варианте в виде внешней обработки.

В целом ничего сверхъестественного там нет, многие из включенных в комплект обработок можно найти на Инфостарте, но здесь все это собрано в одном месте, проверено и доработано.

Что важно, все инструменты работают как под Windows, так и под Linux, а это важно, например, популярная стандартная обработка Выгрузка загрука XML без доработки с Linux серверами не работает. И таких моментов много. А так как основной парк серверов 1С у нас на Linux, то мы по достоинству оценили этот момент.

✅ https://github.com/cpr1c/tools_ui_1c

​​Как поставить в отраслевую конфигурацию 1С:Предприятие патчи от родительской конфигурации.

Отраслевые конфигурации 1С рассказ отдельный и бесконечно грустный. Многие из тех, кто столкнулись с этим разделом «творчества» предпочтут во множестве ситуаций дорабатывать и сопровождать типовые самостоятельно, нежели еще раз связываться с отраслевыми.

При том что отраслевые сильно дороже, как по стоимости прикладного решения, так и по сопровождению, где-то так раза в два. Казалось бы, вместе с готовыми доработками для отрасли логично получать и своевременную поддержку, хотя бы в виде своевременного исправления ошибок и выпуска исправлений.

На деле же пользователь отраслевой часто получает кучу проблем на ровном месте и полное безразличие со стороны вендора, включая никакую поддержку. Да и сам состав решений очень часто вызывает недоумение, создавая впечатление что разработчики знакомились с отраслью по книжкам для профориентации младших начальных классов.

Чтобы не быть голословными перейдем к 1С:Розница 8. Салон оптики. Это конфигурация на базе типовой 1С:Розница 8 от компании Рарус, у нее там целая линейка подобного творчества на все случаи жизни.

А теперь сравним:

🔹 1С:Розница 8 ПРОФ. Электронная поставка – 17 600 руб.

🔹1С:Розница 8. Салон оптики. Электронная поставка – 31 100 руб.

Для поддержки вам потребуется не только ИТС, но еще и КП отраслевой 2 категории (тарифы на 12 месяцев):

🔹 1С:ИТС Техно – 21 204 руб.

🔹 1С:КП Отраслевой Базовый 2-я Категория – 27 800 руб.

Логично предположить, что за эти деньги покупатель должен получить некоторую дополнительную ценность. Но увы. Мы не будем разбирать состав конкретных отраслевых, а сосредоточимся на поддержке, которая идет отдельной строкой и стоит дороже подписки ИТС.

Итак, на руках у нас имеется обновление 1С:Розница 8. Салон оптики 2.3.21.29 от 25.12.24 (типовая с таким же номером выпущена 12.12.24), т.е. временной лаг между ними где-то две недели.

Данный релиз еще на уровне типовой имеет ряд ошибок, некоторые из них достаточно критичные, например, EF_00_00691163 (патч выпущен 25.12.2024):

▫️ В организации с применением УНС 5%(7%) товары с установленной ставкой: без НДС и НДС0% пробиваются в чек со ставкой 5%(7%).

Ошибка для большинства клиник критичная, так как медицинские услуги оказываемые в рамках медицинской лицензии НДС не облагаются, даже если компания применяет ставки 5/7 % НДС.

И что вы думаете в отраслевой? За которую заказчик отдельно платит вдвое более дорогую поддержку?

А ничего 🍌🍌🍌, фирма Рарус считает, что исправления ошибок для релиза 2.3.21.29 не требуются, в то время как фирма 1С выпустила для типовой 1С:Розница указанного релиза 51 патч.

Можно, конечно, подождать следующего релиза, в котором эти ошибки (возможно) исправят, а новых, неизбежно добавят. Но это не дело, по факту мы получаем сырой и недоработанный продукт и находимся в заведомо более худшей ситуации, чем пользователи типовой.

Как быть? Известно, что спасение утопающих – дело рук самих утопающих, поэтому было принято решение попробовать использовать официальные патчи от типовой конфигурации.

Но если попробовать их загрузить в лоб, в виде архива, то программа откажется их принимать, потому что патчи «не той системы». Поэтому распакуем архив, в котором будет файл расширения и манифест.

Манифест выбрасываем, а расширение устанавливаем стандартным способом через форму работы с расширениями, при этом конфигурация распознает в расширении патч и устанавливает его именно как патч. И в последствии вы будете видеть его в списке исправлений, а не расширений.

Насколько это легально? Скажем честно – не особо, если вы не имеете правомерного доступа к типовой Рознице (т.е. нет купленной конфигурации). Но, с другой стороны, вы платите за поддержку и поддержки не получаете. Поэтому определенное моральное право так поступать имеете. А дальше каждый решает сам.

Если доступ к патчам является критичным, то приобрести лицензию на 1С:Розница 8 ПРОФ будет меньшим из зол, все остальные нужные подписки у вас уже есть.

​​Подписывание SMB-пакетов в Samba

В нашей предыдущей заметке мы говорили о подписывании SMB пакетов в Windows.

SMB Signing это одно из средств безопасности средств протокола общего доступа к файлам SMB/CIFS. Когда оно включено, каждое SMB сообщение подписывается в заголовке цифровой подписью. Это позволяет предотвратить реализацию SMB атак типа MitM и NTLM relay.

Начиная с Windows 11 24H2 клиент будет требовать обязательного подписывания пакетов, в дальнейшем эту политику обещают распространить на все поддерживаемые ОС.

В Linux также не трудно настроить подписывание пакетов, для этого в секции [global] файла smb.conf потребуется указать две опции.

Для сервера это server signing, которая может принимать следующие значения:

▫️ auto - подписывание SMB предлагается
▫️ mandatory - подписывание SMB обязательно
▫️ disabled - подписывание SMB отключено

По умолчанию применяется значение disabled.

Для клиента используется опция client signing с доступными значениями:

▫️ auto - подписывание SMB предлагается
▫️ mandatory - подписывание SMB обязательно
▫️ disabled - подписывание SMB отключено

Значение по умолчанию: auto.

В современных условиях оптимальными настройками будет изменение режима сервера также на auto:

[global]
 server signing = auto

Это позволит работать с современными клиентами, не снижая уровня защиты, но при этом сохраняя совместимость с клиентами не поддерживающими подписывание.

В этом плане Samba позволяет более гибко управлять настройками чем SMB в Windows, там сторона может либо требовать подписывание для всех, либо нет, режим согласования отсутствует.