Wolna amerykanka w PLD?

[Pawel Wilk]

On Wed, Apr 09, 2003 at 02:46:02PM +0200, Rafal Cygnarowski wrote:

> - co chcesz przechowywac w tym "rejestrze" poza sciezka do konfiguracji
>   programu?

w przyszłości także inne sciezki, np. data_dir opisany w drafcie do HOME-ETC,
czy tmp_dir, czy inne ścieżki.. także właśnie przyszedł mi taki pomysł, że
można tam trzymać także różne ustawienia, które potem będą ładowane do
zmiennych środowiska przy starcie powłoki, np.:

env.LANG = pl_PL
env.NNTPHOST = news.icm.edu.pl

i mamy z głowy sytuację taką, że dla różnych powłok zmienne środowiskowe
umieszczamy w różnych plikach rc ze względu na różnice w składni exportu.
Ofkors wymaga lekko zmodyfikowanych powłok.

Celem switches jest uspójnienie gospodarki prostymi ustawieniami i przełącznikami.

Switches może przechowywać nazwy ścieżkowe, bo nie jest celem tutaj na pewno
zastąpienie plików konfiguracyjnych.

Switches może przechowywać dowolne inne ustawienia [domena.nazwa = wartość].

Jest to rozwiązanie dla ustawień programów użytkowników jak i dla ustawień systemu.

Switches dostarcza informacji niezależnie od środowiska. Użycie pozwala
implementować mechanizmy sterowania ścieżkami i w ogóle zmiennymi także dla
aplikacji, które nie mogą czytać zmiennych środowiskowych powłoki użytkownika.

(to może się niektórym nie spodobać)

Dla systemu switches może oznaczać miejsce, w które wpadają ustawienia.
Jedna wspólna baza przypominająca sysctl. Wiem, że /etc/sysconfig/[costam]
to takie Unixowe i że przejrzyste jest. Ale tutaj skłaniam się w stronę nawet
Unixów (bo nie Windowsów), które takie informacje mają uspójnione,
co upraszcza konfigurację, bo wystarczy jedno narzędzie do sterowania
wszystkimi ustawieniami, także tymi, które wpadną w przyszłości do tej bazy.

Można opcjonalnie generować z tego db albo i dopisać wsparcie dla
"zewnętrznych" źródeł jak LDAP, jeśli danych okaże się wiele.

> - Jaka to ma zalete nad aktualnymi rozwiazaniami?

Trzymanie ustawień w zmiennych środowiskowych nie jest optymalne.
Przekazywanie ustawień używając profile.d do środowiska każdego
użytkownika nie jest optymalne. Trzymanie wielu ustawień w wielu
plikach nie jest optymalne z punktu widzenia narzędzi konfiguracyjnych.

Zmiennych env robi się coraz więcej, różne powłoki mają różną składnię
na ich wczytywanie. Są aplikacje, które nie startują z powłoki usera
ale działają na jego prawach (np. dostarczając pocztę) i im także warto
by pozwolić mieć styczność z ustawieniami użytkownika w jeden prosty
sposób.

Aby zautomatyzować konfigurację systemu trzeba obecnie pisać wiele różnych
programów, ew. modułów do programów, które korzystają z różnych
plików z ustawieniami. Można to uprościć i wrzucać wszytko w jedną
bazę. Wtedy mamy jedno uniwersalne narzędzie do kontrolowania podstawowej
konfiguracji systemu, a dla użytkownika jedno narzędzie do kontrolowania
konfiguracji swoich ustawień i przełączników.

Przystosowanie tego do obecnych rc-scripts to dodanie paru funkcji w sh
które wzywać będą polecenie uzyskujące informacje przy użyciu switches.

Jeśli chodzi o bezpieczeństwo to:

/etc/switches  z odczytem dla każdego
/etc/sswitches z odczytem tylko dla nadzorcy

lub

kontrola na podstawie acl w samej bibliotece, jeśli podane
dodatkowe parametry sterowania dostępem dla konkretnego entry.
Ale to rozwiązanie ryzykowne o tyle, że pewna część mechanizmu
musiałaby działać na suidzie na właściciela pliku/bazy
odczytywalnego/zapisywalnego tylko przez niego.

Ewentualne definiowanie typów danych dla poszczególnych entries to
kwestia do dyskusji.

-- 
Pawel Wilk ( siefca @ entropy echelon pl )           ) pld-devel )

                 żyj skromnie. szanuj swojego admina.