А можно мы сами?

- А у нас тут 1С не запускается, пишет недостаточно места…

- Значит недостаточно места, надо почистить.

- А если вы подключитесь, то возьмете как за час работы?

- Да, это минимальная такса.

- Но там же просто место почистить.

- Да какая разница, мы тратим свое время. Время – деньги.

- А можно мы сами почистим?

- Можно.

На следующий день сообщают, что они почистили, место есть, но теперь 1С вообще не запускается. 😫

Наверное, вы уже догадались, они удалили самую большую папку в корне диска, с простым и понятным названием «СТ», в которой была база 1С. 🤦‍♀️

Сэкономили денег, однако.

Последний бекап от марта месяца. Но документов немного, дня за два-три в пару рук внесут все обратно.

Морали не будет. Каждый сам определяет, что дорого, а что нет. И несет последствия своего выбора.

Не спеши, а то успеешь

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

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

Любые нормы на чем-то да основаны, проверены временем и т.д. и т.п. Сказали чистить снег пару – значит пару. Это сегодня снега пару сантиметров выпало, и вы за полчаса справились, а завтра его по колено наметет? А норма – штука такая, если ее регулярно перевыполнять, то ее обязательно поднимут (или сократят) и легче никому от этого не станет.

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

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

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

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

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

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

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

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

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

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

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

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

Для себя я давно вывел некоторые эмпирические коэффициенты, любые материалы на проекте умножаем на 1,25, а время просто увеличиваем в полтора, а то и два раза. Запас карман не тянет, особенно если это такой ресурс, как время.

Новый формат DEB822 для источников APT

Так уж пошло, что многие привычные вещи воспринимаются нами чем-то незыблемым, а попытка нарушить текущий ход вещей часто воспринимается в штыки. Новый формат источников APT - DEB822 не исключение, он появился начиная с выпуска Debian 13, а пользователи Ubuntu познакомились с ним немного раньше, начиная с Ubuntu 24.04. В данной статье мы подробно разберем новый формат, его основные отличия и преимущества перед привычным старым.

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

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

✅ Читать: https://interface31.ru/post/novyj-format-deb822-dlya-istochnikov-apt/

Их нравы
 
На конференции Linux App Summit Себастьян Вик (Sebastian Wick), мэйнтейнер инструментария Flatpak, и Адриан Вовк (Adrian Vovk), создатель инсталлятора для GNOME OS и один из разработчиков systemd-homed и systemd-sysupdate, выступили с докладом о будущем системы самодостаточных пакетов Flatpak.
 
В докладе упоминалось намерение создать для нужд Flatpak новый процесс systemd-appd для управления правами приложений и вложенной изоляции. Важный нюанс: код ещё не написан, а поддержка пока только задумывалась.
 
Но тут «разверзлись хляби небесные» в социальной сети Fediverse началась волна агрессии. Разработчиков обвинили в «насаждении диктатуры», «предательстве портативности» и «союзничестве с Ландьюком». Критика сыпалась на этапе концепции, без анализа доклада. Аргументы «мы ещё даже код не написали» игнорировались.
 

Брайан Ландьюк (Bryan Lunduke) — известный технический блогер, яростный критик systemd и корпоративного влияния в Linux . В данном контексте обвинение в «союзничестве» с ним используется как токсичный ярлык и обвинение в намеренном вреде проекту ради идеологии.  

 
В результате Адриан Вовк заявил, что до начала этой токсичной кампании он искренне хотел найти элегантное решение для пользователей альтернативных init-систем (например, выделить appd в отдельный демон, как это сделали с elogind). Но после потока неконструктивной агрессии и обвинений у него пропала мотивация тратить личное время и силы на это:
 

Но, честно говоря, всё это обсуждение сейчас совершенно бессмысленно, пока мы не написали ни единой строчки кода. Если быть откровенным, до этой травли в Феди я планировал максимально тактично отнестись к сценарию использования без systemd. Но тут я увидел, как кто-то в открытую обвиняет нас в том, что мы «союзники Ландьюка».

Так что, извините, но у меня больше нет ни малейшего желания тратить своё время на это дерьмо. Оно того не стоит.

 
К чему это привело? Да к тому, что systemd теперь станет обязательной зависимостью Flatpak, альтернативные решения разработчики больше рассматривать не желают.
 
И это не первый случай токсичного поведения меньшинств, которые потом искренне удивляются почему никто не хочет поддерживать их решения и вообще тратить на них время. Многие начинают склоняться к теориям заговора и козням корпораций.
 
На самом деле проблема не в systemd vs openrc (или подставьте сюда все что хотите). Проблема в культуре дискуссии. Токсичное меньшинство, кричащее громче всех, создаёт иллюзию «общественного мнения». Но реальные мейнтейнеры видят: за громкими лозунгами стоит оголтелый фанатизм и догматическое отторжение инакомыслия.

Настраиваем Visual Studio Code для удаленной работы через SSH

Сегодня все чаще и чаще для конфигурационных файлов используются продвинутые текстовые форматы, такие как JSON или XML, имеющие строгий синтаксис и структуру.

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

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

Поэтому гораздо удобнее использовать для этого специальные среды разработки, например, VS Code, тем более что он прекрасно умеет работать через SSH.

✅ Читать далее: https://interface31.ru/post/nastraivaem-visual-studio-code-dlya-udalennoy-raboty-cherez-ssh/

Обновление PostgreSQL в Docker через pg_dumpall
 
Обновление PostgreSQL между мажорными версиями задача не самая простая, недостаточно просто загрузить новый контейнер, нужно еще выполнить конвертацию структуры кластера СУБД, которая меняется от версии к версии.
 
Для небольших и средних баз идеально использовать импорт/экспорт при помощи утилиты pg_dumpall, что полностью исключает риск повреждения исходных данных, плюс у вас на руках всегда остается актуальная резервная копия в виде дампа всего кластера.
 
Итак, приступим, допустим мы изначально имеем:
 

services:
  db:
    container_name: postgres-db

 
В нашем случае:

▫️ db — имя сервиса Compose
▫️ postgres-db — реальное имя контейнера Docker
 
1️⃣ Остановим весь стек и запустим обратно только контейнер с СУБД, это исключит возможную запись в БД во время выгрузки:
 

docker compose stop
docker compose up -d db

 
Теперь выполним выгрузку дампа всего кластера:
 

docker exec -t postgres-db pg_dumpall -U postgres > full_backup.sql

Проверяем, что файл выгрузки создан. После чего останавливаем контейнер с БД:
 

docker compose down

 
2️⃣ Следующие шаги будут несколько различаться в отличие от того, используем ли мы Named Volumes или Bind mount, но в любом случае наша задача запустить новый контейнер СУБД с пустым томом.

🔹 Для Named Volumes было:
 

services:
  db:
    image: postgres:17
    volumes:
      - pg_data:/var/lib/postgresql/data
volumes:
  pg_data:

 
Стало:
 

services:
  db:
    image: postgres:18
    volumes:
      - pg_data_18:/var/lib/postgresql/data
volumes:
  pg_data_18:

 
🔹 Для Bind mount было:
 

services:
  db:
    image: postgres:17
    volumes:
      - ./postgres-data:/var/lib/postgresql/data

Стало:
 

services:
  db:
    image: postgres:18
    volumes:
      - ./postgres-data-18:/var/lib/postgresql/data

 
3️⃣ Запускаем СУБД:
 

docker compose up -d db

 
Мы нее запускаем весь стек, чтобы раньше времени приложения не начали писать в новую чистую БД.
 
Ждем пока база инициализируется и готова будет принимать соединения, для этого выполним команду:
 

docker logs -f postgres-db

 
Как только появится сообщение:
 

database system is ready to accept connections

 
Можно двигаться дальше. Загружаем дамп кластера СУБД:
 

docker exec -i postgres-db psql -U postgres < full_backup.sql

 
Теперь запускаем весь стек:
 

docker compose up -d

 
4️⃣ После чего рекомендуется выполнить оптимизацию загруженной базы:
 

docker exec -it postgres-db vacuumdb -U postgres --all --analyze-only

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

Особенности установки УТМ ЕГАИС на Debian 13

Сегодня попробовали установить УТМ ЕГАИС на свежий дистрибутив Debian 13. Сама установка не вызывает особых сложностей и ее можно выполнить по нашей статье:

🔹 ЕГАИС. Устанавливаем УТМ 4.2.0 на Debian (Ubuntu)

При этом, вместо libncurses5:i386 следует устанавливать libncurses6:i386, а библиотека SSL называется libssl3t64 и скорее всего будет установлена по умолчанию.

Сам пакет u-trans тоже ставится без особых проблем, запускается, но не работает. Если вы откроете лог, то увидите, что УТМ не может обнаружить ключ. Странно, ведь инсталлятор увидел Рутокен и инструменты диагностики тоже его видят.

Поэтому читаем лог дальше и находим интересные записи:

/opt/utm/lib/librtpkcsllecp.so: невозможно задействовать исполняемый стек, как требует разделяемый объект

Это значит, что библиотека требует наличия executable stack (исполняемый стек), который отключен в Debian 13 по соображениями безопасности (а также в Ubuntu, начиная с 25.10).

👆 Включить данную технологию не представляется возможным (во всяком случае без глубокого изменения системы), поэтому можно считать, что УТМ ЕГАИС несовместим с Debian 13 и грядущей Ubuntu 26.04 LTS.

😉 Ну если, конечно, разработчики Росалкогольтабакконтроль не перепишут программу, но надежды на это призрачные, с учетом того, что u-trans для Linux до сих пор 32-битное приложение.

С другой стороны, у нас все-таки Linux и каждый тут сам кузнец собственного счастья. Указанные в ошибках библиотеки являются библиотеками PKCS11Lib от Рутокен и поставляются вместе с пакетом УТМ.

Поэтому мы можем заменить их на более современные версии библиотек от Рутокен, которые не требуют executable stack.

Скачать их можно на https://download.rutoken.ru в разделе /Rutoken/PKCS11Lib/Current/Linux/x32/, просто качаем librtpkcs11ecp.so.

Для этого перейдем в домашнюю папку и скачаем библиотеку через wget, в нашем случае это последняя на сегодня версия, вам же потребуется уточнить версию библиотеки:

cd ~ 
wget  https://download.rutoken.ru/Rutoken/PKCS11Lib/Current/Linux/x32/librtpkcs11ecp.so

Затем останавливаем УТМ, заменяем необходимые библиотеки (их там две копии) и снова запускаем УТМ:

supervisorctl stop utm
cp -v librtpkcs11ecp.so /opt/utm/lib/librtpkcs11ecp.so
cp -v librtpkcs11ecp.so /opt/utm/lib/librtpkcs11ecp-replica.so
supervisorctl start utm

После чего все запускается и отлично работает. Посмотреть лог УТМ в реальном времени можно командой:

tail -f /opt/utm/transport/l/transport_info.log

Но данное действие вам придется выполнять всякий раз после переустановки или обновления УТМ.

❗️Также обратите внимание, что данный способ проверен только с токенами Рутокен и работа с JaCarta не проверялась и не гарантируется.

👉 Кроме того, добавим – непосредственной необходимости ставить УТМ ЕГАИС на Debian 13 в текущий момент нет, сервис это сугубо внутренний и при необходимости может эксплуатироваться даже на устаревших версиях системы.