Атомарное обновление system (как в freebsd).
Никто не встречал проекта с такой направленностью? Gentoo использую на серверах , все достаточно приемлемо пока дело не доходит до
апдейта системы.. Тут с вероятностью 90% что-то пойдет не так , если давно не обновлялось (блокированные зависимости , вырубленный use netifrc ведущий к отваливанию сети , удаление из init чего-то нужного и.т.д). Вобщем у кого есть сервера работающие хотя-бы года по 3 - меня поймут , зачастую проще переставить с нуля. (а если нет ipmi и сервер далеко - чисто игра в русскую рулетку :) )
Отсюда вопросы:
1. Собственно в заголовке. Есть ли какие тулзы позволяющие собрать новый system а потом сразу его закатать без убивания конфигов и разрешения зависимостей?
2. Security updates. Про emerge @security в курсе , но а) работает оно не всегда. б) может по зависимостям утянуть пересборку половины системы. Соответственно хотелось бы иметь некий срез portage (в git например) с не очень частыми апдейтами пакетов , только security. Сделать конечно можно свой , но может есть поддерживаемое решение уже.
Про calculate в курсе (п.2 пожалуй можно решить за счет их срезов portage в git'e) , но вот (1) очень хочется получить в том виде как оно сделано во freebsd.
В последнее время проблема решается разнесением системы по lxc контейнерам и минимализмом установленных пакетов в host системе , но тем не менее проблема остается (убитая система инициализации в контейнере не так страшно , но пересобирать то все равно надо)
- Для комментирования войдите или зарегистрируйтесь
Лично я бы рекомендовал Вам
Лично я бы рекомендовал Вам все же ipmi или подобное аппаратное решение.
А на деле, у нас тоже нету таких, дороговато показалось руководству. Посему я на vmware esxi 5xx остановился & router. Да и с бэкапами проще становиться, целиком ось "зазеркалить" проблем не представляет. Копию сделали, и редактируйте себе на здоровье, собирайте хоть год.
discord: hwline#1904
constantly use: funtoo-linux, ubuntu
У меня практически везде он
У меня практически везде он есть. (на старых серверах правда без KVM , но там задача решалась включением PXE загрузки - в случае чего поднимал dhcp+tftp ресетил сервер и бутал по сети образ для восстановления) .
Сейчас он есть на любом сервере ибо бесплатно - встроено в чипсет.
Тут вопрос больше в возможности обновления системы "на ходу", с 0 или минимальным downtime. Ну как debian - там практически всегда уверен что все пройдет ок.
VmWare , kvm , lxc и прочие системы виртуализации/контейнеризации - удобная штука , уже писал что юзаю lxc.
К libvirt присматривался в
К libvirt присматривался в свое время, но как то видимо не судьба...не пробовал.
OpenVZ пробовал поднять, но из-за нехватки времени, сроки поджимали, пришлось отказаться. Хотя чаша весов vmware <=> gentoo конечно в пользу gentoo. Появиться свободная физическая машина и время, попробую еще раз поднять.
VMware ESXi надежная, проверенная временем система, к тому же "даром" для организаций это перевесило, с ограничениями правда, на количество серверов. Но пофиг. Версия 5.5 как раз в это время вышла.
Но лично я, ни за что рабочий сервер, обновлять так не буду. Копию жесткого диска снять проблем нет, да и "скормить" в виртуалку, залить исходники и поставить на сборку без установки. По пути решая проблемы с зависимостями. Хотя неприятный момент тут это то что реальная ось привязана к реальному железу. Это проблема. Еще одна причина почему был выбран ESXi. Виртуальное железо не привязывает виртуальную ось к одному месту расположения. Снял копию с рабочей системы, вези хоть на Марс. ESXi примет как родную. А перенос нода, у меня лично, не всегда почему то гладко проходит.
discord: hwline#1904
constantly use: funtoo-linux, ubuntu
>>У меня практически везде он
>>У меня практически везде он есть.
Удаленная аппаратная консолька да еще с возможностью подмонтировать удаленно лайв это только часть проблем. Что касается возможности обновления на ходу c нулевым даунтаймом, то тут ни фря ни дебиан вас не спасет, ибо нулевой даунтайм предполагает наличие как минимум двунодового кластера. Если же речь идет об "или минимальном downtime" то тут надобно определить в численном выражении понятие минимальный. Ваше сравнение бинарного дистра debian с наколенным конструктором gentoo на мой взгляд некоректно. Хотите без проблем "как в дебиан" - его и ставте. Сурсовый дистр по определению не может быть оттестирован мантейнером на предмет совместимости и работоспособности. Эту работу дистростроители оставили вам. Инструментарий в комплекте. Как минимум, можно в сшруте насобирать бинарей и оттестировать работоспособность (в том числе и конфигов) на тестовом серваке (возможно даже виртуальном) с последующим резервированием системы и установкой ранее оттестированных бинарников. При правильном подходе получится не хуже дебиан.
.
Сильна у людей вера в Чудо…
С заявленной частотой обновлений (3+ года) ты на любой платформе найдёшь приключений.
Без резервирования задача (обновления сервера раз в 3-4-… года без перерыва в обслуживании) решения не имеет.
Но есть хитрый ход: у grub'а ЕМНИП была фича в случае облома с основным вариантом загрузки указывать резервный. В качестве которого можно положить соответственно сконфигурированный (локально проверенный и отлаженный) образ SRCD.
Самому не смешно?
etc-update
зачем?Учи математику на предмет решения задачи расчёта зависимостей.
Ни бздя, ни тырпрайсы ни фига не панацея.
Даже если внезапно твои требования к серверу полностью удовлетворяются тем, что в FreeBSD называется базовой системой, остаётся замечание к п.2.
Как ни скучно, но начинать здесь надо с освоения философии используемого конструктора.
:wq
--
Live free or die
Anarchist написал(а): Сильна
3+ года - не частота обновлений а время жизни самой системы. (последний раз обновлял систему на сервере установленную в 2006м вообще , на дом. машине уже и не помню сколько лет). Обновляю периодически естественно.. Насчет srcd - сейчас похоже сделано кое где - 2 раздела , после перезагрузки (если все ок) - синхронизируем рабочую систему на бэкап раздел , в случае чего грузимся оттуда.
Насчет etc-update - в случае грубого решения a'la распаковки stage3 - чем оно поможет? Идея состоит в том чтобы иметь stage3 не убивающих конфигов (и еще чего).
Насчет "учи математику: - вопрос к девелоперам portage. Периодичеслие блоки , циклические зависимости и прочие радости сильно мешают хоть сколь нибудь автоматизированному апгрейду.
В принципе в варианте с обеспечением безопасности обновлений можно еще попробовать заюзать log based filesystem , хоть откатиться можно (если диск конечно не использован на 90%).. Но у меня на данный момент опыт работы с ними (юзал nilfs2) скорее отрицательный - там userspace сборщик мусора , который иногда сглючивает , что приводит к заполнению на 100% блочного девайса с этой fs.
Насчет "освоения философии".. С 2003 вроде освоил :) , но в последнее время не особо следил за появлением новых фишек , собственно отсюда и данная тема - не у одного
меня же такие проблемы..
не надо обновлять систему
не надо обновлять систему вживую на боевом сервере
Скопируй, обнови в chroot и граб настрой на новую, а при обломе загрузки на старую
1. BINHOST?2.a GLSA выходят
1. BINHOST?
2.a GLSA выходят постоянно. в чём проблема?
2.б Это на десктопе, на сервере не встречал.
Portage можно обновлять атомами. rsync в помощь . Получается обновления только GLSA, например или что-то ещё по вкусу. В целом на выходе хороший такой фриз системы со временем жизни до выхода следующей версии EAPI. Последнее EAPI ЕМНИП уже года 2.
Кстати , в процессе изучения
Кстати , в процессе изучения вопроса нашел http://wiki.gentoo.org/wiki/GLEP:19. Но оно не взлетело :(
Status Withdrawn by the
Status
Withdrawn by the author. "If someone wants to take up the torch, more power to them, but they should probably start clean with a new glep."
Ну и самое главное требование:
profile x86 only & gentoo-stable-portage
discord: hwline#1904
constantly use: funtoo-linux, ubuntu