piątek, 28 września 2012

Bridge Linux - Grub - konsola

Ostatnio po odtworzeniu obrazu dysku, na którym zainstalowany był Bridge Linux, używający Gruba2 zainstalowanego w MBR (startowy sektor dysku), powitała mnie konsola Gruba... 1. Wszystko przez ClonZillę, która obraz zrobiła poprawnie, ale podczas jego odtwarzania instalowała Gruba 1 zamiast 2.
Reanimacja systemu możliwa jest oczywiście z płyty instalacyjnej Bridge Linux Live, ale można prościej. Należy wykorzystać możliwości konsoli Gruba:

  • root (hd0,0) - wskazanie partycji, na której zainstalowany był Bridge (/dev/sda1);
  • kernel /boot/vmlinuz-linux ro - wskazanie jądra
  • initrd /boot/initramfs-linux.img - wskazanie obrazu startowego systemu plików
  • boot - uruchomienie

Po wydaniu powyższych komend, zgłosi się konsola awaryjna Bridge'a (Archa), czyli rootfs. Zakładając, że używamy systemd do uruchamiania systemu, wykonujemy następujące polecenia:

  • mkdir /boot - jeżeli mamy osobną partycję dla tego katalogu
  • mount /dev/sda1 /new_root - montujemy partycję, na której zainstalowaliśmy Bridge'a
  • cd /new_root
  • exec init=/bin/systemd

Po wydaniu ostatniego polecenia system powinien wystartować. Pozostaje wtedy zainstalować Gruba2:

  • sudo grub-install --target=i386-pc --recheck --force /dev/sda - instalacja w MBR
  • sudo grub-mkconfig -o /boot/grub/grub.cfg


Po restarcie powinniśmy zobaczyć menu startowe Gruba.

Bridge Linux - serwer SSH

Instalacja

sudo pacman -S openssh

Konfiguracja

Edytujemy plik /etc/ssh/sshd_config, w którym można dodać następujące opcje:
AllowUsers user1 user2
PermitRootLogin no

Pierwsza wskazuje użytkowników, którzy będą mogli logować się przez ssh; druga opcja zabrania logowania na konto roota.

Uruchomienie serwera

Mamy dwie możliwości:

  • sudo systemctl enable sshd.service - uruchomienie serwera ssh podczas startu systemu
  • sudo systemctl enable sshd.socket - uruchamianie serwera ssh po próbie połączenia


Proponuję wybrać drugie.

środa, 12 września 2012

Apache2 + PHP5 na Ubuntu 12.04 i Archlinux

Chodzi o zainstalowanie serwera www z obsługą php w katalogach domowych użytkownika.

Ubuntu 12.04


Instalujemy pakiety:
sudo apt-get install apache2 php5 php5-gd php5-sqlite

Po instalacji edytujemy /etc/apache2/mods-available/php5.conf, aby odkomentować wspracie dla php w katalogach użytkownika. Następnie uaktywniamy odpowiednie moduły apache'a:
sudo a2enmod userdir rewrite
sudo service apache2 restart - restart usługi


Archlinux, Bridge Linux


Instalujemy pakiety:
sudo pacman -S apache php php-gd php-sqlite
sudo pacman -S systemd-httpd-units
- pliki konfiguracyjne usługi dla systemd
sudo packer -S php-apache

Do pliku /etc/httpd/conf/httpd.conf dodajemy:
  • LoadModule php5_module modules/libphp5.so - na końcu sekcji LoadModule,
  • Include conf/extra/php5_module.conf - na końcu sekcji Include, pod koniec pliku.

W tym samym pliku odkomentowujemy:
  • TypesConfig conf/mime.types - powinno być odkomentowane domyślnie,
  • MIMEMagicFile conf/magic - opcjonalnie.

Do pliku /etc/httpd/conf/mime.types dodajemy na końcu listy "application":
application/x-httpd-php5 php php5

sudo systemctl start httpd.service - uruchomienie
systemctl status httpd.service - status


Błędy


W obydwu systemach zaglądamy do logów:
  • cat /var/log/apache2/error.log - Ubuntu
  • cat /var/log/httpd/error.log - Arch

Katalogi użytkownika


Tworzymy katalog na strony www:
mkdir public_html

Tworzymy plik testowy index.php z zawartością:
<?php
    phpinfo();
?>
- i zapisujemy w public_html. W przeglądarce wpisujemy localhost/~nazwa_użytk i powinniśmy zobaczyć informacje o środowisku php i serwerze.

niedziela, 2 września 2012

Bridge Linux i Systemd

W poprzednim poście nt. instalacji najnowszego Bridge'a poruszyłem temat migracji na nowy mechanizm startowy systemd. Wypada rozszerzyć i uporządkować uwagi dotyczące wdrażania tego rozwiązania.

Pliki konfiguracyjne

Pierwszym, nieodzownym warunkiem przejścia na systemd jest zastąpienie dotychczasowego pliku konfiguracyjnego Archa, tj. rc.conf, plikami charakterystycznymi dla nowego systemu, co opisałem wcześniej:

  • /etc/hostname
  • /etc/vconsole.conf
  • /etc/locale.conf
  • /etc/timezone
  • /etc/adjtime
  • /etc/environment

Obsługa modułów ładowanych podczas uruchamiania systemu realizowana jest przez pliki z katalogu /etc/modules-load.d/ [więcej], moduły blokowane konfigurujemy w katalogu /etc/modprobe.d/ [więcej].

Próbne użycie systemd

Pierwsze użycie systemd wiąże się z czynnościami opisanymi w poprzednim poście:
  • w /etc/environment wstawiamy: LANG=pl_PL.utf8
  • w /etc/default/grub dopisujemy: GRUB_CMDLINE_LINUX_DEAFAULT="quiet init=/bin/systemd"
  • sudo grub-mkconfig -o /boot/grub/grub.cfg - aktualizujemy Gruba
  • sudo systemctl enable graphical.target - ustawiamy domyślny target (runlevel, poziom) uruchamiania
  • sudo systemctl enable lxdm.service - uruchamiamy podczas startu systemu menedżer logowania
Restart i... wszystko powinno działać.

Tylko systemd

Jeżeli po restarcie wszystko (lub prawie) działa, należy spróbować całkowitego zastąpienia dotychczasowych skryptów startowych nowym mechanizmem:
  • sudo pacman -R sysvinit initscripts - usuwamy stare skrypty startowe
  • sudo pacman -S systemd-sysvcompat - instalujemy pakiet kompatybilności systemd z sysvinit
  • sudo systemclt enable NetworkManager.service - jeżeli wykorzystujemy NetworkManagera do zarządzania połączeniami sieciowymi uruchamiamy go podczas startu systemu
Restart i... wszystko powinno działać.
Jeżeli wszystko (lub prawie) działa, z domyślnej konfiguracji Gruba można usunąć parametr "init=/bin/systemd", pamiętając o zaktualizowaniu potem pliku koniguracyjnego.

Journal zamiast syslog-ng

Systemd zawiera własną usługę logowania, journal. Syslog-ng można odinstalować lub skonfigurować do używania razem z journalem. Domyślnie logi journala są tracone po restarcie, aby tak nie było należy utworzyć klatalog: sudo mkdir /var/log/journal. Rozmiar logu ustawiamy w pliku /etc/ssytemd/journald.conf, np. na 20 MB:
SystemMaxUse=20M
Użyteczne polecenia:
  • journalctl - wyświetlenie logów
  • journalctl _SYSTEMD_UNIT=alsa.service - przykładowe filtrowanie logów

sobota, 1 września 2012

Bridge Linux 2012.8 i systemd

Jak zainteresowanym wiadomo, dostępna jest następna kompilacja Bridge Linux, oznaczona 2012.8. Instalacja przebiega tak samo, jak w wersji 2012.5, ale domyślnie instalowany jest GRUB2. W moim przypadku po restarcie okazało się, że bootmenedżer poprawnie się nie zainstalował. Musiałem więc jeszcze raz uruchomić komputer z wypalonej instalki Bridge'a i wklepać trochę kodu:

sudo mount /dev/sda2 /mnt -o rw
cd /mnt
sudo mount -t proc proc proc/
sudo mount -t sysfs sys sys/
sudo mount -o bind /dev dev/
sudo mount -t devpts pts dev/pts/
chroot . /bin/bash
- po tych operacjach można zainstalować GRUBA2 tak jak potrzeba, np.:
grub-install --target=i386-pc --recheck --force /dev/sda[2]
grub-mkconfig -o /boot/grub/grub.cfg
exit
- powyższe polecenia instalują GRUBa na dysku /dev/sda albo w MBR (/dev/sda), albo na wybranej partycji (/dev/sda2). Po restarcie wszystko powinno działać.

Po udanej instalacji, jak zwykle uruchomi się skrypt konfiguracyjny, który ustawia m.in. repozytoria i uruchamia procedurę aktualizacji. Tym razem przebiega ona bez większych problemów, ale jak się okazuje Bridge nadal używa "starego" pliku konfiguracyjnego /etc/rc.conf. Ponieważ ArchLinux stopniowo rezygnuje ze skryptów startowych sysvinit na rzecz systemd, należy je jednak utworzyć. W poście Bridge Linux 2012.5 - konfiguracja opisałem, które pliki są potrzebne. Po ich utworzeniu plik /etc/rc.conf można ograniczyć do wpisu:
DAEMONS=(dbus networkmanager syslog-ng @alsa)
- czyli określenia usług uruchamianych podczas startu systemu.

Systemd

Przejście Archa na mechanizm startowy systemd niesie ze sobą przede wszytskim przyśpieszenie uruchamiania i wyłączania systemu (w moim przypadku system uruchamia się w trybie GUI 10 sekund). Jednak żeby tak się stało, trzeba skonfigurować kilka rzeczy. Na początek w pliku /etc/environment dopisujemy:
LANG=pl_PL.utf8
- następnie w pliku /etc/default/grub jedną linię uzupełniamy:
GRUB_CMDLINE_LINUX_DEFAULT="quiet init=/bin/systemd"

Trzeba jeszcze zaktualizować plik konfiguracyjny GRUBa, czyli: sudo grub-mkconfig -o /boot/grub/grub.cfg.
Teraz można skonfigurować domyślny poziom (ang. target) uruchamiania się systemu i start graficznego menedżera logowania:
systemctl enable graphical.target
systemctl enable lxdm.service

Pozostaje restart i... obserwowanie szybszego startu systemu... Na koniec warto dodać, że powyższe zmiany nie porzucają jeszcze całkowicie mechanizmu sysvinit i jego skryptów konfiguracyjnych. Jak całkowicie przejść na systemd, napiszę niedługo.

Aktualizacja: Czysty systemd w Bridge Linux 2012.8.

czwartek, 9 sierpnia 2012

Ubuntu Server 12.04 LTS - Dnsmasq

Usługi DHCP i DNS są zazwyczaj realizowane przez wyspecjalizowane oprogramowanie, takie jak odpowiednio ISC DHCP i ISC Bind, niemniej w małych sieciach, gdzie ta sama maszyna pełni funkcję routera, serwera DHCP i DNS etc. można pomyśleć o alternatywnym rozwiązaniu, czyli Dnsmasq.

Instalacja

sudo apt-get install dnsmasq

Konfiguracja

Wszystkie ustawienia znajdują się w pliku /etc/dnsmasq.conf, chociaż moglibyśmy umieścić je w osobnych plikach w katalogu /etc/dnsmasq.d. Konfiguracja funkcjonalności serwera DHCP i DNS (cache) dla sieci lokalnej na interfejsie 192.168.19.1 (zobacz post nt. konfiguracji Ubuntu Server 12.04 LTS) przedstawia się następująco:
domain-needed
bogus-priv
filterwin2k
# nie korzystaj z pliku /etc/resolv.conf
no-resolv
# serwery DNS, np. naszego ISP
server=208.67.222.222
server=208.67.220.220
# nasza domena
local=/mojadomena.org/
# nasłuchuj na interfejsie
interface=eth1
expand-hosts
domain=mojadomena.org
# zakres adresów
dhcp-range=192.168.19.100,192.168.19.200,255.255.255.0,12h
# przykład rezerwacji adresów stałych
dhcp-host=00:1E:33:49:0E:C2,hostwlanie,192.168.19.14,1h
#
dhcp-option=3,192.168.19.1 # adres routera
# Opcje dla Samby w roli PDC
dhcp-option=19,0           # opcja ip-forwarding off
dhcp-option=44,0.0.0.0     # WINS server(s)
dhcp-option=45,0.0.0.0     # netbios datagram distribution server
dhcp-option=46,8           # netbios node type (hybrid)
dhcp-option=vendor:MSFT,2,1i # zwalnianie przydzielonego adresu DHCP
# serwer autorytatywny
dhcp-authoritative
cache-size=200
W opcjach server podajemy adresy naszych serwerów DNS, w przykładzie powyżej mamy serwery Open DNS, pozostałe opcje są bardzo dobrze opisane w oryginalnym pliku konfiguracyjnym (warto zrobić jego kopię).

Aby wszystko działało, trzeba jeszcze pamiętać o dwóch rzeczach. W pliku /etc/dhcp/dhclient.conf opcja prepend domain-name-servers 127.0.0.1; powinna być odkomentowana. Natomiast w pliku /etc/hosts, który dnsmasq propaguje do wszystkich klientów, powinna znaleźć się linia definiująca adres naszego routera i serwera Samby (bardzo ważne, jeżeli Samba jest serwerem PDC i korzystamy z profili wędrujących):
#127.0.1.1 mojserwer.mojadomena.org mojserwer//to zakomentowujemy
192.168.19.1 mojserwer.mojadomena.org mojserwer
Dnsmasq zużywa o wiele mniej zasobów niż tandem ISC DHCP + ISC Bind, jest też, jak widać prostszy w konfiguracji. Przydzielone adresy zapisywane są w pliku:
cat /var/lib/misc/dnsmasq.leases

Usługę uruchamiamy standardowo, tzn. sudo service dnsmasq start, oczywiście jeżeli wcześniej skonfigurowaliśmy ISC Dhcp i Binda, trzeba je wyłączyć: sudo service isc-dhcp-server stop && sudo service bind9 stop. Żeby ISC Dhcp i Bind nie były uruchamiane podczas startu systemu (załóżmy, że chcemy wypróbować Dnsmasq nie odinstalowując niczego), można zrobić tak:
# poniższe da błędy podczas startu, które można pominąć
sudo chmod a-x /etc/init.d/bind9
# przenosimy linki uruchamiajce isc-dhcp do swojego katalogu domowego
sudo mv /etc/init.d/isc-dhcp-* ./
Po restarcie powinien uruchomić się Dnsmasq.

środa, 1 sierpnia 2012

Ubuntu Server 12.04 LTS - dynamiczna aktualizacja DNS przez DHCP

Chodzi nam o to, aby serwer DHCP na bieżąco aktualizował bazę usługi DNS. Obydwie usługi zainstalowane są na tej samej maszynie i obsługują sieć lokalną (zobacz poprzedni post).
Sieć LAN: 192.168.19.0/24
Adres serwera: 192.168.19.1

Ponieważ serwer Bind9 musi mieć prawo zapisu do plików definiujących naszą strefę lokalną, przenosimy pliki konfiguracyjne i nadajemy odpowiednie uprawnienia, następnie generujemy klucz zabezpieczający dla usługi DHCP:

sudo cp /etc/bind/db.* /var/lib/bind
sudo chown bind:bind /var/lib/bind/*
sudo dnssec-keygen -r /dev/urandom -a HMAC-MD5 -b 128 -n USER DHCP_UPDATER
sudo cat Kdhcp_updater.*.private|grep Key

Ostatnie polecenie wyświetli wygenerowany klucz na ekranie, np. Key: 5FROo2v0qrs5qS3pKL8pS2==, to co po dwukropku, należy skopiować do schowka.
Zmieniamy plik /etc/bind/named.conf.local:

key DHCP_UPDATER {
  algorithm HMAC-MD5.SIG-ALG.REG.INT;
  # Poniżej wklej skopiowany wcześniej klucz
  secret "5FROo2v0qrs5qS3pKL8pS2==";
};
# W definicjach stref zmieniamy opcje file oraz dodajemy
# opcje allow-update
zone "lo1cg.org" {
  type master;
  file "/var/lib/bind/db.lo1cg.org";
  allow-update { key DHCP_UPDATER; };
};

zone "19.168.192.in-addr.arpa" {
  type master;
  notify no;
  file "/var/lib/bind/db.192";
  allow-update { key DHCP_UPDATER; };
};

Trzeba jeszcze skonfigurować usługę DHCP. Modyfikujemy plik /etc/dhcp/dhcpd.conf:
# Na początku pliku dodajemy:
ddns-update-style interim;
ignore client-updates;
update-static-leases on;
ddns-domainname "mojadomena.org.";
ddns-rev-domainname "in-addr.arpa.";

# Przed definicją podsieci dodajemy:
key DHCP_UPDATER {
  algorithm HMAC-MD5.SIG-ALG.REG.INT;
  # Poniżej wklej skopiowany wcześniej klucz
  secret "5FROo2v0qrs5qS3pKL8pS2==";
};

zone lo1cg.org. {
  primary 127.0.0.1;
  key DHCP_UPDATER;
}

zone 19.168.192.in-addr.arpa. {
  primary 127.0.0.1;
  key DHCP_UPDATER;
}

Reszta bez zmian. Na uwagę zasługuje opcja update-static-leases, którą powyżej włączyliśmy. Odpowiada ona za dopisanie do bazy DNS rekordów dla wszystkich hostów, którym przypisujemy statyczne adresy IP poprzez usługę DHCP. Manual dhcpd.conf ostrzega, że może to generować dużo ruchu wewnątrz sieci, więc trzeba zwrócić uwagę na opcje min-lease-time i max-lease-time oraz przeglądać log systemowy.
Na koniec restartujemy obie usługi i sprawdzamy, czy poprawnie się uruchomiły:
sudo service bind9 restart
sudo service isc-dhcp-server restart
sudo tail -n 50 /var/log/syslog

Po uruchomieniu jakiejś maszyny w sieci LAN (mojhost), możemy sprawdzić, czy baza DNS została zaktualizowana:
host 192.168.19.100 #adres IP mojegohosta
100.19.168.192.in-addr.arpa domain name pointer mojhost.mojadomena.org.