Sieciowe bazy danych użytkowników - NIS, LDAP :: Instalacja serwera LDAP :: Konfiguracja Ldap Account Manager :: Administracja kontami LDAPowymi :: Klienci bazy LDAP :: Autoryzacja kont systemowych w LDAP z użyciem PAM i NSS :: Klucze publiczne SSH z LDAP :: Autoryzacja HTTP w Apache2 w oparciu o LDAP :: Autoryzacja w MediaWiki :: Autoryzacja użytkowników Mantis'a w oparciu o LDAP :: LDAP password change on web page :: Tworzenie "instalacji" postgres'a :: IPMI :: nie tylko IPMI :: Puppet czyli centralne zarządzanie :: Monit :: Fail2ban - odpieranie ataków siłowych :: Logi systemowe - syslog-ng i logrotate :: Usługi wysokiej dostępności

Poradnik konfiguracyjny POSIX - serwerowe

Sieciowe bazy danych użytkowników - NIS, LDAP

Tradycyjnie udostpnianiem danych użytkowników dla wielu maszyn zajmował się NIS. Współcześnie jego miejsce coraz częściej zajmuje LDAP.

Konfiguracja oby tych machanizmów może być oparta na pliku /etc/nsswitch.conf w którym określamy źródła pochodzenia (takie jak file, nis, ldap, dns, ...) dla różnych usług informacyjnych (baza hostów, baza protokołów, baza użytkowników, ...). Możliwe jest także wykorzystanie PAM do konfiguracji tych mechanizów.

O ile sam LDAP pozwala na zagnieżdzanie grup w grupach itp to jest to ciężko zastoswać do UNIXowego modelu grup uzytkowników, jednak w przypadku takiej potrzeby można stworzyć narzędzie zamieniające taką zagnierzoną strukturę na płaską listę wielu grup do których przynależy użytkownik.

Bazę LDAP możemy przeszukiwać za pomocą komendy ldapsearch, natomiast pełną informację np. o bazie passwd możemy uzyskać poprzez getent passwd (jest to odpowiednik znanego z systemów NIS ypcat).

Zobacz w Sieci: LDAP/NSS - Debian Wiki, LDAP/PAM - Debian Wiki

Instalacja serwera LDAP

Jeżeli mamy ustawiony zbyt wysoki priorytet debconfa to instalator pakietu serwera LDAP (slapd) użyje nazwy domeny (bez nazwy serwera) do utworzenia suffix'u zakładanej bazy danych. Aby użyć czegoś innego najprościej użyć dpkg-reconfigure slapd.

Utworzona przy instalacji baza danych nie posiada struktury wykorzystywanej do uzyskiwania informacji o użytkownikach przez NSS oraz PAM. Można utworzyć ją manualnie lub wykorzystać Ldap Account Manager, który utworzy ją przy pierwszym zalogowaniu.

Konfiguracja Ldap Account Manager

Ldap Account Manager jest wygodnym interfejsem web-owym do zarządzania bazą użytkowników opartą o LDAP. Logowanie do systemu odbywa się przy pomocy konta i hasła administracyjnego LDAP (jest od razu logowaniem do serwera LDAP).

Przed zalogowaniem należy skonfigurować system do pracy ze swoim serwerem LDAP. W tym celu łączymy się z stroną konfiguracyjną LAM dostępną pod adresem http://nazwa.lub.IP.serwera/lam/templates/config/index.php i w sekcji dotyczącej profili serwerowych ("server profiles"):

Warto także ustawić odpowiednie wymagania dotyczące haseł oraz zmienić hasło dostępu do sekcji dotyczącej ustawień globalnych. W obu wypadkach domyślnym hasłem dostępowym jest lam

Po tych zmianach należy zalogować się do LAM. System zaproponuje utworzenie brakującej struktury dla wybranych typów kont - zgadzamy się. Gdy utworzenie struktury zostanie wykonane, możemy przystąpić do zakładania grup i kont.

Administracja kontami LDAPowymi

URL="ldap://adres.of.ldap.serwer/"
BASEDN="dc=opcode,dc=eu,dc=org"
BINDDN="uid=MYADMINLOGIN,ou=People,$BASEDN"

# dodanie usera:
	ldapadd -xW -H "$URL" -D "$BINDDN" -x -W -f dodawanie.ldif

# dodanie do grupy lub inne modyfikacje:
	ldapadd -xW -H "$URL" -D "$BINDDN" -f modyfikacja.ldif

# zmiana hasla:
	ldappasswd -xW -H "$URL" -D "$BINDDN" -S "uid=LOGIN,ou=People,$BASEDN"

# sprawdzenie dzialania hasla:
	ldapsearch -xW -H "$URL" -b "$BASEDN" -D "uid=LOGIN,ou=People,$BASEDN"

# wyszukiwanie:
	ldapsearch -H "$URL" -b "$BASEDN" -x

Przyklad pliku ldif do zakladania uzytkownika:

dn: uid=LOGIN,ou=People,dc=vls,dc=icm,dc=edu,dc=pl
objectClass: ldapPublicKey
objectClass: shadowAccount
objectClass: posixAccount
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
shadowWarning: 10
shadowInactive: 10
shadowMin: 1
shadowMax: 365
shadowLastChange: 14673
homeDirectory: /home/LOGIN
loginShell: /bin/false
uid: LOGIN
cn: IMIE NAZWISKO
uidNumber: 30001
sn: NAZWISKO
givenName: IMIE
mail: ADRES@MAILOWY
gidNumber: 3003
userPassword: {MD5}da4427d9e3dbb96a7fe4053a4bfb21dd

Przyklad pliku ldif do dodania uzytkownika do grupy:

dn: cn=NAZWAGRUPY,ou=Group,dc=vls,dc=icm,dc=edu,dc=pl
changetype: modify
add: memberUid
memberUid: LOGIN

Klienci bazy LDAP

Autoryzacja kont systemowych w LDAP z użyciem PAM i NSS

W przypadku korzystania z LDAP do autoryzacji użytkowników systemowych wymagane jest umieszczenie odpowiedniej konfiguracji (wskazującego źródło informacji autoryzacyjnych LDAP) w plikach /etc/nss-ldapd.conf (lub /etc/libnss-ldap.conf) oraz /etc/pam_ldap.conf. Jako że pliki te są łudząco podobne do siebie należy uważać aby nie powstawały rozbieżności między nimi - niespójność danych w tych plikach grodzi dziwnymi i trudnymi do diagnozowania błędami) oraz odpowiedniej konfiguracji samego pam w plikach /etc/pam.d/* np:

account    required     pam_ldap.so
auth       sufficient   pam_ldap.so use_first_pass
password   sufficient   pam_ldap.so use_first_pass

session    optional     pam_ldap.so

Konfiguracja krok po kroku:

  1. aptitude install libnss-ldapd libpam-ldap
  2. w trakcie konfiguracji podajemy (dwu krotnie - osobno dla nss i osobno dla pam) poprawny URI serwera LDAP oraz bazowe DN dla wyszukiwania (zwyczajowo jest to nasza domena zapisywana w postaci kolejnych dc= składających się z kolejnych członów domeny rozdzielanych kroplami - np. dla subdomena.example.net będzie to dc=subdomena,dc=example,dc=net)
    aby nie musieć podawać danych autoryzacyjnych LDAP (gdy nasz serwer odpowiada na niezautoryzowane zapytania) na pytania o zezwolenie lokalnemu root'owi na dostęp administracyjny oraz o to czy LDAP wymaga autoryzacji odpowiadamy przecząco
  3. W tym momencie komenda grep -v '^#' /etc/*ldap*.conf | grep -v '^[^:]*:$' powinna zwracać coś na kształt:
    /etc/nss-ldapd.conf:uid nslcd
    /etc/nss-ldapd.conf:gid nslcd
    /etc/nss-ldapd.conf:uri ldap://mojserwerldap/
    /etc/nss-ldapd.conf:base dc=subdomena,dc=example,dc=net
    /etc/pam_ldap.conf:base dc=subdomena,dc=example,dc=net
    /etc/pam_ldap.conf:uri ldap://mojserwerldap/
    /etc/pam_ldap.conf:ldap_version 3
    /etc/pam_ldap.conf:pam_password crypt
    Polecam także dodanie do pliku /etc/pam_ldap.conf ograniczenia czasu oczekiwania na odpowiedź serwera LDAP:
    timelimit 10
    bind_timelimit 10
    bind_policy soft
  4. W przypadku nowszych systemów odpowiadamy na pytania dotyczące modyfikacji konfiguracji PAM aby używać autoryzacji UNIXowej i LDAP w przypadku starszych samodzielnie modyfikujemy pliki /etc/pam.d/common-*:
    • common-account zastępujemy następującą zawartością:
      account [success=2 new_authtok_reqd=done default=ignore]        pam_unix.so
      account [success=1 default=ignore]      pam_ldap.so
      account requisite                       pam_deny.so
      account required                        pam_permit.so
      account required                        pam_access.so
    • common-auth zastępujemy następującą zawartością:
      auth    [success=2 default=ignore]      pam_unix.so nullok_secure
      auth    [success=1 default=ignore]      pam_ldap.so use_first_pass
      auth    requisite                       pam_deny.so
      auth    required                        pam_permit.so
    • w common-password dodajemy:
      password    sufficient    pam_ldap.so
      password    required      pam_deny.so
    • w common-session dodajemy:
      session     required      pam_limits.so
      session     optional      pam_ldap.so
      Opcjonalnie możemy dodać session required pam_mkhomedir.so skel=/etc/skel umask=0022 aby automatycznie tworzyć katalogi domowe
  5. Wpisy ldap przy wybranych przez nas pozycjach w /etc/nsswitch.conf powinny zostać dodane automatycznie, jeżeli nie robimy to ręcznie.
  6. W /etc/security/access.conf umieszczamy wpis ograniczający prawo logowania do użytkowników znajdujących się w podanych grupach: -:ALL EXCEPT root grupaA grupaB:ALL EXCEPT LOCAL

Klucze publiczne SSH z LDAP

W przypadku korzystania z SSH dostęp w oparciu o hasło PAMowe to nie wszystko. Wielu użytkowników wręcz preferuje dostęp oparty o klucze publiczne SSH przechowywane standardowo w $HOME/.ssh/authorized_keys. Kuszącym jest możliwość umieszczania tych kluczy również w bazie LDAP (dotyczy to zwłaszcza systemów mających centralną autoryzacje opartą o LDAP, a nie mających wspólnego /home). Istnieje stosowny patch do serwera SSH umożliwiający taką integrację - openssh-lpk. Niestety w chwili obecnej nie jest on włączony ani do samego serwera OpenSSH ani do paczki Debianowej, zatem konieczne jest jego samodzielne nałożenie. W tym celu:

aptitude install devscripts libldap-dev
aptitude build-dep openssh-server

svn checkout http://openssh-lpk.googlecode.com/svn/trunk/ openssh-lpk-read-only
apt-get source openssh-server

cd openssh-5.1p1/
# dodac w debian/rules w okolicy innych confflags:
# confflags += --with-libs="-lldap" --with-ldflags="-L/usr/lib" --with-cppflags="-I/usr/include -DWITH_LDAP_PUBKEY"
vi debian/rules

patch -p1 < ../openssh-lpk-read-only/patch/contrib/contrib-openssh-lpk-5.1p1-0.3.10.patch
debchange -i "openssh-lpk path"
dpkg-buildpackage -rfakeroot

Użycie patcha sprowadza się do dodania do /etc/ssh/sshd_config:

UseLPK yes
LpkLdapConf /etc/pam_ldap.conf
LpkForceTLS no

Po stronie serwera LDAP konieczne jest pobranie i zainstalowanie odpowiedniego schema:

cd /etc/ldap/schema && wget http://openssh-lpk.googlecode.com/files/openssh-lpk_openldap.schema
echo "include         /etc/ldap/schema/openssh-lpk_openldap.schema" >> /etc/ldap/slapd.conf
/etc/init.d/slapd restart

Autoryzacja HTTP w Apache2 w oparciu o LDAP

Aby Apache2 mógł autoryzować dostęp w oparciu o LDAP konieczne jest włączenie stosownych modułów (poprzez utworzenie dowiązań do odpowiednich plików z /etc/apache2/mods-available/ w /etc/apache2/mods-enabled/: auth_basic, authn_file, authnz_ldap, authz_default, authz_groupfile, authz_host i authz_user

Następnie do ogólnej konfiguracji można dodać opcje takie jak:

LDAPSharedCacheSize 500000
LDAPCacheEntries 1024
LDAPCacheTTL 600
LDAPOpCacheEntries 1024
LDAPOpCacheTTL 600
		
<Location /ldap-status>
	SetHandler ldap-status
	Order deny,allow
	Deny from All
	Allow from 127.0.0.1
</Location>

Natomiast samą autoryzację włączmy wpisem typu:

<Directory /var/www/tajne_dane>
	AuthType Basic
	AuthName "Sorry - autoryzacja LDAP"
	AuthBasicProvider ldap
	AuthLDAPURL ldap://adres.naszego.serwera.ldap/ou=People,dc=subdomena,dc=example,dc=net?uid
	# ?uid oznacza w powyzszym że login jest w polu bazy LDAP o nazwie uid
	
	# możemy wymagać tylko posiadania konta w LDAPie:
	#Require valid-user
	
	# lub członkowstwa w podanej grupie (w tym wypadku wwwACL):
	Require ldap-group cn=wwwACL,ou=Group,dc=subdomena,dc=example,dc=net
	AuthLDAPGroupAttribute memberUid
	AuthLDAPGroupAttributeIsDN off
</Directory>

Autoryzacja w MediaWiki

Aby MediaWiki korzystało do autoryzacji użytkowników z bazy LDAP należy w LocalSettings.php umieścić wpisy:

require_once( "/usr/share/mediawiki-extensions/LdapAuthentication.php" );
$wgAuth = new LdapAuthenticationPlugin();

// podstawowa konfiguracja
$wgLDAPDomainNames = array( "JakasNazwaGrupyAutoryzacyjnej" );
$wgLDAPServerNames = array( "JakasNazwaGrupyAutoryzacyjnej" => "adres.naszegoserwera" );
$wgLDAPBaseDNs = array( "JakasNazwaGrupyAutoryzacyjnej"=>"dc=subdomena,dc=example,dc=net" );
$wgLDAPSearchStrings = array( "JakasNazwaGrupyAutoryzacyjnej" => "uid=USER-NAME,ou=people,dc=subdomena,dc=example,dc=net" );
$wgLDAPEncryptionType = array( "JakasNazwaGrupyAutoryzacyjnej"=>"clear" );

// wymog czlonkowstwa w grupie
$wgLDAPRequiredGroups = array( "JakasNazwaGrupyAutoryzacyjnej"=>array("cn=wikiACL,ou=group,dc=subdomena,dc=example,dc=net") );
$wgLDAPGroupObjectclass = array( "JakasNazwaGrupyAutoryzacyjnej"=>"posixGroup" );
$wgLDAPLowerCaseUsername = array( "JakasNazwaGrupyAutoryzacyjnej"=>"true" );
$wgLDAPGroupAttribute = array( "JakasNazwaGrupyAutoryzacyjnej"=>"memberUid" );
//$wgLDAPGroupNameAttribute = array( "JakasNazwaGrupyAutoryzacyjnej"=>"cn" );
//$wgLDAPGroupUseFullDN = array( "JakasNazwaGrupyAutoryzacyjnej"=>false );
//$wgLDAPGroupSearchNestedGroups = array( "JakasNazwaGrupyAutoryzacyjnej"=>false );

Autoryzacja użytkowników Mantis'a w oparciu o LDAP

w Konfiguracji Mantisa w pliku config_local.php:

$g_send_reset_password = OFF;
$g_allow_signup = OFF;
	
$g_login_method = LDAP;
$g_ldap_protocol_version = 3;
$g_ldap_server = 'ldap://adres.naszego.serwera.ldap';
$g_ldap_port = '389';
#$g_ldap_bind_dn = 'cn=admin,dc=subdomena,dc=example,dc=net';
#$g_ldap_bind_passwd = 'root';
	
$g_ldap_root_dn = 'ou=People,dc=subdomena,dc=example,dc=net';
$g_ldap_group_dn = 'cn=mantisACL,ou=group,dc=subdomena,dc=example,dc=net';
#$t_ldap_memberuid_field
#$g_ldap_organization = '';
#$g_ldap_uid_field = 'uid';

Aby mantis automatycznie tworzył (swoje) konta dla użytkowników autoryzowanych w oparciu o LDAP konieczne jest zaaplikowanie łaty mojego autorstwa dostępnej jako załącznik do stosownego zgłoszenia - 0011470: auto-create mantis account for LDAP users - MantisBT. Jest to niezbędne aby użytkownicy LDAPowi mieli dostęp do mantisa bez ręcznego zakładania dla nich kont w Mantisie.

Aby działała autoryzacja w oparciu o grupie konieczne jest zaaplikowanie łaty mojego autorstwa dostępnej jako załącznik do stosownego zgłoszenia - 0011488: LDAP group based autentication - MantisBT. Alternatywnym rozwiązaniem jest 0008471: Add feature to check required LDAP attribute for authentication - MantisBT.

LDAP password change on web page

Jest to prosty skrypt umożliwiający zmianę hasła LDAPowego przy pomocy strony WWW.

POBIERZ

Tworzenie "instalacji" postgres'a

Niekiedy potrzebujemy utworzenia dodatkowej instancji bazy danych postgres. w tym celu należy:

  1. utworzyć użytkownika (user-db) który będzie penem i władcą tej instancji bazy danych
  2. utworzyć katalog (/var/postgres-mydb) w którym będziemy trzymali naszą bazę, jego właścicielem musi być user-db
  3. zainicjalizować bazę w tym katalogu komendą initdb (uruchomioną z pod user-db - tak samo będzie nazywał się użytkownik mający prawa administracyjne w naszej nowej bazie danych)
  4. uruchomić jako user-db postgres'a postgres -D /var/postgres-mydb lub pg_ctl -D /var/postgres-mydb -l logfile start
  5. bazy danych i użytkowników może tworzyć user-db poprzez wywołania komend createdb i createuser

Do wykonywania zapytań SQLowych może posłużyć narzędzie psql. Warto w nim zwócić uwagę na komendy \l i \d listujące odpowiednio bazy danych oraz tabele w aktualnej bazie danych (więcej informacji \?). Do kasowania użytkowinów i baz służą komendy dropuser i dropdb. Jeżeli mamy problem z kasowaniem bazy z powodu używania przez innego usera (ERROR: database ... is being accessed by other users) przydatne może się okazać wyświetlenie aktywności na tej bazie poprzez zapytanie SQLowe: select * from pg_stat_activity where datname='NAZWABAZY';

IPMI

IPMI jest specyfikacją komunikacji systemu zarządzającego sprzętem z interfejsem administracyjnym. Aby korzystać z pod Linuxa z dobrodziejstw tego wynalazku należy posiadać płytę główną (ew. inne urządzenie) wspierające ten protokół oraz zainstalować OpenIPMI i ipmitool. IPMI umożliwia m.in. (zdalny) podgląd informacji z sensorów, wyłączenie, włączenie czy też reset zasilania, a także zdalny dostęp do konsoli.

Lokalne używanie ipmi wymaga załadowania modułów ipmi_devintf i ipmi_si, zainstalowania wspomnianego openipmi oraz połączenia się przy pomocy komendy ipmitool -I open -H 192.168.0.102 shell. Możemy wtedy dokonać konfiguracji dostępu sieciowego:

# w testowanej płycie były dwie karty sieciowe z których mógł korzystać IPMI
# - identyfikowane w nim jako interfejsy 6 i 7
lan set 6 ipaddr 192.168.0.100
lan set 6 netmask 255.255.0.0
lan set 6 ipsrc static
lan set 6 auth ADMIN PASSWORD
lan set 6 auth OPERATOR PASSWORD
lan set 6 auth USER PASSWORD
lan set 6 auth CALLBACK PASSWORD
lan set 6 user
lan set 6 password NASZE_TAJNE_HASLO
lan set 6 access on
lan set 6 vlan id off
lan set 6 macaddr MAC:adres:karty:z:IPMI
isol set enabled true
isol set bit-rate 115.2
# u mnie poniższa opcja nie chciała zadziałać, ale da się to obejść
lan set 6 arp respond on

Następnie możemy połączyć się zdalnie do IPMI przy pomocy ipmitool -I lan -H 192.168.0.100 shell lub do konsoli wystawionej na port szeregowy (w wypadku testowanego sprzętu był to /dev/ttyS1, ponadto wymagał użycia starszego trybu isol zamiast sol) - ipmitool -I lan -H 192.168.0.100 isol activate. Testowana płyta (SE7501WV2) posiadała także w biosie opcje przekierowania konsoli na port szeregowy (w odróżnieniu od innej testowanej płyty bez IPMI) ta przekierowywała też gruba więc wystarczyło wystawić jądro i getty. Zobacz w Sieci: Howto setup IPMI under Linux (Debian / Sarge) on the Intel SR2300 Server Chassis (Intel Server Board SE7501WV2) (uwaga od czasu powstania tamtego artykułu trochę się zmieniło - ipmitool obsługuje isol, inne nazwy modułów).

IPMI możemy wykorzystać także lokalnie - np. do monitoringu temperatury (niekiedy daje lepsze wyniki niż lmsensors czy tez mbmon). Prezentuje przykład prostego skryptu który w przypadku wykrycia zbyt wysokiej temperatury wysyła powiadomnienie i dokonuje (dość brutalnego) wyłączenia maszyny:

IPMI_INFO=`ipmitool -I open sdr`

date +%T >> /var/log/temperature_`date +%F`
echo "$IPMI_INFO" | grep Temp >> /var/log/temperature_`date +%F`

echo "$IPMI_INFO" | awk '
	BEGIN {
		ret_code=0
	}
	$1=="CPU" && $3=="Temp" && $5 > 68 {
		if ($5 < 200) {ret_code=12; exit 12} else {ret_code=11}
	}
	END {
		exit ret_code
	}
'
SHUTDOWN=$?

if [ $SHUTDOWN -ge 11  ]; then
	sendEmail -f "root@$HOSTNAME" -t admin@email.adress \
		-u "SHUTDOWN INFO from `hostname`" -m "$IPMI_INFO" \
		-s nasz.serwer.smt.puszczajacy.beze.autoryzacji.i.greylist
	if [ $SHUTDOWN -ge 12  ]; then
		ipmitool -I open power off
	fi
fi

Warto także zwrócić uwagę na alternatywną implementację protokołu IPMI - freeipmi.

nie tylko IPMI

IPMI nie jest jedynym interfejsem systememów zarządzania sprzętem. W sererach SUNowskich możemy spotakać także różne *LOMy, poniżej porównanie naistotniejszych funkcji poszczególnych systemów obsługi service procesora:

działanie IPMI v1.5 Service Processor ELOM ILOM ALOM
uruchamianie konsoli platform console start /SP/AgentInfo/console start /SP/console console oraz consolehistory
wychodzenie z konsoli (rozłączanie) Ctrl+E c . Esc ( Esc ( # .
zasilanie platform set power state set /SP/SystemInfo/CtrlInfo PowerCtrl=on | gracefulloff | forceoff | reset | BIOSSetup stop -force /SYS poweron | poweroff | reset
pomoc help oraz dodanie do komendy -h lub --help help [komenda] help [komenda] help [komenda]
uwagi konsola często źle znosi reset systemu zlecony z SP (należy ją odpalić ponownie)

W przypadku ILOM w wersji 1 i 2 możliwe jest zalogowanie się do bash'owej powłoki z użyciem ssh sunservice@ilom.adres oraz hasła użytkownika root. Umożliwia to m.in. zrestartowanie ILOMu gdy restart /SP odmawia współpracy.

Puppet czyli centralne zarządzanie

Gdy administrujemy wieloma (zwłaszcza podobnymi) systemami uciąliwe staje się wprowadzanie takich samych bądź podobnych zmian w dziesiątkach (jak nie więcej) plików. Dużym ułatwieniem może okazać się (gdy już przebijemy się przez jego konfigurację) system puppet który umożliwia m.in. rozsyłanie plików konfiguracyjnych, generowanie ich w oparciu o szablony, edycję konfiguracji na zdalnym serwerze z użyciem augeas (augtool), instalację oprogramowania i wiele innych.

Typowo na konfigurację składają się:

Zobacz też przykładowe moduły puppet'a w dziale "archiwum"

Monit

Istonym zaganieniem jest kontrola działania usług i podejmowanie akcji gdy coś nie działa. Pomocnym w tym może być monit. Umożliwia on wysyłanie powiadomien, wykonanie restartu niedziałającej usługi, itd.

Dobrym pomysłem wydaje się pozostawienie /etc/monit/monitrc bez zmian i umieszczenie całości konfiguracji w /etc/monit/conf.d/. Pliki są includowane wg kolejności nazw zatem np. w /etc/monit/conf.d/000_global.conf należy umieścić konfigurację podstawową:

set daemon 120 with start delay 60
set eventqueue basedir /var/monit slots 100
set logfile syslog facility log_daemon

set mailserver primary.mailserwer, secondary.mailserwer, localhost
set alert adres@mailowy.uzywany.do.powiadomien
set mail-format {
  from: monit@nazwa.monitorowanego.hsta
  subject: [$HOST] monit alert -- $EVENT $SERVICE
}

set httpd port 2812 use address localhost allow localhost

W kolejnych plikach mozemy umieścić monitorowanie stanu systemu:

check system nazwa.monitorowanego.hsta
  group system
  if loadavg (1min) > 6 then alert
  if loadavg (5min) > 4 then alert
  if memory usage > 95% then alert
  if cpu usage (user)   > 90% then alert
  if cpu usage (system) > 50% then alert
  if cpu usage (wait)   > 35% then alert

oraz monitorowanie poszczególnych usług - np.:

check process cron with pidfile /var/run/crond.pid
  group system
  start program = "/etc/init.d/cron start"
  stop  program = "/etc/init.d/cron stop"
  if 5 restarts within 5 cycles then timeout

Dane o stanie usług prezentowane są na www (w powyższym przykłądzie port 2812). Przy pomocy prostego skryptu można je zebrać w jedn spójny system

Fail2ban - odpieranie ataków siłowych

Częstym problemem (zwłaszcza w ssh) jest znaczna liczba (często realizowanych przez kiepskie boty) ataków siłowych. Wygodnym narzędziem do zabezpieczenia się przed nimi jest fail2ban. Jego działanie polega na analizowaniu wskazanego logu, wychwytywaniu prób ataku w oparciu o zadane kryteria i dodawaniu do firewala systemowego własnych regułek. W przypadku Linuxa fail2ban dodaje je do własnego łańcucha iptables regułek blokujących (łańcuch ten jest wstawiany na samym początku reguł). Przykładowa konfiguracja. Podobnym, ale trochę mniej konfigurowalnym (za to wspierającym IPv6) narzędziem jest sshguard.

Logi systemowe - syslog-ng i logrotate

Kuszącą wizją jest zbieranie logów z wszystkich usług poprzez jeden program, który umożliwiłby ich zapisywanie czy też przesyłanie do zdalnej maszyny. Jest to możliwe z wykorzystaniem odpowiedniej konfiguracji usług (problemem mogą być "młode usługi" jak voip czy xmpp) i np. syslog-ng. Zamieszczam przykładową konfigurację dla syslog-ng oraz stosowny plik konfiguracyjny dla logrotate (należy umieścić go w /etc/logrotate.d/ i usunąć lub zmodyfikować z tamtąd pliki które obsługiwałyby te same logi)

Konfiguracja większości usług do korzystania z logowania przez syslog zaprezentowana jest wraz z opisami tych usług (głównie w Konfiguracja serwerów sieciowych), poniżej prezentuję uwagi konfiguracyjne dotyczące oprogramowania tam nie opisanego:

Usługi wysokiej dostępności

Nierzadko mamy doczynienia z koniecznością zapewnienia (niemal) bezprzerwowej dostępności jakiejś usługi (np. serwera www). Z pomocą przychodzi nam tutaj oprogramowanie takie jak heartbeat, czy też nawet cały openais wraz z innymi narzędziami takimi jak ctdb, drbd8-utils (klastrowa baza danych tymczasowych oraz raid1 over tcp/ip).

Zasada działania heartbeat polega na kontrolowaniu działania hosta (poprzez komunikację z swoim klientem) i w przypadku wykrycia padu tamtego hosta automatycznym uruchomieniu odpowiednich usług (i przeniesieniu adresu) na inny host.



Copyright (c) 1999-2015, Robert Paciorek (http://www.opcode.eu.org/), BSD/MIT-type license


Redystrybucja wersji źródłowych i wynikowych, po lub bez dokonywania modyfikacji JEST DOZWOLONA, pod warunkiem zachowania niniejszej informacji o prawach autorskich. Autor NIE ponosi JAKIEJKOLWIEK odpowiedzialności za skutki użytkowania tego dokumentu/programu oraz za wykorzystanie zawartych tu informacji.

This text/program is free document/software. Redistribution and use in source and binary forms, with or without modification, ARE PERMITTED provided save this copyright notice. This document/program is distributed WITHOUT any warranty, use at YOUR own risk.

Valid XHTML 1.1 Dokument ten (URL: http://www.opcode.eu.org/usage_and_config/operating_systems_config/servers) należy do serwisu OpCode. Autorem tej strony jest Robert Paciorek, wszelkie uwagi proszę kierować na adres e-mail serwisu: webmaster@opcode.eu.org.
Data ostatniej modyfikacji artykulu: '2015-10-10 11:34:09 (UTC)' (data ta może być zafałszowana niemerytorycznymi modyfikacjami artykułu).