Месяц: Май 2015

Управление сервисами CentOS 7 с systemd

Systemd приносит концепцию юнитов systemd. Юниты представлены конфигурационными файлами, размещенными в одной из директорий:

  • /usr/lib/systemd/system/ – юниты из установленных пакетов RPM.
  • /run/systemd/system/ — юниты, созданные в рантайме. Этот каталог приоритетнее каталога с установленными юнитами из пакетов.
  • /etc/systemd/system/ — юниты, созданные и управляемые системным администратором. Этот каталог приоритетнее каталога юнитов, созданных в рантайме.

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

Типы юнитов systemd:

  • .service – системный сервис
  • .target — группа юнитов systemd
  • .automount – точка автомонтирования файловой системы
  • .device – файл устройства, распознанного ядром
  • .mount – точка монтирования файловой системы
  • .path – файл или директория в файловой системе
  • .scope – процесс, созданный извне
  • .slice – группа иерархически организованных юнитов, управляющая системными процессами
  • .snapshot – сохраненное состояние менеджера systemd
  • .socket – сокет межпроцессного взаимодействия
  • .swap – Свап-устройство или свап-файл (файл подкачки)
  • .timer – таймер systemd

 

Основные функции systemd в CentOS 7

 

  • Активация, основанная на сокетах. Во время загрузки systemd прослушивает сокеты для всех системных сервисов, поддерживает этот тип активации и передает сокеты этим сервисам сразу после старта сервисов. Это позволяет systemd не только запускать сервисы параллельно, но также дает возможность перезапускать сервисы без потери любых отправленных им сообщений, пока сервисы были недоступны. Соответствующий сокет остается доступным и все сообщения выстраиваются в очередь.
  • Активация, основанная на D-Bus. Системные сервисы, использующие D–Bus для межпроцессного взаимодействия, могут быть запущены по требованию, когда клиентское приложение пытается связаться с ними.
  • Активация, основанная на девайсах. Системные сервисы, поддерживающие активацию, основанную на девайсах, могут быть запущены, когда определенный тип оборудования подключается или становится доступным.
  • Активация, основанная на путях. Системные сервисы могут поддерживать этот вид активации, если изменяется состояние папки или директории.
  • Снепшоты системных состояний. Система может сохранять состояние всех юнитов и восстанавливать предыдущее состояние системы.
  • Управление точками монтирования и автомонтирования. Systemd отслеживает и управляет точками монтирования и автомонтирования.
  • Агрессивная параллелизация Systemd запускает системные сервисы параллельно из-за использования активации, основанной на сокетах. В комбинации с сервисами, поддерживающими активацию по требованию, параллельная активация значительно уменьшает время загрузки системы.
  • Транзакционная логика активации юнитов. До активации и деактивации юнитов systemd вычисляет их зависимости, создает временную транзакцию и проверяет целостность этой транзакции. Если транзакция нецелостная, systemd автоматически пытается исправить ее и удалить не требующиеся задания из нее до формирования сообщения об ошибке.
  • Обратная совместимость с инициализацией SysV. SystemD полностью поддерживает скрипты инициализации SysV, как описано в спецификации Linux Standard Base (LSB), что упрощает переход на systemd.

 

Управление сервисами

В предыдущих версиях CentOS использовалась SysV или Upstart. Скрипты инициализации располагались в директории /etc/rc.d/init.d/. Такие скрипты обычно писались на Bash и позволяли администратору управлять состоянием сервисов и демонов. В CentOS 7 скрипты инициализации были заменены сервисными юнитами.

По способу использования сервисные юниты .service напоминают скрипты инициализации. Для просмотра, старта, остановки, перезагрузки, включения или выключения системных сервисов используется команда systemctl. Команды service и chkconfig по-прежнему включены в систему, но только по соображениям совместимости.


При использовании systemctl указывать расширение файла не обязательно.

Ниже представлены основные команды systemctl:

  • systemctl start name.service – запуск сервиса.
  • systemctl stop name.service — остановка сервиса
  • systemctl restart name.service — перезапуск сервиса
  • systemctl try-restart name.service — перезапуск сервиса только, если он запущен
  • systemctl reload name.service — перезагрузка конфигурации сервиса
  • systemctl status name.service — проверка, запущен ли сервис с детальным выводом состояния сервиса
  • systemctl is-active name.service — проверка, запущен ли сервис с простым ответом: active или inactive
  • systemctl list-units —type service —all – отображение статуса всех сервисов
  • systemctl enable name.service – активирует сервис (позволяет стартовать во время запуска системы)
  • systemctl disable name.service – деактивирует сервис
  • systemctl reenable name.service – деактивирует сервис и сразу активирует его
  • systemctl is–enabled name.service – проверяет, активирован ли сервис
  • systemctl list-unit-files —type service – отображает все сервисы и проверяет, какие из них активированы
  • systemctl mask name.service – заменяет файл сервиса симлинком на /dev/null, делая юнит недоступным для systemd
  • systemctl unmask name.service – возвращает файл сервиса, делая юнит доступным для systemd

 

Работаем с целями (targets) Systemd

Предыдущие версии CentOS с SysV init или Upstart включали предопределенный набор уровней запуска (runlevels), которые представляли специфичные режимы для операций, пронумерованные от 0 до 6. В CentOS 7 концепция уровней запуска была заменена целями systemd.

Файлы целей systemd .target предназначены для группировки вместе других юнитов systemd через цепочку зависимостей. Например юнитgraphical.target, использующийся для старта графической сессии, запускает системные сервисы GNOME Display Manager (gdm.service) и Accounts Service (accounts–daemon.service) и активирует multi–user.target. В свою очередь multi–user.target запускает другие системные сервисы, такие как Network Manager (NetworkManager.service) или D-Bus (dbus.service) и активирует другие целевые юниты basic.target.

В CentOS 7 присутствуют предопределенные цели, похожие на стандартный набор уровней запуска. По соображениям совместимости они также имеют алиасы на эти цели, которые напрямую отображаются в уровнях запуска SysV.

  • poweroff.target (runlevel0.target) – завершение работы и отключение системы
  • rescue.target (runlevel1.target) – настройка оболочки восстановления
  • multi–user.target (runlevel2.target, runlevel3.target, runlevel4.target) – настройка неграфической многопользовательской системы
  • graphical.target (runlevel5.target) – настройка графической многопользовательской системы
  • reboot.target (runlevel6.target) – выключение и перезагрузка системы

Команды runlevel и telinit по-прежнему доступны, но оставлены в системе по соображениям совместимости. Рекомендуется использовать systemctl для изменения или настройки системных целей.

Для определения, какой целевой юнит используется по умолчанию, полезна следующая команда: systemctl get–default.

Для просмотра всех загруженных целевых юнитов воспользуйтесь командой systemctl list-units —type target, а для просмотра вообще всех целевых юнитов командой: systemctl list-units —type target —all.

Для изменения цели по умолчанию поможет команда systemctl set-default name.target.

Для изменения текущей цели: systemctl isolate name.target. Команда запустит целевой юнит и все его зависимости и немедленно остановит все остальные.

Выключение и перезагрузка системы

В CentOS 7 systemctl заменяет значительное количество команд управления питанием. Прежние команды сохранены для совместимости, но рекомандуется использовать systemctl:
systemctl halt – останавливает систему
systemctl poweroff – выключает систему
systemctl reboot – перезагружает систему

Управление systemd на удаленной машине

Systemd позволяет управлять удаленной машиной по SSH. Для управления используйте команду:
systemctl —host user_name@host_name command, где user_name – имя пользователя, host_name – имя хоста, которым осуществляется удаленное управление, а command – выполняемая команда systemd.

Типичный systemd .service

Этот раздел поможет вам, если вам необходимо быстро сделать поддержку управления сервисом из systemd. Подробная информация о всех параметрах файла .service есть в соответствующем разделе документации по systemd.

[Unit]
Description=Daemon to detect crashing apps
After=syslog.target

[Service]
ExecStart=/usr/sbin/abrtd
Type=forking

[Install]
WantedBy=multi-user.target

Давайте посмотрим на секцию [Unit]. Она содержит общую информацию о сервисе. Такая секция есть не только в сервис-юнитах, но и в других юнитах (например при управлении устройствами, точками монтирования и т.д.). В нашем примере мы даем описание сервиса и указываем на то, что демон должен быть запущен после Syslog.

В следующей секции [Service] непосредственно содержится информация о нашем сервисе. Используемый параметр ExecStart указывает на исполняемый файл нашего сервиса. В Type мы указываем, как сервис уведомляет systemd об окончании запуска.

Финальная секция [Install] содержит информацию о цели, в которой сервис должен стартовать. В данном случае мы говорим, что сервис должен быть запущен, когда будет активирована цель multi–user.target.

Это минимальный работающий файл сервиса systemd. Написав свой, для тестирования скопируйте его в /etc/systemd/system/имя_сервиса.service. Выполните команды systemctl daemon-reload. Systemd узнает о сервисе и вы сможете его запустить.

UID of script is smaller than min_uid

Возникла проблема с сайтом. Начальная страница не грузилась, да собственно вообще никакие страницы.

Выводило ошибки в логе апача:

[Sun May 17 17:51:11 2015] [error] [client 192.168.252.43] SoftException in Application.cpp:355: UID of script «/home/user/public_html/index.php» is smaller than min_uid
[Sun May 17 17:51:11 2015] [error] [client 192.168.252.43] Premature end of script headers: index.php

 

Проблема в том, что права выставлены были не верно, да и файлы в папке принадлежали не пользователю,  а root.

Решение:

 

chown -R user:user /home/user
find /home/user -type f -exec chmod 644 {} \;
find /home/user -type d -exec chmod 755 {} \;

 

Использование Group Policy Prefernces для подключения сетевых дисков

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

Давайте рассмотрим простой сценарий. У нас есть группа студентов, которым нужен доступ к личным папкам на определенном сервере. Я поместил всех подобных студентов в группу безопасности Active Directory “Media”.

Далее создадим групповую политику и перейдем в раздел User Configuration > Preferences > Windows Settings > Drive Maps

mapped_drives_1

Нажмите правой кнопкой по Drive Maps и выберите New > Mapped Drive. В меню Action выберете Create, введите путь к серверу (например \\server\share ). Я создал папки на основе имен студентов, поэтому я использовал в данном примере переменную %username%.

mapped_drives_2

Затем перейдите в вкладку Common и выберите Item Level Targeting. В меню New Item выберите Security Group, убедитесь что выбран чекбокс User In Group и выберите нужную группу.

mapped_drives_3

На этом создание групповой политики завершено, теперь всем студентам, входящим в группу безопасности Media при входе в систему будет подключаться сетевой диск с именем Media Drive под литерой M.

 

Wireshark — как это работает?

Wireshark — это достаточно известный инструмент для захвата и анализа сетевого трафика, фактически стандарт как для образования, так и для траблшутинга.
Wireshark работает с подавляющим большинством известных протоколов, имеет понятный и логичный графический интерфейс на основе GTK+ и мощнейшую систему фильтров.
Кроссплатформенный, работает в таких ОС как Linux, Solaris, FreeBSD, NetBSD, OpenBSD, Mac OS X, и, естественно, Windows. Распространяется под лицензией GNU GPL v2. Доступен бесплатно на сайте wireshark.org.
Установка в системе Windows тривиальна — next, next, next.
Самая свежая на момент написания статьи версия – 1.10.3, она и будет участвовать в обзоре.

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

Начинаем

Для начала захвата достаточно выбрать свой сетевой интерфейс и нажать Start.

После чего и начнется процесс захвата, причем прилетевшие пакеты будут появляться в реальном времени.
В процессе рассмотрения и изучения пакетов бывают ситуации, когда нужно вернуться предыдущему пакету. Для этого есть две кнопки (см скриншот).

А следующая за ними кнопка позволяет сделать быстрый переход к пакету, указав его номер.
В случае если колонки перекрываются и наползают друг на друга, можно кликнуть по такой колонке правой кнопкой мыши и выбрать “Resize Column”.
Произойдет автоматическая подгонка размеров под текущую ситуацию.
И кроме того, есть кнопка “Resize all Columns”, которая приведет в порядок все колонки.
Используя меню View – Time Display Format, можно, например, настроить, чтобы отсчет времени шел не с начала захвата, а с момента получения предыдущего пакета (Since Previous Captured Packet).
Самое важное в каждой программе (Help – About Wireshark) покажет не только версию и список авторов, но и содержит закладку Folders, которая покажет пути размещения каталогов с конфигурациями.
Изучая интерфейс, можно выбрать, например, пакет http, и увидеть, что HTTP инкапсулируется в TCP (транспортный уровень), TCP инкапсулируется в IP (сетевой уровень), а IP в свою очередь инкапсулируется в Ethernet (перед этим даже мелькает 802.1Q).

И на самом верху идет нечто вроде небольшого обзора собранной информации о кадре.

Про фильтры мы поговорим дальше, а на данном этапе, если нужно быстро отфильтровать лишние пакеты, достаточно сделать правый клик на пакете, выбрать меню Apply as Filter – Not selected и изменения сразу же вступят в силу.
Если нужно еще что-то убрать, то в следующий раз выбирать “and not Selected”, и новое правило просто добавится к фильтру.

Убираем заусенцы

Довольно часто при работе с Wireshark возникает ошибка IP checksum offload – ошибка контрольной суммы заголовка IP пакета.

Современные сетевые карты насколько умные, что сами считают контрольную сумму, зачем это делать на уровне стека TCP/IP программно, если можно делать хардварно.
А Wireshark натурально перехватывает пакеты, до того как они попадают в сеть.
И до того как эта сумма была просчитана и была добавлена в заголовок пакета.
Соответственно есть два пути решения этой проблемы — выключать функцию offload в настройках сетевой карты или в настройках сниффера указать, чтобы он не обращал внимание на это значение.
Хардваные функции зачастую лучше софтварных, в основном из-за скорости обработки (в железе обычно выше) поэтому лучше изменить настройки самого сниффера.
Для этого нужно зайти в настройки (Edit — Preferences), затем Protocols – IPv4 – и снять флаг с “Validate IPv4 checksum if possible”.

Перед тем как захватывать трафик нужно определиться с тем, что, собственно, нужно захватывать.
Разместить анализатор трафика можно в нескольких местах:

  • Локально на своем хосте;
  • Организовать зеркалирование трафика на коммутаторе;
  • Подключаться непосредственно в интересующие места;
  • или же отравление протокола ARP (еще более незаконно, чем пассивное прослушивание трафика)

 

Фильтруем поток

Wireshark содержит два вида фильтров – захвата (Capture Filters) и отображения (Display Filters).
Вначале рассмотрим Capture Filters.
Как можно догадаться по названию, они служат для фильтрации еще на этапе захвата трафика.
Но в таком случае, безусловно, можно безвозвратно потерять часть нужного трафика.
Фильтр представляет собой выражение, состоящее из встроенных значений, которые при необходимости могут объединяться логическими функциями (and, or, not).
Для того, чтобы его задействовать, нужно зайти в меню Сapture, затем Options, и в поле Capture Filter набрать, например, host 8.8.8.8 (или, например, net 192.168.0.0./24)

Так же, конечно, можно выбрать и заранее созданный фильтр (за это отвечает кнопка Capture Filter).
В любом из вариантов фильтр появится возле интерфейса, можно жать Start.

Теперь перейдем к Display Filters.
Они фильтруют исключительно уже захваченный трафик.
Что можно фильтровать?
— Практически все — протоколы, адреса, специфические поля в протоколах.
Операции, которые можно использовать при построении фильтров:

Команда Значение Пример использования
== равенство ip.dst == 193.168.3.10
!= Не равно udp.dst != 53
< меньше чем ip.ttl < 24
> больше чем frame.len > 10
<= меньше или равно frame.len <= 0x20
>= больше или равно tcp.analysis.bytes_in_flight >= 1000
matches регулярные выражения frame matches «[Pp][Aa][Ss][Ss]»
contains содержит dns.resp.name contains google

Как вы, наверное, заметили, в таблице в качестве примеров были разнообразные выражения, достаточно понятные и зачастую говорящие сами за себя.
Например, ip.dst – это поле протокола IP.
Чтобы увидеть это поле, можно просто посмотреть на пакет, и в нижней части окна можно увидеть его значение, которое потом можно применять в любом фильтре.
Например, нас интересует, как создать фильтр, где будет проверяться значение TTL.
Для этого раскрываем L3 часть и становимся на соответствующее поле:

И видим, что для построения фильтра, нужно использовать выражение ip.ttl.
Если начать набирать фильтр, то после точки автоматически появится список возможных значений:

Чтобы применить фильтр, достаточно нажать enter или кнопку Apply.
Само поле для ввода фильтра может менять цвет в зависимости от того, что было набрано.
Зеленый цвет означает, что все в порядке. Красный — допущена ошибка, желтый — получен неожиданный результат, потому что существуют другие варианты написания фильтра (например можно написать ip.dst != 8.8.8.8 или же !ip.dst == 8.8.8.8, именно второй вариант более предпочтительный).
Фильтры можно сохранять для дальнейшего использования, нажав кнопку Save, затем ввести произвольное название

и после нажатия на кнопку ОК фильтр появится как кнопка на панели.

А если кликнуть на расположенную неподалеку кнопку «Expression…», то откроется достаточно мощный конструктор выражений, по которому можно чуть ли не изучать сетевые протоколы. Количество поддерживаемых протоколов постоянно увеличивается.

Как уже упоминалось ранее, можно выделить любой пакет и в контекстном меню выбрать Apply as Filter и в подменю выбрать режим — selected или not selected и соответственно сразу же появится фильтр, который будет показывать только выбранное или наоборот уберет выбранное с экрана.
Таким образом можно гибко выбирать, что видеть на экране, а что — нет.
Это может быть определенный ip-адрес, ttl, порт, dns ответ и многое другое.
Кроме того, есть два варианта для таких быстрых фильтров — Prepare as Filter и Apply as Filter.
Как можно догадаться по названию — разница заключается в том, что в первом случае только появится в поле для ввода Display Filter, но не применится (удобно, если например, добавлять таким способом несколько фильтров, а затем сразу применить готовый результат), а во втором — сразу же и применится.

Фильтры можно объединять, используя знакомые по булевой алгебре логические операции:
(dns) && (http) логическое и

(dns) || (http) это логическое или

Таким образом можно строить большие и сложные фильтры вроде:
(tcp.flags.syn==1) && (ip.src == 172.16.10.2) && (ip.dst == 172.16.10.1)
Здесь видим, что выбираются только TCP SYN сегменты, только с определенным адресом отправителя и получателя. При составлении больших фильтров нужно помнить, что фильтр по сути — логическое выражение, и если оно истинно, то пакет отобразится на экране, если ложно — нет.

Ныряем глубже

Достаточно частая ситуация, когда возникают жалобы на медленную работу сети, причин этого может быть множество.
Попробуем разобраться, в чем может быть причина, и рассмотрим два способа.
Первый состоит в добавлении колонки TCP delta.
Открываем пакет, находим поле Time since previous frame in this TCP frame, правый клик и выбираем Apply as Column. Появится новая колонка.
На ней можно кликнуть правой кнопкой мыши и выбрать режим сортировки, например, Sort Descending.

И сразу же рассмотрим второй способ.
Относительно недавно (в версии 1.10.0) появился фильтр tcp.time_delta, который, собственно, учитывает время с момента последнего запроса.

Если клиент делает запрос и получает ответ через 10 миллисекунд, и клиент говорит, что у него все медленно работает, то, возможно, проблема у самого клиента.
Если же клиент делает запрос и получает ответ через 2-3 секунды, тут уже, возможно, проблема кроется в сети.

Еще глубже

Если посмотреть в TCP пакет (или сегмент если быть точным), то можно увидеть там Stream index, который начинается обычно с нуля.
Само поле будет называться tcp.stream.

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

Таким образом можно фильтровать нужные соединения.

Еще один способ – сделать правый клик на самом пакете, выбрать Conversation Filter и создать фильтр для l2 l3 l4 уровня соответственно.

В итоге мы опять увидим взаимодействие двух хостов.

И третий вариант — это одна из самых интересных фич — Follow TCP Stream.
Для того чтобы его задействовать, нужно опять таки кликнуть правой кнопкой мыши на пакете и выбрать “Follow TCP Stream”. Появится окно, где будет наглядно продемонстрирован весь обмен между двумя узлами.

Если же зайти в меню Statistics – Conversations, то, выбирая закладки, можно увидеть статистику по таким “разговорам” и различные сессии, при этом можно отсортировать их по различным колонкам, например, по количеству переданных данных.

И прямо в этом окне можно правой кнопкой взывать контекстное меню и опять же применить как фильтр.

Со временем приходит опыт

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

Нажатие на эту кнопку приведет к открытию окна Expert Infos.
Того же результата можно добиться, пройдя в меню Analyze – Expert Info.

В этом окне будет содержаться информация по найденным пакетам, разбитая на группы Errors, Warnings, Notes и Chats.
Цветовая раскраска для этих групп выглядит следующим образом:
Ошибки — красный цвет
Предупреждения — желтый
Примечания — сине-зелёный (cyan)
Чат — серый

Wireshark содержит в себе мощный анализатор и умеет автоматически обнаруживать большое количество проблем, возникающих в сети.
Как вы уже могли заметить, буквально везде можно использовать фильтры и Expert Info не является исключением.
Для того чтобы создать такой фильтр, нужно использовать конструкцию expert.severity.
Например, expert.severity==error.

Грабим трафик!

Можно ли с помощью Wireshark узнать, что было скачано?
Да, можно. И сейчас это увидим.
Вначале возьмем HTTP трафик.
Сделаем правый клик по HTTP пакету — Protocol Preferences – и видим тут массу опций, которые непосредственно влияют на извлечение файлов из веб трафика.
Для того чтобы увидеть, что можно извлечь из текущего дампа нужно перейти в меню File – Export Objects – HTTP.
Появится окно, которое покажет все захваченные http объекты — текстовые файлы, картинки и т.д. Для того чтобы вытащить любой файл из этого списка, достаточно просто выделить его и нажать Save As.

Как можно заметить, рисунок был извлечен без каких-либо проблем.

Таким же способом, можно извлекать и потоковое видео/аудио.

Но на этом возможности Wireshark не заканчиваются!
Он умеет вытаскивать файлы и с протокола FTP.
Для этого можно использовать знакомый уже Follow TCP Stream.
В итоге отобразится только обмен по протоколу FTP, в котором нужно будет найти строку RETR, что собственно и будет означать передачу файла.

Затем опускаемся дальше, находим пакеты уже непосредственно с файлом (FTP-DATA) и опять выбираем Follow TCP Stream, видим содержимое файла, жмем Save As и сохраняем.

VoIP

Wireshark имеет несколько встроенных функций для работы с этой технологией.
Он поддерживает массу голосовых протоколов — SIP, SDP, RTSP, H.323, RTCP, SRTP и другие.
И, конечно же, умеет перехватывать и сохранять голосовой трафик для дальнейшего прослушивания.
Этот функционал как нельзя лучше подойдет для траблшутинга в сетях Voice over IP.
Меню Statistics — Flow Graph покажет наглядную картину, как происходил весь обмен пакетами.

А вообще целое меню Telephony отведено для работы с голосовым трафиком.
Например, Telephony – RTP – Show All Streams покажет подробно, что происходило с RTP, в частности jitter (параметр, который, вероятно, самый важный в голосе), что иногда сразу скажет о наличии проблем.

Нажав на кнопку “Analyze”, можно открыть окно RTP stream Analysis – и, выбрав там поток, можно его даже проиграть, используя кнопку player.
Сначала отроется окно проигрывателя, в котором вначале нужно установить подходящее значение jitter и использовать кнопку decode.

Появится нечто похожее на анализатор спектра, в котором можно отметить требуемый разговор, и после этого кнопка Play станет активной.

Так же существует еще один способ прослушивания голосовых звонков — можно зайти в меню Telephony – VoIP Calls.

Откроется окно со списком совершенных звонков, где опять же можно нажать кнопку player, отменить нужные разговоры флажками и нажать play.
Для того чтобы добиться приемлемого качества звучания, потребуется проиграться со значением поля jitter buffer, меняя его значение.

Небольшое отступление

Некоторое время назад появился сайт CloudShark.org.

Это тот самый сниффер Wireshark, но реализованный в виде онлайн-сервиса. Очевидно, что с его помощью не удастся захватывать сетевой трафик, но выполнять анализ дампа трафика – вполне. Загрузив туда через форму PCAP-файл на анализ, можно будет получить четкую последовательность пакетов, в которой всё данные будут разбиты на понятные поля в зависимости от протокола. В общем, тот же Wireshark, но немного облегченный и доступный из любого браузера.

Финальная битва

Напоследок рассмотрим как выглядит сканирование портов.
Смотрим на дамп и видим, что вначале происходит ARP запрос и затем непосредственно начинается сканирование. Адрес нашего маршрутизатора 192.168.10.11, сканирование идет с адреса 192.168.10.101

Это, так называемое, SYN сканирование, когда идут SYN-пакеты на указанный диапазон портов. Так как большинство портов закрыто, маршрутизатор отвечает пакетами RST, ACK.
Пролистав чуть ниже видим, что открыт telnet (tcp 23).

На это указывает то, что маршрутизатор ответил пакетом SYN, ACK.
К слову, для фильтрации портов в сниффере можно использовать конструкции вида: tcp.srcport, tcp.dstport и tcp.port. Для протокола UDP всё аналогично — udp.srcport, udp.dstport, udp.port.

Обзор популярных решений для быстрого развертывания почтового сервера

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

iRedMail

Название: iRedMail

Сайт проекта: iredmail.org

Лицензия: GNU GPL

Платформа: *nix

Добавление учетной записи в iRedMail

Почтовые серверы на *nix подкупают своей открытостью, производительностью и защищенностью, но для новичка развертывание с нуля и последующее сопровождение может превратиться в настоящий кошмар. Проект iRedMail ставит своей целью решить эту проблему. По сути, данная разработка представляет собой набор скриптов и готовых конфигов, упрощающих процесс развертывания и первоначальной настройки почтового сервера на базе Postfix/Dovecot с поддержкой протоколов SMTP, POP3 и IMAP. После запуска скрипт сам скачает и установит нужные пакеты, создаст первый виртуальный домен (задав минимум вопросов) с администратором и пользователем. Сам процесс развертывания занимает минут десять, после чего уже можно будет отправлять и получать почту. Читать документацию и копаться в настройках не придется, не потребуется и специфических знаний *nix. Учетные записи можно сохранять в OpenLDAP или MySQL, это выбирается на этапе установки. Далее можно создавать любое количество доменов, почтовых ящиков и алиасов, то есть ограничений никаких нет. Для защиты почты от вирусов и спама будут автоматически установлены SpamAssassin и ClamAV, а также инструменты, обеспечивающие поддержку технологий SPF (Sender Policy Framework), DKIM (DomainKeys Identified Mail), HPR (HELO Randomization Prevention), Spamtrap и белые, черные, серые списки. Для блокировки попыток перебора пароля ставится iptables Fail2ban. Проект предлагает свою разработку iRedAPD (Access Policy Delegation), позволяющую управлять политиками Postfix, делегируя полномочия между пользователями. Управление производится при помощи веб-интерфейса Roundcube WebMail, параллельно будут установлены средства управления сервисами phpLDAPadmin, PostfixAdmin, phpMyAdmin и анализатор логов AWStats для просмотра статистики. Доступен также локализованный интерфейс администратора собственной разработки — iRedAdmin, в двух версиях: бесплатной Open Source и коммерческой iRedAdmin-Pro. Первая позволяет управлять только учетными записями и доменами, вторая решает все вопросы по администрированию почтовой системы. Все компоненты ставятся на один «чистый» сервер; если уже есть работающий MySQL, к нему можно подключиться, только если выполнить необходимые настройки вручную (требует некоторого опыта).

Поддерживается установка на i386/x86_64 версии Red Hat Enterprise Linux, CentOS, Gentoo Linux, Debian, Ubuntu, openSUSE и Open/FreeBSD. На сайте проекта доступно несколько руководств, помогающих быстро сориентироваться.

IndiMail

Название: IndiMail

Сайт проекта: indimail.sf.net

Лицензия: GNU GPL

Платформа: *nix

Веб-интерфейс iWebAdmin построен на QmailAdmin

Платформа обмена сообщениями по протоколам SMTP, IMAP, POP3, поддерживающая QMQP, QMTP, DKIM и BATV (Bounce Address Tag Validation) и проверку почты на спам и вирусы. Базируется на нескольких Open Source решениях: Qmail, Courier IMAP/POP3, serialmail (доставка почты через коммутируемые соединения), qmailanalog (списки рассылки), dotforward, fastforward, mess822, daemontools, ucspi-tcp, Bogofilter, Fetchmail и других. Предоставляет набор инструментов для управления виртуальными доменами и учетными записями пользователей собственной разработки. Обеспечивает маршрутизацию для SMTP, IMAP и POP3, что позволяет разместить почтовый домен на нескольких серверах с обменом данными между ними или как прокси. Это очень удобно, если организация состоит из нескольких удаленных офисов. Используя утилиту hostcntrl, можно добавить на обслуживание отдельные адреса из других доменов. Это позволяет использовать IndiMail в гетерогенной среде без необходимости поднятия нескольких доменов или при переходе от проприетарного решения. Несколько серверов с синхронизацией данных позволяют легко наращивать структуру. Чтобы обеспечить лучшую масштабируемость и производительность, некоторые компоненты были изменены (в частности, Qmail). В IndiMail используется несколько так называемых коллекций (queue collection), каждая из которых выполняет свой процесс qmail-send/qmail-todo и может хранить данные на отдельном харде. Такая архитектура позволяет обрабатывать запросы быстрее, чем оригинальный Qmail.

Разработчики дают полную свободу в настройках, практически все параметры можно переопределить через переменные (а их всего около 200). Например, переменная CONTROLDIR указывает на каталог с конфигурационными файлами, QUEUEDIR — каталог с очередями. То есть можно запустить несколько копий IndiMail на одном сервере со своими настройками для каждой очереди, отправителя, получателя и узла. Но разбираться во всех переменных необязательно: чтобы запустить IndiMail, понадобится всего несколько правок. Новички могут управлять установками при помощи меню FLASH (построено на Ncurses). Для хранения данных о виртуальных пользователях используется MySQL, адресные книги могут храниться в OpenLDAP. Последние релизы полностью совместимы с systemd. Много внимания разработчики уделяют безопасности как самого сервера, так и сервисов — минимальное использование SETUID, четкое разделение между программами/адресами/файлами, пятиуровневый trust partitioning, автоматическое распознавание локальных IP, access-list, tcprules, фильтр контента, TLS/SSL и многое другое.

Установить IndiMail можно на любой 32/64 *nix платформе. Для загрузки доступны исходные тексты, пакеты и репозитории для некоторых популярных дистрибутивов Linux (RHEL/CentOS 5/6, Fedora, openSUSE/SLE, Mandriva, Debian и Ubuntu). Для управления сервером предлагается около 45 программ различного назначения (большинство расположено в /var/indimail/bin), учетные записи можно также настраивать при помощи веб-интерфейса iWebAdmin (построен на QmailAdmin), который необходимо устанавливать отдельно.

Rumble

Название: Rumble

Сайт проекта: rumble.sf.net

Лицензия: GNU GPL

Платформа: *nix, Win

Информация о сервере в веб-интерфейсе Rumble

Почтовый сервер, поддерживающий SMTP (ESMTPSA), POP3 и IMAP. Очень прост в управлении, для администрирования используется веб-интерфейс. Вполне подходит для небольших организаций с несколькими доменами. Написан на C/C++, для сценариев предлагается свой API (Lua и C/C++). Архитектура позволяет наращивать производительность сервера за счет кластеризации серверов для одного или всех доменов. Поддерживает SSL/TLS, SQLite и MySQL, аутентификацию (MD5/PLAIN/STARTTLS), для защиты от спама включены модули white/grey/blacklist, SpamAssassin, технологии BATV и VERP (Variable Envelope Return Path). В настройках предусмотрена возможность ограничить максимальный размер сообщения.

На сайте доступны исходные коды и x86/x64-бинарники для установки на Linux (Generic, Ubuntu, Debian). Чтобы запустить сервер, нужно распаковать архив и выполнить скрипт, все остальное программа сделает сама. Для удобства исходные тексты и конфигурационные файлы можно распределить по соответствующим каталогам и обеспечить автозагрузку при старте ОС. Параметры сервера и модули подключаются в файле rumble.conf. Для возможности регистрации через веб-интерфейс (порт 2580) следует удалить автоматически созданный файл modules/rumblelua/auth.cfg (в нем содержится пароль админа), после этого открываем веб-браузер и указываем новый пароль. Теперь можно управлять доменами, учетными записями и почтовыми ящиками, настройками сервера, просматривать логи и статистику.

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

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

Zentyal — почтовик из коробки

Новичкам, которых пугает само слово Linux и необходимость ввода команд в терминале, нужно простое решение, позволяющее быстро и без чтения документации развернуть почтовый сервис. Как вариант здесь можно посоветовать Zentyal — специализированный дистрибутив, построенный на базе Ubuntu Server (последний релиз основан на Ubuntu 12.04 LTS) и позволяющий выполнить все необходимые установки и настройки при помощи графического интерфейса. Zentyal — дистрибутив широкого назначения, который может использоваться и как роутер с функциями UTM, офисный сервер или сервер сообщений. Все необходимые функции реализуются при помощи устанавливаемых модулей/пакетов. В настоящее время доступно более тридцати модулей из пяти категорий, которые добавляются одним щелчком. Zentyal может устанавливаться в качестве самостоятельного сервера, используя свою базу пользователей, или работать в связке master/slave с возможностью репликации между несколькими серверами и синхронизации учетных данных с LDAP/AD.

Axigen

Название: Axigen

Сайт проекта: axigen.com/ru

Лицензия: GNU GPL

Платформа: Linux, FreeBSD, Solaris, Windows

Axigen: антиспам-настройки в веб-интерфейсе юзера

Многофункциональный, быстрый, защищенный почтовый сервер (SMTP/POP3/IMAP) с функциями совместной работы, календарем, списком задач и заметками, разрабатываемый румынской компанией Gecad Technologies. Работать с сообщениями пользователи могут через почтовый клиент или при помощи локализованного (и очень даже симпатичного) веб-интерфейса, построенного с применением технологии Ajax, — его можно полностью подогнать под себя. Поддерживаются горячие клавиши, что еще больше усиливает ощущение работы с обычным настольным приложением. В настройках доступны: сбор почты с внешних ящиков, автоответчик, фильтр почты, установка псевдонимов и другое. Пользователь также может экспортировать/импортировать контакты в файл формата CSV для переноса в другие приложения. Кроме стандартного, предлагается и упрощенный для мобильных устройств интерфейс, поддержка ActiveSync для синхронизации сообщений, контактов и календаря. В качестве дополнения устанавливается расширение для работы с общими папками.

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

Возможна интеграция с LDAP-сервером (в документации описан OpenLDAP и eDirectory) или Active Directory, для этого следует установить специальные схемы расширения. Реализованы модули резервирования и восстановления информации, списки рассылки, поддержка кластера и балансировки нагрузки, MAPI-интерфейс, РOP3- и IMAP-прокси. Сервер может обслуживать несколько доменов с различными настройками. В документации описано, как интегрировать IM-сервис, построенный на основе Jabber/XMPP. Кроме этого, Axigen имеет развитую систему отчетов с выводом всевозможных графиков, всего подготовлено около ста шаблонов. Для защиты информации может использоваться TLS/SSL, поддерживаются все популярные механизмы аутентификации: plain, login, cram-md5, digest-md5 и так далее. Возможна интеграция с пятнадцатью решениями для борьбы с вирусами (Kaspersky, DrWeb, Symantec, ClamAV и другие) и спамом (включая SpamAssassin). Поддерживаются технологии SPF, DKIM, черный/серый/белый списки и фильтрация по IP / стране отправителя. Все это подключается буквально одним щелчком мышки из интерфейса администратора. Возможен обмен данными между Axigen и MS Outlook, для этого необходимо установить коннектор.

Большим плюсом Axigen является возможность работы сервера на нескольких ОС. На странице закачки доступны пакеты для Debian, Red Hat Enterprise Linux и CentOS 5/6, SUSE Linux Enterprise 10/11, Fedora 12 и 13, OpenSUSE 11.2 и 11.3, FreeBSD 7.x/8.x, Solaris 10 x86/SPARC и Win2k3/2k8 (x86/x64). Также подготовлены Virtuozzo — контейнеры для быстрого развертывания в виртуальных средах. Установка очень проста и производится при помощи GUI-интерфейса, в котором предстоит выбрать сервисы, задать порты и указать сетевые интерфейсы для подключений пользователей и админов. При должной сноровке весь процесс займет не более 10–15 минут. На сайте проекта можно найти подробную документацию и несколько видеороликов, в которых показан процесс установки и администрирования. Кроме этого, доступны демоинтерфейсы пользователя и администратора. Версия Axigen Free Mail Server (Office Edition) предоставляется бесплатно и позволяет обслуживать до ста учетных записей e-mail и пять календарей.

CommuniGate Pro

Название: CommuniGate Pro

Сайт проекта: communigate.com

Лицензия: Free/платная

Платформа: *nix, Windows, Mac OS X

Веб-интерфейс администрирования CommuniGate Pro

Популярная платформа для обмена электронной почтой, IM, VoIP, с функциями календаря и автоматизацией совместной работы. Например, VoIP обеспечивает передачу голоса/видео и обеспечивает такие возможности, как конференции, автосекретарь (IVR), автоматическое распределение звонков, управление очередями вызовов, голосовая почта. При этом CommuniGate поддерживает установку на большое количество ОС и архитектур (всего около тридцати), IPv4 и IPv6, стандартные протоколы SMTP, SIP, IMAP, XMPP, LDAP, RADIUS, XIMSS, CalDAV, WebDAV, MAPI и другие. Пограничный контроллер сессий (Session Border Controller) обеспечивает корректную работу через NAT-устройства. Входящий в состав CGP LDAP-сервер может использоваться и другими приложениями. Возможна синхронизация данных с BlackBerry при помощи AirSync (лицензия на каждое устройство приобретается отдельно). Менеджер рассылок позволяет автоматизировать рассылку новостей с возможностью самостоятельной подписки пользователем. Рассылка создается администратором, в дальнейшем управляется одним из пользователей сервера.

Пользователи могут подключиться через любую программу-клиент, поддерживающую эти протоколы, или локализованный веб-интерфейс. Причем веб-интерфейс очень просто настроить таким образом, что он принимает вид обычного почтового клиента (чтобы юзвери меньше путались). Также возможно использование упрощенного интерфейса для экономии трафика при работе с PDA и доступ по протоколу WAP с мобильных телефонов. Вызвать пользователя для разговора через VoIP можно одним щелчком из веб-клиента или адресной книги. Администратор в настройках устанавливает доступные пользователю функции — сортировку и пересылку почты, автоответчик, загрузку писем с внешних POP3-ящиков, список контактов, задач и календарь.

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

Один сервер может обслуживать несколько доменов. Узлы кластера способны обрабатывать только определенный вид трафика (например, по региону), для распределения запросов используется технология SIP Farm. Решение легко масштабируется до любых размеров. К слову, на CommuniGate Pro построена сеть IP-телефонии оператора SIPNET.

Возможна аутентификация пользователя при помощи внутренней БД, Active Directory или внешней программы, в том числе поддерживаются сертификаты клиента. В настройках можно указать IP-адреса, с которых разрешено или запрещено подключение клиентов. Вся информация, хранящаяся на сервере и передаваемая между клиентом и сервером, может быть зашифрована с помощью технологий SSL, TLS, S/MIME и других.

Открытые API упрощают интеграцию с системами биллинга и управления. Поддержка плагинов позволяет подключать решения сторонних производителей для фильтрации спама и вирусов. В настоящее время поддерживается интеграция с решениями от Касперского, Sophos, McAfee, MailShell, Cloudmark.

Реализованы и стандартные средства защиты — проверка обратного адреса отправителя, поддержка DNSBL (RBL), запрет приема почты с определенных IP-адресов и сетей, проверка определенной строки в заголовке или теле письма. Установка в любой ОС несложна, по сути, нужно лишь распаковать архив и запустить сервер. Все настройки сервера, доменов и учетных записей производятся при помощи веб-интерфейса (работает на 8010-м порту, после запуска нужно подключиться к нему в течение десяти минут и задать пароль администратора). Система прав позволяет делегировать администрирование домена другим пользователям, указав только те функции, которые им действительно необходимы.

В настоящее время доступно несколько версий сервера, отличающихся лицензиями. Бесплатно предлагается Community Edition, в которой активно пять аккаунтов, за плату предлагаются Corporate Edition и Service Provider с дополнительными функциями.

WARNING

После первого запуска CommuniGate Pro необходимо в течение десяти минут подключиться к порту 8010 и задать пароль администратора.

Осваиваем систему заморозки процессов CRIU

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

Введение

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

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

Список коммитов CRIU в ядро

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

Тем не менее разработчикам из небезызвестной компании Parallels не так давно удалось добавить соответствующие функции в официальное ядро, и теперь мы имеем почти полноценный инструмент для заморозки процессов. Называется он CRIU и разрабатывается в составе системы виртуализации уровня ОС OpenVZ.

CRIU

История CRIU (Checkpoint/Restore In Userspace) началась в далеком 2005 году, когда компания Parallels взялась реализовать функцию заморозки/разморозки процессов на уровне ядра для проекта OpenVZ. Через несколько лет к работе подключились и другие компании, в результате чего было представлено более ста патчей для ядра, полностью реализующих нужную функциональность. Однако, чего и следовало ожидать, мантейнеры ядра отвергли патчи, как слишком комплексные, и Parallels не осталось другого выбора, как начать реализацию системы на уровне пользователя с небольшими изменениями в ядре в качестве вспомогательных функций.

В результате в 2011 году главный разработчик OpenVZ Павел Емельянов представил первую реализацию CRIU и соответствующий патчсет. На этот раз функциональность была почти полностью реализована на уровне пользователя, а в ядре содержался лишь минимальный набор функций, необходимых для получения более детальной информации о процессах, никак не ломающих внутреннюю согласованность структур ядра. Сообщество благосклонно приняло эту идею, и в январе 2012 года Линус Торвальдс интегрировал их в официальную ветку ядра, не забыв, правда, добавить ехидный комментарий Эндрю Мортона о сумасшедших русских и их сумасшедших идеях

Комментарий Эндрю Мортона

Это проект, разрабатываемый разными сумасшедшими русскими, по созданию/восстановлению контрольных точек в основном из пользовательского приложения, с различным странным вспомогательным кодом, добавленным в ядро там, где это необходимо. … Однако я не так, как разработчики, уверен в том, что все это когда-нибудь заработает! Поэтому я прошу их «обернуть» макросом CONFIG_CHECKPOINT_RESTORE каждый кусок нового кода в ядре. Так что если со временем все это закончится слезами и проект в целом развалится, мы сможем пройтись по коду и выкинуть все без следа.

Список опций crtools

Далее последовали и другие патчи, и к данному моменту в ядре уже появилось девять новых функций, так или иначе относящихся к заморозке процессов. Почти все из них реализованы с помощью экспорта необходимой информации через новые файлы каталога /proc/PID/, которые при запуске читает утилита crtools. Среди добавленной функциональности можно отметить следующее:

  • Каталог /proc/PID/map_files/. Содержит ссылки на все файлы, отображаемые приложением в виртуальную память, имя которых представляет собой адрес расположения файла в памяти. Для получения такой информации уже существовал файл /proc/PID/maps, однако новый каталог открывает большую гибкость, а также гарантирует, что замороженный процесс при восстановлении отобразит в память те же файлы, что и до заморозки.
  • Файл /proc/PID/task/TID/children, который содержит список всех потомков процесса. Эта информация необходима для заморозки дерева процесса либо всех потоков одного приложения.
  • Файл /proc/PID/stat теперь включает информацию об аргументах приложения, список переменных окружения и код возврата.
  • Системный вызов prctl() был расширен и теперь может быть использован для восстановления аргументов приложения и переменных окружения после разморозки. Это и предыдущее новшество позволяют полностью восстановить информацию о процессе так, что утилиты типа ps не покажут разницы.
  • Новый системный вызов kcmp(), который позволяет сравнить два процесса/потока и выявить разделяемые ими ресурсы.
  • Для получения информации, доступной только самому процессу посредством системных вызовов, таких как getitimer() и sigaction(), задействована функция внедрения так называемого паразитного кода, разработанная Tejun Heo. Эта функция позволяет поместить в адресное пространство процесса участок кода, что используется CRIU для сбора недостающей информации с помощью системных вызовов.
  • Добавлена новая sysctl-переменная kernel.nslastpid, которая позволяет явно указать, какой PID получит потомок процесса после следующего вызова clone(). Она нужна для того, чтобы после разморозки процесс получил свой прежний PID (изменившийся PID может вызвать очевидные проблемы, вроде различия PID, прописанного в файле /var/run/httpd.pid и реального).

Это только часть механизмов, добавленных в ядро для поддержки CRIU, но уже только они одни позволяют производить заморозку и восстановление многих приложений. Происходит этот процесс примерно так. При запуске процедуры заморозки crtools останавливает процесс с помощью системного вызова ptrace() (PTRACE_SEIZE), затем собирает информацию обо всех открытых им файлах, сокетах, потомках и прочем с помощью чтения файлов каталога /proc/PID/, системного вызова prctl() и вставки паразитного кода. Затем происходит сохранение образа памяти процесса, а также значений всех его регистров (опять же с помощью ptrace) и, наконец, остановка процесса.

После того как будет инициирован процесс разморозки, утилита crtools восстанавливает память процесса, устанавливает нужное значение PID в kernel.nslastpid, форкается, открывает все необходимые ресурсы и запускает исполнение с помощью системного вызова sigreturn(), возвращающего управление процессу именно в ту точку, в которой он был до заморозки. Таким образом удается заморозить и восстановить не только один процесс/поток, но и всех его потомков.

Более того, CRIU, как система, разрабатываемая в расчете на применение в системах виртуализации, позволяет не только полностью восстановить процесс, но и даже не потерять при этом сетевые соединения. Для этого в ядре была реализована система TCP repair mode, которая позволяет в прямом смысле разобрать и заново собрать сокет, никак при этом не взаимодействуя с другой стороной соединения. Эта функциональность, в частности, позволяет заморозить, например, Apache, затем перенести его образ на другую машину, разморозить, и он продолжит работать как ни в чем не бывало, не потеряв соединение даже с уже подключенными клиентами (если, конечно, клиент не успеет сам разорвать соединение из-за истечения времени ожидания).

Кроме этого, CRIU также поддерживает приложения, использующие такие функции, как inotify и epoll, а также другую функциональность ядра, однако эти пачти еще не включены в официальную ветку.

Процесс сохранения состояния процесса

Ядро и утилита

Как я сказал выше, все нужное для работы CRIU уже есть в ванильном ядре версии 3.7. Однако многие дистрибутивостроители используют ядра с выключенной функцией чекпоинтинга, а это значит, что ядро придется пересобирать самостоятельно с нужными опциями. Как это делать, было описано уже миллиарды раз, поэтому ограничусь лишь списком опций, которые должны быть включены при сборке:

Опции ядра, необходимые CRIU

General setup -> Checkpoint/restore support (CONFIG_CHECKPOINT_RESTORE)
General setup -> open by fhandle syscalls (CONFIG_FHANDLE)
General setup -> Enable eventfd() system call (CONFIG_EVENTFD)
General setup -> Enable eventpoll support (CONFIG_EPOLL)
File systems -> Inotify support for userspace (CONFIG_INOTIFY_USER)
Executable file formats -> Emulations -> IA32 Emulation (CONFIG_IA32_EMULATION)
Networking support -> Networking options -> Unix domain sockets -> UNIX: socket monitoring interface (CONFIG_UNIX_DIAG)
Networking support -> Networking options -> TCP/IP networking -> INET: socket monitoring interface (CONFIG_INET_DIAG)
Networking support -> Networking options -> Packet socket -> Packet: sockets monitoring interface (CONFIG_PACKET_DIAG)

Собственно, почти все эти опции являются стандартными, и обычно выключенной оказывается только первая из них (становится доступна после включения опции Configure standard kernel features (expert users)). Чтобы проверить, так ли это, можно воспользоваться следующей командой:

$ zcat /proc/config.gz | grep CONFIG_CHECKPOINT_RESTORE
CONFIG_CHECKPOINT_RESTORE is not set

В данном случае по выводу команды можно заметить, что опция не включена, поэтому ядро придется пересобирать. Сразу скажу, что в данный момент CRIU работает только на системах x86_64, поэтому если ты юзаешь i386-сборку дистрибутива, то ничего не получится.

Та самая опция

Теперь, когда есть ядро с поддержкой CRIU, нам понадобится утилита crtools, которая как раз и занимается заморозкой/разморозкой процессов. В дистрибутивах ее тоже нет, поэтому придется опять же собрать из исходников (вместе с пакетом protobuf-c, позволяющим работать с форматом Google’s Protocol Buffers, в котором crtools сохраняет состояние сетевых соединений):

$ cd /tmp
$ wget http://bit.ly/KGCeEq
$ tar -xzf protobuf-c-0.15.tar.gz
$ cd protobuf-c-0.15
$ ./configure --prefix=/usr && make
$ sudo make install
$ cd /tmp
$ wget http://bit.ly/WjDLlc
$ tar -xjf crtools-0.3.tar.bz2
$ cd crtools-0.3
$ make
$ cp crtools ~/bin
$ export PATH=~/bin:$PATH

Для корректной работы crtools также необходим пакет iproute2 версии не ниже 2.6.0. Его можно установить стандартными средствами дистрибутива. После установки можно проверить работоспособность crtools, запустив следующую команду:

$ sudo crtools check

Если сообщений об ошибке на экран выведено не будет, значит, все ОK.

Криокамера

Как же теперь заморозить процесс? Очень просто, будет достаточно следующей команды:

$ sudo crtools -D каталог dump -t PID-процесса

Каталог следует создать заранее, после выполнения команды он заполнится файлами с расширением img, в которых будет сохранена вся информация о процессе. Для восстановления достаточно выполнить обратную команду:

$ sudo crtools -D каталог restore -t PID-процесса

И процесс вновь появится в системе, причем, если это консольное приложение, оно будет запущено в том же окне терминала. Разработчики говорят, что таким образом можно замораживать make и GCC, tar, bz2, sendmail, Apache, MySQL, SSH, crond, VNC-сервер, nginx и многие другие приложения. Лично мне удалось без всяких проблем выполнить заморозку mc, mocp, Vim, однако в случае с графическими приложениями положиться на софт получится не всегда, например, Google Chrome мне восстановить так и не удалось.

Стоит заметить, что crtools сохраняет все дерево процессов, воспринимая переданный ему PID как родительский. Эту особенность можно использовать не только для многонитевых приложений, но и, например, для сохранения контейнеров LXC и OpenVZ. Разработчики рекомендуют использовать для этого следующую команду:

$ sudo crtools dump --tcp-established -n net -n mnt -n ipc -n pid --action-script "net-script.sh" -D dump/ -o dump.log -t init-PID

В данном случае аргумент –tcp-established заставляет crtools сохранить также и состояния сетевых соединений, чтобы их можно было восстановить после разморозки. Опции -n net -n mnt -n ipc -n pid позволяют корректно сохранить информацию о пространствах имен сети, точках монтирования, IPC и процессов. Здесь они необходимы, так как контейнеры выполняются в изолированных пространствах имен, и без них процессы удастся восстановить только в корневую систему. С помощью опции –action-script “net-script.sh” мы указываем команде исполнить скрипт net-script.sh перед заморозкой. Он заблокирует любые сетевые коммуникации на время заморозки. Этот скрипт ты найдешь на прилагаемом к журналу диске. Опция -o dump.log сохраняет лог заморозки в файл dump.log. В конце мы указываем PID процесса init внутри виртуального окружения.

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

$ sudo crtools restore --tcp-established -n net -n mnt -n ipc -n pid --action-script "net-script.sh" --veth-pair eth0=интерфейс --root каталог-контейнера -D data/ -o restore.log -t init-PID

В этот раз задействованы две дополнительные опции. Это «–veth-pair eth0=интерфейс», в которой следует указать имя виртуального veth-интерфейса на стороне хост-системы, а также «–root каталог-контейнера» для указания корневого каталога контейнера. Таким образом можно без каких-либо проблем сохранить контейнер на одной машине, затем перекинуть его дамп на другую и восстановить его на ней.

Еще одно неожиданное применение crtools — это возможность внедрять паразитный код в работающие приложения, заставляя их исполнять указанные нами системные вызовы. Среди применений этой технологии разработчики приводят в пример возможность переопределить стандартный поток ввода-вывода:

$ sudo crtools exec -t PID close 1
$ sudo crtools exec -t PID open '&путь-до-файла' 2

Впрочем, ту же операцию можно проделать и с помощью отладчика GDB.

Содержимое каталога состояния процесса

Продакшн?

Несмотря на молодость и недоработанность проекта, CRIU уже используется в последней версии облачной платформы Parallels Cloud Server. Кроме самого CRIU, в ней также задействованы такие технологии, как kexec и pramfs. Используемые совместно, они способны на порядок сократить время простоя сервера при обновлении в сравнении с классической холодной перезагрузкой.

Работает это примерно так. Сначала состояние виртуальных серверов сохраняется с помощью CRIU в виртуальную ФС pramfs (представляет собой аналог tmpfs, главная особенность — ее состояние сохраняется между перезагрузкой ядра через kexec), далее новое ядро загружается с помощью kexec, и состояние контейнеров восстанавливается из pramfs.

Ключевое значение здесь имеют CRIU и pramfs, потому что, со слов разработчиков, сам дамп состояния происходит очень быстро и обычно все упирается в производительность диска, тогда как в pramfs сохранение происходит со скоростью работы оперативной памяти, что дает заметный выигрыш в скорости дампа и восстановления.

WWW

  • Детальный обзор механизма TCP repair mode: lwn.net/Articles/495304;
  • список ядерных коммитов CRIU, включенных и еще не включенных в ядро.

WARNING

В данный момент CRIU работает только на системах x86_64.

Выводы

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

Удаленный контроль

Управляем удаленной машиной с помощью Google Talk, Twitter, Dropbox и Google+

Сегодня социальные сервисы окружают нас со всех сторон. Мы чатимся в Jabber, читаем новости в Twitter, выкладываем фотки в Google+. Мы делаем это с домашних компов, смартфонов и планшетов ежедневно в почти автоматическом режиме. Для многих из нас Twitter или Facebook давно стал заменой электронной почты и IRC-чатов. Так почему бы не использовать те же сервисы для мониторинга удаленной машины и даже управления ей?

Постановка задачи

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

  • Мониторинг удаленной машины средствами Twitter. Мы создадим специального твиттер-юзера, от лица которого наш сервер/медиацентр/ПК будет слать сообщения о своем состоянии, мы сможем читать их через веб или с помощью твиттер-клиента.
  • Управление через Jabber. Мы сделаем Jabber-бот, который будет выступать посредником между нами и консолью удаленной машины. Все написанные ему сообщения будут интерпретироваться как консольные команды, ответ на которые будет выслан в ответном сообщении.
  • Управление через Dropbox. Мы создадим простой демон, который будет выполнять команды по мере их появления в указанном файле внутри диска Dropbox.
  • Камеру слежения с отчетом в Google+. Мы сделаем простой бот, который будет выкладывать в Google+ фотографии, сделанные веб-камерой. Так мы сможем следить за чем угодно удаленно без необходимости организовывать специальный сервис.
  • Видео по запросу. Мы сделаем бот, который будет по нашему запросу снимать видео определенной длительности, а затем выкладывать его в наш приватный канал YouTube.

Все это делается Just for fun, поэтому я заранее соглашусь с теми, кто скажет, что подобные вещи нужно делать с помощью SSH и специальных веб-панелей управления. В то же время хочу заметить, что некоторые из приведенных приемов могут быть удобнее классических подходов. Но обо всем, как обычно, по порядку.

Twitter и отчеты о состоянии

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

Как это сделать? Для этого понадобятся: новый аккаунт в Твиттере, консольный твиттер-клиент и простой скрипт, который будет генерировать нужные нам сводки информации. С первым все просто. Регистрируем новый e-mail, создаем аккаунт, делаем его приватным и добавляем свой основной аккаунт в список подписчиков. Таким образом доступ к информации о состоянии сервера сможешь получить только ты.

Далее нам понадобится клиент, с помощью которого мы будем отправлять отчеты. Популярный TTYtter справится с этой задачей на отлично. Устанавливаем:

$ sudo apt-get install ttytter

Запускаем клиент, видим сообщение, что необходимо получить OAuth-токен, соглашаемся нажатием . Видим на экране ссылку, открываем ее в браузере и нажимаем кнопку «Авторизовать». На экране появится PIN-код, который следует скопировать и ввести в ответ на приглашение TTYtter. Теперь можно отправить тестовый твит вот так:

$ echo "Привет из консоли!" | ttytter -script

А еще лучше так:

$ free | grep Mem | ttytter -script

Другими словами, теперь мы можем отправить вывод абсолютно любой команды на нашу страницу в твиттере, просто перенаправив ее вывод в TTYtter. Написав же небольшой скрипт и прописав его в расписание cron, мы можем сделать так, чтобы машина отправляла любую указанную информацию через определенные промежутки времени. Для примера возьмем следующий скрипт (фактически это сильно урезанная и доработанная версия скрипта, опубликованного в блоге fak3r.com):

$ vi ~/bin/twitter-monitor.sh #!/bin/bash # Формируем твит # Имя хоста HOST=`hostname -s` # Аптайм машины UP=`uptime | cut -d" " -f4,5 | cut -d"," -f1` # Средняя нагрузка LOAD=`uptime | cut -d":" -f5,6` # Скорость пинга PING=`ping -q -c 3 google.com | tail -n1 | cut -d"/" -f5 | cut -d"." -f1` # Количество занятой памяти MEM=`ps aux | awk '{ sum += $4 }; END { print sum }'` # Нагрузка на процессор CPU=`ps aux | awk '{ sum += $3 }; END { print sum }'` # Собираем инфу вместе TWEET="(HOST) ${HOST} (UP) ${UP} (CPU) ${CPU}% (MEM) ${MEM}% (LOAD) ${LOAD} (PING) ${PING}ms" # Отправляем твит echo $TWEET | ttytter -script

Он собирает такую информацию, как имя хоста, аптайм, пинг до гугла, количество памяти, нагрузка на процессор, и отправляет все это одним твитом. Скрипт больше подходит для мониторинга сервера, но ты можешь изменять его как вздумается, главное — проверить, чтобы в итоге вся инфа умещалась в 140 символов, что можно сделать, заменив последнюю команду скрипта на «echo $TWEET | wc -c» и запустив его.

Теперь осталось лишь добавить скрипт в crontab, чтобы он запускался, например, каждый час:

$ crontab -e 0 * * * * /путь/до/скрипта.sh

Сделать это необходимо от имени того пользователя, от которого ты получил токен для TTYtter.

Ответ от сервера
Ответ от сервера

Управление через Twitter

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

Последнее приватное сообщение с помощью TTYtter можно получить так:

$ echo "/dma +1" | ttytter -script [DM da0][ezobnin/Tue Mar 26 09:59:59 +0000 2013] test test

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

$ vi ~/bin/twitter-command.sh #!/bin/sh while true; do CMD=`echo "/dma +1" | ttytter -script | sed 's/[.*] //'` sh $CMD sleep 60 done

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

$ vi ~/bin/twitter-command.sh #!/usr/bin/bash # Имя твиттер-юзера для ответов USER="user" while true; do # Получаем личное сообщение (команду) CMD=`echo "/dma +1" | ttytter -script | sed 's/[.*] //' # Проверяем, выполняли ли такую команду в прошлый раз if [ $CMD != $OLD_CMD ]; then # Если нет — выполняем REPL=`$CMD` # и отправляем ответ команды юзеру echo "/dm $USER ${REPL:0:140}" | ttytter -script # Сохраняем команду, чтобы не выполнять ее снова CMD = $OLD_CMD fi # Спим минуту sleep 60 done

Этот скрипт ведет себя гораздо умнее. Он отправляет результат выполнения команды юзеру, автоматически сокращая его до 140 символов, и запоминает последнюю выполненную команду, чтобы не запускать ее снова. С другой стороны, при запуске скрипт все равно выполнит последнюю отправленную ему команду, но я не думаю, что в этом есть большая проблема.

Скрипт управления через Твиттер
Скрипт управления через Твиттер
TTYtter в интерактивном режиме
TTYtter в интерактивном режиме

Управление через Jabber/GTalk

Twitter может быть отличным инструментом для мониторинга машины, но использовать его для того, чтобы отдавать удаленные команды, довольно неудобно. Гораздо лучше для этого подходит Jabber, который изначально был придуман для ведения текстового диалога между двумя сторонами.

В Linux есть несколько инструментов, позволяющих отсылать и принимать Jabber-сообщения из консоли (например, CJC: cjc.jajcus.net), но для реализации нашей задачи гораздо лучше подойдет Ruby-библиотека xmpp4r-simple, позволяющая реализовать Jabber-клиент, написав буквально три строки. Библиотека есть в репозитории Ruby Gems, поэтому для ее установки, например, в Ubuntu следует набирать такие команды:

$ sudo apt-get install ruby $ sudo apt-get install rubygems $ gem install xmpp4r-simple $ gem install session

Чтобы убедиться в ее работоспособности, можно использовать такой скрипт:

$ vi send-message.rb #!/usr/bin/env ruby require 'rubygems' require 'xmpp4r-simple' jabber = Jabber::Simple.new('юзер@gmail.com', 'пароль') jabber.deliver("адресат@gmail.com", "Привет, Gmail!")

Для решения нашей задачи такой скрипт бесполезен, но, дописав в него каких-то десять строк, мы реализуем полноценный бот:

$ vi jabber-bot.rb #!/usr/bin/env ruby require 'rubygems' require 'xmpp4r-simple' require 'session' # Запускаем сеанс sh, в котором будет происходить выполнение команд @sh = Session::new # Коннектимся к Jabber-серверу bot = Jabber::Simple.new(логин@gmail.com, пароль) while true # Ожидаем сообщение bot.received_messages do |msg| # Проверяем, что сообщение пришло от юзер@gmail.com if msg && msg.from.to_s.include?(юзер@gmail.com) # Выполняем команды в сеансе sh stdout, stderr = @sh.execute(msg.body) if msg.body # Отправляем в ответном сообщении вывод команды bot.deliver(msg.from, "n" + stdout.chomp) unless stdout.empty? # Отправляем поток ошибок bot.deliver(msg.from, "n" + stderr.chomp) unless stderr.empty? end end

Приведенный бот прост, но отлично справляется со своей работой. Все, что нужно сделать, — это завести юзера для бота, прописать его логин и пароль, а также адрес своего основного Jabber-аккаунта в скрипт, затем запустить скрипт и написать на адрес бота нужную команду. Результат запуска придет в ответном сообщении. Это действительно удобно, особенно когда нет возможности или времени выполнять полноценный логин по SSH (например, с телефона).

Для тех, кто говорит, что это жутко небезопасно, скажу, что бот будет выполнять только команды, пришедшие с указанного адреса, а так как в протоколе XMPP за проверку обратного адреса отвечает сам XMPP-сервер, то спуфинг адреса с целью захвата управления будет возможен только в случае захвата самого сервера. Проблемой остается то, что шифрование на уровне протокола отсутствует, но при использовании VPN риски сведутся к минимуму.

Управление с помощью Dropbox

Ты можешь удивиться, но рулить машиной можно даже с помощью Dropbox. По сути, это такой же грязный хак, не претендующий на роль нормального решения, но даже он может быть полезен в определенных ситуациях. В основе его работы лежит идея записи команд в файл. Клиент создает текстовый файл внутри каталога Dropbox и помещает в него строку, содержащую команду. На стороне сервера работает скрипт, который в цикле проверяет существование файла и, если такой существует, выполняет содержащуюся в нем команду и записывает ответ в другой файл. Серверный скрипт выглядит следующим образом:

$ vi ~/Dropbox/server.sh #!/bin/bash # Входим в бесконечный цикл while true; do # Файл существует? if [ -f  input.txt ]; then # Читаем файл, выполняем команду и записываем ответ в другой файл OUTCOM=$(cat input.txt) $OUTCOM > output.txt # Удаляем входной файл rm input.txt > /dev/null 2>&1 else # Если файла нет, уходим в сон sleep 10 fi done

После запуска скрипта любой, кто подключит тот же том Dropbox (зайдет с того же аккаунта), сможет выполнить команду на сервере, просто записав ее в файл input.txt. Так, например, можно управлять серверной машиной через веб-интерфейс, со смартфона или любого устройства, на котором есть клиент Dropbox. Для удобства управления с другой Linux-машины можно использовать такой скрипт:

$ vi ~/Dropbox/client.sh #!/bin/bash # Создаем входной и выходной файлы touch input.txt touch output.txt # Читаем команду echo -n "Enter Command: " read INCOM # Записываем команду в файл и ждем, пока клиент ее не прочитает, сигналом о чем для нас станет удаление файла echo "$INCOM" > input.txt while [ -f input.txt ];do sleep 10 done # Выводим на экран ответ сервера cat output.txt

При запуске скрипт выводит приглашение к вводу команды, после чего записывает ее в файл и ждет ответа. Все просто, к тому же такой способ коммуникации довольно безопасен. Никто не знает точно, могут ли сотрудники Dropbox на самом деле читать наши данные, но соединение между клиентом и сервером всегда зашифровано, что защищает от перехвата данных. А это, на мой взгляд, гораздо важнее.

Автозагрузка фото с камеры в Picasa/Google+

Аккаунт Google сегодня есть у всех, а значит, есть доступ к Google+, Picasa и куче других полезных и не очень сервисов. Большинство из них можно заскриптовать с помощью утилиты командной строки GoogleCL, которая позволяет работать с такими сервисами, как Picasa, Календарь, Blogger, Контакты, Документы и YouTube прямо из командной строки. С помощью этого инструмента можно делать множество интересных вещей, однако я покажу только два его применения: автоматическая публикация фоток с веб-камеры в альбом Picasa (Google+) и снятие видео с той же камеры и публикация в YouTube по запросу.

Чтобы реализовать такое, понадобится сам GoogleCL, который есть в любом дистрибутиве, а также в репозитории Python:

$ sudo apt-get install googlecl $ sudo pip install googlecl

Далее мы должны создать новый альбом в Picasa, куда будут автоматически загружаться фотографии с веб-камеры:

$ google picasa create WebCamera

При первом обращении к сервису Picasa автоматически откроется страница в веб-браузере, в которой следует нажать кнопку «Разрешить», чтобы предоставить GoogleCL права на управление сервисом. После этого можно вернуться в терминал и нажать Enter.

Теперь нам нужно научиться делать сам снимок. Для этого можно использовать mplayer. Сначала запускаем в тестовом режиме:

$ mplayer tv://

Если получили на экран картинку с другого подключенного видеоустройства (TV-тюнер, например) или с другой камеры, перебираем все устройства в поисках нужного, меняя video0 на video1, video2 и так далее:

$ mplayer tv:// -tv device=/dev/video0

Если картинка перевернута, применяем фильтр:

$ mplayer tv:// -vf flip

Пробуем сделать снимок:

$ mplayer tv:// -frames 3 -vo jpeg

Получаем три снимка: 00000001.jpg, 00000002.jpg и 00000003.jpg. Это три последовательных кадра. Такое количество нужно потому, что многие дешевые камеры просто не успевают инициализироваться и вместо нормального изображения поначалу выдают кашу (у меня первый кадр — зеленый экран, второй — съехавшая картинка, третий — нормальный снимок). Теперь все, что нужно, — это написать скрипт, который будет делать снимок и загружать его в Picasa. У меня получилось вот что:

$ vi ~/bin/webcamera-picasa.sh #!/bin/sh mplayer tv:// -frames 3 -vf flip -vo jpeg DATE=`date +%F-%H-%M` mv 00000003.jpg ${DATE}.jpg google picasa post WebCamera ${DATE.jpg} --title ${DATE} rm -f 0000*.jpg ${DATE}.jpg

Это все, теперь на скрипт можно поставить бит исполнения и использовать его для каких угодно целей. Например, добавить в cron задание, которое будет запускать его каждый час или каждый день. Все снимки будут иметь имя в виде времени съемки, и ты в любой момент сможешь посмотреть их в Google+, где бы ты ни находился. Таким же образом, кстати, можно организовать загрузку фотографий в Dropbox, просто заменив предпоследнюю строку на «mv ${DATE}.jpg ~/Dropbox/».

Автозагрузка видео в YouTube

Таким же образом можно организовать автоматическую съемку и загрузку видео в YouTube. Для этого сначала разрешим GoogleCL работать с сервисом:

$ google youtube list

Как в случае с Picasa, вводим адрес своей электронной почты и нажимаем «Разрешить» в открывшемся окне. Далее можно попробовать загрузить тестовое видео для проверки работоспособности:

$ google youtube post video.avi --access=private --category Education
Загружаем видео в YouTube
Загружаем видео в YouTube

Видео будет загружено в раздел Education (YouTube требует указания имени раздела) и сделано приватным, так что никто, кроме тебя, его не увидит. В случае успешной загрузки ты получишь ссылку на видео. Если все ОK, можно приступать к реализации скрипта. Выглядеть он будет так:

$ vi ~/bin/webcamera-youtube.sh #!/bin/sh TIME='1:00' DATE=`date +%F-%H-%M` mencoder tv:// -fps 15 -vf flip -ovc lavc -lavcopts vcodec=mpeg4 -nosound -endpos $TIME -o ${DATE}.mpg google youtube post ${DATE}.mpg --access=private --category Education rm -f ${DATE}.mpg

Для съемки здесь использован mencoder с преобразованием в формат MPEG4. Длительность съемки указана в переменной TIME и по умолчанию составляет одну минуту. Сразу после окончания съемки видео будет загружено в YouTube показанным выше способом. Как и в случае с Picasa, вместо публикации в YouTube видео можно просто скопировать в Dropbox: «cp ${DATE}.mpg ~/Dropbox».

Автоматически загруженное видео в YouTube
Автоматически загруженное видео в YouTube

Такой скрипт можно использовать разными способами, включая запуск съемки по запросу через SSH или какой-нибудь Google Talk, либо добавить в задание cron и регулярно получать сводки с места событий в свой аккаунт в YouTube.

PHP: Require_once(): Unable To Allocate Memory For Pool Error and Solution

How do I fix these php warnings?

This error is usually related to Alternative PHP Cache (APC). APC is a free and open opcode cache for PHP. Its goal is to provide a free, open, and robust framework for caching and optimizing PHP intermediate code.

Solution

Edit the file /etc/php.d/apc.ini (Debian and/or Ubuntu Linux user edit the/etc/php5/conf.d/apc.ini), enter:
# vi /etc/php.d/apc.ini
Make sure the mktemp-style file_mask to pass to the mmap module is correct and valid one:

 
apc.mmap_file_mask=/tmp/apc.XXXXXX

Next make sure the size of each shared memory segment, with M/G suffix is set correct as per your requirements. In my case it was set to 8M:

 
; increased to 96M
apc.shm_size=96M

You need to adjust the number of seconds a cache entry is allowed to idle in a slot in case this cache entry slot is needed by another entry:

 
apc.ttl=3600

The number of seconds a user cache entry is allowed to idle in a slot in case this cache entry slot is needed by another entry:

 
apc.user_ttl=3600

The number of seconds that a cache entry may remain on the garbage-collection list.

 
apc.gc_ttl=3600

Save and close the file. Make sure you adjust the values as per your web-app requirements.Restart the Apache 2 web server:
# service httpd restart
If you are using the Lighttpd instead of Apache2 web-server, restart the Lighttpd web server:
# service lighttpd restart
If you are using Nginx instead of Apache2 or Lighttpd, restart the Nginx web server:
# service nginx restart
OR
# /usr/local/nginx/sbin/nginx -s reload

Tip: Find out your APC memory usage and hit ratio

You need to find out exact memory usage and hit ratio so that you can set apc.ttl and apc.shm_size as per your work load. Copy /usr/share/php-pecl-apc/apc.php to your /var/www/html directory i.e. Apache DocumentRoot:
# cp /usr/share/php-pecl-apc/apc.php /var/www/html
Edit /var/www/html/apc.php and set the admin password :

 
defaults('ADMIN_PASSWORD','YOUR-NEW-PASSWORD-HERE');

Save and close the file. Fire a web-browser and type the url:
http://server-ip-here/apc.php
OR
http://server1.cyberciti.biz/apc.php
Sample outputs:

Apc Memory Status and Hit Ratio

Fig.01: Apc Memory Status and Hit Ratio

From the above graph I’m getting 100.0% hit ratio and I’ve used almost all memory. I need to increase memory and reduce ttl value so that I will not get memory allocation error.

References:
  1. PHP APC documentation.

 

Next example help too:

apc.enabled = 1
apc.enable_cli = 1
apc.max_file_size = 2M
apc.shm_size = 256M
apc.ttl = 120
apc.user_ttl = 120
;stat should normally be placed at 1 for production / live environment
apc.stat = 0
apc.slam_defense = 0
apc.mmap_file_mask = «/tmp/apc.XXXXXX»

Аудит системных событий в Linux

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

Перед тем как перейти к основной части статьи, постараемся разобраться с тем, что же все-таки представляет собой системный аудит (или аудит системных событий). По самой своей сути это не что иное, как постоянное и подробное протоколирование любых событий, происходящих в операционной системе. Аудиту могут быть подвержены такие события, как чтение/запись файлов, выполнение входа в ОС, запуск и остановка приложений, инициация сетевого соединения и многое, многое другое. Linux, как и любая другая современная серверная ОС, включает в себя все необходимые инструменты для проведения аудита системы, однако разобраться в них с наскоку не так-то просто.

Система аудита ядра 2.6

Начиная с версии 2.6, ядро Linux включает в себя подсистему, специально разработанную для проведения аудита. Она позволяет вести слежение за такими системными событиями, как:

  • Запуск и завершение работы системы (перезагрузка, остановка);
  • Чтение/запись или изменение прав доступа к файлам;
  • Инициация сетевого соединения или изменение сетевых настроек;
  • Изменение информации о пользователе или группе;
  • Изменение даты и времени;
  • Запуск и остановка приложений;
  • Выполнение системных вызовов.

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

Установка

Демон auditd доступен в любом современном Linux-дистрибутиве и может быть установлен с помощью стандартного менеджера пакетов. Например, чтобы установить auditd в Debian/Ubuntu, достаточно выполнить следующую команду:

$ sudo apt-get install auditd

Кроме самого демона, вместе с пакетом будут установлены три подсобные утилиты, используемые для управления системой аудита и поиска записей в журнальных файлах:

  • auditctl – утилита, управляющая поведением системы аудита. Позволяет узнать текущее состояние системы, добавить или удалить правила;
  • autrace – аудит событий, порождаемых указанным процессом (аналог strace);
  • ausearch – команда, позволяющая производить поиск событий в журнальных файлах;
  • aureport – утилита, генерирующая суммарные отчеты о работе системы аудита;

По умолчанию система аудита находится в спящем состоянии и не реагирует ни на какие события (ты можешь убедиться в этом, выполнив команду «sudo auditctl -l»). Чтобы заставить систему сообщать нам подробности каких-либо событий, необходимо добавить правила. Но чтобы понять, как их составлять, придется разобраться с тем, как работает подсистема аудита ядра Linux.

Аудит системных событий

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

Именно это делает подсистема аудита. Она устанавливает триггеры до и после всех функций, ответственных за обработку системных вызовов, и ждет. Когда происходит системный вызов, триггер срабатывает, подсистема аудита получает всю информацию о вызове и его контексте, передает ее демону auditd и отдает дальнейшее управление функции, обрабатывающей системный вызов. После ее завершения срабатывает «выходной» триггер, и вся информация о системном вызове вновь поступает к подсистеме аудита и демону auditd.

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

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

Правила аудита

Для создания, удаления и модификации правил аудита предназначена утилита auditctl. Есть три основных опции, которые принимает эта команда:

  • -a – добавить правило в список;
  • -d – удалить правило из списка;
  • -D – удалить все правила;
  • -l – вывести список заданных правил.

Если ты сейчас выполнишь команду «auditctl -l» от имени администратора, то, скорее всего, увидишь «No rules», а это значит, что ни одного правила аудита еще не существует. Для добавления правил используется следующая форма записи команды auditctl:

# auditctl -a список,действие -S имя_системного_вызова -F фильтры

Здесь список – это список событий, в который следует добавить правило. Всего существует пять списков:

  • task – события, связанные с созданием процессов;
  • entry – события, происходящие при входе в системный вызов;
  • exit – события, происходящие во время выхода из системного вызова;
  • user – события, использующие параметры пользовательского пространства, такие как uid, pid и gid;
  • exclude – используется для исключения событий.

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

Второй параметр опции – ‘-a’ – это действие, которое должно произойти в ответ на возникшее событие. Их всего два: never и always. В первом случае события не записываются в журнал событий, во втором – записываются.

Далее указывается опция ‘-S’, которая задает имя системного вызова, при обращении к которому должен срабатывать триггер (например, open, close, exit, и т.д.). Вместо имени может быть использовано числовое значение.

Необязательная опция ‘-F’ используется для указания дополнительных параметров фильтрации события. Например, если мы хотим вести журнал событий, связанных с использованием системного вызова open(), но при этом желаем регистрировать только обращения к файлам каталога /etc, то должны использовать следующее правило:

# auditctl -a exit,always -S open -F path=/etc/

Чтобы еще более сузить круг поисков, сделаем так, чтобы регистрировались только те события, при которых файл открывается только на запись и изменение атрибутов:

# auditctl -a exit,always -S open -F path=/etc/ -F perm=aw

Здесь ‘a’ – изменение атрибута (то есть attribute change), а ‘w’ – запись (то есть write). Также можно использовать ‘r’ – чтение (read) и ‘x’ – исполнение (execute). Другие полезные фильтры включают в себя: pid – события, порождаемые указанным процессом, apid – события, порождаемые указанным пользователем, success – проверка на то, был ли системный вызов успешным, a1, a2, a3, a4 – первые четыре аргумента системного вызова. Фильтр key используется для указания так называемого ключа поиска, который может быть использован для поиска всех событий, связанных с этим ключом. Количество возможных фильтров достаточно велико, их полный список можно найти в man-странице auditctl.

Вообще, для слежения за файлами в auditctl предусмотрен специальный синтаксис, при котором опцию ‘-S’ можно опустить. Например, описанное выше правило может быть задано следующим образом (здесь опция ‘-p’ – это эквивалент фильтра perm):

# auditctl -a exit,always -F dir=/etc/ -F perm=wa

Или используя более короткую форму (здесь оцпия ‘-p’ – это эквивалент фильтра perm, а ‘-k’ – фильтра key):

# auditctl -w /etc/ -p wa -k access_etc

Таким же образом может быть установлена «слежка» за любым индивидуальным файлом:

# auditctl -w /etc/passwd -p wa

Конфигурационные файлы

Правила не обязательно задавать, используя командную строку. Во время старта демон auditd читает два файла: /etc/audit/auditd.conf и /etc/audit/audit.rules (в некоторых дистрибутивах они могут находиться прямо в /etc). Первый описывает конфигурацию демона и содержит такие опции, как имя журнала, его формат, частота обновления и другие параметры. Нет смысла их изменять, разработчики дистрибутива уже позаботились о грамотной настройке.

Второй файл содержит правила аудита в формате auditctl, поэтому все, что нужно сделать, чтобы получить правило, пригодное для записи в этот файл – просто опустить имя команды. Например:

-w /etc/passwd -p wa

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

# Удаляем все правила из всех списков
-D

# Указываем количество буферов, хранящих сообщения аудита
-b 8192

# Что делать в чрезвычайной ситуации (например, если все буферы будут заполнены)

0 – ничего не делать

1 – поместить сообщение в dmesg

2 – отправить ядро в панику (kernel panic)

-f 1

Далее можно разместить свои правила.

Примеры правил

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

# vi /etc/audit/audit.rules

# Наблюдение за конфигурационными файлами
-w /etc/audit/auditd.conf -p wa
-w /etc/audit/audit.rules -p wa
-w /etc/libaudit.conf -p wa
-w /etc/default/auditd -p wa

# Наблюдение за журнальными файлами
-w /var/log/audit/
-w /var/log/audit/audit.log

Далее установим наблюдение за наиболее важными системными конфигурационными файлами. Изменение хотя бы одного из них может привести к открытию дыры в безопасности системы, чего допустить нельзя. Обрати внимание, что некоторые файлы актуальны только для дистрибутивов Debian/Ubuntu!

# vi /etc/audit/audit.rules

# Настройки и задания at
-w /var/spool/at
-w /etc/at.allow
-w /etc/at.deny

# Задания cron
-w /etc/cron.allow -p wa
-w /etc/cron.deny -p wa
-w /etc/cron.d/ -p wa
-w /etc/cron.daily/ -p wa
-w /etc/cron.hourly/ -p wa
-w /etc/cron.monthly/ -p wa
-w /etc/cron.weekly/ -p wa
-w /etc/crontab -p wa
-w /var/spool/cron/root

# Файлы паролей и групп
-w /etc/group -p wa
-w /etc/passwd -p wa
-w /etc/shadow

# Конфигурационные и журнальные файлы входа в систему
-w /etc/login.defs -p wa
-w /etc/securetty
-w /var/log/faillog
-w /var/log/lastlog

# Список и имена хостов
-w /etc/hosts -p wa

# Стартовые скрипты демонов
-w /etc/init.d/
-w /etc/init.d/auditd -p wa

# Пути поиска библиотек
-w /etc/ld.so.conf.d
-w /etc/ld.so.conf -p wa

# Настройки времени
-w /etc/localtime -p wa

# Системные переменные
-w /etc/sysctl.conf -p wa

# Правила загрузки модулей
-w /etc/modprobe.d/

# Модули системы PAM
-w /etc/pam.d/

# Настройки сервера SSH
-w /etc/ssh/sshd_config

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

# vi /etc/audit/audit.rules

# Изменение прав доступа к файлам
-a entry,always -S chmod -S fchmod -S chown -S chown32 -S fchown -S fchown32 -S lchown -S lchown32

# Создание, открытие или изменение размеров файлов
-a entry,always -S creat -S open -S truncate -S truncate64 -S ftruncate -S ftruncate64

# Создание и удаление каталогов
-a entry,always -S mkdir -S rmdir

# Удаление или создание ссылок
-a entry,always -S unlink -S rename -S link -S symlink

# Изменение расширенных атрибутов файлов
-a entry,always -S setxattr
-a entry,always -S lsetxattr
-a entry,always -S fsetxattr
-a entry,always -S removexattr
-a entry,always -S lremovexattr
-a entry,always -S fremovexattr

# Создание файлов устройств
-a entry,always -S mknod

# Монтирование файловых систем
-a entry,always -S mount -S umount -S umount2

# Использование системного вызова ptrace для отладки процессов
-a entry,always -S ptrace

Анализ журнальных файлов

Журнальные файлы, создаваемые демоном auditd в каталоге /var/log/audit, не предназначены для чтения человеком, но хорошо подходят для анализа с помощью специальных утилит, устанавливаемых вместе с самим демоном. Самая важная из них – утилита aureport, генерирующая отчеты из лог-файлов. Вызвав ее без аргументов, мы узнаем общую статистику использования системы, включая такие параметры, как количество входов и выходов из системы, открытых терминалов, системных вызовов и т.д. Эта информация малоинтересна, поэтому лучше запросить более детальный отчет. Например, запустив команду с флагом ‘-f’, мы получим список файлов, к которым происходил доступ:

$ sudo aureport -f

Скорее всего вывод будет слишком длинным, но его можно сократить с помощью запроса информации только за определенный период времени (аргумент ‘–end’ не обязателен):

$ sudo aureport -f --start 08/20/10 12:00 --end 08/20/10 13:00

Кроме числового значения времени можно использовать следующие специальные сокращения: now (сейчас), recent (десять минут назад), today (начиная с полуночи), yesterday (вчерашние сутки), this-week (неделя), this-month (месяц) или this-year (год). Вывод команды разбит на несколько столбцов, которые имеют следующие значения (слева направо):

  1. Просто числовой индекс;
  2. Дата возникновения события;
  3. Время возникновения события;
  4. Имя файла;
  5. Номер системного вызова (чтобы увидеть его имя, используй флаг ‘-i’);
  6. Успешность системного вызова (yes или no);
  7. Имя процесса, вызвавшего событие;
  8. Audit UID (AUID). О нем читай ниже;
  9. Номер события.

Вывод этой команды также можно существенно сократить, если указать флаг ‘–summary’, который заставляет aureport выводить не все случаи доступа к файлом, а только их общее количество по отношению к каждому из файлов:

$ sudo aureport -f -i --start recent --summary

Вывод команды будет разбит на две колонки, первая из которых отражает количество попыток доступа к файлу (успешных или нет), а вторая – его имя. Просматривая суммарный отчет использования файлов и заметив подозрительную попытку доступа к одному из системных/скрытых/личных файлов, можно вновь вызвать aureport, чтобы найти процесс, который произвел эту попытку:

$ sudo aureport -f -i --start today | grep /etc/passwd

Получив список всех попыток доступа и номера событий, каждое из них можно проанализировать индивидуально с помощью утилиты ausearch:

$ sudo auserch -a номер_события

Также ausearch можно использовать для поиска событий по именам системных вызовов:

$ sudo ausearch -sc ptrace -i

Идентификаторам пользователей:

$ sudo ausearch -ui 2010

Именам исполняемых файлов:

$ sudo ausearch -x /usr/bin/nmap

Имени терминала:

$ sudo ausearch -tm pts/0

Именам демонов:

$ sudo ausearch -tm cron

Или ключам поиска:

$ sudo auserch -k etc_access

Вывод ausearch также может быть сокращен с помощью использования временных промежутков, наподобие тех, что мы использовали при вызове aureport. Сам aureport позволяет генерировать отчеты не только по использованию файлов, но и многих других типов событий, как, например, системные вызовы (флаг ‘-s’), попытки аутентификации (флаг ‘-au’) , успешные логины (флаг ‘-l’), модификации аккаунта (флаг ‘-m’) и многих других (полный список смотри в man-странице). Отчеты можно получать только для событий, завершившихся неудачно (флаг ‘–failed’).

AUID и PAM

Во время своей работы в системе пользователь может использовать команды su или sudo для изменения своего системного идентификатора (UID), из-за чего процесс отслеживания его деятельности существенно усложняется. Чтобы обойти эту проблему система аудита использует так называемые Audit UID (AUID), которые закрепляются за каждым пользователем во время его входа в систему и остаются неизменными даже несмотря на смену пользователем своего UID с помощью su или sudo. Однако, по умолчанию функция присваивания AUID отключена (именно поэтому восьмой столбец вывода aureport всегда содержит значение -1), и, чтобы ее активировать, необходимо отредактировать некоторые конфигурационные файлы PAM. Для этого открой файл /etc/pam.d/login и добавь строку «session required pam_loginuid.so» перед строкой «session include common-session». Таким же образом измени конфигурационные файлы /etc/pam.d/sshd, /etc/pam.d/gdm (kdm, если ты используешь среду KDE), /etc/pam.d/crond и /etc/pam.d/atd.

Выводы

Система аудита – достаточно низкоуровневый компонент Linux, который требует глубоких знаний ОС для своей настройки и анализа журнальных файлов. Однако, разобравшись в нем, ты получишь мощнейший инструмент слежения за системой, который поможет обнаружить аномалии в поведении системы и найти их виновника.

WARNING

Чтобы изменения, внесенные тобой в конфигурационные файлы демона auditd, вступили в силу, необходимо перезагрузить демон с помощью команды «/etc/init.d/auditd restart».

Осваиваем и обустраиваем консоль

Настроенный по дефолту терминал — унылое зрелище, отпугивающее новичков и наводящее тоску на гуру. Многое из того, что способен дать командный интерпретатор пользователю, оказывается скрыто за семью замками, а то, что остается доступным — просто неудобно. Перед тем, как консоль станет действительно сподручным инструментом, придется изрядно попотеть.

Полезная инфа в приглашении

Приглашение командного интерпретатора bash формируется на основе содержимого переменной окружения PS1. Если верить man-страницам, эта переменная может содержать любые строки, а также довольно большой набор специальных управляющих символов, которые при выводе приглашения будут превращены в актуальные данные. Так, например, в дистрибутиве Ubuntu содержимое переменной PS1 выглядит так:

'${debian_chroot:+($debian_chroot)}u@h:w$ '

А при выводе на экран превращается во всем знакомую строку вида:

юзер@имя_хоста:текущий_каталог$

Нетрудно догадаться, что юзер здесь появляется за счет управляющего символа ‘u’, имя хоста — за счет ‘h’, а текущий каталог — это ‘w’. Неуклюжая запись, содержащая в себе слова debian_chroot, это всего лишь индикатор того, находится ли пользователь в chroot-окружении. Такое лаконичное приглашение, конечно, удобно, но содержит далеко не всю информацию, которую bash способен отобразить. В его арсенале есть как минимум два десятка различных управляющих последовательностей, о которых многие пользователи даже не подозревают. Вот список наиболее интересных из них:

  • d — текущая дата
  • j — количество фоновых заданий
  • A — текущее время
  • ! — номер команды в истории

Кроме того, в PS1 вполне можно использовать текущие переменные окружения, а если учитывать, что перед каждым выводом на экран PS1 перечитывается, то туда можно засунуть такие вкусности, как, например, статус последней выполненной команды (переменная $?), чтобы знать, было ли ее исполнение успешным.

Управляющий символ ‘n’ также допустим в PS1, поэтому приглашение к вводу можно сделать многострочным, а заодно визуально отделить его от остального текста (с помощью начальной пустой строки):

PS1='nwnu@h:$?$ '

Но и это еще не все. Пример с индикатором chrootокружения показывает, что в приглашении можно использовать вывод любых сторонних приложений, а это открывает просто безграничные возможности по его кастомизации. Например, следующим образом в приглашение можно добавить данные о текущей погоде, количестве непрочитанных писем в gmail и уровне сигнала Wi-Fi:

$ vi ~/.bashrc

Google-погода

weather()
{

Где мы?

local city=»Moscow»
curl -s «http://www.google.com/ig/
api?weather=$city» | sed ‘s|.<temp_c data=»
([^»]
)»/>.*|1|’
}

Google-почта

unread_mail(){

Имя пользователя и пароль (без @gmail.com)

local login=»логин»
local password=»пароль»
wget —secure-protocol=TLSv1 —timeout=3 -t 1 -q -O — https://${login}:${password}@
mail.google.com/mail/feed/atom —nocheckcertificate | grep fullcount | sed
«s/<fullcount>(.*)</fullcount>/1/»
}

Сигнал Wi-Fi

wifi(){
/sbin/iwconfig wlan0 | grep Quality | cut -d = -f2 | awk '{print $1}'
}
PS1='nweather:unread_mail:wifi:wn
u@h:$?$ '

Все это нужно поместить в конец ~/.bashrc и выставить на файл права 600, чтобы никто не смог подсмотреть пароли. Результат будет примерно таким:

-7:32:70/70:/usr/local
j1m@1313:0$

Раскрашиваем консоль

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

Все escape-последовательности заключаются в [�33[ и ], а после кода цвета должна еще стоять буква m. Все цвета расписаны в справочной странице. Например, черному соответствует 0;30, зеленому — 0;32, красному — 0;31, желтому — 1;33, белому — 1;37 и так далее. Чтобы в строке приглашения выводились имя системы (символ h) и логин пользователя (u), подсвеченные красным цветом, а текущий каталог — желтым (w), в конфиге ~/.bashrc заменяем значение переменной PS1 на следующее:

PS1="[�33[0;31m]u@h:[�33[1;33m](w)[�33[0m][�33[0m]"

При необходимости через точку с запятой можно указать цвет фона. Для этой цели используются числа от 40 (черный) до 47 (белый).

PS1="[�33[32;40mw[�33[0m]>"

Все это также можно использовать в скриптах, хотя, чтобы не путаться, в этом случае лучше задействовать переменные, которые потом и вызывать в нужном месте. Например:

local GRAY="[�33[1;30m]"
local NO_COLOUR="[�33[0m]"

Не забываем о том, что некоторые команды поддерживают цветной вывод. Проще это решить при помощи алиасов:

alias ls='ls --color=auto'
alias grep='grep --color=auto'

И так далее. За настройки цветов каталогов и файлов с разным расширением отвечает утилита dircolors, устанавливающая переменную LC_COLORS. Чтобы получить все значения, просто вводим:

$ dircolors --print-database

Использовав полученный результат как шаблон и сохранив его в / etc/DIR_COLORS (либо в персональном конфиге ~/.dir_colors), можно создать свою раскраску.

Программистам будет очень полезен cout (code.google.com/p/cout) — небольшой скрипт на Python, подсвечивающий вывод make, gcc, svn и diff. Скрипт не требует установки, просто скачиваем и распаковываем архив, а затем создаем псевдоним:

$ alias makec='cout data/make-gcc.cfg'

Теперь проверяем работоспособность, используя заранее подготовленный Makefile:

$ makec -f Makefile

Автодополнение bash

Одна из самых удобных функций, имеющихся в bash — автодополнение команд по клавише <Tab>. К этому быстро привыкаешь, и кажется, что улучшить уже ничего нельзя. Однако в разных дистрибутивах автодополнение работает по-разному.

Например, в современных Linux-дистрибутивах, ориентированных на обычного пользователя, bash не только дополняет саму команду, но и предлагает дополнительные параметры. Однако в Gentoo и производных (вроде Calculate Linux) такого нет. Здесь приходится помнить все параметры назубок. Как такое может быть? Некоторые разработчики дистрибутивов используют патченые версии bash?
На самом деле, возможность автодополнения в bash — расширяемая функция. За необходимую функциональность отвечает встроенная команда compgen, генерирующая соответствующие списки. Все настройки производятся в файле /etc/bash_completion (или пользовательском ~/.bash_completion), хотя в некоторых дистрибутивах можно найти целый каталог /etc/bash_completion.d, в котором обычно собраны настройки, специфичные для отдельных программ.

В самом простом случае файл содержит программу и указания для bash по дополнению имен файлов.

Например, чтобы MPlayer предлагал пользователю в качестве автодополнения только файлы с расширением avi и mpg, пишем такое правило: complete -f -X ‘!*.@(avi|mpg|AVI|MPG/so)’ mplayer Но это самый простой вариант, ведь MPlayer имеет большое количество дополнительных параметров, а значит, ему потребуется описать шрифты, звуковые файлы, субтитры и так далее. Все это легко решается при помощи оператора case. Поддерживаются регулярные выражения, что немного упрощает создание правил.

Обычно майнтейнеры конкретного пакета сами составляют списки параметров программы для bash_completion. Никаких чудес здесь нет.

Например, для tar создаем такое правило:

COMPREPLY=( $( compgen -W 'c t x u r d A' -- "$cur" ) )

Как видишь, мы просто перечислили все параметры, и теперь в процессе ввода bash сам выдаст этот список. Команда compgen имеет ряд параметров. Так ‘-b’ позволяет получить список встроенных команд оболочки, ‘-c’ — имена команд, ‘-v’ — имена переменных и так далее. Все подробности можно найти в man-странице bash, в секциях complete и compgen.

Продвинутые настройки

Bash — довольно развитый командный интерпретатор, поддерживающий кучу разных настроек. Причем из этих настроек можно получить гораздо больше профита, чем из настроек поведения терминала, выполненных с помощью утилит setterm и stty. Список всех возможных опций можно посмотреть командой «shopt -p» (shopt — сокращение от Shell Options). Приведем самые интересные из них:

  • autocd — если эта опция включена, то можно просто написать путь к каталогу (опустив команду cd), чтобы в него переместиться;
  • cdspell — bash будет пытаться исправлять простые опечатки (например, /ect/init.d вместо /etc/init.d) в аргументах команды cd;;
  • checkjobs — не дает выйти из консоли, пока в ней есть выполняющиеся задания;
  • cmdhist — объединение многострочных команд в одну строку так, чтобы тебе было проще искать их в истории;
  • dirspell — исправление небольших ошибок в написании имени директории при автодополнении;
  • globstar — позволит использовать конструкцию вида **, обозначающую «все файлы, начиная с текущего каталога, рекурсивно»;
  • Очень удобный новый wildchar — например, данная конструкция отобразит все mp3 в текущем и вложенных каталогах:

$ ls **/*.mp3

Согласись, это гораздо короче и удобнее, чем:

$ find ./ -name "*.mp3" -type f -print

Устанавливаются опции следующим образом:

$ shopt -s autocd cdspell checkjobs cmdhist dirspell globstar

Кроме того:

1.Bash умеет сокращать путь к текущему каталогу в приглашении, если он становится слишком длинным. Для управления этой функцией предусмотрена переменная окружения PROMPT_DIRTRIM. При превышении уровня вложенности каталогов, указанного в этой переменной, путь будет сокращен. Пример использования:

$ export PROMPT_DIRTRIM=3

2.Bash поддерживает «умный» метод помещения команд в историю, позволяя освободить ее от банальностей вроде ls. В историю не будут попадать дубликаты и команды ls, bg, fg, exit после выполнения следующей команды:

$ export HISTIGNORE="&:ls:[bf]g:exit"

3. Bash умеет делать так, чтобы команды, выполненные с использованием sudo, автоматически попадали в файл истории root’а и не засоряли историю пользователя. Просто добавь следующую строку в файл /etc/bash.bashrc:

export HISTFILE=$HOME/.bash_hist-`whoami`

Индикатор прогресса

Отсутствие индикатора прогресса у большинства консольных утилит — одна из главных проблем для тех, кто часто работает в консоли. И хорошо, если под рукой есть mc, который многие так и используют, чтобы получить окошко с прогрессом. А что если это голая консоль, а тебе требуется сохранить бэкап на флешку, смонтированную в режиме sync? В этом случае тебе поможет rsync, который хоть и несколько замедляет процесс копирования, но зато обеспечивает вывод на экран шкалы прогресса. Помещаем в ~/.bashrc следующую строку:

alias cpr='rsync --progress'

И используем команду cpr вместо cp:

$ cpr file1 file2

Если добавить опцию ‘–remove-source-files’, то исходные файлы будут удалены (правда, следует помнить, что в пределах одной файловой системы mv гораздо быстрее rsync). Единственный минус — прогресс отображается для каждого файла в отдельности, общий прогресс увидеть нельзя.

Чтобы увидеть ход выполнения, например, при создании архива, можно использовать утилиту pv (Pipe Viewer). Технически она представляет собой замену стандартного cat, способную не только тупо копировать байты на выход, но и показывать прогресс этой операции. Например:

$ tar -czf — /path/to/dir | pv > /path/to/archive.tgz
758MB 0:01:29 [8,48MB/s] [ <=>

Уже хорошо. Но не хватает времени завершения. Для этого надо передать утилите pv размер каталога (в байтах) с помощью ключа ‘-s’:

$ tar -czf — /path/to/dir | pv -s $(du -sb /path/to/dir | grep -o '[0-9]*') > /path/to/archive.tgz
461MB 0:00:21 [ 32MB/s] [=======================================> ] 60% ETA 0:00:13

Каждый раз набирать такую конструкцию не очень удобно, лучше сделать алиас.

Закладки каталогов в консоли

При выполнении операций администрирования приходится часто переходить по каталогам файлового дерева. Bash поддерживает ряд сокращений (например, чтобы вернуться в домашний каталог, просто вводим «cd», в предыдущий каталог — «cd -»), но этого мало. Конечно, можно использовать псевдонимы (aliases), вроде:

alias cdwww='cd /var/www'

Но этого все равно бывает недостаточно в том случае, если список каталогов большой. И главное — использование алиасов не очень удобно. Так, чтобы создать новый псевдоним, нужно вручную прописать его в ~/.bashrc и перезапустить терминал. Небольшой скрипт Directory Bookmarks for BASH (dirb.info/bashDirB) расширяет набор сокращений, позволяя на лету создавать закладки на нужные каталоги и переходить в них короткой командой.

Скачиваем:

$ wget -c http://www.dirb.info/bashDirB -o ~/.bashDirB

И добавляем в файл ~/.bashrc строку:

source ~/.bashDirB

Теперь каждая новая сессия будет поддерживать закладки. Переходим в нужный каталог и сохраняем его в закладку:

$ cd /var/www
$ s www

После этого будет создан файл ~/.DirB/www, содержащий ссылку на закладку. Теперь, чтобы вернуться в указанный каталог с любого места файловой системы, достаточно ввести в консоли «g www». Аналогичным образом можно создавать любое количество закладок. Но это не все параметры. Например, параметр «p» позволяет запомнить последние перемещения и выводит их в консоли:

$ p www
/var/www
~

И, наконец, команда s1 позволит просмотреть листинг закладок. Для удаления закладки используем ключ ‘-r’.

Также следует знать, что bashDirB модифицирует переменную PS1 таким образом, что в приглашении выводится время и номер текущего каталога в history. Если тебя это не устраивает, просто закомментируй соответствующую строку в скрипте.

В качестве альтернативы bashDirB можно использовать apparix (micans.org/apparix), предлагающий три команды: bm (создание закладки), to (переход к закладке) и portal (добавление подкаталогов в закладки). Помимо bash также поддерживается csh. Пакет доступен в репозитарии Debian/Ubuntu и некоторых других дистрибутивов.

Фортунки

В некоторых Linux-дистрибутивах после запуска консоли выводится небольшая цитата. Практической пользы от нее вроде и нет, но небольшое шуточное высказывание повышает настроение и настраивает на рабочий лад. Тематические пакеты с базами высказываний называются fortunes, а сами цитаты — фортунками.

За несколько десятков лет в Сети появилось большое количество сборников цитат, которые легко интегрируются в консоль. Чтобы установить их в Debian или Ubuntu, достаточно ввести команду:

$ sudo apt-get install fortunes fortunes-debianhits fortunes-ubuntu-server fortunes-min fortune-mod fortunes-ru

Последние два пакета содержат большое количество афоризмов на русском. Кроме этого, в интернете доступны и другие русскоязычные сборки фортунок, найти которые очень просто — достаточно вбить в Гугле fortunes-ru и получим несколько десятков ссылок (например, избранные цитаты с сайта linux.org.ru: lorquotes.ru/fortunes.php).

После установки необходимо настроить вывод цитат в консоль. В самом простом случае достаточно прописать в конфиг ~/.bashrc всего одно слово:

$ echo "fortune" >> ~/.bashrc

Далее следует перезапустить терминал или перезагрузить файл настроек (команда «source ~/.bashrc»). Cписок выводимых категорий фортунок можно получить, введя:

$ fortunes -f

После установки все фортунки помещаются в один из подкаталогов /usr/share/games/fortunes, откуда их и забирает программа. В случае необходимости при помощи ключа ‘-m’ можно указать шаблон фортунок, которые будут выводиться. После добавления своих фортунок следует использовать утилиту strfile для создания индекса (strfile файл_фортунок).

При желании можно грабить RSS-новости, твиты, прогноз погоды или котировки валют с любого сайта, выводя их в качестве фортунок. Хотя для этого мне больше нравятся аналоги fortunes — пакеты cowsay и xcowsay. Сowsay представляет собой приложение на Perl, которое выводит изображение говорящей или думающей коровы, нарисованной ASCII-символами.

$ sudo apt-get install cowsay xcowsay

По умолчанию корова не знает, что сказать, умную мысль ей надо подкинуть. Например, выведем uptime:

$ uptime | cowsay

Или фортунку (так реализовано в Linux Mint):

$ cowsay 'fortune'

Кроме стандартной коровы доступны и другие персонажи, соответствующие названию файлов в подкаталоге /usr/share/cowsay/ cows. Вызвать их можно при помощи параметра ‘-f’. Также ряд параметров изменяют внешний вид коровы: ‘-t’ — усталая корова, ‘-p’ — параноидальная, ‘-w’ — обалдевшая и так далее. Чтобы автоматизировать процесс, заносим строку запуска в ~/.bashrc:

COWDIR=/usr/share/cowsay/cows/;
COWNUM=$(($RANDOM%$(ls $COWDIR | wc -l)));
COWFILE=$(ls $COWDIR | sed -n ''$COWNUM'p'); fortune |
cowsay -f $COWFILE

Заключение

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

Перенос директории dotfiles

Перенос директории dotfiles с одного компа (IP-адрес 192.168.1.1, порт 10000) на другой при помощи netcat и pv:

host1$ tar -cf — dotfiles | pv | nc -l -p 10000 -q 5
host2$ nc 192.168.1.1 10000 | pv | tar -xf

В случае, если host1 работает под управлением OpenBSD, команда должна выглядеть так:

obsdhost1$ tar -cf — dotfiles | pv | nc -l 10000

Пишем в твиттер легко и непринужденно

Простая функция, отправляющая сообщения в твиттер:

$ vi ~/.bashrc
twit()
{
curl --basic --user юзер:пароль --data
status="$*" 'http://twitter.com/statuses/update.xml' -o /dev/null;
}

Использовать так:

$ twit 'Привет из консоли'

Не забываем про 140 символов.

How much is the FISH?

Новичкам в консоли следует внимательно посмотреть в сторону альтернативного командного интерпретатора под названием FISH (Friendly Interactive Shell). Его преимущества перед bash довольно внушительны. Fish на полную катушку использует возможность управления цветами терминала. Он оснащен гораздо более мощной системой автодополнения, которая выводит на экран не только списки каталогов, аргументов и имена команд, но и массу другой полезной информации (например, рядом с каждой опцией помещается описание того, что она делает). В Fish встроена очень хорошая система подсказок, так что если ты допустишь ошибку, то получишь обширное разъяснение того, что произошло, и способы обхода проблемы. Наконец, скриптовый язык Fish гораздо проще и логичнее стандартного языка sh.

Info

  • Во FreeBSD использовать rsync для получения прогресса копирования файлов нет смысла. Можно просто нажать <Ctrl+T> во время работы команды cp, и она сама выдаст прогресс операции на экран.
  • Чтобы сделать man-страницы цветными, установи пакет most с помощью пакетного менеджера и добавь строку «export MANPAGER=”/usr/ bin/most -s» в файл ~/.bashrc.
  • Команда «stty -echo» отключает вывод в терминал того, что набирается на клавиатуре. Подобное поведение можно наблюдать при вводе пароля при логине в терминале.
  • Убрать курсор из терминала и выключить гашение экрана можно с помощью команд «setterm -cursor off» и «setterm -blank 0».

Возможности OpenSSL и OpenSSH, о которых ты не знал.

Такие инструменты, как OpenSSH и OpenSSL, в представлении не нуждаются. Это вечные друзья любого сисадмина и многих продвинутых пользователей. Однако далеко не все знают об их истинной мощи и возможностях, накопленных за годы разработки. Сегодня тебе откроется масса интересных способов использования этих программ.

OpenSSH

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

Используем OpenSSL для подключения к Gmail

INFO

С полным списком команд OpenSSL можно ознакомиться с помощью следующих параметров: list-standart-commands, list-message-digest-commands, list-cipher-commands.

Итак, трюк номер один — множественные подключения. OpenSSH способен обслуживать множество одновременных соединений с одной и той же машиной. Обычно пользователи просто запускают команду и ждут ее завершения, чтобы запустить следующую. К счастью, эту проблему легко обойти путем разделения одного соединения на множество сессий. Просто добавь в конфиг ssh (~/.ssh/config) следующие строки:

ControlMaster auto
ControlPath ~/.ssh/mux_%h_%p_%r

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

Шифруем файлы с помощью OpenSSL

Трюк номер два — проксирование соединений. Допустим, ты не можешь создать соединение с SSH-сервером напрямую, но можешь использовать для этого другой хост, к которому ты тоже имеешь SSH-доступ. Добавь в свой конфиг следующие строки:

ForwardAgent yes
Host host
HostName host.com
ProxyCommand ssh proxy-host.com \
netcat -q 600 %h %p

Команда ssh host создаст соединение с сервером host.com через сервер proxy-host.com.

Трюк номер три — выход за пределы HTTP-изоляции. Многие организации не просто режут неугодный им трафик, но и принуждают пользователей выходить в Сеть только с использованием HTTP-протокола. Такую несправедливость легко обойти с помощью сorkscrew (www.agroman.net/corkscrew/), который умеет туннелировать SSH-трафик через HTTP. Просто установи его на свою машину и добавь в конфиг следующие строки (где proxy.com и 80 — это адрес внешнего HTTP-прокси и его порт):

Host *
ProxyCommand corkscrew proxy.com 80 %h %p

Теперь все соединения пойдут через указанный HTTP-прокси.

Трюк номер четыре — тест пропускной способности сети. Чтобы протестировать скорость соединения, необязательно устанавливать специализированное ПО, достаточно утилиты pv и старого доброго SSH:

$ sudo apt-get install pv
$ yes | pv | ssh host.com "cat > /dev/null"

Тестируем скорость соединения с помощью SSH и pv

Трюк номер пять — удаленный анализ сетевого трафика. Почти в любой UNIX-системе есть сетевой сниффер tcpdump, однако читать его логи довольно утомительно. Возможности OpenSSH помогут упростить анализ трафика:

$ ssh root@host.com tcpdump -w - 'port !22' \
| wireshark -k -i -

Теперь весь трафик, проходящий через host.com, будет виден в графическом окне wireshark на твоей машине.

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

$ sudo apt-get install cstream
$ tar -cj /backup | cstream -t 512k | \
ssh host 'tar -xj -C /backup'

Трюк номер семь — всегда открытая SSH-сессия. Пользователям ноутбуков, чье соединение с сетью может быть не постоянным, приходится каждый раз заново запускать SSH-клиент в момент, когда сеть появляется, и убивать его при потере соединения. Избежать этого можно с помощью инструмента autossh, который будет поддерживать иллюзию постоянного соединения с сервером, восстанавливая связь, когда сеть окажется доступной:

$ sudo apt-get install autossh
$ autossh -M50000 -t server.example.com \
'screen -raAd mysession'

Трюк номер восемь — запуск команды на нескольких серверах одновременно. Комментарии излишни:

$ echo "uptime" | pee "ssh host1" "ssh host2" \
"ssh host3"

Трюк номер девять — удаленное сравнение файлов. Часто требуется сравнить локальную и удаленную версию какого-либо конфига, однако копировать файлы туда-сюда неудобно и долго. В этом случае можно воспользоваться следующей командой:

$ ssh user@host cat /путь/к/удаленному/файлу | \
diff /путь/к/локальному/файлу -

То же самое можно проделать для двух файлов, находящихся на разных серверах:

$ diff <(ssh host1 cat /etc/apt/sources.list) \
<(ssh host2 cat /etc/apt/sources.list)

cpu0: RNG AES

Результаты бенчмарка криптографических средств, встроенных в CPU платформы VIA Eden (процессорные инструкции для работы с алгоритмом блочного симметричного шифрования AES):

% openssl speed -elapsed -evp aes-256-cbc
type 16 bytes 64 bytes256 bytes   1024 bytes   8192 bytes
aes-256-cbc  21780.33k79591.78k   198578.08k   317102.05k   383371.05k

Трюк номер 10 — одновременный просмотр логов с нескольких машин. С помощью multitail и SSH можно запросто просматривать логи с двух серверов одновременно:

$ sudo apt-get install multitail
$ multitail -l 'ssh host1 "tail -f \
/var/log/apache2/error.log"' -l 'ssh host2 \
"tail -f /var/log/apache2/error.log"'

Трюк номер 11 — копирование файлов с одной удаленной машины на другую через локальную. В случае если две удаленные машины не могут установить связь друг с другом, файлы между ними можно передавать, используя свой комп в качестве промежуточного звена:

$ ssh root@host1 "cd /каталог && tar -cf – ." |\
ssh root@host2 "cd /каталог && tar -xf -"

Трюк номер 12 — копирование вывода удаленной команды в буфер обмена. Часто требуется скопировать вывод удаленной команды в буфер обмена, чтобы вставить его в письмо, сообщение форума и т. д. Проще всего это сделать с помощью утилиты xclip:

$ ssh user@host cat /файл.txt | xclip

Трюк номер 13 — синхронизация времени средствами SSH. В случае, если машина не имеет доступа к NTP-серверу или на ней не установлен NTP-клиент, синхронизировать время между машинами можно так:

# date --set="$(ssh user@server date)"

Трюк номер 14 — установка пакетов удаленной машины на локальную. Нередко требуется синхронизировать две машины так, чтобы они имели одинаковый набор установленных пакетов. Стандартными методами сделать это сложно, но с помощью SSH проще простого:

# ssh remotehost 'dpkg --get-selections' | \
dpkg --set-selections && dselect install

Трюк номер 15 — снимок удаленного экрана. Можно очень легко получить изображение X-сервера с удаленной машины, воспользовавшись стандартным графическим пакетом ImageMagick:

# ssh user@host "DISPLAY=:0.0 import -window \
root -format png -" | display -format png -

Чтобы сохранить его в файле, последнюю команду следует заменить на «> file.png»

Трюк номер 16 — ускорение передачи данных. Если машины, с которыми установлено соединение, находятся внутри заведомо безопасной сети (например, офис или дом), передачу данных средствами SSH можно несколько ускорить, если использовать менее стойкий алгоритм шифрования. Для этого добавь в конфигурационный файл следующие строки:

Host host.com
Ciphers arcfour256
MACs umac-64@openssh.com

Трюк номер 17 — вывод звука с удаленной машины на локальную. Вместе с картинкой рабочего стола удаленной машины иногда хочется получить и звук. Это делается с помощью банального dd:

$ dd if=/dev/dsp | ssh -c arcfour -C \
user@host dd of=/dev/dsp

Трюк номер 18 — запуск локального скрипта на удаленной машине. Нередко требуется запустить скрипт на удаленной машине, однако копировать его туда совсем необязательно, достаточно выполнить следующую простую команду:

$ ssh -T user@host < script.sh

OpenSSL

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

  • создание ключей RSA и DSA и управление ими (команды rsa, dsa, dsaparam);
  • создание сертификатов формата x509, формирование запросов на сертификацию, восстановление (команды x509, req, verify, ca, crl, pks12, pks7);
  • симметричное и асимметричное шифрование данных (команды enc, rsautl);
  • расчет хешей (команда dgst);
  • работа с S/MIME (команда s/mime).

Также OpenSSL может быть использован для проверки SSL-серверов и клиентов с помощью специальных команд sclient/sserver и для тестирования скорости работы различных алгоритмов (команда speed).

Мы не раз писали о работе с пакетом OpenSSL, поэтому не будем рассматривать стандартные примеры его использования вроде создания хешей и сертификатов, а сразу перейдем к более серьезным трюкам.

 Тестируем скорость алгоритмов с помощью команды speed

Время — деньги

Одна из интересных особенностей OpenSSL заключается в том, что он может провести бенчмарк используемых алгоритмов и скорости установления SSL-соединения. Для этого предназначена стандартная команда s_time. Чтобы оценить скорость установки SSL-соединения, нужно применить ее к команде openssl:

$ openssl s_time -connect gmail.com:443 \
-www /test.html -new
103 connections in 0.75s; 137.33 connections/user sec, bytes read 42436
103 connections in 31 real seconds, 412 bytes read per connection

То же самое можно проделать с помощью наиболее стойких алгоритмов:

$ openssl s_time -ssl3 -cipher HIGH \
-connect gmail.com:443 -www / -new
99 connections in 0.73s; 135.62 connections/user sec, bytes read 40788
99 connections in 31 real seconds, 412 bytes read per connection

Эти две команды позволяют определить максимальную пропускную способность SSL-сервера. Но еще более интересный способ заключается в тестировании всех поддерживаемых алгоритмов. Для этого нам придется прибегнуть к скриптингу:

IFS=":"
for c in $(openssl ciphers -ssl3 RSA); do
  echo $c
  openssl s_time -connect host:443 -www / -new \
  -time 10 -cipher $c 2>&1 | grep bytes
  echo
done

Такая команда позволяет измерить скорость установки SSL-соединения с помощью различных алгоритмов шифрования, что можно использовать, например, для тюнинга SSL-сервера. Если же SSL-сервера как такового еще нет, его легко эмулировать с помощью самого OpenSSL. На серверной машине запускаем OpenSSL-сервер:

$ openssl s_server -cert mycert.pem -www

На клиентской выполняем следующую команду:

$ openssl s_time -connect myhost:4433 \
-www / -new -ssl3

Клиентская сторона

Еще одна интересная команда OpenSSL — это s_client, которая позволяет коннектиться к удаленным SSL-серверам для их тестирования. Чаще всего я использую эту команду, чтобы проверить дату выдачи сертификата. Для этого следует просто подключиться к удаленному SSL-серверу, дождаться, пока на экране появится информация о сертификате, а затем прогнать его через всё тот же openssl, чтобы вычленить даты. При использовании одной команды всё это выглядит так:

$ echo | openssl s_client -connect \
www.google.com:443 2>/dev/null | \
openssl x509 -dates -noout
notBefore=Oct 26 00:00:00 2011 GMT
notAfter=Sep 30 23:59:59 2013 GMT

Вычленяем нужную информацию из сертификата x509

Команду s_client можно также применять для тестирования сервера на уязвимость, заключающуюся в использовании нестойких алгоритмов шифрования:

$ openssl s_client -connect www.google.com:443 \
    -cipher LOW
CONNECTED(00000003)
140513251690152:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:s23_clnt.c:658:

Сервер, не поддерживающий нестойкие алгоритмы шифрования, просто откажется устанавливать соединение, как это и произошло в случае с сервером Google. Команда s_client также довольно удобна для отладки различных протоколов (в этом случае она выступает в виде SSL’ного Telnet). Например:

$ openssl s_client -starttls smtp -crlf \
    -connect smtp.gmail.com:25

Шифрование

О шифровании с помощью OpenSSL не писал только ленивый, поэтому мы остановимся не на самих принципах шифрования, а на том, как его можно использовать для вспомогательных задач. Утилита командной строки openssl удобна тем, что она, как и все остальные команды UNIX, может принимать данные на вход и имеет для них стандартный выход. В результате с помощью одной простой команды можно обеспечить, например, защищенную передачу файла по сети:

отправляющий$ cat /etc/passwd | openssl \
aes-256-cbc -a -e -pass pass:пароль | \
netcat -l -p 8080
принимающий$ netcat хост:8080 | openssl \
aes-256-cbc -a -d -pass pass:пароль > passwd

Можно также применять и различные скрипты, чтобы автоматизировать шифрование множества файлов (пароль шифрования в /tmp/passwd):

$ for f in * ; do [ -f $f ] && \
openssl enc -aes-256-cbc -salt -in $f \
    -out $f.enc -pass file:/tmp/passwd ; done

Для расшифровки отдельно взятых файлов используем следующую команду:

    $ openssl enc -d -aes-256-cbc -salt \
    -in файл.enc -out filename \
    -pass file:/path/to/passwd

Для шифрования целого каталога проще, конечно, воспользоваться такой конструкцией:

$ tar c каталог | openssl enc -aes-256-cbc -e \
> secret.tar.enc

OpenSSL удобно использовать для генерирования паролей:

$ openssl rand 8 -base64
O0Hqtv9l0sY=

А сгенерировать хеш для записи в /etc/passwd можно так:

# openssl passwd -1 my-secret-pass
$1$WA7AVhQL$y9VaGwseiKRLSGoJg21TP0

Кстати, кодирование в base64 может пригодиться для отправки файлов, если двоичная передача данных не поддерживается:

$ tar -c каталог | gzip -9 | openssl enc \
-base64 > text-message.txt

Возможность генерирования случайных данных можно использовать для создания фиктивных MAC-адресов:

$ openssl rand -hex 6 | \
sed 's/\(..\)/\1:/g; s/.$//'
f2:9e:56:fd:5a:93