Summary: | Уточнение минимального списка сервисов, запускаемых после установки | ||
---|---|---|---|
Product: | ALT Linux Centaurus | Reporter: | enp <enp> |
Component: | Состав | Assignee: | Anton V. Boyarshinov <boyarsh> |
Status: | NEW --- | QA Contact: | QA p6 <qa-p6> |
Severity: | normal | ||
Priority: | P3 | CC: | aen, evg, ldv, mike |
Version: | 7.0 | ||
Hardware: | all | ||
OS: | Linux | ||
Bug Depends on: | |||
Bug Blocks: | 27685 |
Description
enp
2012-12-05 14:51:03 MSK
Существует много сценариев, но программа установки не должна их все предусматривать для этого существует возможность сделать иные дистрибутивы. 2enp: хорошо бы описать хотя бы один распространенный сценарий, при котором все это не нужно. 2boyarsh: отсутствие su это, возможно, блокер. На усмотрение RM. (В ответ на комментарий №1) > Существует много сценариев, но программа установки не должна их все > предусматривать для этого существует возможность сделать иные дистрибутивы. Иные дистрибутивы не смогут стать СПТ, а иначе б я и не беспокоился ;) > 2enp: хорошо бы описать хотя бы один распространенный сценарий, при котором > все это не нужно. Сценарий, в котором не нужны rpcbind/rpc.statd/avahi-daemon/named? Честно говоря, мне труднее представить сценарий, в котором они нужны. Ни на одном из поддерживаемых мною серверов (RDBMS, Web, VoIP, специализированное ПО для внутреннего употребления) они не запущены. Если сервер живет не внутри корпоративной инфраструктуры, а где-то на хостинге, то я вообще не могу придумать ни одной уважительной причины их запускать. Да и вообще мы переворачиваем ситуацию с ног на голову: любые сервисы должны запускаться при необходимости, а не в надежде на то, что они кому-то понадобятся. Когда-то была практика (не знаю, сохранилась ли) опускать sshd на десктопах по дефолту и это никого не смущало. > 2boyarsh: отсутствие su это, возможно, блокер. > На усмотрение RM. Разумеется. Но я очень прошу его сделать несколько лишних chkconfig off в том случае, если ни одна галочка при установке не выбрана. А еще в рассылках регулярно появляются мнения о том, что и dbus на сервере не очень полезен (из последнего - http://lists.altlinux.org/pipermail/devel/2013-May/197376.html). (В ответ на комментарий №3) > А еще в рассылках регулярно появляются мнения о том, что и dbus на сервере не > очень полезен (из последнего - > http://lists.altlinux.org/pipermail/devel/2013-May/197376.html). Уточнил название, давайте обсудим что можно/нужно сделать. // Надеюсь, что su уже в комплекте. (В ответ на комментарий №3) > что и dbus на сервере не очень полезен Отключенный относительно безвреден, suid/sgid binaries там нет. По server-mini могу заметить, что комплектация без dbus сейчас не содержит и wpa_supplicant, что не совсем приятное ограничение (разве что вынести его в дополнительно устанавливаемые пакеты). Вчера пришлось устанавливать и настраивать сервер, к которому требование наличия сертификата ФСТЭК для устанавливаемого дистрибутива было обязательным. По привычке я рекомендовал Альт, но дефолтная инсталляция со всеми выключенными галочками - это просто чудовищно, может потому что отвык :) Я понимаю, что изменить что-то быстро и особенно для сертифицированных решений совершенно нереально, поэтому для следующих подобных инсталляций либо буду либо собирать что-то на основе своего m-p-l и пакетной базы c6 (я понимаю, что это уже не сертифицированное решение, но вряд ли у сертифицирующих органов достаточно квалификации, чтобы это установить), либо буду смотреть на другие дистрибутивы (у CentOS 6.5 минимальная комплектация была приемлемой, может и у клонов окажется не сильно хуже). Но в отношении с7 и p8 надежда есть? Предлагать помощь глупо, это не технический вопрос, у mike@ (пусть на m-p) давным давно все хорошо, исправить m-p-d гораздо легче, чем наворотить то, что сейчас есть - как мне кажется. Если хочешь, посмотри подключаемое и выскажись по нему: http://git.altlinux.org/people/boyarsh/packages/?p=mkimage-profiles-desktop.git;a=blob;f=use.mk.in;h=35754e2025e6328940537dd304547b26090c0ddb;hb=1311a32154a6961691e16679e8983a9b69b6386f#l258 Мне кажется, что тактически разумнее накидать и зафиксировать скрипт зачистки, который делает как минимум chkconfig до состояния "слушает только sshd". А решать профильным образом уже после переезда Centaurus на m-p, что я надеюсь сделать возможным к 8.0, но оказалось неразумным к 7.0 и тем более к 6.0. Сертифицирующие органы могут спросить номерной экземпляр установочного носителя. (В ответ на комментарий №7) > Если хочешь, посмотри подключаемое и выскажись по нему: > http://git.altlinux.org/people/boyarsh/packages/?p=mkimage-profiles-desktop.git;a=blob;f=use.mk.in;h=35754e2025e6328940537dd304547b26090c0ddb;hb=1311a32154a6961691e16679e8983a9b69b6386f#l258 Речь о use-spt? Не вижу связи, честно говоря, между перечисленным и сейчас обсуждаемым, кроме слова СПТ :) > Мне кажется, что тактически разумнее накидать и зафиксировать скрипт зачистки, > который делает как минимум chkconfig до состояния "слушает только sshd". Да, тоже вариант, или даже копия уже установленной и зачищенной системы. > А решать профильным образом уже после переезда Centaurus на m-p, что я надеюсь > сделать возможным к 8.0, но оказалось неразумным к 7.0 и тем более к 6.0. Вот, именно это я надеялся услышать! > Сертифицирующие органы могут спросить номерной экземпляр установочного > носителя. Им даже можно предъявить этот носитель - он в любом случае будет. Но есть ли способ доказать, что система установлена именно с него или наоборот? |