Игорь Олемской — практические заметки по системному администрированию Linux CentOS

Сам удивился почему здесь еще нет шпоры по этой теме.

Если забыл пароль root в MySQL, но имеешь рута на сервер, то заменить пароль очень просто.

Редактируем /etc/my.cnf (ну или где там он у вас) и вставляем в секцию [mysqld] строку:

skip-grant-tables

Далее, рестартуем mysqld, коннектимся:

mysql -u root mysql

Выполняем запрос

UPDATE USER SET password=password('NEWPASS') WHERE USER='root' AND `host`='localhost`;

Убираем skip-grant-tables из my.cnf, рестартуем mysqld.

Теперь пароль для root@localhost будет NEWPASS.

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

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

Как с этим бороться?

Вариант 1. Сложный.

Использовать в скрипте, который запускается по cron, проверку pid:

1. Проверяем наличие pid файла с идентификатором процесса
2. Проверяем, есть ли такой pid в памяти командой «ps -p PID»
3. Если pid запущен, прерываем работу
4. Иначе, пишем в pid файл свой pid и продолжаем

Однако это требует модификации скрипта.

Вариант 2. Простой.

Есть замечательная утилитка в Linux, называется flock (1). В качестве параметра, утилита принимает имя файла лока и команду для исполнения. flock ставит эксклюзивный лок на указанный файл и, при успехе, запускает указанную команду. Функционал flock не ограничивается только этой возможностью – на эту тему можно покурить соответствующий man.

Итак, у нас есть cron задача:

* * * * *   user  /usr/bin/php /some/heavy/script.php

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

* * * * *   user  /usr/bin/flock -xn /var/lock/script.lock -c '/usr/bin/php /some/heavy/script.php'

Ну собсно все.

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

В общем проблема решается установкой пакета alsa-utils (Fedora). Запускаем alsamixer в терминале, выбираем Capture, жмем F6, выбираем свою звуковую карту. Включаем Mic Boost, на канале микрофона делаем левый канал на полную, а правый чуть меньше. Чуть меньше означает что левый и правый канал не должны находиться на одном уровне.

Левый канал регулируется кнопками QZ, правый CE.

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

Monit 4-й версии в репозитарии EPEL (у меня был monit-4.10.1-8) оказался напрочь неработоспособен под CentOS/RHEL. Неработоспособен это значит несовместим с RC скриптами RedHat. Т.е. когда ему декларируешь start/stop команду из /etc/init.d/, в частности для стандартного апача (/etc/init.d/httpd stop/start), то наш монит в следствии урезания каких то ENV’ов не в состоянии ни запустить ни остановить службу.

Не знаю, зачем такое старье поместили в EPEL, но к счастью в исходниках более нового monit имелся spec-файл и можно руками собрать более новую RPM….

Нам потребуется рэдхатовская утилита rpm-build (yum install rpm-build).

Качаем файло monit-5.x.x.tar.gz где то из этих степей Заливаем архив в /usr/src/redhat/SOURCES. Достаем из него файл monit.spec и ложим его в /usr/src/redhat/SPECS/.

Лично я поправлял исходники и spec файл, в частности, дабы главный конф назывался не monitrc, а monit.conf. Далее

cd /usr/src/redhat/SPECS/
rpmbuild -bb monit.spec

Вуаля. Теперь у нас есть в /usr/src/redhat/RPMS/{ARCH}/ свеженький RPM монита, лишенный несовместимостей с CentOS.

Наткнулся на хорошую статью по замене загрузочного диска в софтверном RAID Linux.

Если кратко, то на второй уцелевший диск надо засетапать grub )

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

По этому поводу было много разговоров в mailing list, но чето дела не нашел.

На суд общественности предлагаю патч:  http://www.pentarh.com/files/patch-correct-resume.txt

Патч добавляет опцию -7 к демону pure-ftpd, благодаря которой демон пишет контент передаваемого файла ПРЯМО в файл назначения, а не во временный файл типа «.pureftpd-upload.XXX.YYY.ZZZ». Так же он сохраняет обработку команды APPE.

Соответственно, в конфиге добавилась аналогичная опция:

NoAtomicFile yes

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

Интрукции при сборке из исходников:

1. Положить патч в корневой каталог исходников pure-ftpd 1.0.22
2. patch -p0 < patch-correct-resume.txt
3. ./configure и все такое

Инструкции FreeBSD:

1. Положить файл в /usr/ports/ftp/pure-ftpd/files/
2. make config, make install

В основном это касается Virtual Dedicated Server (VDS/VPS), т.к. дефолтная установка MySQL на CeontOS/Fedora/RHEL с дефолтным my.cnf делает malloc на сотню с лишним мегабайт.

Конечно на потребляемую память MySQL влияют такие параметры как key_buffer, query_cache_size и т.п. Но они по дефолту идут минимальные, а кеш запросов вообще по моему отключен по дефолту.

Так вот все очень просто. Добавляем в my.cnf:

skip-innodb
skip-bdb

Это выключит хандлеры InnoDB и BerkeleyDB и всю потребляемую ими память. Ну конечно делать это нужно если вы не используете вышеприведенные типы таблиц.

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

PS: в большинстве случаев не помешает опция и skip-networking. А вот thread_cache_size я советую поставить в значение 5-15 (в зависимости от нагрузки)