Нещодавно дізнався про fallback правила для файервола PF. Але, це більше залежить від конкретної ОС. Серед тих ОС які підтримують PF і з якими я маю справу лише FreeBSD і Solaris мають такий функціонал.
Що ж таке fallback rules? Це альтернативний набір правил, який буде застосований, якщо основний конфіг буде мати помилку і pf не зможе його застосувати.
Нещодавно зіштовхнувся з тим, що сервіси якось коряво працюють під KVM. Вирішується це так
hw.vtnet.X.tso_disable="1"
hw.vtnet.tso_disable="1"
hw.vtnet.lro_disable="1"
hw.vtnet.X.lro_disable="1"
hw.vtnet.csum_disable="1"
hw.vtnet.X.csum_disable="1"
Це bug.
Нещодавно наштовхнувся на цікаву утиліту ldapctl, яка є тільки в OpenBSD і захотілося мати і собі такий функціонал. Як виявилося, все це доступно в модулі monitor.
Для початку треба перевірити, чи доступний модуль monitor:
$ slapd -VVV
...
monitor
...
Проблема проявляється на серверах Dell R430, а також всіх інших, які мають дисковий контроллер PERC H730P. Починаючи з версії FreeBSD 10.1 core team почала впроваджувати новий драйвер mfi замість старого mrsas, але не завжди це виправдано, що спричиняє FS freeze, chksum error,.. . До прикладу, даний контроллер погано працює саме з mfi і треба примусово використовувати mrsas. Щоб це зробити, додаємо у файл /boot/device.hints такий рядок
hw.mfi.mrsas_enable="1"
і перевантажуємо ОС. Ось витяг із man mfi(4)
A tunable is provided to adjust the mfi driver’s behaviour when attaching to a card. By default the driver will attach to all known cards with high probe priority. If the tunable hw.mfi.mrsas_enable is set to 1, then the driver will reduce its probe priority to allow mrsas to attach to the card instead of mfi.
Нещодавно зіштовхнувся із тим, що zabbix просигналізував, що змінився uptime у одного із juniper комутаторів. При цьому, все працює, ніяких провалів по сервісам чи трафіку. При запиті через SNMP до комутатора, останній, дійсно повертає uptime
$ snmpwalk -v 2c -c SecretCommunity XX.XX.XX.XX 1.3.6.1.2.1.1.3.0
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (105129517) 12 days, 4:01:35.17
Пошук в інтернеті дає відповідь, що переповнюються лічильники і замість “sysUpTimeInstance” треба використовувати “snmpEngineTime.0“. Дійсно, повертає правильне значення
$ snmpwalk -v 2c -c SecretCommunity XX.XX.XX.XX 1.3.6.1.6.3.10.2.1.3
SNMP-FRAMEWORK-MIB::snmpEngineTime.0 = INTEGER: 86950772 seconds
Дана помилка означає, що побилася база CRO (інформація про диски, шассі, експандери,…). Рекомендація від oracle
# pkg fix system/fault-management
# svcadm restart svc:/system/fmd:default
не завжди допомагає. Мені – ні разу не допомогло, тому довелося шукати інший шлях.
Якщо є файл /var/fm/fmd/topo/latest/cro_db.old то копіюємо в /var/fm/fmd/topo/latest/cro_db і пробуємо.
Якщо немає, тоді робимо symlink з іменем latest із найновішого (або будь-якого іншого) UUID в папці /var/fm/fmd/topo на latest.
Якщо раптом немає жодного UUID в /var/fm/fmd/topo немає, то можна скопіювати зі схожого серверу.
В самому кінці зробити
# svcadm restart svc:/system/fmd:default
Настроил квоты в postfix. Все ок. Превысил юзер лимит по почте заданной в Ldap новые письма не принимаются. НО встал вопрос как его об этом предупредить и оповестить заранее? В качестве imap/pop3 сервиса я использую dovecot на данном сервере. Но с ним у меня что-то не сложилось. Не хотел отправлять оповещения и все тут. Наверное руки кривые (у создателей dovecot -)). И тут автор данного сайта посоветовал мне написать скрипт, что бы не мучаться с dovecot. Что я и сделал.
Як бути в курсі чи немає вразливостей у вашій ОС чи в пакетах? Звісно, обовʼязково бути підписаним на різні security news, але простіше користуватися відповідними інструментами, які заточені під вашу ОS/pkgs.
Тут будуть описані деякі FAQ по роботі з pkg у FreeBSD
Версія ABI
$ pkg -vv | grep -i abi
$ pkg query "%n-%v: %q"
Час від часу бувають ситуації, коли підвисає дискова підсистема і нормальними (reboot/shutdown) засобами сервер не перевантажиться, бо перед перевантаженням ОС повинна зробити sync на диски, а цього вона зробити не може, бо “висить”. Це називається cold reboot, так би мовити “reboot по живленню”.