Архив рубрики: Полезное по Linux

Красноярский сайт о Linux. Все, что связанно с Linux., мои личные записки и опыт. А так как я проживаю в Красноярске, очень многие Linux статьи имеют прямое отношение к этому городу.

Контроль свободного места на сервере с помощью скрипта

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

 

#!/bin/bash

# Ящики на которые шлем отчет
mails="admin1@itroad.ru admin2@itroad.ru"

# Создаем массив из рейтинга, наполняя одну переменную разделами, а другую процентом заполнения (убирая с конца символ процента).
F=(echo `df -h | awk '{print $6}' | grep /`)
S=(echo `df -h | awk '{print $5}' | grep % | rev | cut -c 2,3,4 | rev`)

# Считаем кол-во строк с разделами, и наполняем этим числом переменную счетчика.
N=`df -h | awk '{print $5}' | grep -c %`

# Чистим\создаем файл отправки перед циклом.
cat /dev/null >/tmp/df_tmp

# Начинаем перебор массива с 1 элемента до N элемента.
i=1
while [ $i -lt $N ]
do
          # Внутри цикла проверяем первую переменную с процентами, не превысило ли значение 96%
          if [ ${S[$i]} -ge 96 ] <code class="shell plain">&gt;</code><code class="shell plain">/dev/null</code> <code class="shell plain">2&gt;&amp;1</code>; then
                  
                  # Если заполнение раздела 96% или больше, пишем об этом на почту.
                  echo "На разделе ${F[$i]} заканчивается место, занято уже ${S[$i]}%" &gt;&gt;/tmp/df_tmp
          
          # Если процент заполнения всех разделов меньше 96% - выходим.
          fi

# Добавляем к счетчику единицу.
i=$[$i+1]
done

# Если файл не пустой, шлем его на почту, если пустой, выходим.
test -s /tmp/df_tmp &amp;&amp; mutt -s "На разделах сервера `hostname` заканчивается свободное место" $mails &lt;/tmp/df_tmp

exit 0

Вообще, такие вот задачи, и задачи подобные, должны решаться с помощью систем мониторинга — но мне неимоверно лень заниматься.

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

Хотя я конечно же не прав — системы мониторинга, наше все!

Вечный бан fail2ban версия 2.0

fail2ban

Какое то время назад, я написал пост — «Защита от перебора паролей SSH. Автоматический вечный бан на основе списков fail2ban» в котором запилил скрипт по вечной блокировке наиболее активных перебирателей паролей к ssh.

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

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

#!/bin/bash

# Ящики на которые шлем отчет
mails="admin1@itroad.ru.ru admin2@itroad.ru"

# Генерируем список IP которые попадали в бан.
rm -rf /tmp/fail2banlog && mkdir /tmp/fail2banlog && cp `ls /var/log/fail2ban*` /tmp/fail2banlog && cd /tmp/fail2banlog && ls *.gz >/dev/null 2>&1 | while read i; do gzip -d $i >/dev/null 2>&1; done; cat fail2ban.log* | grep Ban | awk '{print $7}' >/tmp/fail2banlog/send_0

# Наполняем переменную из этого списка
fil="`cat /tmp/fail2banlog/send_0`"

# Проверяем все IP на наличие из в блоке
for w in $fil
do
      vuurmuur_script --list-blocked | grep $w >/dev/null 2>&1
   
      # Если такого ip нет в бан листе, то передаем его дальше на проверку, если есть, просто пропускаем.
      if [ $? -ne 0 ]; then
      echo $w >>/tmp/fail2banlog/send_1
      fi
done
# Составляем топ 10 адресов
cat /tmp/fail2banlog/send_1 | sort -nr | uniq -c | sort -nr | head -n10 >/tmp/fail2banlog/send
echo >>/tmp/fail2banlog/send

# Создаем массив из рейтинга, наполняя одну переменную кол-вом совпадений, а другую ip который совпал
F=(echo `cat /tmp/fail2banlog/send |awk '{print $1}'`)
S=(echo `cat /tmp/fail2banlog/send |awk '{print $2}'`)

# Начинаем перебор массива с 1 элемента до 10 элемента (в рейтинге ведь у нас всего 10 элементов).
i=1
while [ $i -lt 10 ]
do

    # Внутри цикла проверяем первую переменную с кол-вом попыток перебора, не превысило ли шест кол-во попыток.
    if [ ${F[$i]} -ge 6 ] >/dev/null 2>&1; then
    
    # Если попыток подбора 6 или больше смотрим бан лист и проверяем, нет ли в нем уже этого ip.
    # Если нет, то баним
    vuurmuur_script --block ${S[$i]} >/dev/null 2>&1
    echo "Ip ${S[$i]} добавлен в вечный бан." >>/tmp/fail2banlog/send
    
    # Если попыток меньше 6, ничего не делаем и выходим.
    else echo >/dev/null 2>&1
    fi

# Добавляем к счетчику единицу.
i=$[$i+1]
done

# Обновляем правила файрвола
vuurmuur_script --reload >/dev/null 2>&1

# Отсылаемый на почту рейтинг ip пытающихся подобрать пароль к SSH.
mutt -s "fail2ban" $mails </tmp/fail2banlog/send

В качестве файрвола, я использую vuurmuur, но переписать скрипт на использование чистого iptables или hosts.deny нет никакой проблемы.

В итоге изменений в скрипте, мы получаем ровненький столбик ip адресов, причем только тех, которых еще не в бане, т.е. в моем случае, в списке будут адреса появившиеся до 6 раз (сделавшие до 6 попыток перебора).

К тому же, в процессе изменения, скрипт был существенно упрощен.

По видимому следующим изменением скрипта будет указание сервиса, из за которого ip попал в бан. Я вообще стараюсь не делать на одном сервере более одного сервиса, но в последнее время таких серверов становится все больше и больше. Уже появляется asterisk + apache и прочие связки, в которых fail2ban работает на несколько сервисов.

Динамический диапазон памяти в Proxmox (Automatically allocate within range)

Proxmox VE

Сегодня я хотел бы поговорить о возможности выделения динамического объема памяти виртуальным машинам в Proxmox.

Когда я только начинал пользоваться Proxmox, идея с динамическим объемом, а тем более с возможностью приоритезации машин, при выдаче когда, память кончилась.

Но тогда, 3-5 лет назад, этот опыт оказался неудачным. Машины с динамической памятью, совершенно непредсказуемо начинали тупить и я отказался от использования этой возможности.

Недавно я узнал, редхатом запилина служба, которая решала еще одну проблему динамической памяти, а именно передачу объема фактически занятого объема памяти из гостевой системы гипервизору. Вся суть описана у них в wiki тут https://pve.proxmox.com/wiki/Dynamic_Memory_Management

Я решил снова вернутся к данному режиму, и посмотреть что изменилось, ведь времени прошло не мало.

На одном из продакшн серверов были обновлены драйвера из набора 0.1-100 и установлена служба из wiki выше.

Как показали тесты, и работа сервера в боевом режиме, на самом деле мало что изменилось. Точно так же появились тормоза, хоть и не такие как раньше, но тем не менее. Гостевая 2008 винда нагружала процессор до 30%, причем все 30% заняты были ядром, т.е. обработкой аппаратного обеспечения. Особенно если оставить нижнюю границу по умолчанию в 32Mb.

Так к стати вообще нельзя делать, хоть в KVM это не оговаривается, а в Proxmox тем более, по правильному нижняя граница памяти, это минимально потребляем объем сервера. Т.е. если он в обычном состояние потребляет 4 гига, то лучше нижнюю границ сделать 5 гигабайт, а верхнюю уже по желанию.

На фоне всех моих мытарств, хотелось бы задать вопрос общественности. Кто нибудь пользовался этим режимом, и какой был эффект?

KSM в Proxmox настройка и особенности

В какое то время наступает осознание того, что виртуальных машин нужно больше, а аппаратных ресурсов недостаточно. В таком случае можно пойти на небольшую хитрость — можно использовать KSM.
KSM (Kernel Samepage Merging) — технология позволяющая уменьшить расходование памяти за счет нахождения одинаковых страниц в анонимной памяти и их последующего объединения.

Механизм работает следующим образом, модуль ядра ksmd, с определенным интервалом запускает сканирование памяти. Если он находит в памяти одинаковые страницы, он объединяет их в одну, а лишние копии удаляет. Эта страница помечается как «copy-on-write», так что ядро будет автоматически разделять их снова, как только один процесс изменит данные. Таким образом процессы могут использовать идентичные блоки памяти. KSM доступно в QEMU начиная с версии 0.12. Linux ядро поддерживает эту технологию с версии 2.6.32.

Положительные стороны KSM:

KSM позволяет избежать своппирования за счет объединения одинаковых страниц;

Возможность избыточного выделения памяти машинам, больше чем есть физически;

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

Недостатки и особенности KSM:

Нет смысла использовать KSM если все гости умещаются в памяти;

В процессе работы KSM расходует процессорные ресурсы
если ресурсы CPU являются узким местом, лучше отказаться от KSM;

Чтобы начать использовать KSM, нужно собрать ядро с параметром CONFIG_KSM=y (ядро Proxmox уже собрано с этой опцией) и включить KSM в системе через /sys/kernel/mm/ksm.

echo 1 > /sys/kernel/mm/ksm/run

Для управления и сбором статистики доступны следующие ключи:

full_scans — количество выполненных операций сканирования
pages_shared — количество используемых общих, объединенных страниц
pages_sharing — количество потенциально сохраненных страниц
pages_to_scan — количесто страниц которое будет просканировано перед принудительной паузой
pages_unshared — количество «претендентов» на объединение
pages_volatile — количество страниц которые меняются слишком часто
run — ключ запуска KSM
sleep_millisecs — пауза между сканированиями памяти

Таким образом на работу KSMd можно влиять через pages_to_scan и sleep_millisecs. Например увеличив pages_to_scan и уменьшив sleep_millisecs можно сделать KSMd более агрессивным, но вместе с тем и увеличится нагрузка на процессора.

Эффективность ksmd определяется значениями pages_sharing и pages_unshared. Чем больше значение pages_sharing тем эффективнее использование KSM и наоборот.
Могу добавить что в своих случаях удалось сэкономить до 11GB памяти на серверах с 48GB RAM. Результаты экспериментов Red Hat еще больше поражают: 52 виртуальных Windows XP с 1GB памяти, могут работать на компьютере с 16GB оперативной памяти.

Памятка по монтированию NFS

На сервере (адрес сервера 192.168.11.1) правим /etc/exports добавляя шару, разрешенные адреса для подключения и параметры экспорта:

/home/work 192.168.21.0/24(rw,sync,no_subtree_check)

После чего делаем service nfs-kernel-server reload или exportfs -rf

На клиенте правим /etc/fstab добавляя запись монтирования, с указанием заранее созданной точки монтирования (в примере f2p):

192.168.11.1:/home/work /mnt/f2p nfs4 ro,user 0 0

После чего перемонтируем шары с выводом mount -a -v

Вот так вот все просто.