[devel] Re: README.ALT wanted

[Michael Shigorin <mike@lic145.kiev.ua>]

[-- Attachment #1.1: Type: text/plain, Size: 365 bytes --]

On Tue, Apr 16, 2002 at 01:52:49PM +0400, Dmitry V. Levin wrote:
> > Часть III.  общесистемное администрирование
> Q: Были внесены изменения в конфигурационные файлы; как синхронизировать
[skip]
[done]

Последняя версия -- в аттаче.  Станислав, заберите, пожалуйста.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

[-- Attachment #1.2: README.ALT --]
[-- Type: text/plain, Size: 6911 bytes --]

Часть I.  root squashed

Q: почему руту не ходит почта?

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

Если это не устраивает (нужен другой пользователь), загляните в
файл /etc/postfix/aliases; после правки необходимо выполнить от
имени root следующую команду:

	newaliases


Q: почему руту не дают собирать RPM? Выдается ошибка:
"rpmb: сборка пакетов запрещена для привилегированного пользователя"

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

Для дополнительной информации обратитесь к содержимому
/usr/share/doc/rpm-4.0.4/README.ALT .


Q: у рута сломана локаль!

A: У пользователя root настроена локаль POSIX в целях устранения
возможных проблем с системными сервисами, использующими этот
пользовательский account для своего запуска. В частности, последствия
применения не-POSIX локали для root становятся видны в файлах протоколов
syslog в виде локализованных дат, которые не воспринимаются большинством
анализаторов системных протоколов.

Крайне не рекомендуется выполнять ежедневную работу от имени root
-- а для администрирования должно хватить sudo и нормального
локализованного пользовательского аккаунта.

Специфические настройки локали для любого пользователя (в том
числе и root) можно изменить в файле ~/.i18n .


Q: CUPS не конфигурируется -- выдает ошибки даже после ввода
правильного пароля root!

A: для повышения безопасности CUPS теперь обычно работает от
имени пользователя вместо root, при этом он не может быть
переконфигурирован.  Есть два варианта для выполнения
конфигурирования и других административных задач:

A1: как предлагают разработчики:

	service cups admrestart

(делаем административные дела)

	service cups restart

(печатаем)

A2: вернуть все к старому варианту: в /etc/cups/cups.conf
раскомментировать

	runasuser no; 
	noizvrat  yes;

Далее

	service cups restart

(печатаем и админим в одной обойме)


Q: рута не пускают по ssh, пароль правильный!

A: обычно принято заходить по ssh пользователем и лишь тогда
делать sudo (или su).  Мотивация -- во-первых, для
административного доступа к системе требуется два пароля;
во-вторых, администрирование в этом случае не анонимно
(идентифицируется по первоначально вошедшему пользователю).

Если в силу каких-либо обстоятельств необходим ssh root login --
скорректируйте параметр PermitRootLogin в файле
/etc/openssh/sshd_config и выполните команду

	service sshd reload

-- но считайте, что вас предупредили.

Если логин осуществляется с сетевой машины -- см. тж. ниже
(насчет hosts.allow).


Часть II.  notwork troubles

Q: почему после установки сервера и его активации (в ntsysv,
DrakConf, /etc/xinetd.d/*) он недоступен из сети?

A1: по умолчанию в ALT Linux xinetd сконфигурирован с опцией
only_from = 127.0.0.1, позволяющей доступ к сервисам,
запускающимся из-под xinetd, только с локальной машины.

Для обеспечения доступа из сети отредактируйте или
закомментируйте эту строку в /etc/xinetd.conf; в последнем случае
настоятельно рекомендуем ввести ограничения по необходимости в
индивидуальные файлы в каталоге /etc/xinetd.d/ .  После внесения
изменений в конфигурацию xinetd необходимо учесть их командой

	service xinetd reload

A2: если проблема не в этом -- обратите внимание на настройки
файрвола, которые можно получить при помощи команд

	service iptables status

(для Linux 2.4) или (для Linux 2.2)

	service ipchains status

A3: проверьте содержимое файлов /etc/hosts.allow и /etc/hosts.deny


Q: Почта не ходит!!

A: по умолчанию в соответствии с политикой безопасности postfix
настроен на работу только с локальными почтовыми клиентами, а
также может отправлять почту на внешние SMTP-сервера. Если вам
необходимо получать или пересылать почту через данный сервер с
внешних хостов, отредактируйте файлы конфигурации postfix.  Для
нормальной работы postfix с внешней почтой необходим доступ к
корректно настроенному серверу DNS.


Часть III.  общесистемное администрирование

Q: почему пуст /etc/shadow?  Неужели он не используется?!

A: в ALT Linux используется реализация Trusted Computing Base
(TCB), выполненная Rafal Wojtczuk и Solar Designer в рамках
проекта Openwall GNU/*/Linux. В этой модели каждый пользователь
имеет собственный shadow-файл, хранящийся в
/etc/tcb/имя_пользователя/shadow, доступ к которому имеют только
сам пользователь (чтение/запись) и программы, исполняющиеся с
sgid auth. В результате, доступ к паролям конкретного
пользователя не приводит к возможности скомпрометировать всю
систему.  О преимуществах и недостатках этой модели подробно
описано в tcb(5).  Для всех приложений, работающих в системах с
поддержкой NSS (например, ALT Linux) и использующих только чтение
паролей системными средствами, схема TCB прозрачна.


Q: проблемы с паролями при подключении ИБП APC с "фирменным" ПО
   PowerChutePlus.

A: в старых дистрибутивах пароли шифровались при помощи более
слабых алгоритмов, чем необходимо сейчас -- и, к сожалению, PC+
занимается самодеятельногстью по части обработки паролей, не
используя системные методы аутентификации.

Проблема в том, что он не понимает пароли, закодированные
blowfish.  Если создать пользователя, под которым работает
xpowerschute, и ему назначить пароль, отключив криптование через
blowfish, то все заработает, главное -- ему потом не менять
пароль при включенном blowfish.

Это можно сделать так:

1. Заменить "на секундочку" в файле /etc/pam.d/system-auth строку
password        required        /lib/security/pam_tcb.so use_authtok shadow fork prefix=$2a$ count=8 write_to=tcb
на
password        required        /lib/security/pam_tcb.so use_authtok shadow fork prefix=$1$ count=8 write_to=tcb

2. Переустановить пароль пользователя, под которым работает
PowerChutePlus, с помощью команды passwd

3. Вернуть файл /etc/pam.d/system-auth в прежнее состояние.


Q: Были внесены изменения в конфигурационные файлы; как
синхронизировать эти изменения во всех многочисленных chrooted
environments, используемых в системе?

A: Запустите команду

	/sbin/update_chrooted conf


Q: А если были изменены системные библиотеки?

A: Обычно это происходит в ходе обновления пакетов; в этом случае
синхронизация библиотек и обновление /etc/ld.so.cache произойдет
автоматически. В противном случае следует запустить команды

	/sbin/ldconfig
	/sbin/update_chrooted lib

P.S. /sbin/update_chrooted раньше назывался
/usr/sbin/update_chrooted .



Благодарности
~~~~~~~~~~~~~
Вячеслав Диконов <sdiconov@mail.ru>
Любимов А.В. <avl@l14.ru>
Власенко Олег <cornet@altlinux.ru>
Alexander Bokovoy <a.bokovoy@sam-solutions.net>
Dmitry V. Levin <ldv@alt-linux.org>

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]