?

Log in

No account? Create an account
Cat-light

klink0v


Блохи в свитере деда Сергеича


Еще про Debian Stretch (9)
Cat-light
klink0v

Чувствую, пора заводить новую рубрику про Debian Stretch.

В процессе обновления с "восьмёрки" на "девятку" обнаружил ещё несколько мелких подстав.


  1. Из девятки выпилили iSCSI Enterprise Target. Вместо него теперь "targetcli-fb". Впрочем, злые языки поговаривают, что Microsoft и вовсе официально объявила всю технологию iSCSI как deprecated, предложив мигрировать всем на SMB3. Так что в итоге я тупо последовал этим рекомендациям. Разбираться с новой реализацией iSCSI чё-то стало сильно лениво.

  2. Также оттуда выпилили Dokuwiki. Вот тут уже я "конкретно не понял". Загадочно. В Jessie есть, в Buster есть, а в Stretch-е нету. Не то, чтобы это прям вот сильная проблема, но как-то непонятно, чем она не угодила QA-команде.

  3. А вот то, что выпилили MySQL, заменив его на MariaDB, принесло чуть больше попа-боли. Я так предполагаю, что там снова началась возня с "бесплатностью" и прочей копирастией. Но если у вас есть боевые MySQL-базы, то учтите, что после обновления они скорее всего без дополнительных пинков и подталкиваний с вашей стороны не поднимутся. Будьте осторожны.


Про обновление MySQL
Cat-light
klink0v

В качестве памятки к предыдущему посту. Как корректно обновлять MySQL при переходе с собственно MySQL 5.5 на MariaDB 10.1.


  1. Обновить софт как обычно.

  2. Зайти в "/etc/mysql", забэкапить и удалить все конфиги с неприлично тухлой датой создания файла. Должны остаться только папка "mariadb.conf.d", файлы "debian-start" и "mariadb.cnf".

  3. Проверить содержимое конфига "/etc/mysql/mariadb.conf.d/50-server.cnf", внести туда коррективы если требуется.

  4. Попробовать [пере]запустить MySQL-сервер.

  5. Почитать логи. Скорее всего там обнаружатся строчки типа "[ERROR] Incorrect definition of table mysql.event: expected column 'sql_mode' at position 14 to have type бла-бла-бла", "[ERROR] mysqld: Event Scheduler: An error occurred when initializing system tables. Disabling the Event Scheduler" или что-то в этом духе.

  6. Остановить MySQL-сервер ("systemctl stop mariadb").

  7. Запустить MySQL-сервер с параметром "--skip-grant-tables" ("sudo -u mysql /usr/sbin/mysqld --skip-grant-tables").

  8. Выполнить один раз "/usr/bin/mysql_upgrade", дождаться завершения работы утилиты.

  9. Остановить MySQL-сервер ("systemctl stop mariadb").

  10. Запустить MySQL-сервер "как обычно" ("systemctl start mariadb").

  11. Снова почитать логи. На этот раз всё должно запуститься без ошибок.

  12. Для использования нового синтаксиса конфига выполнить заклинание "update-alternatives --remove my.cnf /etc/mysql/my.cnf.migrated".


Вопрос по Apache2
Cat-light
klink0v

Коллеги по цеху, вопрос имею. Внезапно. Причем, довольно тупой.

Есть Apache 2.4.25. Есть некий виртуальный хост, в конфиге которого в числе прочего прописаны следующие строчки:

Пресловутый CGI-скрипт по имени "/usr/lib/cgi-bin/refresh" выглядит примерно так:

Разумеется, в "/etc/sudoers" пользователю "www-data" явно разрешено запускать "/bin/echo" от имени суперпользователя без ввода пароля.

Дык вот. Пока используется "mpm_prefork", всё работает так, как задумано. Если же попытаться включить (активизировать) модуль "mpm_itk", то ни хрена не работает. В логах гадит примерно следующее:

При этом в "/var/log/auth.log" наблюдается гробовая тишина.

Вопрос: почему?

Update. Сам спросил, сам ответил. Злобный mpm_itk следит за тем, кто с каким UIDом форкается. Безопасность типа. Лечится вот так.