пятница, 29 апреля 2016 г.

Bacula Heartbeat Interval

Источник

При использовании резервного копирования Bacula вылезает ньюанс, если между Director-сервером и FD-сервером (клиентом) находится маршрутизатор (используется NAT) - выполняемая задача (job) может вдруг ни с того, ни с сего остановиться с ошибкой "Fatal error: Network error with FD during Backup: ERR=Connection reset by peer".
Дело всё в том, что Director, инициируя задачу на клиенте, в процессе выполнения просто ждёт - весь трафик идёт между FD-сервером (клиентом) и SD-сервером (storage). Маршрутизатор спустя установленное время (timeout, у cisco - 7200 секунд) решив, что соединение между Director-сервером и FD-сервером (клиентом) умерло, просто удаляет информацию о соединении из своей таблицы соединений, обрывая таким образом выполняемую задачу.
Решается проблема тривиально - на FD-сервере (клиенте) в конфигурационном файле в секцию FileDaemon добавить:

Heartbeat Interval = 60
 
При действующем Heartbeat-интервале FD-сервер в процессе выполнения работы пересылает heartbeat-пакеты Director-серверу, создавая таким образом активность в соединении и маршрутизатор, видя, что соединение "живо", не вмешивается.

Ссылки:
  1. Client/File daemon Configuration
  2. Timeout (?) problems with some Full backups
Из официального FAQ Bacula project:


My backup starts, but dies after a while with "Connection reset by peer" error

This is usually due to some router/firewall having a connection timeout, and it kills connections that are “idle” for too long. To fix, you should do both of:
(1) activate keepalive by adding
 Heartbeat Interval = 60
in all of SD, FD and DIR configurations. Note that by itself this still won't be enough if you have some slow operations like SQL queries, accurate backups enabled, etc. You need the second point too.
(2) lower the system time before keepalives are sent
Setting the system SO_KEEPALIVE timeouts is needed as the defaults might be quite long (like 2 hours of inactivity or even longer before system starts to send keepalives). See http://tldp.org/HOWTO/html_single/TCP-Keepalive-HOWTO/ for instructions for GNU/Linux systems, or some other systems at http://www.gnugk.org/keepalive.html or http://www.starquest.com/Supportdocs/techStarLicense/SL002_TCPKeepAlive.shtml
You can check if SO_KEEPALIVE timeout is setup correctly by restarting bacula and starting a new job, and then check the current state of TCP connections with “netstat -to”. Here is how it looks when it is WRONG and needs fixing (this example shows it will not start sending keepalives for about 7200 seconds, that is 2 hours!):
# netstat -to
tcp        0      0 client:9102       server:54043      ESTABLISHED  keepalive (7196.36/0/0)
tcp        0      0 client:43628      server:9103       ESTABLISHED  keepalive (7197.26/0/0)
In that case you can try setting the system defaults to lower value, for example on GNU/Linux systems (or check URLs above for other systems) with:
sysctl -w net.ipv4.tcp_keepalive_time=60
Put that in /etc/sysctl.conf or /etc/sysctl.d/* to keep it across reboots.
Alternatively, one could try to increase router/firewall timeouts and/or number of simultaneous connections, and/or reduce time needed for backup (turning off accurate backups, reducing filesets, etc) or reducing the time network connection is idle during backup (for example, running Full backup instead of Incremental will take longer time, but the network connection will be idle for much less time, as bacula won't have to check if files have changed, which can take some time).
Some routers/firewalls (those having connection tracking / stateful firewall / NAT capabilities) will also reset all running connections if they reboot. Not much helping here, apart from avoiding condition which may make them reboot, or turning off their connection tracking / firewall / NAT (which might make them useless, of course)

четверг, 28 апреля 2016 г.

Памятка пользователям ssh

Источник

abstract: В статье описаны продвинутые функций OpenSSH, которые позволяют сильно упростить жизнь системным администраторам и программистам, которые не боятся шелла. В отличие от большинства руководств, которые кроме ключей и -L/D/R опций ничего не описывают, я попытался собрать все интересные фичи и удобства, которые с собой несёт ssh.

Предупреждение: пост очень объёмный, но для удобства использования я решил не резать его на части.

Оглавление:

  • управление ключами
  • копирование файлов через ssh
  • Проброс потоков ввода/вывода
  • Монтирование удалённой FS через ssh
  • Удалённое исполнение кода
  • Алиасы и опции для подключений в .ssh/config
  • Опции по-умолчанию
  • Проброс X-сервера
  • ssh в качестве socks-proxy
  • Проброс портов — прямой и обратный
  • Реверс-сокс-прокси
  • туннелирование L2/L3 трафика
  • Проброс агента авторизации
  • Туннелирование ssh через ssh сквозь недоверенный сервер (с большой вероятностью вы этого не знаете)

Управление ключами


Теория в нескольких словах: ssh может авторизоваться не по паролю, а по ключу. Ключ состоит из открытой и закрытой части. Открытая кладётся в домашний каталог пользователя, «которым» заходят на сервер, закрытая — в домашний каталог пользователя, который идёт на удалённый сервер. Половинки сравниваются (я утрирую) и если всё ок — пускают. Важно: авторизуется не только клиент на сервере, но и сервер по отношению к клиенту (то есть у сервера есть свой собственный ключ). Главной особенностью ключа по сравнению с паролем является то, что его нельзя «украсть», взломав сервер — ключ не передаётся с клиента на сервер, а во время авторизации клиент доказывает серверу, что владеет ключом (та самая криптографическая магия).

Генерация ключа


Свой ключ можно сгенерировать с помощью команды ssh-keygen. Если не задать параметры, то он сохранит всё так, как надо.

Ключ можно закрыть паролем. Этот пароль (в обычных графических интерфейсах) спрашивается один раз и сохраняется некоторое время. Если пароль указать пустым, он спрашиваться при использовании не будет. Восстановить забытый пароль невозможно.

Сменить пароль на ключ можно с помощью команды ssh-keygen -p.

Структура ключа


(если на вопрос про расположение ответили по-умолчанию).
~/.ssh/id_rsa.pub — открытый ключ. Его копируют на сервера, куда нужно получить доступ.
~/.ssh/id_rsa — закрытый ключ. Его нельзя никому показывать. Если вы в письмо/чат скопипастите его вместо pub, то нужно генерировать новый ключ. (Я не шучу, примерно 10% людей, которых просишь дать ssh-ключ постят id_rsa, причём из этих десяти процентов мужского пола 100%).

Копирование ключа на сервер


В каталоге пользователя, под которым вы хотите зайти, если создать файл ~/.ssh/authorized_keys и положить туда открытый ключ, то можно будет заходить без пароля. Обратите внимание, права на файл не должны давать возможность писать в этот файл посторонним пользователям, иначе ssh его не примет. В ключе последнее поле — user@machine. Оно не имеет никакого отношения к авторизации и служит только для удобства определения где чей ключ. Заметим, это поле может быть поменяно (или даже удалено) без нарушения структуры ключа.

Если вы знаете пароль пользователя, то процесс можно упростить. Команда ssh-copy-id user@server позволяет скопировать ключ не редактируя файлы вручную.

Замечание: Старые руководства по ssh упоминают про authorized_keys2. Причина: была первая версия ssh, потом стала вторая (текущая), для неё сделали свой набор конфигов, всех это очень утомило, и вторая версия уже давным давно переключилась на версии без всяких «2». То есть всегда authorized_keys и не думать о разных версиях.

Если у вас ssh на нестандартном порту, то ssh-copy-id требует особого ухищрения при работе: ssh-copy-id '-p 443 user@server' (внимание на кавычки).

Ключ сервера


Первый раз, когда вы заходите на сервер, ssh вас спрашивает, доверяете ли вы ключу. Если отвечаете нет, соединение закрывается. Если да — ключ сохраняется в файл ~/.ssh/known_hosts. Узнать, где какой ключ нельзя (ибо несекьюрно).

Если ключ сервера поменялся (например, сервер переустановили), ssh вопит от подделке ключа. Обратите внимание, если сервер не трогали, а ssh вопит, значит вы не на тот сервер ломитесь (например, в сети появился ещё один компьютер с тем же IP, особо этим страдают всякие локальные сети с 192.168.1.1, которых в мире несколько миллионов). Сценарий «злобной man in the middle атаки» маловероятен, чаще просто ошибка с IP, хотя если «всё хорошо», а ключ поменялся — это повод поднять уровень паранойи на пару уровней (а если у вас авторизация по ключу, а сервер вдруг запросил пароль — то паранойю можно включать на 100% и пароль не вводить).

Удалить известный ключ сервера можно командой ssh-keygen -R server. При этом нужно удалить ещё и ключ IP (они хранятся раздельно): ssh-keygen -R 127.0.0.1.

Ключ сервера хранится в /etc/ssh/ssh_host_rsa_key и /etc/ssh/ssh_host_rsa_key.pub. Их можно:
а) скопировать со старого сервера на новый.
б) сгенерировать с помощью ssh-keygen. Пароля при этом задавать не надо (т.е. пустой). Ключ с паролем ssh-сервер использовать не сможет.

Заметим, если вы сервера клонируете (например, в виртуалках), то ssh-ключи сервера нужно обязательно перегенерировать.

Старые ключи из know_hosts при этом лучше убрать, иначе ssh будет ругаться на duplicate key.


Копирование файлов


Передача файлов на сервер иногда может утомлять. Помимо возни с sftp и прочими странными вещами, ssh предоставляет нам команду scp, которая осуществляет копирование файла через ssh-сессию.

scp path/myfile user@8.8.8.8:/full/path/to/new/location/


Обратно тоже можно:
scp user@8.8.8.8:/full/path/to/file /path/to/put/here


Fish warning: Не смотря на то, что mc умеет делать соединение по ssh, копировать большие файлы будет очень мучительно, т.к. fish (модуль mc для работы с ssh как с виртуальной fs) работает очень медленно. 100-200кб — предел, дальше начинается испытание терпения. (Я вспомнил свою очень раннюю молодость, когда не зная про scp, я копировал ~5Гб через fish в mc, заняло это чуть больше 12 часов на FastEthernet).

Возможность копировать здорово. Но хочется так, чтобы «сохранить как» — и сразу на сервер. И чтобы в графическом режиме копировать не из специальной программы, а из любой, привычной.

Так тоже можно:

sshfs


Теория: модуль fuse позволяет «экспортировать» запросы к файловой системе из ядра обратно в userspace к соответствующей программе. Это позволяет легко реализовывать «псевдофайловые системы». Например, мы можем предоставить доступ к удалённой файловой системе через ssh так, что все локальные приложения (за малым исключением) не будут ничего подозревать.

Собственно, исключение: O_DIRECT не поддерживается, увы (это проблема не sshfs, это проблема fuse вообще).

Использование: установить пакет sshfs (сам притащит за собой fuse).

Собственно, пример моего скрипта, который монтирует desunote.ru (размещающийся у меня на домашнем комьютере — с него в этой статье показываются картинки) на мой ноут:

#!/bin/bash
sshfs desunote.ru:/var/www/desunote.ru/ /media/desunote.ru -o reconnect


Делаем файл +x, вызываем, идём в любое приложение, говорим сохранить и видим:



Параметры sshfs, которые могут оказаться важными: -o reconnect (говорит пытаться пересоединиться вместо ошибок).

Если вы много работаете с данными от рута, то можно (нужно) сделать idmap:

-o idmap=user. Работает она следующим образом: если мы коннектимся как пользователь pupkin@server, а локально работаем как пользователь vasiliy, то мы говорим «считать, что файлы pupkin, это файлы vasiliy». ну или «root», если мы коннектимся как root.

В моём случае idmap не нужен, так как имена пользователей (локальное и удалённое) совпадают.

Заметим, комфортно работать получается только если у нас есть ssh-ключик (см. начало статьи), если нет — авторизация по паролю выбешивает на 2-3 подключение.

Отключить обратно можно командой fusermount -u /path, однако, если соединение залипло (например, нет сети), то можно/нужно делать это из-под рута: sudo umount -f /path.



Удалённое исполнение кода


ssh может выполнить команду на удалённом сервере и тут же закрыть соединение. Простейший пример:

ssh user@server ls /etc/


Выведет нам содержимое /etc/ на server, при этом у нас будет локальная командная строка.

Некоторые приложения хотят иметь управляющий терминал. Их следует запускать с опцией -t:
ssh user@server -t remove_command


Кстати, мы можем сделать что-то такого вида:
ssh user@server cat /some/file|awk '{print $2}' |local_app


Это нас приводит следующей фиче:

Проброс stdin/out


Допустим, мы хотим сделать запрос к программе удалённо, а потом её вывод поместить в локальный файл

ssh user@8.8.8.8 command >my_file

Допустим, мы хотим локальный вывод положить удалённо

mycommand |scp — user@8.8.8.8:/path/remote_file

Усложним пример — мы можем прокидывать файлы с сервера на сервер: Делаем цепочку, чтобы положить stdin на 10.1.1.2, который нам не доступен снаружи:

mycommand | ssh user@8.8.8.8 «scp — user@10.1.1.2:/path/to/file»

Есть и вот такой головоломный приём использования pipe'а (любезно подсказали в комментариях в жж):

tar -c * | ssh user@server "cd && tar -x"


Tar запаковывает файлы по маске локально, пишет их в stdout, откуда их читает ssh, передаёт в stdin на удалённом сервере, где их cd игнорирует (не читает stdin), а tar — читает и распаковывает. Так сказать, scp для бедных.

Алиасы


Скажу честно, до последнего времени не знал и не использовал. Оказались очень удобными.

В более-менее крупной компании часто оказывается, что имена серверов выглядят так: spb-MX-i3.extrt.int.company.net. И пользователь там не равен локальному. То есть логиниться надо так: ssh ivanov_i@spb-MX-i3.extrt.int.company.net. Каждый раз печатать — туннельных синдромов не напасёшься. В малых компаниях проблема обратная — никто не думает о DNS, и обращение на сервер выглядит так: ssh root@192.168.1.4. Короче, но всё равно напрягает. Ещё большая драма, если у нас есть нестандартный порт, и, например, первая версия ssh (привет цискам). Тогда всё выглядит так: ssh -1 -p 334 vv_pupkin@spb-MX-i4.extrt.int.company.net. Удавиться. Про драму с scp даже рассказывать не хочется.

Можно прописать общесистемные alias'ы на IP (/etc/hosts), но это кривоватый выход (и пользователя и опции всё равно печатать). Есть путь короче.

Файл ~/.ssh/config позволяет задать параметры подключения, в том числе специальные для серверов, что самое важное, для каждого сервера своё. Вот пример конфига:

Host ric
        Hostname ооо-рога-и-копыта.рф
        User Администратор
        ForwardX11 yes
        Compression yes
Host home
        Hostname myhome.dyndns.org
        User vasya
        PasswordAuthentication no


Все доступные для использования опции можно увидеть в man ssh_config (не путать с sshd_config).


Опции по умолчанию


По подсказке UUSER: вы можете указать настройки соединения по умолчанию с помощью конструкции Host *, т.е., например:

Host *
User root
Compression yes


То же самое можно сделать и в /etc/ssh/ssh_config (не путать с /etc/ssh/sshd_config), но это требует прав рута и распространяется на всех пользователей.




Проброс X-сервера


Собственно, немножко я проспойлерил эту часть в примере конфига выше. ForwardX11 — это как раз оно.

Теория: Графические приложения в юникс обычно используют X-сервер (wayland в пути, но всё ещё не готов). Это означает, что приложение запускается и подключается к X-серверу для рисования. Иными словами, если у вас есть голый сервер без гуя и есть локальный x-сервер (в котором вы работаете), то вы можете дать возможность приложениям с сервера рисовать у вас на рабочем столе. Обычно подключение к удалённом X-серверу — не самая безопасная и тривиальная вещь. SSH позволяет упростить этот процесс и сделать его совсем безопасным. А возможность жать трафик позволяет ещё и обойтись меньшим трафиком (т.е. уменьшить утилизацию канала, то есть уменьшить ping (точнее, latency), то есть уменьшить лаги).

Ключики: -X — проброс X-сервера. -Y проброс авторизации.

Достаточно просто запомнить комбинацию ssh -XYC user@SERVER.
В примере выше (названия компании вымышленные) я подключаюсь к серверу ооо-рога-и-копыта.рф не просто так, а с целью получить доступ к windows-серверу. Безопасность microsoft при работе в сети мы все хорошо знаем, так что выставлять наружу голый RDP неуютно. Вместо этого мы подключаемся к серверу по ssh, а дальше запускаем там команду rdesktop:
ssh ric
rdesktop -k en-us 192.168.1.1 -g 1900x1200


и чудо, окошко логина в windows на нашем рабочем столе. Заметим, тщательно зашифрованное и неотличимое от обычного ssh-трафика.




Socks-proxy


Когда я оказываюсь в очередной гостинице (кафе, конференции), то местный wifi чаще всего оказывается ужасным — закрытые порты, неизвестно какой уровень безопасности. Да и доверия к чужим точкам доступа не особо много (это не паранойя, я вполне наблюдал как уводят пароли и куки с помощью банального ноутбука, раздающего 3G всем желающим с названием близлежащей кафешки (и пишущего интересное в процессе)).

Особые проблемы доставляют закрытые порты. То джаббер прикроют, то IMAP, то ещё что-нибудь.

Обычный VPN (pptp, l2tp, openvpn) в таких ситуациях не работает — его просто не пропускают. Экспериментально известно, что 443ий порт чаще всего оставляют, причём в режиме CONNECT, то есть пропускают «как есть» (обычный http могут ещё прозрачно на сквид завернуть).

Решением служит socks-proxy режим работы ssh. Его принцип: ssh-клиент подключается к серверу и слушает локально. Получив запрос, он отправляет его (через открытое соединение) на сервер, сервер устанавливает соединение согласно запросу и все данные передаёт обратно ssh-клиенту. А тот отвечает обратившемуся. Для работы нужно сказать приложениям «использовать socks-proxy». И указать IP-адрес прокси. В случае с ssh это чаще всего localhost (так вы не отдадите свой канал чужим людям).

Подключение в режиме sock-proxy выглядит так:
ssh -D 8080 user@server


В силу того, что чужие wifi чаще всего не только фиговые, но и лагливые, то бывает неплохо включить опцию -C (сжимать трафик). Получается почти что opera turbo (только картинки не жмёт). В реальном сёрфинге по http жмёт примерно в 2-3 раза (читай — если вам выпало несчастье в 64кбит, то вы будете мегабайтные страницы открывать не по две минуты, а секунд за 40. Фигово, но всё ж лучше). Но главное: никаких украденных кук и подслушанных сессий.

Я не зря сказал про закрытые порты. 22ой порт закрывают ровно так же, как «не нужный» порт джаббера. Решение — повесить сервер на 443-й порт. Снимать с 22 не стоит, иногда бывают системы с DPI (deep packet inspection), которые ваш «псевдо-ssl» не пустят.

Вот так выглядит мой конфиг:

/etc/ssh/sshd_config:
(фрагмент)
Port 22
Port 443

А вот кусок ~/.ssh/config с ноутбука, который описывает vpn

Host vpn
    Hostname desunote.ru
    User vasya
    Compression yes
    DynamicForward 127.1:8080
    Port 443


(обратите внимание на «ленивую» форму записи localhost — 127.1, это вполне себе законный метод написать 127.0.0.1)



Проброс портов


Мы переходим к крайне сложной для понимания части функционала SSH, позволяющей осуществлять головоломные операции по туннелированию TCP «из сервера» и «на сервер».

Для понимания ситуации все примеры ниже будут ссылаться на вот эту схему:



Комментарии: Две серые сети. Первая сеть напоминает типичную офисную сеть (NAT), вторая — «гейтвей», то есть сервер с белым интерфейсом и серым, смотрящим в свою собственную приватную сеть. В дальнейших рассуждениях мы полагаем, что «наш» ноутбук — А, а «сервер» — Б.

Задача: у нас локально запущено приложение, нам нужно дать возможность другому пользователю (за пределами нашей сети) посмотреть на него.

Решение: проброс локального порта (127.0.0.1:80) на публично доступный адрес. Допустим, наш «публично доступный» Б занял 80ый порт чем-то полезным, так что пробрасывать мы будем на нестандартный порт (8080).

Итоговая конфигурация: запросы на 8.8.8.8:8080 будут попадать на localhost ноутбука А.

ssh -R 127.1:80:8.8.8.8:8080 user@8.8.8.8


Опция -R позволяет перенаправлять с удалённого (Remote) сервера порт на свой (локальный).
Важно: если мы хотим использовать адрес 8.8.8.8, то нам нужно разрешить GatewayPorts в настройках сервера Б.
Задача. На сервере «Б» слушает некий демон (допустим, sql-сервер). Наше приложение не совместимо с сервером (другая битность, ОС, злой админ, запрещающий и накладывающий лимиты и т.д.). Мы хотим локально получить доступ к удалённому localhost'у.

Итоговая конфигурация: запросы на localhost:3333 на 'A' должны обслуживаться демоном на localhost:3128 'Б'.

ssh -L 127.1:3333:127.1:3128 user@8.8.8.8


Опция -L позволяет локальные обращения (Local) направлять на удалённый сервер.

Задача: На сервере «Б» на сером интерфейсе слушает некий сервис и мы хотим дать возможность коллеге (192.168.0.3) посмотреть на это приложение.

Итоговая конфигурация: запросы на наш серый IP-адрес (192.168.0.2) попадают на серый интерфейс сервера Б.

ssh -L 192.168.0.2:8080:10.1.1.1:80 user@8.8.8.8


Вложенные туннели


Разумеется, туннели можно перенаправлять.

Усложним задачу: теперь нам хочется показать коллеге приложение, запущенное на localhost на сервере с адресом 10.1.1.2 (на 80ом порту).

Решение сложно:
ssh -L 192.168.0.2:8080:127.1:9999 user@8.8.8.8 ssh -L 127.1:9999:127.1:80 user2@10.1.1.2


Что происходит? Мы говорим ssh перенаправлять локальные запросы с нашего адреса на localhost сервера Б и сразу после подключения запустить ssh (то есть клиента ssh) на сервере Б с опцией слушать на localhost и передавать запросы на сервер 10.1.1.2 (куда клиент и должен подключиться). Порт 9999 выбран произвольно, главное, чтобы совпадал в первом вызове и во втором.

Реверс-сокс-прокси



Если предыдущий пример вам показался простым и очевидным, то попробуйте догадаться, что сделает этот пример:
ssh -D 8080 -R 127.1:8080:127.1:8080 user@8.8.8.8 ssh -R 127.1:8080:127.1:8080 user@10.1.1.2

Если вы офицер безопасности, задача которого запретить использование интернета на сервере 10.1.1.2, то можете начинать выдёргивать волосы на попе, ибо эта команда организует доступ в интернет для сервера 10.1.1.2 посредством сокс-прокси, запущенного на компьютере «А». Трафик полностью зашифрован и неотличим от любого другого трафика SSH. А исходящий трафик с компьютера с точки зрения сети «192.168.0/24» не отличим от обычного трафика компьютера А.


Туннелирование


Если к этому моменту попа отдела безопасности не сияет лысиной, а ssh всё ещё не внесён в список врагов безопасности номер один, вот вам окончательный убийца всего и вся: туннелирование IP или даже ethernet. В самых радикальных случаях это позволяет туннелировать dhcp, заниматься удалённым arp-спуфингом, делать wake up on lan и прочие безобразия второго уровня.

Подробнее описано тут: www.khanh.net/blog/archives/51-using-openSSH-as-a-layer-2-ethernet-bridge-VPN.html

(сам я увы, таким не пользовался).

Легко понять, что в таких условиях невозможно никаким DPI (deep packet inspection) отловить подобные туннели — либо ssh разрешён (читай — делай что хочешь), либо ssh запрещён (и можно смело из такой компании идиотов увольняться не ощущая ни малейшего сожаления).

Проброс авторизации


Если вы думаете, что на этом всё, то…… впрочем, в отличие от автора, у которого «снизу» ещё не написано, читатель заранее видит, что там снизу много букв и интриги не получается.

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

Для начала о простом пробросе авторизации.

Повторю картинку:



Допустим, мы хотим подключиться к серверу 10.1.1.2, который готов принять наш ключ. Но копировать его на 8.8.8.8 мы не хотим, ибо там проходной двор и половина людей имеет sudo и может шариться по чужим каталогам. Компромиссным вариантом было бы иметь «другой» ssh-ключ, который бы авторизовывал user@8.8.8.8 на 10.1.1.2, но если мы не хотим пускать кого попало с 8.8.8.8 на 10.1.1.2, то это не вариант (тем паче, что ключ могут не только поюзать, но и скопировать себе «на чёрный день»).

ssh предлагает возможность форварда ssh-агента (это такой сервис, который запрашивает пароль к ключу). Опция ssh -A пробрасывает авторизацию на удалённый сервер.

Вызов выглядит так:

ssh -A user@8.8.8.8 ssh user2@10.1.1.2


Удалённый ssh-клиент (на 8.8.8.8) может доказать 10.1.1.2, что мы это мы только если мы к этому серверу подключены и дали ssh-клиенту доступ к своему агенту авторизации (но не ключу!).

В большинстве случаев это прокатывает.

Однако, если сервер совсем дурной, то root сервера может использовать сокет для имперсонализации, когда мы подключены.

Есть ещё более могучий метод — он превращает ssh в простой pipe (в смысле, «трубу») через которую насквозь мы осуществляем работу с удалённым сервером.

Главным достоинством этого метода является полная независимость от доверенности промежуточного сервера. Он может использовать поддельный ssh-сервер, логгировать все байты и все действия, перехватывать любые данные и подделывать их как хочет — взаимодействие идёт между «итоговым» сервером и клиентом. Если данные оконечного сервера подделаны, то подпись не сойдётся. Если данные не подделаны, то сессия устанавливается в защищённом режиме, так что перехватывать нечего.

Эту клёвую настройку я не знал, и раскопал её redrampage.

Настройка завязана на две возможности ssh: опцию -W (превращающую ssh в «трубу») и опцию конфига ProxyCommand (опции командной строки, вроде бы нет), которая говорит «запустить программу и присосаться к её stdin/out». Опции эти появились недавно, так что пользователи centos в пролёте.

Выглядит это так (циферки для картинки выше):

.ssh/config:
Host raep
     HostName 10.1.1.2
     User user2
     ProxyCommand ssh -W %h:%p user@8.8.8.8


Ну а подключение тривиально: ssh raep.

Повторю важную мысль: сервер 8.8.8.8 не может перехватить или подделать трафик, воспользоваться агентом авторизации пользователя или иным образом изменить трафик. Запретить — да, может. Но если разрешил — пропустит через себя без расшифровки или модификации. Для работы конфигурации нужно иметь свой открытый ключ в authorized_keys как для user@8.8.8.8, так и в user2@10.1.1.2

Разумеется, подключение можно оснащать всеми прочими фенечками — прокидыванием портов, копированием файлов, сокс-прокси, L2-туннелями, туннелированием X-сервера и т.д.

Поиск файлов с помощью find

Источник

Используйте утилиту find для поиска файлов в дереве каталогов по имени файла. Укажите имя дерева каталогов для поиска, а затем, с помощью опции `-name' - имя нужного Вам файла.
Чтобы увидеть список всех файлов системы, которые называются `top', наберите:
$ find / -name top [Enter]
Эта команда проведет поиск во всех каталогах, куда Вам разрешен доступ; если Вы не имеете прав прочесть содержимое каталога, find сообщить, что поиск в данном каталоге Вам запрещен.
Опция `-name' различает прописные и строчные буквы; чтобы использовать поиск без этих различий, воспользуйтесь опцией `-iname'.
Чтобы увидеть список всех файлов системы, которые называются `top', без учета регистра символов, наберите:
$ find / -iname top [Enter]
Эта команда найдет все файлы, название которых состоит из букв `top' - включая `Top', `top', и `TOP'.
Для поиска файлов, имена которых совпадают с определенным образцом, удобно использовать метасимволы. Образцы имен нужно указывать в одинарных кавычках.
Чтобы получить список файлов системы, имена которых начинаются с букв `top', введите:
$ find / -name 'top*' [Enter]
Чтобы получить список файлов системы, имена которых начинаются с букв `top', за которыми следуют еще три символа, введите:
$ find / -name 'top???' [Enter]
Чтобы получить список файлов системы, имена которых начинаются с букв `top', за которыми следуют пять и более символов, введите:
$ find / -name 'top?????*' [Enter]
Чтобы увидеть все файлы с расширением `.tex'в Вашем рабочем каталоге, независимо от их написания, введите:
$ find ~ -iname '*.tex' [Enter]
Чтобы увидеть все файлы в каталоге `/usr/share', содержащие в имени слово `farm', введите:
$ find /usr/share -name '*farm*' [Enter]
Используйте `-regex' вместо `-name' для поиска файлов, имена которых удовлетворяют регулярному выражению, или образцу, описывающему несколько строк.
Чтобы увидеть все файлы в текущем каталоге, имена которых содержат строку `net' или `comm', наберите:
   $ find . -regex '.*\(net\|comm\).*' [Enter]
Примечание: Опция `-regex' совпадает с полным именем файла относительно указанного каталога, а не с отдельным именем файла.
Чтобы найти файлы определенного размера, используйте опцию `-size', указав после нее требуемый размер файла. Размер файла может быть задан в трех различных формах: если перед ним указан знак плюс (`+'), ищутся все файлы, большие, чем указанный размер; если указан знак минус (`-'), ищутся все файлы, меньшие, чем указанный размер; если префикс не указан, ищутся файлы точно указанного размера. (Единица измерения - блок 512 байт; символ `k' после размера указывает килобайты, символ `b' - байты.)
Чтобы вывести список файлов в каталоге `/usr/local', размер которых больше 10,000 килобайт, введите:
$ find /usr/local -size +10000k [Enter]
Чтобы вывести список файлов в домашнем каталоге, размер которых меньше 300 байт, введите:
$ find ~ -size -300b [Enter]
Чтобы вывести список файлов системы, размер которых составляет 42 блока по 512 байт, наберите:
$ find / -size 42 [Enter]
Используйте опцию `-empty' для поиска пустых файлов - т.е. файлов с размером 0 байт. Это полезно для поиска и удаления ненужных файлов.
Чтобы найти все пустые файлы в Вашем домашнем каталоге, введите:
$ find ~ -empty [Enter]
Чтобы найти файлы, модифицированные в определенное время, используйте команду find с опциями `-mtime' или `-mmin'; аргумент опции `-mtime' определяет количество прошедших суток (24 часа), а аргумент `-mmin' - количество прошедших минут.
Чтобы вывести все файлы в каталоге `/usr/local', модифицированные точно 24 часа назад, введите:
$ find /usr/local -mtime 1 [Enter]
Чтобы вывести все файлы в каталоге `/usr', модифицированные 5 минут назад, введите:
$ find /usr -mmin 5 [Enter]
Если Вы хотите указать промежуток времени, поставьте перед числом либо знак плюс (`+'), определяя большее или равное аргументу время, или знак минус (`-'), определяя время, меньшее или равное аргументу.
Чтобы вывести все файлы в каталоге `/usr/local', модифицированные в течение последних 24 часов, введите:
$ find /usr/local -mtime -1 [Enter]
Опция `-daystart' определяет отсчет времени с момента начала текущих суток.
Чтобы вывести все файлы в Вашем домашнем каталоге, модифицированные вчера, введите:
$ find ~ -mtime 1 -daystart [Enter]
Чтобы вывести все файлы в каталоге `/usr', модифицированные в течение года, введите:
$ find /usr -mtime +356 -daystart [Enter]
Чтобы вывести все файлы в Вашем домашнем каталоге, модифицированные в период от 2 до 4 дней тому назад, наберите:
$ find ~ -mtime 2 -mtime -4 -daystart [Enter]
Чтобы найти файлы, которые новее некоторого файла, введите его имя в качестве аргумента опции `-newer'.
Чтобы вывести все файлы в каталоге `/etc', которые новее файла `/etc/motd', введите:
$ find /etc -newer /etc/motd [Enter]
Чтобы найти все файлы новее определенной даты, используйте следующий трюк: создайте временный файл в каталоге `/tmp' и установите дату его модификации на требуемую с помощью touch, а затем поределите его как аргумент для `-newer'.
Чтобы вывести все файлы в Вашем домашнем каталоге, модифицированные после 4 мая текущего года, введите:
   $ touch -t 05040000 /tmp/timestamp [Enter]
   $ find ~ -newer /tmp/timestamp [Enter]
Чтобы найти файлы, принадлежащие определенному пользователю, укажите имя пользователя в качестве агрумента опции `-user'. Например, для поиска всех файлов в каталоге `/usr/local/fonts', принадлежащих пользователю warwick, наберите:
$ find /usr/local/fonts -user warwick [Enter]
Опция `-group' подобным образом определяет файлы, принадлежащие некоторой группе пользователей.
Чтобы вывести список файлов в каталоге `/dev', принадлежащих группе audio, введите:
$ find /dev -group audio [Enter]
Вы можете использовать команду find для выполнения других команд над найденными файлами, указав требуемые команды в качестве аргуентов опции `-exec'. Если Вы используететв команде строку `''', эта строка в команде будет заменена именем текущего найденного файла. Окончание команды помечается строкой `';''.
Чтобы найти все файлы в каталоге ` /html/' с расширением `.html', и вывести строки из этих файлов, содержащие слово `organic', введите:
$ find ~/html/ -name '*.html' -exec grep organic '{}' ';' [Enter]
Чтобы ввести подтверждение выполнения команды для файла, найденного find, используйте ключ `-ok' вместо `-exec'.
Чтобы удалить из Вашего домашнего каталога файлы, доступ к которым осуществлялся более года назад, с подтверждением для каждого файла, введите:
$ find ~ -used +365 -ok rm '{}' ';' [Enter]
Вы можете определить несколько опций find одновременно, чтобы найти файлы, удовлетворяющие сразу нескольким критериям.
Чтобы вывести список файлов в Вашем домашнем каталоге, имена которых начинаются со строки `top', и которые новее файла `/etc/motd', введите:
$ find ~ -name 'top*' -newer /etc/motd [Enter]
Чтобы сжать все файлы в Вашем домашнем каталоге, размер которых превышает 2 Mb, и которые еще не сжаты с помощью gzip (не имеют расширения `.gz'), введите:
$ find ~ -size +2000000c -regex '.*[^gz]' -exec gzip '{}' ';' [Enter]
Чтобы найти наибольший файл в каталоге, используйте команду ls с опцией `-S', которая сортирует файлы в нисходящем порядке по размеру (обычно ls выводит список файлов по алфавиту). Добавьте опцию `-l', чтобы вывести размер и другие атрибуты файла.Пример:
$ ls -lS [Enter]
Чтобы вывести оглавление каталога, начав с файлов наименьшего размера, используйте ls с ключами `-S' и `-r', которые сортируют вывод в обратном порядке.Пример:
$ ls -lSr [Enter]
Чтобы вывести список каталогов, отсортированных по размеру - то есть размеру всех содержащихся в них файлов - используйте du и sort. Команда du выводит список каталогов в восходящем порядке, начиная с самого маленького; опция `-S' помещает при выводе в первую колонку размер каталога в килобайтах. Укажите требуемое дерево каталогов в качестве аргумента du и перенаправьте вывод в команду sort с ключом `-n', которая отсортирует список по числам.
Чтобы вывести список подкаталогов в текущем дереве каталогов, отсортированный по размеру, введите:
$ du -S . sort -n [Enter]|
Если Вам нужно, чтобы первыми были указаны самые большие каталоги, используйте ключ `-r':
$ du -S . sort -nr [Enter]|
Чтобы быстро определить количество файлов в каталоге, используйте ls и перенаправьте вывод в команду `wc -l', которая выволит количество строк, пришедших на ее вход.
Для вывода общего количества файлов в текущем каталоге введите:
   $ ls | wc -l [RET]
   19
   $
Общее количество файлов - 19. Поскольку ls по умолчанию не показывает скрытые файлы, приведенная выше команда не будет их учитывать. Опция `-A' для ls позволит посчитать обычные и скрытые файлы:
   $ ls -A | wc -l [RET]
   81
   $
Чтобы посчитать количество файлов во всем дереве каталогов, а не только в отдельном каталоге, используйте find вместо ls, и укажите специальный ключ для find - строку `
! -type d', чтобы исключить вывод и подсчет каталогов.
Чтобы вывести количество файлов в дереве `/usr/share', введите:
$ find /usr/share \! -type d wc -l [Enter]|
Чтобы вывести количество файлов и каталогов в дереве `/usr/share', введите:
$ find /usr/share wc -l [Enter]|
Чтобы вывести количество каталогов в дереве `/usr/share', введите:
$ find /usr/share \! -type f wc -l [Enter]|
Команда which позволяет Вам получить полный путь к приложению или другой команде, указав базовое имя файла в качестве опции. Это удобно, чтобы убедиться, что данное приложение или команда присутствуют в системе.
Чтобы определить, установлен ли в Вашей системе perl и где он расположен, введите:
   $ which perl [RET]
   /usr/bin/perl

MySQL Remove bin-log by the variable expire_log_days

2, Remove bin-log by the variable expire_log_days
An alternative option is to set “expire_log_days” as MySQL server parameter. The default values for expire_log_days is not to purge logs. You can either set it in MySQL’s configuration file or in a command terminal like below:
mysql> SET GLOBAL expire_logs_days = 7;
Query OK, 0 rows affected (0.00 sec)

mysql> show variables like 'expire_%';
+------------------+-------+
| Variable_name    | Value |
+------------------+-------+
| expire_logs_days |  7    |
+------------------+-------+
1 row in set (0.00 sec)
When this vavirable takes effect, the log files will be removed automatically on a weekly basis.

UPDATE:

You can remove binlog files by "PURGE BINARY LOGS"  command.

examples:
 
PURGE BINARY LOGS TO 'mysql-bin.010';
PURGE BINARY LOGS BEFORE '2008-04-02 22:46:26';
 
The BEFORE variant's datetime_expr argument should evaluate to a DATETIME value 
(a value in 'YYYY-MM-DD hh:mm:ss' format).

How to fix MySql Replication Error 1236

Source

We have some websites that use two database servers in master-master replication. Recently one of the servers died and had to be resurrected. (They are cloud based and SoftLayer doesn't seem to have their cloud-based offering thing nailed down, yet. Every week one of them will go down and be unresponsive until tech support does some magic.)

After one of the servers was brought back up the other server would not connect. It "Slave_IO_Running: No" and "Seconds_Behind_Master: null" which means it was not playing nicely.

First, I went to the MySql log files, which for this server is found at /var/log/mysql.log and looked at the last few messages here by running "tail /var/log/mysql.log" from the command prompt. This revealed the error number (server_errno=1236). It also had the following info:

Got fatal error 1236: 'Client requested master to start replication from impossible position' from master when reading data from binary log

Just before this entry in the mysql.log it indicates the file and position that it is trying to read. So, with this data in hand, I headed over to the master server and took a look at the bin logs. They are located in /var/lib/mysql/. Here I took a look at the file in question using the mysqlbinlog utility. I used the following command to check out the bin log. Obviously, you'll have to replace the position and file name with the position and file indicated in your mysql.log.
mysqlbinlog --offset=128694 mysql-bin.000013

And, this is what I saw here, among other things:
Warning: this binlog was not closed properly. Most probably mysqld crashed writing it.

Well, that explains things! When the server crashed the bin log was not closed properly. This is easy to fix. Going back to the slave server, I stopped the slave, reset the bin log position and started the server.
?
1
2
3
4
STOP SLAVE;
CHANGE MASTER TO MASTER_LOG_POS = 0;
CHANGE MASTER TO MASTER_LOG_FILE = 'mysql-bin.000014';
START SLAVE;

I simply pointed the slave to the start of the next bin log. It started right up with no problem.

Update 5/21/13 - An anonymous commentor made a good point about potentially losing data using the above technique. If you are in a situation like I am (master-master replication with 100's of gigs of non-critical data) this is really the only way of getting back up without significant down time. But if you are in a master-slave configuration with a manageable data set or its critical you slave doesn't miss any data, you should probably dump the master database and re-create the slave database to make sure you didn't miss anything.

Установка и настройка Dovecot

Источник, спасибо автору.

В этой заметке рассмотрена настройка агента доставки почты (MDA) Dovecot для совместного использования с Postfixadmin. Рассмотрена вторая версия сервера, настройка которой несколько отличается от настройки первой версии. Я и раньше не считал документацию на Dovecot хорошей, но для настройки второй версии мне пришлось потратить ещё больше времени, потому что для неё документации ещё меньше. Собственно, всё, что есть из документации - это официальный сайт с wiki-страницами, больше напоминающими обрывки HowTo, нежели систематическую исчерпывающую документацию по каждой доступной опции.

Файл конфигурации Dovecot состоит из нескольких логических элементов: глобальные настройки, раздел настройки словарей, несколько разделов настройки сервисов, раздел настройки плагинов. Файл конфигурации не назовёшь логичным, поскольку плагины включаются в одном разделе файла, а настройки хранятся в другом. Взаимосвязи между плагинами и используемыми ими сервисами тоже не всегда кажутся очевидными.

Однако при всех указанных недостатках, Dovecot всё равно настраивается проще других подобных систем (Courier и Cyrus). Причин у этого, на мой взгляд, две: он лучше поддерживается разработчиками дистрибутива и в нём меньше исторических наслоений. (По непонятным причинам поддержка Courier оставляет желать лучшего: когда я пытался его настроить, мне пришлось пересобрать пакет с библиотекой SASL, чтобы она поддерживала прямую работу с courier-auth. После длительных мучений с его настройкой, я решил больше не биться головой в закрытую дверь, пытаясь исправить очередную кривизну в поставке по умолчанию, и настроил Dovecot. Собственно, я и пытался-то настроить Courier из простого любопытства).

Главное разочарование, постигшее меня при настройке второй версии Dovecot, заключалось в том, что теперь не работает придуманный мной метод аутентификации POP-before-SMTP. В новом Dovecot можно задавать только скрипты, выполняемые при отключении клиента от сервера POP3 или IMAP, а не в момент подключения, как это было раньше. В результате для того, чтобы отправить письмо, нужно не только подключиться к POP3 или IMAP-серверу, но и тут же отключиться от него. Впрочем, большинство современных почтовых клиентов имеет встроенную поддержку аутентификации на SMTP-сервере, поэтому утрата не выглядит сейчас столь уж серьёзной.

1. Установка Dovecot

Установим пакеты Dovecot, содержащие поддержку серверов POP3 и IMAP, а также пакет, позволяющий использовать данные из MySQL:

# apt-get install dovecot-core dovecot-imapd dovecot-pop3d dovecot-mysql
2. Подготовка системы

Создадим группу и пользователя vmail, от имени которого будет работать Dovecot и дадим этому пользователю доступ к каталогу, в котором будет храниться почта пользователей почтовой системы. На серверах для размещения почтовых ящиков, как и другой часто меняющейся информации, обычно используется раздел /var, который заранее делается достаточно большим. На настраиваемой мной системе больше всего свободного места на разделе home, поэтому я размещу почтовые ящики пользователей на нём:
# groupadd -g 120 -r vmail
# useradd -g 120 -r -u 120 vmail
# mkdir /home/vmail
# chown vmail:vmail /home/vmail
# chmod u=rwx,g=rx,o= /home/vmail
Добавляем пользователя dovecot для доступа к базе данных:
USE mysql;

INSERT INTO user(user, password, host) VALUES('dovecot', PASSWORD('dovecot_password'), 'localhost');

FLUSH PRIVILEGES;
Вместо пароля dovecot_password я сгенерировал случайный пароль при помощи программы pwgen из одноимённого пакета. Можно сгенерировать сразу длинный пароль, поскольку вводить вручную его не придётся:
$ pwgen 16
Здесь и ниже я оставил пароль dovecot_password для того, чтобы описание настройки было более наглядным. При реальной настройке Dovecot стоит использовать случайный пароль.

Таблица mailbox в базе данных postfixadmin содержит информацию о почтовых ящиках. Дадим пользователю dovecot доступ к таблице mailbox и её колонкам:
USE mysql;

INSERT INTO tables_priv(host, db, user, table_name, table_priv, column_priv) VALUES
('localhost', 'postfixadmin', 'dovecot', 'mailbox', '', 'Select');

INSERT INTO columns_priv(host, db, user, table_name, column_name, column_priv) VALUES
('localhost', 'postfixadmin', 'dovecot', 'mailbox', 'username', 'Select'),
('localhost', 'postfixadmin', 'dovecot', 'mailbox', 'local_part', 'Select'),
('localhost', 'postfixadmin', 'dovecot', 'mailbox', 'domain', 'Select'),
('localhost', 'postfixadmin', 'dovecot', 'mailbox', 'password', 'Select'),
('localhost', 'postfixadmin', 'dovecot', 'mailbox', 'quota', 'Select'),
('localhost', 'postfixadmin', 'dovecot', 'mailbox', 'active', 'Select');

FLUSH PRIVILEGES;
3. Базовая настройка Dovecot

Обратимся к странице Сравнение почтовых программ на Википедии. Судя по сводной таблице механизмов аутентификации, поддерживаемых разными почтовыми клиентами, большинство из них поддерживает механизмы PLAIN, LOGIN и CRAM-MD5.

При использовании PLAIN и LOGIN пароль передаётся в открытом виде, а хранить в базе данных его можно в хэшированном виде. В случае с CRAM-MD5 дело обстоит с точностью до наоборот - пароль передаётся в хэшированном виде, но хранится - в открытом.

Что безопаснее? Если вы не собираетесь настраивать защищённые версии протоколов IMAP и POP3, то лучше использовать CRAM-MD5. На мой взгляд вероятность перехвата паролей выше, нежели вероятность получения не авторизованного доступа к базе данных. Если же предполагается всегда использовать шифрование, то безопаснее использовать PLAIN и LOGIN, потому что при их использовании можно хранить пароли в базе данных в хэшированном виде. Пароль при этом не получится перехватить, а в случае получения доступа к хэшам паролей воспользоваться ими напрямую не удастся, т.к. нужно будет подобрать пароль, который будет соответствовать хэшу.

Я буду использовать защищённые версии протоколов IMAP и POP3, поэтому настрою в файле /etc/dovecot/conf.d/10-auth.conf механизмы PLAIN и LOGIN, чтобы хранить пароли в базе данных в хэшированном виде:
disable_plaintext_auth = no
auth_default_realm = domain.tld
auth_mechanisms = plain login
!include auth-sql.conf.ext
Настроим использование учётных данных из базы данных SQL, прописав в файле /etc/dovecot/conf.d/auth-sql.conf.ext следующие секции:
passdb {
  driver = sql
  args = /etc/dovecot/dovecot-mysql.conf
}
userdb {
  driver = sql
  args = /etc/dovecot/dovecot-mysql.conf
}
Теперь нужно прописать в файл /etc/dovecot/dovecot-mysql.conf учётные данные для доступа к базе данных и запросы для извлечения из неё необходимой информации о почтовых ящиках:
driver = mysql

connect = host=localhost dbname=postfixadmin user=dovecot password=dovecot_password

default_pass_scheme = MD5-CRYPT

password_query = SELECT local_part AS username, \
                        domain, \
                        password, \
                        120 AS userdb_uid, \
                        120 AS userdb_gid, \
                        CONCAT('*:bytes=', quota) AS userdb_quota_rule \
                 FROM mailbox \
                 WHERE username = '%u' \
                   AND active = 1

user_query =  SELECT CONCAT('*:bytes=', quota) AS quota_rule, \
                     120 AS uid, \
                     120 AS gid \
              FROM mailbox \
              WHERE username = '%u' \
                AND active = 1

iterate_query = SELECT username AS user \
                FROM mailbox \
                WHERE active = 1
Выделенные жирным шрифтом части запросов используются плагином quota. Если вы не собираетесь настраивать этот плагин, то эти части запросов можно пропустить. Настройка этого плагина подробнее рассмотрена ниже.

Стоит сразу же изменить права доступа к этому файлу, чтобы посторонние пользователи системы не смогли увидеть пароль, под которым dovecot будет подключаться к базе данных:
# chown root:dovecot /etc/dovecot/dovecot-mysql.conf 
# chmod u=rw,g=r,o= /etc/dovecot/dovecot-mysql.conf
В противном случае потенциальный злоумышленник, получивший локальный непривилегированный доступ к системе, сможет получить список почтовых ящиков системы и хэши паролей от них (или сами пароли). Понятно, чем может быть опасно получение доступа к паролям или их хэшам - злоумышленник сможет получить полный доступ к ящикам. Не столь очевидной может показаться опасность получения злоумышленником списка почтовых ящиков - на них он может начать отправлять спам, что тоже не обрадует ни пользователей почтовой системы, ни её администратора.

Изменим форматирование отметок времени, вписав в файл /etc/dovecot/conf.d/10-logging.conf следующую настройку:
log_timestamp = "%Y-%m-%d %H:%M:%S "
На время отладки также можно включить другие опции из этого файла:
auth_verbose = yes
auth_verbose_passwords = yes
auth_debug = yes
mail_debug = yes
В файле /etc/dovecot/conf.d/10-mail.conf настроим путь к почтовым ящикам и пользователя, от имени которого dovecot будет работать с ящиками:
mail_home = /home/vmail/%Ld/%Ln
mail_location = maildir:/home/vmail/%Ld/%Ln
mail_uid = vmail
mail_gid = vmail
first_valid_uid = 120
last_valid_uid = 120
first_valid_gid = 120
last_valid_gid = 120
Сейчас придётся немного опять забежать вперёд и настроить SASL. Это сервис, при помощи которого Postfix будет проверять учётные данные почтовых клиентов. Для этого отредактируем файл /etc/dovecot/conf.d/10-master.conf и впишем в него путь к UNIX-сокету и права доступа к нему:
service auth {
  unix_listener /var/spool/postfix/private/auth {
    mode = 0600
    user = postfix
    group = postfix
  }
}
Сокет-файл размещается в chroot-окружении Postfix и доступен для чтения и записи только пользователю postfix.

Зададим в файле /etc/dovecot/conf.d/15-lda.conf адрес, с которого Dovecot будет отправлять сообщения об ошибках:
postmaster_address = postmaster@domain.tld
Осталось отредактировать файл /etc/dovecot/dovecot.conf, указав в нём адрес, на котором сервер будет ожидать подключений:
!include_try /usr/share/dovecot/protocols.d/*.protocol
listen = *
!include conf.d/*.conf
!include_try local.conf
Начальная настройка сервера окончена. Осталось перезапустить Dovecot, чтобы настройки вступили в силу:
# /etc/init.d/dovecot restart

4. Настройка плагина acl

Плагин acl позволяет пользователям предоставлять друг другу доступ к папкам в своих почтовых ящиках. Это может быть полезно для корпоративных пользователей. Например, для директора и его заместителя. Или для директора и его секретаря. Или для сотрудников из одного отдела, которые подменяют друг друга на время обеда или отпуска. Эта возможность, естественно, доступна только при использовании протокола IMAP.

В файле /etc/dovecot/conf.d/10-mail.conf включаем использование плагина:
mail_plugins = acl
В файле /etc/dovecot/conf.d/20-imap.conf включаем использование плагина в IMAP-сервере:
protocol imap {
  mail_plugins = $mail_plugins imap_acl
}
В файле /etc/dovecot/conf.d/10-mail.conf прописываем следующие настройки:
namespace inbox {
  type = private
  separator = /
  prefix =
  inbox = yes
}

namespace {
  type = shared
  separator = /
  prefix = shared/%%u/
  location = maildir:%%h:INDEX=%h/shared/%%u
  subscriptions = yes
  list = children
}
Эти настройки описывают два пространства имён: в первом хранится личная почта пользователя, а во втором будут отображаться каталоги других пользователей, к которым этот пользователь имеет доступ.

Поясню смысл настроек location для пространства имён общих каталогов:
  • maildir:%%h - означает место расположения чужого почтового ящика в формате Maildir,
  • %%h - полный путь к Maildir-каталогу чужого ящика,
  • INDEX=%h/shared/%%u - задаёт каталог, в который как бы монтируются каталоги чужой почты, к которым её владелец дал нам доступ,
  • %h - путь к Maildir-каталогу нашего ящика,
  • %%u - имя другого пользователя в виде box@domain.tld.

В файл /etc/dovecot/conf.d/90-acl.conf прописываем настройки плагина:
plugin {
  acl = vfile
  acl_shared_dict = file:/home/vmail/%Ld/shared-mailboxes.db
}
Значение vfile предписывает создавать внутри почтового ящика файл dovecot-acl, в котором и будут прописываться права доступа к нему со стороны других пользователей.

Значение acl_shared_dict указывает путь к файлу словаря, который позволит пользователям узнавать, к каким каталогам в чужих почтовых ящиках у них имеется доступ. В данном случае для каждого домена будет создан отдельный файл словаря, расположенный в каталоге домена, на одном уровне с ящиками.

Заодно опишем в файле /etc/dovecot/conf.d/15-mailboxes.conf назначение различных каталогов внутри пространства имён, в котором хранится личная почта пользователя:
namespace inbox {
  mailbox Drafts {
    special_use = \Drafts
  }
  mailbox Junk {
    special_use = \Junk
  }
  mailbox Trash {
    special_use = \Trash
  }
  mailbox Sent {
    special_use = \Sent
  }
}
  • Drafts - каталог черновиков,
  • Junk - каталог для спама,
  • Trash - каталог для удалённых писем,
  • Sent - каталог для отправленных писем.
Современные почтовые программы смогут прямо по протоколу IMAP узнать назначение каждого из специальных каталогов, вне зависимости от их названия. Это бывает полезно, если каталог имеет нестандартное название или название на языке пользователя ящика, например "Входящие" или "Спам".

Чтобы настройки плагина acl вступили в силу, нужно перезапустить Dovecot:
# /etc/init.d/dovecot restart
5. Настройка плагина quota

Плагин quota позволяет назначить для почтового ящика ограничения на объём хранящихся в нём писем или даже на их общее количество. На мой взгляд, ограничение на общее количество писем имеет довольно мало смысла. Единственная польза, которая мне приходит на ум - это возможность защититься от исчерпания inode'ов в файловой системе, если кто-то намеренно решит отправить огромное количество мелких писем в ящики пользователей, с целью нарушить работу почтовой системы.

Мы настроим плагин так, чтобы он использовал значения квот, указанные в интерфейсе Postfixadmin. Эти квоты ограничивают только максимальный объём писем в ящике.

Включим использование плагина в файле /etc/dovecot/conf.d/10-mail.conf:
mail_plugins = acl quota
Жирным шрифтом показан добавленный текст, а курсивом - текст, добавленный нами при включении плагина acl. Если вы не включали плагин acl, то вписывать этот текст не нужно.
В файл /etc/dovecot/conf.d/15-lda.conf впишем, что в случае превышения квоты Dovecot должен сообщать о временной ошибке, но не отклонять письмо окончательно. Почтовый сервер отправителя (или наш MTA) будет периодически предпринимать повторные попытки в надежде на то, что адресат почистит свой ящик от ненужных писем.
quota_full_tempfail = yes
В файл /etc/dovecot/conf.d/20-imap.conf добавим поддержку квот в IMAP-сервере:
protocol imap {
  mail_plugins = $mail_plugins imap_acl imap_quota
}
Этот плагин позволит почтовым клиентам, работающим по протоколу IMAP, узнавать квоту почтового ящика и её текущее использование.

Укажем в файле /etc/dovecot/conf.d/90-quota.conf, что значения квот берутся из словаря и зададим пустое правило по умолчанию:
plugin {
  quota = dict:User quota::proxy::quota
  quota_rule = *:
}
Текст proxy задаёт использование прокси-сервера, который выполняет мультиплексирование подключений к базе данных. Прокси устанавливает постоянные подключения к базе данных и выполняет необходимые запросы через эти подключения. Таким образом снижаются накладные расходы на повторные переподключения и уменьшается количество одновременно установленных подключений, поскольку без использования прокси каждый процесс, обслуживающий одного клиента, устанавливал бы своё собственное подключение к базе данных.

Плагин quota использует сервис доступа к словарям данных. Включим и настроим этот сервис в файле /etc/dovecot/conf.d/10-master.conf:
service dict {
  unix_listener dict {
    mode = 0600
    user = vmail
    group = vmail
  }
}
Теперь укажем в файле /etc/dovecot/dovecot.conf, где хранятся настройки словаря с данными квот:
dict {
  quota = mysql:/etc/dovecot/dovecot-dict-mysql.conf
}
И укажем в файле с настройками /etc/dovecot/dovecot-mysql-dict.conf, в какой таблице хранятся данные о текущем использовании квот и как подключиться к базе данных с этой таблицей:
connect = host=localhost dbname=postfixadmin user=dovecot password=dovecot_password

map {
  pattern = priv/quota/storage
  table = quota2
  username_field = username
  value_field = bytes
}
Сразу же изменим права доступа к этому файлу, чтобы посторонние пользователи системы не смогли увидеть пароль, под которым dovecot будет подключаться к словарям в базе данных:
# chown root:dovecot /etc/dovecot/dovecot-dict-mysql.conf 
# chmod u=rw,g=r,o= /etc/dovecot/dovecot-dict-mysql.conf
Выдадим пользователю dovecot права на доступ к таблице quota2 и её колонкам:
USE mysql;

INSERT INTO tables_priv(host, db, user, table_name, table_priv, column_priv) VALUES
('localhost', 'postfixadmin', 'dovecot', 'quota2', 'Delete', 'Select,Insert,Update');

INSERT INTO columns_priv(host, db, user, table_name, column_name, column_priv) VALUES
('localhost', 'postfixadmin', 'dovecot', 'quota2', 'username', 'Select,Insert,Update'),
('localhost', 'postfixadmin', 'dovecot', 'quota2', 'bytes', 'Select,Insert,Update');

FLUSH PRIVILEGES;
Не забудьте вписать в файл /etc/dovecot/dovecot-mysql.conf текст, выделенный жирным шрифтом в разделе 3. Этот текст извлекает из базы данных настройки квот ящиков.

Настройка плагина закончена. Осталось перезапустить Dovecot:
# /etc/init.d/dovecot restart
6. Настройка плагина expire

Плагин expire позволяет автоматически удалять устаревшие письма из каталогов почтовых ящиков. Обычно это каталоги с удалённой почтой и спамом. Поскольку алгоритмы обнаружения спама не совершенны, не стоит удалять такие письма - нужно дать пользователю возможность прочитать письмо, ошибочно определённое как спам. С другой стороны, хочется избавить пользователя от утомительной привычки периодически чистить почтовый ящик, особенно для каталогов со спамом и удалёнными письмами - письма в этих каталогах обладают заведомо низкой ценностью.

Включим плагин в файле /etc/dovecot/conf.d/10-mail.conf:
mail_plugins = acl quota expire
Курсивом отмечены плагины, настройка которых была рассмотрена выше. Если вы пропустили их настройку, не нужно их вписывать - достаточно добавить текст, отмеченный жирным шрифтом.
Теперь настроим плагин в файле /etc/dovecot/conf.d/90-expire.conf:
plugin {
  expire = Trash 7            # Хранение писем в папке Trash - 7 дней
  expire2 = Trash/* 7         # Хранение писем в подпапках папки Trash - 7 дней
  expire3 = Spam 30           # Хранение писем в папке Spam - 30 дней
  expire_dict = proxy::expire # Использовать словарь для хранения отметок времени писем
}
Текст proxy задаёт использование прокси-сервера, который выполняет мультиплексирование подключений к базе данных (см. выше описание плагина quota). На самом деле для каждого каталога будет храниться лишь одна отметка времени для самого старого письма в каталоге, которая будет обновляться при очередной чистке каталога.

В файле /etc/dovecot/dovecot.conf укажем путь к файлу с настройками словаря, в котором будут храниться данные об отметках времени писем:
dict {
  quota = mysql:/etc/dovecot/dovecot-dict-mysql.conf
  expire = mysql:/etc/dovecot/dovecot-dict-mysql.conf
}
Курсивом отмечена строчка, которая была добавлена в процессе настройки плагина quota. Сейчас же нужно добавить строчку, отмеченную жирным шрифтом.

Настроим учётные данные для подключения к базе данных в файле /etc/dovecot/dovecot-mysql-dict.conf. Там же укажем, в какой таблице и в каких её полях хранить отметки времени.
connect = host=localhost dbname=postfixadmin user=dovecot password=dovecot_password

map {
  pattern = priv/quota/storage
  table = quota2
  username_field = username
  value_field = bytes
}

map {
  pattern = shared/expire/$user/$mailbox
  table = expire
  value_field = timestamp

  fields {
    username = $user
    mailbox = $mailbox
  }
}
Тут так же нужно добавить лишь текст, выделенный жирным шрифтом. Курсивом отмечен текст, добавленный при настройке плагина quota.

Если вы ещё не поменяли права доступа к этому файлу, стоит сделать это сейчас, чтобы посторонние пользователи системы не могли прочитать пароль, под которым dovecot будет подключаться к словарям в базе данных:
# chown root:dovecot /etc/dovecot/dovecot-dict-mysql.conf 
# chmod u=rw,g=r,o= /etc/dovecot/dovecot-dict-mysql.conf
Включим в файле /etc/dovecot/conf.d/10-master.conf сервис для доступа к словарям, если вы его ещё не включили при настройке плагина quota:
service dict {
  unix_listener dict {
    mode = 0600
    user = vmail
    group = vmail
  }
}
Поскольку по умолчанию в Postfixadmin нет таблицы, предназначенной для хранения информации плагина expire из Dovecot, создадим эту таблицу и дадим пользователю Dovecot права доступа к ней:
USE postfixadmin;

CREATE TABLE expire (
  username varchar(255) not null,
  mailbox varchar(255) not null,
  expire_stamp integer not null,
  primary key (username, mailbox)
);

USE mysql;
 
INSERT INTO tables_priv(host, db, user, table_name, table_priv, column_priv) VALUES
('localhost', 'postfixadmin', 'dovecot', 'expire', 'Delete', 'Select,Insert,Update');

INSERT INTO columns_priv(host, db, user, table_name, column_name, column_priv) VALUES
('localhost', 'postfixadmin', 'dovecot', 'expire', 'username', 'Select,Insert,Update'),
('localhost', 'postfixadmin', 'dovecot', 'expire', 'mailbox', 'Select,Insert,Update'),
('localhost', 'postfixadmin', 'dovecot', 'expire', 'expire_stamp', 'Select,Insert,Update');

FLUSH PRIVILEGES;
На этом настройку плагина можно считать оконченной. Осталось лишь перезапустить Dovecot, чтобы изменения вступили в силу:
# /etc/init.d/dovecot restart
7. Настройка SSL

Настройка SSL будет подробнее рассмотрена в одной из следующих заметок. Там будет описана настройка отдельных сертификатов SSL для разных доменов, а также будет освещён вопрос подготовки самих сертификатов - самоподписанных или подписанных центром сертификации.

Если у вас имеются готовый подписанный сертификат, можно включить поддержку SSL в файле /etc/dovecot/conf.d/10-ssl.conf и указать в нём пути к файлам сертификата:
ssl = yes
ssl_cert = </etc/ssl/mail_public.pem
ssl_key = </etc/ssl/mail_private.pem
После настройки сертификатов нужно перезапустить Dovecot, чтобы изменения вступили в силу:
# /etc/init.d/dovecot restart
8. Настройка плагина sieve

Sieve - это скрипты фильтрации почты, которые выполняются агентом локальной доставки (LDA) в момент получения письма от почтового сервера (MTA). Скрипты позволяют раскладывать письма в разные папки, ориентируясь на их содержимое - тему письма, получателей, отправителей и т.п. Можно удалить письмо, переслать его на другой ящик или отправить уведомление отправителю, причём использовать можно любое поле заголовка или содержимое тела письма.

Главное преимущество Sieve заключается в том, что пользователю не нужно настраивать правила фильтрации в каждом из используемых им почтовых клиентов - правила едины для всех почтовых клиентов сразу. Кроме того, фильтрация происходит вообще без участия клиента. Клиент, подключившись к почтовому ящику, имеет возможность работать уже с отсортированной почтой. Кроме того, отправка уведомлений о получении или пересылка писем на другой ящик вообще может происходить без участия почтового клиента.

Конечно, в наши времена больших почтовых сервисов типа Gmail или Яндекс-почты, этим никого не удивишь. Но тут плюс заключается в том, что перед нами не стоит дилемма "удобство" - "безопасность". Мы можем хранить почту у себя, не делясь ею с посторонними компаниями, имея над ней полный контроль, и в то же время можем пользоваться удобствами, характерными для больших почтовых сервисов.

Установим пакет с плагином Sieve:
# apt-get install dovecot-sieve
Включим использование плагина в файле /etc/dovecot/conf.d/15-lda.conf:
protocol lda {
  mail_plugins = $mail_plugins sieve
}
Укажем настройки плагина в файле /etc/dovecot/conf.d/90-sieve.conf:
plugin {
  sieve = /home/vmail/%Ld/%n/active.sieve # Расположение активного скрипта
  sieve_dir = /home/vmail/%Ld/%n/sieve    # Каталог для скриптов
  sieve_max_script_size = 1M              # Максимальный размер одного скрипта
  sieve_quota_max_scripts = 50            # Максимальное количество скриптов
  sieve_quota_max_storage = 1M            # Максимальный общий объём скриптов
}
Каждый пользователь может обладать собственным набором Sieve-скриптов, из которых в любой момент времени активным может быть только один. Каталог для скриптов указывается в настройке sieve_dir, а в настройке sieve указывается имя символической ссылки, которая будет указывать на активный скрипт.

После настройки плагина нужно перезапустить Dovecot, чтобы изменения вступили в силу:
# /etc/init.d/dovecot restart
Подробнее о скриптах Sieve можно почитать на Википедии, в статье Sieve.

9. Настройка сервиса managesieve

Плагин sieve не был бы столь полезным, если бы Sieve-скриптами нельзя было бы управлять прямо из почтового клиента. Именно эту функцию и реализует сервис ManageSieve. Он ожидает подключений клиентов на отдельном TCP-порту 4190. Для управления скриптами клиент использует учётные данные своего почтового ящика.

Для включения сервиса достаточно лишь установить дополнительный пакет:
# apt-get install dovecot-managesieve
В следующих заметках фильтрация писем при помощи Sieve будет рассмотрена подробнее - я покажу, как им пользоваться в почтовых клиентах.

10. Результирующий файл конфигурации

Поскольку настроек очень много, проверить их можно при помощи следующей команды:
$ doveconf -n
Опция n предписывает показывать только те настройки, которые отличаются от настроек по умолчанию. У меня со всеми плагинами, настройка которых была тут описана, команда выдаёт следующий результат:
# 2.1.7: /etc/dovecot/dovecot.conf
# OS: Linux 3.2.0-4-amd64 x86_64 Debian 7.3 ext4
auth_default_realm = domain.tld
auth_mechanisms = plain login
dict {
  expire = mysql:/etc/dovecot/dovecot-dict-mysql.conf
  quota = mysql:/etc/dovecot/dovecot-dict-mysql.conf
}
disable_plaintext_auth = no
first_valid_gid = 120
first_valid_uid = 120
last_valid_gid = 120
last_valid_uid = 120
listen = *
log_timestamp = "%Y-%m-%d %H:%M:%S "
mail_gid = vmail
mail_home = /home/vmail/%Ld/%Ln
mail_location = maildir:/home/vmail/%Ld/%Ln
mail_plugins = quota acl expire
mail_uid = vmail
managesieve_notify_capability = mailto
managesieve_sieve_capability = fileinto reject envelope encoded-character vacation subaddress comparator-i;ascii-numeric relational regex imap4flags copy include variables body enotify environment mailbox date ihave
namespace {
  list = children
  location = maildir:%%h:INDEX=%h/shared/%%u
  prefix = shared/%%u/
  separator = /
  subscriptions = yes
  type = shared
}
namespace inbox {
  inbox = yes
  location = 
  mailbox Drafts {
    special_use = \Drafts
  }
  mailbox Junk {
    special_use = \Junk
  }
  mailbox Sent {
    special_use = \Sent
  }
  mailbox Trash {
    special_use = \Trash
  }
  prefix = 
  separator = /
  type = private
}
passdb {
  args = /etc/dovecot/dovecot-mysql.conf
  driver = sql
}
plugin {
  acl = vfile
  acl_shared_dict = file:/home/vmail/%Ld/shared-mailboxes.db
  expire = Trash 7
  expire2 = Trash/* 7
  expire3 = Spam 30
  expire_dict = proxy::expire
  quota = dict:User quota::proxy::quota
  quota_rule = *:
  sieve = /home/vmail/%Ld/%n/active.sieve
  sieve_dir = /home/vmail/%Ld/%n/sieve
  sieve_max_script_size = 1M
  sieve_quota_max_scripts = 50
  sieve_quota_max_storage = 1M
}
postmaster_address = postmaster@stupin.su
protocols = " imap sieve pop3"
service auth {
  unix_listener /var/spool/postfix/private/auth {
    group = postfix
    mode = 0600
    user = postfix
  }
}
service dict {
  unix_listener dict {
    group = vmail
    mode = 0600
    user = vmail
  }
}
ssl_cert = </etc/ssl/mail.stupin.su.public.pem
ssl_key = </etc/ssl/mail.stupin.su.private.pem
userdb {
  args = /etc/dovecot/dovecot-mysql.conf
  driver = sql
}
protocol lda {
  mail_plugins = quota acl expire sieve
}
protocol imap {
  mail_plugins = quota acl expire imap_quota imap_acl
}
Примечание от 27 марта 2013 года: Дополнил описание плагина acl.

На этом заметку, посвящённую настройке Dovecot, можно считать оконченой.

Cisco ASA traffic rate limiting (policing on interfaces)

Source

This configuration will not work as the rate limiting is not bidirectional and the other thing it should be configured on your inside interface but in your case you have rate limiting configured it on your outside  interface. If you want this to enable on your all the interface then apply service policy onto global . So that this way the policy map will be applied to all the interfaces.
To activate the policy map on one or more interfaces, enter the following command:
hostname(config)# service-policy policymap_name {global | interface interface_name}

Where global applies the policy map to all interfaces, and interface applies the policy to one interface. Only one global policy is allowed. Interface service policies take precedence over the global service policy for a given feature.
For example, if you have a global policy with inspections, and an interface policy with TCP normalization, then both inspections and TCP normalization are applied to the interface. However, if you have a global policy with inspections, and an interface policy with inspections, then only the interface policy inspections are applied to that interface.
With the new modular policy framework (MPF) introduced in ASA versions 7.x and 8.x, the firewall administrator is now able to apply policing and rate limiting to traffic passing through the ASA appliance. I got a few questions from people how this functionality works and decided to throw in a quick example below which you can easily modify accordingly to match your needs.
Scenario:
We want to rate limit a local internal host when accessing a specific external public server. The local host is 192.168.1.10 and the external public server is 100.100.100.1. We need to limit the traffic to 100kbps and burst size 8000.
Configuration Snippet:
ASA(config)#access-list rate-limit-acl extended permit ip host 192.168.1.10 host 100.100.100.1
ASA(config)#class-map rate-limit
ASA(config-cmap)#match access-list rate-limit-acl


ASA(config)#policy-map limit-policy
ASA(config-pmap)#class rate-limit
ASA(config-pmap-c)#police output 100000 8000

ASA(config)#service-policy limit-policy interface outside
For detail in this regard Kindly go through the following referencce page for all the configuration related information for Bandwidth Management(Rate Limit) Using QoS Policies
http://www.cisco.com/en/US/products/hw/vpndevc/ps2030/products_tech_note09186a008084de0c.shtml#rate
For configuring the rate limits through ASDM kindly go through the following link:
http://flylib.com/books.php?ln=en&n=2&p=464&c=186&p1=1&c1=1&c2=231&view=1
On Cisco ASA 8.x find th following:
http://www1.cisco.com/en/US/docs/security/asa/asa82/configuration/guide/conns_qos.html
http://www1.cisco.com/en/US/docs/security/asa/asa82/configuration/guide/conns_qos.html#wp1075478

Force Dovecot to recalculate mailbox quota

Source

Dovecot provides command line tool doveadm to recalcuate mailbox quota. Sample usage:
  • Recalculate one mailbox:
# doveadm quota recalc -u user@domain.ltd
  • Recalculate ALL mail accounts:
# doveadm quota recalc -A

MySQL: Cannot load from mysql.proc. The table is probably corrupted

Источник

Когда получаешь какую то ошибку от mysql, например, ту что указана в заголовке: "MySQL: Cannot load from mysql.proc. The table is probably corrupted", то немного пугаешься. Жутковато, однако ничего архи страшного в этом нет. Вы наверное только установили новую версию mysql, причем сами базы данных при этом находились на сервере. Такое случается, ну ничего страшного - все поправимо.

Прежде всего заходим в командную строку, например через Putty и делаем следующую команду:

mysql_upgrade -u root -p

После ввода у вас попросит ввести пароль для root пользователя. Вводите его, нажимаем Enter и дожидаемся выполнения операции.

Обращаю ваше внимание на то, что выполнение данной операции может затянуться, особенно, если у вас много Баз Данных и таблиц с данными. Однако другого выбора то нет. Ждем пока не напишет: "OK".

Рекомендуется всегда делать бекап всех баз данных перед тем как инсталлировать устанавливать новую версию Mysql, учтите это на будущее!

четверг, 21 апреля 2016 г.

How can an unauthenticated user access a windows share?

Summary of steps:
  • Adding Everyone, Guest and ANONYMOUS LOGON to the permissions of the share.
  • Open the Group Policy Editor (e.g. by running gpedit.msc)
    • Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options
    • Accounts: Guest account status: Enabled
    • Network access: Let Everyone permissions apply to anonymous users: Enabled
    • Network access: Restrict anonymous access to Named Pipes and Shares: Disabled
    • Network access: Shares that can be accessed anonymously: YOUR_SHARE_NAME
    • Network access: Sharing and security model for local account from “Classic-local users authenticate as themselves” to “Guest only-local users authenticate as Guest”.

понедельник, 4 апреля 2016 г.

Управление логгированием в systemd

Взял отсюда, благодарю автора.

Демон инициализации systemd де-факто уже стал стандартом в современных Linux-системах. На него перешли многие популярные дистрибутивы: Debian, RHEL/CentOS, Ubuntu (начиная с версии 15.04). В systemd используется принципиально иной (по сравнению с традиционным инструментом syslog) подход к логгированию.
В его основе лежит централизация: специализированный компонент journal cобирает все системные сообщения (сообщения ядра, различных служб и приложений). При этом специально настраивать отправку логов не нужно: приложения могут просто писать в stdout и stderr, a journal сохранит эти сообщения автоматически. Работа в таком режиме возможна и с Upstart, но он сохраняет все логи в отдельный файл, тогда как systemd сохраняет их в бинарной базе, что существенно упрощает  систематизацию и поиск.

Хранение логов в бинарных файлах также позволяет избежать сложностей с использованием парсеров для разных видов логов. При необходимости логи можно без проблем переконвертировать в другие форматы (более подробно об этом будет рассказано ниже).
Journal может работать как совместно с syslog, так и полностью заменить его.
Для просмотра логов используется утилита journalctl. Об особенностях и тонкостях работы с ней мы расскажем в этой статье.



Установка времени



Одним из существенных недостатков syslog является сохранение записей без учёта часового пояса. В journal этот недостаток устранён: для логгируемых событий можно указывать как местное время, так и универсальное координированное время (UTC). Установка времени осуществляется с помощью утилиты timedatectl.
Просмотреть список часовых поясов можно при помощи команды:

$ timedatectl list-timezones


Установка нужного часового пояса осуществляется так:

$ timedatectl set-timezone <часовой пояс>

По завершении установки будет нелишним убедиться в том, что всё сделано правильно:

$ timedatectl status
Local time: Thu 2015-07-30 11:24:15 MSK
Universal time: Thu 2015-07-30 08:24:15 UTC
RTC time: Thu 2015-07-30 08:24:15
Time zone: Europe/Moscow (MSK, +0300)
NTP enabled: no
NTP synchronized: no
RTC in local TZ: no
DST active: n/a


В самой первой строке (Local time) должны быть показаны точное текущее время и дата.

Journalctl: просмотр логов



Для просмотра логов используется утилита journalctl.
Если ввести команду journalсtl без каких-либо аргументов, на консоль будет выведен огромный список:

-- Logs begin at Wed 2015-07-29 17:12:48 MSK, end at Thu 2015-07-30 11:24:15 MSK. --
Jul 29 17:12:48 host-10-13-37-10 systemd-journal[181]: Runtime journal is using 4.0M (max allowed 20.0M, trying to leave 30.0M free of 195.9M available → current limit 20.0M).
Jul 29 17:12:48 host-10-13-37-10 systemd-journal[181]: Runtime journal is using 4.0M (max allowed 20.0M, trying to leave 30.0M free of 195.9M available → current limit 20.0M).
Jul 29 17:12:48 host-10-13-37-10 kernel: Initializing cgroup subsys cpuset
Jul 29 17:12:48 host-10-13-37-10 kernel: Initializing cgroup subsys cpu
Jul 29 17:12:48 host-10-13-37-10 kernel: Initializing cgroup subsys cpuacct
Jul 29 17:12:48 host-10-13-37-10 kernel: Linux version 3.16.0-4-amd64 (debian-kernel@lists.debian.org) (gcc version 4.8.4 (Debian 4.8.4-1) ) #1 SMP Debian 3.16.7-ckt11-1+deb8u2 (2015-07-17)
Jul 29 17:12:48 host-10-13-37-10 kernel: Command line: BOOT_IMAGE=/boot/vmlinuz-3.16.0-4-amd64 root=UUID=b67ea972-1877-4c5b-a328-29fc0d6c7bc4 ro console=tty1 console=ttyS0 video=640x480 consoleblank=0 panic=15 c


Здесь мы привели лишь небольшой его фрагмент; на самом деле он включает гигантское количество записей.

Фильтрация логов



У утилиты journalctl есть опции, с помощью которых можно осуществлять фильтрацию логов и быстро извлекать из них нужную информацию.

Просмотр логов с момента текущей загрузки



С помощью опции -b можно просмотреть все логи, собранные с момента последней загрузки системы:

$ journalctl -b


Просмотр логов предыдущих сессий



С помощью journalctl можно просматривать информацию о предыдущих сессиях работы в системе — в некоторых случаях это бывает полезным.
Следует, однако, учитывать, что сохранение информации о предыдущих сессиях поддерживается по умолчанию не во всех дистрибутивах Linux. Иногда его требуется активировать

Для этого нужно открыть конфигурационный файл journald.conf, найти в нём раздел [Journal] и изменить значение параметра storage на persistent:

$ sudo nano /etc/systemd/journald.conf
...
[Journal]
Storage=persistent


Просмотреть список предыдущих загрузок можно с помощью команды:

$ journalctl --list-boots

0 9346310348bc4edea250555dc046b30c Thu 2015-07-30 12:39:49 MSK—Thu 2015-07-30 12:39:59 MSK


Её вывод состоит из четырёх колонок. В первой из них указывается порядковый номер загрузки, во второй — её ID, в третьей — дата и время. Чтобы просмотреть лог для конкретной загрузки, можно использовать идентификаторы как из первой, так и из второй колонки:

$ journalctl -b 0


или

$ journalctl -b 9346310348bc4edea250555dc046b30c


Фильтрация по дате и времени



В journalctl имеется также возможность просмотра логов за определённые периоды времени. Для этого используются опции —since и —until. Предположим, нам нужно просмотреть логи начиная с 17 часов 15 минут 20 июля 2015 года. Для этого потребуется будет выполнить команду:
$ journalctl --since "2015-07-20 17:15:00"


Если с опцией since не будет указано никакой даты, на консоль будут выведены логи начиная с текущей даты. Если дата указана, но при этом не указано время, будет применено значение времени по умолчанию — «00:00:00». Секунды также указывать не обязательно (в этом случае применяется значение по умолчанию — 00).

Можно воспользоваться и вот такими человекопонятными конструкциями:

$ journalctl ---since yesterday
$ journalctl --since 09:00 --until now
$ journalctl --since 10:00 --until "1 hour ago"


Фильтрация по приложениям и службам



Для просмотра логов конкретного приложения или службы используется опция -u, например:

$ journalctl -u nginx.service


Приведённая команда выведет на консоль логи веб-сервера nginx.
Нередко возникает необходимость просмотреть логи какой-либо службы за определённый период времени. Это можно сделать при помощи команды вида:

$ journalctl -u nginx.service --since yesterday


C опцией -u также используется фильтрация по дате и времени, например:

$ journalctl -u nginx.service -u php-fpm.service —since today


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

Фильтрация по процессам, пользователям и группам



Просмотреть логи для какого-либо процесса можно, указав в команде journalctl его идентификационный номер (PID), например:
$ journalctl _PID=381


Для просмотра логов процессов, запущенных от имени определённого пользователя или группы, используются фильтры _UID и _GID соответственно. Предположим, у нас имеется веб-сервер, запущенный от имени пользователя www-data. Определим сначала ID этого пользователя:
$id -u www-data

33

Теперь можно просмотреть логи всех процессов, запущенных от имени этого пользователя:

$ journalctl _UID=33


Вывести на консоль список пользователей, о которых имеются записи в логах, можно так:

$ journalctl -F _UID


Для просмотра аналогичного списка пользовательских групп используется команда:

$ journalctl -F _GUID


С командной journalctl можно использовать и другие фильтры. Просмотреть список всех доступных фильтров можно, выполнив команду
$ man systemd.journal-fields


Фильтрация по пути



Просмотреть логи для какого-либо процесса также можно, указав путь к нему, например:

$ journalctl /usr/bin/docker


Иногда таким способом можно получить более подробную информацию (например, просмотреть записи для всех дочерних процессов).

Просмотр сообщений ядра



Для просмотра сообщений ядра используется опция -k или −−dmesg:

$ journalctl -k


Приведённая команда покажет все сообщения ядра для текущей загрузки. Чтобы просмотреть сообщения ядра для предыдущих сессий, нужно воспользоваться опцией -b и указать один из идентификаторов сессии (порядковый номер в списке или ID):

$ journalctl -k -b -2


Фильтрация сообщений по уровню ошибки



Во время диагностики и исправления неполадок в системе нередко требуется просмотреть логи и выяснить, есть ли в них сообщения о критических ошибках. Специально для этого в journalctl предусмотрена возможность фильтрации по уровню ошибки. Просмотреть сообщения обо всех ошибках, имевших место в системе, можно с помощью опции -p:

$ journalctl -p err -b


Приведённая команда покажет все сообщения об ошибках, имевших место в системе.

Эти сообщения можно фильтровать по уровню. В journal используется такая же классификация уровней ошибок, как и в syslog:

  • 0 — EMERG (система неработоспособна);
  • 1 — ALERT (требуется немедленное вмешательство);
  • 2 — CRIT (критическое состояние);
  • 3 — ERR (ошибка);
  • 4 — WARNING (предупреждение);
  • 5 — NOTICE (всё нормально, но следует обратить внимание);
  • 6 — INFO (информационное сообщение);
  • 7 —DEBUG (отложенная печать).


Коды уровней ошибок указываются после опции -p.

Запись логов в стандартный вывод



По умолчанию journalctl использует для вывода сообщений логов внешнюю утилиту less. В этом случае к ним невозможно применять стандартные утилиты для обработки текстовых данных (например, grep). Эта проблема легко решается: достаточно воспользоваться опцией −−no-pager, и все сообщения будут записываться в стандартный вывод:

$ journalctl --no-pager


После этого их можно будет передать другим утилитам для дальнейшей обработки или сохранить в текстовом файле.

Выбор формата вывода



C помощью опции -o можно преобразовывать данные логов в различные форматы, что облегчает их парсинг и дальнейшую обработку, например:

$ journalctl  -u nginx.service -o json

{ "__CURSOR" : "s=13a21661cf4948289c63075db6c25c00;i=116f1;b=81b58db8fd9046ab9f847ddb82a2fa2d;m=19f0daa;t=50e33c33587ae;x=e307daadb4858635", "__REALTIME_TIMESTAMP" : "1422990364739502", "__MONOTONIC_TIMESTAMP" : "27200938", "_BOOT_ID" : "81b58db8fd9046ab9f847ddb82a2fa2d", "PRIORITY" : "6", "_UID" : "0", "_GID" : "0", "_CAP_EFFECTIVE" : "3fffffffff", "_MACHINE_ID" : "752737531a9d1a9c1e3cb52a4ab967ee", "_HOSTNAME" : "desktop", "SYSLOG_FACILITY" : "3", "CODE_FILE" : "src/core/unit.c", "CODE_LINE" : "1402", "CODE_FUNCTION" : "unit_status_log_starting_stopping_reloading", "SYSLOG_IDENTIFIER" : "systemd", "MESSAGE_ID" : "7d4958e842da4a758f6c1cdc7b36dcc5", "_TRANSPORT" : "journal", "_PID" : "1", "_COMM" : "systemd", "_EXE" : "/usr/lib/systemd/systemd", "_CMDLINE" : "/usr/lib/systemd/systemd", "_SYSTEMD_CGROUP" : "/", "UNIT" : "nginx.service", "MESSAGE" : "Starting A high performance web server and a reverse proxy server...", "_SOURCE_REALTIME_TIMESTAMP" : "1422990364737973" }


Объект json можно представить в более структурированном и человекочитаемом виде, указав формат json-pretty или json-sse:

$ journalctl -u nginx.service -o json-pretty

{
    "__CURSOR" : "s=13a21661cf4948289c63075db6c25c00;i=116f1;b=81b58db8fd9046ab9f847ddb82a2fa2d;m=19f0daa;t=50e33c33587ae;x=e307daadb4858635",
    "__REALTIME_TIMESTAMP" : "1422990364739502",
    "__MONOTONIC_TIMESTAMP" : "27200938",
    "_BOOT_ID" : "81b58db8fd9046ab9f847ddb82a2fa2d",
    "PRIORITY" : "6",
    "_UID" : "0",
    "_GID" : "0",
    "_CAP_EFFECTIVE" : "3fffffffff",
    "_MACHINE_ID" : "752737531a9d1a9c1e3cb52a4ab967ee",
    "_HOSTNAME" : "desktop",
    "SYSLOG_FACILITY" : "3",
    "CODE_FILE" : "src/core/unit.c",
    "CODE_LINE" : "1402",
    "CODE_FUNCTION" : "unit_status_log_starting_stopping_reloading",
    "SYSLOG_IDENTIFIER" : "systemd",
    "MESSAGE_ID" : "7d4958e842da4a758f6c1cdc7b36dcc5",
    "_TRANSPORT" : "journal",
    "_PID" : "1",
    "_COMM" : "systemd",
    "_EXE" : "/usr/lib/systemd/systemd",
    "_CMDLINE" : "/usr/lib/systemd/systemd",
    "_SYSTEMD_CGROUP" : "/",
    "UNIT" : "nginx.service",
    "MESSAGE" : "Starting A high performance web server and a reverse proxy server...",
    "_SOURCE_REALTIME_TIMESTAMP" : "1422990364737973"
}


Помимо JSON данные логов могут быть преобразованы в следующие форматы:

  • cat — только сообщения из логов без служебных полей;
  • export — бинарный формат, подходит для экспорта или резервного копирования логов;
  • short — формат вывода syslog;
  • short-iso — формат вывода syslog с метками времени в формате ISO 8601;
  • short-monotonic — формат вывода syslog c метками монотонного времени (monotonic timestamp);
  • short-precise — формат вывода syslog с метками точного времени (время событий указывается с точностью до микросекунд);
  • verbose — максимально подробный формат представления данных (включает даже те поля, которые в других форматах не отображаются).


Просмотр информации о недавних событиях



Опция -n используется для просмотра информации о недавних событиях в системе:

$ journalctl -n


По умолчанию на консоль выводится информация о последних 10 событиях. С опцией -n можно указать необходимое число событий:

$ journalctl -n 20


Просмотр логов в режиме реального времени



Сообщения из логов можно просматривать не только в виде сохранённых файлов, но и в режиме реального времени. Для этого используется опция -f:

$ journalctl -f 


Управление логгированием



Определение текущего объёма логов



Со временем объём логов растёт, и они занимают всё больше места на жёстком диске. Узнать объём имеющихся на текущий момент логов можно с помощью команды:

$ journalctl --disk-usage
Journals take up 16.0M on disk.


Ротация логов



Настройка ротации логов осуществляется с помощью опций −−vacuum-size и −−vacuum-time.
Первая из них устанавливает предельно допустимый размер для хранимых на диске логов (в нашем примере — 1 ГБ):

$ sudo journalctl --vacuum-size=1G


Как только объём логов превысит указанную цифру, лишние файлы будут автоматические удалены.
Аналогичным образом работает опция −−vacuum-time. Она устанавливает для логов срок хранения, по истечении которого они будут автоматически удалены:

$ sudo journalctl --vacuum-time=1years


Настройка ротации логов в конфигурационном файле



Настройки ротации логов можно также прописать в конфигурационном файле /еtc/systemd/journald.conf, который включает в числе прочих следующие параметры:

  • SystemMaxUse= максимальный объём, который логи могут занимать на диске;
  • SystemKeepFree= объём свободного места, которое должно оставаться на диске после сохранения логов;
  • SystemMaxFileSize= объём файла лога, по достижении которого он должен быть удален с диска;
  • RuntimeMaxUse= максимальный объём, который логи могут занимать в файловой системе /run;
  • RuntimeKeepFree= объём свободного места, которое должно оставаться в файловой системе /run после сохранения логов;
  • RuntimeMaxFileSize= объём файла лога, по достижении которого он должен быть удален из файловой системы /run.


Централизованное хранение логов



Одной из самых распространённых задач в работе системного администратора является настройка сбора логов с нескольких машин с последующим помещением в централизованное хранилище.
В systemd предусмотрены специальные компоненты для решения этой задачи: systemd-journal-remote, systemd-journal-upload и systemd-journal-gatewayd.

С помощью команды systemd-journal-remote можно принимать логи с удалённых хостов и сохранять их (на каждом их этих хостов должен быть запущен демон systemd-journal-gatewayd), например:

$ systemd-journal-remote −−url https://some.host:19531/


В результате выполнения приведённой команды логи с хоста some.host будут сохранены в директории var/log/journal/some.host/remote-some~host.journal.

С помощью команды systemd-journal-remote можно также складывать имеющиеся на локальной машине логи в отдельную директорию, например:

$ journalctl -o export | systemd-journal-remote -o /tmp/dir -


Команда systemd-journal-upload используется для загрузки логов с локальной машины в удалённое хранилище:

$ systemd-journal-upload --url https://some.host:19531/


Как видно из приведённых примеров, «родные» утилиты systemd для поддержки централизованного логгирования просты и удобны в работе. Но они, к сожалению, пока что включены далеко не во все дистрибутивы, а только в Fedora и ArchLinux.

Пользователи других дистрибутивов пока что приходится передавать логи в syslog или rsyslog, которые затем пересылают их по сети. Ещё одно решение проблемы централизованного логгирования было предложено разработчиками утилиты journal2gelf, включённой в официальный репозиторий systemd: вывод journalсtl в формате JSON конвертируется в формат GELF, а затем передаётся приложению для сбора и анализа логов Graylog. Решение не очень удобное, но ничего лучше в текущей ситуации придумать нельзя. Остаётся только ждать, когда «родные» компоненты будут добавлены во все дистрибутивы.