Апгрейд httpd и httpd-tools на боевом сервере

минорные обновления можно ставить с закрытыми глазами. Хотя чейнджлог почитать стоит.

Посоветуй как безопасно (т.е. с возможностью отката на предыдущую версию в случае возникновения каких-либо проблем) на боевом сервере с centos обновить httpd и httpd-tools?

Да как угодно. Но есть важный нюанс, вазелин купить надо заранее.

Вашему чувству юмора не занимать, правда хотелось бы чуть серьезнее.

Еслм в кеше пакетов есть та версия которая сейчас стоит, то откатиться можно с помощью yum history undo. Если таковой нет, можно заранее подключить Vault и в случае проблем сделать тоже самое. У меня обновления в рамках версии никогда к проблемам не приводили.

Да я вполне серьезно.
Вы же как правильно делать не хотите.

Где-то говорится про создании клона сервера плюс пробное обновление там, но хотелось бы что-либо попроще без таких заморочек, если, конечно, такое возможно."

Создали виртуалку, протестировали, запустили в прод

Проблема в том, что у меня боевой сервер это и так виртуалка. Или это все же не проблема?

Так в чем в проблема, поднять отдельную виртуалку и протестить? Вместо того что бы темы плодить?

Хмм, спасибо. Слабо правда представляю пока, как все это, но буду копать в этом направлении.

Проблема в недостаточности моего опыта. Я как-то пытался делать образ системы, правда на фряхе, и не слишком удачно. Я так понимаю, что мне придется стопорить все процессы, ставить фс в режим только для чтения и только потом через dd делать образ около дня, причем неясно хватит ли мне памяти не текущей ФС, чтобы сохранить образ. Вот, к сожалению, поэтому я бы хотел этого избежать. Хотя прекрасно понимаю, что так правильно.

У меня обновления в рамках версии никогда к проблемам не приводили.

Никогда != не-случиться. Не учите плохому. Без тестирования, применять изменения не лучший вариант.

Проблема в недостаточности моего опыта.

Который вы хотите и дальше «культивировать».
Мы не знаем что у вас там за система, но вы говорите виртуалка, проще сделать снапшот (это если возможно) и потом скопировать.
ЗЫ И dd не лучший вариант, есть rsync, tar, cp - это из простого.
ЗЫЫ Учитывая отсутствие опыта, поднять систему (просто с нуля) в отдельной виртуалке, скопировать, развернуть в новой вирталке, если что-то не получиться, учесть ошибки и повторить. При достижении положительного результата можно и на реальной такое проделать.
ЗЫЫЫ «лучше день потерять потом за 5 минут долететь» :)

Мы не знаем что у вас там за система, но вы говорите виртуалка, проще сделать снапшот (это если возможно) и потом скопировать.

Я думал по поводу снапшота. Но опять же не уверен, что хватит место на диске. И мне это пока что еще не приходилось делать. Но это в принципе ладно.

Что касается системы, то у меня Centos 6.5, а версия ядра — 2.6.32-042stab111.12, а виртуалка скорее всего openvz, если это важно, конечно.

ЗЫ И dd не лучший вариант, есть rsync, tar, cp - это из простого.

Спасибо за рекомендацию. Учту.

ЗЫЫ Учитывая отсутствие опыта, поднять систему (просто с нуля) в отдельной виртуалке, скопировать, развернуть в новой вирталке, если что-то не получиться, учесть ошибки и повторить. При достижении положительного результата можно и на реальной такое проделать.

Я бы с удовольствием так поступил, но у меня боевой север, которому уже пара лет. Там стоит старое ПО, может быть, конечно, имеет смысл напрямую установить те самые старые пакеты httpd, httpd-tools и их попробовать обновить при установке mod_ssl, но не знаю, надежная ли это будет проверка.

ЗЫЫЫ «лучше день потерять потом за 5 минут долететь» :)

Я с вами бесконечно солидарен. Набитые шишки уже же есть, поэтому тут даже спорить не с чем, но согласитесь, когда у вас задача всего лишь развернуть https на сайте, меньше всего хочется идти таким сложным путем.

Два пути:

1. Сколонировать сервер и проверить на копии (более надёжно, но надо больше места), повторить на live
2. Сделать бекап, попробовать, и если что не так — откатить (может привести к 1..5 мин downtime)

Т.к. ты упомянул openvz, то у тебя скорей всего proxmox. И первый и второй вариант там реализуем в пару кликов мышкой.

У меня нет доступа к системе виртуализации (только доступ к самой виртуальной машине и не более того), поэтому воспользоваться proxmox я не смогу. Увы.

Третий вариант — плюнуть на всё и просто сделать. Разруливая по дороге проблемы, если будет. Но как уже говорили выше — обычно при минорных апдейтах проблем не наблюдаются.

Всё зависит от того, сколько миллионов USD стоит минута простоя сервиса. В твоём случае это буду скорей всего два цента. Т.ч. решай.

Ну в целом простой да не слишком много стоит. Слава богу, еще до такого не дожил.

Третий вариант — плюнуть на всё и просто сделать. Разруливая по дороге проблемы, если будет. Но как уже говорили выше — обычно при минорных апдейтах проблем не наблюдаются.

Вот этот вариант больше для опытных людей, «Не взлетело? Не вопрос разберемся»
В продолжение:

обычно при минорных апдейтах проблем не наблюдаются.

Вы очень верно слово «обычно» выделили. Вы, как опытный админ, можите зачастую этого не заметить, ну пришлось вдруг «мелочь какую-то поправить» - поправили походя и забыли. Это действительно реалии жизни, то что для вас очевидно и выполняется без включения мозга, у людей которые с этим не работали вызывает много проблем.
Бэкап или «кошечки» фактически одно и тоже. Разница в только том, что пропускаем само тестирование.

Т.к. это мне требуется для установки mod_ssl

А может стоит сначала поставить mod_ssl который под текущий httpd, и если полет нормальный и действительно нужна та новая версия mod_ssl , то обновить оба пакета сразу к нужным версиям?

Вы вероятно не поняли меня. Mod_SSL для апача не установлен в системе. И он требует в качестве зависимостей более новые версии самого апача.

Всё я понял. Установите ту версию mod_ssl который подходит под тот апач который у вас есть. Мешает что-то?

Обновляй так, без проблем всё будет. Это ж центось, всё старое и железобетонное.

Спасибо за совет, нашел нужный мне пакет и накатил его. Сейчас развлекаюсь с настройкой https.

Я послушал совета FeyFre и накатил именно нужный пакет для текущей версии httpd.

Я не говорю за всех. Я говорю что у меня проблем не возникало.

Ну, вообще-то, программы, торчащие наружу, надо обновлять, а не фиксировать версии.

По-хорошему да. Но речь сейчас про боевой сервер, где обновление одного компонента приведет к обновлению всех зависимостей. А значит точно что-нибудь, да не взлетит. А я рисковать бы не хотел.

Ну я боевые сервера на centos спокойно обновляю в моменты, когда можно сделать небольшой даунтайм.

Вот, кстати, а можно вам задать вопрос не по теме, потому что как-то не хочется новую тему создавать. Вы сталкивались когда-нибудь на Debian GNU/Linux 8.3 c версией php 5.6.17 с проблемой сборки мусора? Немного загуглил. Вроде как проблема с правами в /var/lib/php5, но прикол в том, что сессии у меня хранятся как раз в папке /tmp, и по факту права на нее у php определенно должны быть, но почему-то файлы создаются и читаются, но никак не хотят удалятся. Залез в настройки php.ini, обнаружил следующие настройки сборщика мусора: gc_probability = 0 gc_divisor = 1000, исправил на 30/100. Для проверки даже сделал 100/100, но никакого видимого результата это не принесло. Если шо session.gc_maxlifetime = 1440 вот так выставлена. Апач рестартил, да. Буду вам очень признателен, если поможете советом.

Идеальным вариантом было бы держать две копии сайта за каким-нибудь HAProxy или Nginx, да обновлять их, не парясь. Если httpd упал - прокси будет направлять все запросы на рабочий, пока ты его чинишь.

на Debian GNU/Linux 8.3

Нет. До 8.3 не дошёл ещё.

http://serverfault.com/questions/511609/why-does-debian-clean-php-sessions-wi...

Классный вариант. Но т.к. велосипед не мой, а за это мне никто не заплатит — слишком затратный, на мой взгляд. Но как-нибудь подумаю над реализацией подобного у себя на рабочем сервере, спасибо за пищу для размышлений.

Я это видел. В /etc/cron/php5 правда у меня вот это:

09,39 * * * * root [ -x /usr/lib/php5/sessionclean ] && /usr/lib/php5/sessionclean

Может в этом проблема? Вообще бред какой-то.

Клонировать VM/контейнер, поправить адреса и всё. :)

А разве я могу клонировать сам контейнер, если у меня доступ только к самой vps?

Можно нежно попросить операторов/хостеров, вдруг нажмут на кнопочку?

купи вторую vps