Nautilus

Konfiguracja bardzo prosta, musimy wpisać tylko adres serwera, użytkownika, hasło oraz odpowiednią ścieżkę. Zgodnie z opisem na oficjalnej stronie jako ścieżkę podajemy /files/webdav.php. Klikamy na Connect i mamy dostęp do naszych plików w chmurze.

Dolphin

Tutaj oczywiście ustawienia są dokładnie takie same. Konfiguracja krok po kroku na poniższych zrzutach.

Instalacja

Aplikacja wymaga serwera Apache, PHP 5 oraz bazy danych (MySQL lub SQLite). Ściągamy paczkę ownCloud 2 z oficjalnej strony (www.owncloud.org):

root@itcore owncloud]# wget http://owncloud.org/releases/owncloud-2.tar.bz2

Rozpakowane pliki umieszczamy w odpowiednim katalogu (wskazanym przez DocumentRoot w konfiguracji Apache). Teraz musimy nadać właściwe uprawnienia dla katalogów data i config (prawa zapisu dla serwera Apache, w systemie CentOS jest to użytkownik apache).

root@itcore owncloud]# chmod 750 data
root@itcore owncloud]# chmod 755 config
root@itcore owncloud]# chown apache.apache data/
root@itcore owncloud]# chown apache.apache config/

ownCloud korzysta także z pliku .htaccess, dlatego musimy włączyć opcję AllowOverride All w konfiguracji Apache!

[root@itcore owncloud]# cat .htaccess
ErrorDocument 404 /owncloud/core/templates/404.php
<IfModule mod_php5.c>
php_value upload_max_filesize 16M
php_value post_max_size 16M
php_value memory_limit 128M
SetEnv htaccessWorking true
</IfModule>
Options -Indexes

Kolejnym krokiem jest utworzenie użytkownika i bazy w MySQL:

mysql> create database db_owncloud;
Query OK, 1 row affected (0.01 sec)
mysql> GRANT ALL PRIVILEGES ON db_owncloud.* TO user_owncloud@localhost IDENTIFIED BY 'secretpassword';
mysql> flush privileges;

Następnie wpisujemy w przeglądarce adres pod którym zainstalowaliśmy ownCloud. Na stronie ustawiamy użytkownika/hasło dla administratora oraz podajemy poprawne dane dla bazy MySQL.

Po wszystkim możemy się już zalogować do systemu.

Możliwości

Po zalogowaniu się po lewej stronie widoczne jest menu z sekcjami:

- Files (pliki)
- Music (muzyka)
- Calendar (kalendarz)
- Contacts (kontakty)
- Bookmarks (zakładki)

W sekcji Files możemy zarządzać naszymi plikami. Wrzucać, usuwać oraz udostępniać określonym grupom lub wszystkim (make public). W tym przypadku system automatycznie wygeneruje link, który odnosi się do danego pliku. Jeśli chodzi o Upload to maksymalny rozmiar pliku definiujemy w pliku .htaccess (upload_max_filesiz i post_max_size).

Jeżeli na serwerze znajdują się pliki muzyczne możemy ich posłuchać w sekcji Music

Administracja kalendarzem, dodawanie zdarzeń, widok tygodniowy/miesięczny oraz lista zdarzeń, te opcje dostępne są po kliknięciu w Calendar. Każde zdarzenie możemy przypisać do kilku kategorii, określić czas trwania itd. Oczywiście kalendarz możemy też wyeksportować (format ics). Niestety brakuje opcji importu…

Contacts czyli administracja kontaktami. Tutaj też brak importu/eksportu.

Ostatnia sekcja to Bookmarks. Także brakuje importu/eksportu. Ciekawostką jest to że po wpisaniu adresi zakładki system automatycznie uzupełnia pole Title.

W lewym dolnym rogu mamy jeszcze dostęp do ustawień. Zarządzanie użytkownikami i grupami, edycja własnych ustawień (hasło, email, język etc). Tutaj też można aktywować dodatkowe pluginy/aplikacje (Apps), na przykład logowanie przy użyciu OpenID lub LDAP. Miejmy nadzieję że z czasem na stronie apps.owncloud.com pojawi się więcej dodatków.

Podsumowanie

Aplikacja oferuje szereg ciekawych możliwości. Miejmy nadzieję, że braki zostaną szybko uzupełnione. Developerzy obiecują m.in galerię obrazków, rozbudowanie aktualnych sekcji, synchronizację. Premiera ownCloud 3 zapowiedziana jest na 31 Stycznia 2012 roku. Kto chce być na bieżąco może też ściągnąć najnowszą wersję rozwojową.

Przykładowa konfiguracja

W poniższym przykładzie korzystamy z dwóch połączonych ze sobą maszyn (redundancja przy użyciu carp). Firewall fw-m korzysta też z modemu DSL. Więcej informacji na temat redundancji w OpenBSD znaleźć można we wpisie „Redundantny Firewall w OpenBSD”, natomiast o konfiguracji DSL w OpenBSD można przeczytać tutaj. Będziemy monitorować zarówno stan interfejsów carp, jak i łącza DSL (pppoe0). Schemat poniżej:

ifstated używa pliku /etc/ifstated.conf do konfiguracji:

root@fw-m:/>cat /etc/ifstated.conf
init-state master 

carp_up = "carp0.link.up && carp2.link.up"
carp_init = "carp0.link.unknown || carp2.link.unknown"
pppoe0_up = "pppoe0.link.up && vr1.link.up"
pppoe0_down = "!pppoe0.link.up || !vr1.link.up"

state master {
        init {
                run "echo fw-m is now in MASTER state | mail -s 'fw-m ifstated state: MASTER' root@localhost"
        }
        if ($carp_init)
          run "sleep 2"
        if (! $carp_up)
         set-state backup
        if ($pppoe0_up)
        {
          run "echo fw-m DSL is UP | mail -s 'fw-m ifstated DSL up' root@localhost"
          run "pfctl -f /etc/pf.conf"
        }
        if ($pppoe0_down)
        {
	   run "echo fw-m DSL is DOWN | mail -s 'fw-m ifstated DSL down' root@localhost"
           run "pfctl -f /etc/pf.conf-nodsl"
        }

}
state backup {
        init {
          run "echo fw-m is now in BACKUP state | mail -s 'fw-m ifstated state: BACKUP' root@localhost"
        }
        if ($carp_init)
          run "sleep 2"
        if ($carp_up)
          set-state master
}

W powyższym przykładzie fw-m działa domyślnie w stanie master (init-state master). Definiujemy po 2 zdarzenia dla interfejsów carp oraz pppoe. carp_up jeżeli obydwa interfejsy carp są włączone oraz carp_init jeżeli ich stan nie jest jeszcze zdefiniowany. Podobnie dla interfejsu pppoe1 (który jest połączony z vr1). Jeżeli wszystko działa poprawnie system wyśle na wybrany adres 2 maile oraz zrestartuje firewall’a.
Gdy ifstated wykryje, że interfejs pppoe0 lub vr1 nie działają, ponownie prześle odpowiedniego maila oraz dodatkowo włączy firewall’a bez obsługi DSL (/etc/pf.conf-nodsl).
W przypadku usterki któregoś z interfejsów carp system zmieni status na backup oraz oczywiście prześle maila.

Konfigurację można przetestować wpisując:

root@fw-m:/>ifstated -n -v
carp_up = "carp0.link.up && carp2.link.up"
carp_init = "carp0.link.unknown || carp2.link.unknown"
pppoe0_up = "pppoe0.link.up && vr1.link.up"
pppoe0_down = "!pppoe0.link.up || !vr1.link.up"
ifstated: configuration OK

Jeżeli wszystko się zgadza możemy włączyć daemona wpisując po prostu polecenie ifstated.
Jak widać konfiguracja jest bardzo prosta, a możliwość uruchamiania poleceń/skryptów podczas wykrycia zmiany na interfejsach daje szerokie pole do popisu oraz pozwala na zbudowanie niezawodnego systemu.

Aplikacja ppp

Pliki konfiguracyjne znajdziemy w katalogu /etc/ppp, a główny plik konfiguracyjny to ppp.conf. Cały plik jest podzielony na sekcje z różnymi przykładami. Nas interesuje protokół pppoe, znajdziemy go w sekcji pppoe:. Właściwie jedyne co należy wpisać to nasz login (set authname) i hasło (set authkey) oraz podać nazwę interfejsu do którego podłączony jest modem DSL (set device) :

root@fw-s:/etc/ppp>tail -n 20 /etc/ppp/ppp.conf
pppoe:
 set device "!/usr/sbin/pppoe -i vr1"
 set mtu max 1492
 set mru max 1492
 set speed sync
 set crtscts off
 disable acfcomp protocomp vjcomp pred1 deflate
 disable ipv6cp
 deny acfcomp
 enable lqr
 accept lqr
 set lqrperiod 30
 set cd 5
 set login
 set authname "LOGIN"
 set authkey "HASLO"
 enable mssfixup

Aby nawiązać połączenie wpisujemy:

root@fw-s:/etc/ppp>ppp -ddial pppoe
Working in ddial mode
Using interface: tun1

W systemie zostanie utworzony nowy interfejs (w tym przypadku tun1), który jest połączony z fizycznym interfejsem vr1 (bridge). Jeśli nasza konfiguracja jest poprawna, otrzymamy od naszego providera adres IP, który zostanie przypisany do interfejsu:

root@fw-s:/etc/ppp>ifconfig tun1
tun1: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1492
        priority: 0
        groups: tun
        status: active
        inet X.X.X.X --> Y.Y.Y.Y netmask 0xffffffff

Gdzie X.X.X.X to nasz adres IP. W razie problemów, możemy zawsze zajrzeć do logów:

root@fw-s:/etc/ppp>grep "ppp" /var/log/daemon.lg
Aug  5 12:20:13 fw-s ppp[24801]: Phase: Using interface: tun1
Aug  5 12:20:13 fw-s ppp[24801]: Phase: deflink: Created in closed state
Aug  5 12:20:13 fw-s ppp[24801]: tun1: Command: default: set device /dev/cua01
Aug  5 12:20:13 fw-s ppp[24801]: tun1: Command: default: set speed 115200
Aug  5 12:20:13 fw-s ppp[24801]: tun1: Command: pppoe: set device !/usr/sbin/pppoe -i vr1

Dodatkowo ppp może uruchomić dowolny skrypt podczas włączenia/wyłączenia interfejsu. W takim wypadku w katalogu /etc/ppp musimy utworzyć pliki ppp.linkup i ppp.linkdown:

root@fw-s:/etc/ppp>cat /etc/ppp/ppp.linkup
MYADDR:
    !bg sh -c "echo $(date "+%Y%m%d-%H%M") LINK UP >> /tmp/ppp.txt"

Niestety podczas połączenia przez ppp transfer był bardzo niestabilny i zauważalne były bardzo częste spadki prędkości nawet do kilkudziesięciu kilobitów na sekundę. Przykład poniżej (plik pobierany ze strony kernel.org):

Sytuacja ta ma miejsce zarówno w wersji 4.8 jak i 4.9 systemu. Na szczęście problem ten nie występuje jeśli łączymy się używając pseudo-urządzenia pppoe.

pseudo-device pppoe

W tym przypadku cała konfiguracja zamyka się w pliku /etc/hostname.pppoe0:

root@fw-s:~>cat /etc/hostname.pppoe0
inet 0.0.0.0 255.255.255.255 NONE \
   pppoedev vr1 authproto pap \
   authname 'LOGIN' authkey 'HASLO' up
   dest 0.0.0.1
!/sbin/route add default -ifp pppoe0 0.0.0.1

Tutaj podobnie łączymy interfejs pppoe0 z fizycznym interfejsem vr1. Ważnym jest, żeby vr1 był włączony (UP):

root@fw-s:~>cat /etc/hostname.vr1
up

Połączenie zostanie automatycznie podniesione podczas uruchomienia systemu. Można też sprawdzić konfigurację od razu , korzystając ze skryptu /etc/netstart a jako parametr podać nazwę interfejsu:

root@fw-s:~>sh /etc/netstart pppoe0

Podobnie jak w przypadku aplikacji ppp powinniśmy otrzymać adres adres IP od naszego providera:

root@fw-s:~>ifconfig pppoe0
pppoe0: flags=8851<UP,POINTOPOINT,RUNNING,SIMPLEX,MULTICAST> mtu 1484
        priority: 0
        dev: vr1 state: session
        sid: 0x8ad PADI retries: 6 PADR retries: 0 time: 04:30:14
        sppp: phase network authproto pap authname "LOGIN"
        groups: pppoe egress
        status: active
        inet6 fe80::200:24ff:fecb:d110%pppoe0 ->  prefixlen 64 scopeid 0xf
        inet X.X.X.X --> Y.Y.Y.Y netmask 0xffffffff

Warto jeszcze ustawić maksymalny rozmiar segmentu (MSS) w pliku /etc/pf.conf dla interfejsu pppoe0:

match on pppoe0 scrub (max-mss 1440)

Opcja ta jest równoważna z ustawieniem enable mssfixup w pliku ppp.conf w przypadku połączenia przez aplikację ppp.

Tym razem nie było żadnych problemów z transferem, wszystko działało bardzo stabilne:

Więcej informacji znajdziemy jak zawsze w manualu. Dla ppp wpisujemy (man pppoe), a dla pseudo-urządzenia pppoe: man 4 pppoe

Przygotowanie maszyny wirtualnej

Na początku utworzymy nową maszynę wirtualną. Przydzielimy systemowi 512MB pamięci, do tego dysk twardy o rozmiarze 8GB.

Instalacja systemu

Po przygotowaniu maszyny wirtualnej, można przystąpić do instalacji. Na początek musimy ściągnąć obraz ISO systemu (plik install49.iso). Lista wszystkich serwerów lustrzanych znajduje się pod adresem openbsd.org/ftp.html. Plik ten następnie dodajemy do naszej maszyny wirtualnej jako napęd CD (Storage -> IDE Controller):

Teraz możemy uruchomić już maszynę i naszym oczom ukaże się bootloader systemu. Po wciśnięciu klawisza enter, wczyta się instalator systemu. Na początku musimy zdecydować czy chcemy system zainstalowac (‘I’), zaaktualizowac (‘U’) czy chcemy uruchomić tylko powłokę (‘S’). My oczywiście wciskamy ‘I’. Zostawiamy domyślny układ klawiatury, ustawiamy nazwę hosta i decydujemy się na automatyczną konfigurację sieci.

W kolejnym kroku ustawiamy hasło dla konta root oraz dzecydujemy się na automatyczny start demona sshd i ntpd wraz z systemem. Ustawiamy też konto dla zwykłego użytkownika (testuser)

Teraz czas na podział dysku na partycje. Instalator automatycznie przygotuje dysk:

jednak my utworzymy własny schemat (guzik ‘C’):

/ -> 5000MB
swap -> 256MB
/home -> reszta

Partycje dodajemy używając ‘a’, określamy jej rozmiar (np 5000M), punkt montowania (np. /home) oraz typ plików (zostawiamy domyślne). Po wszystkim wychodzimy zapisujemy schemat (‘w’) i wychodzimy z programu (‘q’). Podział na partycje jest pokazany poniżej:

Teraz pora na wybór pakietów które chcemy mieć zainstalowane w systemie. Do wyboru mamy kilka tzw. set’ów, są to m.in. jądro systemu (bsd, bsd.rd, bsd.mp), pliki konfiguracyjne (etc), bibioteki, manuale, kompilatory, X-serwer, czcionki. My zostawimy domyślny zestaw. Odznaczyć dany set moża wpisując znak ‘-’ wraz z jego nazwą (np. -game49.tgz), a dodajemy używając ‘+’.
Na koniec pozostaje nam wybór strefy czasowej (Europe/Warsaw) i system jest już gotowy. Wpisujemy polecenie reboot, usuwamy wirtualną płytę i bootujemy nasz nowy system.

Konfiguracja

Po instalacji dodamy kilka podstawowych pakietów, które ułatwią nam pracę. Na początku musimy ustawić zmienną PKG_PATH:

export PKG_PATH=ftp://ftp.piotrkosoft.net/pub/OpenBSD/4.9/packages/i386/

Zmienną PKG_PATH warto dodać to pliku ~/.profile. Teraz możemy już zainstalować interesujące nas aplikacje (bash, screen, bzip2, mc):

# pkg_add -i bash
bash-4.1.9p0:partial-libiconv-1.13p2->libiconv-1.13p2: ok
bash-4.1.9p0:gettext-0.18.1p0: ok
bash-4.1.9p0: ok
# pkg_add -i screen
Ambiguous: choose package for screen
 a       0: <None>
         1: screen-4.0.3p2
         2: screen-4.0.3p2-shm
         3: screen-4.0.3p2-static
Your choice: 1
screen-4.0.3p2: ok
# pkg_add -i screen
Ambiguous: choose package for screen
 a       0: <None>
         1: screen-4.0.3p2
         2: screen-4.0.3p2-shm
         3: screen-4.0.3p2-static
Your choice: 1
screen-4.0.3p2: ok
# pkg_add -i bzip2
bzip2-1.0.6: ok
# pkg_add -i mc
mc-4.7.0.8:pcre-8.02p1: ok
mc-4.7.0.8:oniguruma-5.9.1: ok
mc-4.7.0.8:libslang-2.2.2: ok
mc-4.7.0.8:zip-3.0: ok
mc-4.7.0.8:unzip-6.0: ok
mc-4.7.0.8:libgamin-0.1.10p3: ok
mc-4.7.0.8:glib2-2.26.1p0: ok
mc-4.7.0.8: ok

Więcej na temat zarządzania pakietami w systemie OpenBSD można przeczytać w naszym starszym wpisie. Na koniec jescze dla użytkownika testuser ustawimy powłokę bash jako domyślną:

# usermod -s /usr/local/bin/bash testuser
# su - testuser
-bash-4.1$ echo $SHELL
/usr/local/bin/bash

Nasza „bazowa” wersja systemu jest już gotowa. W kolejnym artykule opiszemy jak zainstalować i skonfigurować na niej środowisko Gnome 2.32.

Pobranie listy

Posłużymy się plikiem udostępnianym na stronie heise.de. Jak można przeczytać lista jest uaktualniana co 15 minut, a w pliku znajduje się 40000 adresów IP. Po 12h dany adres jest automatycznie usuwany z listy, jeśli nie wysyła już spamu. Plik zapiszemy i rozpakujemy w katalogu /tmp:

root@fw-s:~>wget http://www.dnsbl.manitu.net/download/nixspam-ip.dump.gz -O /tmp/spamips_list.gz
root@fw-s:~>gunzip /tmp/spamips_list.gz

Każda linika w pliku składa się z 2 pól: czasu i adresu IP. My potrzebujemy tylko kolumnę nr 2:

root@fw-s:~>cd /tmp && cat spamips_list | cut -d" " -f2 > spamips_list.txt
root@fw-s:~>wc -l /tmp/spamips_list
   40000 /tmp/spamips_list

Konfiguracja packet filter

Tak przygotowany plik można już wrzucić do firewall’a. W tym celu stworzymy nową tablicę spamips_list, która będzie wskazywać na nasz plik. Następnie zablokujemy cały ruch z tych adresów IP na interfejsie WAN dla portów 25, 110, 465 etc.

root@fw-s:~>cat /etc/pf.conf
table <spamips_list> persist file "/tmp/spamips_list.txt"
block in log quick on $WAN proto tcp from <spamips_list> to any port {25,110,465}

Teraz wystarczy tylko zrestartować pfctl:

root@fw-s:~>pfctl -t spamips_list -T kill && pfctl -f /etc/pf.conf

Warto jeszcze zobaczyć czy tablica została utworzona i czy jakieś adresy IP zostały już zablokowane:

root@fw-s:~>pfctl -t spamips_list -T show  | wc -l
   39785
root@fw-s:~>pfctl -sr -vv | grep -A2 spamips
@20 block drop in log quick on vr0 inet proto tcp from <spamips_list:33285> to any port = smtp
  [ Evaluations: 2177      Packets: 5         Bytes: 300         States: 0     ]

Tablica spamips_list zawiera 39785 adresów IP (zdublowane adresy są automatyczne usuwane), a nasz firewall zablokował już 5 pakietów na porcie 25 z adresów IP znajdujących się w tablicy. Czyli wszystko gra.
Jako że lista jest aktualizowana co 15 minut, warto napisać skrypt który automatycznie pobiera nowe adresy, a następnie restartuje firewall’a.

[root@itcore ~]# dd if=/dev/sda of=/mnt/sda-dump.img
19999490048 bytes (20 GB) copied, 2335.69 s, 8.6 MB/s

Taka kopię najlepiej wykonać na nie zabotowanym systemie, używając na przykład dystrybucji LiveCD (Knoppix). Warto ustawić też większą wartość dla opcji bs (ile bajtów jest odczytywanych/zapisywanych naraz) przez co zyskamy na czasie, przykładowo 15MB:

[root@itcore ~]# dd bs=15M if=/dev/sda of=/mnt/sda-dump.img
19999490048 bytes (20 GB) copied, 875.233 s, 22.9 MB/s

Różnica w szybkości jest znaczna, z 8.6MB/s dla domyślnych wartości do 22.9MB/s przy ustawieniu bs=15MB.

Zrzut dysku na zdalny serwer

Łącząc polecenie dd z ssh można w prosty sposób umieścić kopię dysku na zdalnym serwerze:

[root@itcore ~]# dd if=/dev/sda bs=15M conv=sync,noerror | ssh -o TCPKeepAlive=yes root@REMOTE_SERVER “dd of=/root/sda-dump.img”

Aby zaoszczędzić cenny transfer, można użyć polecenia gzip. Dodatkowo używając polecenia pv ograniczymy prędkość wysyłania do 1MB na sekundę:

[root@itcore ~]# dd if=/dev/sda bs=10M conv=sync,noerror | gzip -c | pv -L 1m -r | ssh -o TCPKeepAlive=yes root@REMOTE_SERVER "cat > root/sda-dump.img.gz"

[root@itcore bin]# ls -l /bin/chmod
-rwxr-xr-x 1 root root 40024 Oct 27  2009 /bin/chmod
[root@itcore bin]# chmod -x /bin/chmod
[root@itcore bin]# /bin/chmod
bash: /bin/chmod: Permission denied
-rw-r--r-- 1 root root 40024 Oct 27  2009 /bin/chmod

Operacji nie da się już naprawić w prosty sposób:

[root@itcore bin]# /bin/chmod +x /bin/chmod
bash: /bin/chmod: Permission denied

Naprawa

Tak jak pisaliśmy sposobów jest wiele. Możemy użyć linkera ld.so, który pozwoli nam uruchomić dowolny program:

[root@itcore ~]# /lib64/ld-2.5.so /bin/chmod +x /bin/chmod
[root@itcore ~]# ls -l /bin/chmod
-rwxr-xr-x 1 root root 40024 Oct 27  2009 /bin/chmod

W zależności od wersji systemu (32 lub 64bity) należy użyć katalogu lib lub lib64. Plik chmod można też naprawić używając dowolnego pliku, który aktualnie posiada prawa wykonywania. Wystarczy skopiować go gdzieś (np. jako /bin/chmod2chmod'a:

[root@itcore ~]# cp /bin/ls  /bin/chmod2
[root@itcore ~]# cat /bin/chmod > /bin/chmod2
[root@itcore ~]# /bin/chmod2
[root@itcore ~]# /bin/chmod2 +x /bin/chmod
[root@itcore ~]# ls -l /bin/chmod
-rwxr-xr-x 1 root root 40024 Oct 27  2009 /bin/chmod
[root@itcore ~]# rm /bin/chmod2
rm: remove regular file `/bin/chmod2'? y

root@fw-s:~>cat /etc/mail/service.switch
hosts       files dns

W tym przypadku sendmail najpierw sprawdzi zawartość pliku /etc/hosts, a dopiero później skorzysta z serwera DNS (jeżeli nie znajdzie potrzebnej domeny w pliku). Jeśli chcemy, żeby korzystał tylko z pliku hosts wystarczy usunąć słowo dns:

root@fw-s:~>cat /etc/mail/service.switch
hosts       files

Na koniec musimy zrestartować proces sendmail:

root@fw-s:~>kill -HUP `head -1 /var/run/sendmail.pid`