jot (FreeBSD)
seq (Linux)
две простые утилиты для работы с последовательностями, прекрасная альтернатива замены for в shell скриптах.

Работать с ними очень просто:
SEQ=`jot 10 1 10`
for i in $SEQ
echo $i
done

Получим
1
2
3
4
5
6
7
8
9
10

А если вот так, то
SEQ=`jot 10 10 1`
10
9
8
7
6
5
4
3
2
1

Первая[10] цифра, это число цифр, которые нужно напечатать, вторая[1] – первый элемент, третья[10] – последний элемент. Т.е. jot сам построит последовательность из 10 цифр с равным шагом, чтобы пройтись от 1 до 10.

seq в Linux несколько проще, seq FIRST INCREMENT LAST

Иногда нужно подсмотреть окружение запущенного процесса, для этого есть несколько способов и утилит.
Linux:
cat /proc/PID/environ

Solaris:
pargs -e PID

FreeBSD:
mount -t procfs none /proc
ps ewwwp PID

Общий подход для всех UNIX систем:
gcore PID
получим core файл
string core.PID

По умолчанию yum в CentOS имеет достаточно куцый список репозиториев, с которыми он может работать. В них нет многих нужных пакетов, например мне потребовался nrpe, и yum его не нашел. Ставить из исходников при наличии yum – лишняя головная боль через какое-то время. Так что добавляем RPMForge!
Все очень просто. Идем на сайт https://rpmrepo.org/RPMforge и видим в документации

Для CentOS5 нужна вот эта версия http://packages.sw.be/rpmforge-release/rpmforge-release-0.3.6-1.el5.rf.i386.rpm (для x64 http://packages.sw.be/rpmforge-release/rpmforge-release-0.3.6-1.el5.rf.x86_64.rpm)
Выполняем команды и получаем установленный репозиторий. Можно пользоваться!

Что сеть полна ботов, пытающихся сделать что-то нехорошее, уже давно не новость. И увидеть в логах попытки отправить письмо через ваш SMTP, попытки пройти аутентификацию у вас на сайте или попытки подобрать пароль от FTP/SSH – обычное дело. Ради интереса решил натравить geoip на логи неудачных попыток входа по ssh.
Смотрите что получилось:

Вот такой конструкции пропарсил лог и получил список числа попыток войти/страны откуда эта попытка была произведена

Получился любопытный график

Т.е. США виноваты не только в мировом кризисе =)

Asterisk Manager Interface (AMI) – интерфейс, позволяющей клиентам подключаться к работающему asterisk, и через набор заданных функций получать данные о его работе или менять его настройки. Звучит хорошо?

На практике все несколько тяжелее. Для включения AMI нужно настроить asterisk/manager.conf

После чего можно сделать вот так

вводим команды и после несколько раз нажимаем enter

получаем ответ

дальше можно сделать вот так

и получить ответ

Если посмотреть список доступных функций, то открывается массу возможностей по управлению asterisk в реальном времени без редактирования конфигов. Дело за малым – найти библиотеку для работы с AMI, чтобы самому не писать обвязку для работы с TCP сокетами и т.п. Библиотек много, кажется есть почти для каждого популярного языка программирования. Я выбрал для PHP asterisk-php-api, можно скачать с google code. Напишем пример для статистики по очередям

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

WARNING[18373]: app_queue.c:2705 try_calling: The device state of this queue member, SIP/612, is still ‘Not in Use’ when it probably should not be!
Please check UPGRADE.txt for correct configuration settings.
Какое-то время наблюдал вот такое сообщение в логах и не мог понять почему не меняется статус для очередей когда смотришь queue show queuename.

Решить проблему все время как-то руки не доходили, да и locate UPGRADE.txt на gentoo сервере ничего не показывал. Вчера решил побороть проблему, оказалось все просто, если прочитать UPGRADE.txt (взял из исходников с сайта asterisk)

* Queues depend on the channel driver reporting the proper state
for each member of the queue. To get proper signalling on
queue members that use the SIP channel driver, you need to
enable a call limit (could be set to a high value so it
is not put into action) and also make sure that both inbound
and outbound calls are accounted for.

Example:
[general]
limitonpeer = yes
[peername]
type=friend
call-limit=10

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

Каждое сетевое соединение потребляет определенный объем памяти ядра, чем больше соединений, тем больше памяти нужно и тем ближе момент, когда в списке процессов можно будет увидеть статус zoneli (zonelimit). Но обо всем по порядку.

Для каждого TCP соединения ядро выделяет два буфера, буфер на прием и буфер на отправку данных. Эти значения задаются параметрами net.inet.tcp.sendspace и net.inet.tcp.recvspace. По умолчанию они равны 32 и 64 килобайтам. Т.е. чтобы поддерживать одно соединение нужно 96К памяти ядра. Это конечно не совсем так, так как кроме этих буферов используются и другие ресурсы, с другой стороны не факт, что соединению потребуется буфер целиком. В man tuning для определения потребляемой памяти для TCP соединений придерживаются правила “x2″, т.е. увеличивают вдвое расчетные параметры. Я бы сказал что при значениях буферов 32К и 64К двойной запас прочности излишен, лучше домножить на 1,5.
В результате получаем, что для обслуживания 1000 одновременных соединений требуется
1000 * (64 + 32) * 1,5 = 144000К памяти.
А сколько памяти разрешено ядру выделять под TCP соединения в данный момент? Это определяет параметр ядра kern.ipc.nmbclusters. Для буферов приема и отправки ядро используется mbuf, число которых как раз определяется nmbclusters, каждый кластер занимает 2К, т.е. чтобы определить сколько nmbclusters нужно для обслуживания 1000 TCP соединений, нужно поделить полученный объем необходимой памяти на размер кластера
144000 / 2 = 72000
Т.е. нужно установить kern.ipc.nmbclusters = 72000
Если мы ошиблись и кластеров не хватит, то процесс который их не получит перейдет в состояние zonelimit (в top будет видно zomeli). Чтобы проверить текущее потребление mbuf можно воспользоваться netstat
# netstat -m
…
512/418/930/25600 mbuf clusters in use (current/cache/total/max)
…

В iptables мне очень не хватало таблиц PF!

block in quick on $if inet proto tcp from to $me port 80

Как красиво выглядит такое правило в PF по сравнению с ужасным аналогом в iptables:

$IPTABLES -A INPUT -i eth1 -p tcp -m tcp -s 192.168.0.1 -d $me –dport 80 -j DROP
$IPTABLES -A INPUT -i eth1 -p tcp -m tcp -s 192.168.4.1 -d $me –dport 80 -j DROP
$IPTABLES -A INPUT -i eth1 -p tcp -m tcp -s 10.10.0.1 -d $me –dport 80 -j DROP
$IPTABLES -A INPUT -i eth1 -p tcp -m tcp -s 10.0.1.1 -d $me –dport 80 -j DROP
…

И так далее. Более того, проверка каждого нового правила – это лишняя нагрузка на процессор, так что если у вас несколько тысяч правил, то не удивляйтесь idle процессора, равного 0 процентов… В общем такое положение дел в iptables меня долго отпугивало от него. Но не так давно я нашел проект http://ipset.netfilter.org/ , который дает весь функционал таблиц PF и даже больше!

Настройка вся ведется на gentoo, так что мне не пришлось патчить ядро и пересобирать его:

emerge ipset
modprob ipt_set

Теперь у нас есть и работает ipset. В ipset нет таблиц, а есть set различных типов. Типы позволяют задавать ip адреса из определенной подсети (ipmap тип), связки ip адресов с MAC адресами (macipmap), порты из заданного диапазона (portmap), набор ip адресов или сетей (iphash, nethash), разные комбинации этих set-ов, или даже хранить ip адреса в set только определенное время (iptree). Более подробно советую посмотреть man ipset(8).

Для нашей задачи подходит тип iphash. Создаем set с именем badip, и смотрим его содержимое:

# ipset -N badip iphash
# ipset -L badip
Name: test
Type: iphash
References: 0
Default binding:
Header: hashsize: 1024 probes: 8 resize: 50
Members:
Bindings:

Добавляем несколько ip в badip и смотрим содержимое set

# ipset -A badip 192.168.0.1
# ipset -A badip 10.10.0.1
# ipset -L test
Name: test
Type: iphash
References: 0
Default binding:
Header: hashsize: 1024 probes: 8 resize: 50
Members:
192.168.0.1
10.10.0.1
Bindings:

Удаляем ip из set

# ipset -D badip 192.168.0.1
# ipset -L test
Name: test
Type: iphash
References: 0
Default binding:
Header: hashsize: 1024 probes: 8 resize: 50
Members:
10.10.0.1
Bindings:

Проверяем, есть ли ip в set

# ipset -T badip 10.10.0.1
10.10.0.1 is in set test.

Удаляем все ip из set

# ipset -F badip

Удаляем сам set

# ipset -X badip

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

$IPTABLES -A INPUT -i eth1 -p tcp -m tcp -d $me -m set –set badip src –dport 80 -j DROP

Т.е. мы подключили модуль set (-m set), потом указали какой set использовать (–set badip src). src – это флаг, который показывает какие ip сравнивать с set, src или dst . Если нужно проверить и src и dst, то флаг задается так src,dst. В результате использования ipset можно упросить и само написание правил и быстродействие фаервола в целом.

OpenVPN – замечательный продукт сообщества OpenSource, позволяющий легки и просто организовать VPN.
Забудьте про PPTP, L2TP и IpSec, для работы OpenVPN нужен только UDP или TCP порт, что значительно упрощает развертывания VPN для клиентов за NAT.

В короткой статье я опишу, как организовать соединение точка-точка при помощи OpenVPN.
Пакет OpenVPN доступен на всех популярных платформах ОС, процесс установки просто и не требует отдельного описания. Единственное, что нужно упомянуть, для Linux нужна поддержка tun устройств в ядре.
Перейдем сразу к настройке. У нас есть два компьютера, который необходимо соединить туннелем. Пусть первый зовется mars (192.168.0.100) и moon (192.168.100.10). Считаем, что маршрутизация между этими компьютерами есть.
Для mars мы создадим vpn подключение с адресом 10.0.0.1, для moon 10.0.0.2.

root@mars:~# openvpn –remote 192.168.100.10 –dev tun0 \
–ifconfig 10.0.0.1 10.0.0.2
root@moon:~# openvpn –remote 192.168.0.100 –dev tun0 \
–ifconfig 10.0.0.2 10.0.0.1

После какого-то времени должно появится сообщение

Wed Sep 29 15:33:05 2009 Initialization Sequence Completed

Что означает, что туннель был создан. Опция remote задает адрес, к которому будет подключаться openvpn и с которого он готов принимать трафик, dev указывает какой интерфейс использовать для туннеля, последняя опция ifconfig определяет IP адреса для создаваемого туннеля, первый для своей стороны, второй для удаленной.
Теперь можно открыть два новых терминала на mars и moon и проверить, работает ли туннель

user@mars:~$ ping 10.0.0.2
PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data.
64 bytes from 10.0.0.2: icmp_seq=1 ttl=64 time=0.421 ms
…
user@moon:~$ ping 10.0.0.1
PING 10.0.0.1 (10.0.0.1) 56(84) bytes of data.
64 bytes from 10.0.0.1: icmp_seq=1 ttl=64 time=0.360 ms
…

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

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

Просто нажмите Сtrl+z для приостановки текущего процесса. Процесс будет ожидать вашего возврат. Тем временем вы вернетесь в терминал из которого запустили gzip и сможете запустить любую команду.

Если вы хотите вернуться к процессу архивирования (или любому другому приостановленному процессу), то нужно только набрать команду
fg %1
которая активирует первый приостановленный процесс. Если процесс всего один параметр %1 необязателен.

Чтобы получить список всех приостановленных процессов нужно запустить команду
jobs.