Skip to content


DigitalOcean что-то радикально улучшил 18-го сентября

Вот такая картинка на графиках одного из моих дроплетов на DigitalOcean-е заставила крепко задуматься на тему "а что это у меня там отвалилось"?

Резкое снижение нагрузки на процессор после 18-го сентября

Снижение нагрузки на процессор (недельный график)

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

Зато спустя пару дней новостная рассылка кроме прочего содержала вот такую строчку:

Added capacity for 192 GB Standard Droplets in the following regions AMS3, BLR1, FRA1, LON1, NYC3, NYC1, SGP1, SFO2, and TOR1

Что, конечно, не может не радовать. Ведь за те же деньги я получил приличный запас по CPU.

Кстати, если вдруг по какой-то причине вы еще не клиент DigitalOcean, то самое время им стать – при регистрации в октябре по этой ссылке в честь Hacktoberfest-а Вы получите $100 бонусных денег на ваш аккаунт.

Размещено в категории Разное. Теги: .

Отслеживание изменений в файлах с помощью tripwire


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

Запустить всё это хозяйство можно с помощью следующих простых шагов.

  1. Создаём ключи. Каждый из них будет защищен своим паролем:

    1. twadmin --generate-keys --local-keyfile /etc/tripwire/$(hostname)-local.key
    2. twadmin --generate-keys --site-keyfile /etc/tripwire/site.key
  2. Создаем зашифрованный конфигурационный файл /etc/tripwire/tw.cfg на основе plaintext файла /etc/tripwire/twcfg.txt, для этого потребуется ввести пароль от site-ключа.

    1. twadmin --create-cfgfile --cfgfile /etc/tripwire/tw.cfg --site-keyfile /etc/tripwire/site.key /etc/tripwire/twcfg.txt
  3. Правим под свои потребности файл /etc/tripwire/twpol.txt, в котором указано какие файлы и как мониторить, и конвертируем его в зашифрованный файл /etc/tripwire/tw.pol:

    1. twadmin --create-polfile --polfile /etc/tripwire/tw.pol --site-keyfile /etc/tripwire/site.key /etc/tripwire/twpol.txt

    Здесь опять потребуется ввести пароль от site-ключа.

  4. Инициализируем базу данных, чтобы tripwire просканировал файловую систему и сохранил исходную информацию об упомянутых в policy-файле объектах:
    1. tripwire --init
    2.  
    3. Please enter your local passphrase:
    4. Parsing policy file: /etc/tripwire/tw.pol
    5. Generating the database...
    6. *** Processing Unix File System ***
    7. Wrote database file: /var/lib/tripwire/srv.host.name.twd
    8. The database was successfully generated.

    Потребуется ввести пароль от local-ключа.

Затем через cron будет вызываться проверялка (по умолчанию раз в сутки) и присылать на email список изменений. Отчеты об изменениях записываются в директорию /var/lib/tripwire/report (для CentOS, в других дистрибутивах может быть иначе). Если после просмотра отчета мы не обнаружили ничего подозрительного и хотим "согласиться" с изменениями, то запускаем такой скриптик:

  1. #!/bin/bash
  2.  
  3. WD=/var/lib/tripwire/report
  4. tripwire --update --accept-all -r `echo $WD/$(ls -tr $WD | tail -n 1)` -P xxxXXXxxx

где xxxXXXxxx – пароль от local-ключа.

Если потребовалось внести изменения в policy-файл, то после этого нужно сделать

  1. tripwire --update-policy /etc/tripwire/twpol.txt

и далее ввести пароли от site и local ключей.

Если после этого ругается вот так:

  1. ### Error: Policy Update Changed Object.
  2. ### An object has been changed since the database was last updated.

то последнюю команду можно заменить на

  1. tripwire --update-policy --secure-mode low /etc/tripwire/twpol.txt

Размещено в категории *nix, Howto. Теги: , .

Календарная мистика

cal 1-ое сентября 2018 года считает пятницей:

А если запустить под sudo, то 1-ое сентября уже суббота:

WTF?

UPDATE спустя 12 часов:

Оказывается, у меня в .bashrc был вот такой алиас, который был добавлен еще лет 10 назад:

alias cal='cal -m3'

И после того, как я его убрал, cal стал показывать всё правильно.

Мораль: заглядывайте иногда в свой .bashrc :)

Размещено в категории Разное.

О режимах bonding-а в linux

Дано:
- есть сервер srv00 в одном датацентре, подключен к сети на скорости 1Gbit/sec
- есть сервер srv01 в другом датацентре, подключен к сети на скорости 10Gbit/sec, используется bonding.
Проблема: аномально низкая скорость:

  1. [avz@srv00 ~]$ iperf3 -c srv01.my.zone
  2. Connecting to host srv01.my.zone, port 5201
  3. [  4] local xx.xxx.xx.xx port 27108 connected to yyy.yy.yy.yyy port 5201
  4. [ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
  5. [  4]   0.00-1.00   sec  5.21 MBytes  43.7 Mbits/sec   40    130 KBytes
  6. [  4]   1.00-2.00   sec  2.45 MBytes  20.6 Mbits/sec    5   79.8 KBytes
  7. [  4]   2.00-3.00   sec  2.02 MBytes  17.0 Mbits/sec    3   52.8 KBytes
  8. [  4]   3.00-4.00   sec  1.96 MBytes  16.4 Mbits/sec    8   51.3 KBytes
  9. [  4]   4.00-5.00   sec  1.96 MBytes  16.4 Mbits/sec    0   68.4 KBytes
  10. [  4]   5.00-6.00   sec  1.53 MBytes  12.8 Mbits/sec    1   65.6 KBytes
  11. [  4]   6.00-7.00   sec  1.96 MBytes  16.4 Mbits/sec    3   67.0 KBytes
  12. [  4]   7.00-8.00   sec  1.53 MBytes  12.8 Mbits/sec    2   47.1 KBytes
  13. [  4]   8.00-9.00   sec  1.47 MBytes  12.3 Mbits/sec    3   51.3 KBytes
  14. [  4]   9.00-10.00  sec  1004 KBytes  8.22 Mbits/sec   14   31.4 KBytes
  15. - - - - - - - - - - - - - - - - - - - - - - - - -
  16. [ ID] Interval           Transfer     Bandwidth       Retr
  17. [  4]   0.00-10.00  sec  21.1 MBytes  17.7 Mbits/sec   79             sender
  18. [  4]   0.00-10.00  sec  20.1 MBytes  16.9 Mbits/sec                  receiver

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

Смотрим текущий режим:

  1. [root@srv01 ]# cat /proc/net/bonding/bond0
  2. Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)
  3.  
  4. Bonding Mode: load balancing (round-robin)
  5. MII Status: up
  6. MII Polling Interval (ms): 1  
  7. Up Delay (ms): 0
  8. Down Delay (ms): 0
  9.  
  10. Slave Interface: enp2s0f0
  11. MII Status: up
  12. Speed: 10000 Mbps
  13. Duplex: full
  14. Link Failure Count: 0
  15. Permanent HW addr: 00:01:02:a3:78:c0
  16. Slave queue ID: 0
  17.  
  18. Slave Interface: enp2s0f1
  19. MII Status: up
  20. Speed: 10000 Mbps
  21. Duplex: full
  22. Link Failure Count: 0
  23. Permanent HW addr: 00:01:02:a3:78:c4
  24. Slave queue ID: 0
  25.  
  26. [root@srv01 ~]# ethtool bond0 | grep Speed
  27.         Speed: 20000Mb/s

В конфиге

  1. [root@srv01 ]# grep BONDING /etc/sysconfig/network-scripts/ifcfg-Bond_connection_1
  2. BONDING_OPTS="miimon=1 updelay=0 downdelay=0 mode=balance-rr"
  3. BONDING_MASTER="yes"

Начинаем экспериментировать, меняем режим с balance-rr на active-backup:

  1. [root@srv01 ]# grep BONDING /etc/sysconfig/network-scripts/ifcfg-Bond_connection_1
  2. BONDING_OPTS="miimon=1 updelay=0 downdelay=0 mode=active-backup"
  3. BONDING_MASTER="yes"

Рестартим сеть, смотрим:

  1. [root@srv01 ~]# cat /proc/net/bonding/bond0
  2. Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)
  3.  
  4. Bonding Mode: fault-tolerance (active-backup)
  5. Primary Slave: None
  6. Currently Active Slave: enp2s0f0
  7. MII Status: up
  8. MII Polling Interval (ms): 1
  9. Up Delay (ms): 0
  10. Down Delay (ms): 0
  11.  
  12. Slave Interface: enp2s0f0
  13. MII Status: up
  14. Speed: 10000 Mbps
  15. Duplex: full
  16. Link Failure Count: 0
  17. Permanent HW addr: 00:01:02:a3:78:c0
  18. Slave queue ID: 0
  19.  
  20. Slave Interface: enp2s0f1
  21. MII Status: up
  22. Speed: 10000 Mbps
  23. Duplex: full
  24. Link Failure Count: 0
  25. Permanent HW addr: 00:01:02:a3:78:c4
  26. Slave queue ID: 0

Примечательно, что скорость по данным ethtool изменилась с 20-ти на 10Гбит/сек:

  1. [root@srv01 ~]# ethtool bond0 | grep Speed
  2.         Speed: 10000Mb/s

что и логично, поскольку в этом режиме всегда активен только один сетевой интерфейс, а второй – "на подхвате".

Тестируем скорость еще раз:

  1. [avz@srv00 ~]$ iperf3 -c srv01.my.zone
  2. Connecting to host srv01.my.zone, port 5201
  3. [  4] local xx.xxx.xx.xx port 27108 connected to yyy.yy.yy.yyy port 5201
  4. [ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
  5. [  4]   0.00-1.00   sec  94.5 MBytes   793 Mbits/sec    0   4.94 MBytes      
  6. [  4]   1.00-2.00   sec   114 MBytes   954 Mbits/sec    0   4.94 MBytes      
  7. [  4]   2.00-3.00   sec   112 MBytes   944 Mbits/sec    0   4.94 MBytes      
  8. [  4]   3.00-4.00   sec   110 MBytes   923 Mbits/sec    8   2.56 MBytes      
  9. [  4]   4.00-5.00   sec  81.2 MBytes   682 Mbits/sec    0   2.71 MBytes      
  10. [  4]   5.00-6.00   sec  86.2 MBytes   724 Mbits/sec    0   2.83 MBytes      
  11. [  4]   6.00-7.00   sec  88.8 MBytes   744 Mbits/sec    0   2.92 MBytes      
  12. [  4]   7.00-8.00   sec  92.5 MBytes   776 Mbits/sec    0   2.99 MBytes      
  13. [  4]   8.00-9.00   sec  92.5 MBytes   776 Mbits/sec    0   3.04 MBytes      
  14. [  4]   9.00-10.00  sec  95.0 MBytes   797 Mbits/sec    0   3.07 MBytes      
  15. - - - - - - - - - - - - - - - - - - - - - - - - -
  16. [ ID] Interval           Transfer     Bandwidth       Retr
  17. [  4]   0.00-10.00  sec   967 MBytes   811 Mbits/sec    8             sender
  18. [  4]   0.00-10.00  sec   959 MBytes   804 Mbits/sec                  receiver
  19.  
  20. iperf Done.

Красота, в десятки раз лучше.

Отсюда следует вывод – на стороне коммутатора режим был сконфигурен неправильно (не соответствовал конфигурации со стороны сервера).
Из официальной доки по linux-bonding-у:

The active-backup, balance-tlb and balance-alb modes do not require any specific configuration of the switch.

The balance-rr, balance-xor and broadcast modes generally require that the switch have the appropriate ports grouped together. The nomenclature for such a group differs between switches, it may be called an "etherchannel" (as in the Cisco example, above), a "trunk group" or some other similar variation. For these modes, each switch will also have its own configuration options for the switch's transmit policy to the bond. Typical choices include XOR of either the MAC or IP addresses. The transmit policy of the two peers does not need to match. For these three modes, the bonding mode really selects a transmit policy for an EtherChannel group; all three will interoperate with another EtherChannel group.

Размещено в категории *nix. Теги: .