Вот такое сообщения я получаю, когда пробую установить Solaris. И так ругается на все 6 дисков, которые есть в сервере. Как итог: система не ставится, так как все диски в offline.
Мудрые коллеги подсказали, что это проблема контроллера Dell Perc H200, а точнее проблема энергосбережения, а так же подсказали решение , но оно уже годится для установленной системы.
Под FreeBSD под этот контроллер нету энергосбережения, поэтому там таких проблем нет и система на него ставится без проблем.
Тестовый стенд: tmux-1.8, libevent-2.0.21
Сборка tmux’a под Solaris ещё тот квест с правкой исходников. И так, качаем свежую версию tmux’a, а так же libevent (как зависимость). libevent ставится без проблем:
root@skeletor:/export/home/skeletor/libevent-2.0.21-stable# CFLAGS="-m64 -O2" CPPFLAGS="-m64 -O2" CCASFLAGS="-m64 -O2" CXXFLAGS="-m64 -O2" LDFLAGS="-m64 -O2" ./configure --prefix=/usr --libdir=/lib/64 && gmake && gmake install && gmake clean
А теперь соберём tmux:
Всё бы хорошо, но tomcat не понимает сигналs HUP, SIGUSR1 (при их получении он просто завершается). Как быть, если надо ротировать логи. Есть 2 варианта: через системный log-ротатор и через встроенные механизмы самого tomcat’a. Я рассмотрю первый вариант, так как в нём больше возможностей в плане ротации файлов. Но тут есть нюанс: ротировать будем с помощью метода copytruncate, то есть нужный нам лог сначала копируется, а потом урезается до нулевой длинны, тем самым не нарушая последующей записи в исходный лог.
Что делать, если зона запущена, а в ней нужно добавить ещё одну сеть? Можно добавить через zonecfg и ребутнуть зону. Но что делать, если ребут невозможен по каким-то причинам? Оказывается, выход есть.
Примечание.
Начиная с 11.2 появилась возможность сделать apply конфига при запущенной зоне. Делаем необходимые изменения через zonecfg и потом просто выполняем:
# zoneadm -z zonename apply
Появилась задача: создать юзера, который бы ничего не мог сделать, кроме как читать файл (в идеале только 1 )), но это оказалось невозможным, возможно пока).
В Solaris за права юзеру отвечает RBAC. Он позволяет как расширить права, так и сузить. По дефолту новому юзеру присваивается 2 профиля: All и Basic Solaris User:
$ profiles skeletor
skeletor:
Basic Solaris User
All
Данная утилита от LSI так же позволяет оперировать рейд-контроллерами от Dell. Но замена дисков через такую утилиту – целый hardcore, только для настоящих Tru-админов )).
Тестовый стенд: контроллер PERC 6/i, RAID-1, Linux MegaCli64, выпал 1 диск.
Что имеем: есть сервер (8Гб памяти, Intel(R) Xeon(R) CPU E31220 @ 3.10GHz) FreeBSD 8.4 Release amd64, сайт на php5.2, nginx+apache+mysql.
Перейти полностью на php-fpm не получилось, поэтому пришлось защищаться как есть. Это поможет отразить небольшую syn flood атаку.
Ниже будет приведены выполненные действия для отражения атак.
После обновления FreeBSD 8.1 на 8.4 вылез неприятный момент: при ребуте сервер подвисает на сообщении:
usb0 disconnected
Всему виной оказался USB 3G модем Novatel U720, из-за которого и получали подвисание.
Недавно, на один из старых серверов (там крутилась FreeBSD 7.3) пришла абуза от хостера, что на сервере замечен rootkit. Была информация, что при любом логине (а как позже оказалось, вообще при любой попытке, даже неудачной) на сервер он отправляет login/pass/ip на сервер злоумышленника в виде хитрого DNS запроса.
Недавно сообщалось, что такой руткит был найден на серверах с linux (там была протроянена либа libkeyutils.so). Гугление показало, что такого руткита для FreeBSD и в помине нет (а может плохо гуглил).
UPD: а вот похоже и оно
Тестовый стенд: Centos 6.2 (kernel 2.6.32-220.4.2.el6.x86_64), apache+php+mysql
Имеем очень много соединений с состоянием SYN_RECV (syn flood):
$netstat -ntu
...
tcp 0 0 XX.XX.XX.XX:80 202.51.102.34:40700 SYN_RECV
tcp 0 0 XX.XX.XX.XX:80 190.225.143.29:40123 SYN_RECV
tcp 0 0 XX.XX.XX.XX:80 101.255.71.7:38725 SYN_RECV
tcp 0 0 XX.XX.XX.XX:80 122.226.122.201:48952 SYN_RECV
tcp 0 0 XX.XX.XX.XX:80 186.91.63.97:44343 SYN_RECV
tcp 0 0 XX.XX.XX.XX:80 109.230.156.97:56149 SYN_RECV
...
Как с ними бороться?