удаление собственных тем
Форум — Linux-org-ru
Кого из модеров лучше попросить, чтобы снёс некоторые мои старые темы, к тому же не имеющие заметной ценности?
Кого из модеров лучше попросить, чтобы снёс некоторые мои старые темы, к тому же не имеющие заметной ценности?
Прежде с головой хватало бесплатных сертификатов от китайского WoSign, который прекрасно позволяет использовать в сертификате любое удобное CN + некоторое количество произвольных альтернативных имён (Subject Alternative Name) в том же домене. К сожалению, WoSign с некоторых пор внедрил у себя странные чёрные списки, не допускающие выдачу сертификатов для доменов, если они являются какими-то популярными словами (предполагается, что таким образом они «защищают» крупные бренды / торговые марки).
В общем, нужен сертификат на несколько субдоменов одного домена за минимальную цену. Но УЦ поголовно выпускают сертификаты или только с CN, или предлагают более дорогой мультидоменный (что по сути и не нужно), SAN за доплату или wildcard сертификат. Пока никаких вариантов дешевле ~3 тысяч рублей так и не нашёл.
Let's Encrypt и подобную шляпу не предлагать.
Исследователи показали, что информацию о батареи мобильного устройства можно использовать для слежки за интернет-пользователями.
Новый способ слежения
Исследователи обнаружили возможность отслеживания онлайн-активности пользователя по информации о его батареи, которую сайты и веб-приложения могут получать посредством интерфейса программирования 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...
На кой чёрт нужно выдумывать какую-то специальную версию сайта ради продления заряда аккумулятора на несколько процентов, в том время как на эффективность и экономичность клиентского ПО многие давно уже положили болт? Почему некоторые разработчики сначала придумывают что-то якобы пользовательско-ориентированное, а более дальновидным коллегам потом приходится объяснять всему миру, чем грозит использование их поделок? Среднестатистический пользователь настолько деградировал, что сам не способен принять решение как и когда ему выполнять свои задачи?
Есть потребность регулярно синхронизировать файлы с одной системы на другую (однонаправленно), но вместе с тем хотелось бы на системе-реципиенте раскладывать получаемые файлы в несколько ином порядке, в частности, на основе хэшей (в идеале - от содержимого), с целью более-менее равномерного распределения нагрузки на носители.
Первоначально подумал, что в простейшем случае можно обойтись традиционным rsync: в файловой системе реципиента создавать некую структуру из симлинков, указывающих на необходимые конечные места хранения, однако rsync всё ещё не умеет подобным образом использовать симлинки, а пилить такую фичу самостоятельно как-то не хочется. Но, предположим, что будет использовано какое-то другое решение для собственно синхронизации, которое может писать по симлинкам.
При быстром гуглинге выяснилось, что файловая система GlusterFS умеет распределять данные по физическим томам на основе хэша от имени файла, но такой расклад вполне годится.
Возможно, есть ещё какие-то годные решения, о которых я не знаю. Решение должно быть абсолютно прозрачно для существующего ПО, работающего с файлами. В качестве хранилища используются только локальные диски.
Допустим, что слейв хост упал. После перезапуска системы видим следующее
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;Пытаюсь вникнуть в бакуловскую модель разграничения доступа.
Допустим, есть некий 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.
Проблема, аналогичная уже как-то обсуждавшейся 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 дел не имел, настройки сделал по одной из существовавших конфигураций.
Посоветуйте недорогой PCI-E SATA контроллер с 3-4 внутренними портами на замену встроенного. На RAID пофиг.
Хотел автоматизировать генерацию CSR, но столкнулся с расхождениями в поведении OpenSSL.
Если делать
openssl req -newkey rsa:1024 -nodes -keyout host.key -out host.csrЕсли же сделать
openssl req -newkey rsa:1024 -nodes -subj "/O=company/CN=host" -keyout host.key -out host.csrcompany,CN=host, а не каждое на своём месте.Сам OpenSSL в текстовом дампе показывает одинаковые subject в обоих случаях
Subject: O=company, CN=hostНужно поменять дефолтный umask на 0002. Пишу в /etc/ssh/sshd_config
ForceCommand internal-sftp -u 0002В чём логика?
Есть хост-система с несколькими виртуалками. На ней подняты два бриджа:
Всё бы ничего, но есть необходимость доступа с любых машин к почтовому серверу, который включён в 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 - ума не приложу.
Есть такая система биллинга
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Есть сервер с несколькими винтами 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) с такими же винтами, там проблем не наблюдается.
Столкнулся с одним вялотекущим багом в 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!
Какие наиболее грамотные способы сделать сабж? Есть сервер, на котором крутятся виртуалочки, некоторым нужно выделять отдельные адреса. NAT реализован на хост-системе через iptables. Вышестоящий роутер ничего не знает про адреса, поэтому периодически шлёт ARP запросы.
Читал про
arp -Ds <external-address> <interface> pubip route add local <address>/<mask> table local dev <interface>ip route add nat <external-address> via <internal-address>
ip rule add nat <external-address> from <internal-address>Пока запилил 4 способом - через ebtables.
ebtables -t nat -A PREROUTING -p arp --arp-opcode request --arp-ip-dst <external-address> -j arpreply --arpreply-mac <mac>Есть PV гость с vcpus = 4, захотел увеличить до 6 (всего 16 аппаратных ядер). Запускаю, проходит совсем немного времени и гость наглухо виснет. В консольке только сообщение
sched: RT throttling activatedhrtimer: interrupt took ********* nsЕсть один почтовый сервер с Dovecot, работающим со следющим форматом хранилища
mail_location = mbox:/var/mail/%d/%u:INBOX=/var/mail/%d/%nНеобходимо сконвертировать существующие ящики в
mail_location = maildir:/var/mail/%d/%n/MaildirЕсть ли способы?
Имеется 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Есть ли какие-то актуальные актуальные решения (не обязательно open source)? Нужно ПО для управления списками рассылки с user-friendly веб-интерфейсом, где можно было бы управлять списками и получателями + разграничение доступа к управлению списками, backend таким образом не особенно важен. В идеале что-нибудь по юзабельности на уровне WebAdmin for MDaemon, но не за такую дикую цену.
Поставил fail2ban, чтобы блокировать всяких вредных ботов-скрэйперов, периодически набегающих на сайт. Но из-за довольно невысокого порога срабатывания возникают случаи блокировки легитимных поисковых ботов (хотя и анализируются только запросы к наиболее часто запрашиваемым ботами разделам сайта). Хотелось бы прописать их в белый список, но fail2ban имеет только унылый ignoreip, куда ручками надо забивать конкретные хосты/подсети.
В то же время, есть уже готовый список конкретных хостов поисковых ботов, собираемый отдельным анализатором, хотелось бы его задействовать без постоянной переконфигурации fail2ban. Исключать легитимных ботов просто по user agent - не вариант, вредители легко могут прикинуться кем угодно.
| следующие → |