Archivinhalt auflisten – ohne entpacken

Inhalt komplett auflisten:

 tar -tvf MEINTAR.tar.gz

Inhalt auflisten und filtern:

 tar -tvf MEINTAR.tar.gz | grep suchwort

Diese Information ist eine gesunde Basis für die nächsten Schritte

Einzelne Dateien entpacken

Einzelne Datei aus einem TAR entpacken:

 tar -zxvf MEINTAR.tar.gz ordner1/ordner2/datei1.jpg

Einzelne Ordner/Pfade rekursiv aus einem TAR entpacken:

 tar -zxvf MEINTAR.tar.gz ordner1/ordner2/

Richtig flexibel wird das entpacken mit Wildcard-Filtern:

Rekursiv aus TAR mit Wildcard-Filter entpacken:

tar xfv MEINTAR.tar.gz  --wildcards --no-anchored 'settings*'

Einzelne Dateitypen aus TAR mit Wildcard-Filter entpacken:

tar xfv MEINTAR.tar.gz  --wildcards --no-anchored '*.jpg'

Folgendes Mini HowTo zeigt die Vorgehensweise unter Debian Lenny mit einem selbst signierten Zertifikat

Als erstes sollte – sofern notwendig – “submission” freigeschaltet werden. Dazu müssen folgende Zeilen in der master.cf einkommentiert werden:

/etc/postfix/master.cf

submission inet n       -       -       -       -       smtpd
  -o smtpd_enforce_tls=no
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_client_restrictions=permit_sasl_authenticated,reject

Danach legen wir einen neuen Ordner für die benötigten Zertifikate an:

mkdir /etc/postfix/ssl
cd /etc/postfix/ssl

Nun können wir einen privaten RSA Key generieren (2048 Bit)

openssl genrsa -out smtp.key 2048

Weiter gehts mit dem CSR (Certificate Signing Request)

openssl req -new -key smtp.key -out smtp.csr

Die entsprechenden Angaben sollten mehr oder weniger seriös ausgefüllt werden. Funktionsbezogen ist allerdings nur der CN (Common Name). Hier muss der Hostname des Mailservers eingetragen werden – oder ein entsprechender Wildcard (z.B. smtp.beispieldomain.ch oder *.beispieldomain.ch).

Nun können wir unser Zertifikat anlegen (In diesem Beispiel 365 Tage gültig)

openssl x509 -req -days 365 -in smtp.csr -out smtp.cert -signkey smtp.key

Nun ergänzen wir noch die main.cf, oder passen die bereits vorhanden Werte an.

/etc/postfix/main.cf

smtpd_tls_auth_only = no
smtpd_enforce_tls = no
smtpd_tls_security_level = may
smtp_tls_note_starttls_offer = yes
smtpd_tls_cert_file = /etc/postfix/ssl/smtp.cert
smtpd_tls_key_file = /etc/postfix/ssl/smtp.key
smtpd_tls_loglevel = 1
smtpd_tls_received_header = yes
smtpd_tls_session_cache_timeout = 3600s
tls_random_source = dev:/dev/urandom

Mit dem Parameter smtpd_tls_security_level kann bestimmt werden, ob auch unverschlüsselte Verbindungen erlaubt sind. In diesem Beispiel überlassen wir die Entscheidung über eine allfällige Verschlüsselung beim Client und setzten den Wert daher auf “may”.

Der Parameter smtpd_tls_auth_only definiert, ob nur noch mittels TLS Authentifiziert werden kann. Dies ist bei allgemeinen Mailservern nicht unbedingt empfehlenswert, da sich sonst massenhaft relay access denied Fehler ansammeln werden durch eine “fehlgeschlagene” Authentifizierung von “dummen” clients.
Sicherheitstechnisch müsste dieser Wert allerdings defenitiv aktiviert sein.

Danach noch Postfix neu initialisieren – und testen.

postfix reload

Ihre Nachricht hat einige oder alle Empfänger nicht erreicht.
      Betreff:  ***** 
      Gesendet am:      dd.mm.yyyy HH:MM
Folgende(r) Empfänger kann/können nicht erreicht werden:
'*****' am dd.mm.yyyy HH:MM
573 573  
Authentifizierte Verbindungen nicht moeglich. Bitte nutzen Sie den Port 587 oder kontaktieren Sie uns unter 0800 800 800. 
Connexions authentifiees pas possible. Veuillez utiliser le port 587 ou nous appeler au 0800 800 800.
Collegamenti autenticati non possibili. Prego voi uso la porta 587 oppure contattare il numero 0800 800 800.
Authenticated connections not possible. Please use port 587 or contact us on 0800 800 800.

Offenbar hat dieser Schritt bei vielen Providern erheblichen Supportaufwand produziert. Zumindest eröffneten Hostpoint und Cyon Statustickets zu dieser Problematik. Ebenfalls wurde auf der Swinog Mailingliste ordentlich darüber diskutiert.

Offiziell will man dadurch das versenden von Spam über Mailserver ohne Authentifizierung/Verschlüsselung unterbinden (z.B. durch Viren). Ob die entsprechenden Mailserver unter Port 587 (Submission) aber sicherer konfiguriert sind bezweifle ich. Zumal auch hier eine Verschlüsselung (TLS) nicht zwingend erforderlich ist.

Dieser Artikel soll konzeptionell aufzeigen wie Serverseitig eine möglichst ideale Umgebung bereitgestellt werden kann. Die Sicherheit innerhalb von PHP Scripts wird hier nicht behandelt.

Setup
PHP kann grundsätzlich auf 2 Arten installiert/betrieben werden.

• Als Modul eigebunden in den Webserver (z.B. Apache). Somit läuft der PHP-Interpreter sammt seinen Modulen persistent und logischerweis unter demselben User wie der Webserver selbst. Dadurch hat PHP grundsätzlich auch dieselben Rechte wie der Webserver auf dem System. Von PHP erstellte Dateien gehören somit danach auch dem “Webserver” – und nicht dem User. Diese können danach möglicherweise per FTP z.B. nicht gelöscht oder geändert werden.
  Ein paar spezifische Manipulationen an der Konfigurationsdatei php.ini sind pro vHost möglich.

  Diese Variante eignet sich primär für einzelne Webprojekte – auf keinen Fall für Shared Hosting.

• Als CGI. Wenn ein PHP-Script “interpretiert” werden muss – wird dazu ein neuer Prozess gestartet, der zuerst PHP initialisiert, die Module lädt – und dann erst seine Arbeit startet. Defaultmässig läuft die CGI-Variante auch unter dem User des Webservers.
  Der Resourcenverbrauch gegenüber der Modul-Variante ist natürlich massiv höher – da neben dem Overhead durch das starten des Threads die Module nicht geshared werden können.

Auf den ersten Blick hat somit Variante 2 eigentlich nur Nachteile. ABER: Durch zusätzliche Wrapper können die Threads unter dem eigentlichen User des vHosts ausgeführt werden. Hier gibt es aktuell suExec und suPHP. Ersteres simuliert näherungsweise die Modul Variante – da die Threads noch künstlich am Leben erhalten werden können für allfällige weitere Aufgaben. suPHP startet und beendet dagegen den Thread bei jeder “Interpretation”

Pro vhost kann hier eine komplett eigene php.ini verwendet werden – sowie (wenn erwünscht) eine eigene PHP-Versionen. Von PHP erstelle Files gehören danach vHost-User und können problemlos per FTP mutiert werden.

Somit hätte man also Grundsätzlich die “Sicherheit” durch den Thread sichergestellt – und hat eigentlich bereits ansatzweise eine chroot() Umgebung für PHP.

Als Systemadmin hat man durch diese Variante zudem den grossen Vorteil, das sofort ersichtlich ist wem welche Threads gehören.

Konfiguration
Weiter ist die Konfiguration von PHP vorsichtig zu definieren. Folgende Funktionen sollten wirklich nur bei Bedarf aktiviert werden:

• exec()
• passthru()
• system()
• popen()
• ini_set()
• ini_restore()

–>Einzelne Funktionen können gezielt mittels der php.ini gesperrt werden.

open_basedir
Sehr wichtig ist ausserdem das open_basedir. Leider werden die Sicherheitsmassnahmen nicht selten ganz alleine auf diese Einstellung beschränkt. Man muss sich aber bewusst sein dass das open_basedir lediglich für Filehandles berücksichtigt wird – nicht aber für exec, system etc..

safe_mode?
Der safe_mode war ein etwas unglücklicher Ansatz, die PHP Umgebung abzusichern. In der Praxis sind dadurch mehr Probleme als Lösungen entstanden. Da der safe_mode zukünftig wieder komplett wegfällt – sollten wir diesen nicht weiter berücksichtigen.

Kontrolle
Als Anwender kann das PHP-Setup über ein einfaches phpinfo() jederzeit ermittelt werden.

Der Parameter “Server API” zeigt z.B. auf – wie PHP installiert worden ist.

• Apache-Modul: Apache 2.0 Handler
• CGI: CGI/FastCGI

Fazit
PHP als Modul eignet sich primär für Einzelprojekte. Im Shared Hosting Bereich ist diese Variante nur für den Betreiber interressant, da effizient und somit lukrativ. Als Kunde (Shared Hosting) sollten sie eine solche Dienstleistung auf keinen Fall unterstützen.

apt-get install cowsay
ln -s /usr/games/cowsay /usr/bin/cowsay

Das wars eigentlich schon.

Ein erster Test:

cowsay "blog.alonso.ch"

Müsste zu folgendem Resultat führen:

 ________________
< blog.alonso.ch >
 ----------------
        \   ^__^
         \  (oo)\_______
            (__)\       )\/\
                ||----w |
                ||     ||

Unter /usr/share/cowsay/cows/ sind ausserdem diverse Templates vorhanden, welche alternativ über den Parameter -f verwendet werden können.

Ein weiteres Beispiel:

cowsay -f bunny "blog.alonso.ch"

Müsste zu folgendem Resultat führen:

 ________________
< blog.alonso.ch >
 ----------------
  \
   \   \
        \ /\
        ( )
      .( o ).

Natürlich kann die Kuh auch über die Pipe gefüttert werden.

Ein letztes Beispiel:

cat /proc/meminfo | grep MemFree | cowsay -f tux

Müsste zu folgendem Resultat führen:

  ____________________
< MemFree: 369624 kB >
 --------------------
   \
    \
        .--.
       |o_o |
       |:_/ |
      //   \ \
     (|     | )
    /'\_   _/`\
    \___)=(___/

Natürlich kann die Kuh noch viel mehr, siehe Manpage

Für dieses Beispiel haben wir folgende Anforderungen:

• SMS – und E-Mail Alarmierung
• Unterschiedliche Support-Teams pro Host
• Möglichst wenig Aufwand

SMS-Gateway
Der SMS-Versand soll in unserem Fall über den E-Mail2SMS Gateway von eCall (Schweiz) erfolgen. Dazu benötigen wir dort natürlich einen Account und ein Guthaben. Zudem muss dort der “Zugang via E-Mail” freigeschaltet sein und unsere Nagios E-Mailadresse als gültiger Absender eingetragen sein. In diesem Beispiel wollen wir den Empfänger im An-Feld der E-Mail zuweisen (also z.B. +41791234567@sms.ecall.ch).

Konfiguration
Die Nagios-Konfigurationsfiles liegen in unserem Setup unter /etc/nagios3/conf.d. Die bestehenden Files dort löschen wir vorerst. (Natürlich könnten die vorhanden Files auch übernommen und angepasst werden).

cd /etc/nagios3/conf.d/
rm *.cfg

Perioden
Nagios erlaubt es, verschiedene Zeitpläne zu verwalten, damit die Alarmierung z.B. nur während Bürozeiten erfolgt. In unserem Setup benutzen wir diese Möglichkeit allerdings nicht und alarmieren somit 24×7.

/etc/nagios3/conf.d/periods.cfg

###############################################################################
# periods.cfg
###############################################################################
 
# Unfriendly period
define timeperiod{
        timeperiod_name 24x7
        alias           24 Hours A Day, 7 Days A Week
        sunday          00:00-24:00
        monday          00:00-24:00
        tuesday         00:00-24:00
        wednesday       00:00-24:00
        thursday        00:00-24:00
        friday          00:00-24:00
        saturday        00:00-24:00
        }

Kontakte und Kontaktgruppen
Dies sind die Alarmempfänger. Damit unser Setup flexibel und einfach bleibt, arbeiten wir ausschliesslich über Kontaktgruppen. So können später die Alarmempfänger ganz einfach hier in Gruppen ein/ausgetragen werden.

/etc/nagios3/conf.d/contacts.cfg

###############################################################################
# contacts.cfg
###############################################################################
 
# Persons
define contact{
        contact_name                    admin1
        alias                           Your friendly Hostadmin 1
        service_notification_period     24x7
        host_notification_period        24x7
        service_notification_options    w,u,c,r
        host_notification_options       d,r
        service_notification_commands   notify-service-by-email, notify-service-by-sms
        host_notification_commands      notify-host-by-email, notify-host-by-sms
        email                           admin1@mail.tld
        pager                           004179*******@msg.ecall.ch
}
 
 
define contact{
        contact_name                    admin2
        alias                           Your unfriendly Hostadmin 2
        service_notification_period     24x7
        host_notification_period        24x7
        service_notification_options    w,u,c,r
        host_notification_options       d,r
        service_notification_commands   notify-service-by-email, notify-service-by-sms
        host_notification_commands      notify-host-by-email, notify-host-by-sms
        email                           admin2@mail.tld
        pager                           004179*******@msg.ecall.ch
}
 
# Contactgroups
define contactgroup{
        contactgroup_name       staff
        alias                  All SysAdmins
        members                 admin1, admin2
}
 
define contactgroup{
        contactgroup_name       company1
        alias                   Company 1
        members                 admin1
}
 
define contactgroup{
        contactgroup_name       company2
        alias                  Company 2
        members                 admin2
}

Das “Pager” Attribut wird in unserem Fall verwendet, um den SMS-Empfänger einzutragen. In den Kontaktgruppen werden nun jeweils unsere Members eingetragen. Diese werden im entsprechenden Fall ALLE informiert.

Host-Template
Es können verschiedene Host-Templates erfasst werden. Wir verwenden vorerst das Defaultemplate von Nagios weiter

/etc/nagios3/conf.d/template-host.cfg

##############################################################################
# template-host.cfg
##############################################################################
 
define host{
        name                            generic-host
        notifications_enabled           1       ; Host notifications
        event_handler_enabled           1       ; Host event handler
        flap_detection_enabled          1       ; Flap detection
        failure_prediction_enabled      1       ; Failure prediction
        process_perf_data               1       ; Process performance data
        retain_status_information       1       ; Retain status information across program restarts
        retain_nonstatus_information    1       ; Retain non-status information across program restarts
                check_command                   check-host-alive
                max_check_attempts              10
                notification_interval           0
                notification_period             24x7
                notification_options            d,u,r
                contact_groups                  admins
        register                        0
        }

Hosts
Langsam wirds spannend – Wir erfassen unsere Hosts. Die können etntweder mit ihrem Hostnamen oder ihrer IP “adressiert” werden. Über das “use” Attribut wird das Template bestimmt, welches wir verwenden wollen. Wenn erwünscht können für einzelne Hosts auch die Parameter des Templates übersteuert werden.

/etc/nagios3/conf.d/hosts.cfg

##############################################################################
# hosts.cfg
##############################################################################
define host {
        host_name       nagioshost
        alias           mynagios.something.tld
        address         localhost
        use             generic-host
        contact_groups  staff
        }
 
define host {
        host_name       server1
        alias           server1.something.com
        address         xxx.xxx.xxx.xxx
        use             generic-host
        contact_groups  company1
        }
 
define host {
        host_name       server2
        alias           server2.something.com
        address         xxx.xxx.xxx.xxx
        use             generic-host
        contact_groups  company2
        }

Über die contact_groups weisen wir nun die zuständigen Teams direkt dem Host zu. Damit werden danach alle Alarme für den Host und seine Services entsprechend zugestellt.

Hostgruppen
Über die Hostgruppen können Hosts logisch gruppiert werden (Dienst, Funktion..). Natürlich kann ein Host auch in mehreren Gruppen zugeteilt werden.

/etc/nagios3/conf.d/hostgroups.cfg

##############################################################################
# hostgroups.cfg
##############################################################################
define hostgroup {
        hostgroup_name  all
                alias           All Servers
                members         *
        }
 
# Web servers
define hostgroup {
        hostgroup_name  http-servers
                alias           HTTP servers
                members         nagioshost, server1
        }
 
define hostgroup {
        hostgroup_name          https-servers
                alias           HTTPS servers
                members         nagioshost, server2
        }
 
 
# SSh Servers
define hostgroup {
        hostgroup_name  ssh-servers
                alias           SSH servers
                members         server1, server2
        }

Es lohnt sich hier, die Gruppen klever zu bestimmen und einzuteilen.

Dienst-Template
Es können verschiedene Dienst-Templates erfasst werden. Wir verwenden hier bis auf einige Details das Defaultemplate von Nagios weiter

/etc/nagios3/conf.d/template-service.cfg

##############################################################################
# template-service.cfg
##############################################################################
 
define service{
        name                            generic-service
        active_checks_enabled           1       ; Active service checks
        passive_checks_enabled          1       ; Passive service checks
        parallelize_check               1       ; Active service checks should be parallelized (disabling this can lead to major performance problems)
        obsess_over_service             1       ; We should obsess over this service (if necessary)
        check_freshness                 0       ; Default is to NOT check service 'freshness'
        notifications_enabled           1       ; Service notifications 
        event_handler_enabled           1       ; Service event handler 
        flap_detection_enabled          1       ; Flap detection 
        failure_prediction_enabled      1       ; Failure prediction 
        process_perf_data               1       ; Process performance data
        retain_status_information       1       ; Retain status information across program restarts
        retain_nonstatus_information    1       ; Retain non-status information across program restarts
                notification_interval           0               ; Only send notifications on status change by default.
                is_volatile                     0
                check_period                    24x7
                normal_check_interval           5
                retry_check_interval            1
                max_check_attempts              4
                notification_period             24x7
                notification_options            w,u,c,r
        register                        0
        }

Wichtig ist hier, dass KEIN contact/contact_group zugewiesen wird. Dadurch werden diese Informationen vererbt (in unserem Fall vom Host).

Dienste
Als letztes können wir nun noch die zu überwachenden Dienste definieren.

/etc/nagios3/conf.d/services.cfg

###############################################################################
# services.cfg
###############################################################################
define service {
        hostgroup_name                  http-servers
        service_description             HTTP
        check_command                   check_http
        use                             generic-service
        notification_interval           0 ; set > 0 if you want to be renotified
}
 
 
define service {
        hostgroup_name                  https-servers
        service_description             HTTPS
        check_command                   check_https
        use                             generic-service
        notification_interval           0 ; set > 0 if you want to be renotified
}
 
define service {
        hostgroup_name                  ssh-servers
        service_description             SSH
        check_command                   check_ssh
        use                             generic-service
        notification_interval           0 ; set > 0 if you want to be renotified
}

Die Dienste werden idealerweise an Hostgruppen zugewiesen, da dies die Administration erleichtert. So können z.B. für Hostgruppen gleich mehrere Dienste überwacht werden.

Natürlich können auch unzählige weitere Dienste überwachen oder gar eigene Plugins schreiben. Die Nagios Dokumentation hilft weiter

Eigene Befehle (commands)
Als letztes müssen wir noch die beiden neuen Commands (notify-host-by-sms, notify-service-by-sms) eintragen. Die bestehenden commands dürfen/müssen natürlich weiter existieren.

/etc/nagios3/commands.cfg

...
# host 'notify-host-by-sms' command definition
define command{
        command_name    notify-host-by-sms
        command_line    /usr/bin/printf "%b" "\nHost: $HOSTNAME$\nState: $HOSTSTATE$\nDate/Time: $LONGDATETIME$\n" | /usr/bin/mail -s "** NAGIOS **" $CONTACTPAGER$
        }
 
# 'notify-service-by-sms' command definition
define command{
        command_name    notify-service-by-sms
        command_line    /usr/bin/printf "%b" "\nHost: $HOSTALIAS$\nService: $SERVICEDESC$\nState: $SERVICESTATE$\nDate/Time: $LONGDATETIME$" | /usr/bin/mail -s "** NAGIOS **" $CONTACTPAGER$
        }
..

Dies ist gleichzeitig das Nachrichtentemplate, welches natürlich beliebig ergänzt werden kann. Mein Beispiel ist so definiert dass die 160 Zeichen möglichst nicht überschritten werden.

Nagios neu starten
Damit unsere Konfiguration übernommen wird, muss Nagios neu gestartet werden

/etc/init.d/nagios3 restart

(Allfällige Fehler in der Konfiguration werden direkt beim Start von Nagios auf die Shell zurückgemeldet)

Gemäss 20min war das Konzert prompt nach 12 Minuten ausverkauft. Lediglich über den AC/DC Fanclub waren noch bis am Mittag Tickets erhältlich, allerdings gegen 40$ Clubbeitrag und zu leicht höheren Tarifen als beim Ticketcorner. Diese Tickets konnten über einen vom Club generierten “presale access code” bei etix gekauft werden. Zugestellt werden diese Tickets dann allerdings erst ~2 Wochen vor dem Konzert.

Ebenfalls traditionell sind nun viele Tickets auf diversen Plattformen zu unglaublichen Preisen zu erwerben – auch solche aus dem Fanclub-Angebot. Offenbar haben aber viele “Tickethändler” es verpasst, die Bestimmungen von etix vorher zu lesen:

PLEASE BE AWARE OF THE FOLLOWING:

This ticket is a revocable license. Any violation of law while attending this event may result in holder being removed from the premises without refund of any portion of the ticket price or charges. The holder of this ticket voluntarily assumes all risks of property loss and personal injury arising during its use whether prior to, during, or after the event and agrees that etix.com, the venue, its management and affiliates of the event are not liable under any theory whatsoever. This ticket is non-transferable. Any transfer, attempted transfer, resale, counterfeit, or unauthorized copy is grounds for seizure from and/or cancellation without refund. Tickets obtained from an unauthorized source may be stolen, copied illegally, counterfeit or lost and if so, may be seized and cancelled without compensation. There are no refunds or exchanges. Event dates, times and locations are subject to change. etix.com reserves the right to change this information without notification.

Kurz zusammengefasst:
Diese Ticket werden durch den Weiterverkauf streng betrachtet wertlos – natürlich ohne Rückerstattung. Halt ein Ticket für den echten Fan – und nicht für den “Schwarzmarkt”.

Seien sie also vorsichtig wenn sie Tickets auf dem “Schwarzmarkt” kaufen wollen.

Stellt sich die Frage, wie man dem Schwarzmarkt grundsätzlich entgegen wirken könnte?
Wieso stellt der Ticketcorner für solche Events eigentlich nicht eine eigene Auktionsplattform bereit? Das würde den Ansturm drastisch reduzieren, und vermutlich auch weitgehend den Schwarzmarkt ausbremsen – da kaum jedes der 40’000 Tickets ein mehrfaches über seinem Wert gehandelt würde. Ausserdem hätten auch die Leute morgens um 08:00 Uhr arbeiten müssen eine faire Chance “offizielle” Tickets zu erwerben.

Das zusätzlich eingebrachte Geld könnte sicherlich auch noch irgendwie sinnvoll investiert werden..

Lassen sie sich überraschen:  http://www.whattheinternetknowsaboutyou.com

Einen kriminellen Nutzen davon gibt es kaum, viel spannender dürfte sowas allerdings für Werbezwecke sein. Dennoch sind es “ihre” Daten – und sollten es auch bleiben.

Bei Mozilla ist diese Problematik längst bekannt, wie folgende 2 Tickets bestätigen:

Ticket #57351, bzw. Ticket #147777

Für den Firefox gibt es aktuell folgende Gegenmassnahme:

Installieren sie das Add-On “Link Status”

Danach bei den Extras->Add-Ons->Linkstatus:Einstellungen”Bereits besuchte Links nicht stilisieren” markieren und bestätigen:

Das war’s

Die Anforderungen:

1. Betriebsfähiges Debian Lenny (32 oder 64Bit) mit intaktem Netzwerksetup
2. Konsole oder SSH Zugang mit Root-Account
3. ca. 200MB freier Speicherplatz (/usr, /var)
4. Texteditor (z.B. vim)

Die Installation kann direkt über die Packete aus dem Repository gestartet werden:

apt-get install nagios3 apache2

(Durch die Packetabhängigkeiten werden alle notwendigen Packete automatisch mitinstalliert)

Damit ist schon ein beachtlicher Teil der Installation erledigt. Nun braucht es noch ein paar kleine Anpassungen.

Die Nagios-Konfiguration ist weitgehend unter /etc/nagios3 zu finden. Dort brauchen wir als erstes nun einen gültigen User für die HTTP-Autentifizierung.

cd /etc/nagios3
htpasswd -c htpasswd.users IHRBENUTZERNAME

Danach wird das Passwort abgefragt. Mit diese Kombination aus User/Passwort können wir uns anschliessend auf unserer Nagios-Installation anmelden.

Als nächstes sollten wir nun die external commands aktivieren. Dadurch können wir direkt über Weboberfläche die Alarmierung aktivieren/deaktivieren.

Dazu bearbeiten wir die nagios.cfg:

vi /etc/nagios3/nagios.cfg

Dort suchen wir uns folgende Zeile:

check_external_commands=0

Diese aktivieren wir durch ändern dieses Wertes auf 1:

check_external_commands=1

Danach müssen noch die Berechtigungen auf dem Filesystem angepasst werden, wa wir sonst diesen Fehler erhalten:

Error: Could not stat() command file '/var/lib/nagios3/rw/nagios.cmd'!

Dies können wir relativ einfach beheben durch:

touch /var/lib/nagios3/rw/nagios.cmd
dpkg-statoverride --update --add nagios www-data 2710 /var/lib/nagios3/rw
dpkg-statoverride --update --add nagios nagios 751 /var/lib/nagios3
/etc/init.d/nagios3 restart

Das wars. Nun sollten sie unter http://NAGIOSIP/nagios3 auf ihr soeben installiertes Nagios zugreiffen können.

Natürlich braucht unser Nagios danach noch eine Konfiguration.