# Gentoo как дистрибутив небольшой организации

## chiko

Доброго времени суток!

Такой вопрос: в организации, имеющей 4GB инет-трафика в месяц (ну не добывает она нефть) и насчитывающая около 30 компов в локалке потребовалось воткнуть на половину парка машин Linux. Так как мне по душе Gentoo, задумался над вопросом как же держать все разношерстные тачки (P3, P4, Athlon-XP и Athlon 64bit) как говорится "up-to-date". Иметь несколько /etc/make.conf , собирать в бинарники на самой мощной машине под каждый камень и расставлять как emerge -k packagename ? Слишком много ручной работы, автоматизировать бы... Если только crontab + монтировать удаленный /usr/portage/packages/All на каждую тачку?

К тому же делать emerge sync с каждой машины, считаю глупо. Подымать полноценное зеркало накладно.

Что предполагается использовать на ~15 машинах: Xorg, GNOME (на некоторых fluxbox), OpenOffice, Sylpheed-Claws, FireFox etc. Обычная пишущая машинка должна получиться в результате с выводом печати на расшаренные принтеры.

Может у кого есть опыт нахождения удобного, требующего минимум вмешательства человека, решения? А то уже поглядываю в сторону подъема терминал-сервера, но тогда окажутся лишними затраты на недавно приобретенные Athlon 64bit & P4.

Спасибо.

----------

## AlexSuslov

У меня работает примерно так. 

На машине которая являеться прокси сервером запущен в cron на 13:00 emerge sync (это съедает примерно 5 мб в день)

далее portage раздаеться rsync. Потребителей несколько. Я себе на ноутбук унощу. 

Машина которая собирает пакеты( для интела). Cron в 23:00 emerge sysc && emerge -uDb world.

Причем поскольку у меня 2 компа не выключаються то запущен distcc.

В /etc/make.conf

MAKEOPTS="-j5"

FEATURES="distcc"

DISTCC_DIR="/home/tmp/.distcc"

Пакеты укладываю на NFS

Далее их можно использовать.

Правда это все работает в качестве эксперимента. На сервера продолжаю ставить Suse.

----------

## YD

 *YD wrote:*   

> /usr/portage - выделен свой раздел в ~500MB(кушает около 100).Полезно повесить на cron, чтоб архивировалось, удалялось полностью(можно umaunt && mkfs && mount) и распаковывалось заного. Очень эффективно при использовании reiser4.
> 
> /usr/distfiles - зашарен по NFS, чтобы одно и то же не качать на все комки.
> 
> /usr/packages - в следствии разных архитектур, на каждой машинке своя.
> ...

 

Не бойся, глаза боятся, а руки очень быстро делают. rsync у тебя УЖЕ стоит, конфиг только подредактировать, чё там парится. Ставишь потом distcc и окуеваешь с быстродействия (: На машинки со схожей архитектурой можешь /usr/packages зашарить по NFS между ними. Например на сервере сделаешь разделы /usr/distpackages/arch. Где arch pentium3, pentium4, ahtlon-xp и т.п.

----------

## cha-chaynik

 *chiko wrote:*   

> Может у кого есть опыт нахождения удобного, требующего минимум вмешательства человека, решения? А то уже поглядываю в сторону подъема терминал-сервера, но тогда окажутся лишними затраты на недавно приобретенные Athlon 64bit & P4.

 

У меня есть подобный опыт с виндовс (прошу не плевать в меня). Корпоративный стандарт PC - Dell GX280 (ранее был GX270). Учитывая, что машины идентичны, серьезно настраивается только одна машина, после чего, с этой машины делается образ, который заливается на все новые машины. Итого, работа с новой машиной заключается только в том, чтобы дать ей имя и включить в домен.

С Линуксом, в Вашем случае, тоже можно поступить подобным образом, собрать "эталонный Линукс":

- собрать ядно с поддержкой всех имеющихся в наличии чипсетов и железок

- поставить необходимый софт

- настроить xorg для наиболее часто встречающейся видеокарты

- сделать образ с "эталона" и разливать его. Править только конфиг xorg-а и имя машины.

 *chiko wrote:*   

> как же держать все ... как говорится "up-to-date".

 

В защищенной сети нет большого смысла держать все "up-to-date". Это, скорее, критично только для серверов, "торчащих" наружу, да и то, только при появлении уязвимостей или при появлении обновлений с новым необходимым функционалом в используемом п/о.

----------

## dish

У меня в отделе собран кластер из 12 разношерстных машин: начиная от первых пней и заканчивая прескотами, бартонами и AMD64. На роутере тоже Дженту. Все эти машинки замечательно синкятся с роутером и качают с него пакеты, а так же вполне хорошо работают друг с другом по distcc.

Дома тоже достаточно разношерстная комбинация из трех машин и роутера и все точно так же.

Абсолютно никаких проблем с синком и обновлениями. А насчет ядра и xorg.conf -- именно так и делай. ИМХО, это действительно оптимальный путь.

----------

## viy

 *chiko wrote:*   

> К тому же делать emerge sync с каждой машины, считаю глупо. Подымать полноценное зеркало накладно.

 

Глупо --- согласен. Накладно?!

Выбираешь 1 машину, которая будет делать emerge sync из сети. Далее 2 варианта:

1) поднять rsyncd демон и настроить его, чтобы он стандартное дерево /usr/portage предоставлял клиентам;

  На клиентских машинах правишь /etc/make.conf, указывая свой SYNC.

2)  расшариваешь /usr/portage через NFS и на клентских машинах монтируешь, тоже в /usr/portage.

Для distfiles у меня настроен такой кэш. Это позволяет на клиентских машинах удалять distfiles после установки софта. А шарить их через NFS мне как-то не по душе.

----------

## YD

Мне почему-то кажется, что по NFS portage будет тормозить с маленькими файлами. Ну хотя такие программы, как esearch & eix могут помочь отвести от этого внимание.

----------

## viy

 *YD wrote:*   

> по NFS portage будет тормозить с маленькими файлами.

 

Не замечал. Точнее даже не обращал внимание. На самом деле, на большинстве серверов portage монтируется редко, т.к. я предпочитаю не лезть в дебри, если все работает хорошо. И в те редкие разы работы с emerge я не задумываюсь о скорости, главное тут удобство.

----------

## rusxakep

Шарить надо по SHFS, а не NFS  :Smile: 

----------

## YD

Если сделать SSH тунель для NFS сервисов, работать будет стабильней с меньшими ограничениями. Но на кой хрен, шифровать общедоступные данные?

----------

## rusxakep

А зачем шарить NFS?  :Smile:  Сразу SHFS напрямую. И прозрачно и секьюрно. В отличии от portmap

----------

## WI

 *viy wrote:*   

>  *chiko wrote:*   К тому же делать emerge sync с каждой машины, считаю глупо. Подымать полноценное зеркало накладно. 
> 
> Глупо --- согласен. Накладно?!
> 
> Выбираешь 1 машину, которая будет делать emerge sync из сети. Далее 2 варианта:
> ...

 

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

----------

## rusxakep

Русские славны не тем, что влезают в такие дебри, в какие не влезает ни одна нация, а тем, что они еще умудряются из них выбраться  :Smile: 

----------

## AlexSuslov

Незнаю про дебри, но Китайцы мне расказали анекдот про Русских. 

Пока два китайских землекопа копают канаву. Два русских землекопа решают как правильно копать.

----------

## jaffar

Про rsyncd и disctccd это правильно - там все просто. 

Еще можно добавить, что есть такая штука, как http-replicator. Работает как http-proxy для дерева portage. Если есть distfile в его кэше он берет его оттуда, если нет - берет из инета. 

вот линк про его настройку:

http://gentoo-wiki.com/HOWTO_Download_Cache_for_LAN-Http-Replicator

Можно еще поставить ccache - тоже будет польза.

----------

## bukazoid

так способа и не нашли:

как на одной машине собрать пакеты под разное железо с оптимизацией под него

без распределённой компиляции и прочего изврата ?

----------

## YD

При обьчном методе установки, система собирает сама себя, т.е. код должен быть нативном для системы. Есть вариант собрать не саму себя, а чужую систему с помощью ENV-var'a ROOT (man emerge) и с сопутствующим изменением CHOST/CBUILD/CTARGET/CFLAGS/CXXFLAGS/USE/ACCEPT_KEYWORDS и т.д.

Результат не гарантирую, но по логике должно работать.

з.ы. Без изврата только тулзами, которые изврат прикрывают интерфейсом :>

----------

## ManJak

 *rusxakep wrote:*   

> Шарить надо по SHFS, а не NFS 

 

SHFS не юзал полезу читать, кинь, если не в падлу ссылки, может будут лучше, чем найду =)))

Похоже, что шифрует, судя по абревиатуре  :Very Happy: 

----------

## bukazoid

 *YD wrote:*   

> При обьчном методе установки, система собирает сама себя, т.е. код должен быть нативном для системы. Есть вариант собрать не саму себя, а чужую систему с помощью ENV-var'a ROOT (man emerge) и с сопутствующим изменением CHOST/CBUILD/CTARGET/CFLAGS/CXXFLAGS/USE/ACCEPT_KEYWORDS и т.д.
> 
> Результат не гарантирую, но по логике должно работать.
> 
> з.ы. Без изврата только тулзами, которые изврат прикрывают интерфейсом :>

 

собственно то что хотел услышать.

----------

## ManJak

Нашел сразу на свежем мясе =)))

Кому интересно:

SHFS (sshfs) is a simple and easy-to-use Linux kernel module which allows you to mount remote filesystems using a plain shell (SSH) connection. It supports some nice features like file cache for access speedup, and a Perl server, etc.

About shfs

Shfs is a simple and easy to use Linux kernel module which allows you to mount remote filesystems using a plain shell (ssh) connection. When using shfs, you can access all remote files just like the local ones, only the access is governed through the transport security of ssh. Shfs supports some nice features:

    * file cache for access speedup

    * perl and shell code for the remote (server) side

    * could preserve uid/gid (root connection)

    * number of remote host platforms (Linux, Solaris, Cygwin, ...)

    * Linux kernel 2.4.10+ and 2.6

    * arbitrary command used for connection (instead of ssh)

    * persistent connection (reconnect after ssh dies) 

Похоже ресурсов жрет конкретно, хотя, запомню, оно того иногда стоит  :Razz: 

----------

## YD

SHFS помему достаточно известна, но некоторые её особенности являются недостатком. Возможно в новых версиях что-то изменилось к лучшему, но первые версии, кроме секьюрности с NFS не сравнить.

----------

## rusxakep

shfs немного жрет - не больше чем SSH  :Smile:  Скорость перекачки конечно не ахти - но ...

----------

## lend

 *rusxakep wrote:*   

> shfs немного жрет - не больше чем SSH  Скорость перекачки конечно не ахти - но ...

 Скорость перекачки в 10 раз меньше, чем у wget-а. но тем не менее, но...

----------

## YD

SCP на 100Mbit'ном линке передаёт примерно 5-6MiB/s с моего рутика. FTP ~ 11MiB/s

----------

## GOROD

ну действительно трудно понять вас русских.

1. rsync portage

ну что сложно поднять на машине rsync сервер???

2. /usr/portage/distfiles монтируется по nfs

3. /usr/packages также по nfs.

----------

## bukazoid

 *GOROD wrote:*   

> ну действительно трудно понять вас русских.
> 
> 1. rsync portage
> 
> ну что сложно поднять на машине rsync сервер???
> ...

 

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

----------

## dish

А ночью можно не работать, а компилировать.

Ну, не так много они компилируют, к тому же, есть distcc и ccache  :Wink: 

----------

## bukazoid

 *dish wrote:*   

> А ночью можно не работать, а компилировать.
> 
> Ну, не так много они компилируют, к тому же, есть distcc и ccache 

 

на счёт много это вопрос относительный 

distcc & rpc & nfs считаю дырой в системе (особенно в ночное время  :Smile:  )

учитавая ccache у меня на 1.7 Athlon (самая мощьная машина) за ночь при обновлении kde+oofice(хотя я ими не пользуюсь) с 21.00 -8.00 система не всегда успевает собрать всё (нагруз немалый в любое время , в среднем груз CPU ниже 20% не падает)

----------

## YD

Поэтому я говорю: используй binhost, всего одно FTP открыто, а компилить на сервере.

----------

## dish

Согласен.

Но такой (резонный) вопрос:

а как часто на рабочих станциях надо делать emerge -uD world?

Можно написать скриптик, который будет по ssh на всех машинах запускать distcc, маунтить по nfs дисты с деревом и компилить. А потом таким же скриптиком останавливать все это. Если конфигурация стандартная, то собрал дистриб на одной машинке, сделал бинарники и все.

А на время компиляции, например выходные, блокировать доступ в инет кронтабом.

----------

## viy

 *dish wrote:*   

> а как часто на рабочих станциях надо делать emerge -uD world?

 

Я считаю, что пока нет жалоб на глюки от пользователей и дырок в софте, ничего трогать не стоит.

Как в старом анекдоте про программера, его сына и солнышко.

----------

## dish

ОФФТОПИК: что за анекдот?

----------

## viy

Сидит программист глубоко в отладке.

Подходит сынишка:

- Папа, почему солнышко каждый день встает на востоке, а садится на западе?

- Ты это проверял?

- Проверял.

- Хорошо проверял?

- Хорошо.

- Работает?

- Работает.

- Каждый день работает?

- Да, каждый день.

- Тогда ради бога, сынок, ничего не трогай, ничего не меняй.

Взял тут.

----------

## WI

А еще неплохо бы deltup поставить, дабы траффик экономить.

----------

## chiko

Так к приемлемому решению и не пришли... Может ли кто-либо набросать краткий howto на тему?

----------

## viy

Это не реально.

Сколько организаций, столько требований и возможностей. Последние накладывают жесткие рамки.

Если рамок нет, то все упирается в админа. И тут уже на вкус и цвет...

Дискуссия явно показала, что часть админов использует одни методы, часть --- другие.

Для себя я сделал такие выводы --- организовывается мастер-сервер, который шарит все необходимые данные. На нем же хранятся бинарные пакеты для каждой из используемых архитектур. В принципе логично --- 1 сервер, меньше геммороя с настройкой и поддержкой.

----------

## dish

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

В чем плюсы генты, это то, что it's all about choices, а про минусы viy писал в соседнем топике (Oracle, PostreSQL)

----------

