Com\’è dura la professione!

5 marzo 2007

And the winner is … OpenNMS

Filed under: Amministrazione di sistema — lbell @ 23:31

SearchNetworking.com, dopo un sondaggio fra i suoi lettori, ha premiato per il 2007 il pacchetto Open Source OpenNMS come miglior prodotto nella categoria dei monitor di rete, davanti a pietre miliari come Tivoli e OpenView. Poco a poco sembra che l’Open Source stia filtrando nel mondo delle imprese. Per provarlo non c’è nemmeno bisogno di installarlo, basta seguire il link al demo presente sul sito opennms.org. Non farà tutto quello che fa Tivoli, ma il suo lavoro sembra farlo bene.

Link alla notizia:

http://searchnetworking.techtarget.com/productsOfTheYearCategory/0,294802,sid7_tax306257_ayr2007,00.html

 

Annunci

12 dicembre 2006

Recensione di “Integrare Windows e Linux” di Moskowitz e Boutell

Filed under: Amministrazione di sistema,Linux,Microsoft — lbell @ 22:20

ISBN 88-481-1973-5
Autori: Jeremy Moskowitz, Tom Boutell
Anno: 2006
Editrice: tecniche nuove
Come recita il titolo, viene descritto tutto quello che è necessario fare per far coesistere i due sistemi (e non per sostituirne uno con l’altro) in varie aree di utilizzo. Sono indicati chiaramente i passi da svolgere, con tanto di relative schermate, per permettere il login centralizzato in reti miste, per condividere file e stampanti, gli account, la posta e il DNS. Ogni operazione è descritta in dettaglio, sia per quello che riguarda la parte Linux che quella Windows in un modo quasi banale (per chi abbia un minimo di esperienza). Si parla delle tecnologie più avanzate, di Windows Server 2003 ma non del 2003/R2, per il quale si rimanda ad una appendice supplementare scaricabile da internet (dal sito inglese http://www.winlinanswers.com/); d’altronde è il destino dei libri di informatica che trattano di questi argomenti di uscire già vecchi almeno in qualche parte.

Il libro è ricco di dettagli, ovvero quei particolari che fanno la differenza tra avere un sistema funzionante in pratica e non solo in teoria. Si parla sia di come configurare i sistemi Linux per accedere alla controparte Windows, che del caso opposto, mediante la realizzazione di alcuni scenari aziendali mostrando, quando opportuno, anche i limiti degli approcci tra sistemi con modelli di protezione tanto diversi.

Per la mia esperienza comunque si tratta di casi molto più teorici che pratici, esperimenti da eseguire per cultura personale o in previsioni di lavori futuri, dato che in nessun ambiente lavorativo di mia conoscenza nella pratica si usa qualcosa di diverso da Windows e dalle pagine del libro se ne capisce il perché: per ogni argomento, in primis per quello che riguarda l’autenticazione degli utenti ma anche per la gestione della posta (Exchange è una vera killer application), il lavoro per l’amministratore di sistema è veramente ridotto in Windows, dato che realizza una stretta integrazione fra i componenti per quello che riguarda autenticazione e sicurezza dei servizi. Che poi il sistema sia sicuro in assoluto è tutto un altro paio di maniche, come la storia dei virus recenti sta a dimostrare.

15 giugno 2006

Nagios e Snort parte II

Filed under: Amministrazione di sistema,Nagios,Uncategorized — lbell @ 18:32

Dimenticavo: il comando di esempio:


define command {
command_name   check-file-time
    command_line    $USER1$/check_file_time -f "$ARG1$" -l "$SERVICEPERFDATA$"
}
define service {
	use				generic-service
	( ... )
	check_command			check-file-time!/var/ (...) /filelog
}

13 giugno 2006

Nagios e Snort

Filed under: Amministrazione di sistema,Nagios — lbell @ 20:56

Sto iniziando a lavorare sull'integrazione dell'IDS piu' noto (snort) con Nagios. Il problema e' che da snort sarebbe possibile scatenare un comando asincrono di Nagios, ma snort sarebbe bloccato per troppo tempo da questa operazione. Una soluzione può essere quella di far scrivere gli allarmi di snort in alcuni files di log e far controllare da un job schedulato da cron la variazione di data di modifica di tale file. Dato che abbiamo gia' Nagios che svolge egregiamente questo tipo di lavoro, perché non chiamarlo in causa? Dobbiamo solamente creare un semplice plugin che controlli la data di variazione del file di log. Tutto molto semplice, ma questa soluzione ha un difetto: possono venire monitorati solo i files locali o su percorsi accessibili a meno di metter in piedi qualcosa di più complicato. Ecco il codice di esempio del plugin:

#! /bin/sh
#
# check_file_time Copyright (C) 2006 Luca Bellonda <lbell_at_tsc4.com>
#
# This program is free software; you can redistribute it and/or
# modify it under the terms of the GNU General Public License
# as published by the Free Software Foundation; either version 2
# of the License, or (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty
# of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
#
# you should have received a copy of the GNU General Public License
# along with this program (or with Nagios);  if not, write to the
# Free Software Foundation, Inc., 59 Temple Place - Suite 330,
# Boston, MA 02111-1307, USA
# Out: State|LastTime=value;

PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin

PROGNAME=`basename $0`
PROGPATH=`echo $0 | sed -e 's,[/][^/][^/]*$,,'`
REVISION=`echo '$Revision: 1.0 $' | sed -e 's/[^0-9.]//g'`

. $PROGPATH/utils.sh

#DEBUG="1"

print_usage() {
	echo "Usage: $PROGNAME (-f|--filename) file_name (-l|--lasttime)time"
}

print_help() {
	print_revision $PROGNAME $REVISION
	echo ""
	print_usage
	echo ""
	echo "This plugin checks if file modification time differs from last check."
	echo ""
	support
	exit 0
}

esegui_plugin()
{
    #check the command line
    while test $# -gt 0
    do
	case "$1" in
		-l|--lasttime)
			if [ -n "$last_time" ]
			then
				echo "Only one --lasttime argument is used"
                                print_usage
                                exit $STATE_UNKNOWN
			fi
			shift
			last_time="`echo $1|tr "," "|"`"
			last_time="`echo $last_time|cut -d '=' -f 2`"
			;;
		-f|--filename)
			if [ -n "$file_name" ]
			then
				echo "Only one --filename argument is used"
                                print_usage
                                exit $STATE_UNKNOWN
			fi
			shift
			file_name="`echo $1|tr "," "|"`"
			;;
		*)
			echo "Unknown argument $1"
			print_usage
			exit $STATE_UNKNOWN
			;;
	esac
	shift
    done
    #no time -> no work
    #if( test last_time_seen false -eq 0 ) then si puo' fare anche cosi'
    if [ ! -n "$last_time" ]; then
	last_time=0
	#echo "No last time argument"
	#print_usage
	#exit $STATE_UNKNOWN
    fi
    if [ ! -n "$file_name" ]; then
	echo "No file name argument"
	print_usage
	exit $STATE_UNKNOWN
    fi

# do the work
    last_check_time="echo $last_time | cut -d "=" -f 1"
    if [ ! -e "$file_name" ]; then
	echo 'File does not exists|LastTime=0'
	exit $STATE_UNKNOWN
    fi

time_of_actual_check=`stat --format=%Y $file_name`
    if [ "a$time_of_actual_check" != "a$last_time" ]
    then
        echo "ALERT|LastTime=$time_of_actual_check"
	exit $STATE_CRITICAL
    else
	echo "OK|LastTime=$time_of_actual_check"
	exit $STATE_OK
    fi

#echo "Errore generico|LastTime=$time_of_actual_check"
    #exit $STATE_CRITICAL
}

case "$1" in
	--help)
		print_help
		exit 0
		;;
	-h)
		print_help
		exit 0
		;;
	--version)
	   	print_revision $PROGNAME $REVISION
		exit 0
		;;
	-V)
		print_revision $PROGNAME $REVISION
		exit 0
		;;
	*)
		esegui_plugin $@
		exit 0
		;;
esac

17 maggio 2006

Grafici con Nagios

Filed under: Amministrazione di sistema,Nagios — lbell @ 20:05

Il punto debole di Nagios, oltre alla complessità della configurazione beninteso, e' la mancanza di uno storico dei valori quantitativi. E' molto comodo e intuitivo controllare la tendenza dei valori di risposta dei singoli servizi a colpo d'occhio. Ovviamente a questa mancanza si può sopperire con l'ennesimo comando, questa volta non un plugin, ma un filtro. Il progetto che dovremo utilizzare si chiama NagiosGrapher (http://www.nagiosexchange.org/NagiosGrapher.84.0.html) e richiede la presenza di rrd. Sfrutta il meccanismo di eco dei performance data di Nagios per leggere i dati che arrivano dai plugins per passarli ad un servizio che li decodifica e li inserisce in un database rrd in tempo reale; vi sono anche degli scripts che generano un grafico dei valori per le pagine web di amministrazione.

NagiosGrapher consiste in un servizio, che l'amministratore deve far partire, che apre una pipe in lettura. Quando i dati arrivano, li confronta con il proprio file di configurazione per decidere se il dato va memorizzato ed in quale archivio. Non tutti i dati possono quindi essere utilizzati, ma solo quelli che sono formattati secondo la convenzioni indicate dalle linee guida per i plugins. Per far arrivare i dati da Nagios a NagiosGrapher va creato un comando di Nagios utilizzando un applicativo fornito, come script o eseguibile compilato, che ricevendo i dati da Nagios li scrive sulla named pipe aperta da NagiosGrapher.

define command {
command_name   process-service-perfdata
command_line    percorso/fifo_write.pl  percorso/ngraph.pipe '$HOSTNAME$   $SERVICEDESC$ $SERVICEOUTPUT$   $SERVICEPERFDATA$' 3
}

Non rimane che dire a Nagios (in nagios.cfg) di utilizzare il comando appena creato :

process_performance_data=1
service_perfdata_command=process-service-perfdata

Per la verità occorre anche gestire una opportuna configurazione per ogni grafico che si vuole generare, ma questi sono dettagli che potete leggere nella documentazione di NagiosGrapher che invito a leggere.

26 aprile 2006

Monad e’ morto, evviva PowerShell

Filed under: Amministrazione di sistema,Programmazione — lbell @ 19:20

L’uscita imminente della nuova shell Microsoft (Microsoft PowerShell per la precisione) fa fare all’amministrazione dei sistemi Windows un nuovo salto di qualità. L’integrazione con .NET dice molto sulla volontà di utilizzare questa tecnologia nelle nuove piattaforme Microsoft. Un’altra caratteristica riguarda la diversa ottica sotto cui PowerShell puo’ essere vista. Sara’ possibile passare da una shell tradizionale (bash ad esempio) con gestione in modo testo utilizzando una sintassi uniforme anziché utilizzare una miriade di strumenti (awk per esempio) ad una orientata agli oggetti. Molto probabilmente le richieste di RAM saranno come al solito onerose, ma con macchine nuove non sara’ certo un problema. Tuttavia, ad una prima impressione, sembra di vedere all’opera python come shell di sistema.
Link di riferimento: http://blogs.msdn.com/powershell/
Il blog da cui ho ricavato l’evento http://blogs.technet.com/italy/archive/2006/04/26/426430.aspx

20 febbraio 2006

Amministrazione di sistema

Filed under: Amministrazione di sistema — lbell @ 21:42

Un esperimento ci parla di come gli impiegati di banca non abbiano cura della sicurezza. Sarebbe interessante ripetere la prova con altre categorie di lavoratori che in teoria dovrebbero averne più coscienza (Ingegneri in primis). E’ proprio vero, la sicurezza e’ come il silenzio, se ne sente il bisogno solo quando manca. Con buona pace degli amministratori di sistema coscienziosi.

Blog su WordPress.com.