propozycje

[Tomasz Kłoczko]

On Sun, 9 May 1999, Pawel Wilk wrote:

> =?iso-8859-2?Q?Arkadiusz_Mi=B6kiewicz?= napisał(a):
> 
> > 1) automagiczne wyszukuje i usuwa/nie usuwa stare pliki "core":
> 
> ktoś zauważył, że fajnie majlować do ruta (i to chiba jedyne co możnaby
> robić)
> bym dodał:
> 
> CORE_NOTIFY=root       # puste albo brak to wcale
> CORE_OWNER=100 # pliki z takim lub < UID nas interesują
> CORE_GROUP=100 # pliki z takim lub < GID nas interesują

Przy okazji uid/gid.
Tutaj Markowe narządka (shadow) podnoszą tą granicę do 500. Wogóle z
uid/gid systemowymi robi się ostatnio bajzel. Jeszcze doneidwna RH
stosowało rezerwację uid/gid na konkretne rzeczy w przedziale systemowy.
Od niedwana (widać przed wyjściem 6.0 zaczeli niepotrzebnie się śpiezyć)
zrobił się bajzel i w %pre dla addgroup dodają tylko -r i uważają, że jest
wpożo. Burdel .. :> .. tak jest np. w utmpter.
Jak ktoś używa NFS/CODA czy czego tam jeszcze przyjdzie i w różnej
klejności zainstaluje różne pakiety na serwerze i stacjach to się to
będzie gryxć. Wychodzi na to, że trzeba będzie to poprawiać. Taktyka
podejścia do tego zagadnienia powinna być taka, że systemowe uid/gid
rezerwujemy w PLD-doc/uid_gid.db.txt, w %pre o ile okaże się, że uid/gid
już jest założony i jest inny to findem powinniśmy znajdować wszystkie
plik/katalogi i korygować im uid/gid. Normalne dodawanie grupy/użytkownika
robić się powinnno tak jak jest np. w slocate:

%pre
/usr/sbin/groupadd -g 21 -r -f slocate

[..]
> > 7) To zainteresuje Tomka:
> > # SuSEconfig.wm can create a .fvwm2rc, .fvwmrc, .bowmanrc, .fvwm2rc95,
> > # .steprc, .mwmrc, .ctwmrc, depending on the installed packages. If
> > # you want your systemwide wm config files to be updated after install
> > # / removal of packages set SUSEWM_UPDATE to "yes", otherwise to "no"
> > #
> > SUSEWM_UPDATE="yes"
> 
> typowe dla suse, ble.

Co do WMów i DMów (KDE, GNOME i inne) to postaram się dzisiaj skończyć
skrypty do xinitrc. Chodzi o to, że w RH też poszli na łatwiznę wstawiając
wszystkie WM-y jakie mają w dystrybucji. Nie chce mi się teraz tłumaczyć
jak to sobie wyobrażam ale postaram się to zrobić ASAP i jako pierwszy
przykład dorobić wsparcie do WM. To można ujednolicić i zmodularyzować
powodując jednocześnie, ze całość jest przejrzysta i prosta.

> > Uwagi mile widziane ... jeśli nie będzie żadnych _nie_
> > to zacznę powoli wprowadzać powyższe ...
> > Plikiem konfiguracyjnym będzie /etc/sysconfig/system ...
> 
> A jak jest rozwiązana (rozwiązywana) sprawa ingerencji w ten plik.?
> Będzie jak w suzi jakiś configurator systemu, ktory na każdym kroku
> straszy usera, że tego nie można robić manualnie, czy może jakiś złoty
> środek? (się kloczka naczytałem chciałem napisać sirodek:) 

W tym pliku powinno być jeszcze kupa rzeczy. Np. na jednej z maszynek
która latem mi się przegrzewa (co powoduje regularnie wywalanie się z
kernel panic) mam ręcznie w rc.local wstawione:

echo "15" > /proc/sys/kernel/panic

Co powoduje, że po 15tu sekundach od wystąpienia kernel panica maszynka
sama się restartuje (normalnie jest tam "0" co powoduje, że czas na
restart jest nieskończony). Wogóle /etc/sysconfig/system powinien być
przewidziany na różne rzeczy związane z tuningiem systemu (ustawianie max
inodów itepe). W tej chwili jest tam:

# $RUN_SULOGIN_ON_ERR - if "yes" this cause run on any errors sulogin instead
#                       shell
RUN_SULOGIN_ON_ERR=yes


Jakby się kiedyś komuś chciało do tego dorobić jakieś międzymordzie to
IMHO możnaby zastosować jakąć konwencję opisu pozycji w częśći
zakomentowanej (tak jak jest z helpen i run/stop priority w wkryptach w
/etc/rc.d/init.d) po to żeby raz apisany program wspomagający ustawianie
tych parametrów (jakiś drobiażdzek w curxes/newtl) mógł obsługiwać dowolne
opcje niezależnie od tego ile ich będzie i jakie wartości będą mogły one
przybierać.

Jeszcze jedno .. wyjście XFree opózni się. Trzeba najpierw dorobić kilka
rzeczy w PAM. W RH dołożyli tam taki moduł który nazywa się pam_concole i
sam xinit używa PAM do tego żeby stwierdzic kto i w jakich warunkach ma
prawo do uruchomienia X serwera. W wersji podstawowej w RH 6.0 jest tam
tylko pam_rootok, pam_console i pam_permit co powoduje, że X serwera nie
da się uruchomic z sesji zdalnej (wery klewer) bat .. można to także
próbować używać także do tego żeby Xy mogła uruchomić tylko konkretna
grupa ludzi (dodają użycie np. pam_wheel czu pam_list). Takze xinitrc
zmodularyzowane też poewinno wejść razem z XF.

kloczek
-- 
-----------------------------------------------------------
*Ludzie nie mają problemów, tylko sobie sami je stwarzają*
-----------------------------------------------------------
Tomasz Kłoczko, sys adm @zie.pg.gda.pl|*e-mail: kloczek w rudy.mif.pg.gda.pl*