Com\’è dura la professione!

28 giugno 2006

Linux su MacBook

Filed under: Mac — lbell @ 18:44

Come installare Linux sul nuovo MacBook con cuore Intel senza paura di perdere il disco di sistema? Dopo avere provato a partizionare il LinuxOnMacBookdisco con bootcamp ed installare con successo alcune distribuzioni oltre ad avere utilizzato vari CD live, mi sono scontrato con il problema di installare un boot loader senza rischiare di perdere la tabella di partizione del disco. Un primo ricorso ricorso al disco di emergenza per ripristinare il boot con MacOS mi ha fatto realizzare che non volevo, come risultato di una manovra poco accorta, realmente reinstallare i 10 giga di software Apple in dotazione. Ho provato parallels e l’ho trovato di una semplicità disarmante: permette oltretutto di utilizzare Linux ( o Windows, se credete ) assieme a MacOS a velocità pressoche’ piena. L’ho utilizzato anche per fare il boot da una immagine ISO di un live CD e devo dire che funziona in modo egregio, anche se una volta ha inchiodato MacOS con un problema su di una macchina virtuale Windows (scherzi del destino o puro caso?). Il vantaggio rispetto ad una installazione reale di Linux sta anche nell’evitare di partizionare il disco, bastando un file per contenere il disco virtuale del sistema ospite. L’unico vero problema e’ che la RAM in dotazione nel modello di base e’ poca per far funzionare agevolemente una macchina virtuale.

18 giugno 2006

Magnetismo animale

Filed under: Programmazione — lbell @ 20:54

Il nuovo MacBook ha un sistema di chiusura a magnete. Niente più incastri, perfino il cavo di alimentazione e' ancorato con un magnete. La cosa che lascia perplessi e' vedere le graffette di metallo che si attaccano al case. Viene immediatamente da pensare al disco esterno o alle chiavette USB che si infilano nelle borsa assieme al portatile quando ci si reca dal cliente, la vicinanza con questi magneti non sara' un problema? D'altronde, ricordando il NeXT, le macchine di Jobs sono cosi': capolavori di ingegneria con un particolare aggiunto per strafare che stona.

15 giugno 2006

Stanchi di patchare il vostro sistema?

Filed under: Open Source,Programmazione — lbell @ 20:33

Parto da questo link http://blogs.23.nu/ilja/stories/12093/ in cui si parla di quali programmatori dovrebbero evitare di scrivere codice di una certa rilevanza dato il numero di buchi pericolosi che 'nascono' nelle loro opere e soprattutto dal fatto che ogni giorno che arriva in terra devo controllare quali patches sono uscite per le macchine che gestisco. Il problema secondo me sta soprattutto nei linguaggi di programmazione, che ora come ora inducono facilmente in errore i programmatori. Una gran parte dei problemi di sicurezza deriva dai buffer overflow e non da ieri. Sono anni che ci trasciniamo questa piaga senza poterla sradicare. Il fatto e' che il linguaggio utilizzato per scrivere i componenti di sistema e tutti i servizi piu' importanti ( web server, mail, server LDAP, database, linguaggi script ) e' il C.

Questa passione per il C, linguaggio universale, se poteva essere giustificata da macchine con risorse limitate di memoria e velocità oggi non ha più nessuna ragione di essere. Ditte e programmatori necessitano di strumenti che li possano far concentrare sulla risoluzione dei problemi per cui si scrivono i programmi piuttosto che sul modo di scrivere per evitare guai. Chiaro che anche il modo di scrivere ha la sua importanza, ma ora ne ha troppa. Occorrerebbe realmente riscrivere tutto il software citato sopra con linguaggi adatti all'uso di produzione. C'è da chiedersi realmente se un software scritto in C possa ritenersi 'professionale' e possa essere usato senza problemi dagli utenti; usare il C per programmare significa far progettare una casa progettando perfino le viti dei telai delle finestre. Un'ingegneria del software richiede un linguaggio di programmazione professionale, il che oggi significa utilizzare una VM. Il mondo Open Source da questa tendenza ha molto poco da guadagnare dato che dei due motori VM principali, Java e .net, esso possiede una limitata compatibilità' con .net grazie al progetto Mono. Java continua a rimanere una tecnologia proprietaria, perciò se il mondo Open Source volesse riprogettare i propri programmi, dando per scontato che Java rimarrà proprietario almeno per ora, dovrebbe separare la base del linguaggio C# dalle librerie proprietarie Microsoft come ADO.net e Visual Basic .net.

A dire il vero esiste una serie di macchine virtuali su cui si basano i linguaggi di script popolari, come Perl PHP o Python, ma per vari motivi non sembrano abbastanza diffusi per coinvolgere la maggioranza degli sviluppatori (inoltre, basandosi spesso su librerie scritte in C sono causa essi stessi di continui problemi come nel caso di PHP per il quale continuano ad uscire patches per problemi seri). Difficile far accettare un Apache o un Sendmail scritto in Perl, anche se con la nuova VM Parrot ci si potrebbe pensare.

In questo campo forse il mondo OS rivela il suo lato più debole: organizzare una analisi di grande respiro invece che risolvere un problema immediato. I talenti comunque non mancano e le speranze sono qui. Per ora non resta che esaminare le patches ed aggiornare.

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

Informatica anno zero

Filed under: Uncategorized — lbell @ 20:48

Ho finalmente potuto mettere di nuovo le mani su di un mac dopo tanto tempo e ho realizzato che il mondo delle interfacce utente e' fermo al 1984, anno della comparsa del primo mac. Tutto il resto e' solo un dettaglio, NeXT a parte, ovviamente.

Blog su WordPress.com.