Автор: unixmin
Изменение PATH в Debian buster
В дистрибутиве Buster зачем-то подчистили переменную PATH от важных и полезных путей, в частности /usr/sbin. В итоге полезные и весьма нередко используемые команды вроде dpkg-reconfigure, fdisk, blkid и многие другие стали недоступны без указания точного пути. Интерпретатор пишет command not found и усё на этом.
Возвращаем к обратному добавлением в .bashrc:
export PATH=$PATH:/usr/sbin
После следующего логина всё работает
Неподдерживаемый код
Работаем с одним проектом, в котором требуется хранить большое количество картинок. Картинки хранятся на разных серверах в сетевой файловой системе mogilefs. Выбор этой системы был сделан очень давно, когда она поддерживалась разработчиками. Как иногда бывает со свободным специфическим софтом, поддержка через некоторое время закончилась, а именно с 2013 исходный код могилы не обновляется.
В продакшене могила компилировалась из исходников на тех же CentOS серверах примерно в те же годы, т.е. начало 2010-х. На тех же серверах работает код самого проекта на php 5.4 с остальным уже сильно не новым окружением. А код заказчика развивается и хотелось бы уже мигрировать новую спецификацию языка и использовать возможности новых библиотек. Но сделать это сложно.
Код скомпилироан на старом продакшене, под старые версии библиотек. Операционная система тоже не обновляется и старые репозитарии уже не доступны, а ставить по частям новые библиотеки опасно — там ещё много другого кода с зависимостями на старое и можно их поломать. Получается, что старые библиотеки нормально не обновить.
На новом продакшене с новым окружением не компилируется старый код mogilefs и его модуля для php. Ситуация осложняется тем, что могила непрозрачно хранит файлы, их из хранилища просто так не вытащить, а в базе хранятся только их могиловские идентификаторы.
Какое решение нашли? Настроили параллельно на старых и новых серверах nfs, сделали единую структуру файловой системы, путь в которой не зависит от места хранения. Далее уже задача программистов перенести файлы со старой системы на новую. Для этого написали отдельный скрипт, которой вытягивал файл со старой на новую и правил путь в базе данных. Отдельно для кода заказчика пришлось писать новый интерфейс доступа к файлам и менять старые вызовы в коде на использование этого интерфейса.
Долго запрягали, но поехали очень быстро. За половину суток скрипт обработал все файлы и доступ к ним через новый интерфейс неожиданно оказался намного быстрее. И самое главное: можно полностью избавиться от всего старого окружения.
Выводы:
- Избегать использования библиотек, поддержка которых вероятно скоро прекратится. Заранее это не всегда можно определить, но есть косвенные признаки.
- Писать код с продуманной архитектурой и интерфейсами, которые позволяют легко поменять хранилище (и не только его).
- Разделять задачу на разные уровни. Конкретно здесь хранение можно почти полностью реализовать на более низком уровне без существенного потери функционала.
- Использовать как можно более прозрачные и унифицированные инструменты.
SSLError: [SSL: UNSUPPORTED_PROTOCOL] unsupported protocol
В новом дебиане при попытке законнектиться к очень старым сайтам из питона (и не только) периодически вылезает ошибка «SSLError: [SSL: UNSUPPORTED_PROTOCOL] unsupported protocol». Вылезает она из-за отсутствия поддержки более-менее современных протоколов серверами с теми сайтами. Работать с этими сайтами надо, а повлиять никак, поэтому единственный доступный выход — это обойти ограничение. На глобальном уровне это делается правкой секции в /etc/ssl/openssl.cnf:
[system_default_sect] MinProtocol = TLSv1.2 CipherString = DEFAULT@SECLEVEL=1
на
[system_default_sect] MinProtocol = None CipherString = DEFAULT
Серьезный недостаток такого «чита» это общее снижение безопасности системы, т.к. приложениям теперь глобально разрешается выходить по старым протоколам. Но это можно локализовать используя чит только в виртуалке на старые сайты.
Обновление с репозитария без подписи
Начиная примерно с дистрибутива buster стандартный установщик дебиана apt-get требует подписи всех используемых репозитариев. Обычный способ использования репозитария — добавление его подписи в систему. Это, однако, не всегда удобно и целесообразно. Иногда нужно что-то взять из сторонних репозитариев не добавляя подписи в систему. Это можно сделать разово при обновлении с помощью опции
apt-get update --allow-unauthenticated
Намного удобнее сделать это навсегда в отдельном списке репозитариев по типу:
deb [arch=amd64 allow-insecure=yes] http://www.deb-something-exampe.org buster main
Использование репозитериев без подписи в общем случае не безопасно, но в определённых случаях разумно обновляться именно так.
rsync на нестандартном порту с докачкой
Бывают ситуации, когда нужно скачать несколько больших файлов по ssh/scp, а канал очень узкий, так что приходится качать несколько раз. Иногда ещё и сам ssh висит на нестандартном порту и его явно нужно указать.
Первая часть задачи — заставить rsync работать с докачкой, без дотошного сравнения файлов и быстро. Это делается ключом --append-verify, который докачивает файл полность и затем сравнивает контрольную сумму. Если она расходится, то файл копируется заново. Это практически идеальный вариант для закачки многогигабайтовых образов по тонкому каналу.
Вторая часть — заставить rsync подключаться на другой порт. Прямой опции, кторая позволяет так делать нет, но можно указать опцию для ssh, через ключ «-e».
В итоге получается команда вроде
rsync -av --append-verify -e "ssh -p 55667" backup-srv:/data/backup/ /data/backup-srv