Mamy mało krytyczny serwer, świadczący pewne usługi dla użytkowników. Dopóki działa i robi swoje, nikt się do niego nie dotyka. Ale ostatnio zachciało mi się przejrzeć listę systemów i porobić trochę aktualizacji. Byłem dość mocno zdziwiony, jak po zalogowaniu i wpisaniu „yum clean all”, program zawisł. Dosłownie – nie reagował na nic, poza „kill -9″. Zacząłem przeglądać logi, porównałem konfigurację, wyłączyłem wszystkie pluginy – nadal nic. Następnym krokiem byłoby przeinstalowanie pakietu, ale w tym wypadku było to mało realne (no bo przecież do instalacji potrzebny jest właśnie YUM, który nie działa).
Poszedłem więc odrobinę inną drogą i ściągnąłem sobie ręcznie nową wersję bezpośrednio z repozytorium CentOSa (wget jest jednym z bardziej przydatnych narzędzi w ratowaniu systemu). „rpm -U yum…” i…. wisi!
Okazało się, że uszkodzeniu uległa baza pakietów (a dokładniej, pliki blokad) RPMa. Wystarczyło je usunąć:
rm -f /var/lib/rpm/__db*żeby wszystko wróciło do normy. Warto zapamiętać ;-)

Systemem wykonującym kopie bezpieczeństwa dla wspomnianych przeze mnie systemów jest Linux (konkretnie CentOS w wersji 5). Po przejrzeniu informacji dostępnych w Internecie okazało się, że metod szyfrowania systemów plików nie ma wcale tak dużo. Pierwszym kandydatem był TrueCrypt, którego z powodzeniem używam w wielu innych miejscach (zarówno zawodowo, jak i prywatnie), jednak – z niewiadomych mi przyczyn – był mało stabilny i potrafił wywalić całą maszynę. Znalazłem nawet informację, że problem faktycznie występuje i że zostanie to kiedyś poprawione. Ale potrzebowałem czegoś „na już”, więc zacząłem szukać dalej. Ostatecznie padło na LUKSa. Nie będę się specjalnie rozpisywał, co można za pomocą tego oprogramowania zrobić, bo jest to ładnie opisane na stronie domowej. Ograniczę się jedynie do krótkiej ściągawki, jak wykonać podstawowe czynności.

Załóżmy, że dysk, który chcemy „zaLUKSować” to /dev/sdd1. Podstawowym narzędziem, jakiego będziemy używać to „cryptsetup”.

Sprawdzanie, czy dane urządzenie nie jest już przypadkiem zaszyfrowane:
cryptsetup isLuks /dev/sdd1 2>>/dev/null && echo TAK || echo NIE
Jeżeli poprzednie polecenie dało wynik negatywny (czyli nie jest jeszcze zaszyfrowane), to możemy je „sformatować”:
cryptsetup luksFormat /dev/sdd1
Teraz warto sprawdzić, czy operacja się faktycznie udała i podejrzeć nagłówek LUKSa:
cryptsetup luksDump /dev/sdd1
Nastepnym krokiem jest „otworzenie” zaszyfrowanego urządzenia:
cryptsetup luksOpen /dev/sdd1 bkpPo tej operacji powinno nam się w systemie pojawić nowe urządzenie blokowe, do którego możemy uzyskać dostęp poprzez /dev/mapper/bkp.

Po zamontowaniu możemy sobie obejrzeć jego „stan”:
dmsetup info bkp
Jeżeli wszystko się zgadza (a przynajmniej nie ma żadnych rażących błędów), przystępujemy do tworzenia systemu plików:
mke2fs -j /dev/mapper/bkp

Na koniec wystarczy zamontować system plików w systemie:
mount /dev/mapper/bkp /mnt/usb…i cieszyć możliwością ukrywania naszych ściśle tajnych danych przed światem.

Po zakończeniu zabawy należy oczywiście odpowiednio wszystko pozamykać:
sync
umount /mnt/usb
cryptsetup luksClose bkp

Ponieważ kilka dni temu zostałem po raz kolejny wymęczony (tym razem za pomocą ankiety) przez audyt, postanowiłem przyjrzeć się sytuacji na rynku skanerów bezpieczeństwa i spróbować coś u siebie w firmie wdrożyć. Do tej pory najlepiej pracowało mi się z Nessusem i od niego zacząłem. Program wygląda naprawdę fajnie (z ciekawości przetestowałem sobie nawet bezpłatną wersję „dla domu”) i jest jednym z najbardziej popularnych skanerów. Ma tylko jedną wadę – cena usługi ProfessionalFeed wynosi 1.200 USD rocznie. I nawet pomimo tego, że według mnie Nessus wart jest tych pieniędzy, to jestem dziwnie spokojny, że nie byłoby łatwo przeforsować takiego wydatku. Kolejnym strzałem była Retina. Produkt równie dojrzały i uznany, co Nessus, to i cena dość podobna. Co dalej? Kiedyś był SATAN, ale znalazłem tylko coś, co nazywało się SARA i nie jest już rozwijane. Kolejną witryną, jaką odwiedziłem była strona domowa projektu SAINT. Niestety, w tym przypadku nie znalazłem nawet konkretnej ceny interesującego mnie produktu. Na tym etapie działania wiedziałem, że mam do wybory trzy produkty, z czego jeden znam, lubię i jest prawdopodobnie najtańszy. Ale to jeszcze nie koniec…

Nie wiem skąd się tam wziąłem, ale w pewnym momencie moim oczom ukazała się strona domowa projektu OpenVAS. O ile udało mi się zorientować, jest to fork Nessusa, który rozpowszechniany jest na licencji GNU. Składa się z kilku współpracujących ze sobą modułów i zestawu testów, które stanowią o sile tego rozwiązania. Co ciekawe, same testy (Network Vulnerability Tests) napisane są w języku NASL opracowanym dla Nessua – kolejna rzecz, która mi się spodobała. Postanowiłem zainstalować OpenVASa na jakiejś maszynie i zobaczyć, ile to cudo jest warte. W CentOSie 5.6 instalacja przebiegła bez problemu i po niedługim czasie miałem gotowe rozwiązanie do skanowania swoich zasobów…

Na razie jestem z odkrycia bardzo zadowolony i w wolnych chwilach staram się tego w jakiś sensowny sposób użyć. Pomimo pewnej „toporności” interfejsu (używam Greenbone Security Assistant), wydaje mi się, że zaprzyjaźnię się z OpenVASem na dłużej. Ciekawe tylko, co powiedzą audytorzy, jak zobaczą raporty utworzone w jakimś abstrakcyjnym systemie, który nie jest „ogólnie uznany przez środowisko” :-)

Można, na przykład, skorzystać z takiej instrukcji, ale dla mnie jest ona odrobinę za bardzo skomplikowana, poza tym nie przepadam za rsync’iem.

Alternatywny proces tworzenia własnego repozytorium pakietów w moim przypadku wyglądał tak:

Po pierwsze – w katalogu /mnt/md3 (bo akurat tutaj miałem trochę miejsca)  utworzyłem odpowiednią strukturę katalogów:
[kbechler@sv ~]# tree /mnt/md3/mirror/centos/5.5 -L 2
/mnt/md3/mirror/centos/5.5
|-- addons
|   |-- i386
|   `-- x86_64
|-- centosplus
|   |-- i386
|   `-- x86_64
|-- contrib
|   |-- i386
|   `-- x86_64
|-- extras
|   |-- i386
|   `-- x86_64
|-- os
|   |-- i386
|   `-- x86_64
`-- updates
|-- i386
`-- x86_64

Po drugie – napisałem sobie prosty plik, o taki:


[kbechler@sv ~]$ cat /mnt/md3/mirror/centos55.lftp
open http://ftp-stud.fht-esslingen.de/pub/Mirrors/centos/5.5
lcd /home/www/html/centos/5.5
echo CENTOS_OS
mirror -e --verbose=3 --parallel=10 os/x86_64 os/x86_64
mirror -e --verbose=3 --parallel=10 os/i386 os/i386
echo CENTOS_ADDONS
mirror -e --verbose=3 --parallel=10 addons/x86_64 addons/x86_64
mirror -e --verbose=3 --parallel=10 addons/i386 addons/i386
echo CENTOS_EXTRAS
mirror -e --verbose=3 --parallel=10 extras/x86_64 extras/x86_64
mirror -e --verbose=3 --parallel=10 extras/i386 extras/i386
echo CENTOS_UPDATES
mirror -e --verbose=3 --parallel=10 updates/x86_64 updates/x86_64
mirror -e --verbose=3 --parallel=10 updates/i386 updates/i386
echo CENTOS_CENTOSPLUS
mirror -e --verbose=3 --parallel=10 centosplus/x86_64 centosplus/x86_64
mirror -e --verbose=3 --parallel=10 centosplus/i386 centosplus/i386
echo CENTOS_CONTRIB
mirror -e --verbose=3 --parallel=10 contrib/x86_64 contrib/x86_64
mirror -e --verbose=3 --parallel=10 contrib/i386 contrib/i386
exit

Po trzecie – w katalogu /etc/cron.daily utworzyłem skrypt, który wywołuje polecenie:

lftp -f /mnt/md3/mirror/centos55.lftp > /var/log/mirror_centos55.log

Po czwarte – skonfigurowałem Apache’a na ten maszynie tak, aby link „http://sv/centos” wskazywał na katalog /mnt/md5/mirror/centos.

Po piąte – poczekałem, aż skrypt z crona zrobi swoje i na lokalnym serwerze będę miał aktualną kopię wszystkich pakietów. Tutaj drobna uwaga: przy wolnym łączu do internetu trzeba albo sprytnie napisać skrypt do synchronizacji, albo uruchomić tą ostatnią „z palca”, a skrypt dopisać do crona po jej zakończeniu. W innym wypadku możemy się natknąć na race-condition, w którym kolejne wywołania „zazębią” się ze sobą (o ile pierwsza synchronizacja nie zakończy się w ciągu 24h).

Po szóste (i ostatnie)  – poprosiłem wszystkie moje systemy, aby pobierały aktualizacje z nowo utworzonego repozytorium. Polegało to na tym, że wywaliłem standardową zawartość katalogu /etc/yum.repos.d i wrzuciłem tam poniższy plik:

[kbechler@sv ~]$ cat /etc/yum.repos.d/centos.repo
[base]
name=CentOS-$releasever - Base
baseurl=http://sv/centos/$releasever/os/$basearch/
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-5
[updates]
name=CentOS-$releasever - Updates
baseurl=http://sv/centos/$releasever/updates/$basearch/
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-5
[addons]
name=CentOS-$releasever - Addons
baseurl=http://sv/centos/$releasever/addons/$basearch/
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-5
[extras]
name=CentOS-$releasever - Extras
baseurl=http://sv/centos/$releasever/extras/$basearch/
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-5
#additional packages that extend functionality of existing packages
[centosplus]
name=CentOS-$releasever - Plus
baseurl=http://sv/centos/$releasever/centosplus/$basearch/
gpgcheck=1
enabled=0
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-5
#contrib - packages by Centos Users
[contrib]
name=CentOS-$releasever - Contrib
baseurl=http://sv/centos/$releasever/contrib/$basearch/
gpgcheck=1
enabled=0
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-5

I to tyle – od momentu wykonania tego powyżej, wszystkie moje maszyny instalują i aktualizują pakiety z lokalnego repozytorium. Dzięki temu zaoszczędziłem odrobinę ruchu (co akurat nie jest w moim przypadku specjalnie ważne), oraz uprościłem konfigurację samej sieci – większość z tych maszyn nie „wystaje” na zewnątrz i konfiguracja NATa stała się zbędna.

Na początek kilka słów o tym, jak znaleźć odpowiedni pakiet. W przypadku SAPa nic nie jest oczywiste, więc nawet z pobieraniem oprogramowania można mieć pewne problemy. Przede wszystkim musimy określić, jaka właściwie wersja będzie nam potrzebna. Z pomocą przychodzi notka o numerze 825494. Ponieważ aktualnie mam zamiar to instalować na CentOSie 5.4 w wersji 32-bitowej, potrzebuję RFCSDK w wersji 6.40 lub 7.00 (przynajmniej tak wynika ze wspomnianej noty). Teraz zaglądamy do noty numer 413708. Mamy tu ładnie opisane gdzie, co i w jakiej kolejności kliknąć, żeby dojść do miejsca z którego możemy sobie pożądane rzeczy pobrać. Oczywiście z rzeczywistością ma to niewiele wspólnego :-) Jak już znajdziemy to, co nas interesuje, to możemy kliknąć „download” i przy odrobinie szczęścia po chwili będziemy posiadaczami wymarzonego pakietu.

Następnym krokiem jest rozpakowanie pliku, który pobraliśmy. Potrzebne jest do tego narzędzie SAPCAR. Do pobrania z serwisu SAP. Tutaj jest trochę łatwiej. Przebijamy się przez menu, aby dojść do miejsca „Search for Support Packages and Patches” i w polu „Search” wpisujemy „SAPCAR”. Klikamy na odpowiednią wersję, wybieramy platformę i pobieramy pakiet. Co ciekawe, wersja dla Linuksa także ma rozszerzenie .exe, ale jest to najzwyklejsza binarka w formacie ELF.

Dobra, mamy dwa upragnione pliki i coś z nimi teraz trzeba zrobić. Na początek zmieńmy atrybuty sapcara:
chmod 755 ./SAPCAR_0-10003688.exe
Tutaj drobna uwaga: Jeżeli próba uruchomienia tego ostatniego spowoduje wywalenie błędu "./SAPCAR_0-10003688.exe: error while loading shared libraries: libstdc++.so.5: cannot open shared object file: No such file or directory" to oznacza, że musimy doinstalować pakiet zgodności o nazwie „compat-libstdc++-33„.

Rozpakowujemy archiwum z instalką RFCSDK:
./SAPCAR_0-10003688.exe -xvf ./RFC_25-10004432.SAR

W wyniku dostajemy katalog rfcsdk, który trzeba gdzieś skopiować. Na przykład do /usr/sap.
Żeby to wszystko chciało działać, musimy jeszcze utworzyć plik sap.conf w katalogu /etc/ld.so.conf.d i wpisać do niego dwie linijki:
/usr/sap/rfcsdk/lib
/usr/sap/lib


Wywołanie sapinfo powinno dać w wyniku mniej-więcej coś takiego:

[kbechler@sv bin]$ /usr/sap/rfcsdk/bin/sapinfo -v
This RFC library belongs to the SAP R/3 Release *** 700,0,239 ***
Versions of SAP internal libraries:
dptr: 2
ni : 38
cpic: 3
rfc : 3
Compiled by compiler version:
3.3.3 (SuSE Linux)
[kbechler@sv bin]$

Ale po co to wszystko? Ano po to, żeby móc monitorować systemy SAP za pomocą Nagiosa i tego skryptu(1).

Skrypt wywołuje się mniej-więcej tak:

[kbechler@sv /]# /usr/lib/nagios/plugins/check_sap_rfcping.pl -a 192.168.0.1 -s 10 -w 50 -c 200
RFCPING OK - No Problems found, AvgRTT=1 ms (SAPF001_SF1_10)
[kbechler@sv /]#


Konfiguracja Nagiosa:

do pliku ‘commands.cfg‘ dodałem wpis:

define command{
command_name check_sap_rfcping
command_line $USER1$/check_sap_rfcping.pl -a $HOSTADDRESS$ -s $ARG1$ -w 50 -c 200
}


Potem zdefiniowałem serwis, który będzie monitorował PINGa:
define service{
use generic-service
host_name sap_sandbox1
service_description SAP RFC PING
check_command check_sap_rfcping!10!-w 100 -c 300
}


I to w zasadzie wszystko. Ruszyło za pierwszym razem (co w IT zdarza się niekoniecznie zawsze ;-))

(1) Żeby skrypt działał, musimy jeszcze pobawić się trochę w linkowanie katalogów: 'ln -s /usr/sap /usr/local/sap'

Jak zmusić Firefoksa pod CentOSem do współdziałania z Javą? Okazuje się to nie być aż tak trywialnym zadaniem, jak by się wydawało (czyli kliknąć, potwierdzić i mieć). Zainstalowałem sobie dość standardowego CentOSa, wyposażonego w pełnowartościowy system graficzny kontrolowany przez GNOMEa. Okazało się, że Firefox jako taki był sam z siebie. Ale nie bardzo, OOTB, wspierał Javę.

Po pierwsze pobrałem najnowszą wersję JRE w wersji „Linux RPM”. Co ciekawe, plik, który udało mi się sciągnąć okazał się „prawie” RPMem. Niby w środku RPM, ale dodatkowo opakowany kawałkiem skryptu BASH:
[root@h7-centos ~]# file ./jre-6u20-linux-i586-rpm.bin
./jre-6u20-linux-i586-rpm.bin: Bourne shell script text executable

Po uruchomieniu „instalatora” najpierw wyświetliło licencję, potem się samo rozpakowało a na koniec powiedziało „Done.” :-)

Problem w tym, że wprawdzie Java się niby zainstalowała, ale Firefox jakby nie załapał, że powinien z niej w jakikolwiek sposób skorzystać i w dalszym ciągu marudził, że nie rozumie. Nic to, nie zrażony pierwszym niepowodzeniem, zacząłem szukać, jak to wszystko zmusić do współdziałania. Może cała procedura (nota bene składająca się z jednego polecenia :-)) nie jest jakoś porażająco skomplikowana, ale tak zupełnie oczywista dla mnie na początku też nie była.

Po krótkich poszukiwania okazało się, że Firefox szuka swoich pluginów w dwóch katalogach:
- globalnym, który wpływa na zachowanie przeglądarkidla wszystkich użytkowników korzystających z danego systemu: /usr/lib/mozilla/plugins,
- lokalnym użytkownika: ~/.mozilla/plugins.

Aby pożenić Firefoksa ze świeżo zainstalowaną przeze mnie Javą, musiałem utworzyć dowiązanie symboliczne (w katalogu, w którym FF szuka pluginów) do odpowiedniej binarki Javy. Wyglądało to tak:
[root@h7-centos ~]# cd /usr/lib/mozilla/plugins
[root@h7-centos plugins]# ln -s /usr/java/default/lib/i386/libnpjp2.so ./
[root@h7-centos plugins]# ls -la libnpj*
lrwxrwxrwx 1 root root 38 lip 2 22:06 libnpjp2.so -> /usr/java/default/lib/i386/libnpjp2.so
[root@h7-centos plugins]#

Po restarcie Firefoksa, program nagle zaczął rozumieć Javę i chyba ją nawet trochę polubił :-)

P.S. Dokładnie tak samo należy postąpić z niedziałającym Flashem, linkując do znanego nam już katalogu plik /usr/lib/flash-plugin/libflashplayer.so.

Okazuje się, że jest kilka metod, którymi zły użytkownik może się posłużyć i powinniśmy zneutralizować je wszystkie. Ale po kolei:

1) Ikonki „Uruchom ponownie” oraz „Wyłącz” widoczne na ekranie logowania (GDM).

To akurat wyłącza się wyjątkowo prosto:
W sekcji [greeter] pliku /etc/gdm/custom.conf musimy dopisać linijkę
SystemMenu=false i zrestartować X’y. Koniec.

Po takim zabiegu ikony służące do denerwowania administratora znikną z ekranu powitalnego raz na zawsze (albo do ponownego włączenia).

2) Menu systemowe GNOME.

Uruchamiamy gconf-editor (jeżeli nie mamy go w systemie, to trzeba sobie doinstalować: yum install gconf-editor), i w gałęzi /apps/panel/global zaznaczamy opcję „disable_log_out„. Nazwa jest trochę myląca, bo samej możliwości wylogowania z systemu nie wyłącza, ale robi to, co mi potrzebne a ja nie muszę chyba wszystkiego rozumieć :-)

3) Zablokowanie możliwości wywołania „poweroff” lub „reboot” z terminala.

Domyślnie CentOS (zamiast kombinować z flagą SUID) dość intensywnie korzysta z programu consolehelper(*) i właśnie w jego konfiguracji będziemy grzebać. Wszystkie programy, które mogą być uruchamiane przez zwykłych użytkowników z prawami roota zdefiniowane są w dwóch katalogach:
/etc/security/console.apps oraz /etc/pam.d

Aby wyłączyć (brutalnie, ale skutecznie) użytkownikom możliwość denerwowania innych, należy z pierwszego z podanych katalogów (czyli /etc/security/console.apps) usunąć pliki „reboot„, „halt” oraz „poweroff„. Warto jeszcze usunąć dowiązania symboliczne do samego consolehelpera z katalogu /usr/bin (bez usuwania linków użytkownikom, zamiast „nie ma takiego pliku…” wyświetlać się będzie okienko „Nieznany błąd”, co wygląda mało profesjonalnie :-)).

I to chyba wszystko. Po krótkich staraniach nie udało mi się zdalnie wyłączyć systemu nie posiadając uprawnień roota :-)

(*) Trochę więcej o programie consolehelper można poczytać sobie tutaj.

Szczęśliwie istnieje „bezpieczna” odmiana FTPa: FTPS, która dodaje wsparcie dla TLS/SSL. W dodatku skonfigurowanie czegoś takiego nie jest zbytnio skomplikowane. W najprostszym przypadku (vsftpd działający na CentOSie) wystarczy wygenerować certyfikat typu self-signed:
[kbechler@flame ~]$ openssl req -new -x509 -nodes -out vsftpd.pem -keyout vsftpd.pem
Generating a 2048 bit RSA private key
.................................................................................................+++
....................................+++
unable to write 'random state'
writing new private key to 'vsftpd.pem'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [PL]:
Locality Name (eg, city) []:
Organization Name (eg, company) []:
Organizational Unit Name (eg, section) []:
Given name []:
Surname []:
Common Name (eg, your name or your server's hostname) []:
Email Address []:
[kbechler@flame ~]$ sudo mv ./vsftpd.pem /etc/vsftpd


Dopisać poniższe trzy linijki do pliku konfiguracyjnego serwera (/etc/vsftpd/vsftpd.conf):
ssl_enable=YES
rsa_cert_file=/etc/vsftpd/vsftpd.pem
force_local_data_ssl=NO

i zrestartować usługę:
[kbechler@flame ~]$ sudo /etc/init.d/vsftpd restart
Shutting down vsftpd: [ OK ]
Starting vsftpd for vsftpd: [ OK ]


Potrzebujemy jeszcze klienta, który wspiera FTPS. Na szczęście ładnie poproszony Total Commander coś takiego potrafi :-)

Różnicę widać od razu:

Niestety, taka konfiguracja nieco nas ogranicza. Serwer vsftpd nie pozwala na logowanie użytkowników bez użycia SSLa, co powoduje, że nie da się do naszego serwera podłączyć używając np. klienta FTP wbudowanego w Windows. Można to zmienić dodając parametr „force_local_logins_ssl=NO” do konfiguracji serwera, ale… ponieważ ludzie są z natury leniwi, to nie będzie im się chciało niczego zmieniać w i dalszym ciągu będą korzystać z połączenia nieszyfrowanego… niestety, na ten problem lekarstwa nie znam :-(

(*) Od wersji 4.8 (ChangeLog) istnieje w OpenSSH parametr ChrootDirectory, który w prosty sposób coś takiego umożliwia.

• nazwę hosta,
• nazwę pakietu,
• wersję pakietu zainstalowanego,
• najnowszą wersję pakietu, która została wydana i można ją zainstalować.

Skrypt powstał w BASHu i wygląda tak:
#!/bin/bash
IFS=$'\n'
for l in `yum -d 0 check-update | grep -v "^$"`; do
pakiet=`echo ${l} | cut -d ' ' -f 1`
ver1=`yum list ${pakiet} | grep -A 1 "^Installed Packages" | grep -v "^Installed Packages" | awk '{print $2}'`
ver2=`echo ${l} | awk '{print $2}'`
s=`hostname`; while [ ${#s} -lt 30 ]; do s="${s} "; done
s="${s} pakiet: ${pakiet}"; while [ ${#s} -lt 70 ]; do s="${s} "; done
s="${s} aktualna wersja: ${ver1}"; while [ ${#s} -lt 120 ]; do s="${s} "; done
s="${s} nowa wersja: ${ver2}"
echo "${s}"
done

Nie jest może zbyt wyrafinowany i zdecydowanie nie jest najszybszy, ale robi to, co do niego należy i nie jest zbytnio skomplikowany.

Po co? Bo fajnie jest wiedzieć, co się u moich „podopiecznych” dzieje i jak bardzo ten stan odbiega od tzw. „nówki sztuki”.

Jednak Linux, jako system operacyjny w firmie, powinien posiadać kilka cech, których Slack’owi brakuje. Większość (jeżeli nie wszyscy) producentów oprogramowania dla firm wspiera tylko kilka konkretnych dystrybucji. Najczęściej lista taka zawiera trzy lub cztery pozycje, produkowane przez „dużych” i nie zawraca sobie głowy niczym, co powstaje w przysłowiowym ‘garażu’. No, może poza produktami Apple’a, ale Oni mają odrobinę większy garaż :-)

Dlaczego akurat CentOS? Bo jest to w zasadzie RedHat dostępny za darmo. Nie kojarzę programu napisanego dla Linuksa, który na liście wspieranych dystrybucji nie miałby RH. A CentOS to prawie to samo (i w tym wypadku nie robi aż tak dużej różnicy). Kompilowany jest z tych samych źródeł, więc jego pakiety są binarnie zgodne z tymi z Red Hata. A to oznacza, że możemy mieć całkiem niezłą i stabilną dystrybucję Linuksa klasy Enterprise bez płacenia.

Oczywiście, korzystając z CentOSa, nie mamy możliwości skorzystania z pomocy technicznej Red Hata ani kilku innych rzeczy, oferowanych przed producenta czerwonego kapelusza. Ale jeżeli są nam rzeczywiście potrzebne, to cena zakupu RH nie powinna być dla nas żadnym problemem.

Z drugiej strony, w CentOSie nie ma wszystkich możliwych programów w ich najnowszych wersjach. Jest to jednak cena, którą musimy zapłacić za naprawdę stabilne środowisko.

Od ponad roku używam na swoich maszynach wyłącznie opisywanej tu dystrybucji i, jak do tej pory, sprawuje się świetnie. Aktualizowanie systemu jest bezproblemowe. Nie zdarzają się właściwie problemy z niepoprawnych działaniem czegokolwiek po wykonaniu aktualizacji nawet tych bardziej wrażliwych części systemu. Co oczywiście nie oznacza, że na maszynach produkcyjnych możemy sobie tak po prostu zrobić update w dowolnej chwili! Takie rzeczy powinny być przemyślane bardzo dokładnie – tak na wszelki wypadek.

Właśnie, skoro przy bezpieczeństwie systemów jesteśmy…

Ludzie dzielą się na dwie grupy. Na tych, którzy robią backupy i na tych, którzy dopiero będą je robić. A Ty? Do której grupy należysz? :-)