дистрочойз

> `белых людей'

gentoo

Gentoo - дистр для белых людей.
Остальное - красноглазие.
Серьёзно.
Щупал и centos, и opensuse, и debian.
После Gentoo оно всё очень убого.

Centos - убогий менеджер пакетов. Это просто леденящий душу п-ц.
Debian - хорошо, пока не понадобиться что-то не стандартное.
Opensuse - аналогично с centos.

В целом - пока всё стандартно - можно обойтись centos/debian. Но если надо что-то более-менее реальное - только gentoo.

У gentoo однако один минус - не весь софт в пакетах есть для неё.

Наиболее оптимальный выбор, имхо, CentOS. Сейчас в нем очень неплохо прокачан Xen (оп историческим причинам), и поддержка KVM в 5.4 уже очень неплохая. Плюс еще куча работающих практически out of the box энтерпрайз-плюшек, типа SELinux и kdump.

Сходными возможностями обладает openSUSE, но в энтерпрайзе дистр с таким мизерным сроком поддержки будет юзать разве что мазохист. А SLES, в отличие от RHEL, бесплатной версии пока не имеет. Поэтому учиться придется по openSUSE, а в продакшене работать уже со SLES. Немного неудобно :)

Убунта, во-первых, в более-менее новых версиях ксена уже не имеет, во-вторых, несерьезно (имхо). 8.04 даже для десктопа имхо баговат (был, в то время, когда я его гонял).

Спасибо, улыбнуло :)

> Убунта, во-первых, в более-менее новых версиях ксена уже не имеет,

трололо!

denis@laptop:~$ aptitude search xen | wc -l
28
denis@laptop:~$ lsb_release -a
LSB Version: core-2.0-amd64:core-2.0-noarch:core-3.0-amd64:core-3.0-noarch:core-3.1-amd64:core-3.1-noarch:core-3.2-amd64:core-3.2-noarch:core-4.0-amd64:core-4.0-noarch
Distributor ID: Ubuntu
Description: Ubuntu lucid (development branch)
Release: 10.04
Codename: lucid

во-вторых, несерьезно (имхо).

а мужики то не знают!

8.04 даже для десктопа имхо баговат (был, в то время, когда я его гонял).

конечно, когда 10.04 уже вот-вот выпустят.

Вы не согласны, что yum убог?

Понятно, что enterprise это в целом хорошо.
И в некоторых случаях centos - идеальный выбор.
Но, ИМХО, если квалификация позволяет - можно точно так де использовать и gentoo. Как минимум будет работать не хуже чем centos.
Ну и философия дистра способствует тому, что в случае проблем админ, как минимум, знает где же искать причину.

Возможно я просто мало пользовался centos. Очень может быть, что и так.

>denis@laptop:~$ aptitude search xen | wc -l

linux-image-xen — есть? Без него вся эта обвязка ничего не значит.

а мужики то не знают!

«Оно и видно, молодой человек, оно и видно!» ©

конечно, когда 10.04 уже вот-вот выпустят.

Ждем еще больше багов! </трололо>

> linux-image-xen — есть? Без него вся эта обвязка ничего не значит.

есть вот такое:

p ubuntu-xen-desktop - Xen software for running on desktops
p ubuntu-xen-server - Xen software for running on servers
p xen-docs-3.3 - documentation for XEN, a Virtual Machine Monitor
v xen-hypervisor -
p xen-hypervisor-3.3 - The Xen Hypervisor for i386 and amd64.
v xen-hypervisor-amd64 -
v xen-hypervisor-i386 -
v xen-utils -
p xen-utils-3.3 - XEN administrative tools

>Вы не согласны, что yum убог?

yum имхо отлично выполняет свои функции как менеджер бинарных пакетов. Как и apt-get.

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

Возможно я просто мало пользовался centos.

Думаю, здесь главное — не _чем_ пользоваться, а _где_ пользоваться. Точнее, в каких условиях.

В промышленных задачах все подчинено принципам эффективности, надежности и минимизации накладных расходов. И, как показывает практика, в большинстве задач наилучший результат показывают именно бинарные дистры в сочетании со сборочной фермой.

На пальцах — центос, дебиан, суся заточены под то, что пакеты им собирает отдельный сервер. Гента же заточена под сборку пакетов своими силами. Понятно, что в любой более-менее крупной инфраструктуре выносить сборку на отдельные сервера удобнее.

Дело в том, что если контора крупная - вероятна ситуация, когда некоторые (а иногда и многие) пакеты идущие в дистрибутиве приходится собирать самим.
В таком случае gentoo по удобству использования выигрывает в разы.
Вообще согласен - всё зависит от задач и опытности администратора.

>xen-hypervisor-3.3

Хм. Похоже, что это оно.
Неужели они таки отделили его от штатного гостевого ядра?

>Дело в том, что если контора крупная - вероятна ситуация, когда некоторые (а иногда и многие) пакеты идущие в дистрибутиве приходится собирать самим.

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

Наоборот. Как раз в этой ситуации выигрывают бинарные дистры.
Сборочная ферма + локальный репозитарий = –100 к гемору админов :)

Полагаю, под гентой тоже можно собрать один бинарник и потом раскидывать его по десяткам серверов. Но она все-таки является source-based дистром, а следовательно, этот подход реализован в ней не так хорошо, как сборка из сорцов на каждой машине.

> Полагаю, под гентой тоже можно собрать один бинарник и потом раскидывать его по десяткам серверов. Но она все-таки является source-based дистром, а следовательно, этот подход реализован в ней не так хорошо, как сборка из сорцов на каждой машине.

4.2, man emerge -B && emerge -k

Да не, скорее в gentoo проще настроить сервер компиляции и бинарные обновления. Есть binhost-ы и прочее. Оно существенно более продуманно, если интересно в чём именно - могу рассказать. Есть определённые ситуации, в которых эти плюсы особо ярко видны.

>4.2, man emerge -B && emerge -k

Мне лень читать вещи, которые, скорее всего, никогда мне не пригодятся :)

Поэтому задам три самый простых вопроса (для начала):
1. Реализован ли механизм подписывания и проверки подписей пакетов/репозитариев?
2. Существуют ли механизмы гибкого управления приоритетами, позволяющие задать приоритет (необходимость обновления) каждого бинарного пакета в зависимости от значения пары версия-репозитарий?
3. Можно ли использовать failover для репозитариев, например, на базе DNS round robin?

в случае проблем, в любом случае админу придется разбираться и искать причину, и как раз в этом случае надежнее использовать rhel/centos или debian.

>Да не, скорее в gentoo проще настроить сервер компиляции и бинарные обновления. Есть binhost-ы и прочее. Оно существенно более продуманно, если интересно в чём именно - могу рассказать.

Хм, вы меня заинтриговали. Расскажите, пожалуйста :)

Большое спасибо за информацию, пощупаю на следующей неделе центос на живом железе.

Поэтому задам три самый простых вопроса (для начала)

Вообще это можно разворачивать без проблем. Как угодно и по каким угодно параметрам, gentoo безумно гибок. Но надо потратить времени много. Если в машинах одинаковое железо (процессоры), то можно вообще собирать на одной тачке или распределенно с distcc, и потом забирать всем по nfs.

Немного смущает состояние xen/kvm в gentoo. Где-то месяца три назад проскакивало письмо от мейнтенера qemu с вопросом примерно следующего плана: `Мужики, у меня нет времени разбираться с qemu/kvm. И оно вообще хоть кому-нибудь надо из всего комьюнити?'.

А чем ты разруливаешь? libvirt'ом?

>Как угодно и по каким угодно параметрам, gentoo безумно гибок. Но надо потратить времени много.

Что-то мне подсказывает, что в качестве недостижимого идеала в конце этого пути (наращивания гибкости и увеличения времязатрат) сияет LFS :)

Если в машинах одинаковое железо (процессоры), то можно вообще собирать на одной тачке или распределенно с distcc, и потом забирать всем по nfs.

Как там насчет трех моих вопросов, а?

Немного смущает состояние xen/kvm в gentoo. Где-то месяца три назад проскакивало письмо от мейнтенера qemu с вопросом примерно следующего плана: `Мужики, у меня нет времени разбираться с qemu/kvm. И оно вообще хоть кому-нибудь надо из всего комьюнити?'.

Дело в том, что есть просто qemu, а есть qemu-kvm. Как нетрудно догадаться, второй из этих проектов суть первый, но заточенный под использование KVM.
Видимо, мейнтейнеру за глаза хватает первого проекта, и возиться со вторым ему влом.
Впрочем, причин отчаиваться пока нет, ибо qemu-kvm очень скоро собираются влить в основную ветку qemu (емнип).

А чем ты разруливаешь? libvirt'ом?

Виртуалками? Да, в основном libvirt. Очень сильно упрощает жизнь, и чем больше хостов и виртуалок, тем сильнее это заметно.

Хотя, конечно, он не везде соломку подстилает. Например, не умеет рулить томами в пуле на основе блочного устройства — приходится падать с небес абстракции к банальному fdisk'у :) Я, конечно, понимаю, что ССЗБ, use LVM, Luke и т.п., но все равно осадок остался.

Нет. В современных убунтах нет ядра для dom0, так что в качестве ксен-хостов они не катят.

In the meantime, a suitable workaround is to go ahead and install the Xen 3.3 hypervisor and userland tools for Intrepid, Jaunty, or whatever later version of Ubuntu you're running, and then go get a dom0 linux kernel from Debian.

Шутники однако :D

Для начала уточню - мы говорим про ситуацию, в которой у нас есть некий репозитарий бинарных пакетов для внутренних нужд компании, так?
Тогда ответы такие:
1. Вроде нет, механизмов подписи нет, однако, в данном случае они и не нужны. Они нужны при использовании какого-то внешнего репозитария. Однако разработчики про этот недостаток в курсе и обещали реализовать в дальнейшем.
2. Приоритет обновления? Сомневаюсь. Вопрос - зачем такое нужно?
3. Разумеется.


Плюсы:
1. встроенный механизм того, подходит ли пакет для данной системы или нет. Поскольку у нас происходит сборка с какой-то дополнительной оптимизацией или с какими-то дополнительными патчами/опциями становится актуально. Ибо не на всех системах нужен пакет именно с такими опциями. Соответственно подходящие пакеты выбираются с одного из бинарных репозитариев.

Это может быть.
Вообще в данной ситуации centos будет предпочтительней.

>У gentoo однако один минус - не весь софт в пакетах есть для неё.

А кто отменял установку софта из rpm? ;)

> А кто отменял установку софта из rpm? ;)

Ставь rpm-based дистрибутив и ставь из rpm. В дженте либо с дерева, либо с оверлея, либо самописный ебилд (пишутся они очень легко), либо получаем бардак в системе.

>Как там насчет трех моих вопросов, а?

Я конкретно с серверами компиляции не разбирался, но portage позволяет очень гибко управлять пакетами. Можно для определенных версий задать использовать стейбл или анстейбл, можно маскировать определенные версии. Про use-флаги я уж не говорю. В подписях особого смысла не вижу, ведь у нас всё будет в локальной сети. Второе тоже можно, просто это по-другому работает, читать выше. По-третьему не знаю, но мы же в локалке. О глобальных серверах с бинарными пакетами не знаю, но пользоваться не стал бы.

ибо qemu-kvm очень скоро собираются влить в основную ветку qemu (емнип).

А, я-то думал это и есть влитое :}

На серверы ставил openSUSE и Debian, обе системы никаких нареканий не вызывали. Удобно и то, и другое, правда в последнее время склоняюсь к тому, что на сервере лучше использовать Debian - в целом поудобнее, у него меньше своих специфических особенностей, по сравнению с openSUSE. Однако, для десктопа предпочитаю последнюю.

>Вроде нет, механизмов подписи нет, однако, в данном случае они и не нужны.

Очень даже нужны. Собранный пакет подписывается координатором группы сопровождения ПО и передается дежурному фтп-мастеру, который проверяет подписи и укладывает пакет в репозитарий, подписывая его уже ключом репозитария.
В результате, всегда понятно, кто едет ночью в лес в багажнике в случае чего :)

Приоритет обновления? Сомневаюсь. Вопрос - зачем такое нужно?

См. ниже.

встроенный механизм того, подходит ли пакет для данной системы или нет. Поскольку у нас происходит сборка с какой-то дополнительной оптимизацией или с какими-то дополнительными патчами/опциями становится актуально. Ибо не на всех системах нужен пакет именно с такими опциями. Соответственно подходящие пакеты выбираются с одного из бинарных репозитариев.

В принципе, это определенный аналог системы приоритетов, однако, я так понял, определение пригодности происходит автоматически.
А в промышленности удобна система, которая поддерживает как автоматические проверки (зависимости), так и ручную расстановку приоритетов.

Действительно, иногда проще сделать несколько репозитариев, имеющих пакеты с одинаковым названием, но с разной версией, разными патчами и разными опциями сборки. И каждый рабочий сервак обычно основан на довольно сложном миксе из этих пакетов. Именно поэтому и важна возможность вручную менять «концентрации» в этом «растворе». При правильно выполненном разбиении на репозитарии и при правильной расстановке зависимостей, проектирование даже масштабных переформирований производится относительно просто.

Это дебиан.

Кстати, в следующем после squeeze выпуске поддержку ксена тоже собираются прекратить.

про SLES - 4.2
пруф: http://www.novell.com/products/server/eval.html
Модель использования такая же, как у RHEL - eval и 60 дней апдейтов. Дальше - либо приобретение, либо отказ от апдейтов.

Gentoo или debian stable. А по поводу центоси и опенсъюз... (O_(O_O)_O) они смотрят на них как на гогно.

если нужен хen то сусе, любое ядро собираемое для суси есть с xen, хоть 34-rc4 на данный момент бери, 4 xen есть с ранних rc, xen в сусе кагбэ основной инструмент виртуализации, а краснашапка и центос тяготеют больше к kvm.

>про SLES - 4.2

Покажите мне аналог CentOS для SLES, а?

soft of prorpietary - что-нибудь хорошего/плохого про VMware ESXi скажешь?

Не скажу. Общаться не приходилось.

>Вы не согласны, что yum убог?

Не согласны.

>Дело в том, что если контора крупная - вероятна ситуация, когда некоторые (а иногда и многие) пакеты идущие в дистрибутиве приходится собирать самим.

Если контора крупная, то приобретается коммерческий дистрибутив в техподдержкой. И в крупной конторе, особенно на «продакшн»-серверах просто НЕ ПОЗВОЛЯТ самим собирать пакеты. Ибо себе дороже. А вот если домашний сервак, а админ - перфекционист и любитель самостоятельной сборки, то можно и генту.

Я к тому, что необязательно начинать с openSUSE, а потом покупать и переходить на SLES. Можно изначально поставить SLES и, если устроит, то, как только приспичит, купить поддержку.
Установить и использовать SLES можно бесплатно.

P.S. да, бесплатного клона он не имеет

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

В большинстве случаев такие конторы не могут себе позволить покупку промышленного дистра, а установка версии с коротким сроком поддержки выглядит просто свинством.

>Если контора крупная, то приобретается коммерческий дистрибутив в техподдержкой. И в крупной конторе, особенно на «продакшн»-серверах просто НЕ ПОЗВОЛЯТ самим собирать пакеты. Ибо себе дороже.

Это не крупная, это средненькая конторка.

Крупная контора, всоблыво айтишной направленности, может позволить себе собственный отдел сопровождения софта. В таких условиях, в принципе, без разницы, что брать, но даже крупные фирмы транжирством заниматься не склонны, так что при выборе между CentOS и RHEL предпочтение обычно отдается первому.

> Установить и использовать SLES можно бесплатно.

60 дней же, разве нет?

Дальше просто нельзя получать обновления

Цитата с сайта:

NOTE: The only limitation of this evaluation software is the duration of your free access to update.novell.com.

>Да не, скорее в gentoo проще настроить сервер компиляции и бинарные обновления.
йопаный стыд