(Zahar Kiselev, 2:5030/382) Вот что достаточно сделать чтобы работало: Взять с ftp.kernel.org ядро, которое умеет "на ходу" менять лимиты на количество открытых файлов. Hасколько я знаю, начиная с 2.2.10 это работает, как делается - сказано в том числе и в этом faq. 1С отличается совершенно неприличными аппетитами по части количества открываемых файлов - надо ставить из расчета где-то 800 на каждого виндового пользователя, потому что есть особо "продвинутые", которые две-три копии 1С у себя на компе запускают. Взять Самбу например 2.0.5a - это последняя, которая работала у меня. Важно, чтобы она понимала параметр в smb.conf "ole locking compatibility"(надеюсь теперь не наврал в написании), установить его в "no". Внимание! До меня доходили сведения, что в какой-то даже более новой чем 2.0.5а Самбе этого параметра нет. Остальное настроить в соответствии с любой из многочисленных рекомендаций по установке Самбы, главное - не запрещать ей работать с блокировками(я знаю одного человека, который до этого додумался). Запускать надо не через inetd, а как отдельный демон, вернее у Самбы их два - smbd и nmbd. Чтобы несколько пользователей могли лезть в одну базу - поместить их в одну юниксовую группу и поставить права на файлы так, чтобы был доступ на запись для группы. Есть еще одна мелкая особенность - Самба при работе хочет создать файлики browse.dat, wins.dat - так вот надо поставить права так, чтобы она могла их читать в том числе и тогда, когда работает от имени виндового пользователя - иначе могут быть большие таймауты при выполнении команды net use в виндах, и может не работать столь любимое многими чайниками "сетевое окружение". Если после очередного падения 1С винды говорят что база заблокирована - то можно подкрутить в конфиге Самбы параметр, отвечающий за принудительное снятие "зависших" блокировок(см man). Поставить например три минуты, меньше не стоит, тогда через три минуты в базу можно будет войти. Рекомендуется также поставить keepalive-таймаут, чтобы соединения не висели бесконечно. Желательно при помощи файрволла закрыть для доступа "снаружи" те два порта, через которые Самба работает. Причем не только на Линукс, а на всю сеть. А теперь - совет тем, кто хочет избавиться от проблем, вызванных наличием 1С у него в сети. Hадо запускать 1С на NT-сервере, причем желательно sql-версию, она менее критична к сбоям (не повреждаются данные), а доступ осуществлять с линуксовых машин через Citrix Meta Frame. При этом ситуация меняется "до наоборот" - вместо одного линукса и кучи виндов вокруг - получаются _одни_ винды(и те NT), а вокруг куча Линукс-терминалов, причем можно их бездисковыми сделать, загружая с линукс-сервера. Если не хотите линуксы (а напрасно) - citrix-клиент есть и под винды. Для сомневающихся - работа 1С в терминальном режиме проверена в боевой обстановке. Результат положительный. Доступ я пробовал осуществлять и с Линукса и с win95.

Есть mars -- netware server для линукса (эмуляция нетваpевского сеpвеpа) ipx*, ncp*, nw* (из дистpибутива mars) - клиент. Посмотрите Caldera Open Linux (caldera.com) - компания Caldera владеет исходными текстами Novell и переносит их на Linux. Netware for Linux - calderasystems.com/support/docs/netware/. Не забудьте про IPX-HOWTO: linuxdoc.org/HOWTO/IPX-HOWTO.html

Медленно и печально идем на diald.sourceforge.net, сливаем diald, разворачиваем, читаем README, совершаем _минимальные_ телодвижения на предмет конфигурации и инсталляции, и получаем эмулятор выделенной линии. Как только требуется выйти во внешний мир, diald дозванивается до провайдера, устанавливает роутинг и можно работать. Внимание: учтите, что с ядрами 2.2.x нормально работает diald-1.99 и выше. 0.16, лежащий везде, в том числе и в некоторых дистрибутивах, предназначен только для 2.0. (почему-то эта информация пропущена в Changes) Да, еще... Рекомендации лучших линуксоводов: в файле /etc/resolv.conf надо размножить строчки nameserver xxx.xxx.xxx.xxx раза по три, чтобы он по таймауту не отваливался раньше, чем diald дозвонится. Полезно также удалить default route на eth0. А еще можно так: в diald.rc пишем

ip-up "cp /etc/resolv.conf.connected /etc/resolv.conf" ip-down "cp /etc/resolv.conf.local /etc/resolv.conf",

где в resolv.conf.connected написано:

search yourdomain nameserver xxx.xxx.xxx.xxx (я предпочитаю 127.0.0.1)

а в resolv.conf.local написано:

domain yourdomain

Хорошо настроить и использовать локальный DNS-cервер в режиме caching-only. Его можно поднимать и опускать через ip-up и ip-down как сказано чуть выше, или через /etc/ppp/ip-up.local и ip-down.local. Как его настроить: раньше вариант был только один - почитать книжку и настроить таки bind. Теперь есть более простой вариант: к редхату прилагаются готовые настройки для cache-only bind-а (в пакете caching-nameserver) или можно установить демон nscd, который умеет только кешировать DNS-запросы (а также запросы к базе пользователей и групп). А еще можно сходить посмотреть на alexm.here.ru

telnet (а точнее, login) не пускает root потому, что root может заходить в систему только со специальных защищенных терминалов, перечисленных в /etc/securetty. Обычно там перечислены только виртуальные консоли tty1-ttyN. Другие места считаются небезопасными, потому что пароль, вводимый оттуда, может передаваться по сети открытым текстом (что и происходит в случае использования telnet), а значит его может узнать злоумышленник, "прослушивая" сеть и анализируя "чужие" пакеты. Ответов на второй вопрос несколько:

быстрый и неправильный способ - удалить файл /etc/securetty или прописать в нем псевдотерминалы /dev/ttyP*. Это опасно потому, что дает злоумышленнику возможность не только узнать пароль, но и воспользоваться им для удаленного захода на машину.

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

самый правильный способ - полностью отключить сервисы telnet, не-анонимный ftp, rsh, rlogin и заменить их на ssh, шифрующий все, что передается через сеть и поддерживающий аутенификацию не только через пароль, но и с использованием криптографии с открытым ключом. Клиент и сервер ssh для Unix можно взять на openssh.com, про клиенты для Windows написано в разделе "Прочее".

Прочтите man smrsh или /usr/share/doc/sendmail/README.smrsh

Такое сообщение может появляться по нескольким причинам:

Такого модуля действительно нет. В этом случае нужно выяснить его назначение и причину, по которой система пытается его загрузить. Затем, в зависимости от результатов выяснения, либо прописать в modules.conf (про формат которого есть man-страница) такую строку:

alias <имя-модуля> off

либо собрать этот модуль из его исходных текстов или исходных текстов ядра Linux.

Такой модуль существует, но программа modprobe, вызываемая ядром, не может установить соответствие между именем модуля, которое передает ядро и реальным именем файла, содержащего этот модуль. В этом случае нужно либо обновить пакет modutils, либо прописать в /etc/modules.conf:

alias <что-не-может-найти> <имя-файла-без-.o>

(я буду признателен тому, кто укажет способ установить это соответствие, если оно не прописано внутри modprobe)

Sticky bit (chmod +t) на каталоге означает, что файлы в этом каталоге могут стирать только их владельцы или суперпользователь. Обычно на /tmp и /var/tmp этот бит включен. Setgid бит (chmod +g) на каталоге означает, что файлы, созданные в этом каталоге, будут иметь ту же группу-владельца, что и сам этот каталог. Также, если в setgid-каталоге создаются другие каталоги, то они также будут иметь setgid-бит. По словам ДиДжея Бернстайна, "есть три метода задания групп-владельцев файлов: BSD-шный, бесполезный и SVR4-й. При BSD-шном методе файлы всегда получают ту же группу-владельца, что и каталог, в котором они были созданы. Это очень удобно с точки зрения администратора.(*) При бесполезном методе новые файлы принадлежат основной группе, на правах которой выполняется текущий процесс. Этот случай моментально приводит к настоящему кошмару. SVR4-й метод почти совпадает с бесполезным, но если на каталоге есть setgid-бит, то включается BSD-шный метод." Заметьте, что с помощью флага монтирования bsdgroups можно включить BSD-шный метод работы с группами-владельцами. Подробности -- mount(8). (*) Объяснение, почему удобно, можно найти в руководстве Red Hat - rhref/s1-sysadmin-usr-grps.htm, Users, Groups and User-Private Groups)

Если имеется ввиду перенос содержимого одной файловой системы в другую, то одним из корректных способов сделать это будет ( cd /old_fs && tar cf - . ) | ( cd /new_fs && tar xvpf - )

dump 0f - /old_fs | ( cd /new_fs && restore xf - ) и набирать побыстрее, и понять легче, и кое-что, что у tar не получится или получится с трудом, таким образом можно скопировать (атрибуты, файлы с "дырками"). Для tar можно и попроще: tar -C /old_fs -cf - . | tar -xpf - -C /new_fs - GNU tar более интеллектуальная штука, чем dump.

Подробное руководство есть в /usr/doc/HOWTO/mini/Hard-Disk-Upgrade

Для начала прочтите /usr/doc/HOWTO/Security-HOWTO. Hа openwall.com можно найти патч Solar Designer-а, который помогает от исполняемого стека и еще восьмидесяти восьми болезней. Кроме того, рекомендуется придирчиво изучать rootshell.com packetstorm.securify.com, linuxsecurity.com , и подписаться на списки рассылки bugtraq, linux-security, и список по безопасности того дистрибутива, которым вы пользуетесь. Еще одна, хотя и несколько радикальная ссылка: infowar.co.uk/thc/files/thc/anonymous-unix.html

Hадо заглянyть в директорию /var/log и посмотреть, нет ли в логах сообщений от этой программы. Для sendmail - 99% воплей пpо долгое думанье объясняется попыткой pезолвинга адpесов локальных интеpфейсов. Hадо эти адpеса занести в /etc/hosts. Альтеpнативный ваpиант - O DontProbeInterfaces=True в /etc/sendmail.cf.

Попробуйте fdmount /dev/fd[0-9] mountpoint, ну и не забыть почитать man fdmount, или root мог написать -user- в /etc/fstab, и обычный пользователь может говорить "mount <mountpoint>". man 8 mount. Еще лучше вовсе не монтировать дискеты, а пользоваться mtools.

Для установки времени в CMOS используется утилита hwclock из свежего комплекта util-linux. Если на вашей машине стоит только Linux, то очень удобно записать в CMOS время по Гринвичу, а в одном из стартовых скриптов сказать

/sbin/hwclock --hctosys --utc

Если на машине стоит, кроме Linux, какая-то другая операционная система, то в CMOS пишется местное время, а в стартовом скрипте пишется просто

/sbin/hwclock --hctosys

Для того, чтобы программы правильно определяли местное время (с учетом летнего времени и тому подобных обстоятельств), надо:

убрать из стартовых скриптов всякие упоминания переменной окружения TZ, если таковые имеются;

сделать так, чтобы файл /etc/localtime был правильной символической ссылкой на соответствующий файл из /usr/share/zoneinfo, например,

rm -f /etc/localtime ln -s /usr/share/zoneinfo/Europe/Moscow /etc/localtime

В Red Hat-based системах параметр utc задается в файле /etc/sysconfig/clock. Непосредственно редактировать стартовые скрипты не нужно. Кроме того, этот параметр и timezone можно задать с помощью утилиты timeconfig. Проверить правильность задания времени можно, запустив сначала ``date-- (должна показать правильное местное время), а затем ``date --utc-- (должна показать правильное время по Гринвичу). Для того, чтобы синхронизировать время с часовыми серверами в Internet, сходите на ntp.org. Там раздается пакет xntpd и приведен список публично доступных часовых серверов в Интернете. Из всего комплекта xntpd вам потребуется лишь программа ntpdate. Периодически, например, при каждом звонке провайдеру, выполняйте, например, такую команду:

/usr/local/bin/ntpdate ntp1.gamma.ru

Если на вашей машине под Linux установлена Samba, то клиенты под MS Windows могут синхронизировать время с этой машиной с помощью команды

C:> NET TIME \LINUXBOX /SET /YES

("Alexey Mahotkin" mailto:alexm@hsys.msk.ru)

Hе надо пользовать cua*. То есть вообще. Они в ядре - только для обратной совместимости со схемой, принятой в BSD. В BSD /dev/cuXX -- это "Call Up" порты, т.е. для исходящих звонков -- на них всегда есть CD. В Linux /dev/cuaXX не применяется и новые ядра даже выдают предупреждение.

Во-первых, они должны использовать одно и то же имя файла для доступа к порту, скажем, /dev/modem. Если одна программа использует /dev/ttyS0, а другая /dev/cua0 (а третья -- /dev/modem, который линк на один из этих двух :), - то они точно передерутся. Во-вторых, они должны использовать механизм lock-файлов. Hаверное, все известные программы его используют, но все же. В-третьих, они должны видеть локи друг друга. То есть, в их конфигурации должен быть указан один и тот же каталог для создания локов, они должны использовать один и тот же формат имен файлов (обычно LCK..<имя файла порта>), один и тот же формат самих файлов (обычно десять символов -- PID программы в ASCII), и иметь привилегии, достаточные для создания и удаления своих лок-файлов.

man setrlimit

Надо ставить su не из gnu sh_util, которая в принципе этого не умеет (RTFmanpage на предмет, по чьей милости), а какую-нибудь другую. Но ежели su пользует pam (в Red Hat, напpимеp и основанных на нем дистрибутивах, а также в Debian 2.2), подобное поведение достигается добавлением стpочки:

su auth required pam_wheel.so

в /etc/pam.conf, если pam дpевний, или:

auth required pam_wheel.so

в /etc/pam.d/su, если поновее. Такой механизм получше будет, поскольку поведение можно ваpьиpовать на ходу. Hапpимеp, манипулиpуя паpаметpами -group- и -deny-, pазpешить это делать всем, кpоме одной гpуппы:

pam_wheel.so group=guest deny

Пpавда, модуль этот стpанный, забывает смотpеть на gid, а смотpит только на groups... А может так и надо... В Debian 2.1 надо поставить пакетик secure-su и посмотреть на файл suauth. В Slackware от 3.3 (гаpантиpовано) это pешается путем pедактиpования /etc/login.defs Hужно, что бы было

SU_WHEEL_ONLY yes

тогда su смогут использовать только входящие в гpуппу root. В слаквари от 3.4 (до 4.0, где su опять из другой банки) лучше прочесть сперва man 5 suauth - там возможна гораздо более гибкая настройка su, чем тупая "группа ноль". Если память не вpет, то это же спpаведливо в SuSe 6.x. В SuSE 5.3 su из sh_util, со всеми вытекающими. К сожалению, su, понимающая login.defs и suauth, страдает другими болезнями - в частности, не имеет удобных ключиков -m и -s. Если секьюрити важнее удобства...