Linux-EduCD

Rajmund Radziewicz

NIS (Network Information Service), czyli usługa informacji sieciowej — jest uniksową usługą udostępniania komputerom w sieci takich informacji, jak loginy, hasła, klucze, czy np. dane o grupach.

Jest doskonałym sposobem na scentarlizowane zarzadządzanie użytkownikami i katalogami domowymi. Sprawdza się w przypadkach — kiedy mamy dużą ilość kont (lub planujemy mieć dużą) i chcielibyśmy zakładać/kasować te konta tylko na jednym komputerze. Oczywiście logować się na nie użytkownicy będą mogli z dowolnego hosta.
NIS jest ściśle powiązany z NFSem, który posłuży nam tutaj do eksportowania katalogów domowych z serwera.
Rozwiązanie jakie postaram się przybliżyć, z pewnością może okazać się przydatne w szkolnej sieci, gdzie z jednej pracowni komputerowej może korzystać przykładowo kilkaset osób. W momencie kiedy administrator chce, aby każda z takich osób miała swoje unikalne konto – NIS jest tym, co znacznie ułatwi mu życie.

Żeby działał NIS, w sieci musi być komputer pełniący rolę tzw. nadrzędnego serwera NIS (podrzędne – zapasowe, nie są konieczne. Posiadają one tylko kopię baz danych NIS i otrzymują te kopie od nadrzednego serwera tylko wtedy, kiedy robione są jakieś zmiany w głównej bazie. Przydatne stają się przy bardzo dużych sieciach, o zastosowaniach krytycznych, gdzie niezwykle ważna jest bezawaryjność).

Bazy danych NIS przechowywane są w tak zwanym formacie DBM. Jest to format dużo bardziej zoptymalizowany pod kątem odczytu — niż zwykły plik tekstowy. W bazach tych są właśnie informacje na temat kont, czy grup i są one udostępniane klientom przez nadrzędny serwer NIS. Takie eksportowane bazy określa sie jako mapy (maps).

Zacznijmy więc od konfiguracji klienta. W naszym przypadku klient to komputer o nazwie ‘Linux-EduCD’ i adresie ip: 192.168.0.11. Serwer to komputer o nazwie ‘educd-serv’ i ip: 192.168.0.1

Na kliencie powinny być uruchomione dwa demony – ypbind, zajmujący się obsługą żądań, oraz ypwhich – który odpowiada za lokalizacje nadrzednego serwera NIS. Ponadto wymagany jest działajacy demon portmap. Zanim to wszystko uruchomimy, musimy jednak ustawić wcześniej kilka rzeczy.

Poleceniem “domainname” ustawiamy na kliencie nazwę naszej domeny NIS. Jest to coś zupełnie innego niż “typowa” nazwa domeny, czy np. dns. Działa tylko na potrzeby NISa i powinna różnić się od nazwy dns-owej.
Powiedzmy, że nasza domena będzie się nazywała “Knoppixdomain”. Jako użytkownik root, ustawiamy więc tę nazwę, wpisując w terminalu:

domainname Knoppixdomain

Żeby nazwa domeny była ustawiana przy każdym starcie komputera, należy ją umieścić w pliku /etc/defaultdomain (skasujmy tę, która już tam jest). Nie powinna być to również nazwa tożsama z nazwą hosta.

Następnie w /etc/yp.conf (główny plik konfiguracyjny demona ypbind) umieszczamy tę nazwę + nazwę serwera NIS:

domain Knoppixdomain server educd-serv

Następnie (WAŻNE) należy umieścić również odpowiedni wpis w /etc/hosts razem z numerem ip:

192.168.0.1     educd-serv
ypserver        educd-serv

Istotne  jest teraz, żeby ustawić zakres informacji, jakie będą przekazywane
w ramach usług NIS. Zakres ten jest zdefiniowany w pliku /etc/nsswitch.conf

W /etc/nsswitch.conf powinno się zatem znaleźć:

passwd:   compat
group:    compat
shadow:   compat
netgroup: nis

Oraz przy dyrektywie “hosts” wpis:

hosts:  files dns nis

Ważny jest wpis ‘dns’ przy “hosts” na drugim miejscu. Bez niego nie będą działały serwery nazw ustawione w /etc/resolv.conf na klientach!

Teraz konieczna będzie modyfikacja plików z hasłami i grupami. W /etc/passwd dodajemy na końcu pliku
linijke:

+::::::

Możemy także użyć znaczków +/-, aby włączyć/wyłączyć lub zmienić użytkowników, korzysatjących z NIS.
Przykładowo:

+rajmund::::::
+moodle::::::
+wujek_franek::::::

Jeśli używasz pliku /etc/shadow, taki wpis musi się znaleźć również tam.

Do /etc/group dodajemy natomisat:

+:::

Wystartujemy teraz usługę NIS i portmappera (jeśli pamiętasz definicję portmapa z artykułu o NFS, to jest on serwerem, który zamienia numery programowe RPC na numery portów protokołu TCP/IP . Musi być uruchomiony, aby działało oprogramowanie klienta NIS):

cd /etc/init.d

./nis start

./portmap start

Możesz sprawdzic, czy klient komnikuje się z serwerem przez wpisanie:

ypwhich educd-serv

Ustawiamy teraz serwer NIS

W /etc/hosts dopisujemy:

192.168.0.1     educd-serv    educd-serv
192.168.0.11    Linux-EduCD

W /etc/defaultdomain ustawiamy znaną już nazwę domeny (w sposób analogiczny, jak na kliencie).

Teraz powinniśmyy w /etc/init.d/nis ustawić następującą wartość, przy NISSERVER:

NISSERVER=master

Ustawiamy teraz taką samą opcję w /etc/default/nis

Teraz przyszła kolej na edycję pliku /etc/ypserv.securenets. Jego zawartość określa, które
komputery w sieci będą miały dostęp do map serwera nisowego. Domyślnie jest tam wpis,
mówiący, że każdy komputer, który może połączyć się z serwem nadrzędnym — ma do nich dostęp
i może korzystać z usług NIS. Zakres można ustawić podając kombinację maski i adresu sieci, np:

255.0.0.0       127.0.0.0

To powyżej, pozwoli na dostęp wyłącznie z adresu localhost. Możemy więc ustawić tu wartość:

255.0.0.0    192.168.0.0

Jako że na serwerze najważniejsze jest ustawienie zawartości naszej eksportowane bazy danych (mapy), zajrzyjmy jeszcze do jej definicji w /var/yp/Makefile

Upewnijmy się, że w /var/yp/Makefile, jest odkomentowana linia z wpisami:

ALL =   passwd group hosts rpc services netid protocols netgrp shadow

(istotny jest ‘shadow’, jeśli go nie ma — należy dopisać).

oraz że opcje:

‘MERGE_PASSWD’ i ‘MERGE_GROUP’ ustawione są na ‘true’.

Opcje ‘MINUID’ (minimalne id klienta) ustawiliśmy na ’100′ Niżej są już konta admninistracyjne, więc nie będzie to zbyt zalecane.

Teraz tylko:

cd /etc/init.d
./nis stop
./nis start
./portmap start

Na koniec musimy wygenerować mapę, żeby mogła być “widoczna” w domenie NIS. Wykonujemy polecenie:

/usr/lib/yp/ypinit -m

W tym momencie mamy już scentarlizowane zarządzanie kontami. Pozostaje nam tak
skonfigurować NFS, żeby można było udostępniać katalogi domowe z serwera.

Na serwerze startujemy tylko odpowiednie usługi. Katalog /home już jest
udostępniony w /etc/exports (sprawiła to domyślna konfiguracja LTSP, jaką zapewne
mamy w Linux-EduCD po instalacji). Więc:

cd /etc/init.d
./nfs-kernel-server start

rpc.mountd && rpc.nfsd

Na kliencie natomiast montujemy katalog /home z serwera – w miejsce oryginalnego /home
(nam zależy na możliwości zakładania kont wyłącznie z serwera NIS):

mount -t nfs 192.168.0.1:/home /home

Teraz (KONIECZNIE) musimy dopisać polecenie montowania do skryptów startowych (najlepiej w pliku umieszczonym w /etc/init.d klienta i z dowiązaniem do niego w /etc/rcS.d)

Odpowiednio inne wpisy powinny się także znaleźć w skryptach startowych serwera (naszego educd-serv z ip: 192.168.0.1). Wystarczy jak w /etc/init.d umieścimy mały skrypcik (np. startuj_nis) o zawartości:

——–
#!bin/bash

cd /etc/init.d ; ./nfs-kernel-server start

rpc.mountd && rpc.nfsd

./nis start
———-

Należy pamietać także o dowiązaniu w /etc/rcS.d:

cd /etc/rcS.d/
ln -s /etc/init.d/startuj_nis S40cokolwiek

Pamiętajmy również, że po każdorazowym dodaniu konta na serwerze, zanim zalogujemy się na klienta, należy zrestartować nisa i wykonać:

/usr/lib/yp/ypinit -m

Teraz wystarczy na serwerze założyć dowolną liczbę kont (np. za pomocą adduser), wywołać:

cd /etc/init.d ; ./nis restart

/usr/lib/yp/ypinit -m

… i możemy logować się na nie z komputera o adresie 192.168.0.11

Rajmund Radziewicz

Po standardowej kompilacji oprogramowania PostgreSQL – instalacja znajdzie się w katalogu /usr/local/pqsql.Docelowe miejsce może różnić się, jeśli instalujemy bazę z paczek (np. debów lub rpmów). Wszystkie polecenia Postgresa są dostępne z poziomu /usr/local/pgsql/bin. Należy więc dodać tę lokalizację do zmiennej PATH powłoki z którą pracujemy. Jeśli jest to bash, csh lub tcsh powinieneś dodać:

% set path = ( /usr/local/pgsql/bin path )

W bazowym katalogu znajdzie się siedem podkatalogów przechowujących składniki naszej bazy: programy, biblioteki, pliki nagłówkowe itp. Mamy więc podkatalog bin (programy składające się na PosgreSQL), include, lib (biblioteki i pliki nagłówkowe pomocne przy tworzeniu aplikacji klienckich), doc (dokumentacja), man (strony podrecznika systemowego), share (przykłady plików konfiguracyjnych i kopie zapasowe) oraz data (instalacja bazy).
Za tworzenie nowej bazy odpowiedzialny jest program initdb.
Domyślna instalacja przykładowej bazy za pomocą tego programu zawiera informacje o koncie superusera oraz bazę template1. Aby utworzyć dodatkową, można uzyć analogicznego programu o nazwie createdb.
Serwer PostgreSQL uruchamia się jako proces w systemach uniksowych. Taki proces nazywa się postmaster i musi cały czas działać jako demon, żeby umożliwić łączenie się z bazą. W czasie połaczeń z serwerem postmaster uruchamia dodatkowy proces – postgres. Obsługuje on połączenia aplikacji klienckich z bazą danych. Postmaster nie może być uruchamiany z uprawnieniami użytkownika root. Powinno się utworzyć specjalnego użytkownika do tego celu (np. postgres).
Do sterowania procesem postmaster słuzy narzedzie pg_ctl. Za jego pomocą możemy zatrzymywać, uruchamiać i sprawdzać status serwera:

pg_ctl start [-w] [-D DATADIR] [-s] [-l FILENAME] [-o "OPTIONS"]
pg_ctl stop [-W] [-D DATADIR] [-s] [-m SHUTDOWN-MODE]
pg_ctl restart [-w] [-D DATADIR] [-s] [-m SHUTDOWN-MODE] [-o "OPTIONS"]
pg_ctl reload [-D DATADIR] [-s]
pg_ctl status [-D DATADIR]

Wszyscy użytkownicy bazy PosgreSQL muszą figurować w odpowiedniej tabeli
pg_user. Wydając więc dla przykładu zapytanie:

simp=# SELECT usename, usesysid FROM pg_user;

- otrzymamy wykaz wszystkich użytkowników wraz z ich identyfikatorem.
Do utworzenia nowego użytkownika służy program createuser. Pozwala on na ustawienie serwera do którego chcemy przypisać użytkownika, oraz praw (np. do aktualizowania danych w bazie). Uzytkownika możemy też stworzyć ręcznie np:

simp=# CREATE user “simp” WITH PASSWORD ‘password’ NOCREATEDB

Do usunięcia użytkownika służy polecenie sql DROP ( dropuser [opcje] nazwa_usera).
Możemy tworzyć też w Postgresie grupy (do ustawiania zbiorowych uprawnień). Służy do tego polecenie: CREATE GROUP nazwa. Do kontroli uprawnień (zarówno na poziomie uzytkowników jak i grup) służy polecenie GRANT:

simp=# GRANT SELECT, INSERT ON simp TO GROUP studenci;

W tej chwili użytkownicy z grupy studenci mogą wybierać i wprowadzać dane
do tablicy simp. Do obierania uprawnień służy polecenie REVOKE:

simp=# REVOKE INSERT ON simp FROM rajmund;

To polecenie odbiera użytkownikowi rajmund uprawnienia do wprowadzania
danych do tabeli simp.

Perspektywy

Perspektywy umożliwiają tworzenie ograniczonego widoku na określone
dane w bazie. Jeśli mamy np. tabelę studenci – i nie chcemy, żeby wszystkie dane z tej tabeli były dostępne nawet dla osób majacych uprawnienia do tej tabeli – możemy posłużyć się perspektywą.

Tworzenie i usuwanie bazy.

Nową bazę tworzymy za pomocą polecenia CREATE DATABASE np:

simp=# CREATE DATABASE nazwa
[WITH [LOCATION = 'sciezka']
[TEMPLATE = szablon]
[ENCODING = kodowanie]

Do usunięcia bazy posłuży oczywiście polecenie DROP.

Kopie zapasowe

PosgreSQL pozwala na tworzenie kopii zapasowych i procedur odtwarzania danych. Służą do tego programy: pg_dump, pg_dumpall i pg_restore. Polecenie utworzenia kopii zapasowej w najprostszej
postaci może wyglądać następująco:

pg_dump simp | gzip > simp_kopia.gz

Pg_dumpall służy do wykonywania kopii wszystkich baz w całej instalacji.
Ponieważ polecenie pg_dump pozwala na określanie formatu wykonywanego
backupu (np. pg_dump -F t, utworzy format archiwum tar), polecenie
pg_restore służy do odtwarzania kopii z archiwum.

Aktualizacja wersji

Co jakiś czas ukazuje się nowa wersja serwera PostgreSQL. Proces
aktualizacji całego systemu baz danych wspomaga narzedzie pg_upgrade. Przed aktualizacją należy jednak zrobić kopię zapasową wszystkich danych.

Wydajność

Jeżeli nasza baza jest niezbyt pokaźnych rozmiarów, sprawy takie jak indeksy czy wydajność mogą nie mieć dużego znaczenia. Nabierają go jednak – gdy okazuje się, że nasze dane rozrastają się
w szybkim tempie, bądź mają być wykorzystywane przez wiekszą liczbę użytkowników. Jednym z poleceń, poprawiających wydajność bazy jest VACUUM. Za jego pomocą odzyskujemy m.in miejsce w bazie (utracone np. w
wyniku procedur rollback, czyli cofania nieudanych transakcji) oraz aktualizujemy statystyki optymalizatora. Dla przykładu:

simp=# vacuum verbose studenci;
NOTICE: –Relation studenci–
NOTICE: Pages 1: Changed 1, reaped 1, Empty 0, New 0, Crash 0
UnUsed 0, MinLen 110, MaxLen 128, Re-using: Free/Avail. Space
7005/0 EndEmpty/Avail. Pages 0/0. CPU 0.00s/0.00u sec.
[...]

Ponieważ dodaliśmy do polecenia opcję verbose, system wyświetlił
nam też niektóre statystyki .

Sposób autoryzacji (kwestia pytania o hasło przy próbie połączenia z bazą) zdefiniowana jest w pliku pg_hba.conf znajdującym się w katalogu z danymi Postgresa. Na końcu tego pliku znajują się dwie takie linie:

local all trust
host all 127.0.0.1 255.255.255.255 trust

Oznaczają one, że dla połączeń lokalnych (local) – czyli takich gdzie łączymy się nie korzystająć z socketów tcp/ip, dla dowolnej bazy (all) system ma przyjąć regułę niepytania o hasło (trust).
dla połączeń zdalnych, ale tylko z maszyny o adresie 127.0.0.1 (czyli z tego samego komputera, ale przez sockety tcp/ip), też będzie ta sama reguła.
Aby to zmienić należy zmienić ostatnie słowo (trust) na “password”, “crypt” lub “md5″ (różnią się one metodą przesyłania hasła oraz akceptowalną długością hasła). Np. zapis:

host all 81.15.147.193 255.255.255.0 password

Oznacza, że osoby łączące się z serwera o ip 81.15.147.193 oraz z całej klasy C muszą podać hasło, aby dostać się do dowolnej bazy

Rajmund Radziewicz

Sieciowy system plików NFS – jest mechanizmem pozwalającym na współdzielenie zasobów pomiędzy komputerami w sieci. Jest to narzędzie o tyle korzystne w przypadku dystrybucji livecd (Knoppix, Linux-EduCD, Ubuntu), że podczas pracy bezpośrednio z płyty mamy możliwość centralnego zapisywania danych przez użytkowników – np. na szkolnym serwerze.Ponieważ w linuksie każde urządzenie reprezentowane jest jako plik, można w ten sam sposób udostępniać w sieci wszelkie wymienne napędy. Najprostszy scenariusz wykorzystania NFS-a w sieci mógłby wyglądać następująco: Na jednym komputerze (będzie to nasz “serwer plików”) zainstalowany jest Knoppix na twardym dysku. Udostępnia on poprzez NFS katalog: users. W katalogu tym są podkatalogi utworzone specjalnie dla użytkowników w taki sposób .. że każdy z poszczególnych hostów w sieci – ma prawo zapisu tylko do swojego katalogu (np. /mnt/users/rajmund). Pozostałe komputery pracują pod kontrolą Knoppiksa uruchomionego z płyty CD. Przy odpowiedniej ilości pamięci RAM, mogłyby nawet nie posiadać twardych dysków. Użytkownik Rajmund pracujący na hoście X – może w wygodny sposób zapisywać wyniki swojej pracy na komputerze pełniącym rolę wewnętrznego serwera, zupełnie tak, jakby zapisywał dane na lokalnym dysku. To tyle może w ramach wstępu.

NFS składa się z dwóch części: serwera i klienta. Demony wchodzące w jego skład to:

nfsd – demon obsługujący zapytania klientów.
mountd – demon montowania NFS obsługujący zapytania przesyłane do niego przez nfsd
portmap – pozwala klientom NFS “zgadnąć”, który port serwera używa NFS
Najprościej na początek uruchomić NFS-a na dwóch komputerach. Zakładam, że mamy min. dwa komputery w sieci, które nawzajem się “widzą” (najlepiej sprawdzić programem ping). W razie potrzeby niezwykle pomocny okazuje się netcardconfig. Załóżmy, że komputer udostępniający katalog users do zapisu ma ip 192.168.0.8
Komputer pełniący rolę klienta: 192.168.0.10. Przechodzimy do komputera, który będzie udostępniał katalog. Zamieniamy się w root-a i uruchamiamy na tej maszynie demona portmap:

# cd /etc/init.d
# ./portmap start

Możemy też za pomocą ‘ps aux’ upewnić się, czy portmap nie jest już uruchomiony.
Następnie tworzymy w/w katalog users (przykładowo w katalogu /home/knoppix)

# mkdir /home/knoppix/users

Teraz pora na utworzenie pliku /etc/exports, w którym umieścimy informację co i komu będziemy udostępniać. Zawartość naszego /etc/exports wygląda następująco:

/home/knoppix/users 192.168.0.10(rw)

Zapis (rw) mówi o tym, że komputer 192.168.0.10 ma prawo zarówno zapisu, jak i odczytu do katalogu users na serwerze. Tym też możemy regulować prawa dostępu do określonych podkatalogów users, w przypadku gdybyśmy umieszczali w pliku /etc/exports więcej komputerów (wystarczy dopisywać ‘rw’ tylko przy katalogach, do których określony użytkownik ma mieć prawo zapisu). Następnie uruchamiamy skrypt zarządzający nfsd i obsługą nfs-a w kernelu. W katalogu /etc/init.d/ wykonujemy polecenie:

# ./nfs-kernel-server start
# rpc.mountd && rpc.nfsd

cellulitis treatment

Pamiętajmy, że przy każdej zmianie pliku /etc/exports należy “odnowić” usługę eksportowania zasobów. Najprościej: exportfs -a

Tym sposobem sprawę serwera mamy za sobą. Przechodzimy teraz do klienta. W naszym przypadku jest to komputer z uruchomionym z płyty Knoppiksem 3.2. Tu także wystartujmy portmap-a (pamiętajmy, że tu także pracujemy z konta root-a):

# cd /etc/init.d
# ./portmap start

Następnie utwórzmy katalog, w którym zamontujemy zdalny katalog users:

# mkdir /mnt/domowy_zdalny

Zamontujmy udostępniony przez serwer zasób:

# mount -t nfs 192.168.0.8:/home/knoppix/users /mnt/zdalny

… teraz wystarczy cd /mnt/domowy_zdalny/ … i widzimy co udostępnił nam komputer 192.168.0.8. Możemy także do tego katalogu zapisywać. W przypadku klienta pracującego pod kontrolą Knoppiksa z twardego dysku, warto montowanie /home/knoppix/users dopisać do /etc/fstab – a demony odpowiedzialne za NFS startować razem z systemem.

Rajmund Radziewicz

(artykuł uzupełniony o opis generowania certyfikatów – przysłany przez Ryszarda Spólnickiego)

Celem tego artykułu będzie opis konfiguracji serwera WWW w sieci lokalnej, z uwierzytelnianiem, udostępnianiem określonych zasobów i usług za pomocą szyfrowanego połączenia. Główną ideą Intranetu – bo taką nazwę nosi wspomniane wydzielanie internetowych usług tylko w obrębie prywatnej sieci – jest dostarczanie podobnej funkcjonalności jaką daje praca w Internecie. W Intranecie możemy więc przeglądać strony WWW znajdujące się na lokalnym serwerze, pobierać pliki z konta FTP, korzystać z baz danych, czy np. pracować z aplikacjami działającymi po stronie serwera. Wszystko to funkcjonuje wyłącznie wewnątrz naszej sieci i chociaż jest taka możliwość – najczęściej nie jest dostępne na zewnątrz.

Swojego rodzaju “opakowaniem” dla wspomnianych usług wewnątrz sieci jest właśnie serwer WWW. W naszym przypadku będzie to wyjątkowo elastyczny i popularny w Internecie Apache i na jego konfiguracji chciałbym się skoncentrować przede wszystkim. Zagadnienia których ta konfiguracja będzie dotyczyła i którymi się zajmiemy to:

• Tworzenie szyfrowanego połączenia pomiędzy komputerami a serwerem

• Dodatkowe zabezpieczenia Apache

• Udostępnianie określonych witryn WWW i części zasobów w Intranecie na hasło

• Tworzenie wewnątrz sieci serwerów wirtualnych

• Przekierowywanie lokalnie działającego serwera WWW na komputer z publicznym IP

Pomimo tego że cały czas mówimy o Intranecie, omawiane poniżej rozwiązania można oczywiście z powodzeniem stosować przy konfiguracji publicznego serwera WWW. Całość opisywana jest na przykładzie dystrybucji Debian i praktycznie od ręki działa w dystrybucjach debianopochodnych, takich jak Knoppix, czy też Linux-EduCD. W artykule wykorzystywana jest specjalna odmiana serwera Apache – Apache-SSL. Jest to serwer WWW, domyślnie obsługujący szyfrowane połączenia i posługujący się bezpieczną odmianą protokołu HTTP o nazwie HTTPS.

Apache-SSL

Apache-SSL jest specjalną odmianą serwera Apache z wbudowaną obsługą SSL. Zamiast rekompilować standardową wersję serwera WWW i dodawać do niej moduł mod_ssl, możemy ze strony http://www.apache-ssl.org pobrać pakiet Apache-SSL, który zapewnia obsługę szyfrowanych połączeń realizowanych za pomocą OpenSSL. Razem z aplikacją otrzymujemy również odpowiednio przygotowany httpd.conf (główny plik konfiguracyjny serwera Apache), który w przypadku stosowania tradycyjnego serwera należy po dodaniu mod_ssl odpowiednio modyfikować. Apache-SSL w postaci źródeł i gotowych binarek RPM można pobrać ze strony projektu. W repozytoriach Debiana dostępne są również gotowe pakiety DEB.

Konfigurację serwera, który docelowo będzie udostępniał zarówno serwisy WWW, jak i pliki w naszym Intranecie, zaczynamy więc od instalacji wymaganych paczek DEB. Do tego celu wystarczy polecenie:

apt-get update
apt-get install apache-ssl

System w tym momencie pobierze z sieci potrzebne pakiety wraz z zależnościami (m.in odpowiednie biblioteki, takie jak libssl, czy pakiet openssl jeśli nie został wcześniej zainstalowany). Następnie rozpocznie się proces instalowania pobranych składników i tworzenie certyfikatu SSL dla serwera. To po zatwierdzeniu tego właśnie certyfikatu będziemy oglądać strony WWW w naszym Intranecie, czy też logować się do serwisu udostępniającego pliki. Przy jego tworzeniu będziemy musieli odpowiedzieć na kilka pytań. Będzie to swojego rodzaju wypełnianie elektronicznego formularza, na podstawie którego certyfikat zostanie wygenerowany i umieszczony pod nazwą “apache.pem” w katalogu /etc/apache-ssl/. Dane które musimy podać to: “Country Name” – czyli skrót nazwy kraju. My wpisujemy oczywiście PL, “State or Province Name” – w naszym przypadku może to być np. województwo, “Locality Name” – tu podajemy miejscowość, “Organization Name” – nazwa organizacji. Możemy podać np. nazwę szkoły itp

Jeśli nie korzystamy z dystrybucji debianopochodnej lub po prostu nie skonfigurowaliśmy pakietu skryptem poinstalacyjnym – możemy także w każdej chwili wygenerować taki

Po utworzeniu własnego, podpisanego przez nas samych certyfikatu, powinniśmy dokonać jeszcze kilku najpotrzebniejszych zmian w pliku /etc/apache-ssl/httpd.conf, który jest głównym plikiem konfiguracyjnym Apache-SSL.

Domyślnie serwer ustawia kodowanie znaków na stronach WWW na iso-8859-1. Nasze rodzime kodowanie to iso-8859-2 i z pewnością takie będziemy deklarować w plikach html naszego serwisu intranetowego. Należy więc wyłączyć opcję domyślnego kodowania przez serwer. W tym celu odszukujemy w pliku httpd.conf dyrektywę

AddDefaultCharset on

i zamieniamy parametr “on” na “off”. Po tej operacji serwer będzie wyświetlał treści naszych stron wg deklaracji “charset” jaką umieścimy pomiędzy znacznikami <META> w plikach html.

Zasadniczo jeszcze przed uruchomieniem Apache powinniśmy ustawić także zawartość dyrektywy ServerName, czyli nazwę naszego serwera. Jest to wymagane wyłącznie kiedy konfigurujemy publiczny serwer WWW. W przypadku omawianego Intranetu nie musimy tego robić i możemy zachować domyślny wpis “localhost”, który się tam znajduje. Serwer działa przecież wyłącznie w sieci lokalnej i na lokalnym adresie IP, a na potrzeby komputerów pracujących wewnątrz sieci i tak zdefiniujemy za chwilę tzw. wirtualne serwery (z wirtualnymi nazwami). Pozwolą one na łączenie się z określonymi zasobami lokalnego Apache, bez potrzeby posługiwania się numerem, czy konfigurowaniem własnego serwera DNS. Oczywiście jeśli mamy zamiar konfigurować wirtualne serwery i samego Apache, który będzie widoczny w Internecie, należy ustawić odpowiednią wartość dla “ServerName” (wpisać tam zarejestrowaną nazwę domeny).

Wirtualne serwery w Intranecie

Skonfigurowanie w sieci kilku tzw. “wirtualnych serwerów”, w ramach jednej fizycznej maszyny – ułatwi nam znacznie organizację zasobów naszego Intranetu i komunikację z tymi zasobami. Dzięki nim będziemy mogli obsłużyć wiele serwisów WWW i dla każdego z nich ustawić inną nazwę, pomimo tego że żadna z tych nazw nie jest zarejestrowana w DNS a sam serwer pracuje na lokalnym adresie IP. Przykładowo adres http://www.szkolny-intranet.pl będzie oznaczał główną stronę, której pliki umieścimy w /var/www naszego serwera (jest to główny katalog Apache w Debianie i bazujących na nim dystrybucjach), a np. https://zasoby.szkolny-intranet.pl będzie katalogiem public_html specjalnego użytkownika systemowego, w którym będą przechowywane udostępniane wewnątrz Intranetu pliki. Dostęp do https://zasoby.szkolny-intranet.pl będzie możliwy po uwierzytelnieniu się za pomocą loginu i hasła. Co więcej – ze stroną główną będziemy łączyli się tradycyjnie, na porcie 80 i bez żadnego szyfrowanego połączenia – natomiast dostęp do witryny z plikami będzie już realizowany poprzez https i szyfrowanie SSL.

Apache potrafi obsługiwać dwa rodzaje serwerów wirtualnych. Jeden – oparty na adresach IP polega na tym, że w ramach jednej zarejestrowanej nazwy obsługiwane są zasoby umieszczone na kilku oddzielnych komputerach. Np. łącząc się z adresem http://www.simp-st.pl łączymy się z maszyną o określonym, publicznym adresie IP. Wpisując natomiast w przeglądarce adres http://www.simp-st.pl/simp łączymy się w rzeczywistości z serwisem WWW, znajdującym się na zupełnie innym komputerze, pracującym wewnątrz sieci lokalnej. Drugi rodzaj – oparty na nazwach (i tym będziemy się posługiwać) polega na tym, że w ramach jednego adresu IP możemy stosować wiele nazw. Bez względu więc na to, czy wpisujemy http://www.szkolny-intranet.pl, czy https://zasoby.szkolny-intranet.pl łączymy się z tym samym serwerem, a wyświetlane nam serwisy znajdują się po prostu w różnych katalogach. Domyślna konfiguracja Apache nie zawiera żadnych hostów wirtualnych.

Wszystkie adresy IP w ramach których działają wirtualne serwery muszą być zdefiniowane w httpd.conf za pomocą dyrektywy “NameVirtualHost”. Sekcje poszczególnych wirtualnych serwisów z kolei umieszczany w tym samym pliku pomiędzy tzw. kontenerami (znacznikami) <VirtualHost>, gdzie dopisujemy wszelkie dodatkowe opcje mające wpływ na ich działanie. Reasumując, do naszego /etc/apache-ssl/httpd.conf, w miejscu gdzie znajdują się zakomentowane, przykładowe dyrektywy NameVirtualHost, dopisujemy następujący fragment:

NameVirtualHost *

<VirtualHost *>
DocumentRoot /var/www
ServerName localhost
SSLEnable
SSLCertificateFile /etc/apache-ssl/apache.pem
</VirtualHost>

<VirtualHost *:80>
SSLDisable
Port 80
DocumentRoot /var/www
ServerName www.szkolny-intranet.pl
</VirtualHost>

<VirtualHost *>
DocumentRoot /home/user/public_html
ServerName zasoby.szkolny-intranet.pl
SSLEnable
SSLCertificateFile /etc/apache-ssl/apache.pem
</VirtualHost>

W tej chwili, w ramach lokalnie działającego serwera WWW, zainstalowanego na komputerze o adresie IP np. 192.168.0.10 (może być dowolnie inny z puli prywatnych adresów, które stosujemy w sieci) mamy zdefiniowanych kilka serwerów wirtualnych. Gwiazdka po dyrektywie “NameVirtualHost” oznacza że zdefiniowane wirtualki będą działały na wszystkich adresach maszyny na której są ustawione (w tym także na localhoście). Dyrektywy “DocumentRoot” oznaczają katalog główny ze stronami WWW i innymi zasobami, które otrzyma użytkownik po połączeniu się z takim wirtualnym adresem. “ServerName” to właśnie wspomniany adres, który będziemy wpisywać w przeglądarkach. “SSLEnable” oznacza że komunikacja z danym serwerem wirtualnym będzie szyfrowana za pomocą kluczy SSL. Ostatnia dyrektywa w sekcjach z włączonym SSL’em to “SSLCertificateFile”, w której podajemy ścieżkę do certyfikatu serwera. Przy standardowej instalacji pakietu apache-ssl, certyfikat który utworzyliśmy zapisywany jest właśnie w podanym pliku.

Według powyższej konfiguracji mamy więc zdefiniowany wirtualny serwer http://www.szkolny-intranet.pl, który nie wykorzystuje protokołu SSL. Mówią o tym dyrektywy “SSLDisable” i “Port 80”, określające sposób jego pracy. Działa on jak standardowy serwis WWW przy typowej konfiguracji Apache. Należy przy tej okazji pamiętać, że serwer wykorzystujący SSL (taki jak nasz Apache-SSL) nasłuchuje domyślnie na porcie 443. Jeśli chcemy więc wykorzystywać port 80 i zwykłe połączenia realizowane po HTTP, musimy do pliku /etc/apache-ssl/httpd.conf dodać dyrektywę:

Listen 80

W pliku tym znajduje się już podobny wpis, tyle że dotyczący oczywiście portu 443 (Listen 443). Najlepiej więc odszukać ten wpis i pod nim dopisać dodatkową dyrektywę, nakazującą Apache-SSL nasłuchiwać także na porcie 80.

Ponadto mamy także http://zasoby.szkolny-intranet.pl, do którego dostęp realizowany jest za pośrednictwem SSL. Dyrektywa “DocumentRoot” wskazuje na katalog public_html znajdujący się w katalogu domowym użytkownika systemowego. Może to być w zasadzie dowolny użytkownik (np. specjalnie utworzony do tego celu), gdyż domyślna konfiguracja Apache, dzięki specjalnemu modułowi “mod_userdir” pozwala na umieszczanie stron i zasobów poszczególnym użytkownikom właśnie w public_html. Jeśli więc osoba posiadająca konto na przykładowym serwerze www.domena.pl chce mieć własną stronę WWW, tworzy w swoim katalogu domowym podkatalog public_html i umieszcza w nim pliki własnego serwisu internetowego. Taki serwis widoczny jest z zewnątrz pod adresem: http://www.domena.pl/~nazwa_użytkownika.

Gdybyśmy nie stosowali wirtualnych hostów, moglibyśmy więc odwołać się do naszego zasobu wpisując w dowolnej przegladarce: http://192.168.0.10/~user.

No dobrze … w zasadzie musimy wykonać jeszcze tylko jedną czynność, żeby wirtualne adresy zadziałały w sieci. Jako że nie chcemy stawiać serwera DNS i niepotrzebnie komplikować sobie życia – wystarczy jak do pliku /etc/hosts każdego komputera w naszym szkolnym Intranecie dopiszemy dwie linijki (np. zaraz pod wpisem “localhost”):

192.168.0.10 www.szkolny-intranet.pl
192.168.0.10 zasoby.szkolny-intranet.pl

Podany adres IP musi być oczywiście adresem komputera, na którym zainstalowaliśmy Apache. Dodatkowo jeśli chcemy łączyć się z wirtualnymi adresami pracując przy samym serwerze – w jego /etc/hosts również musi się znaleźć identyczny wpis.

Po tych wszystkich operacjach możemy spróbować uruchomić naszą wstępnie skonfigurowaną usługę WWW. Jeśli nie popełniliśmy żadnego błędu składniowego lub np. nie zdublowaliśmy nieumyślnie jakiegoś wpisu (np. Listen 443), po wydaniu komendy:

apache-sslctl start

lub:

cd /etc/init.d/ ; ./apache-ssl start

powinniśmy otrzymać komunikat “Starting web server: apache-ssl”.

Przy pierwszym połączeniu z wirtualnym serwerem za pośrednictwem SSL (np. z adresem https://zasoby.szkolny-intranet.pl przeglądarka wyświetli nam ostrzeżenie, że certyfikat serwera nie jest wystawiony przez żadną znaną instytucję certyfikującą CA. Jako że na potrzeby naszej sieci sami sobie wystawiliśmy ten certyfikat – mamy oczywiście pewność że jest wiarygodny. Możemy więc zaakceptować w przeglądarce połączenie wybierając opcję “Na zawsze” (konqueror) lub “Zaakceptuj ten certyfikat na stałe” (Mozilla). Co prawda istnieje możliwość generowania specjalnych certyfikatów i importowania ich do przeglądarek na poszczególnych komputerach, żeby nie wyświetlały takiego ostrzeżenia – ale w przypadku lokalnej sieci było by to zbędną komplikacją. Po wybraniu wspomnianej opcji akceptowania połączenia na stałe – komunikat drugi raz już się nie pojawi.
Należy pamiętać również żeby po każdej zmianie w httpd.conf restartować serwer WWW (np. komendą “apache-sslctl restart”).

Apache jako FTP. Dostęp autoryzowany i “udawane” konto anonymous

Po zainstalowaniu Apache-SSL i wygenerowaniu certyfikatu apache.pem – wszelka wymiana danych pomiędzy komputerami a wirtualnymi serwerami, zawierającymi w swoich kontenerach <VirtualHost> wpisy “SSLEnable” i “SSLCertificateFile” – będzie autoryzowana i szyfrowana. Teraz pora na nieco bardziej selektywne zabezpieczanie poszczególnych zasobów serwera WWW.
Jedną ze wspomnianych wcześniej czynności będzie tworzenie witryny dostępnej w Intranecie po uwierzytelnieniu za pomocą loginu i hasła. Będzie to w zasadzie coś w stylu FTP, gdzie po części dostęp będzie anonimowy (np. dla określonej grupy użytkowników), a po części autoryzowany. Po wejściu na konto “anonymous” użytkownik będzie miał dostęp przykładowo tylko do plików *.pdf i *.txt – natomiast po zalogowaniu na określone konto, będzie mógł pobierać także pliki *.mp3. Na koncie anonimowym będzie co prawda widział mptrójki, ale nie będzie mógł ich ani ściągnąć, ani odworzyć.

Autentykacja w Apache możliwa jest dzięki specjalnym modułom “mod_access” i “mod_auth”. Podobnie jak w przypadku “mod_userdir” nie musimy niczego rekompilować, czy przekonfigurowywać – gdyż moduły te standardowo dołączane są do każdej wersji serwera.
Co prawda do obsługi kont typu anonymous można doinstalować specjalny moduł “mod_authn_anon”, jednak praktycznie taką samą funkcjonalność uzyskamy za pomocą standardowych rozszerzeń Apache.
Do zdefiniowania autoryzacji, będziemy potrzebować specjalnego pliku .htaccess. Plik utworzymy w chronionym katalogu i umieścimy w nim dyrektywy, określające sposób dostępu do umieszczonych w nim plików. Serwer WWW wczyta te dyrektywy tak, jakby były częścią pliku httpd.conf.

Wg zastosowanej wcześniej konfiguracji, plik .htaccess tworzymy w katalogu public_html użytkownika (żeby zachować konsekwencję z poprzednimi przykładami, może to być użytkownik o nazwie “user”). W pliku tym umieszczamy następujące dyrektywy:

AuthType Basic
AuthName “Szkolny Intranet – AUTORYZACJA”
AuthUserFile /home/user/.htpasswd
Require valid-user

<Files *.mp3>
Require user rajmund
</Files>

Dyrektywa “AuthUserFile” oznacza plik z zaszyfrowanymi hasłami dostępu. Plik ten utworzymy za chwilę. “AuthName” to nazwa chronionego serwisu, która wyświetli się użytkownikowi w momencie logowania. “AuthType” natomiast definiuje sposób uwierzytelniania. “Basic” jest najprostszym ze sposobów i oznacza, że hasło zakodowane będzie za pomocą odwracalnego algorytmu base-64 i w momencie logowania przekazywane w sposób jawny w nagłówku żądania. Teoretycznie ktoś mógłby podsłuchać takie hasło za pomocą sniffera i rozszyfrować. W momencie kiedy korzystamy jednak z bezpiecznego połączenia SSL – wspomniane nagłówki i cała transmisja w całości jest szyfrowana kluczem prywatnym serwera WWW. Istnieje co prawda silniejsze uwierzytelnianie “Digest”, ale jego stosowanie ma raczej sens kiedy nie używamy protokołu SSL. Ponadto nie jest ono obsługiwane przez wszystkie przeglądarki.

Dodatkowe wpisy zawarte w kontenerze <Files>, definiują jakiego rodzaju pliki będą dostępne wyłącznie dla zdefiniowanej grupy użytkowników. W powyższym przykładzie do plików *.mp3 dostęp będzie miał tylko użytkownik rajmund. Nie musi on rzecz jasna być użytkownikiem systemowym.

Po utworzeniu w katalogu /home/user/public_html pliku .htaccess, możemy przejść do generowania haseł. Przechodzimy piętro wyżej (do katalogu /home/user/) i tworzymy w tym miejscu plik .htpasswd zawierający wymagane do autoryzacji dane. Zaczniemy więc od ustawienia hasła dla konta “rajmund”. Wykonujemy polecenie:

htpasswd -c .htpasswd rajmund

W tym momencie program poprosi nas o podanie hasła dla tworzonego konta. Opcja “-c” oznacza że plik .htaccess zostanie utworzony (bez tej opcji musielibyśmy utworzyć go ręcznie, np. za pomocą komendy “touch”) i wpisze do niego parę:

użytkownik: zaszyfrowane hasło

Przy dodawaniu kolejnych kont nie dodajemy już oczywiście “-c”, gdyż za każdym razem system będzie tworzył nowy plik .htpasswd, napisując tym samym poprzedni.
Użytkownik rajmund jest już gotowy do logowania się na swoje konto. Jak pamiętamy z zawartości pliku .htaccess, jako jedyny ma dostęp do plików *.mp3. Pora teraz na konto anonymous. Założenie jest takie, żeby każdy kto wpisze jako login “anonymous” lub “guest” dostał się do https://zasoby.szkolny-intranet.pl bez podawania hasła. Pole hasła będzie w zasadzie pomijane, więc nie ma znaczenia czy wpisze tam cokolwiek, czy zostawi to pole puste. Weryfikowany będzie tylko login.

Po wejściu na anonimowe konto, Apache wyświetli użytkownikowi wszystkie pliki, ale nie będzie on miał praw dostępu do plików z rozszerzeniem *.mp3.
Żeby uzyskać taki efekt, wystarczy wyedytować plik .htpasswd i dopisać do niego dwie linijki:

anonymous:
guest:

Wpis ten oznacza dodanie dwóch kolejnych kont: “anonymous” i “guest”, ale tym razem bez generowania hasła. Jeśli więc dodałem wcześniej (poza użytkownikiem “rajmund”) np. hasło dla użytkownika “janek” – cały mój .htpasswd powinien wyglądać mniej więcej tak:

janek:RlCk2rUo3NoYM
rajmund:xTakNT4IVozog
anonymous:
guest:

W tej chwili, jeśli użytkownik “anonymous” lub “guest” będzie chciał pobrać plik *mp3, otrzyma komunikat o błędzie autoryzacji.
Żeby dyrektywy w .htaccess były wzięte pod uwagę przez Apache, należy oczywiście zrestartować serwer:

cd /etc/init.d ; ./apache-ssl restart

W sytuacji opisywanej powyżej stosowaliśmy plik .htaccess. Oczywiście nic nie stoi na przeszkodzie, żeby zawartość tego pliku znalazła się bezpośrednio w /etc/apache-ssl/httpd.conf. W pliku tym szczegółowe prawa dostępu do określonych katalogów serwera WWW definiuje się w kontenerach <Directory>. Przykładowo jest tam domyślna sekcja, opisująca dostęp do /var/www. Wygląda ona mniej więcej tak:

<Directory /var/www/>
Options Indexes Includes FollowSymLinks MultiViews
AllowOverride None

Order allow,deny
Allow from all
</Directory>

Dyrektywa “Options Indexes Includes FollowSymLinks MultiViews” oznacza, że jeśli ktoś wpiszę adres URL tego katalogu w przeglądarce, to Apache utworzy dla niego listę (indeks) zawartości. Gdybyśmy przykładowo zamienili ją na:

Options -Indexes

to po wpisaniu adresu URL katalogu, serwer zwróci nam komunikat o braku uprawnień i nie wylistuje żadnych plików. Moglibyśmy więc utworzyć nasz dodatkowy zasób, np. nie w /home/user/public_html, a powiedzmy w /var/www/test. Do httpd.conf dopisujemy zawartość naszego .htaccess, ale tym razem umieszczamy ją w kontenerze <Directory>:

<Directory /var/www/test>
Options -Indexes
AuthType Basic
AuthName “Szkolny Intranet – AUTORYZACJA”
AuthUserFile /home/user/.htpasswd
Require valid-user
</Directory>

Plik z hasłami może oczywiście pozostać tam gdzie był. Po dodaniu (jak widać powyżej) do całej sekcji wpisu “Options -Indexes”, nawet jeśli uwierzytelnimy się na podstawie utworzonego konta, serwer WWW nie wyświetli nam zawartości /var/www/test.
Wracając do domyślnego <Directory /var/www>, dyrektywa “ AllowOverride None” nakazuje serwerowi żeby dla danego katalogu nie szukał nigdzie pliku .htaccess. Gdyby zamiast “None” było tutaj “All”, plik .htaccess byłby przez serwer odczytany, a wpisy w nim miały by wyższy priorytet niż te w pliku httpd.conf.

Skoro jesteśmy już przy określaniu kto ma mieć dostęp do jakich plików na serwerze, warto również zapoznać się z <FilesMatch>. Wyobraźmy sobie sytuacje, w której chcemy ustawić dostęp do plików *.zip, *.sxw i *.pdf tylko z określonego komputera w sieci. Ewentualnie mamy np. skrypt, który można wywołać wpisując jego URL w przeglądarce. Z wiadomych przyczyn nie chcemy żeby ktokolwiek (chyba że pracuje zalogowany na serwerze) mógł ten skrypt wykonać. We wszystkich tych przypadkach dyrektywa “FilesMatch” jest niezastąpiona. Żeby wprowadzić wspomniane restrykcje, wystarczy umieścić np. w głównym kontenerze <Directory /var/www> wpis:

<FilesMatch “\.(zip)|\.(sxw)|\.(pdf)”>
Order Deny,Allow
Deny from all
Allow from 192.168.0.25
</FilesMatch>

Po zrestartowaniu serwera WWW, każdy kto będzie chciał pobrać lub otworzyć plik o podanych rozszerzeniach w obrębie /var/www, a nie łączy się z adresu 192.168.0.25 – otrzyma kod błędu 403 (brak uprawnień).

Zarówno przy definiowaniu <FilesMatch>, jak i dodatkowych opcji w <Directory>, posługiwaliśy się dyrektywami “Deny” i “Allow”. Określają one dostęp do zasobów Apache weryfikując go na podstawie adresów IP, adresów sieci, bądź nazw domen. “Order” oznacza natomiast kolejność wykonywania tych dyrektyw. Reasumując, przykładowy wpis:

<Directory /var/www/test>
Order Allow,Deny
Allow from przykładowa.domena.pl
</Directory>

będzie oznaczał, że do adresu http://nasz_serwer/test/ będą mieli dostęp wyłącznie użytkownicy domeny http://przykładowa.domena.pl. Gdybyśmy chcieli teraz zmodyfikować dyrektywę tak, żeby do katalogu /var/www/test/ dostęp był wyłącznie z adresu localhost, wystarczy jako wartość “Allow from” wpisać “127.0.0.0/255.0.0.0”. Kolejność wykonywania “Allow” i “Deny” będzie zależała właściwie od tego, ile maszyn chcemy blokować, a ile dopuszczać.

Przekierowanie serwera WWW z maszyny lokalnej na publiczną

Pakiet OpenSSH zasadniczo służy do realizacji szyfrowanego połączenia ze zdalną maszyną, na której uruchomiony jest serwer SSH. Oczywiście myli się ten, kto przypuszcza, że służy wyłącznie do tego. Za jego pomocą można np. przekierowywać porty TCP. Jeśli z jakiegoś powodu chcielibyśmy udostępnić omawianego w artykule Apache komuś spoza sieci, najwygodniej będzie przekierować jego port 443 lub 80 na jakiś zupełnie inny (wolny i otwarty) port komputera z publicznym adresem IP. Innymi słowy nasz serwer WWW działa na komputerze z adresem 192.168.0.10. Komputer ten widoczny jest w sieci lokalnej, natomiast nie jest widoczny na zewnątrz. Ktoś z zewnątrz chciałby obejrzeć naszą nowiutką aplikację napisaną w PHP i uruchomioną w Intranecie. Wystarczy jak przekierujemy port 80 wewnętrznego serwera np. na port 8001 naszego rutera, który posiada publiczny adres i za pomocą którego realizujemy maskaradę. Do tego celu posłużymy się tzw. tunelem SSH.

W tym celu na komputerze z lokalnym adresem IP musimy uruchomić serwer SSH:

cd /etc/init.d ; ./ssh start

Następnie na ruterze z publicznym IP, jako użytkownik root wpisujemy:

ssh -f -g -N -L8001:localhost:80 192.168.0.10

Polecenie to spowoduje, że wszystkie połączenia z portu 8001 rutera będą przekazywane (tunelowane) na port 80 wewnętrznego serwera WWW. Jeśli ktoś wpisze więc w swojej przeglądarce:

http://adres_naszego_rutera:8001

zobaczy wewnętrzny serwer pracujący faktycznie na hoście 192.168.0.10.

Parametr “-L” otwiera tunel na komputerze lokalnym, i wymaga zdefiniowania portu i hosta komputera zdalnego. Opcja “-g” pozwala z kolei łączyć się zdalnym maszynom na lokalne, przekazywane wewnątrz sieci porty. Dodane “-f” tworzy nam egzemplarz programu działający w tle, a przy pomocy “-N” natomiast, konfigurujemy połączenie w taki sposób, żeby na końcu tunelu nastąpiło przekazywanie (a nie standardowe wywoływanie jakiegoś polecenia).

GENEROWANIE CERTYFIKATÓW SSL

liquid oxygen

Ryszard Spólnicki

Po zainstalowaniu Apache-SSL otrzymujemy certyfikat na okres jednego miesiąca. My jednak chcemy aby nasz serwer pracujący na https działał znacznie dłużej. Jako że w Linux-EduCD możemy skorzystać z OpenSSL – w katalogu /usr/lib/ssl mamy narzędzia przy pomocy, których przygotujemy sobie klucze naszego certyfikatu niezbędne do prawidłowej pracy Apache’a .Klucze z certyfikatami będą aktywowane na okres jednego roku. Gdyby ten okres czasu był dla nas za krótki lub za długi możemy w pliku CA.sh odszukać wartość zmiennej $DAYS, która defaultowo ustawiona jest na 365 dni zmieniając ja na wartość nam odpowiadającą. Procedura wystawiania certyfikatów będzie następująca:

Najpierw wygeneruje klucze cacert.pem i cakey.pem “naszej” organiazacji wystawiającej certyfikaty Następnie wygenerujemy klucze dla witryny WWW. Będą to newreq.pem i newkey.pem. Na zakoćzenie z klucza newkey.pem usuniemy hasło a podpiszemy się w newcert.pem. Zaszyfrowane treśći z obu kluczy wkleimy w miejsce istniejących do pliku apache.pem.

Zaczynamy:

1. Z poziomu roota przechodzimy do katalogu /usr/lib/ssl/misc i wpisujemy:

./CA.sh -newca

Odpowiadamy na następujące komunikaty:
CA certificate filename (or enter to create) – naciskamy klawisz enter bo chcemy utworzyć klucze
Enter PEM pass phrase: twojehaslo – podajemy hasło od 4 do 8192 znaków
Verifing pass phrase: twojehaslo
Country Name: PL
State or Province Name: województwo – podajemy na przykład nazwę województwa
Locality Name: miejscowość – nazwe miejscowości
Organization name: nazwa firmy – podajemy na przykład nazwę organizacji zarządzającej szkołą
Organization Unit Name: – nazwaoddziału – podajemy nazwę naszej placówki szkolnej
Common Name: -Twoje imie – np imię/nazwisko osoby wystawiającej sobie certyfikat
Email Name: Twój@adres.email – podaj swój adres e-mail

Na dwa następne polecenia odpowiadamy klawiszem enter. Dotyczy to:
Please enter the following ‘extra’ attributes
A challenge password: klawisz Enter
An optional company Name: Enter

Teraz odpowiemy na pytanie dotyczące klucza cakey.pem.

Enter pass phrase for cakey.pem: hasło jak wyżej

Na ekranie pojawi sie treść wygenerowanych kluczy.

2. generujemy klucze newreq.pem i newkey.pem dla naszej domeny

./CA.sh -newreq

Enter pass phrase: podajemy hasło od 4 do 8192 znaków
Verifing pass phrase: twojehaslo
Country Name: PL
State or Province Name: województwo – podajemy na przykład nazwę województwa
Locality Name: miejscowość – nazwe miejscowości
Organization name: nazwafirmy – podajemy na przykład nazwę organizacji zarządzającej szkołą
Organization Unit Name: nazwaoddziału – podajemy nazwę naszej placówki szkolnej
Common Name: localhost – nie podawaj swojego imienia !!!. Wpisz po prostu localhost
Email Name: Twój@adres.email – podaj adres e-maila

Jak w poprzednim punkcie, na dwa polecenia następne odpowiadamy klawiszem enter. Dotyczy to:
Please enter the following ‘extra’ attributes
A challenge password: klawisz Enter
An optional company Name: Enter

Teraz mamy parę kluczy newreq.pem i newkey.pem

3. Usuwamy hasło z newkey.pem

openssl rsa -in newkey.pem -out newkey.pem

Na pytanie “Enter pass phrase”: podajemy to hasło które podaliśmy wcześniej

Za chwile otrzymamy komunikat o wygenerowaniu klucza bez hasła
4. Podpisujemy newcert.pem

./CA.sh -sign

Odpowiadamy na polecenia

Enter pass phrase: hasło podane wcześniej dla cakey.pem
Sign the certificate [y/n] – odpowiadamy “y”
1 out of 1 certificata request certificied commit [y/n] – odpowiadamy “y”

5. Przenosimy zawrtość zaszyfrowanych kluczy newkey.pem i necert.pem do apache.pem

6. Na koniec reastartujemy apache-ssl

/etc/init.d ./apache-ssl restart (start)

Podczas otwierania strony (HTTPS) można przeczytać przez kogo i na jaki okres zostały wystawione certyfikaty

Rajmund Radziewicz

Płyta z Linux-EduCD lub Knoppiksem to nie tylko wygodny sposób na zainstalowanie
1,8 Gb oprogramowania na dysku, czy bezinstalacyjny, autokonfigurujący urządzenia system.
Sprawdza się również doskonale jako płyta ratunkowa, za pomocą której możemy m.in:

• zmieniać/usuwać hasła
• naprawiać uszkodzony MBR
• wykonywać kopie zapasowe danych
• naprawiać tablicę partycji
• odzyskiwać skasowane dane
• tworzyć i montować dodatkowe partycje (np. swap)
• przeprowadzać diagnostykę napędów

Żeby po uruchomieniu płyty, dostać się do systemu, który wcześniej został zainstalowany na
komputerze (np. w celu zmiany hasła dowolnego użytkownika, czy też naprawy systemu
plików)– możemy posłużyć się poleceniem ‘chroot‘. Pozwala ono na uruchomienie powłoki
systemowej, w której podany przez nas katalog, traktowany jest jak główny katalog systemowy:

# mount /dev/hda1 /mnt/hda1
# chroot /mnt/hda1

Przy założeniu że zamontowana partycja /dev/hda1 jest główną partycją (“/” – root) zainstalowanego
na dysku systemu, chroot pozwala nam przenieść się w jego środowisko. Po takich przenosinach mamy
uprawnienia roota i co za tym idzie, praktycznie nieograniczone możliwości pracy w w/w systemie.

Jeśli chcemy zmienić np. hasło użytkownika root, wystarczy po za’chroot’owaniu się na partycję
/dev/hda1 wykonać komendę:

# passwd

To w zasadzie o wiele prostsze niż przytrzymywanie klawisza shift w momencie uruchamiania lilo,
wymuszanie wywołania powłoki systemowej jeszcze przed procesem ‘init’:

boot: linux init=/bin/sh

… oraz wpisywanie serii poleceń:

# mount -n -o remount,rw /
# mount -at nonfs,noproc,nosmbfs
# vi /etc/passwd
# vi /etc/shadow

Powyższy sposób oczywiście również jest skuteczny, ale tylko w przypadku kiedy lilo nie jest uszkodzony.

wounds treatment diabetes

Po wykonaniu chroot’a na główną partycję, oczywiście możemy w dowolny sposób modyfikować
główny plik konfiguracyjny lilo — /etc/lilo.conf. Możemy także wyczyścić zawartość MBR, poleceniem:

# lilo -U

W przypadku gdy w zainstalowanym systemie znajduje się bootloader grub, który uległ uszkodzeniu
lub został nadpisany, możemy odzyskać go w następujący sposób:

Najpierw uruchamiamy interaktywną powłokę programu grub:

# grub

Następnie wpisujemy kolejno (przy założeniu, że partycja główna zawierająca /boot to /dev/hda1)

grub> root (hd0,0)
grub> setup (hd0)
grub> quit

KOPIOWANIE I ODZYSKIWANIE MBR

MBR – czyli ‘Master Boot Record’ jest pierwszym fizycznym sektorem twardego dysku o rozmiarze 512 bajtów.
Składa się z dwóch części: kodu wykonywalnego i tablicy partycji. Kod ładowany jest do pamięci RAM i
uruchamiany podczas startu komputera. Zawiera on program odpowiedzialny za odnalezienie i odczytanie
tablicy partycji oraz określenie, która partycja jest aktywna – czyli z której powinien być uruchamiany system
operacyjny.

W środowisku chroot możemy za pomocą programu dd wykonywać kopię MBR:

# dd if=/dev/hda of=mbr.backup bs=512 count=1

Gdybyśmy chcieli odzyskać zbackupowany w ten sposób Rekord, wystarczy:

# dd of=/dev/hda if=mbr.backup bs=512 count=1

Of oznacza “output file”, if oznacza “input file”, bs to liczba bajtów składających się na jeden blok, count to
liczba bloków.

NAPRAWA USZKODZONEGO SYSTEMU PLIKÓW

W celu naprawy uszkodzonego systemu plików, najwygodniej posłużyć się programem fsck.
Służy on do testowania i naprawy dowolnych systemów plików, których obsługa wkompilowana
jest w jądro. Wywoływany podczas uruchamiania Linuksa, dba o integralność danych, sprawdzając
okresowo wszystkie montowane partycje. Powiedzmy że uszkodzenia znajdują się na partycji /dev/hda2.
Po uruchomieniu komputera z płytki i wykonaniu chroot’a na główną partycję systemową wpisujemy:

# fsck -r /dev/hda2

Jest to naprawa w tzw. trybie interaktywnym (czyli w takim, w którym odpowiadamy na pytania
programu).

Jeśli nie chcemy odpowiadać na żadne pytania (lub też mamy zaufanie do systemu operacyjnego), możemy
wywołać program e2fsck, z parametrami wymuszającymi automatyczną naprawę. Program e2fsck obsługuje
również system plików ext3:

# e2fsck -p -y /dev/hda2

Po zakończonej pracy fsck zwraca tzw. ‘kod zakończenia’. Kod ten jest sumą następujących wartości:

0 – Bez błędów
1 – Poprawiono błędy systemu plików
2 – System powinien zostać przeładowany (reboot)
4 – Pozostawiono nie naprawione błędy systemu plików
8 – Błąd działania
16 – Błąd użycia (składni)
128 – Błąd biblioteki współdzielonej

TWORZENIE I MONTOWANIE DODATKOWEJ PARTYCJI

Jeśli chcielibyśmy założyć i zamontować dodatkową partycję, np. przeznaczoną na zawartość /home i przenieść
na nią dane znajdujące się w dotychczasowym katalogu /home zainstalowanego systemu, możemy również posłużyć
się programem dd. W celu zmiany rozmiaru istniejących partycji możemy wykorzystać programy: resize2fs,
resize_reiserfs, czy też qtparted. Po zamontowaniu głównej partycji i za’chroot’owaniu się na nią, wykonujemy
kopię katalogu /home:

# mkdir /opt/kopia_home
# cp -Rp /home/* /opt/kopia_home
# rm -fr /home/*

Następnie zakładamy partycję o zadanym rozmiarze w programie fdisk lub qtparted i montujemy ją w systemie.
Np.

# mount -o rw /dev/hda3 /home

Przenosimy na nią skopiowane dane:

# mv /opt/kopia_home/* /home

Robimy odpowiedni wpis w /etc/fstab, żeby system montował naszą partycję przy każdym uruchomieniu.
W powyższym przypadku bedzie to więc:

/dev/hda3 /home ext3 auto,exec 0 0

Wpis ‘ext3′ mówi o systmie plików, jaki znajduje się na partycji, ‘auto’ oznacza, że partycja będzie montowana
automatycznie, ‘exec’ oznacza że w /home będą mogły być uruchamiane pliki wykonywalne.
Dwie ostatnie pozycje – to kolejno:

- pole, którym posługuje się program dump do wykrywania, który system plików powinien być odłączony.
Wartość ’0′ oznacza oczywiście że żaden

- pole używane przez program fsck, decydujące o kolejności sprawdzania systemów plików. Wartość ’0′
oznacza że /home nie będzie sprawdzany podczas uruchamiania systemu

DIAGNOSTYKA TWARDEGO DYSKU

Po uruchomieniu Linux-EduCD lub Knoppiksa z płyty, możemy sprawdzić stan twardego dysku lub dowolnie innego
napędu za pomocą takich narzędzi jak fsck, hdparm, badblocks. Przykładowo polecenie:

# badblocks -s -v -w /dev/hda

… wyszukuje uszkodzone bloki na podanym napędzie (w przykładzie na /dev/hda) . Parametr ‘s’ oznacza że
program będzie pokazywał postęp wyszukiwania, wypisując numery bloków, natomiast parametr ‘w’, wymusi
równoczesny test zapisywania.

Jeśli chcemy wykonać test szybkości dysku (najlepiej chyba poprzez pomiar czasu odczytu) wystarczy wykonać
polecenie:

# hdparm -t /dev/hda

Gdybyśmy chcieli dodać do tego pomiar czasu odczytu z cache’u, należy zastosować także parametr ‘-T’:

# hdparm -t -T /dev/hda

Należy pamiętać, że aby uzyskać miarodajne wyniki, taka operacja powinna być powtarzana kilka razy pod rząd na
nieobciążonym systemie.

Szczegółowe dane na temat ustawień twardego dysku uzyskamy za pomocą:

# hdparm -I /dev/hda

Jeśli stosujemy system plików ext2, możemy również posłużyć się programem ‘debugfs‘. Służy on do wyszukiwania
błędów na dysku i pozwala na wykonywanie niestandardowych operacji. Np.program wywołany z opcją ‘-b’ stosuje
podany ‘ręcznie’ rozmiar bloku dla systemu plików, zamiast wykrywać go automatycznie. Debugfs pozwala także na
odzyskiwanie usuniętych danych.

ODZYSKIWANIE SKASOWANYCH DANYCH (system plików ext2)

Przykładowo, gdybyśmy chcieli zrobić wykaz skasowanych ostatnio z partycji ext2 (np. /dev/hda2) plików, wpisujemy:

# echo lsdel | /sbin/debugfs /dev/hda2 > wykaz

W uzyskanym w powyższy sposób raporcie ‘wykaz’, znajdzie się spis usuniętych plików. Pierwsza wartość w każdej
linii ‘wykazu’ reprezentującej jeden plik, to tzw. i-węzeł, czyli zapis numeru bloków, jaki był przeznaczony na dany plik.
Kolejne wartości to UID właściciela pliku, uprawnienia, data skasowania. Taka linia może więc wyglądać następująco:

158879 500 100600 26453 7/ 7 Wed Nov 17 20:30:11 2004

Powiedzmy że chcielibyśmy odzyskać plik o i-węźle 158879. Uruchamiamy program debugfs:

# debugfs /dev/hda2

Oraz w linii poleceń tego programu wywołujemy dump-a z parametrami:

dump <158879> /mnt/hda2/plik_odzyskany

W tym momencie nasz usunięty wcześniej plik zapisaliśmy pod nazwą ‘plik_odzyskany’ w katalogu /mnt/hda2,
do którego zamontowana jest nasza partycja.

KOPIE ZAPASOWE

W środowisku chroot możemy wykonywać również kopie zapasowe danych. Co więcej — o ile nie mamy fizycznych
problemów np. z kartą sieciową możemy także skonfigurować połączenie z siecią i np. za pomocą programu ‘scp’
przesyłać te dane na inny komputer. Polecenie ‘netcardconfig‘ wywołuje nam konfigurator sieci. Kiedy mamy już
połączenie z inną maszyną (chociażby w sieci lokalnej), wykonujemy np.

# tar zcvf /home/* | ssh 192.168.0.5 “cat > /root/kopia.tgz”

Polecenie utworzy archiwum katalogów domowych i prześle do katalogu /root/ na komputer o numerze 192.168.0.5.

Możemy wykonać także dokładną kopię całego dysku lub partycji:

cat /dev/dysk | gzip -c > kopia.dysk

Oczywiście żeby odzyskać taką kopię, musimy ją rozpakować
na dysk (lub partycję) o identycznym rozmiarze:

gunzip -c kopia.dysk >/dev/dysk

Do wykonania kopii zapasowej możemy posłużyć się również programem cpio. Przykładowo po uruchomieniu płyty
podmontowujemy sobie partycję, której kopię chcemy wykonać do katalogu /mnt/hda1, podmontowujemy także
partycje na której ma się znaleźć archiwum (np. /mnt/hda2) i wykonujemy:

# cd /mnt/hda1/
# find . -mount -print | cpio -o > /mnt/hda2/kopia.cpio

Żeby odtworzyć powyższą kopię, należy wykonać:

# cpio -i < /mnt/hda2/kopia.cpio