LINUX.ORG.RU

Сообщения frozen_twilight

 

удаление собственных тем

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

 ,

frozen_twilight
()

Дешёвые SSL-сертификаты с Subject Alternative Name

Прежде с головой хватало бесплатных сертификатов от китайского WoSign, который прекрасно позволяет использовать в сертификате любое удобное CN + некоторое количество произвольных альтернативных имён (Subject Alternative Name) в том же домене. К сожалению, WoSign с некоторых пор внедрил у себя странные чёрные списки, не допускающие выдачу сертификатов для доменов, если они являются какими-то популярными словами (предполагается, что таким образом они «защищают» крупные бренды / торговые марки).

В общем, нужен сертификат на несколько субдоменов одного домена за минимальную цену. Но УЦ поголовно выпускают сертификаты или только с CN, или предлагают более дорогой мультидоменный (что по сути и не нужно), SAN за доплату или wildcard сертификат. Пока никаких вариантов дешевле ~3 тысяч рублей так и не нашёл.

Let's Encrypt и подобную шляпу не предлагать.

 ,

frozen_twilight
()

Обратная сторона сомнительных технологий

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

Новый способ слежения

Исследователи обнаружили возможность отслеживания онлайн-активности пользователя по информации о его батареи, которую сайты и веб-приложения могут получать посредством интерфейса программирования Battery Status API. Они успешно опробовали возможность такого отслеживания в Mozilla Firefox в среде Linux.

Battery Status API

Battery Status API — это элемент HTML5. Он позволяет узнавать уровень заряда батареи и ее текущую рабочую емкость для того, чтобы переводить интернет-пользователя на более облегченную версию веб-сайта.

Например, во время веб-серфинга заряд батареи снизился до 5%. Узнав об этом, сайт отключит ряд своих компонентов для того, чтобы снизить скорость расхода батареи. При этом разработчики этого API не позаботились об уведомлении пользователя или о том, чтобы получать его согласие, так как не усмотрели в работе интерфейса каких-либо способных навредить брешей.

По состоянию на июнь 2015 г. три браузера поддерживали Battery Status API — Firefox, Chrome и Opera. Примечательно, что еще в 2012 г. в ходе создания HTML5, разработчики Mozilla и Tor Browser обратили свое внимание на возможные проблемы с безопасностью вследствие текущей имплементации API. Тем не менее, их дискуссии не были услышаны.

Как это работает

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

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

Как решить проблему

Исследователи выяснили, что в Linux передача информации о емкости батареи через API осуществляется с двойной точностью. Например, сайт получает число 0.9301929625425652. Это число и является своего рода уникальным отпечатком, по которому пользователя можно «ловить» и на других сайтах. По мнению исследователей, повысить защиту пользователей можно было бы простым округлением числа. Для сравнения, в Windows, Mac OS X и Android интерфейс передает число с двумя знаками после запятой (например, 0.32).

Авторы находки опубликовали в интернете доклад (PDF) с результатами свой работы. В нем говорится, что разработчики Firefox были уведомлены о проблеме в Linux-версии браузера. Они уже выпустили соответствующее обновление.

http://www.cnews.ru/news/top/2016-08-04_uroven_zaryada_batarei_prisposobili_d...

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

 , , , ,

frozen_twilight
()

синхронизация файлов с перераспределением между физическими хранилищами

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

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

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

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

 , ,

frozen_twilight
()

восстановление MySQL репликации при повреждении relay лога

Допустим, что слейв хост упал. После перезапуска системы видим следующее

Last_Errno: 1594
Last_Error: Relay log read failure: Could not parse relay log event entry. The possible reasons are: the master's binary log is corrupted (you can check this by running 'mysqlbinlog' on the binary log), the slave's relay log is corrupted (you can check this by running 'mysqlbinlog' on the relay log), a network problem, or a bug in the master's or slave's MySQL code. If you want to check the master's binary log or slave's relay log, you will be able to know their names by issuing 'SHOW SLAVE STATUS' on this slave.

Можно ли считать процедуру

STOP SLAVE;
RESET SLAVE;
CHANGE MASTER TO MASTER_LOG_FILE={@Relay_Master_Log_File}, MASTER_LOG_POS={@Exec_Master_Log_Pos};
START SLAVE;
действительно эффективным решением, не допускающим рассинхронизацию?

 ,

frozen_twilight
()

Bacula: разграничение доступа к хранилищу

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

Допустим, есть некий storage daemon, на который бэкапятся, с одной стороны, данные с «доверенных» file daemon'ов под управлением «доверенного» же director'а, с другой стороны, есть необходимость предоставить возможность «посторонней» системе director + file daemon также складывать данные на него. Насколько я могу понять, единственное, что предлагает storage daemon - это ограничить саму возможность подключения к нему director'а. Но что делать с доступом к конкретным device? Ведь никто, по идее, не мешает «постороннему» director'у запросить доступ к любому device.

Документация эту тему освещает крайне лаконично

The Director resource specifies the Name of the Director which is permitted to use the services of the Storage daemon. There may be multiple Director resources.
...
If Monitor is set to no (default), this director will have full access to this Storage daemon.

 , ,

frozen_twilight
()

ошибки передачи у GRE туннеля с IPsec

Проблема, аналогичная уже как-то обсуждавшейся gre-tunnel - ошибки на интерфейсе

Есть GRE L2 (gretap) туннель между дата-центрами, сам по себе работающий без нареканий. Нужно добавить шифрование туннелируемого траффика, для чего в Debian были установлены ipsec-tools и racoon. В /etc/ipsec-tools.conf прописано:

spdadd 1.1.1.1 2.2.2.2 gre -P out ipsec
   esp/tunnel/1.1.1.1[4500]-2.2.2.2[4500]/require;
spdadd 2.2.2.2 1.1.1.1 gre -P in ipsec
   esp/tunnel/2.2.2.2[4500]-1.1.1.1[4500]/require;
На второй стороне, соответственно, наоборот.

В /etc/racoon/racoon.conf:

listen {
    isakmp 1.1.1.1 [500];
    isakmp_natt 1.1.1.1 [4500];
    strict_address;
}

remote anonymous {
    exchange_mode main;
    generate_policy on;
    dpd_delay 20;
    proposal {
        encryption_algorithm aes;
        hash_algorithm md5;
        authentication_method pre_shared_key;
        dh_group modp1024;
    }
}

sainfo anonymous
{
    encryption_algorithm     aes;
    authentication_algorithm hmac_sha1;
    compression_algorithm    deflate;
    pfs_group                modp1024;
}

После включения IPsec туннель на первый взгляд работает, но начинаются проблемы с пакетами разного размера (нормально проходят только совсем небольшие), и на gretap интерфейсах с обоих сторон массово сыпятся TX errors.

gretap0   Link encap:Ethernet  HWaddr 11:22:33:44:55:66
          UP BROADCAST RUNNING MULTICAST  MTU:1462  Metric:1
          RX packets:43300 errors:0 dropped:0 overruns:0 frame:0
          TX packets:39415 errors:10148 dropped:0 overruns:0 carrier:0

Прежде с IPsec дел не имел, настройки сделал по одной из существовавших конфигураций.

 , ,

frozen_twilight
()

выбор SATA контроллера

Посоветуйте недорогой PCI-E SATA контроллер с 3-4 внутренними портами на замену встроенного. На RAID пофиг.

 ,

frozen_twilight
()

странное поведение OpenSSL при создании CSR

Хотел автоматизировать генерацию CSR, но столкнулся с расхождениями в поведении OpenSSL.

Если делать

openssl req -newkey rsa:1024 -nodes -keyout host.key -out host.csr
и вводить данные вручную (только organization и common name, остальное поля пустые), то CSR и сертификат получаются корректными.

Если же сделать

openssl req -newkey rsa:1024 -nodes -subj "/O=company/CN=host" -keyout host.key -out host.csr
то при использовании полученного сертификата в целевом ПО обнаруживается, что сертификат имеет некорректный CN. Если посмотреть TLS сессию сниффером, то заметно, что в каком-то из полей стоит значение company,CN=host, а не каждое на своём месте.

Сам OpenSSL в текстовом дампе показывает одинаковые subject в обоих случаях

Subject: O=company, CN=host

 ,

frozen_twilight
()

OpenSSH и umask

Нужно поменять дефолтный umask на 0002. Пишу в /etc/ssh/sshd_config

ForceCommand internal-sftp -u 0002
и нифига, залитые файлы всё равно создаются с 0644.

В чём логика?

 , ,

frozen_twilight
()

подружить бриджи и iptables NAT

Есть хост-система с несколькими виртуалками. На ней подняты два бриджа:

  • в br0 включён внешний интерфейс (eth0) и виртуальные интерфейсы виртуалок, которые напрямую используют внешние адреса;
  • в br1 включён dummy интерфейс (host-only network) и виртуальные интерфейсы виртуалок, которые используют внутренние адреса (в пределах рассматриваемой хост-системы), а доступ извне к их сервисам и доступ к Интернет обеспечивается через DNAT+SNAT в iptables.

Всё бы ничего, но есть необходимость доступа с любых машин к почтовому серверу, который включён в br1, а необходимые порты (25 и др.) в него с целью экономии проброшены с IP-адреса, который одновременно используется хост-системой. MX запись доменов, соответственно, указывает на внешний адрес хост-системы.

В зависимости от состояния net.bridge.bridge-nf-call-iptables наблюдаются следующие ситуации. Для наглядности привожу краткие логи из tcpdump, слушавшего виртуальные интерфейсы проверяемых машин. Внешний адрес хост-системы обозначен как host-system, vm-on-br0 - произвольная виртуалка, включённая в br0, vm-on-br1 - произвольная виртуалка, включённая в br1, mailserver-vm - внутренний адрес почтового сервера.

При net.bridge.bridge-nf-call-iptables = 1

Попытка подключиться с vm-on-br0 к host-system: подключение на первый взгляд устанавливается, но не работает - траффик не ходит (сразу же обрывается?).

IP vm-on-br0.34978 > host-system.25: Flags [S], seq 1849458227, win 14600, options [mss 1460,sackOK,TS val 368978 ecr 0,nop,wscale 4], length 0
IP host-system.25 > vm-on-br0.34978: Flags [S.], seq 1081576981, ack 1849458228, win 14480, options [mss 1460,sackOK,TS val 205318642 ecr 368978,nop,wscale 4], length 0
IP vm-on-br0.34978 > host-system.25: Flags [.], ack 1, win 913, options [nop,nop,TS val 368978 ecr 205318642], length 0
IP vm-on-br0.34978 > host-system.25: Flags [P.], seq 1:2, ack 1, win 913, options [nop,nop,TS val 369195 ecr 205318642], length 1
IP host-system.25 > vm-on-br0.34978: Flags [R], seq 1081576982, win 0, length 0

Попытка подключиться с vm-on-br1 к host-system: подключение устанавливается.

IP vm-on-br1.57407 > host-system.25: Flags [S], seq 385890268, win 14600, options [mss 1460,sackOK,TS val 205342014 ecr 0,nop,wscale 4], length 0
IP host-system.25 > vm-on-br1.57407: Flags [S.], seq 1331471692, ack 385890269, win 14480, options [mss 1460,sackOK,TS val 205348051 ecr 205342014,nop,wscale 4], length 0
IP vm-on-br1.57407 > host-system.25: Flags [.], ack 1, win 913, options [nop,nop,TS val 205342014 ecr 205348051], length 0
IP host-system.25 > vm-on-br1.57407: Flags [P.], seq 1:20, ack 1, win 905, options [nop,nop,TS val 205348063 ecr 205342014], length 19
IP vm-on-br1.57407 > host-system.25: Flags [.], ack 20, win 913, options [nop,nop,TS val 205342025 ecr 205348063], length 0
IP vm-on-br1.57407 > host-system.25: Flags [F.], seq 1, ack 20, win 913, options [nop,nop,TS val 205342602 ecr 205348063], length 0
IP host-system.25 > vm-on-br1.57407: Flags [F.], seq 20, ack 2, win 905, options [nop,nop,TS val 205348640 ecr 205342602], length 0
IP vm-on-br1.57407 > host-system.25: Flags [.], ack 21, win 913, options [nop,nop,TS val 205342602 ecr 205348640], length 0

При net.bridge.bridge-nf-call-iptables = 0

Попытка подключиться с vm-on-br0 к host-system: подключение устанавливается.

IP vm-on-br0.34992 > host-system.25: Flags [S], seq 328034242, win 14600, options [mss 1460,sackOK,TS val 432621 ecr 0,nop,wscale 4], length 0
IP host-system.25 > vm-on-br0.34992: Flags [S.], seq 225042229, ack 328034243, win 14480, options [mss 1460,sackOK,TS val 205382285 ecr 432621,nop,wscale 4], length 0
IP vm-on-br0.34992 > host-system.25: Flags [.], ack 1, win 913, options [nop,nop,TS val 432621 ecr 205382285], length 0
IP host-system.25 > vm-on-br0.34992: Flags [P.], seq 1:20, ack 1, win 905, options [nop,nop,TS val 205382285 ecr 432621], length 19
IP vm-on-br0.34992 > host-system.25: Flags [.], ack 20, win 913, options [nop,nop,TS val 432621 ecr 205382285], length 0
IP vm-on-br0.34992 > host-system.25: Flags [F.], seq 1, ack 20, win 913, options [nop,nop,TS val 432800 ecr 205382285], length 0
IP host-system.25 > vm-on-br0.34992: Flags [F.], seq 20, ack 2, win 905, options [nop,nop,TS val 205382464 ecr 432800], length 0
IP vm-on-br0.34992 > host-system.25: Flags [.], ack 21, win 913, options [nop,nop,TS val 432800 ecr 205382464], length 0

Попытка подключиться с vm-on-br1 к host-system: подключение не устанавливается - ответы от хоста приходят в обход NAT, в итоге имеем connection timed out.

IP vm-on-br1.57408 > host-system.25: Flags [S], seq 3460236042, win 14600, options [mss 1460,sackOK,TS val 205385318 ecr 0,nop,wscale 4], length 0
IP mailserver-vm.25 > vm-on-br1.57408: Flags [S.], seq 3875201270, ack 3460236043, win 14480, options [mss 1460,sackOK,TS val 205391356 ecr 205385318,nop,wscale 4], length 0
IP vm-on-br1.57408 > mailserver-vm.25: Flags [R], seq 3460236043, win 0, length 0
IP vm-on-br1.57408 > host-system.25: Flags [S], seq 3460236042, win 14600, options [mss 1460,sackOK,TS val 205385568 ecr 0,nop,wscale 4], length 0
IP mailserver-vm.25 > vm-on-br1.57408: Flags [S.], seq 3890788609, ack 3460236043, win 14480, options [mss 1460,sackOK,TS val 205391605 ecr 205385568,nop,wscale 4], length 0
IP vm-on-br1.57408 > mailserver-vm.25: Flags [R], seq 3460236043, win 0, length 0
IP vm-on-br1.57408 > host-system.25: Flags [S], seq 3460236042, win 14600, options [mss 1460,sackOK,TS val 205386069 ecr 0,nop,wscale 4], length 0
IP mailserver-vm.25 > vm-on-br1.57408: Flags [S.], seq 3922100458, ack 3460236043, win 14480, options [mss 1460,sackOK,TS val 205392106 ecr 205386069,nop,wscale 4], length 0
IP vm-on-br1.57408 > mailserver-vm.25: Flags [R], seq 3460236043, win 0, length 0
IP vm-on-br1.57408 > host-system.25: Flags [S], seq 3460236042, win 14600, options [mss 1460,sackOK,TS val 205387072 ecr 0,nop,wscale 4], length 0
IP mailserver-vm.25 > vm-on-br1.57408: Flags [S.], seq 3984788496, ack 3460236043, win 14480, options [mss 1460,sackOK,TS val 205393109 ecr 205387072,nop,wscale 4], length 0
IP vm-on-br1.57408 > mailserver-vm.25: Flags [R], seq 3460236043, win 0, length 0
IP vm-on-br1.57408 > host-system.25: Flags [S], seq 3460236042, win 14600, options [mss 1460,sackOK,TS val 205389076 ecr 0,nop,wscale 4], length 0
IP mailserver-vm.25 > vm-on-br1.57408: Flags [S.], seq 4110038680, ack 3460236043, win 14480, options [mss 1460,sackOK,TS val 205395113 ecr 205389076,nop,wscale 4], length 0
IP vm-on-br1.57408 > mailserver-vm.25: Flags [R], seq 3460236043, win 0, length 0
IP vm-on-br1.57408 > host-system.25: Flags [S], seq 3460236042, win 14600, options [mss 1460,sackOK,TS val 205393088 ecr 0,nop,wscale 4], length 0
IP mailserver-vm.25 > vm-on-br1.57408: Flags [S.], seq 65821133, ack 3460236043, win 14480, options [mss 1460,sackOK,TS val 205399125 ecr 205393088,nop,wscale 4], length 0
IP vm-on-br1.57408 > mailserver-vm.25: Flags [R], seq 3460236043, win 0, length 0

Полагаю, нужно всё-таки курить конфигурацию с net.bridge.bridge-nf-call-iptables = 1 (кроме того, будет полезно для нужд фильтрации траффика всех виртуалок), но почему подключение в первом случае сразу же заканчивается TCP RST - ума не приложу.

 , ,

frozen_twilight
()

Бугурт от MikBiLL - как можно продавать подобное говно?

Есть такая система биллинга http://www.mikbill.ru/
Сайт на первый взгляд приятный, но отовсюду торчат косяки, что явно уже говорит об уровне авторов. То касается и документации.
Онлайн-демо: http://www.mikbill.ru/2-mikbill/6-demo.html
Пробная версия: http://wiki.mikbill.ru/download

Установщик под Ubuntu/Debian выглядит так

drwxr-xr-x  5 root root  4096 Авг 13  2013 etc
drwxr-xr-x  4 root root  4096 Авг 13  2013 init_scripts
-rwxr-xr-x  1 root root  3160 Янв 12  2011 install_all_ubuntu.sh
-rw-r--r--  1 root root 10240 Апр 21  2011 intal.tar
-rwxr-xr-x  1 root root  1361 Янв 12  2011 only_packets_install_debian.sh
-rwxr-xr-x  1 root root  1414 Янв 12  2011 only_packets_install_ubuntu.sh
-rwxr-xr-x  1 root root    75 Дек 23  2010 radiusd_debug.sh
# tar tvf intal.tar
-rwxr-xr-x root/root      1202 2011-04-21 14:40 instal_mikbill.sh
-rw-r--r-- root/root       588 2011-04-21 02:01 list
-rwxr-xr-x root/root       308 2011-04-20 21:55 MakeInstal.sh
-rwxr-xr-x root/root       159 2011-04-21 01:13 SetAvtoRun.sh

Из любопытства сначала запустил

# ./install_all_ubuntu.sh
./install_all_ubuntu.sh: 4: ./install_all_ubuntu.sh: sudo: not found
./install_all_ubuntu.sh: 5: ./install_all_ubuntu.sh: sudo: not found
./install_all_ubuntu.sh: 6: ./install_all_ubuntu.sh: sudo: not found
./install_all_ubuntu.sh: 10: ./install_all_ubuntu.sh: sudo: not found
./install_all_ubuntu.sh: 13: ./install_all_ubuntu.sh: sudo: not found
./install_all_ubuntu.sh: 14: ./install_all_ubuntu.sh: sudo: not found
./install_all_ubuntu.sh: 15: ./install_all_ubuntu.sh: sudo: not found
./install_all_ubuntu.sh: 16: ./install_all_ubuntu.sh: sudo: not found
./install_all_ubuntu.sh: 18: ./install_all_ubuntu.sh: sudo: not found
./install_all_ubuntu.sh: 20: ./install_all_ubuntu.sh: sudo: not found
./install_all_ubuntu.sh: 22: ./install_all_ubuntu.sh: sudo: not found
./install_all_ubuntu.sh: 24: ./install_all_ubuntu.sh: sudo: not found
libapache2-mod-php5 php5-cli php5-common php5-curl php5-gd php5-mysql
./install_all_ubuntu.sh: 27: ./install_all_ubuntu.sh: sudo: not found
./install_all_ubuntu.sh: 33: ./install_all_ubuntu.sh: sudo: not found
./install_all_ubuntu.sh: 35: ./install_all_ubuntu.sh: sudo: not found
./install_all_ubuntu.sh: 36: ./install_all_ubuntu.sh: sudo: not found
./install_all_ubuntu.sh: 37: ./install_all_ubuntu.sh: sudo: not found
./install_all_ubuntu.sh: 38: ./install_all_ubuntu.sh: sudo: not found
./install_all_ubuntu.sh: 39: ./install_all_ubuntu.sh: sudo: not found
./install_all_ubuntu.sh: 41: ./install_all_ubuntu.sh: sudo: not found
./install_all_ubuntu.sh: 43: ./install_all_ubuntu.sh: sudo: not found
./install_all_ubuntu.sh: 45: ./install_all_ubuntu.sh: sudo: not found
./install_all_ubuntu.sh: 47: ./install_all_ubuntu.sh: sudo: not found
./install_all_ubuntu.sh: 48: ./install_all_ubuntu.sh: sudo: not found
./install_all_ubuntu.sh: 49: ./install_all_ubuntu.sh: sudo: not found
./install_all_ubuntu.sh: 50: ./install_all_ubuntu.sh: sudo: not found
./install_all_ubuntu.sh: 51: ./install_all_ubuntu.sh: sudo: not found
./install_all_ubuntu.sh: 52: ./install_all_ubuntu.sh: sudo: not found
./install_all_ubuntu.sh: 53: ./install_all_ubuntu.sh: sudo: not found
и только потом поглядел в install_all_ubuntu.sh...

 ,

frozen_twilight
()

периодически отваливаются жёсткие диски

Есть сервер с несколькими винтами Seagate ST3000DM001 сомнительного качества, тем не менее поначалу работавший стабильно. На сервере крутится Citrix XenServer с десятком Windows виртуалок, которые распределены по 3 дискам (образы хранятся в LVM). В системе также имеется 4 диск, который довольно быстро вышел из строя с симптомами

183 Runtime_Bad_Block       0x0032   099   099   000    Old_age   Always       -       1
187 Reported_Uncorrect      0x0032   001   001   000    Old_age   Always       -       305
188 Command_Timeout         0x0032   100   100   000    Old_age   Always       -       65537
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       8
198 Offline_Uncorrectable   0x0010   100   100   000    Old_age   Offline      -       8
и сейчас никак не используется.

Периодически, раз в неделю-две-три, случается ситуация, когда все винты разом отваливаются. Хост-система при этом продолжает работать, хотя смонтированные разделы становятся недоступны - «Input/output error». По моим наблюдениям падения случаются не в то время, когда нагрузка на I/O является высокой, а скорее наоборот - в моменты наибольшего простоя (нерабочее время).

Если после случившегося обвала открыть консоль с логом, то там бесконечно бегут сообщения

end_request: I/O error, dev sd*, sector ******
в которых упоминаются все реально используемые диски и рандомные сектора.

После хард резета всё возвращается на места. Проблем с детектом дисков не наблюдается. У всех винтов по мере эксплуатации SMART аттрибут Runtime_Bad_Block стал ненулевым, но пока исчисляется единицами. Что выглядит откровенно подозрительно, так это соотношение Start_Stop_Count и Power-Off_Retract_Count

  4 Start_Stop_Count        0x0032   100   100   020    Old_age   Always       -       61
192 Power-Off_Retract_Count 0x0032   100   100   000    Old_age   Always       -       44

  4 Start_Stop_Count        0x0032   100   100   020    Old_age   Always       -       77
192 Power-Off_Retract_Count 0x0032   100   100   000    Old_age   Always       -       45
  4 Start_Stop_Count        0x0032   100   100   020    Old_age   Always       -       62
192 Power-Off_Retract_Count 0x0032   100   100   000    Old_age   Always       -       45

Фрагмент из /proc/kmsg, сохранённый в прошлый раз: http://pastebin.com/UNp8qtZU

В той же стойке работают ещё 2 сервера (Debian+Xen и Citrix XenServer) с такими же винтами, там проблем не наблюдается.

 , ,

frozen_twilight
()

баг в ядре «soft lockup - CPU#* stuck for ***s!»

Столкнулся с одним вялотекущим багом в Linux ядре, известным ещё с ядер 2.6, но до сих пор, как оказывается, не исправленным.

Есть хост-система с Xen, под ней работает N гостей (несколько PV и одна HVM). Некоторые машины (только PV) при условии использовании более одного ядра (vcpus) и некоторой интенсивной нагрузке (предполагаю, что прежде всего по части дискового или сетевого I/O) со временем впадают в ступор - не зависают совсем, но где-то около. После появления сообщения «BUG: soft lockup - CPU#* stuck for ***s!», впринципе, машину уже приходится жёстко перезагружать, поскольку она перестаёт отзываться.

Детальный лог http://pastebin.com/SXiFHnj4

Debian Wheezy. Ядро 3.2.51-1 x86_64 и на хосте, и под гостем.

Другие обсуждения по теме:
[Xen-devel] on starting HVM-domU whole system freezes with «soft lockup - CPU X stuck for XXs! [qemu-dm:...]»
Debian Bug report logs - #638172 / BUG: soft lockup - CPU#0 stuck for 61s!

 , , ,

frozen_twilight
()

прицепить внешний IP-адрес для NAT

Какие наиболее грамотные способы сделать сабж? Есть сервер, на котором крутятся виртуалочки, некоторым нужно выделять отдельные адреса. NAT реализован на хост-системе через iptables. Вышестоящий роутер ничего не знает про адреса, поэтому периодически шлёт ARP запросы.

Читал про

arp -Ds <external-address> <interface> pub
тут нужно включать net.ipv4.ip_nonlocal_bind, чтобы задавать произвольный адрес.
ip route add local <address>/<mask> table local dev <interface>
Полагаю, не сильно лучше обычного алиаса, разве что ifconfig не будет его показывать.
ip route add nat <external-address> via <internal-address>
ip rule add nat <external-address> from <internal-address>
Будет ли генерировать ARP ответы? Нужны ли оба?

Пока запилил 4 способом - через ebtables.

ebtables -t nat -A PREROUTING -p arp --arp-opcode request --arp-ip-dst <external-address> -j arpreply --arpreply-mac <mac>

 , ip-адреса,

frozen_twilight
()

Xen PV гость виснет при >4 vcpus

Есть PV гость с vcpus = 4, захотел увеличить до 6 (всего 16 аппаратных ядер). Запускаю, проходит совсем немного времени и гость наглухо виснет. В консольке только сообщение

sched: RT throttling activated
Иногда может ещё успеть появиться
hrtimer: interrupt took ********* ns
Debian 7, ядро дефолтное 3.2.0-4-amd64 и на хосте, и под гостем.

 , vcpus, ,

frozen_twilight
()

Dovecot: конвертация mbox+inbox в maildir

Есть один почтовый сервер с Dovecot, работающим со следющим форматом хранилища

mail_location = mbox:/var/mail/%d/%u:INBOX=/var/mail/%d/%n

Необходимо сконвертировать существующие ящики в

mail_location = maildir:/var/mail/%d/%n/Maildir
чтобы перенести на другой сервер.

Есть ли способы?

 , , ,

frozen_twilight
()

PHP FPM и логирование

Имеется php5-fpm под Debian. Сильно напрягает, что в глобальный error log пишутся PHP сообщения от всех имеющихся пулов. Если убрать error_log из /etc/php5/fpm/php-fpm.conf, это лишь меняет имя лога с /var/log/php5-fpm.log на /var/log/php-fpm.log.

Как сделать отдельный error log для каждого пула или отключить совсем (чтобы сообщения падали только в error log веб-сервера)? Выставлять catch_workers_output = no у пулов, я так понимаю, не выход, пропадёт всё.

Прописывал

php_admin_flag[log_errors] = on
php_admin_value[error_log] = /var/log/php-fpm/$pool_error.log
в конфигах пулов. Ничего не создаётся.

 ,

frozen_twilight
()

на чём организовать список рассылки с веб-мордой

Есть ли какие-то актуальные актуальные решения (не обязательно open source)? Нужно ПО для управления списками рассылки с user-friendly веб-интерфейсом, где можно было бы управлять списками и получателями + разграничение доступа к управлению списками, backend таким образом не особенно важен. В идеале что-нибудь по юзабельности на уровне WebAdmin for MDaemon, но не за такую дикую цену.

 списки рассылки

frozen_twilight
()

как прикрутить произвольный whitelist к fail2ban

Поставил fail2ban, чтобы блокировать всяких вредных ботов-скрэйперов, периодически набегающих на сайт. Но из-за довольно невысокого порога срабатывания возникают случаи блокировки легитимных поисковых ботов (хотя и анализируются только запросы к наиболее часто запрашиваемым ботами разделам сайта). Хотелось бы прописать их в белый список, но fail2ban имеет только унылый ignoreip, куда ручками надо забивать конкретные хосты/подсети.

В то же время, есть уже готовый список конкретных хостов поисковых ботов, собираемый отдельным анализатором, хотелось бы его задействовать без постоянной переконфигурации fail2ban. Исключать легитимных ботов просто по user agent - не вариант, вредители легко могут прикинуться кем угодно.

 , ,

frozen_twilight
()

RSS подписка на новые темы