K-NET s.c.

Jak prawidłowo zainstalować RAID1 w Debianie z dyskami 2TB

Obecnie dyski twarde osiągają pojemności, o których jeszcze nie dawno można było pomarzyć. Obsługa dużych dysków w systemie Debian nie stanowi żadnego problemu. Jednak sytuacja może się nieco skomplikować jeżeli chcemy złożyć RAID1. Zdarza się, że podczas instalacji, napotykamy błąd instalacji GRUB. Dodatkowo, jeżeli uda się zainstalować system to okazuje się, że po awarii pierwszego dysku system nie chce wystartować automatycznie z drugiego.

Powyższy problem wynika z nieprawidłowej obsługi tablicy partycji typu GUID. Jednak nie tylko. Rzecz jasna, gdy instalujemy system od początku i musimy przygotować tablice partycji na nowym dysku, wówczas w programie instalacyjnym należy wybrać partycję typu GPT. Nie rozwiązuje to jednak problemu z instalacją GRUB.

Począwszy od Debiana Wheezy należy, na początku każdego dysku w RAID1, założyć partycję typu biosgrub. Jej rozmiar to 1MB. Potem możemy zdefiniować kolejne partycje wg uznania.  Po złożeniu macierzy RAID1, na zakończenie instalacji, zostaniemy poproszeni o wskazanie miejsca instalacji GRUB. Wybieramy opcje 'master boot record’.

Ostatnim, bardzo ważnym, krokiem jest wydanie polecenia:

grub-install /dev/sdb

po instalacji i uruchomieniu czystego systemu operacyjnego.

MG

Debian Wheezy – Vsftpd: Refusing to Run With Writable Root Inside Chroot ()

Wheezy, który jest najmłodszą wersją w dystrybucji Debian, zyskał już całkiem spore gorono użytkowników. Przyznam, że również korzystam z tej wersji i myśle, że jest całkiem udanym produktem. Niemniej spotkałem się ostatno z pewnym problemem, który dotyczył serwera FTP. Ponieważ od kilku lat korzystam z pakietu vsftpd, który wydaje się być dość stabilną i bezpieczną alternatywą dla pozostałych serwerów, postanowiłem zainstalować to oprogramowanie na jednym z moich nowych hostów.   Tym razem czekała mnie przykra niespodzianka. Po zainstalowaniu paczki i skopiowaniu gotowych i sprawdzonych plików konfiguracyjnych, przy próbie pierwszego połączenia vsftpd powitał mnie komunikatem:

vsftpd: refusing to run with writable root inside chroot() Login failed.

Bardzo zależało mi na rozwiązaniu problemu. Szybka lektura z pomocą Google zaowocowała gradem linków, setkami odpowiedzi na różnych forach. Niestety żadna nie dawała gotowej recepty. Jednak w międzyczasie zidentyfikowałem bład opisany w serwisach Debiana: 656900. Pozwoliło to na wyszukanie całkiem ciekawej łatki. Okazało się, że ekipa Cyconet na swoim blogu zdążyła opublikować poprawioną wersję vsftpd. Wystarczyło ją zainstalować (kod/sniplet zamieszczam poniżej) i po problemie… do następnego razu.

echo "deb http://ftp.cyconet.org/debian wheezy-updates \ 
main non-free contrib" >> \
/etc/apt/sources.list.d/wheezy-updates.cyconet.list; \
aptitude update; aptitude install -t wheezy-updates \ 
debian-cyconet-archive-keyring vsftpd && \
echo "allow_writeable_chroot=YES" >> /etc/vsftpd.conf \
&& /etc/init.d/vsftpd restart

MG

Instalacja GRUB na drugim dysku macierzy RAID1

Począwszy do Debiana Squeuze, wśród jego użytkowników, administratorów systemu itd. rozgorzała dyskusja na temat błędów pojawiających się podczas instalacji. Rzecz dotyczy składania macierzy RAID1. Jak się okazuje, nawet prawidłowo przeprowadzony proces instalacji systemu od zera nie gwarantuje, że nasz serwer będzie bezpieczny. W czym rzecz? W przypadku awarii pierwszego dysku macierzy, nie ma szans aby system wystartował z drugiego, lustrzanego dysku. Najprościej ujmując, pakiet GRUB, który stanowi tzw. boot-loader, zostanie zainstalowany w MBR (Master Boot Record – Główny Rekord Startowy) tylko pierwszego dysku. Rozwiązanie wydaje się bardzo proste. Trzeba ręcznie zainstalować GRUB w MBR drugiego dysku. Jednak z niewiadomych przyczyn większość poradników przytacza błędną komendę (sic!). Wg moich doświadczeń, a walczyłem z powyższym problemem dzień cały, jedyną i sprawdzoną postacią komendy 'grub-install’ jest:

grub-install --no-floppy --boot-directory=/dev/md0 /dev/sdb

Kilka słów komentarza. Istotne jest poprawne wskazanie zarówno partycji typu RAID (/dev/md0) jak i fizycznego dysku (/dev/sdb – zakładam, że w przytoczonym przykładzie drugi dysk to /dev/sdb). Po wykonaniu powyższej operacji, można przejść do sprawdzenia czy system startuje z drugiego dysku np. odpinając na czas testów, dysk pierwszy od kontrolera.

MG

Jak ograniczyć liczbe równoczesnych połączeń z serwerem SSH

Obecnie sieci VPN są zagadnieniem powszechnie znanym, szeroko komentowanym i zalecanym we wdrożeniach biznesowych. Istnieje cała masa gotowych rozwiązań sprzętowych, na poziomie aplikacji itp. Praktycznie każdy administrator może sam, według uznania, wybrać wygodne narzędzie. Różnią się one algorytmami, wymaganiami oraz niestety ceną. Czy można zbudować skalowalny dostęp VPN do firmy, który nie będzie wymagał dużych środków finansowych? Jednym z szeroko ostatnio polecanych rozwiązań jest VPN z wykorzystaniem serwera SSH. Elementami tej techniki są m. in.: (a) serwer dostępowy, zrealizowany np. jako sewer Linux z demonem SSHD oraz (b) aplikacja kliencka, która potrafi zestawić szyfrowany tunel np. Bitwise Tunellier.

Jeden z problemów, związanych z opisywanym tunelem SSL polega na tym, że klient może kreować równocześnie wiele połączeń, korzystających w tym samym czasie, z tego samego konta dostępowego. Być może nie jest to rzecz dyskwalifikująca całość, jednak w codziennej praktyce administratorskiej może utrudniać życie. W końcu chcemy aby logi systemowe były jasne i przejrzyste – słowem czytelne. Najlepiej aby jedno połączenie, czyli wspomniany tunel SSL, było przypisane tylko i wyłączenie do jednego konta.

Przykładowe rozwiązanie dla systemu Linux, z serwerem dostępowym bazującym na dystrybucji Debian Squeeze, polega na odpowiedniej modyfikacji pliku ’/etc/security/limits.conf’. Zawiera on m. in. defincje dotycząca liczby równoczesnych sesji SSH dla jednego konta dostępowego. W opisywanym rozwiązaniu należy dodać następującą linie przed znacznikiem ’# End of file’:

@sshlimited     -       maxlogins       1

I to wszystko, jak zwykle w przypadku Linuxa, krótko i na temat 🙂

MG

Jak skompilować ClamAV dla Debiana – aktualizacja

Jakiś czas temu opublikowałem krótki artykuł na temat kompilacji ClamAV dla systemu Debian. Trochę czasu upłynęło (tak naprawdę ponad 3 lata – jak ten czas leci…), pora zatem na aktualizację poradnika. Dystrybucje Debiana nie często pociągają za sobą konieczność rewolucyjnych zmian, jednak jeśli chcemy powtórzyć cały proces dla Debiana Squeeze (aktualnej wersji stable) to powinniśmy liczyć się z paroma drobiazgami:

•  Przede wszystkim nie musimy już dodawać repozytorium Debian Volatile, które zostało zastąpione przez squeeze-updates (vide: http://www.debian.org/News/2011/20110215). Zatem, o ile jeszcze tego nie zrobiliśmy, powinniśmy w pliku /etc/apt/sources.list umieścić linikę:

deb-src http://security.debian.org/  squeeze/updates →
→ main contrib non-free

• Jeśli zaś, a jestem niemal pewien, że tak właśnie jest,  mamy również dodane repozytorium:

deb     http://security.debian.org/  squeeze/updates →
→ main contrib non-free

•  to kompilowanie ClamAV powinniśmy wykonywać tylko w przypadku problemów z pakietem instalowanym z gotowej paczki.

Jak widać na podstawie powyższego przykładu, od Debiana Squeeze, zadania związane z obsługą ClamAV, znacznie się upraszczają. Czy to dobrze, czy źle? Odpowiedź pozostawiam administratorom na co dzień utrzymującym swoje serwery.

MG

Obsługa UPS Smart-UPS SC1000 w Debian Squeeze

Dawno już minęły czasy, kiedy praktycznie każdy UPS firmy APC, obecnie APC Schneider, można było obsłużyć za pomocą linuksowego daemona apcupsd. Na stronie jego autorów można znaleźć ostrzeżenie przed kupowaniem modeli SmartUPS SMX/SMT 750, 1000, 1500, czy SmartUPS RT 3000XL, 5000XL. Niestety padłem ofiarą takiego zakupu i duże było moje zdziwienie, że nic nie działa jak powinno. Ponieważ miałem możliwość wymiany urządzenia, to zamówiłem nowy, inny model. Tym razem zażyczyłem sobie żeby był obsługiwany przez apcupsd. Po paru dniach dotarł UPS Smart-UPS SC1000. Zabrałem się szybko za instalacje i okazało się, że znowu jest problem. Serwer nie miał portu szeregowego, zaś UPS zamiast kabla USB został wyposażony w adapter Profilic USB-to-serial. Mając na pokładzie Debiana Squeeze zacząłem zmagać się z adapterem. Moduł obsługi został dołączony do standardowego jądra, jednak UPS nadal pozostawał ślepy i głuchy. Po kilku godzinach szukania rozwiązania, trafiłem na strony Ubuntu Forum, gdzie udało mi się znaleźć pozyteczne informacje i przygotować działające, choć może niezbyt eleganckie rozwiązanie.

Po pierwsze – modyfikujemy skrypt startowy ’/etc/init.d/apcupsd’, dodając między wierszem:

case "$1" in
  start)
    echo -n "Starting $DESC: "

a wierszem:

rm -f /etc/apcupsd/powerfail

następujący kod:

if [ ! -d /dev/usb-tty ]
then
mkdir -p /dev/usb-tty
fi

mknod /dev/usb-tty/ttyUSB0 c 188 0
mknod /dev/usb-tty/ttyUSB1 c 188 1
mknod /dev/usb-tty/ttyUSB2 c 188 2
mknod /dev/usb-tty/ttyUSB3 c 188 3
mknod /dev/usb-tty/ttyUSB4 c 188 4
mknod /dev/usb-tty/ttyUSB5 c 188 5
mknod /dev/usb-tty/ttyUSB6 c 188 6
mknod /dev/usb-tty/ttyUSB7 c 188 7
mknod /dev/usb-tty/ttyUSB8 c 188 8
mknod /dev/usb-tty/ttyUSB9 c 188 9
mknod /dev/usb-tty/ttyUSB10 c 188 10
mknod /dev/usb-tty/ttyUSB11 c 188 11
mknod /dev/usb-tty/ttyUSB12 c 188 12
mknod /dev/usb-tty/ttyUSB13 c 188 13
mknod /dev/usb-tty/ttyUSB14 c 188 14
mknod /dev/usb-tty/ttyUSB15 c 188 15

Po drugie – edytujemy plik ’/etc/apcupsd/apcupsd.conf’ i definiujemu następujące parametry:

UPSCABLE smart
UPSTYPE apcsmart
DEVICE /dev/usb-tty/ttyUSB0

Ostania linijkę powinniśmy zmodyfikować w zależności od portu, do którego podłączyliśmy UPS. Po restarcie daemona apcupsd:

/etc/init.d/apcupsd stop
/etc/init.d/apcupsd start

nasz UPS, po wpisaniu polecenia:

/etc/init.d/apcupsd status

powinien odezwać się dobrze znanym komunikatem.

MG

Automatyczne przesyłanie zawartości skrzynki pocztowej na inne konto z wykorzystaniem Mutt

Jakiś czas temu spotkałem się z sytuacją, w której znajomy posiadający konto poczty elektronicznej na linuksowym serwerze chciał wszystkie wiadomości przesłać jednym poleceniem na nowe konto na serwerze MS Exchange. Wiem, dla niektórych to mocno niewłaściwy kierunek ale zostałem poproszony o pomoc. Konfiguracja serwerów uniemożliwiała bezpośredni import danych. Pozostały zatem jedynie różne mniej lub bardziej udane obejścia. Długo myślałem rozważając różne możliwości i ponieważ jestem zadeklarowanym zwolennikiem terminala oraz Mutta, postanowiłem wygorzystać jego funkcje. Przyznam, że nie wiedziałem czy jest to wogóle możliwe ale Mutt po raz kolejny pozytwnie mnie zaskoczył.

Po uruchomieniu Mutta z linii poleceń:

mutt -f /path/to/mboxfile

możemy przystąpić od razu do działania. Wykorzystujemy następującą sekwencje klawiszy:

[T][.][enter]

zaznaczając wszystkie wiadomości w skrzynce. Następnie kontynuujemy:

[;][b]

i podajemy adres e-mail, na który chcemy przesłać wiadomości. Po zatwierdzeniu:

[enter]

Mutt prześle wszystkie wiadomości na nowe konto.

Nie ma rzeczy doskonałych. Dlatego i w tym przypadku trzeba wspomnieć, że wiadomości zostaną przekazane na nowe konto z tą samą datą. Jednak nasze cenne dane zostaną skopiowane i zachowane.

MG

Jednorazowe korzystanie z Proxy podczas aktualizacji

Jednym z wielu zadań należących do administratora systemu Linux Debian jest wykonywanie aktualizacji. Funkcjonuje nawet anegdota, że użytkownika Debiana można rozpoznać po tym, iż każdy dzień rozpoczyna od komendy:

apt-get update

Tak czy inaczej czasami zdarza się, że aktualizacje ciągną się w nieskończoność a szybkość połączenia pozostawia wiele do życzenia. Nie są to niestety sporadyczne przypadki. Dodatkowo jeżeli mamy do czynienia z kilkoma serwerami w sieci, które powinniśmy zaktualizować sytuacja może być irytująca. Rozwiązaniem w tym przypadku jest serwer proxy. Co zrobić jednak, gdy chcemy z niego skorzystać tylko jednorazowo na czas aktualizacji? Rozwiązanie jest bardzo proste i wymaga jedynie dostępu do konsoli. Wydajemy polecenie:

http_proxy='http://adres_serwera_proxy:port'

co pozwoli nam na wykorzystanie proxy ad-hoc bez rekonfiguracji ustawień systemowych.

MG

Jak dodać obsługę SVN do XAMPPa

XAMPP jest bardzo wygodnym zestawem typu Apache+PHP+MySQL. Moim zdaniem jego przewaga nad podobnymi rozwiązaniami wynika z dopracowanego projektu oraz możliwości instalacji przez rozpakowanie archiwum do katalogu '/opt’. Wykonywanie kopii zapasowych oraz przenoszenie całego serwisu z serwera na serwer jest również bardzo proste, wystarczy bowiem zatrzymać usługę, zrobić kopię (np. za pomocą tar) i przenieść na inny komputer.

XAMPP nie jest jednak pozbawiony drobnych wad. Jedną z nich jest brak wbudowanej obsługi systemu kontroli wersji SVN. Taka właściwość jest bardzo przydatna jeśli chcemy utworzyć np. repozytorium dokumentów za pomocą WebDAV (odpowiedni moduł jest standardowo wbudowany w XAMPP).

Instalację SVN zaczynamy od instalacji odpowiednich pakietów z repozytorium:

apt-get install subversion libapache2-svn

Następnie przygotowywujemy katalog dla repozytorium SVN np. '/var/svn’:

mkdir /var/svn/

Zakładamy pzrykładowy projekt o nazwie test:

svnadmin create --fs-type fsfs /var/svn/test

Potem dodajemy użytkownika (np. marcin) z uprawnieniami do naszego projektu. Dwa pierwsze wiersze kodu poniżej wykonujemy jednorazowo:

rm -f /var/svn/test/conf/passwd
touch /var/svn/test/conf/passwd
htpasswd /var/svn/test/conf/passwd marcin

Tworzymy grupę subversion i ustawiamy uprawnienia dla katalogu '/svn’:

groupadd subversion
chmod -R 777 /var/svn/*

Żeby XAMPP mógł obsłużyć SVN konieczne są dwie biblioteki mod_authz_svn.so oraz mod_dav_svn.so. Możemy je np. skopiować z katalogu Apache, pod warunkiem, że zainstalowaliśmy wcześniej pakiet apache2:

cp /usr/lib/apache2/modules/mod_authz_svn.so /opt/lampp/modules/
cp /usr/lib/apache2/modules/mod_dav_svn.so /opt/lampp/modules/

Teraz możemy wyedytować plik '/opt/lampp/etc/httpd.conf”, żeby najpierw pod linią zawierającą wpis LoadModule ssl_module modules/mod_ssl.so umieścić fragment:

LoadModule dav_svn_module modules/mod_dav_svn.so
LoadModule authz_svn_module modules/mod_authz_svn.so

a następnie na końcu pliku dodać:

# Subversion repositories

<Location /test>
DAV svn
SVNPath /var/svn/test
AuthType Basic
AuthName “Subversion Repository”
AuthUserFile /var/svn/test/conf/passwd
Require valid-user
SSLRequireSSL
</Location>

Po zatrzymaniu i ponownym uruchomieniu XAMPPa, możemy rozpocząć testowanie opisanego rozwiązania.

MG

NOCC – następca Webimiau

Posiadanie własnego systemu webmail lub inaczej mówiąc klienta poczty zainstalowanego na serwerze WWW jest z wielu powodów przydatną rzeczą. Rzecz jasna mamy wiele gotowych rozwiązań takich jak Gmail czy Yahoo Mail lub OWA dla posiadaczy serwera MS Exchange. Jeśli jednak chcemy przygotować rozwiązanie wyłącznie dla swoich (lub firmy) potrzeb i nie chcemy poświęcać dużo czasu na jego konfigurację a mamy już zainstalowany serwer protokołu POP3 lub IMAP to znalezienie dobrego, lekkiego rozwiązania, które w dodatku może zostać zainstalowane praktycznie wszędzie (nie tylko na serwerze poczty jak np. SquirrelMail) staje się małym wyzwaniem.

Moim ulubioną aplikacją do tej pory był Uebimiau. Niestety wydaje się, że projekt został porzucony lub przynajmniej nie jest rozwijany. A szkoda, bowiem był na prawdę prosty w konfiguracji i oferował elegancki interfejs (co dla mnie jest ważne).

Za jego następcę, biorąc pod uwagę łatwość i szybkość wdrożenia, można obecnie uznać projekt NOCC. Ta ciągle rozwijająca się aplikacja posiada minimalne wymagania. W zasadzie wystarczy serwer WWW np. Apache z zainstalowanym PHP w wersji 5.0.0 lub nowszej. Baza danych nie jest potrzebna w tym przypadku. Trochę surowy interfejs całkowicie rekompensuje konfiguracja za pomocą pliku 'config/conf.php’, która została przejrzyście udokumentowana. Jedyny błąd jaki znalazłem związany był z nieprawidłowym spolsczeniem interfejsu. Usterkę tą można łatwo naprawić usuwając z pliku 'config/conf_lang.php’ poniższą sekcję:

// Pashto
$lang_array[$i] = new lang();
$lang_array[$i]->filename = 'ps';
$lang_array[$i]->label = 'پښتو';

Podobno błąd dotyczy wersji 1.9.1, jednak w poprzednich wersjach również występuje (co osobiście sprawdziłem).

MG