[Devel] [Задача 6609] Установить и зафиксировать сервер ALT Linux Ковчег в Virtualbox

[Evgeny Sinelnikov]

Думаю, что этот вопрос бессмысленно обсуждать в баге.

10 декабря 2010 г. 16:23 пользователь  <bugs на lists.etersoft.ru> написал:
> http://bugs.etersoft.ru/show_bug.cgi?id=6609
>
> Devaev Maxim <mdevaev на etersoft.ru> changed:
>
>           What    |Removed                     |Added
> ----------------------------------------------------------------------------
>       Hours Worked|                            |0.25
>
> --- Comment #7 from Devaev Maxim <mdevaev на etersoft.ru> 2010-12-10 16:23:52 MSK ---
> (В ответ на comment #5)
>> Один из сетевых интерфейсов в Ковчеге предполагается настроить как статический,
>> потому что через него предполагается получить доступ к установленному серверу,
>> что исключает использование сервера совместно с DHCP, что логично для сервера.
>
> Я бы не сказал, что это логично. Предположим, что у нас имеется большая сеть с
> несколькими серверами. Один из этих серверов, уже настроенный со стороны,
> занимается раздачей интернетов, dhcp и прочих замечательных вещей. Чтобы иметь
> возможность централизованного управления сетью, мы можем задать диапазон для
> энного количества клиентов и некоторый диапазон статических адресов, выдаваемых
> серверам. Далее, мы хотим добавить в нашу сеть еще один сервер. Пусть это будет
> торрентокачалка и файлопомойка. Мы устанавливаем Альт-сервер и внезапно
> осознаем, что он хочет именно статический адрес. А у нас вся сеть динамическая.
> Из такой ситуации я вижу два выхода:
> 1) Администратор назначает отдельный IP для сервера вне какого-либо из
> диапазонов DHCP, подключается к нему откуда-то извне, перенастраивает сервер
> для использования DHCP и затем радуется, на сколько это возможно, бурно.
> 2) Искореняется желание Альт-сервера иметь статический адрес. Это ограничение,
> по сути, было вызвано тем, что сервер должен иметь заранее определенный адрес.
> НО параметры для подключения к серверу будут выведены во фреймбуффере, поэтому
> администратор в любом случае узнает, как ему подключиться к его серверу. А
> картинку можно уж сгенерировать динамически.

Мой вариант:
3) Задаём в dhcp ip для сервера по маку (через web-interface) это
делается тривиально. Указываем на сервере тот ip, который задан в dhcp
статически. Может быть не сразу. Во время установки используем dhcp, а
потом переключаемся на статику.


> Мне больше нравится второй вариант, поскольку он уменьшает количество ненужных
> телодвижений для того, чтобы встроить в сеть новый сервер. Как живой пример -
> сколько сейчас нужно произвести действий, чтобы установить к нам в виртуалку
> сервер? Кошмар.

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

Во-первых, в домашней сети зачастую роль роутера и dhcp-сервера играет
ADSL-модем или миниатюрный Ethernet-маршрутизатор, он же по
совместительству 4-5 портовый коммутатор (aka switch). Поскольку
lease-файл в таких устройствах  dhcp-сервером не хранится, ибо флешка,
то для _надёжной_ настройки сети _разумно_ задать назначение
ip-адресов для всех известных устройств по макам. Иначе могут быть
конфликты на перезагрузках роутера, в котором dhcp-сервер "забывает"
адреса он уже выдавал.

Во-вторых, сервер - это всё-таки сервер, даже домашний. _Разумно_,
чтобы ip-адрес у него был всегда одинаковый. Не менее разумно, чтобы у
него не было проблем во время загрузки из-за того, что не настроена
сеть. Дело в том, что многие сервисы довольно странно себя ведут, если
на момент загрузки не подняты все необходимые интерфейсы, в частности
eth0. Поэтому _разумно_ делать интерфейс любого сервера статическим.
При этом, чтобы избежать конфликтов в dhcp, никто не мешает задать в
настройках dhcp-сервера дополнительному серверу соотвеnствие ip по
маку.

Единственный вариант, когда возникает проблема - это случай
необходимости использования dhcp на первых этапах установки или
упрощённой, хотя и менее надёжной, эксплуатации сервера.

Необходимость на первых этапах установки опишу подробнее - это важно.
- Даже если настраивать на сервере статику на этапе его установки,
проще получить ip и настройки по dhcp
- Чтобы задать на dhcp-сервере соответствие по маку проще, чтобы
клиент сначала получил ip из пула. Тогда его будет легко привязать к
заданному ip из интерфейса управления dhcp-сервера, который уже выдал
какой-то ip из пула. В этом случае нужно переписывать вручную
mac-адрес


Далее хочу поддержать альтов в их решении требований статики - они
поднимают с ходу LDAP, Kerberos, web-сервисы альтератора. Чтобы оно
взлетело и заработало, требуется, что бы сеть была и сразу. А DHCP в
сети может и не быть. Они заложились на более общий сценарий
использования и, в чём-то, это правильно.

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

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



-- 
Sin (Sinelnikov Evgeny)