Вот тут уже неоднократно задают вопрос, какой php выбирать для установки на свой сервер? Ну, а так как "ложки нет" (© Матрица), и универсального рецепта всеобщего счастья тоже нет, то предлагаю самостоятельно выбрать метод установки, предварительно оценив все за и против.

Установка как mod_php, модуль Apache. Предполагает получение максимальной производительности от PHP, что является предпочтительным на очень нагруженных сайтах, обновление версии PHP повлияет на все захостченные веб узлы. Очень подходит для случаев "один сервер - один сайт".

Установка PHP как CGI. По сравнению с mod_php несколько медленнее. Необходимо прописывать php.cgi как обработчик для php файлов в концигурациях apache для каждого сайта (я это делаю у каждого сайта в корневом .htaccess). Несомненным плюсом является возможность держать нужную версию PHP для каждого конкретно взятого виртуального хоста. Массовые хостинг-серверы, как правило, настроены именно так, ибо при обновлении PHP можно будет переводить на более новую версию php.cgi сайт за сайтом, без боязни потерять работоспособность.

Оффтоп: Не нравится мне PHP, идеологически не нравится. Начиная от миллиона напрасновкомпиленных процедур, и корявым "эскейпом и экранированием" HTML и заканчивая мусорником репозитария классов. Но уж очень много всего написано, да и хостинг без поддержки PHP уже практически исчез ;) А поэтому продолжаем грызть кактус ...

Когда мысли становятся как молекулы, и перемещаются в пределах черепной коробки по принципам броуновского движения, у нас начинают генериться добавочные мысли, по типу "как же это все привести в порядок".

В связи с этим начало свою активность новое направление с хитрым названием mindmaps. Так что же собой представляет типичный mindmap? Сходу подобрать определение достаточно сложно, но попробую. Самой близкой аналогией будет графическое представление процесса мышления "от руки", в виде некоторых рисунков, выкладок, демонстрация перед аудиторией принципов работы чего-то.

Если у кого-то все-таки возникают проблемы с чтением RSS с этого сайта - прошу отправлять багрепорты мылом на nexus[at]mail.ru.

Кстати, о RSS ридерах. Самый, на мой взгляд, классный ридер - FeedDemon от Bradbury Software (да и вообще автор делает исключетельно правильные штуки, как говориться, must see). Лично мне нравится рендеринг содержимого не "по теме в каждой строчке", а как газетная колонка, где сообщения идут одной лентой.

Надо отметить, был приятно удивлен простой и удобной настройке удаленного подключения к Linux box. Работа с удаленной системой визуально ничуть не тормозит (в локальной сетке), однако при использовании совсем удаленного работчего места, например, через WAN, будьте готовы к значительному потреблению трафика.

Во-первых, в составе дистрибутива почему-то отсутствовал kinit и вообще пакет kerberos-workstation, который мы и устанавливаем при помощи yum:

yum install kerberos-workstation

После попыток проверить Керберос через kinit Administrator@it.group мы получили

kinit(v5): KDC reply did not match expectations while getting initial credentials

Путем непродолжительного гугления был найден ответ: юзаем все после знака @ в апперкейсе, т.е.
Administrator@IT.GROUP сработало!

На самом деле sshd работает, эмпирическим путем было выяснено, что помогает если в ssh выбрать протокол ssh версии не 2, а 1.

И спокойно коннектимсу к хосту. 

Yum - так называется менеджер пакетов в RedHat. Запустил, посмотрел, и как-то вот сразу он мне не понравился, начиная с названия, и заканчивая принципами работы.

Каждый линукс-клон решает проблему установки и каталогизирования софта своими способами, в linux debian это система apt (которая по праву считается наиболее полной и лучшей системой работы с пакетами), в linux red hat - yum. Начнем с того, что при каждом чихе и пуке yum начинает лезть на редхатовские сервера, подчитывать каждый (!) раз списки софта, обновления и прочее. Но работает. После портов в FreeBSD yumom ни разу не впечатлился. 

Вообще самой удачной реализацией считаю систему портов и пакаджей у FreeBSD, настройка и работа с портами доставляет настоящее удовольствие. К примеру, простой командой мы выкачаем исходники софтины, компильнем и сделаем из этого paсkage, который потом распространим на серверы с такими же конфигурациями. Также можем легко расшарить уже скачанные дистрибутивы для системы портов и других FreeBSD серверов. Очень удобная система работы с индексом базы портов, поиск, и в целом, по моему скромному мнению, пока ничего лучше придумано не было.

Как запустивший Линукс Красную Шапку с версией Core 2 могу субъективно оценить положение дел с 1996г в Линуксах. Предаваясь ностальгическим воспоминаниям не могу не вспомнить ядра версии 1.х.х, полностью текстовые инсталляторы с интуитивно непонятным на то время fdiskом.

Если взглянуть на сегодняшний Линукс из ракурса old school линуксоида закваски 96года отдельно хочется отметить семимильные шаги технического прогресса в области дизайна и интерфейсов. Сегодня мы имеем полностью графический инсталлятор, при этом не нужно быть великим гуру юникс-шеллов, достаточно выбрать с начала установки язык, на котором мы будем понимать систему, и откинувшись на спинку стула в лучших традициях Майкрософта будем давить на кнопки "Далее", пока не получим полностью работоспособный Линукс. Ну насчет "полностью работоспособного" я погорячился ;) Конечно, мы будем делать тысячу и одну настройку, что бы заточить все это космическое чудо "под себя" или под серверные задачи. Конечно, мы будем еще десять тысяч раз украшать, и одиннадцать тысяч раз сносить украшения. Мы будем компилить, коннектить и затачивать GUI. Но такого драйва и ступора при виде командной строки, как в том 96м году при установке Линукса Красной Шапки версии 4.20 мы уже не будем ощущать никогда. Да и к лучшему это.

Вот таким был сайт microsoft.com с апреля 1994 по август 1995.

Что интересно, в то время самым популярным браузером был Netscape Navigator, а IE был рагульной добавкой, которую никто не ставил, ибо в составе операционки его еще не было. Все течет, все меняется.

В общем не захотел с полпинка устанавливаться контроллер домена в удаленном месте. Предполагалась операция замены одного КД другим КД, последовательность действий предполагалась такой:

1. Устанавливаем рядом второй КД.
2. Понемногу перетягиваем на себя функции первого КД, как то: WINS, DHCP, DNS
3. Аккуратно переводим DFS на себя, реплицируем.
4. Выводим первый КД из DFS.
5. Убираем первый КД из WINS, выключаем DHCP (unauthorize), включаем второй DHCP.
6. Деинсталируем первый КД через визард "add remove role".

Так вот, при этих всех манипуляциях произошло два неприятных момента.
Первый: новый R2 КД отказался на халяву устанавливаться в домен. Не валидная, видете ли, схема у леса. Рекомендация сделать adprep не сработала. Много гуглил. Нагуглил рекомендацию юзать adprep от R2 релиза, тот что на втором диске, CMPNENTS\R2\ADPREP. Да, это уже сработало. При чем пришлось это проделывать на самом-самом главном контроллере домена. Глюк второй, первый КД не захотел просто так отконнекчиваться от домена с невнятным сообщением об ошибке. Пришлось повторить процедуру позже, после полной репликации AD. Во второй раз все прошло без сучка, без задоринки.

Вот тут некоторые (не будем показывать на cjnova пальцем)  начинают упрекат меня в уходе от основной ИТ тематики, на что моя незамедлительно начинать кассовую статью о реализации failover схемы подключения нескольких провайдеров, и организации бесперебойной связи с удаленным подразделением на основе протокола BGP и системе FreeBSD (zebra).

UPDATED: После выведения контроллера из домена необходимо вручную удалить связи для репликации с другими контроллерами в консоли Active Directory Sites and Services