[OpenBSD]

[Spis treści] [Sekcja 9 - Migracja do OpenBSD] [Sekcja 11 - X Window System]

10 - Zarządzanie systemem


Spis treści


10.1 - Dlaczego system odpowiada, że nie należę do odpowiedniej grupy, kiedy próbuję wydać polecenie su?

Użytkownicy posiadający już konto w systemie muszą zostać dopisani do grupy "wheel" ręcznie. Robi się tak dla zwiększenia bezpieczeństwa, i należy zachować ostrożność z tym komu daje się taki dostęp. W systemie OpenBSD tylko użytkownicy należący do grupy wheel mają prawo używać polecenia su(1) w celu uzyskania praw roota. Użytkownicy, którzy nie należą do grupy "wheel", nie mogą korzystać z polecenia su(1). Istniejącego użytkownika można dodać do grupy wheel odpowiednio redagując plik /etc/group. Zamieszczony poniżej wpis z tego pliku uwzględnia użytkownika ericj (oraz roota) jako członka grupy "wheel".

Dodając nowego użytkownika za pomocą polecenia adduser(8), można od razu dodać go do grupy wheel po prostu wpisując "wheel" w odpowiedzi na pytanie "Invite user into other groups:". W ten sposób użytkownik zostanie automatycznie dodany do grupy "wheel" w pliku /etc/group:

wheel:*:0:root,ericj

Często chcemy zwiększyć uprawnienia danego użytkownika, ale w sposób kontrolowany, nie umieszczając go w grupie "wheel". Dokładnie w tym celu został stworzony program sudo(8).

10.2 - Jak zrobić kopię systemu plików?

W celu skopiowania systemu plików można skorzystać z programów dump(8) i restore(8). Na przykład, aby skopiować zawartość katalogu SRC do katalogu DST wystarczy wydać następujące polecenie:

# cd /SRC; dump 0f - . | (cd /DST; restore -rf - )

Dump został zaprojektowany tak, aby spełniać różnorodne wymagania dotyczące wykonywania kopii zapasowych i może być zbyt skomplikowanym narzędziem, jeżeli chcemy skopiować tylko część (albo nawet całość) systemu plików. Dla prostszych zastosowań szybszy może okazać się program tar(1). Składnia tego polecenia jest bardzo podobna jak w poprzednim przykładzie:

# cd /SRC; tar cf -  . | (cd /DST; tar xpf - )

10.3 - W jaki sposób automatycznie uruchamiać demony przy starcie systemu? (Prezentacja rc(8))

OpenBSD uruchamia demony podczas startu sytemu poprzez rc(8). Korzysta on przy tym z kilku pomocniczych skryptów i plików konfiguracyjnych:

Jak działa rc(8)?

Najważniejszymi plikami, na których powinien skupić się administrator systemu są /etc/rc.conf (albo /etc/rc.conf.local), /etc/rc.local oraz /etc/rc.shutdown. Na początku opiszmy jednak poszczególne czynności wykonywane przez skrypt rc(8):

Po załadowaniu jądra systemu, rozpoczyna pracę /etc/rc:

Uruchamianie demonów i usług systemowych

Większość dostarczonych z systemem OpenBSD demonów i usług można uruchomić podczas startu systemu przez prostą modyfikację pliku konfiguracyjnego /etc/rc.conf. Na początek przyjrzyjmy się domyślnej zawartości pliku /etc/rc.conf. Znajdują się tam linie podobne do tej:

ftpd_flags=NO           # for non-inetd use: ftpd_flags="-D"

Zamieszczony powyżej wpis oznacza, ze ftpd nie powinien być uruchamiany przy starcie systemu (a przynajmniej nie przez rc(8), przeczytaj dział Konfigurowanie anonimowego serwera FTP, by dowiedzieć się więcej na ten temat). Tak czy inaczej, każdy wpis zawiera także komentarz opisujący flagi (opcje) NORMALNEJ pracy demona lub usługi. Nie oznacza to, że trzeba uruchamiać tego czy innego demona czy usługę z dokładnie tymi samymi ustawieniami. Zawsze można skorzystać z podręcznika systemowego, aby sprawdzić, jakiej opcji użyć w celu osiągnięcia zamierzonego efektu. Na przykład, poniższa linia pokazuje domyślne ustawienie demona httpd(8).

httpd_flags=NO          # for normal use: "" (or "-DSSL" after reading ssl(8))

Jak widać, w tym przypadku httpd może być uruchomiony bez jakichkolwiek opcji. A zatem potrzebny byłby tylko taki wpis: httpd_flags="". W przypadku, gdy chcielibyśmy uruchomić httpd z obsługą ssl (patrz SSL FAQ lub ssl(8)) należało by napisać: httpd_flags="-DSSL".

Dobrym zwyczajem jest w ogóle nie zmieniać /etc/rc.conf. Zamiast tego można utworzyć plik /etc/rc.conf.local i skopiować do niego te linie, które mamy zamiar zmienić w /etc/rc.conf, a potem dostosować je do własnych potrzeb. Znacznie ułatwia to proces aktualizacji -- wszystkie zmiany są zapisane bowiem w tym jednym pliku.

Uruchamianie i konfiguracja lokalnych demonów

W przypadku demonów lokalnych, czyli doinstalowanych z portów, pakietów czy w dowolny inny sposób, należy korzystać z pliku /etc/rc.local. Na przykład, jeżeli zainstalowaliśmy demona, który znajduje się w /usr/local/sbin/daemonx i chcemy, aby uruchamiał się on przy starcie systemu, to do pliku /etc/rc.local powinniśmy dodać następujący wpis:

if [ -x /usr/local/sbin/daemonx ]; then
	echo -n ' daemonx';       /usr/local/sbin/daemonx
fi

(Jeżeli demon nie przechodzi automatycznie do pracy w tle, należy dodać znak "&" po "/usr/local/sbin/daemonx".)

Od tej pory demon będzie uruchamiany zawsze podczas startu systemu. W trakcie tej operacji można zobaczyć komunikaty o błędach (jeżeli się takowe pojawią). Natomiast komunikat bezbłędnego uruchomienia demona będzie wyglądał mniej więcej tak:

Starting local daemons: daemonx.

rc.shutdown

/etc/rc.shutdown to skrypt, który jest uruchamiany przed zatrzymaniem pracy systemu. Wszystkie polecenia, które mają być wykonane przed zamknięciem OpenBSD powinny być zawarte w tym pliku. Jeżeli wykorzystywane jest zarządzanie energią (apm), można także ustawić "powerdown=YES", co jest odpowiednikiem komendy "shutdown -p".

10.4 - Dlaczego użytkownicy otrzymują komunikat "relaying access denied" gdy próbują wysłać zdalnie pocztę przez moją maszynę działającą na OpenBSD?

Proszę spróbować tego:

# grep relay-domains /etc/mail/sendmail.cf

Wynik może wyglądać tak:

FR-o /etc/mail/relay-domains

Jeżeli ten plik nie istnieje, należy go utworzyć i wpisać do niego nazwy hostów, którym zezwala się na przesyłanie poczty przez swój serwer stosując następującą składnię:

.domain.com    #Zezwalaj na przekazywanie poczty z/do każdego hosta w domain.com
sub.domain.com #Zezwalaj na przekazywanie poczty z/do domeny sub.domain.com oraz z każdego hosta w tej domenie 
10.2           #Zezwalaj na przekazywanie poczty ze wszystkich hostów o adresach IP 10.2.*.*

Na koniec należy wysłać procesowi sendmail sygnał 'HangUP' (jest to sygnał, który zmusza większość demonów do ponownego odczytania swoich plików konfiguracyjnych):

# kill -HUP `head -1 /var/run/sendmail.pid`

Dalsze informacje

10.5 - Uruchomiłem serwer POP, ale użytkownicy mają kłopoty z odbiorem maili poprzez ten protokół. Co mam zrobić?

Większość problemów związanych z protokołem POP ma swoje źródła w plikach tymczasowych oraz plikach blokady. Jeżeli serwer POP wysyła komunikat o błędzie podobny do tego:

-ERR Couldn't open temporary file, do you own it?

to spróbujmy ustawić prawa do plików w następujący sposób:

prawa w  /var
drwxrwxr-x   2 bin     mail     512 May 26 20:08 mail


prawa w  /var/mail
-rw-------   1 username   username        0 May 26 20:08 username

Należy upewnić się, że dany użytkownik jest właścicielem swojego pliku poczty w katalogu /var/mail (tzn. /var/mail/joe powinien należeć do joe itd.). Teoretycznie nie ma powodu, dla którego miało by być inaczej, ale jeżeli jest, to tu może tkwić problem!

Oczywiście, przyznanie praw do pisania do /var/mail grupie mail może być przyczyną wielu tajemniczych, nie do końca znanych problemów związanych z bezpieczeństwem. Istnieje duże prawdopodobieństwo, że nigdy nie będzie z tym kłopotów, jeśli jednak serwer stanowi znaczący punkt na mapie Internetu (np. należy do ISP) mogą się takowe pojawić! W kolekcji portów można znaleźć kilka różnych serwerów POP, zalecane jest jednak używanie popa3d, który jest dostępny już w podstawowej instalacji OpenBSD. Może się też zdarzyć, że zostaną określone nieodpowiednie opcje konfiguracji serwera POP (np. blokada plików z kropką). Być może wystarczy jedynie zmienić katalog, który jest blokowany przez serwer (chociaż wtedy blokowanie miałoby sens tylko dla demona POP).

Uwaga: Proszę zwrócić uwagę, że OpenBSD nie tworzy automatycznie grupy "mail". Jeżeli zajdzie taka potrzeba, należy utworzyć ją własnoręcznie dodając do pliku /etc/group. Wpis w stylu:

mail:*:6:

powinien wystarczyć.

10.6 - Dlaczego Sendmail ignoruje plik /etc/hosts?

Domyślnie Sendmail korzysta z DNS w celu uzyskania informacji o adresach, ignorując plik /etc/hosts. Zachowanie to można zmienić korzystając z pliku /etc/mail/service.switch.

Jeżeli chcemy aby Sendmail przed wysłaniem zapytania do DNS odczytywał plik /etc/hosts, należy utworzyć plik /etc/mail/service.switch, zawierający następujący wpis:

     hosts       files dns

Jeżeli zaś chcemy, by Sendmail odczytywał TYLKO plik /etc/hosts, użyjemy następującego wpisu:

     hosts       files

Wysyłamy teraz procesowi Sendmail sygnał HUP:

     
    # kill -HUP `head -1 /var/run/sendmail.pid`

aby zmiany, które wykonaliśmy, zostały uwzględnione.

10.7 - Konfigurowanie bezpiecznego serwera HTTP z wykorzystaniem SSL(8)

OpenBSD jest dostarczany z gotowym do użytku serwerem httpd wyposażonym w obsługę SSL oraz biblioteki RSA. Aby móc korzystać z SSL w httpd(8), należy najpierw utworzyć certyfikat. Będzie on przechowywany w /etc/ssl/, a odpowiadający mu klucz w /etc/ssl/private/. Opisane poniżej kroki zostały częściowo zaczerpnięte ze strony podręcznika systemowego ssl(8). Tam też znajdują się dalsze informacje. Ta sekcja FAQ jedynie zarysowuje sposób tworzenia certyfikatów RSA dla serwerów WWW, pomija zaś certyfikaty DSA. Aby dowiedzieć się więcej na ten temat, przeczytaj stronę podręcznika ssl(8).

Na początku należy utworzyć klucz oraz certyfikat serwera korzystając z OpenSSL:

# openssl genrsa -out /etc/ssl/private/server.key 1024

Jeżeli klucz ma zostać zaszyfrowany hasłem, które trzeba będzie wpisać przy uruchamianiu serwerów, zamiast poprzedniego polecenia używamy tego:

# openssl genrsa -des3 -out /etc/ssl/private/server.key 1024

Kolejnym krokiem jest wygenerowanie prośby o podpis certyfikatu (ang. Certificate Signing Request), która jest wykorzystywana przez Instytucję Uwierzytelniającą (ang. Certifying Authority) do podpisania certyfikatu. Robi się to za pomocą polecenia:

# openssl req -new -key /etc/ssl/private/server.key -out /etc/ssl/private/server.csr

Plik server.csr może zostać następnie przekazany Instytucji Uwierzytelniającej, która podpisze klucz. Jedną z takich instytucji jest Thawte Certification, której strona znajduje się pod adresem http://www.thawte.com/.

Jeżeli nie stać Cię na certyfikat Thawte, albo chcesz sam podpisać swój certyfikat, możesz to zrobić w następujący sposób:

# openssl x509 -req -days 365 -in /etc/ssl/private/server.csr \
       -signkey /etc/ssl/private/server.key -out /etc/ssl/server.crt

Po wygenerowaniu plików /etc/ssl/server.crt oraz /etc/ssl/private/server.key, bez przeszkód będzie można uruchomić httpd(8) z opcja -DSSL (patrz sekcja nt. rc(8) w tym FAQ), co zezwala na przeprowadzanie transakcji na porcie 443.

10.8 - Dokonałem zmian w /etc/passwd, ale nie zostały one uwzględnione. Dlaczego?

Bezpośrednie modyfikacje pliku /etc/passwd zostaną zignorowane. OpenBSD generuje /etc/passwd dynamicznie za pomocą pwd_mkdb(8). Głównym plikiem haseł w systemie OpenBSD jest /etc/master.passwd. Cytując za pwd_mkdb(8):

PLIKI
     /etc/master.passwd  obecnie obowiązujący plik haseł
     /etc/passwd         plik haseł w formacie 6-tej Edycji
     /etc/pwd.db         niezabezpieczony plik bazy haseł
     /etc/pwd.db.tmp     plik tymczasowy
     /etc/spwd.db        zabezpieczony plik bazy haseł
     /etc/spwd.db.tmp    plik tymczasowy

W tradycyjnym pliku haseł w systemach Unix, takim jak /etc/passwd, cała jego zawartość, włączając w to zaszyfrowane hasło użytkownika, jest dostępna dla każdego, kto posiada konto w systemie (plik ten jest głównym celem ataków programów takich jak Crack). 4.4BSD wprowadził plik master.passwd, który posiada rozszerzony format (z dodatkowymi opcjami w stosunku do /etc/passwd) i tylko root posiada prawo do odczytu tego pliku. W celu przyspieszenia dostępu do danych, wywołania biblioteczne zazwyczaj odczytują pliki /etc/pwd.db i /etc/spwd.db (zamiast /etc/master.passwd).

OpenBSD posiada narzędzie, które służy do modyfikacji pliku haseł. Nazywa się ono vipw(8). Do modyfikacji /etc/master.passwd vipw korzysta z vi (albo Twojego ulubionego edytora zdefiniowanego za pomocą zmiennej środowiskowej $EDITOR). Po dokonaniu zmian vipw utworzy na nowo /etc/passwd, /etc/pwd.db oraz /etc/spwd.db tak, aby uwzględniały one wprowadzone zmiany. vipw zakłada także blokady na te pliki tak, by dwie osoby nie modyfikowały ich naraz.

10.9 - Jaki jest najlepszy sposób na dodanie/usunięcie użytkownika?

OpenBSD posiada dwa polecenia pozwalające w łatwy sposób dodać użytkownika do systemu:

Można także dodawać użytkowników ręcznie za pomocą vipw(8), ale zwykle jest to bardziej skomplikowane.

Najprostszym sposobem na dodanie użytkownika w OpenBSD jest użycie skryptu adduser(8). Można go skonfigurować redagując plik /etc/adduser.conf. adduser(8) sprawdza spójność plików /etc/passwd, /etc/group oraz baz danych powłoki. Tworzy także niezbędne wpisy oraz katalog $HOME. Potrafi nawet wysłać użytkownikowi wiadomość powitalną. Oto przykład dodania użytkownika testuser do systemu. Jego katalog $HOME (domowy) będzie umieszczony w /home/testuser. Przydzielimy go do grupy guest, oraz ustawimy domyślną powłokę na /bin/ksh.

# adduser
Use option ``-silent'' if you don't want to see all warnings and questions.

Reading /etc/shells
Reading /etc/login.conf
Check /etc/master.passwd
Check /etc/group

Ok, let's go.
Don't worry about mistakes. I will give you the chance later to correct any input.

Enter username []: testuser
Enter full name []: Test FAQ User
Enter shell csh ksh nologin sh [sh]: ksh
Uid [1002]: Enter
Login group testuser [testuser]: guest
Login group is `guest''. Invite testuser into other groups: guest no 
[no]: no
Login class auth-defaults auth-ftp-defaults daemon default staff 
[default]: Enter
Enter password []: Type password, then Enter
Enter password again []: Type password, then Enter

Name:        testuser
Password:    ****
Fullname:    Test FAQ User
Uid:         1002
Gid:         31 (guest)
Groups:      guest
Login Class: default
HOME:        /home/testuser
Shell:       /bin/ksh
OK? (y/n) [y]: y
Added user ``testuser''
Copy files from /etc/skel to /home/testuser
Add another user? (y/n) [y]: n

Goodbye!

Do skasowania użytkownika z systemu służy polecenie rmuser(8). Usunie ono wszelkie ślady bytności użytkownika w systemie - wszystkie jego wpisy w crontab(1), katalog domowy (jeśli jego właścicielem jest użytkownik), jego pocztę. Oczywiście, również wpisy w /etc/passwd oraz /etc/group zostaną usunięte. Oto przykład usunięcia użytkownika dodanego przez nas przed chwilą. Proszę zauważyć, że rmuser(8) pyta się o login użytkownika oraz czy usuwać jego katalog domowy.

# rmuser
Enter login name for user to remove: testuser
Matching password entry:

testuser:$2a$07$ZWnBOsbqMJ.ducQBfsTKUe3PL97Ve1AHWJ0A4uLamniLNXLeYrEie:1002
:31::0:0:Test FAQ User:/home/testuser:/bin/ksh

Is this the entry you wish to remove? y
Remove user's home directory (/home/testuser)? y
Updating password file, updating databases, done.
Updating group file: done.
Removing user's home directory (/home/testuser): done.

Dodawanie użytkowników za pomocą polecenia user(8)

Niżej opisane narzędzia są mniej interaktywne niż polecenie adduser(8), co ułatwia korzystanie z nich w skryptach powłoki.

Na narzędzia te składają się następujące programy:

Dodawanie użytkowników w praktyce.

Ponieważ program user(8) nie jest interaktywny, najłatwiejszym sposobem dodania użytkownika jest użycie komendy adduser(8). Polecenie /usr/sbin/user to tylko fronton (ang. front-end) poleceń /usr/sbin/user*. Dlatego też można używać zarówno user add jak i useradd. Wybór należy do Ciebie - składnia komend pozostaje w obu przypadkach identyczna.

W kolejnym przykładzie dodamy tego samego użytkownika z takimi samymi ustawieniami jak w przykładzie wyżej prezentującym polecenie adduser. useradd(8) będzie dużo prostszy w obsłudze, jeśli najpierw zaznajomimy się z domyślnymi ustawieniami. Znajdują się one w pliku /etc/usermgmt.conf, zaś wyświetlić je można pisząc:

$ user add -D
group           users
base_dir        /home
skel_dir        /etc/skel
shell           /bin/csh
inactive        0
expire          Null (unset)
range           1000..60000

Powyższe ustawienia, jeśli nie zostaną zmienione, będą wykorzystane przy dodawaniu użytkownika z pomocą poleceń user add/useradd. Żeby było ciekawiej, w naszym przykładzie umieścimy użytkownika w grupie guest, nie w users. Ostatnią przeszkodą, o jakiej musimy pamiętać jest fakt, że hasło, które przekażemy programowi user add/useradd musi być już zaszyfrowane. Zatem najpierw należy użyć programu encrypt(1), służącego do szyfrowania haseł. OpenBSD używa do kodowania haseł sześciorundowego algorytmu Blowfish. Oto przykład pokazujący jak można otrzymać zaszyfrowane hasło gotowe do wykorzystania w programie useradd(8):

$ encrypt -p -b 6
Enter string:
$2a$06$YOdOZM3.4m6MObBXjeZtBOWArqC2.uRJZXUkOghbieIvSWXVJRzlq

Mamy już zakodowane hasło, możemy więc dodać użytkownika:

# user add -p '$2a$06$YOdOZM3.4m6MObBXjeZtBOWArqC2.uRJZXUkOghbieIvSWXVJRzlq' -u 1002 \
-s /bin/ksh -c "Test FAQ User" -m -g guest testuser

Uwaga: Hasło należy umieścić w parze apostrofów (' '), a nie cudzysłowów (" "); w przeciwnym razie zostanie ono zinterpretowane przez powłokę przed wysłaniem do user(8). Opcja -m jest konieczna by system utworzył katalog domowy użytkownika i skopiował do niego pliki z /etc/skel.

By sprawdzić, czy użytkownik został poprawnie dodany do systemu, można posłużyć się wieloma narzędziami. Zamieszczone poniżej przykłady pokazują jak szybko upewnić się, że wszystko wykonane zostało poprawnie.

$ ls -la /home
total 14
drwxr-xr-x   5 root      wheel   512 May 12 14:29 .
drwxr-xr-x  15 root      wheel   512 Apr 25 20:52 ..
drwxr-xr-x  24 ericj     wheel  2560 May 12 13:38 ericj
drwxr-xr-x   2 testuser  guest   512 May 12 14:28 testuser
$ id testuser
uid=1002(testuser) gid=31(guest) groups=31(guest)
$ finger testuser
Login: testuser                         Name: Test FAQ User
Directory: /home/testuser               Shell: /bin/ksh
Last login Sat Apr 22 16:05 (EDT) on ttyC2
No Mail.
No Plan.

Dodatkowo, user(8) dostarcza własne narzędzie do podglądu parametrów użytkownika o nazwie userinfo(8).

$ userinfo testuser
login   testuser
passwd  *
uid     1002
groups  guest
change  Wed Dec 31 19:00:00 1969
class
gecos   Test FAQ User
dir     /home/testuser
shell   /bin/ksh
expire  Wed Dec 31 19:00:00 1969

Usuwanie użytkowników

W celu usunięcia użytkownika za pomocą polecenia z zestawu user(8), należy skorzystać z komendy userdel(8). Jest to bardzo proste, a jednocześnie przydatne polecenie. By usunąć użytkownika dodanego w poprzednim wystarczy napisać:

# userdel -r testuser

Proszę zwrócić uwagę na opcję -r, która każe systemowi usunąć nie tylko samego użytkownika, ale też jego katalog domowy. Alternatywnie, zamiast -r można użyć flagi -p, która tylko blokuje konto użytkownika, bez usuwania jakichkolwiek informacji o nim.

10.10 - Jak stworzyć konto umożliwiające logowanie tylko przez FTP?

Istnieje na to kilka sposobów. Bardzo powszechne jest rozwiązanie polegające na dodaniu pliku "/usr/bin/false" do "/etc/shells". Jeżeli następnie domyślna powłoka użytkownika ustawiona zostanie właśnie na "/usr/bin/false", to nie będzie on mógł zalogować się do systemu w trybie interaktywnym. Będzie mógł natomiast zalogować się przez FTP. Możesz także, korzystając poprzez ftpchroot ograniczyć dostęp użytkowników ftp tylko do ich katalogów domowych.

10.11 - Konfigurowanie kwot dyskowych

Kwoty wykorzystywane są do ograniczania przestrzeni dyskowej dostępnej użytkownikom. Jest to szczególnie pomocne, gdy zasoby dyskowe są mocno ograniczone. Limity można narzucić zarówno pojedynczemu użytkownikowi jak i całej grupie.

Pierwszym krokiem do ustawienia kwot jest sprawdzenie czy opcja "option QUOTA" została włączona w twojej konfiguracji kernela. Jest ona domyślnie ustawiona w jądrze GENERIC. Następnie należy wskazać w pliku /etc/fstab, systemy plików na których chcesz włączyć kwoty. Do tego służą słowa kluczowe userquota oraz groupquota. W korzeniu wybranych systemów plików domyślnie tworzone są pliki quota.user oraz quota.group, które zawierają niezbędne informacje o kwotach. Nie ma przeszkód, by pliki te znajdowały się w dowolnym innym katalogu lub nawet inaczej się nazywały. Robi się to dodając w pliku /etc/fstab; przykładowo "userquota=/var/quotas/quota.user". Poniżej znajduje się przykład pliku /etc/fstab z jednym systemem plików z włączonymi kwotami i plikiem kwot nie niestandardowej lokalizacji:

/dev/wd0a / ffs rw,userquota=/var/quotas/quota.user 1 1

Teraz można już przyznawać użytkownikom kwoty. Służy do tego narzędzie o nazwie edquota(8). Wpisując "edquota <user>" do konfigurowania kwot użyty zostanie edytor vi(1), chyba że za pomocą zmiennej środowiskowej EDITOR ustawimy jako domyślny inny edytor. Dla przykładu:

# edquota ericj

spowoduje wyświetlenie mniej więcej takiej informacji:

Quotas for user ericj:
/: blocks in use: 62, limits (soft = 0, hard = 0)
	inodes in use: 25, limits (soft = 0, hard = 0)

Aby wprowadzić ograniczenia wystarczy zredagować ten plik. Np.:

Quotas for user ericj:
/: blocks in use: 62, limits (soft = 1000, hard = 1050)
	inodes in use: 25, limits (soft = 0, hard = 0)

W powyższym przykładzie ustawiliśmy limit miękki (ang. soft limit) na 1000 bloków, zaś limit twardy (ang. hard limit) na 1050 bloków. Różnica między limitem miękkim a twardym polega na tym, że ten pierwszy może zostać na jakiś czas przekroczony. Czas ten ustala się stosując opcję -t w poleceniu edquota(8). Gdy okres ten jednak minie, limit miękki jest traktowany identycznie jak limit twardy, co powoduje częste błędy alokacji.

Po ustawieniu kwot należy je jeszcze włączyć. Robi się to za pomocą polecenia quotaon(8). Przykład:

# quotaon -a

Spowoduje to wczytanie /etc/fstab i włączenie kwot na wybranych systemach plików. Do wyświetlania kwot służy polecenie quota(1). Wywołanie "quota <user>" dostarczy informacji na temat kwot wybranego użytkownika. Wywołanie komendy quota(1) bez dodatkowych argumentów zwróci nasze własne statystyki. Oto przykład:

# quota ericj

Spowoduje to wypisanie informacji podobnej do tej:

Disk quotas for user ericj (uid 1001): 
     Filesystem  blocks   quota   limit   grace   files   quota   limit   grace
              /      62    1000    1050              27       0       0        

Kwoty ustawione w /etc/fstab włączają się domyślnie podczas startu systemu. Natomiast wyłączyć można je pisząc:

# quotaoff -a

10.12 - Konfigurowanie klientów i serwerów KerberosV

KerberosV jest domyślnie preinstalowanym składnikiem systemu.

Więcej informacji o KerberosV można uzyskać za pomocą polecenia:

     # info heimdal

10.13 - Konfigurowanie anonimowego serwera FTP

Dzięki anonimowemu FTP nawet użytkownicy nie posiadający konta mogą mieć dostęp do naszych plików. Poniżej podpowiadamy jak skonfigurować anonimowy serwer FTP.

Dodawanie konta FTP

Najpierw należy stworzyć w systemie konto o nazwie ftp. Hasło do tego konta nie powinno być wartościowe, tzn. nie powinniśmy używać go nigdzie indziej. W naszym przykładzie dla tego konta ustalimy katalog domowy /home/ftp, ale można użyć tez innego katalogu. Gdy ktoś zaloguje się na nasz anonimowy serwer FTP, demon ftp zmieni środowisko za pomocą polecenia chroot, na katalog domowy użytkownika ftp. Więcej na ten temat można dowiedzieć się na stronach podręcznika systemowego ftpd(8) oraz chroot(2). Oto przykład dodania użytkownika o nazwie ftp. Używamy tutaj polecenia: adduser(8). Należy także dodać linię /usr/bin/false do pliku /etc/shells. Jest to "powłoka", którą nadajemy użytkownikowi ftp. Dzięki temu nie będą się oni mogli zalogować, nawet jeśli ustawimy im puste hasło.

echo /usr/bin/false >> /etc/shells
Po czym jesteśmy gotowi na utworzenie użytkownika ftp:
# adduser
Use option `-silent'' if you don't want to see all warnings and questions.

Reading /etc/shells
Reading /etc/login.conf
Check /etc/master.passwd
Check /etc/group

Ok, let's go.
Don't worry about mistakes. I will give you the chance later to correct any input.
Enter username []: ftp
Enter full name []: anonymous ftp
Enter shell csh false ksh nologin sh tcsh zsh [sh]: false
Uid [1002]: Enter
Login group ftp [ftp]: Enter
Login group is `ftp''. Invite ftp into other groups: guest no 
[no]: no
Login class auth-defaults auth-ftp-defaults daemon default staff 
[default]: Enter
Enter password []: Enter
Set the password so that user cannot logon? (y/n) [n]: y

Name:        ftp
Password:    ****
Fullname:    anonymous ftp
Uid:         1002
Gid:         1002 (ftp)
Groups:      ftp
Login Class: default
HOME:        /home/ftp
Shell:       /usr/bin/false
OK? (y/n) [y]: y
Added user ``ftp''
Copy files from /etc/skel to /home/ftp
Add another user? (y/n) [y]: n
Goodbye!

Konfigurowanie katalogu

Mamy już dodanego użytkownika ftp; stworzony został także jego katalog domowy - /home/ftp. Należy dokonać jednak jeszcze kilku zmian, by konto było gotowe do obsługi anonimowego FTP. Ponownie odsyłamy do podręcznika systemowego programu ftpd(8).

Nie ma potrzeby zakładania katalogów /home/ftp/usr czy /home/ftp/bin.

Proszę zwrócić uwagę na to, by właścicielem wszystkich katalogów był root. Oto listing pokazujący jak powinny wyglądać stworzone katalogi:

# pwd
/home
# ls -laR ftp
total 5
dr-xr-xr-x  5 root  ftp    512 Jul  6 11:33 .
drwxr-xr-x  7 root  wheel  512 Jul  6 10:58 ..
dr-x--x--x  2 root  ftp    512 Jul  6 11:34 etc
dr-xr-xr-x  2 root  ftp    512 Jul  6 11:33 pub

ftp/etc:
total 43
dr-x--x--x  2 root  ftp    512 Jul  6 11:34 .
dr-xr-xr-x  5 root  ftp    512 Jul  6 11:33 ..
-r--r--r--  1 root  ftp    316 Jul  6 11:34 group
-r--r--r--  1 root  ftp  40960 Jul  6 11:34 pwd.db

ftp/pub:
total 2
dr-xr-xr-x  2 root  ftp  512 Jul  6 11:33 .
dr-xr-xr-x  5 root  ftp  512 Jul  6 11:33 ..

Uruchamianie serwera i logowanie

W przypadku ftpd można wybrać czy uruchamiać go z inetd(8), czy ze skryptów rc. Nasze przykłady pokażą jak uruchomić demona z pomocą inetd.conf. Na początku musimy jednak poznać pewne opcje ftpd. Standardowa linia z /etc/inetd.conf wygląda tak:

ftp             stream  tcp     nowait  root    /usr/libexec/ftpd       ftpd -US

W naszym przypadku ftpd jest przywoływany z opcją -US. Spowoduje to logowanie anonimowych połączeń do /var/log/ftpd, zaś sesji równoległych do /var/run/utmp. Sprawi to także, że sesje te będą widoczne przez polecenie who(8). Można również akceptować tylko i wyłącznie anonimowe połączenia, korzystając z opcji -A. Oto odpowiedni wpis (używamy także opcji -ll która powoduje, że każde połączenie jest logowane do sysloga, włączając w to komendy ftp takie jak get, retrieve itd):

ftp             stream  tcp     nowait  root    /usr/libexec/ftpd       ftpd -llUSA

Uwaga: W przypadku, gdy przewidywane jest bardzo duże obciążenie serwera ftp, zaleca się nie wywoływać ftpd z poziomu inetd.conf. Najlepiej jest wówczas wykomentować odpowiednią linię z pliku inetd.conf i uruchomić ftpd z poziomu rc.conf.local z włączoną opcją -D. Sprawi to, że demon będzie działał szybciej, niż gdyby został uruchomiony z inetd.conf. Oto przykład pokazujący jak uruchomić demona ftp z poziomu rc.conf.local:

ftpd_flags="-DllUSA"           # for non-inetd use: ftpd_flags="-D"

Zadziała to oczywiście tylko wtedy, jeśli wcześniej wykomentowano odpowiedni wpis z /etc/inetd.conf oraz nakazano demonowi intetd ponownie przeczytać swój plik konfiguracyjny.

Inne ważne pliki

10.14 - Ograniczanie dostępu użytkowników wyłącznie do ich katalogów domowych w ftpd(8)

Domyślnie logując się przez ftp, użytkownicy mogą zmienić katalog na każdy do którego mają dostęp. W niektórych przypadkach może to być niepożądane. Istnieje możliwość ograniczenia tego co użytkownicy widzą w sesji ftp, poprzez chrootowanie ich w ich katalogach domowych.

Jeżeli chcesz zezwolić tylko na chrootowane połączenia ftp, przyjżyj się opcji -A w ftpd(8).

Jeżeli chcesz ograniczyć ich bardziej delikatnie, login.conf(8). oraz ftpd(8). mogą to ułatwić.

Użytkownicy w klasie logowania z ustawioną zmienną ftp-chroot będą chrootowani automatycznie. Dodatkowo, możesz dodawać nazwy użytkowników do pliku /etc/ftpchroot by chrootować tych użytkowników. Wystarczy by dany login był wpisany w jednej z tych dwóch lokalizacji.

10.15 - Łatanie systemu OpenBSD

Nawet w OpenBSD zdarzają się błędy. Niektóre błędy mogą doprowadzić problemów z niezawodnością (tj. coś może spowodować, że system przestanie pracować jak zaplanowano). Inne błędy mogą doprowadzić do problemów z bezpieczeństwem (te mogą pozwolić innym na "użycie" twojego komputera w niezamierzony sposób). Gdy zostanie wykryty błąd krytyczny, poprawka zostaje dodana do drzewa źródłowego wersji current, oraz wydawane są łatki dla każdej wspieranej wersji OpenBSD. Łatki te pojawiają się na stronie errat i są dzielone na "wspólne", obejmujące wszystkie platformy , oraz erraty działające w ramach jednej lub kilku, ale nie wszystkich, platform.

Proszę zwrócić uwagę na to, że łatki nie są jakimiś nowymi dodatkami do OpenBSD; są tworzone tylko wtedy, gdy powstanie problem związany z niezawodnością lub bezpieczeństwem systemu. Dlatego też łatki z reguły powinny być jak najszybciej aplikowane na objętych nimi maszynach (co często NIE oznacza wszystkich maszyn, w zależności od ich przeznaczenia).

Są trzy możliwości uaktualnienia systemu z poprawionym kodem:

Jeszcze raz, łatanie poszczególnych plików nie zawsze jest proste, zatem poważnie pod uwagę możliwość podążania za wersją -stable odgałęzienia OpenBSD. Mieszanie i dopasowywanie łatek możesz wykonywać tylko jeżeli rozumiesz jak wszystko działa, ale nowi użytkownicy powinni wybrać jedną metodę i tej metody się trzymać.

Jak łatki "erraty" różnią się od tego co znajduje się w drzewie CVS?

Wszystkie łatki publikowane na stronie errat są przeznaczone do aplikowania na wskazany kod źródłowy danej wersji systemu (ang. release system). Łatki znalezione w najnowszym drzewie CVS mogą dodatkowo spowodować zmiany, które byłyby niepożądane w podstawowej wersji systemu. To jest bardzo ważne: jeżeli instalowałeś system ze "snapshota", sprawdziłeś źródła w czasie gdy pobierałeś snapshot i usiłowałeś załatać je korzystając z opublikowanej łatki, może lepiej zachowaj wersję przed użyciem łaty, jako że kod może ulec zmianie.

Nakładanie łatki

Łaty dla systemu OpenBSD są rozpowszechniane jako "ujednolicone diff'y", które są plikami tekstowymi zawierającymi różnice w stosunku do oryginalnego kodu źródłowego. NIE są dystrybuowane w formie binarnej! Oznacza to, że aby załatać swój system musimy mieć kod źródłowy wersji RELEASE OpenBSD. W szczególności powinieneś posiadać pełne dostępne drzewo źródeł. Jeżeli korzystasz z wersji dostępnej z oficjalnych płyt CD, źródła znajdują się na płycie 3, są także dostępne jako pliki z serwerów FTP. Zakładamy że posiadasz pełne i sprawdzone źródła.

W ramach naszego przykładu, przyjżymy się łatce 001 dla OpenBSD 3.6 dotyczącej sterownika st(4) obsługującego napędy taśmowe. Bez wspomnianej łatki, odzyskiwanie danych z backupu jest dość kłopotliwe. Osoby korzystające z napędów taśmowych potrzebują tej łatki, jakkolwiek w przypadku osób nie korzystających z napędu taśmowego nie ma szczególnego powodu na instalowanie tej łatki. Przyjżyjmy się łatce:

# more 001_st.patch
Apply by doing:
        cd /usr/src
	patch -p0 < 001_st.patch
	
Rebuild your kernel.

Index: sys/scsi/st.c
===================================================================
RCS file: /cvs/src/sys/scsi/st.c,v
retrieving revision 1.41
retrieving revision 1.41.2.1
diff -u -p -r1.41 -r1.41.2.1
--- sys/scsi/st.c       1 Aug 2004 23:01:06 -0000       1.41
+++ sys/scsi/st.c       2 Nov 2004 01:05:50 -0000       1.41.2.1
@@ -1815,7 +1815,7 @@ st_interpret_sense(xs)
	u_int8_t skey = sense->flags & SSD_KEY;
        int32_t info;

        if (((sense->flags & SDEV_OPEN) == 0) ||
+       if (((sc_link->flags & SDEV_OPEN) == 0) ||
(serr != 0x70 && serr != 0x71))
return (EJUSTRETURN); /* let the generic code handle it */
Jak pewnie zauważyłeś nagłówek łaty zawiera krótkie instrukcję jak należy postępować. Załóżmy że umieściłeś tą łatę w katalogu /usr/src, w takiej sytuacji następnym krokiem jest:
# cd /usr/src
# patch -p0 < 001_st.patch

Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|Apply by doing:
|       cd /usr/src
|        patch -p0 < 001_st.patch
|
|Rebuild your kernel.
|
|Index: sys/scsi/st.c
|===================================================================
|RCS file: /cvs/src/sys/scsi/st.c,v
|retrieving revision 1.41
|retrieving revision 1.41.2.1
|diff -u -p -r1.41 -r1.41.2.1
|--- sys/scsi/st.c      1 Aug 2004 23:01:06 -0000       1.41
|+++ sys/scsi/st.c      2 Nov 2004 01:05:50 -0000       1.41.2.1
--------------------------
Patching file sys/scsi/st.c using Plan A...
Hunk #1 succeeded at 1815.              <-- Szukaj takiej informacji!
done
Zwróć uwagę na komunikat "Hunk #1 succeeded". Oznacza on, poprawne nałożenie łatki. Wiele łatek jest znacznie bardziej skomplikowanych niż ta, zatem ilość takich komunikatów bedzie znacznie większa; powinieneś sprawdzić czy wszystkie fragmenty we wszystkich plikach zostały zaktualizowane poprawnie. Jeśli nie, zazwyczaj oznacza to, że posiadasz niewłaściwe źródła, nie wypełniłeś wszystkich instrukcji uważnie, lub twoja łatka jest poszarpana. Łaty są bardzo wrażliwe na "białe znaki" - kopiowanie i wklejanie z twojej przeglądarki internetowej często zmieni znaki tabulacji na spacje lub odwrotnie, czyniąc ją bezużyteczną.

W tym momencie, możesz przystąpić do budowy jądra, zainstalowania go i zrestartowania systemu.

Nie wszystkie łaty dotyczą jądra. W niektórych przypadkach, będziesz musiał przebudować pojedyńcze narzędzia. W innych będziesz potrzebował przebudować wszystkie narzędzia statycznie zlinkowane z łataną biblioteką. Zastosuj się do informacji w nagłówku łaty, a gdy masz wątpliwości przebuduj cały system

Łaty nie mające zastosowania dla twojego określonego systemu, zazwyczaj nie powinny być nakładane. Dla przykładu, jeżeli nie posiadasz napędu taśmowego, nie odniesiesz żadnej korzyści z opisanej wyżej łaty. Jakkolwiek, łaty mogą przypuszczalnie być zakładane "w kolejności" - istnieje możliwość, że późniejsza łatka jest powiązana z jedną z wcześniejszych. Bądź uważny jeżeli postanowisz "grymasić" z łatkami które nakładasz, i w przypadku wątpliwości, nałóź je wszystkie w kolejności.

10.16 - Zastosowanie środowiska chroot(2) dla serwera Apache.

W systemie OpenBSD, serwer HTTP Apache ( httpd(8)) jest uruchamiany domyślnie w środowisku zmodyfikowanym poleceniem chroot(2). Chociaż jest to wspaniałe z punktu widzenia bezpieczeństwa systemu, mogą się z tym wiązać pewne niespodzianki dla osób nieprzygotowanych na taką zmianę.

Co to jest chroot?

Proces działający w środowisku zmodyfikowanym poleceniem chroot(2) (dalej będziemy pisali po prostu: "proces działający w środowisku chroot") jest ograniczony do określonego katalogu i nie ma możliwości "chodzenia" po reszcie drzewa katalogów. Katalog, w którym proces zostaje "zamknięty", jest postrzegany przez ten proces jako katalog "/" (root). W przypadku httpd(8), proces ten startuje, otwiera swoje pliki dziennika, podłącza się do swojego portu TCP (chociaż nie przyjmuje jeszcze danych) i odczytuje swój plik konfiguracyjny. Następnie "zamyka się" w /var/www, oddaje przywileje, a potem rozpoczyna przyjmowanie żądań. Oznacza to, że wszystkie pliki wysyłane bądź odbierane przez serwer Apache muszą znajdować się w katalogu /var/www. W domyślnej konfiguracji OpenBSD, wszystkie pliki w /var/www mają atrybuty tylko do odczytu dla użytkownika www z uprawnieniami którego chodzi Apache. Ogromnie pomaga to w podniesieniu bezpieczeństwa systemu -- jeżeli nastąpiło by włamanie poprzez serwer Apache, to zniszczenia dokonane przez włamywacza byłyby ograniczone do jednego katalogu z prawami "tylko do odczytu" -- bez dostępu do zasobów, które można by wykorzystać do niecnych zamiarów.

Co to oznacza dla administratora?

Nie owijając w bawełnę trzeba powiedzieć, że uruchamianie serwera Apache w środowisku chroot(2) jest czymś nowym. Dlatego też wiele starszych programów czy ustawień systemowych przestanie działać, bez kilku przeróbek. Ponadto musimy pamiętać, że bezpieczeństwo i wygoda często nie są kompatybilnymi założeniami. Implementacja Apache w OpenBSD nie jest kompromisem bezpieczeństwa względem funkcjonalności i "wygody".

Jak więc widać, w niektórych przypadkach, programy lub ustawienia mogą być zmienione tak, by działały w środowisku chroot(2). W innych przypadkach trzeba będzie po prostu wyłączyć chroot(2) za pomocą opcji -u demona httpd(8) w pliku /etc/rc.conf

Przykład chrootowania w aplikacji wwwcount

Jako przykład procesu pozwalającego na umieszczenie aplikacji w chroot(2)-cie weźmiemy wwwcount, prosty licznik odwiedzin stron dostępny w pakiecie. Będąc bardzo wydajnym narzędziem, wwwcount nie wie nic na temat chroot(2)-owanego Apache'a, zatem nie będzie pracował w domyślnej konfiguracji.

Na początek instalujemy pakiet wwwcount. Konfigurujemy go i testujemy, a także odkrywamy że wydaje się nie działać, otrzymując błąd Apache "Internal Server Error". Następnie zatrzymujemy Apache'a i restartujemy z opcją -u i sprawdzamy, że problemem jest chroot(2), nie konfiguracja.

# apachectl stop
/usr/sbin/apachectl stop: httpd stopped
# httpd -u
Po tym wszystkim, widzimy że licznik działa poprawnie, przynajmniej po zmianie właściciela katalogu, tak by Apache (oraz CGI) mógł zapisywać do plików tam umieszczonych. Zatem, zdecydowanie mamy problem z chroot'em. Zatrzymujemy więc i uruchamiamy Apache ponownie, z domyślmym chrootem.
     
# apachectl stop
/usr/sbin/apachectl stop: httpd stopped
# httpd

Dobrym punktem wyjścia byłoby założyć, że wwwcount używa bibliotek i innych plików do których nie ma dostępu przez chroot. Możemy użyć polecenia ldd(1) by sprawdzić zależności jakich wymaga CGI:

# cd /var/www/cgi-bin/
# ldd Count.cgi
Count.cgi:
         Start    End      Type Ref Name
         00000000 00000000 exe   1  Count.cgi
         03791000 237ca000 rlib  1  /usr/lib/libc.so.30.3
         03db4000 03db4000 rtld  1  /usr/libexec/ld.so
Ok, znaleźliśmy problem, dwa pliki które nie są dostępne w środowisku chroot(2) Apache'a. Kopiujemy je zatem:
     # mkdir -p /var/www/usr/lib /var/www/usr/libexec
     # cp /usr/lib/libc.so.30.3 /var/www/usr/lib
     # cp /usr/libexec/ld.so /var/www/usr/libexec
i sprawdzamy licznik ponownie.

Teraz program przynajmniej się uruchamia i zwraca nam błąd: "Unable to open config file for reading". Mamy postęp, lecz jeszcze nie skończyliśmy. Normalnie plikiem konfiguracyjnym jest /var/www/wwwcount/conf, jednak w środowisku chroot wydaje się że jest to /wwwcount/conf. Możemy więc albo przekompilować program tak by korzystał z plików w miejscu gdzie są teraz, albo przenieść te dane. Ponieważ zainstalowaliśmy program z pakietu, po prostu przeniesiemy pliki. Aby używać tej samej konfiguracji zarówno w środowisku chroot(2), jak i normalnym, możemy zrobić dowiązanie symboliczne:

     # mkdir -p /var/www/var/www
     # cd /var/www/var/www
     # ln -s ../../wwwcount wwwcount
Zauważmy, że link symboliczny będzie działał wewnątrz chroota. Ponownie testujemy... i znajdujemy jeszcze jedno zagadnienie. Teraz wwwcount narzeka, że nie może znaleźć plików "strip image", których używa przy wyświetlaniu wiadomości. Po krótkich poszukiwaniach, odnajdujemy je w /usr/local/lib/wwwcount, zatem muszą zostać skopiowane do chroot'a.
# tar cf - /usr/local/lib/wwwcount | (cd /var/www; tar xpf - )
Testujemy ponownie... i wszystko działa!

Zwróć uwagę, że skopiowaliśmy tylko te pliki które są absolutnie niezbędne. Generalnie, tylko minimalna ilość plików potrzebna do uruchomienia aplikacji powinna być kopiowana do chroot'a.

Czy powinienem korzystać z funkcjonalności chroot-a?

W powyższym przykładzie, program był bardzo prosty, a mimo to natrafiliśmy na kilka różnych problemów.

Nie każdą aplikację można lub powinno się chroot(8)-ować.

Celem jest bezpieczny serwer www, chroot(8) jest tylko narzędziem doskonalącym to zadanie, lecz sam nie jest celem. Pamiętaj, początkowa konfiguracja chroot(2)-owanego Apache'a w OpenBSD oznacza, że użytkownik z uprawnieniami którego działa httpd(8), nie może uruchamiać żadnych programów, nie może modyfikować żadnych plików, a także nie może przejmować tożsamości innych użytkowników. Tracąc te ograniczenia, tracisz bezpieczeństwo, nie ważne czy chrootowane czy nie.

Niektóre aplikacje bywają bardzo proste, więc chroot(2)-owanie ich ma sens. Inne bywają dość skomplikowane i albo nie są warte wysiłku by umieścić je w chroot(2), albo podczas kopiowania systemu w chroot, możesz stracić korzyści środowiska chroot(2). Przykładowo, program OpenWebMail wymaga dostępu do czytania i zapisu katalogów z pocztą, katalogów domowych użytkowników, a także musi mieć możliwość działania jako jakikolwiek użytkownik w systemie. Usiłowanie wepchnięcia go w chroot jest zupełnie bezcelowe, ponieważ w rezultacie i tak pozbawisz się wszystkich zalet chroot(2)-owania. Nawet w przypadku aplikacji tak prostej jak nasza, musi ona zapisywać na dysk (by zapamiętywać liczniki), więc niektóre korzyści z chroot(2)-a są tracone. Generalnie, tylko minimum plików koniecznych by aplikacja działała powinno być kopiowane w chroot.

Usiłowanie chroot(2)-owania jakiejkolwiek aplikacji działającej z uprawnieniami root-a jest bezcelowe, root generalnie może uciec z chroot(2)-a.

Nie zapomninaj także, że w sytuacji gdy chrootowanie jakiejś aplikacji okaże się bardzo trudne, możesz nie aktualizować systemu tak często jak powinieneś. Może to spowodować, że twój system będzie MNIEJ bezpieczny, niż bardziej zarządzalny system z wyłączoną funkcjonalnością chroota.

10.17 - Mogę zmienić powłokę roota?

Czasem mówiono że nie należy zmieniać powłoki użytkownika root, aczkolwiek w OpenBSD nie ma powodów by tego nie robić.

Domyślną powłoką użytkownika root w systemach OpenBSD jest ksh.

Tradycyjnym przykazaniem administratora Uniksa jest korzystanie jako root tylko ze statycznie skompilowanych powłok, ponieważ kiedy system przechodzi w tryb pracy pojedynczego użytkownika (ang. single user), partycje nie należące do tego użytkownika nie są montowane, zatem dynamicznie łączone powłoki nie będą w stanie skorzystać z bibliotek zlokalizowanych w partycji /usr. Nie jest to coś, o czym administrator systemu OpenBSD musi pamiętać, ponieważ gdy system przejdzie w tryb pojedynczego użytkownika to sam poprosi o wybranie powłoki, zaś domyślną powłoką jest sh. W systemie OpenBSD standardowo znajdują się trzy powłoki (csh, sh oraz ksh). Wszystkie z nich są zlinkowane statycznie, tak więc dostępne są również w trybie pojedynczego użytkownika.

10.18 - Co jeszcze można zrobić z ksh?

W systemie OpenBSD wywoływana poleceniem ksh powłoka to w rzeczywistości pdksh (Public Domain Korn Shell). Ksh ma te same binaria co powłoka sh.

Użytkownicy posługujący się swobodnie powłoką bash (często spotykaną w systemie Linux), prawdopodobnie odnajdą w ksh wiele podobieństw. Ksh(1) posiada większość funkcji spotykanych w powłoce bash, włączając w to dopisywanie nazw plików po naciśnięciu klawisza Tab, redagowanie i przeglądanie listy wydanych wcześniej poleceń za pomocą klawiszy strzałek oraz przeskakiwanie na początek/koniec redagowanego polecenia za pomocą klawiszy CTRL-A/CTRL-E. Jeżeli potrzebne są inne funkcje powłoki bash, bash można zainstalować korzystając z pakietów lub pakietów.

Znak zachęty powłoki ksh można z łatwością zmienić z domyślnego "$ " na coś, co dostarczy użytkownikowi więcej informacji przez ustawienie zmiennej PS1. Na przykład, wstawienie następującej linii:

    export PS1='$PWD $ '
do pliku /etc/profile spowoduje wygenerowanie następującego znaku zachęty:
    /home/nick $
Zachęcamy też do przeanalizowania pliku /etc/ksh.kshrc, w którym znajduje się wiele przykładów tego, co można zamieścić w pliku .profile.

Dostępna w OpenBSD powłoka ksh(1) zostało rozszerzone o kilka "specjalnych znaków" dla podstawowego znaku zachęty, PS1, podobnych do tych wykorzystywanych w bashu. Dla przykładu:

\e - Wstaw znak ASCI - escape.
\h - Nazwa hosta, bez nazwy domeny.
\H - Pełna nazwa hosta, łącznie z nazwa domeny.
\n - Wstaw znak nowej linii.
\t - Aktualny czas w formacie: HH:MM:SS (24-godzinnym).
\u - Aktualna nazwa użytkownika.
\w - Aktualny katalog roboczy. $HOME jest skracany do `~'.
\W - Nazwa aktualnego katalogu roboczego bez wiodącej ścieżki.
\$ - Wyświetli "#" dla root-a, "$" dla pozostałych użytkowników.
(na stronie manuala ksh(1) znajdziesz więcej szczegółów a także znacznie więcej "znaków specjalnych"! Zwróć uwagę że znak "$" ma specjalne znaczenie wewnątrz podwójnego cytowania, zatem używaj go ostrożnie)

Niektórzy mogą użyć poniższego polecenia:

export PS1="\n\u@\H\n\w \\$ "
by otrzymać zbyt rozwlekły ale w jakiś sposób użyteczny prompt.

[Spis treści] [Sekcja 9 - Migracja do OpenBSD] [Sekcja 11 - X Window System]


[back] www@openbsd.org
$OpenBSD$