Да, кстати, хотел отметить просто обалденный перформанс (быстрее чем железный райд) у FreeBSD ZFS. Когда 3-4 райда 0 в zraid2 сводится скорость просто бешеная.
К тому же можно сделать NSPF кластер ZFS (hastd + geom_gate + zfs) и по nfs раздавать место, но это еще не пробовали.
В Европе вполне адекватная такая рентабельность. Вон hetzner по 9 евро с сервера имеет при окупаемости за 6 месяцев.
У нас на Sun, IBM, HP без проблем все заводится, все с кеширующими баттареизированными райдами, все видит все распознает и дает управлять, райды на рабочей системы без проблем перестраиваем. На Деллах тоже я слышал проблем нет. Супермикра тоже без проблем подхватывается. И с RMM3 что-то я не вижу зависаний, есть сугубо личные глюки RMMки, проявляющиеся на всех ос, а так все в порядке...
rtyug - а зачем это надо? Если он это на уровне ядра или базовой комплектации, то пусть идет лесом и ведет свой порт - они для того и сделаны, ибо ни в ядре ни в базе этого быть не должно.
NetBSD не в курсе, DragonflyBSD - хорошая вещь, только очень медленно развивается (ее вообще по-моему 1 человек пишет :) ).
Зачем гном дебиану? Ставьте мини или бейз или как он там? Когда только SSH и все, а потом любым установщиком, что угодно ставьте.
А на видяхи он капризен, да... По RMM3 отключился при установке, когда определил, что "монитор" по USB подключен.
FreeBSD 4.9 патченная до сих пор работает как один из основных серверов.
Отличная стабильная система. Если б не переезды в другие дц, аптайм бы у нее был уже лет 5 где-то.
Отличия в настройках с FreeBSD 8.1 минимальны. Кто работал с 4.3 без проблем подружится с 8.2 без передрессировки на тренингах.
Не уверен, что Redhat, например, может таким похвастаться, ибо знакомство с ним 7 лет назад не помогло в общении со свежими федорами и центосями (которые люто ненавижу, вот уж точно ОС для эникейщиков). Из осей линукс понравились Gentoo (ибо все можно прочувствовать, полный контроль за процессом, отсюда легкое втягивание в понимание процесса работы системы) и конечно же Debian, т.к. его стабильность чем-то напоминает мне BSD.
Linux используем там, где БСД слаба - это частично виртуализация (по-большей части из-за отсутствия поддержки производителей), хотя у БСД есть уникальная и отличная jail система, и всякие хитрости, под которые никто не делает драйверы для FreeBSD (самое обидное - infiniband и sun neptune). А так при прочих равных BSD и к черту уже этот зенд, компиляция софта под BSD не так уж и сложна для их маленькой программульки - это был чисто "личный" ход, тем более если уж для Мака есть, а линуксовые детишки только и радуются, что кто-то подписал приговор своему софту.
По-моему "не оверселлить" там можно только память. Ядра все равно без разницы как scheduler раскидает, а жесткий диск и подавно ничем не проконтролируешь...
Можем предложить вот такой конфиг KVM VDS:
1x Intel Xeon E5540 2.53Ghz 2GB DDR3 25GB RAID10 SAS HDD 2000р. в месяц
В списке пока что не значится, но у нас будет конфигуратор, поэтому список мало на что влияет.
Расценки примерно следующие 1000 рублей за ядро процессора, 500 за гигабайт памяти, 500 за 10 гбайт места. Стартовая цена за 1000 рублей за 1 ядро 1гб памяти и 15 гбайт места.
С ежедневными бекапами.
Наши сервера - Sun Microsystems и сетевая инфраструктура - Cisco.
p libapache2-mod-rpaf - module for Apache2 which takes the last IP from the 'X-Forwarded-For
этот не подходит?
apache2-dev
тут apxs
Вот с этой стороны Вы правы, т.к. как я указал средства на это есть (mod_rpaf)
Именно, я же написал, что в данном случае HTTP заголовок X-Forwarded-For передается клиентом - то есть прокси сервером на их сервере. А прокси сервером он берется из реальных данных о клиенте.
Даже если реальный клиент пошлет такой заголовок, то он будет перезаписан, подделать невозможно.
Изучайте устройство Layer 7 протокола HTTP и Layer 7 же проксирования. А не по таким "учебникам" и будет Вам счастье.
Для наглядности вот схема предполагаемого устройства их сервиса:
internet client (70.30.42.5) -> connect (1.1.1.1, 80) -> proxy (listen 1.1.1.1 80) -> apache server(listen 127.0.0.1 85)
Отсюда proxy соединяется с апачей, но ремоут адрес для апача будет уже 1.1.1.1, а не 70.30.42.5 именно для этого сделан http заголовок X-real-ip или в оригинале x-forwarded-for, в котором и передается 70.30.42.5 от прокси. И даже если 70.30.42.5 пошлет заголовок x-forwarded-for: admin durak, то apache server получит в x-forwarded-for: 70.30.42.5 .
И добавлю, проксирование можно было бы реализовать натом или прозрачным прокси, но намного проще и удобнее сделать схему с x-real-ip.
Единственное странно, что на апач они не поставили mod_rpaf2, который прекрасно перезаписывает переменную remote_addr на данные из x-forwarded-for или x-real-ip...
Разницы между этими переменными нет в контексте PHP все они задаются системой (от того и называются SERVER).
В данном случае сервер PHP стоит за каким-то балансиром или прокси, оттого реальный адрес клиента попадает в переменную HTTP_X_FORWARDED_FOR (и подделать его нельзя, кроме смены IP), которая задается на прокси-сервере.
REMOTE_ADDR задается уже самим сервером из контекста данных от клиента для него (то есть того, что выдает accept(socket)), клиентом для него является прокси-сервер. Именно для этого были введены хедеры x-forwarded-for и x-real-ip.
Поэтому в данном вопросе Вы не правы.
