Linux

Что-то последнее время часто приходится настраивать ротацию логов dovecot с помощью logrotate. Заметка на память. Всё очень просто. Создаём файлик 1 # vim /etc/logrotate.d/dovecot с содержимым… 1 2 3 4 5 6 7 8 9 10 /var/log/dovecot*.log { mail [email protected] size 10M missingok notifempty delaycompress sharedscripts postrotate /bin/kill -USR1 `cat /var/run/dovecot/master.pid 2>/dev/null` 2> /dev/null || true endscript Для проверки и моментальной ротации можно выполнить logrotate -v /etc/logrotate.d/dovecot Для FreeBSD можно добавить в файл /etc/newsyslog.conf строку 1 /var/log/dovecot.log 644 3 2000 * J /var/run/dovecot/master.pid 30 Вот и всё UPDATE: немного больше информации вы сможете найти по адресу wiki2.dovecot.org/Logging Если при выполнении # logrotate -f -v /etc/logrotate.d/dovecot вы получаете 1 2 3 4 error: skipping "/var/log/dovecot-lda.log" because parent directory has insecure permissions (It's world writable or writable by group which is not "root") Set "su" directive in config file to tell logrotate which user/group should be used for rotation. considering log /var/log/dovecot.log error: skipping "/var/log/dovecot.log" because parent directory has insecure permissions (It's world writable or writable by group which is not "root") Set "su" directive in config file to tell logrotate which user/group should be used for rotation. considering log /var/log/dovecot-sieve.log не спешите делать выводы. Директива “su” указана в основном конфигурационном файле /etc/logrotate.conf, и если ротация выполняется полностью, то ошибок не возникает.

Иногда смотришь в top и видишь процесс, например php-fpm, но не видишь полный путь откуда же он был запущен. Находим pid нашего процесса ps ax|grep fpm Выбираем интересующий нас pid ls -l /proc/$pid/exe Получаем /proc/6162/exe -> /usr/sbin/php-fpm5.6

Чтобы разархивировать архив упакованный GZ можно воспользоваться следующей командой: 1 gzip -d <имя_файла>.gz

**Время от времени, сервисы в Linux могут сообщать что закончилось место и они не могут записать данные. Мы проверяем свободное место, оно есть. Причиной может быть закончившиеся Inode. ** В информатике inode (произносится а́йнод или ино́д), индексный дескриптор — это структура данных в традиционных для ОС UNIX файловых системах (ФС), таких как UFS, ext4. В этой структуре хранится метаинформация о стандартных файлах, каталогах или других объектах файловой системы, кроме непосредственно данных и имени. Для проверки нашего предположения набираем в консоли # df -ih получаем примерно такой вывод 1 2 3 4 5 6 7 8 9 10 Файл.система Iнодов IИспользовано IСвободно IИспользовано% Cмонтировано в udev 982K 566 982K 1% /dev tmpfs 987K 850 987K 1% /run /dev/sda2 15M 923K 14M 7% / tmpfs 987K 286 987K 1% /dev/shm tmpfs 987K 7 987K 1% /run/lock tmpfs 987K 16 987K 1% /sys/fs/cgroup /dev/sda1 0 0 0 - /boot/efi tmpfs 987K 38 987K 1% /run/user/1000 /home/user1/.Private 15M 923K 14M 7% /home/user1 Таким образом мы увидели на каком именно разделе могли закончиться Inode. Но как же выявить где именно находится это множество файлов, какой сервис их создал и почему. Допустим у нас закончились Inode в разделе /home. Переходим в него ...

Thunderbird начиная с версии 3.1 (and 3.0 to some degree) включают в себя функционал автоконфигурации почтового аккаунта. Цель автоконфигурации в создании для пользователей более простого способа настроить соединение клиента с почтовым сервером. В большинстве случаев, пользователь лишь должен загрузить и установить приложение, ввести свое настоящее имя, почтовый адрес и пароль в настройках аккаунта и почтовый клиент полностью готов к работе для получения и отправки писем, настолько безопасной, насколько это возможно . Способы получения настроек Thunderbird получает настройки сервера различными способами, каждый из них предназначен для своего случая: ISPDB ISPDB - это центральная база данных, которая в настоящий момент принадлежит коммерческой организации Mozilla Messaging, но может быть использована любым клиентом. Она содержит настройки для крупнейших почтовых провайдеров. Мы надеемся что эта база в ближайшем времени будет содержать достаточно информации для автоконфигурирования не менее половины почтовых аккаунтов пользователей. Эта база была добавлена из-за нашей уверенности в том, что не все почтовые провайдеры (в том числе Microsoft) сразу же добавят файлы конфигурации для Thunderbird на своих сервера. Конфигурация сервера почтового провайдера Почтовые провайдеры могут предоставить информацию о своих настройках для пользователей, настроив автоконфигурацию на своем сервере. <домен>, который просто возвращает статический XML с настройками, как описано ниже. При более сложных настройках, когда, например, логин не отображается в почтовом адресе XML-файл может быть также сгенерирован провайдером. В таких случаях это единственный способ получить автоматическую настройку. Файл конфигурации на жестком диске Администраторы могут поместить файл конфигурации в установочную папку Thunderbird. Этот способ предназначен для компаний, которые устанавливают Thunderbird на компютеры своих сотрудников и хотят получить легкую настройку учетной записи без необходимости настраивать конфигурацию почтового сервера. Этот метод не стоит применять в других случаях, потому что обновлять файл конфигурации весьма трудно. Таким образом, публичным провайдерам рекомендуется использовать конфигурации сервера. Подборка наугад В том случае, когда другими способами определить настройки не получилось, Thunderbird пытается угадать конфигурацию, пробуя распространенные имена почтовых серверов типа imap.<domain>, smtp.<domain>, mail.<domain> и так далее, и, когда сервер отвечет, проверяет поддержку SSL, STARTTLS и шифрование паролей (CRAM-MD5). Ручная настройка Если угадать не получается, пользователь должен ввести настройки вручную. Пользователь может также изменить настройки, даже если они были получены способами описанными выше. Все механизмы поиска используют домен почтового адреса в качестве основы для поиска. Например, для почтового адреса [email protected] , поиск выполняется в следующем порядке: ...

Вступление В серверной среде работа с командной строкой занимает много времени. Часто используется оболочка bash – командная оболочка по умолчанию большинства дистрибутивов. Вероятно, во время терминальной сессии общие команды будут повторяться часто, а вариации данных команд – еще чаще. Конечно, сначала набирать каждую команду вручную очень полезно, так как это – лишняя возможность попрактиковаться, но в какой-то момент это начинает надоедать и раздражать. К счастью, bash-оболочка имеет некоторые довольно хорошо разработанные функции истории. Умение продуктивно использовать и управлять историей в bash позволяет тратить меньше времени на ввод команд, и тем самым увеличивает объем выполненной работы. Как известно, среди разработчиков популярен так называемый принцип DRY (Don’t Repeat Yourself). Продуктивное использование истории в bash помогает работать с информацией согласно данному принципу. Это руководство демонстрирует все функции на Linux Ubuntu 12.04, но почти все современные дистрибутивы Linux будут работать подобным образом. Настройки истории в bash Прежде чем использовать историю, нужно отредактировать некоторые настройки bash, чтобы сделать ее более применимой. Bash позволяет редактировать количество предыдущих команд, которые нужно сохранить в истории. Для этого в bash есть две отдельные опции: параметр «HISTFILESIZE» задает количество команд, хранящихся в файле истории, а «HISTSIZE» указывает количество команд, которое сохраняется в памяти для текущей сессии. Это означает, что в памяти можно установить разумные пределы размера истории для текущего сеанса, а также хранить более объемную историю на диске для дальнейшего использования. ...

Иногда бывает так что, на первый взгляд, начинает без причины падать apache, или php-fpm. Никакие CoreDump в этом могут не помогать. Часто этот процесс представляет собой связку процессов и мониторить их необходимо все, так как заранее неизвестно, каким из процессов будет отработан наш запрос. На этот случай strace умеет принимать набор pid’ов процессов, на каждый процесс свой аргумент -p. Получаем список всех процессов по имени: 1 pidof apache2 Собираем список аргументов: 1 pidof apache2 | sed 's/\([0-9]*\)/\-p \1/g' Вызываем strace: 1 strace -s 1024 -f $(pidof apache2 | sed 's/\([0-9]*\)/\-p \1/g') На CentOS имя процесса другое: 1 strace -s 1024 -f $(pidof httpd | sed 's/\([0-9]*\)/\-p \1/g') Для трейса php-cgi процессов команда будет следующая: 1 strace -s 1024 -f $(pidof php5-cgi | sed 's/\([0-9]*\)/\-p \1/g') А вот более гибкий вариант для выборки процессов по регулярному выражению: 1 strace -s 1024 -f $(pgrep php5-fastcgi | sed 's/\([0-9]*\)/\-p \1/g') А для Nginx: 1 strace -s 1024 -f $(pidof nginx | sed 's/\([0-9]*\)/\-p \1/g') Для php5-fpm: 1 strace -s 1024 -f $(pidof php5-fpm | sed 's/\([0-9]*\)/\-p \1/g') Для Apache wsgi: 1 strace -s 1024 -f $(ps aux|grep wsgi|grep -v 'grep'|awk '{print $2}'| sed 's/\([0-9]*\)/\-p \1/g')

После обновления ядра CentOS перестал пускать vsftpd с ошибкой в клиенте 1 500 OOPS: prctl PR_SET_SECCOMP failed при этом в логах сервера было пусто. Пришлось добавить в конфиг /etc/vsftpd/vsftpd.conf параметр 1 seccomp_sandbox=NO Ну и конечно не забываем перезапустить VSFTP. 1 service vsftpd restart

Был как-то случай когда заканчивалось место у клиента на XFS разделе, клиент не отреагировал. Получили Input/output error. Пришлось исправлять ситуацию. Опишу что как делать и какие подводные камни можем встретить. Описание делается на примерах из интернета, реально ситуация была когда свободно было 0 места. 1. Смотрим как называется наш раздел 1 2 3 4 5 # df -h Filesystem Size Used Avail Use% Mounted on /dev/sda2 68G 45G 21G 69% / tmpfs 2.0G 0 2.0G 0% /dev/shm /dev/sdb1 2.8T 2.6T 195G 94% /data 2. Отмонтируем раздел 1 2 # umount /data umount: /data: device is busy 3. Пробуем по другому 1 2 3 # umount -f /data umount2: Device or resource busy umount: /data: device is busy 4. Ещё один вариант # umount -l /data сейчас всё нормально, кажется раздел отмонтирован 1 2 3 4 # df -h Filesystem Size Used Avail Use% Mounted on /dev/sda2 68G 45G 21G 69% / tmpfs 2.0G 0 2.0G 0% /dev/shm fsck этот раздел не берёт, предлагает использовать xfs_repair, или xfs_check, так и быть, пробуем. 5. Проверка раздела на ошибки 1 2 3 4 # xfs_repair /dev/sdb1 xfs_repair: /dev/sdb1 contains a mounted filesystem fatal error -- couldn't initialize XFS library 6. Пробуем по другому 1 2 3 # xfs_check /dev/sdb1 xfs_check: /dev/sdb1 contains a mounted and writable filesystem fatal error -- couldn't initialize XFS library Выходит не отмонтировалась наша ФС корректно. ...

Бывает необходимо быстро создать/добавить swap во FreeBSD для какого-нибудь процесса, пожирающего память с астрономической скоростью. На просторах интернета нашел замечательное решение. Создаем пустой файл размером 4Гб, заполненный нулями, в корне ФС: 1 dd if=/dev/zero of=/home/swap bs=1M count=4096 Даем права доступа только для root 1 chmod 600 /home/swap Подключаем файл как виртуальный диск 1 mdconfig -a -t vnode -f /home/swap -u 0 В каталоге /dev появляется виртуальный диск md0 И включаем в swap 1 swapon /dev/md0 Для того, чтобы каждый раз при перезагрузке файл подключался в swap, необходимо добавить строчку в /etc/rc.conf 1 swapfile="/home/swap"