Угдыжеков Сергей sugdyzhekov

Проблема “ хочу новую версию %software% на моем стареньк… стабильном Debian/CentOS…” так же стара, как *nix-мир. Способов добиться желаемого хватает. Есть масса решений как притащить в систему несколько версий одного и того же софта. Но дальше хочется не просто иметь ещё одну версию, но и управлять тем, какая из версий доступна в системе по умолчанию, для конкретных приложений или пользователей.

Что делать, если хочется сменить системную версию PHP на одну из кастомных сборок? Давайте отталкиваться от того, что у вас на сервере уже установлено несколько версий PHP и вы хотите, чтобы в консоли команда php была конкретной версии, отличающаяся от той, что шла с системой. В этой статье я расскажу, как правильно это настроить, чтобы не было проблем с будущими пакетными обновлениями.

Каждый раз поднимая новый сервер в облаках, вы получаете случайный IP-адрес. Не все понимают, что IP-адрес может попасть к вам с "историей". Часто приходится тратить время на удаление IP из публичных черных списков. В моём случае в последний раз это была очень неторопливая переписка с mail.ru, которая ни к чему не привела. После этого, создав новый сервер, я задумался: как же сделать так, чтобы не огребать проблем с такими IP-адресами?

Введение

У меня есть pet project, которым я занимаюсь в свободное время. Этот проект полностью посвящён инфраструктурным экспериментам. Для управления конфигурацией я использую SaltStack. SaltStack — это централизованная система управления инфраструктурой. Это значит, есть мастер-сервер, который настраивает подчинённые серверы.

За время жизни проекта я наступил на небольшой набор граблей, но в итоге пришёл к очень удобному подходу работы с ним. В общем про это и статья — как оно все начиналось и к чему пришло.

Давным-давно в нашей хостинг-панели Parallels Plesk Panel мы сделали такую интересную фишечку: если вводился адрес панели с указанием порта (8443), но без указания шифрования (https), то Plesk перенаправлял пользователя на адрес https://<server_hostname>:8443. Это было удобно. Кто-то к этому поведению привык. А кто-то — даже учел в своих процессах. В версии 11.5 мы заменили веб-сервер, обслуживающий сам Plesk, c lighttpd на nginx. И нечаянно сломали ту самую маленькую фишечку. Просто не смогли придумать, зачем бы она была нужна, и с новым веб-сервером ее не реализовали. Пользователям, обращавшимся по адресу http://:8443, стала показываться ошибка 400 - «Bad request».

Наши пользователи тут же напомнили нам, написав отзыв на forum.parallels.com (а мы читаем наш форум, да), - что ломать хорошие фичи и не давать ничего взамен - это плохо. Простите нас :) Вы скоро сможете увидеть в превью Parallels Plesk Panel 12.x, что мы ее вернули.


Предыстория

Озадачившись получением фидбэка и более точной приоритезацией задач, разработчики Plesk завели аккаунт на UserVoice — http://plesk.uservoice.com. Тем самым организовали место, где клиенты могут предлагать свои нововведения, писать, что именно им не нравится, голосовать за нужные им функции (те, что набирают большинство голосов, попадают в разработку). Один из популярных запросов, которые мы получили от наших пользователей – это «Automate slave DNS support». Это довольно старый запрос на функциональность, которую хотят почти все администраторы Plesk-серверов. Чтобы раз и навсегда закрыть этот вопрос, мы решили сделать соответствующее Plesk-расширение. Какие причины были сделать это именно так? Что именно мы сделали?