Хочу купить ИБП, понятное дело, сразу смотрю на APC, т.к. там с софтом под Линукс всё в порядке (по крайней мере было). Но APC — это немного дороговато, хотя и терпимо, но, всё же, хотелось бы узнать, нет ли чего подешевле, но тоже с линуксовым софтом. Хочу, чтобы демон умел рапортовать основную статистику (вольтаж, потребляемая мощность, заряд), а также умел выполнять произвольные хуки при пропадании/появлении напряжения.

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

Советуйте.

Столкнулся с вот такой презамечательной фичей реализации L2-мостов в Линуксе.

Вкратце: при добавлении нового интерфейса в бридж MAC бриджа может пересчитаться, что приведёт к недоступности хоста, если он должен быть досягаем через IP, назначенный бриджу. Конкретно в моём случае происходит затирание ARP-таблицы, и хост не видится из сети, пока из хоста что-либо не пропинговать, чтобы получить MAC шлюза.

Как наиболее разумный вариант решения проблемы предлагают такое:

We could go back to using a VETH device for the host, and using the bond MAC address, and stop putting an IP address on the bridge. We then would need to assign a random MAC to the bond itself (which now seems to work).

Я правильно понимаю, что предлагают на хосте создать pair из двух veth'ов, один воткнуть в мост (повесив на другой IP бриджа, а самому бриджу IP не назначать)? Не хочется костылять самопальным скриптом такое, а ifcfg-*, похоже, не поддерживает создание пары veth. Писать самому?

И вообще, как тогда правильно организовывать бриджи на гипервизорах?

Вот вернулся я из отпуска, а за моё отсутствие СисОпс успели наломать дров в продакшене. Я потратил 2 дня чтобы по логам приложений (то бишь по косвенным уликам) восстановить картину преступления.

А вот есть какие-то тулы для централизованного логгирования шеллов (с датой и временем)?

Конечно, можно слушать .bash_history отовсюду и лить их в 1 файл, но вдруг есть какой-то тул, который помимо этого даёт ещё какую-то киллер фичу.

Всем привет. Настраиваю домен AD внутри сети и решил пробросить к нему 53 порт. Но что то не работает, nmap пишет 53/udp open|filtered domain. Пробрасываю через mikrotik. Вот думаю что провайдер заблочил, подскажите, как проверить ?

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

libOpenCL.so -> libamdocl64.so
libOpenCL.so.1 -> libamdocl64.so
libOpenCL.so.1.0.0 -> libamdocl64.so

Пытаюсь так:

ln -s libamdocl64.so libOpenCL.so{.1,.1.0.0}

ln -s libamdocl64.so {libOpenCL.so,libOpenCL.1,libOpenCL.1.0.0}

Подскажите пожалуйста, это возможно? Если да, то как? Спасибо.

Пытаюсь читать доки по OpenStack и не могу найти в них прямого ответа на вопрос: как именно обеспечивается взаимодействие между KVM и возможностями предоставляемыми OpenStack (Swift, Cinder, Neutron). Насколько я понимаю, интерфейс у OpenStack - ReST поверх HTTP; устройства ввода-вывода, эмулируемые KVM, обращаются непосредственно к нему? Или (например, для Swift или Cinder) на хосте через FUSE монтируются некие сетевые шары, к которым потом KVM обращается как к обычным файлам?

Тем, кто посоветовал «поставь OpenStack и посмотри» - большое спасибо.

iptables -A INPUT -p tcp -m tcp --dport 22     -m recent --name ssh_delay --rcheck --seconds 300 -j DROP
iptables -A INPUT -p tcp -m tcp --dport 22     -m recent --name ssh_delay --set                  -j DROP

Вроде простое правило задержки в 5 минут для всех новых подключений на 22 порт. Iptables легко реализуемое 2 правилами. А как тоже самое сделать средствами ipfw? Неужели без костылей не обойтись? Знатоки ipfw подскажите пожалуйста решение.

p.s. Устанавливать iptables не предлагать.

Доступны видео и слайды докладов со встречи для разработчиков и пользователей Linux-контейнеров, которая прошла 19 сентября в Москве.

• Живая миграция контейнеров: плюсы, минусы, подводные камни — Павел Емельянов (разработчик OpenVZ/CRIU)
• Управление памятью контейнеров в проекте OpenVZ — Владимир Давыдов (разработчик OpenVZ)
• LibCT и контейнеры на уровне приложений — Александр Бурлука (разработчик OpenVZ/CRIU)
• Использование контейнерных технологий в DevOps — Дмитрий Лазаренко (Jelastic)
• Опыт использования виртуальных контейнеров в работе сервис-провайдера — Константин Анисимов (Русоникс)
• CRIU: ускорение запуска PHP в CloudLinux OS — Руслан Купреев (CloudLinux)
• Развёртывание приложений Docker в контейнерах Virtuozzo — Павел Тихомиров (разработчик OpenVZ)
• Проблема фрагментации виртуальных дисков и способы её решения — Дмитрий Монахов (разработчик OpenVZ)

Для координациии предстоящих встреч подобной тематики организована группа «Moscow Containers meetup». Добавляйтесь, если не хотите пропустить.

>>> Посмотреть все видео