Рубрика: Uncategorized
Отключение обновлений Windows 10
Беда современных ОС от MS в том, что они считают себя умнее пользователя и обновляются когда это совсем не вовремя. И дело не только в том, что обновления не всегда полезны, а прежде всего это прерывает рабочий процесс. Оставил ПК на ночь с запущенными задачами, а он за ночь взял и сам перезагрузился. И на утро НИЧЕГО не осталось.
Поэтому отключаем. Отключить получается только обходными методами, в частности мы отключим задания из Планировщика. Просто так это сделать тоже не получится, даже запустив Планировщик из под администратора, не хватает прав.
Идём более длинным путём. Качаем PsExec, распаковываем и запускаем через cmd с правами администратора. Далее запускаем Планировщик:
psexec -i -s "C:\Windows\system32\mmc.exe" "C:\Windows\system32\taskschd.msc" /s
Далее отключаем неугодные задания из Microsoft\Windows\UpdateOrchestrator.
Всё. С внезапными обновлениями и перезагрузками покончено.
Запуск nodejs через systemd
Приложения nodejs собираются обычно на коленке и для них нет стандартного способа запуска как демон. Наиболее короткий и корректный способ сделать это сейчас — через systemd. Для этого создаем свежий конфиг в /etc/systemd/system/, называем по имени приложения, например /etc/systemd/system/myapp.service с содержимым:
[Service] WorkingDirectory=/opt/myapp/ ExecStart=/usr/bin/node /opt/myapp/app.js Restart=always StandardOutput=syslog StandardError=syslog SyslogIdentifier=myapp User=igogoo Group=igogoo Environment=NODE_ENV=production [Install] WantedBy=multi-user.target
Обычно в /etc кладутся не сами конфиги, а симлинки на действительные конфиги в /lib/systemd/system/, но поскольку наш демон кастомный, а директория /etc бэкапится полностью, создадим его прямо здесь.
Далее релодим конфигурацию и включаем демона на автостарт
systemctl daemon-reload systemctl enable node-app.service
Теперь возможны стандартные операции вроде
systemctl start myapp systemctl stop myapp systemctl restart myapp systemctl status node-app.service
Перезапускаем виртуалку, проверяем, что всё работает. Готово.
Исправление графиков munin
Бывает, что на графиках мунина появляются выбивающиеся из общей картины пики, значения которых на порядки выше типичных. Из-за этого график теряет репрезентативность и на долгое время становится бесполезным. Исправить это можно, для этого нужно выкинуть выбивающиеся значения.
Графики munin хранит в rrd-формате в /var/lib/munin. Чтобы исправить заходим туда и конвертируем rrd в xml:
cd /var/lib/munin/localdomain cp x.xml x.xml.bak rrdtool dump x.rrd > x.xml
Открываем получившийся xml, удаляем оттуда ненужное и конвертируем обратно:
rrdtool restore x.xml > x.rrd
Обновление с небезопасного репозитария
Иногда нужно поставить какой-нибудь старый или просто сторонний софт с «левых» репозитариев. Для этого apt настойчиво требует добавить в систему открытые части ключей для сверки подписей, что делать не всегда нецелесообразно. Но в последних версиях дебиановцы очень «позаботились» о пользователях и просто не позволяют качать софт и даже вообще получать его списки с левых репозитариев, что уже совсем негоже. Да, небезопасно. Да, в общем случае не правильно. Но не разрабам дистра решать как действовать в той или иной ситуации. К сожалению, приходиться обходить это отмычкой, невольно вспоминая что-то похожее в Windows стародавних версий.
Отмычка такая. Добавляем кастомный конфиг /etc/apt/apt.conf.d/99custom такого содержания:
Acquire::Check-Valid-Until "false"; Acquire::AllowInsecureRepositories "true"; Acquire::AllowDowngradeToInsecureRepositories "true";
После этого софт из сторонних репозитариев ставится нормально. При желании отмычку можно удалить или сохранить в удобном месте на случай другого такого же крайне редкого обновления.
Дебиановские установочные образы non-free firmware
Иногда возникает необходимость скачать несвежий устанвщик дебиана с версией несвободных пакетов. Свежий постоянно располагается по ссылке:
https://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/current/amd64/iso-cd/
А «несвежий» можно загрузить по ссылке из из архива:
https://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/archive/
Изменение 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, сделали единую структуру файловой системы, путь в которой не зависит от места хранения. Далее уже задача программистов перенести файлы со старой системы на новую. Для этого написали отдельный скрипт, которой вытягивал файл со старой на новую и правил путь в базе данных. Отдельно для кода заказчика пришлось писать новый интерфейс доступа к файлам и менять старые вызовы в коде на использование этого интерфейса.
Долго запрягали, но поехали очень быстро. За половину суток скрипт обработал все файлы и доступ к ним через новый интерфейс неожиданно оказался намного быстрее. И самое главное: можно полностью избавиться от всего старого окружения.
Выводы:
- Избегать использования библиотек, поддержка которых вероятно скоро прекратится. Заранее это не всегда можно определить, но есть косвенные признаки.
- Писать код с продуманной архитектурой и интерфейсами, которые позволяют легко поменять хранилище (и не только его).
- Разделять задачу на разные уровни. Конкретно здесь хранение можно почти полностью реализовать на более низком уровне без существенного потери функционала.
- Использовать как можно более прозрачные и унифицированные инструменты.