Hi all. По итогам свежих действий, с претензией на faq.
Во всех Юниксах традиционно существует жесткое ограничение на количество групп, к которым может принадлежать пользователь. Более того, это ограничение забито в RFC для NFS. Однако в корпоративной среде может реально возникать возникать значительно большее количество "проектов" и "рабочих групп", причём пользователь одновременно участвует во многих проектах. ACL "per user" позволяет раздать права на объекты однократно независимо от NGROUPS_MAX, но задача перевода юзера из одного проекта в другой становится после этого весьма трудоёмкой. В общем, хочется избавится от ограничения. Значение ограничения в ядре записано у нас в /usr/include/linux/limits.h #define NGROUPS_MAX 32 /* supplemental group IDs are available */ Помимо ядра это ограничение эффективно работает в главной системной библиотеке, libc. При изменении значения в limits.h нужно пересобрать не только ядро, но и libc. Начиная с ядра 2.6.4 значение NGROUPS_MAX увеличено до 65536. Но libc (aka glibc2) в стабильном дистрибутиве Дебиана собиралась на машине с инклудами ядра 2.6.0; увидеть это можно запустив /lib/libc.so.6 как программу. [EMAIL PROTECTED]:~$ /lib/libc.so.6 GNU C Library stable release version 2.3.2, by Roland McGrath et al. Copyright (C) 2003 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Compiled by GNU CC version 3.3.5 (Debian 1:3.3.5-12). Compiled on a Linux 2.6.0-test7 system on 2005-05-10. Available extensions: GNU libio by Per Bothner crypt add-on version 2.1 by Michael Glad and others linuxthreads-0.10 by Xavier Leroy BIND-8.2.3-T5B libthread_db work sponsored by Alpha Processor Inc NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk Thread-local storage support included. Соответственно, далее есть два пути: собирать glibc из исходников самого Дебиана или взять более свежую версию из первоисточника gnu.org. По моему опыту: если мы вынуждены использовать свою версию какой-то софтины вместо выдаваемой в составе системы, то нужно использовать ту версию, которую рекомендуют разработчики софтины. Тогда дольше можно будет ничего не трогать :-). В данном случае (по состоянию на 04-oct-2005) Дебиан использует glibc 2.3.2, разработчики дают 2.3.5. Сборка: cd /usr/src mkgir glibc cd glibc ../glibc-2.3.5/configure --enable-add-ons --prefix=/usr make Инсталляция: make install под конец работы надёжно убивает систему :-). Невозможно запустить ни одну программу кроме статически линкованных. Кстати, у вас ведь поставлен уже какой-нибудь статический шелл для моментального восстановления при такой аварии, правда? Суть беды в следующем. Debian имеет целое дерево версий glibc и динамического загрузчика, оптимизированных под разные типы процессоров: в /lib/, /lib/tls/, /lib/tls/i686.cmov/. Makefile знает только про каноническое место /lib. И в какой-то момент замены возникает конфликт версий между новым загрузчиком и этими дополнительными копиями библиотек. Для безопасной инсталляции достаточно удалить всю ветку /lib/tls/: после этого все вновь стартующие программы гарантированно используют "каноническую" /lib/libc.so.6, а "make install" умеет подменять её на ходу синхронно с загрузчиком, безопасным образом. Результат в шелле немедленный: [EMAIL PROTECTED]:/usr/src/glibc# su -p myst [EMAIL PROTECTED]:/usr/src/glibc$ groups|wc -w 37 Если вся операция делалась ради доступа из Самбы, то, естественно, надо сказать /etc/init.d/samba restart. NB: после замены libc на собранную таким простейшим образом система не будет стартовать на старом (ниже i686) процессоре. Поскольку configure оптимизирует код именно под имеющийся процессор: cmov и т.п. Параноики, желающие полной переносимости, могут читать дальше INSTALL от glibc. А.Л. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]