16 апреля 2016, 20:09
После обновления до последней версии vagrant и образа для ОС Debian 8 столкнулся с проблемой:
|
|
There was an error when attempting to rsync a synced folder. Please inspect the error message below for more info. Host path: /cygdrive/e/Work/vagrant/deb8/ Guest path: /vagrant Command: rsync --verbose --archive --delete -z --copy-links --chmod=ugo=rwX --no-perms --no-owner --no-group --rsync-path sudo rsync -e ssh -p 2222 -o StrictHostKeyChecking=no -o IdentitiesOnly=true -o UserKnownHostsFile=/dev/null -i 'E:/Work/vagrant/deb8/.vagrant/machines/default/virtualbox/private_key' --exclude .vagrant/ /cygdrive/e/Work/vagrant/deb8/ vagrant@127.0.0.1:/vagrant Error: Warning: Permanently added '[127.0.0.1]:2222' (ECDSA) to the list of known hosts. dup() in/out/err failed rsync: connection unexpectedly closed (0 bytes received so far) [sender] rsync error: error in rsync protocol data stream (code 12) at io.c(226) [sender=3.1.2] |
Проблема была в том, что у меня установлены cygwin64 и mingw64, но для первого не был установлен пакет openssh. В итоге при запуске виртуальной машины rsync из cygwin64 пытался использовать ssh из mingw64, а это не работает из-за не совместимости окружений. После установки пакета openssh для cygwin64 проблема ушла.
Отдельно есть проблема в самом vagrant 1.8, точнее используются не поддерживаемые ключи для ssh, необходимо обновить файл helpers.rb, подробнее в описании ошибки.
15 октября 2015, 4:33
Для реализации резервного копирования СУБД MySQL при помощи LVM есть отличный инструмент – mylvmbackup. Но в нем есть один недостаток – это “из коробки” не реализован механизм автоудаления старых архивов, решил это поправить, в связи с чем в 2012 году родился hook который отрабатывает после успешного создания резервной копии и удаляет все старые архивы, но оставляет, указанное в настройках, количество недавно созданных.
Для ОС Ubuntu или Debian копируем файл в папку /usr/share/mylvmbackup и даем ему права на исполнение.
Код ниже:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 |
#!/bin/bash # Old backup remove script for mylvmbackup # v 1.0 # # BPATH - path where backup files stored # RTNF - retention files, how many backup files will NOT be removed BPATH="/var/cache/mylvmbackup/backup/" RTNF=3 function delete_old_files { find $1 -type f -name "backup-*_mysql.tar.gz" \ | sort | head -n -$2 \ | xargs --no-run-if-empty rm -f if [ $? -ne 0 ];then echo "Something wrong..." exit 1 fi } if [ -d "$BPATH" ]; then delete_old_files $BPATH $RTNF else echo "Cant access backup directory." exit 1 fi exit 0 |
20 сентября 2015, 2:33
Для корректной настройки работы bridge в linux необходимо обязательно прописывать в sysctl следующие параметры:
|
|
net.bridge.bridge-nf-call-arptables = 0 net.bridge.bridge-nf-call-ip6tables = 0 net.bridge.bridge-nf-call-iptables = 0 |
Данные параметры отвечают за обработку сетевого трафика бриджа тем или иным ПО для контроля трафика. Есть несколько проблем с этим, для примера sysctl при загрузке выполняется в тот момент, когда еще не создался bridge и в итоге параметры не применяются и приходится выполнять sysctl -p в ручном режиме или через cron.
Более подробно можно почитать по ссылке.
7 августа 2015, 16:12
Столкнулся с проблемой, после добавления 2-х нод на базе Centos 6 в систему мониторинга zabbix значительно выросли значения для zabbix busy poller и zabbix busy unreachable poller статистик. Для примера график:
Включив DebugLevel=4 на сервере увидел в логах ошибки:
|
|
13371:20150807:142850.682 Item [cento6node:system.cpu.util[,system]] error: Get value from agent failed: ZBX_TCP_READ() failed: [4] Interrupted system call 13357:20150807:142851.695 Item [cento6node:system.cpu.util[,user]] error: Get value from agent failed: ZBX_TCP_READ() failed: [4] Interrupted system call 13352:20150807:142852.258 Item [cento6node:vtundcheck] error: Get value from agent failed: ZBX_TCP_READ() failed: [4] Interrupted system call 13363:20150807:142853.446 Item [cento6node:system.localtime] error: Get value from agent failed: ZBX_TCP_READ() failed: [4] Interrupted system call |
При этом судя по дампу сетевого трафика zabbix агент просто не успевал ответить за 20 секунд, а это значение выставлено у меня в timeout. При этом запросы простейшие, такой ситуации просто не должно возникать.
Подозрение пало на проблемы в работе DNS серверов, либо какой-то внутренний баг в zabbix agent. При проверке выяснилось, что DNS сервера работают нормально, отвечают быстро, но проблема была решена добавлением записи со ссылкой на zabbix server в /etc/hosts.
Как альтернативу можно использовать вариант с заменой FQDN имени Zabbix сервера в конфигурационном файле агента на IP.
По факту у хостера видимо какое-то ограничение на количество запросов от клиента на получение IP для одного и того же домена. При этом сам zabbix агент делает тонну DNS запросов, по сути на каждый запрос на получение данных с него. Ждем когда закроют этот тикет, с 2011 года не закрыт.
22 июля 2015, 17:11
После добавления одного из серверов в мониторинг выяснилась странная проблема, а именно не работала простая проверка HTTPS порта в zabbix, то есть он все время выдавал информации что порт недоступен, хотя через браузер все открывалось корректно.
После анализа сетевого трафика всплыла следующая проблема:
|
|
63.893903 123.123.123.123 -> 123.123.123.124 SSL 208 Client Hello 63.895282 123.123.123.124 -> 123.123.123.123 TCP 66 443 > 43871 [ACK] Seq=1 Ack=143 Win=15616 Len=0 TSval=165771041 TSecr=1070936 63.905794 123.123.123.124 -> 123.123.123.123 TLSv1.2 1514 Alert (Level: Warning, Description: Unrecognized Name), Server Hello |
После чего SSL сессия обрывалась и zabbix не мог продолжить дальнейшую установку соединения.
Причиной оказался неправильно оформленный файл /etc/hosts, из-за чего apache не мог корректно определить FQDN и curl, который используется zabbix`ом для реализации http/https проверок, не мог корректно установить соединение.
В логе apache была следующая ошибка:
|
|
[Wed Jul 22 14:28:59 2015] [warn] RSA server certificate CommonName (CN) `test.domain.ru' does NOT match server name!? |
После внесения изменений в /etc/hosts и перезапуска сервера проблема ушла.
18 июня 2015, 0:34
Недавно переводил один старый сервер с debian 4 на debian 8.1, в ходе этой миграции возникла проблема с сервером nginx, а вернее с самописным клиентом, который подключался к нему по HTTPS. В логах проблема была выражена следующей строкой:
|
|
2015/06/16 02:56:04 [crit] 1196#0: *20 SSL_do_handshake() failed (SSL: error:14076102:SSL routines:SSL23_GET_CLIENT_HELLO:unsupported protocol) while SSL handshaking, client: xxx.xxx.xxx.xxx, server: 0.0.0.0:443 |
Причина проблемы – в настройках клиента явно указано, что требуется использовать протокол шифрования SSL3, но в пакете openssl его поддержку убрали. Для устранения проблемы – пришлось пересобрать пакет openssl БЕЗ конфигурационного ключа no-ssl3. В ближайшее время создам репозиторий, куда буду периодически выкладывать актуальную версию пакета.
17 мая 2015, 13:21
Полезный файл с описанием методики оптимизации настроек Linux сервера под высокие сетевые нагрузки.
Скачать (PDF, Неизвестный)
7 мая 2015, 22:21
Чтобы каждый раз не пересобирать модуль ixgbe создал DKMS пакет с версией 3.23.2.1 для Debian Linux. Возможно кому-то пригодиться, сам пакет доступен по ссылке. Если кому-то интересно как самостоятельно это сделать, то пишите в комментариях – оформлю краткую инструкцию в отдельной заметке.
Список поддерживаемых опций под катом.
Читать полностью ‘Dkms версия модуля ixgbe для Debian Linux’ »
5 мая 2015, 22:55
Рано или поздно перед любым владельцем сайта встает вопрос настройки HTTPS доступа.
Для этого необходимо купить или получить бесплатный сертификат от WoSign и настроить его в веб сервере сайта, ниже укажу пример конфигурации для Nginx.
Конфигурация SSL:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 |
ssl on; # SSLv3 и v2 нас не интересуют. ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_ciphers kEECDH+AES128:kEECDH:kEDH:-3DES:kRSA+AES128:kEDH+3DES:DES-CBC3-SHA:!RC4:!aNULL:!eNULL:!MD5:!EXPORT:!LOW:!SEED:!CAMELLIA:!IDEA:!PSK:!SRP:!SSLv2; # Указываем свои ssl_certificate /etc/nginx/ssl/bundle.crt; ssl_certificate_key /etc/nginx/ssl/key.key; # Создаем командой openssl dhparam -out dhparam.pem 4096 ssl_dhparam /etc/nginx/ssl/dhparam.pem; ssl_session_cache shared:SSL:10m; ssl_session_timeout 24h; ssl_prefer_server_ciphers on; # Включаем OCSP, версия nginx должна быть не ниже 1.3.7. # При проверке OCSP включается не сразу, а через 1-2 https запроса. ssl_stapling on; ssl_stapling_verify on; resolver 8.8.8.8 8.8.4.4 ipv6=off valid=300s; resolver_timeout 5s; # Это bundl файл с CA Chain сертификатами, подойдет тот что указан в ssl_certificate, # но без 1-го сертификата ssl_trusted_certificate /etc/nginx/ssl/ca_ocsp.crt; # Включаем HSTS, после этого скорее всего сайт получит A+ и браузеры всегда будут переходить на https, # даже если доступен http add_header Strict-Transport-Security "max-age=31536000; includeSubDomains"; |
Проверить корректность внесенных изменений можно на ssllabs.com, пример для этого сайта.
4 мая 2015, 16:57
Следующая ошибка с ключами при обновлении списка пакетов в debian 7:
|
|
W: There is no public key available for the following key IDs: 9D6D8F6BC857C906 W: There is no public key available for the following key IDs: 7638D0442B90D010 W: There is no public key available for the following key IDs: 7638D0442B90D010 |
Исправляется путем установки новой версии пакетов с ключами:
|
|
aptitude update; aptitude -y install debian-archive-keyring debian-keyring |
Аналогично устраняется проблема с ключами для репозитория cyconet.org:
|
|
wget -O - http://ftp.cyconet.org/debian/repo.key 2>/dev/null | apt-key add - |
