Creazione di una Certification Authority con CentOS/Fedora (Parte II)

Continuando il discorso iniziato nell’articolo precedente, di seguito riportiamo i comandi necessari per installare una propria Certification Authority creata con OpenSSL.

Quasi tutte le installazioni di Linux (Fedora e CentOS compresi) fanno uso di OpenSSL. Per accertarsi che sia installato è sufficiente scrivere nella shell:

OpenSSL

Se tutto è ok comparirà il prompt dei comandi del programma (per uscire scrivere quit e premere invio).

Chi dovesse installare il pacchetto può scrivere invece:

yum install openssl

A differenza di altre distribuzioni, in Red Hat i files di configurazione di OpenSSL risiedono nella cartella “/etc/pki/tls”. Il primo passo consiste nel creare una nuova directory dove conservare tutti i files necessari alla nostra CA. Per non incorrere in problemi dovuti alle policy di selinux, in questo esempio utilizzeremo la cartella “/etc/pki/CA” (l’utente può usare comunque un altro percorso).

Una volta scelta la destinazione è necessario creare alcune sottocartelle:

  • certs – cartella in cui verranno sistemati i certificati;
  • crl – cartella dedicata alla revoca dei certificati;
  • newcerts – cartella utilizzata da openssl per creare i certificati nella forma non criptata
  • private – cartella contenente le chiavi private. Questa cartella dovrebbe essere di sola lettura e trattata con estrema cura dal momento che contiene la parte più intima della CA.

Oltre alle cartelle, bisogna creare alcuni file:

  • index.txt – file che fungerà da database;
  • serial – file che contiene il numero progressivo dei certificati segnati;
  • crlnumber – (facoltativo) contiene il numero successivo da utilizzare nella lista dei certificati revocati;

Per comodità, di seguito trovate i comandi necessari per creare l’ambiente:

cd /etc/pki/CA
mkdir certs crl newcerts private
touch index.txt
echo "01" > serial
chmod 0755 *

Fatto questo, passiamo alla modifica del file di configurazione openssl.cnf che si trova nella cartella /etc/pki/tls. Prima di procedere oltre però sarebbe bene fare una copia di backup.

[ CA_default ]
  dir = /etc/pki/CA
  x509_extensions = v3_ca
  countryName_default = IT
  stateOrProvinceName_default = Calabria
  0.organizationName_default = Catanzaro

In alto abbiamo riportato solo le righe che sono state modificate.

Per quanto concerne il parametro x509_extensions vi sono alcune considerazioni da fare. Si tratta di un parametro che indica quale sezione del file di configurazione prendere in considerazione quando vengono creati i certificati (relativamente alle estensioni x509). Poichè la sezione usr_cert (valore di default) contiene alcuni parametri che devono essere correttamente impostati per creare certificati validi in ambiente MS-Windows, si è preferito sostituirla con v3_ca che non necessita di personalizzazioni; ricordiamo che questo articolo non tratta tutti gli argomenti relativi al file di configurazione di openssl.

Se non sono state apportate modifiche al file di configurazione diverse da quelle specificate in precedenza, per creare una CA è sufficiente impartire il seguente comando:

openssl req -config /etc/pki/tls/openssl.cnf \
    -new -x509 -days 7200 -keyout /etc/pki/CA/private/cakey.pem \
    -out /etc/pki/CA/cacert.pem

É ovvio che i percorsi indicati nel comando devono rispecchiare la configurazione altrimenti il certificato non verrà utilizzato dal sistema operativo. Il certificato creato avrà una durata di 20 anni, probabilmente è un periodo di tempo eccessivo.

A questo punto viene richiesta una pass phrase ed i campi del certificato:

Generating a 1024 bit RSA private key
.................++++++
.........++++++
writing new private key to '/etc/pki/CA/private/cakey.pem'
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:
-----
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) [GB]:IT
State or Province Name (full name) [Berkshire]:Catanzaro
Locality Name (eg, city) [Newbury]:Catanzaro
Organization Name (eg, company) [My Company Ltd]:Morzello Blog
Organizational Unit Name (eg, section) []:
Common Name (eg, your name or your server's hostname) []:morzello.com
Email Address []:noreply@morzello.com

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:ScegliUnaPassword
An optional company name []:Morzello Blog

La pass phrase non deve essere intesa come una password, in effetti viene rischiesta una “frase segreta” che dorà essere custodita con cura.

La challenge password invece viene usata per evitare le la chiave privata venga conservata in chiaro sul disco.

Creazione dei certificati

La creazione dei certificati è relativamente semplice e si compone di due fasi: nella prima viene fatta una richiesta di certificazione mentre nella seconda la richiesta viene segnata digitalmente.

In linea di principio non c’è differenza tra i certificati emessi per un server e quelli emessi per un client; a variare è l’uso che se ne fa del certificato. In genere, la chiave privata del certificato non viene conservata in chiaro ma viene anch’essa sottoposta a crittografia mediante la richiesta di una password. Nel caso di servizi server però questa politica è difficilmente applicabile poichè all’avvio del server tipicamente non vi è nessuno in gradi di digitare una password. Conservare la password in chiaro non ha senso e quindi i certificati per i server non contemplano la crittografia per la chiave privata.

Richiesta di certificati server

OpenSSL può essere utilizzato anche per emettere le richieste di certificazione. Di seguito vediamo un esempio applicabile ai certificati server:

openssl req -config /etc/pki/tls/openssl.cnf -new -nodes -days 730 \
     -keyout /etc/pki/CA/private/new.key \
     -out /etc/pki/CA/newcerts/new_req.pem

Il parametro -nodes evita proprio che il certificato venga sottoposto a crittografia triple des.

Dopo aver eseguito il comando si procederà con la compilazione dei campi necessari:

Generating a 1024 bit RSA private key
........++++++
..........++++++
writing new private key to '/etc/pki/CA/private/new.key'
-----
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) [GB]:IT
State or Province Name (full name) [Berkshire]:Italy
Locality Name (eg, city) [Newbury]:Torino
Organization Name (eg, company) [My Company Ltd]:Morzello Blog
Organizational Unit Name (eg, section) []:
Common Name (eg, your name or your server's hostname) []:www.morzello.com
Email Address []:noreply@morzello.com

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:test
An optional company name []:

Richiesta di certificati client

Per i client la richiesta è del tutto simile ma in questo caso, possiamo usare la crittografia a protezione della chiave privata:

openssl req -config /etc/pki/tls/openssl.cnf -new -days 730 \
     -keyout /etc/pki/CA/private/new.key \
     -out /etc/pki/CA/newcerts/new_req.pem

A titolo esemplificativo riportiamo l’output del comando precedente:

Generating a 1024 bit RSA private key
.++++++
.......++++++
writing new private key to '/etc/pki/CA/private/new.key'
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:
-----
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) [GB]:IT
State or Province Name (full name) [Berkshire]:Calabria
Locality Name (eg, city) [Newbury]:Catanzaro
Organization Name (eg, company) [My Company Ltd]:Morzello Blog
Organizational Unit Name (eg, section) []:
Common Name (eg, your name or your server's hostname) []:client.morzello.com
Email Address []:noreply@morzello.com

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:test
An optional company name []:

Come è possibile notare, in questo caso viene richiesta una pass phrase per il certificato.

Firmare digitalmente le richieste

Dopo aver creato la richiesta possiamo passare alla sua firma (sign). Per farlo possiamo usare la nostra CA:

openssl ca -config /etc/pki/tls/openssl.cnf \
     -policy policy_anything \
     -out /etc/pki/CA/certs/new.crt \
     -infiles /etc/pki/CA/newcerts/new_req.pem

Il risultato sarebbe del tutto simile al seguente:

Using configuration from /etc/pki/tls/openssl.cnf
Enter pass phrase for /etc/pki/CA/private/cakey.pem:
Check that the request matches the signature
Signature ok
Certificate Details:
        Serial Number: 1 (0x1)
        Validity
            Not Before: Jun 30 09:18:53 20xx GMT
            Not After : Jun 30 09:18:53 20yy GMT
        Subject:
            countryName               = IT
            stateOrProvinceName       = Calabria
            localityName              = Catanzaro
            organizationName          = Morzello Blog
            commonName                = client.morzello.com
            emailAddress              = noreply@morzello.com
        X509v3 extensions:
            X509v3 Subject Key Identifier:
                0A:AF:2C:D3:55:29:86:33:FC:D2:9A:A4:AF:90:42:AB:BD:17:01:29
            X509v3 Authority Key Identifier:
                keyid:30:16:68:ED:CD:61:20:61:F3:D0:BA:17:35:2A:74:87:E4:D3:A1:32
                DirName:/C=IT/ST=Calabria/L=Catanzaro/O=Vittorio Benintende/CN=client.morzello.com/emailAddress=noreply@morzello.com
                serial:09:DB:34:A3:DA:3F:56:BC

            X509v3 Basic Constraints:
                CA:TRUE
Certificate is to be certified until Jun 30 09:18:53 20xx GMT (365 days)
Sign the certificate? [y/n]:y

1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated

A questo punto possiamo eliminare la richiesta:

rm /etc/pki/CA/newcerts/new_req.pem

Verifiche e test sui certificati

Per visualizzare le informazioni relative ad un certificato basta indicare gli argomenti che interessano, come ad esempio: l’emittente, la data di scadenza, l’hash md5, il fingerprint, …

openssl x509 -noout -subject -issuer -enddate -hash -fingerprint -in /etc/pki/CA/certs/new.crt

Il parametro -noout indica ad openssl che non c’è un output da gestire.

Per verificare la validità di un certificato si può utilizzare il comando:

openssl verify -CAfile /etc/pki/CA/cacert.pem /etc/pki/CA/certs/new.crt
/etc/pki/CA/certs/new.crt: OK

Installare i certificati in Windows

In Windows l’installazione dei certificati merita un po’ di attenzione perchè è necessario fare una conversione se si utilizza l’esempio riportato in alto. Per metabolizzare il certificato infatti Windows ha bisogno del formato PKCS#12. Per ottenere questo possiamo utilizzare il seguente comando:

openssl pkcs12 -export -in /etc/pki/CA/certs/new.crt \
-inkey /etc/pki/CA/private/new.key -out /etc/pki/CA/certs/new.p12 -clcerts

A questo punto viene eventualmente richiesta la password per l’esportazione del certificato.

Per importare i certificati e le CA all’interno del sistema operativo basta cliccare sul file e seguire le istruzioni del wizard proposte a video. Un certificato può essere installato per il singolo utente o per la macchina (con credenziali amministrative).

Se si desidera avere maggior controllo si può invece utilizzare la Microsoft Management Console (mmc.exe)  aggiungendo l’apposito snap-in:

file -> aggiungi/rimuovi snap-in...
aggiungi -> certificati -> account del computer

Dovreste trovarvi in una situazione simile a quella riportata in foto:


Alla prossima.

Pentaho – Avviare il servizio al boot. Uno script per CentOS, Fedora e RHEL

Ho visto che in giro non è ancora stato pubblicato uno script per l’avvio automatico di pentaho su sistemi linux derivati da Red Hat così ho pensato di mettere online il mio:

#!/bin/bash
#
# chkconfig: - 92 36
# description: Starts and stops pentaho.

# Source function library.
. /etc/init.d/functions

# Source networking configuration.
. /etc/sysconfig/network

# Check that networking is up.
[ ${NETWORKING} = "no" ] && exit 0

unset BASH_ENV ENV

PUSER="pentaho"
PENTAHO_HOME="/opt/pentaho/biserver-ce"
JAVA_HOME="/usr/lib/jvm/jre-1.6.0/"
prog=$"Pentaho server"
logfile="${PENTAHO_HOME}/pentaho.log"

if [ -e "${logfile}" ]; then
    rm -f "${logfile}" > /dev/null
fi

cd ${PENTAHO_HOME}
. "${PENTAHO_HOME}/set-pentaho-java.sh"

if [ -d "${PENTAHO_HOME}/jre" ]; then
    setPentahoJava "${PENTAHO_HOME}/jre" >> ${logfile} 2>&1
else
    setPentahoJava >> ${logfile} 2>&1
fi

PENV="export _PENTAHO_JAVA_HOME=${_PENTAHO_JAVA_HOME} && export _PENTAHO_JAVA=${_PENTAHO_JAVA} && export JAVA_OPTS='-Djava.awt.headless=true' && export JAVA_HOME=${_PENTAHO_JAVA_HOME}"

start() {
    echo -n $"Starting $prog: "

    if [ -e "${PENTAHO_HOME}/promptuser.sh" ]; then
        sh "${PENTAHO_HOME}/promptuser.sh" >> ${logfile} 2>&1
        rm "${PENTAHO_HOME}/promptuser.sh"
    fi

    if [ "$?" = 0 ]; then
        /sbin/runuser -l ${PUSER} -c "${PENV} && cd '${PENTAHO_HOME}/data' && sh ./start_hypersonic.sh & " >> ${logfile} 2>&1 && \
        /sbin/runuser -l ${PUSER} -c "${PENV} && cd '${PENTAHO_HOME}/tomcat/bin' && export CATALINA_OPTS='-Xms256m -Xmx768m -XX:MaxPermSize=256m -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000' && sh ./startup.sh" >> ${logfile} 2>&1 && echo "OK" || echo "ERROR"

    fi

}

stop() {
    echo -n $"Shutting down $prog: "

    /sbin/runuser -l ${PUSER} -c "${PENV} && cd '${PENTAHO_HOME}/data' && sh ./stop_hypersonic.sh & "  >> ${logfile} 2>&1 && \
    /sbin/runuser -l ${PUSER} -c "${PENV} && cd '${PENTAHO_HOME}/tomcat/bin' && sh ./shutdown.sh"  >> ${logfile} 2>&1 && echo 'OK' || echo "ERROR"

}

# See how we were called.
case "$1" in
  start)
	start
	;;
  stop)
	stop
	;;
  restart)
	stop
	sleep 3
	start
	;;
  status)
	ps U 'pentaho' | grep -e 'sh ./start_hypersonic.sh' >> /dev/null && echo "$prog is running" || echo "$prog is stopped"
	;;
  *)
	echo $"Usage: $0 {start|stop|restart}"
	exit 1
esac

Ovviamente sarà necessario configurare le variabili in base alla installazione di Pentaho.

Alla prossima.

Repository aggiuntivi in CentOS e Fedora

Come tutte le grandi distribuzioni open source, sia CentOS che Fedora godono di un ampio repository ed offrono supporto ad una vasta gamma di programmi.

Non tutte le applicazioni però sono disponibili all’interno della distribuzione e di conseguenza nel repository ufficiale.

Repository non ufficiali possono essere utilizzati come valida alternativa alla compilazione dei sorgenti.

Bisogna però fare attenzione perché utilizzare repository sconosciuti potrebbe compromettere il sistema operativo, sia dal punto di vista della sicurezza che da quello della stabilità.

In questo articolo spiegheremo brevemente come accedere a repository non ufficiali tramite yum.

La priorità dei repository
Quando si ha a che fare con più repository esiste un concetto di priorità che bisogna tenere in considerazione altrimenti si rischia di fare l’aggiornamento dei pacchetti di base su un repository non ufficiale come ad esempio quello di test.

Yum consente di priorizzare i repository in base alle proprie esigenze mediante un apposito plugin che può essere installato con il seguente comando:

yum install yum-priorities

Per consentire l’uso dei plugin in yum è necessario modificare il file /etc/yum.conf:

[main]
cachedir=/var/cache/yum
keepcache=0
debuglevel=2
logfile=/var/log/yum.log
distroverpkg=redhat-release
tolerant=1
exactarch=1
obsoletes=1
gpgcheck=1
plugins=1

# Note: yum-RHN-plugin doesn't honor this.
metadata_expire=1h

installonly_limit = 5

# PUT YOUR REPOS HERE OR IN separate files named file.repo
# in /etc/yum.repos.d

aggiungendo eventualmente la riga “plugins=1″

Un seconda abilitazione deve essere fatta per ogni singolo plugin installato. Nel nostro caso quindi bisogna modificare il file /etc/yum/pluginconf.d/priorities.conf impostando il parametro enabled:

[main]
enabled = 1

Una volta abilitato il plugin è possibile gestire la priorita di ogni repository aggiungendo il parametro priority=N in nel relativo file di configurazione. N è un numero che va da 1 a 99 ed esprime una gerarchia. A valori di N più elevati corrispondono repository con priorità più bassa.

Nella cartella /etc/yum.repos.d sono presenti i files relativi ai singoli repository. L’esempio seguente si riferisce al file /etc/yum.repos.d/CentOS-Base.repo:

[base]
name=CentOS-$releasever - Base
mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=os
#baseurl=http://mirror.centos.org/centos/$releasever/os/$basearch/
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-5
priority=1

#released updates
[updates]
name=CentOS-$releasever - Updates
mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=updates
#baseurl=http://mirror.centos.org/centos/$releasever/updates/$basearch/
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-5
priority=1

#packages used/produced in the build but not released
[addons]
name=CentOS-$releasever - Addons
mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=addons
#baseurl=http://mirror.centos.org/centos/$releasever/addons/$basearch/
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-5
priority=1

#additional packages that may be useful
[extras]
name=CentOS-$releasever - Extras
mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=extras
#baseurl=http://mirror.centos.org/centos/$releasever/extras/$basearch/
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-5
priority=1

#additional packages that extend functionality of existing packages
[centosplus]
name=CentOS-$releasever - Plus
mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=centosplus
#baseurl=http://mirror.centos.org/centos/$releasever/centosplus/$basearch/
gpgcheck=1
enabled=0
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-5
priority=2

#contrib - packages by Centos Users
[contrib]
name=CentOS-$releasever - Contrib
mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=contrib
#baseurl=http://mirror.centos.org/centos/$releasever/contrib/$basearch/
gpgcheck=1
enabled=0
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-5
priority=2

Da notare come i repository di base abbiano tutti priorità 1.

Importare il repository di rpmforge
Prima di importare un nuovo repository è bene verificarne l’autenticità. Ogni repository inoltre dovrebbe essere dotato di una chiave GPG che consenta a yum di verificare la provenienza dei pacchetti.

Nell’esempio che segue, aggiungeremo una chiave valida per rpmforge:

rpm --import http://dag.wieers.com/rpm/packages/RPM-GPG-KEY.dag.txt

Anche se può sembrare strano, è necessario importare la chiave prima del repository stesso altrimenti yum non sarà in grado di certificarne l’installazione.

Prima di installare il repository bisogna identificare l’architettura hardware che si intende utilizzare (ad esempio i386 oppure x86_64). Fare uqesta sceltà è necessaria perché ogni architettura ha un percorso diverso. Per capire con ragionevole certezza quale sia l’architettura corretta è sufficiente impartire il seguente comando:

uname -i

A questo punto possiamo scegliere tra:

dopo aver scaricato il pacchetto procediamo con la verifica:

wget http://apt.sw.be/redhat/el5/en/$(uname -i)/RPMS.dag/rpmforge-release-0.3.6-1.el5.rf.$(uname -i).rpm
rpm -K rpmforge-release-0.3.6-1.el5.rf.*.rpm

Con una risposta simile a:

rpmforge-release-0.3.6-1.el5.rf.i386.rpm: (sha1) dsa sha1 md5 gpg OK

Ora possiamo procedere con l’installazione:

rpm -i rpmforge-release-0.3.6-1.el5.rf.*.rpm

Infine aggiungiamo una priorità più alta per questo repository:

echo "priority = 5" >> /etc/yum.repos.d/rpmforge.repo

Installare repository di test
Possiamo fare lo stesso discorso con i repository di test. L’esempio che segue si applica a CentOS 5:

cd /etc/yum.repos.d
wget http://dev.centos.org/centos/5/CentOS-Testing.repo

Dando un’occhiata al file noterete che il repository è disabilitato. Questo è molto importante perché in genere i repository di test sono molto instabili ed il loro uso potrebbe essere causa di instabilità in ambienti di produzione.

Quando si intende usare un repository disabilitato è possibile eseguire yum con il parametro –enablerepo=REPO dove REPO è il nome del repository. Ad esempio:

yum --enablerepo=c5-testing install pacchetto

Altro sui repository
A fronte di più repository, quando si esegue yum per un aggiornamento del sistema si noterà certamente l’esclusione di alcuni pacchetti:

yum update

Loaded plugins: fastestmirror, priorities
Loading mirror speeds from cached hostfile
 * addons: centos.bio.lmu.de
 * base: ftp.halifax.rwth-aachen.de
 * extras: centos.bio.lmu.de
 * rpmforge: fr2.rpmfind.net
 * updates: mirror.avalonsys.eu
478 packages excluded due to repository priority protections
Setting up Update Process
No Packages marked for Update

Alcuni pacchetti marcati come da aggiornare non saranno scartati se sono marcati come da non aggiornare in un repository con priorità più bassa. Per verificare quali pacchetti sono stati esclusi è possibile usare il parametro –d3:

yum -d3 update
Loaded plugins: fastestmirror, priorities
Config time: 0.136
Yum Version: 3.2.22
Setting up Package Sacks
Loading mirror speeds from cached hostfile
 * addons: mirror.silyus.net
 * base: ftp.halifax.rwth-aachen.de
 * extras: mirror.silyus.net
 * rpmforge: fr2.rpmfind.net
 * updates: mirror.avalonsys.eu
 --> subversion-perl-1.6.3-0.1.el5.rf.i386 from rpmforge excluded (priority)
 --> php-pecl-memcache-2.1.2-1.el5.rf.i386 from rpmforge excluded (priority)
 --> perl-DBD-Pg-2.10.7-1.el5.rf.i386 from rpmforge excluded (priority)
 --> qemu-0.9.0-2.el5.rf.i386 from rpmforge excluded (priority)
 --> subversion-perl-1.3.2-0.2.el5.rf.i386 from rpmforge excluded (priority)
 --> fuse-2.7.4-1.el5.rf.i386 from rpmforge excluded (priority)
 --> lftp-3.5.11-1.el5.rf.i386 from rpmforge excluded (priority)
...

Alla prossima.

Un Domain Controller in CentOS/Fedora per la piccola e media impresa

In questo articolo viene proposto un modo facile e veloce di creare un DC (Domain Controller) per ambienti Windows utilizzando Samba.
Va detto che la soluzione è dimensionata per la piccola e media impresa, dove il numero di utenti generalmente non supera le cento unità.
Facile e veloce perché impiega un solo server e non prevede ridondanza.
Per l’articolo ho scelto di utilizzare CentOS ma dovrebbe funzionare anche con Fedora.

Prerequisiti
La soluzione prevede il deployment all’interno di una rete locale (LAN); si presuppone dunque che i servizi di DNS (per la risoluzione dei nomi) e DHCP (per l’assegnazione automatica degli indirizzi IP) funzionino a dovere.
La lista della spesa Per far girare “il tutto” è necessario installare sulla macchina alcuni pacchetti fondamentali di samba. Per verificare i pacchetti già installati è sufficiente usare yum:

[root@myserver ~]# yum list *samba*
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
 * base: centos.fastbull.org
 * updates: centos.fastbull.org
 * addons: centos.fastbull.org
 * extras: centos.kiewel-online.ch base
Installed Packages
 samba.i386	3.0.33-3.7.el5_3.1	installed
 samba-client.i386		3.0.33-3.7.el5_3.1	installed
 samba-common.i386		3.0.33-3.7.el5_3.1	installed
 system-config-samba.noarch	1.2.41-3.el5		installed
 Available Packages
 samba-swat.i386		3.0.33-3.7.el5_3.1	updates
 sblim-cmpi-samba.i386		0.5.2-31.el5_2.1	base
 sblim-cmpi-samba-devel.i386	1-31.el5_2.1		base
 sblim-cmpi-samba-test.i386	1-31.el5_2.1		base

Nel nostro caso samba è già installato. Nel caso in cui fosse necessario installare il software possiamo sempre utilizzare yum:

yum install samba

I pacchetti fondamentali sono:

samba.i386 samba-common.i386system-config-samba.noarch

Degli altri possiamo anche farne a meno.

Personalizzare il servizio
Nel nostro caso, Samba dovrà funzionare come DC, per questo motivo è necessario editare il file /etc/samba/smb.conf indicando le corrette impostazioni. Di seguito un esempio di configurazione possibile:

[global]
        workgroup = MORZELLO
        server string = Samba Server Version %v
        netbios name = MYSERVER
        security = user
        passdb backend = tdbsam
        domain master = yes
        domain logons = yes
        logon script = %m.bat
        logon script = %u.bat
        logon path =
        add user script = /usr/sbin/useradd "%u" -n -g users
        add group script = /usr/sbin/groupadd "%g"
        add machine script = /usr/sbin/useradd -n -c "Workstation (%u)" -M -d /nohome -s /bin/false "%u"
        delete user script = /usr/sbin/userdel "%u"
        delete user from group script = /usr/sbin/userdel "%u" "%g"
        delete group script = /usr/sbin/groupdel "%g"
        username map = /etc/samba/smbusers
        lanman auth = no
        ntlm auth = Yes
        client NTLMv2 auth = Yes
        client lanman auth = no
        client plaintext auth = no
        winbind enum groups = yes
        winbind enum users = yes
        wins support = yes

[homes]
        comment = Home Directories
        browseable = no
        writable = yes

Il file di configurazione contiene solo ed esclusivamente i dati strettamente necessari per far funzionare il servizio come PDC (Primary Domain Controller). Probabilmente il lettore vorrà successivamente attivare altre voci come ad esempio le stampanti di rete e le cartelle di rete. Queste informazioni non sono strettamente necessarie e per questo motivo non sono trattate in questa sede. Per dare un senso al nostro operato cerchiamo di capire il significato delle voci principali che compongono il nostro file di configurazione:

  • workgroup: indica il nome del nostro dominio;
  • passdb backend: indica come samba gestirà le utenze windows. specificando tdbsam samba autenticherà gli utenti e le macchine appartenenti al dominio mediante il proprio database, senza utilizzare servizi esterni come ad esempio LDAP oppure un altro DC;
  • *script: sono le voci che indicano quali script eseguire per gestire gli utenti ed i gruppi;
  • logon path: è il percorso della cartella che contiene informazioni di netlogon di Windows. Nell’esempio si è deciso di non fornire questo servizio;
  • domain logons: indica se il server agirà come DC oppure no;
  • domain master: indica se il server agirà come PDC oppure no.

Per capire se la nostra configurazione è valida o meno possiamo usare il comando testparm:

[root@myserver ~]# testparm -s
Load smb config files from /etc/samba/smb.conf
Processing section "[homes]"
Loaded services file OK.
Server role: ROLE_DOMAIN_PDC
[global]
        workgroup = MORZELLO
        server string = Samba Server Version %v
        passdb backend = tdbsam
        username map = /etc/samba/smbusers
        lanman auth = No
        client NTLMv2 auth = Yes
        client lanman auth = No
        client plaintext auth = No
        log level = 2
        log file = /var/log/samba/%m.log
        add user script = /usr/sbin/useradd "%u" -n -g users
        delete user script = /usr/sbin/userdel "%u"
        add group script = /usr/sbin/groupadd "%g"
        delete group script = /usr/sbin/groupdel "%g"
        delete user from group script = /usr/sbin/userdel "%u" "%g"
        add machine script = /usr/sbin/useradd -n -c "Workstation (%u)" -M -d /nohome -s /bin/false "%u"
        logon script = %u.bat
        logon path =
        domain logons = Yes
        domain master = Yes
        wins support = Yes
        winbind enum users = Yes
        winbind enum groups = Yes

[homes]
        comment = Home Directories
        read only = No
        browseable = No

È fondamentale che la voce server role sia quella corretta.

L’utenza amministrativa
Per poter gestire il dominio è necessario aggiungere nel database di samba l’utente amministratore:

[root@myserver samba]# smbpasswd -a root
New SMB password:
Retype new SMB password:
tdbsam_open: Converting version 0 database to version 3....
Added user root.

Gli utenti di dominio
Gli utenti samba sono in realtà utenti linux e bisogna dare una regola per convertire correttamente gli utenti tra linux e windows. Per fare questo personalizziamo il file /etc/samba/smbusers:

# Unix_name = SMB_name1 SMB_name2 ...
root = administrator admin
nobody = guest pcguest smbguest

Nel nostro caso ci limitiamo a dire che l’utente administrator equivale a root e che l’utente guest equivale a nobody. Aggiungiamo anche i gruppi di utenti windows che non esistono ancora in linux:

# Map Windows Domain Groups to UNIX groups
net groupmap add rid=514 ntgroup="Domain Guests" unixgroup="nobody" type=d
net groupmap add rid=513 ntgroup="Domain Users" unixgroup="users" type=d
net groupmap add rid=512 ntgroup="Domain Admins" unixgroup="root" type=d

Si possono aggiungere anche altri gruppi di utenti, quelli specificati in alto sono quelli “canonici”. Per verificare che i gruppi siano stati creati possiamo usare il comando wbinfo:

[root@myserver samba]# wbinfo -g
domain users
domain admins
domain guests

Aggiungendo gli utenti di dominio ricordiamo sempre che questi sono anche utenti Linux. È probabile però che non tutti gli utenti dovranno avere accesso al server come utenti locali. Per inibire l’accesso alla console del server specificheremo una shell non valida. Su CentOS possiamo creare un utente con queste caratteristiche usando il comando adduser:

[root@myserver samba]# adduser -m -s /sbin/nologin testuser
[root@myserver samba]# passwd testuser
[root@myserver samba]# smbpasswd -a testuser

Con precedenti comandi abbiamo creato un utente, assegnato una password per linux ed una per samba.
Un metodo alternativo per creare gli utenti è quello di accodare direttamente gli utenti nel file /etc/passwd senza assegnare la password all’utente.
A pensarci bene non è necessario assegnare una password ad un utente che non può fare il logon. Se invece l’utente deve comunque avere l’accesso al server è sufficiente omettere il parametro “–s”.
Comunque sia per abilitare l’utente al dominio è necessario inserirlo nel database di samba con il comando smbpasswd.
Da notare che la password per linux può essere diversa da quella specificata in samba. Eseguire il servizio all’avvio In CentOS i servizi possono essere gestiti facilmente mediante il comando chkconfig.
Le righe seguenti assicurano l’avvio del servizio all’accensione del nostro server:

chkconfig smb on

Ultimi ritocchi: iptables e selinux
Samba necessita di alcune porte tcp ed udp per poter funzionare correttamente. Queste porte sono chiude per default da iptables. Di seguito le righe da inserire nel file /etc/sysconfig/iptables:

-A RH-Firewall-1-INPUT -m state --state NEW -m udp -p udp --dport 137 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m udp -p udp --dport 138 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 139 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 445 -j ACCEPT

Le righe devono essere inserite nel file prima delle ultime due stringhe:

-A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited
COMMIT

Per quanto concerne selinux invece bisogna consentire a samba l’uso dei comandi necessari per svolgere alcuni task:

# Se si intende usare useradd/groupadd è necessario eseguire:
setsebool -P samba_domain_controller on
#
# Se si vuole condividere la home degli utenti eseguire:
setsebool -P samba_enable_home_dirs on

Per condividere una cartella di rete bisogna assegnare alla stessa l’etichetta “samba-share_t”. Evitate le cartelle di sistema perché queste probabilmente hanno una etichetta diversa già applicata. Per verificare i dettagli di una cartella relativa a selinux è possibile usare il comando ls specificando il paramentr “–Z”:

ls -ldZ /percorso_completo

Aggiungere una workstation al dominio
La procedura di Join è totalmente trasparente in windows.
Per aggiungere una macchina al dominio possiamo cliccare con il tasto destro del mouse su “Gestione Risorse” quindi selezionare il percorso :“Proprietà->Nome Computer->Cambia”. Specificare MORZELLO nella casella “dominio” e procedere al logon di root con la password indicata in samba (mediante il comando smbpasswd).

Alla prossima.

VNC server su Fedora e CentOS

Sono lontani i tempi in cui VNC era considerato un trojan. Oggi quasi tutte le distribuzioni hanno una versione di questo demone per amministrare da remoto un computer in ambiente visuale.

Nonostante l’installazione sia alquanto banale, la messa a punto dello strumento può risultare problematica, specie la prima volta.

Di seguito riporto una breve guida che veste bene per le distribuzioni derivate da Red Hat come ad esempio CentOS e Fedora.

Diamo per scontato che il gestore delle finestre X Window sia correttamente installato e funzionante; non è necessario che sia attualmente in uso. È possibile trovare server che non hanno testiera e monitor ma che comunque offrono una interfaccia visuale con VNC.

Procediamo verificando in primo luogo l’esistenza del demone

yum list vnc-server

In caso procediamo con l’installazione

 yum install vnc-server

Consiglio vivamente di eseguire il demone con un utente non amministrativo, anzi, per dirla tutta, la cosa migliore è creare un utente ad-hoc che non appartenga al gruppo utenti “users”. Questo ci consentirà di definire policy specifiche per questo servizio

groupadd vnc
useradd -g vnc vnc
passwd vnc

Con il comando precedente abbiamo definito un nuovo gruppo, un nuovo utente ed una password per l’utente stesso.

Ora passiamo alla personalizzazione del servizio. Su Red Hat è sufficiente editare e personalizzare il file “/etc/sysconfig/vncservers“. Di seguito un esempio funzionante per la nostra dimostrazione

# The VNCSERVERS variable is a list of display:user pairs.
#
# Uncomment the lines below to start a VNC server on display :2
# as my 'myusername' (adjust this to your own).  You will also
# need to set a VNC password; run 'man vncpasswd' to see how
# to do that.
#
# DO NOT RUN THIS SERVICE if your local area network is
# untrusted!  For a secure way of using VNC, see
# .

# Use "-nolisten tcp" to prevent X connections to your VNC server via TCP.

# Use "-nohttpd" to prevent web-based VNC clients connecting.

# Use "-localhost" to prevent remote VNC clients connecting except when
# doing so through a secure tunnel.  See the "-via" option in the
# `man vncviewer' manual page.

# VNCSERVERS="2:myusername"
# VNCSERVERARGS[2]="-geometry 800x600 -nolisten tcp -nohttpd -localhost"

 VNCSERVERS="2:vnc"
 VNCSERVERARGS[2]="-geometry 1024x768"

Le righe che interessano sono le ultime due dove vengono definite le variabili necessarie al demone per “girare”.

VNCSERVERS definisce la porta e l’utente di ogni singola sessione. È possibile infatti eseguire diverse sessioni utente ovviamente ognuna su porte differenti.

vncserver si mette in ascolto a partire dalla porta TCP 5900. Impostando il primo parametro a “2″ chiediamo al demone di aprire una sessione sulla porta 5902.

Più sessioni possono essere specificate nella stessa variabile. Ad esempio

VNCSERVERS="1:utente1 2:utente2 3:utente3"

VNCSERVERARGS[X] (dove “X” indica il numero di porta) definisce i parametri da passare al demone per ogni sessione. Nel caso di più sessioni sarà necessario specificare più parametri:

VNCSERVERARGS[1]="-geometry 1024x768"
VNCSERVERARGS[2]="-geometry 800x600 -depth 16"
VNCSERVERARGS[3]="-geometry 1024x768 -localhost"

Per un dettaglio maggiore sui parametri supportati consultare la documentazione ufficiale (man Xvnc).

Poiché il servizio partirà con l’utenza vnc è necessario personalizzare l’ambiente di questo utente. In particolare è necessario impostare una password che vncserver chiederà al momento del log-on

su vnc
vncpasswd

Dopo aver impostato la password, che può essere diversa da quella specificata per l’utente, facciamo partire il servizio (sempre come utente vnc)

vncserver

Se tutto è andato a buon fine dovremmo avere una sessione attiva sulla porta 5902

vncviewer remotehost:5902:2

Dove remotehost è il nome della macchina e 5902 la porta tcp.

All’avvio del servizio verrà creato un file, una sorta di autoexec.bat contenente i comandi da eseguire per gestire l’ambiente visuale.
Nel nostro esempio questo file sarà “/home/vnc/.vnc/xstartup” ed avrà un aspetto del tutto simile a questo

xsetroot -solid grey
vncconfig -iconic &
xterm -geometry 80x24+10+10 -ls -title "$VNCDESKTOP Desktop" &
twm &

Questo script si occupa tra le altre cose di definire quale gestore grafico utilizzare nella sessione. Nell’esempio riportato in alto, è stato specificato twm, un gestore molto leggero ed essenziale

Chi volesse cambiare gestore può tranquillamente editare il file sostituendo l’ultima riga. Di seguito un esempio che mostra impiego di KDE

startkde &

Ed ecco una immagine dell’ambiente grafico in esecuzione

Per far partire il servizio all’avvio del sistema operativo possiamo utilizzare chkconfig (con credenziali amministrative)

chkconfig vncserver on

Concludiamo la procedura assicurandoci che il traffico di rete sia abilitato sulla macchina istruendo correttamente iptables. Di seguito le righe da aggiungere al file “/etc/sysconfig/iptables

-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 5902 -j ACCEPT

Bisogna fare attenzione ad inserire la riga precedente nella esatta posizione, prima cioè delle seguenti righe

-A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited
COMMIT

Altrimenti le regole di iptables non avranno l’effetto desiderato.


VNC e sessioni sicure
VNC non fa uso di crittografia a meno di non andare su prodotti commerciali la cui licenza è a pagamento. Questo significa che con un semplice sniffer è possibile rubare la password di accesso.

Una soluzione percorribile “out of the box” prevede l’uso di ssh (il comando utilizzato in Linux per ottenere una shell sicura).

L’idea è quella di far transitare il traffico in un tunnel ssh aperto su entrambi gli host (client e server) secondo il seguente schema:

client --> SSH --| network |-- SSH <-- server

Nel nostro esempio le terminazioni del tunnel verranno create direttamente sui due host in modo da rendere sicura la comunicazione su tutta la rete.

Chiediamo ad ssh di collegarsi al server VNC sulla porta 5902. Chiediamo inoltre ad ssh di mettersi in ascolto su un’altra porta, la 55902 e di fare in modo che il traffico criptato su quest’ultima finisca in chiaro sulla 5902 (forwarding)

ssh -f -L 55902:localhost:5902 remotehost

Il parametro -f istruisce il comando a liberare il prompt agendo come un comune demone.
Il paramtro -L si occupa invece del forwarding trasferendo i byte dalla porta 55902 del client sulla porta 5902 del server.

Per accedere al servizio possiamo eseguire vncviewer localmente

vncviewer localhost:55902:2

Per rendere le cose un tantino più semplici è possibile avvalersi del paramtro sleep con il quale specificare un tempo massimo di attesa (ad esempio 60 secondi) entro il quale creare una connessione. Questo garantisce che non restino appese sessioni inutili.

ssh -f -L 55902:localhost:5902 remotehost sleep 60; vncviewer localhost:55902:2

Nel caso ci fossero problemi è necessario verificare i parametri di ssh ed eventualmente di OpenSSL. Per maggiori informazioni prendere visione della miniguida riportata alla fine dell’articolo.

Sessioni sicure con Windows
Quanto detto in precedenza vale anche per i client Windows dato che ssh esiste anche per cygwin.

Volendo è possibile utilizzare PuTTY creando una sessione e specificando i parametri Source port (55902) e Destination (remotehost:5902) sotto Category -> SSH -> Tunnels e cliccando su “Add“.

Di seguito un esempio che replica quanto fatto in precedenza

Per il momento è tutto. Spero come al solito di non avervi annoiato.
Alla prossima.

Per saperne di più
VNC Mini-FAQ

Quando Yum fa le bizze

In questi giorni, a seguito del passaggio a FC10 ho avuto qualche problema con gli aggiornamenti. Da una veloce ricerca su Internet mi sono accorto che si tratta di un problema sentito da molti.

Nel mio caso ho riscontrato due problemi; entrambi a seguito di un comune aggiornamento (update):

yum update

Il comando non è andato a buon fine per il seguente motivo:

There are unfinished transactions remaining. You might consider running yum-complete-transaction first to finish them.

Questo vuol dire che la precedente transazione è rimasta appesa senza finire il proprio lavoro.

Come indicato nel messaggio stesso è consigliabile usare il comando yum-complete-transaction.

Questo comando non è installato di default nel sistema operativo ma fa parte del pacchetto di utility per yum. Quindi bisogna eventualmente procedere con l’installazione:

yum install yum-utils

Una volta eseguito il comando la transazione è stata agevolmente completata:

# yum-complete-transaction
Loaded plugins: refresh-packagekit
There are 1 outstanding transactions to complete. Finishing the most recent one
The remaining transaction had 84 elements left to run
Nothing in the unfinished transaction to cleanup.
Cleaning up completed transaction file

Un secondo problema si è presentato sempre a seguito di un aggiornamento:

pacchetto-xxx-yyy-2.26-2.fc10.noarch from installed has depsolving problems

I problemi di dipendenze tra pacchetti sono comuni solo per le versioni di development (sviluppo) di Fedora, non di certo per la produzione.
Purtroppo non sono stato in grado di risolvere il problema se non escludendo il/i pacchetto/i incriminato/i dall’aggiornamento, in attesa che il Team di Fedora ponga rimedio.
Per escludere dall’aggiornamento un pacchetto che soffre di questo problema è sufficiente specificare l’opzione –skip-broken nella riga di comando:

yum –skip-broken update

Ovviamente alla fine dell’aggiornamento yum elenca i problemi di dipendenza riscontrati:

Skipped (dependency problems):
PackageKit.i386 0:0.3.11-4.fc10 PackageKit-glib.i386 0:0.3.11-4.fc10
PackageKit-udev-helper.i386 0:0.3.11-4.fc10 PackageKit-yum.i386 0:0.3.11-4.fc10
PackageKit-yum-plugin.i386 0:0.3.11-4.fc10

E con questo è tutto.

Alla prossima.

Problema con Openldap e Berkeley db dopo upgrade a FC10

Qualche giorno fa ho eseguito l’upgrade a FC10 su un server ldap. Più precisamente si tratta di una versione di Openldap con db Berkley.

Dopo l’aggiornamento il servizio non partiva per via di una incompatibilità con il db e lo script di avvio terminava con il seguente errore:

[root@server ~]# service ldap start
Checking configuration files for slapd: [FAILED]
bdb(dc=localdomain): Program version 4.6 doesn’t match environment version 4.4
bdb_db_open: database “dc=tr1″ cannot be opened, err -30972. Restore from backup!
backend_startup_one: bi_db_open failed! (-30972)
slap_startup failed (test would succeed using the -u switch)
stale lock files may be present in /var/lib/ldap [WARNING]

A questo punto ho aperto un thread su fedoraforum.org

Su suggerimento dei ragazzi del forum ho fatto una ricerca su Internet alla ricerca di un modo che mi indicasse come fare la conversione del db (l’alternativa era installare una versione precedente del Berkley DB).

Dopo una decina di minuti sono approdato sul link http://www.oracle.com/technology/documentation/berkeley-db/db/ref/upgrade/process.html

Seguendo le istruzioni riportate mi sono accorto di dover semplicemente eseguire un check sul db per renderlo “compatibile” con la nuova versione.

In realtà Fedora è dotato di un comando apposito per il check del db di ldap (slapd_db_chekpoint) così ho evitato di installare il pacchetto db4-util contenente il necessario.

Di seguito riporto i comandi impartiti che mi hanno consentito di risolvere il problema:

slapd_db_checkpoint -1 -h /var/lib/ldap
chown -R ldap.ldap /var/lib/ldap/*

Alla prossima.

OmniFind e Fedora Core 6

Tempo fa ho comprato un hard disk da mezzo tera in un centro commerciale della mia città.
Piano piano l’ho riempito di files di ogni genere: backup, posta, sorgenti, progetti, distribuzioni linux, …

In breve tempo non ero più in grado di trovare facilmente i files che mi servivano.
Così le soluzioni al problema erano due:

- Mettere in ordine l’archivio e darsi un metodo per copiare i files

- Trovare un piccolo crowler a cui richiedere i files quando servono.

Forse non tutti sanno cos’è un crowler. In parole povere si tratta di un software che indicizza le risorse in rete e le rende disponibili ad un motore di ricerca.

Ovviamente ho optato per la seconda opzione.

Durante una delle tante presentazioni sul software alle quali assisto per lavoro, sono venuto a conoscenza di Google Mini, un motore di ricerca per le aziende mantenuto da Google.
Non si tratta di un pacchetto gratuito anche perchè viene venduto insieme all’hardware su cui “gira” il motore di ricerca.

Dopo varie ricerche sono incappato su una soluzione di IBM e Yahoo! Search.

Sto parlando di OmniFind, un crowler scritto in Java e disponibile per Windows e Linux.

Ho deciso di provarlo subito ma purtroppo il supporto per Linux è limitato alla distribuzione di Red Hat Enterprise.

Questo significa che è possibile eseguire OmniFind su altre distribuzioni ma è necessario apportare le dovute modifiche al processo di installazione.

La prima cosa da fare in assoluto è disabilitare Selinux in caso sia attivo nell’ambiente operativo altrimenti l’installazione non si concluderà correttamente. Provvederemo in un secondo momento a riabilitarlo.
Chi non avesse impostato Selinux all’avvio del SO può tranquillamente ignorare i comandi che seguono.
Fedora Core mette a disposizione un semplice modo per disabilitare temporaneamente Selinux:

setenforce 0

Per verificare che il comando abbia sortito l’effetto desiderato, procediamo con una verifica:

cat /selinux/enforce

Il comando precedente dovrà restituire 0.

A questo punto è utile creare un utente di sistema con il quale eseguiremo il programma (non è consigliabile eseguire il crowler con le credenziali di root anche perchè non c’è ne la necessità):

groupadd omnifind
useradd -g omnifind omnifind
passwd omnifind

Una volta definita la password per l’utente omnifind procediamo oltre.

OmniFind utilizza una propria Java Virtual Machine, di conseguenza non è necessario installare Java sul SO. Tuttavia il crowler fa uso di librerie condivise, in particolare è necessario disporre di libstc++. Un semplice comando yum list dovrebbe essere sufficiente per fare un controllo. Per installare le librerie possiamo impartire il seguente comando:

yum install compat-libstdc++*

Adesso è possibile procedere con l’installazione di OmniFind seguendo le istruzioni incluse nel manuale del software. Prima di procedere però sostituiamo l’utente omnifind all’utente root.

su omnifind
./setuplinux_i586.bin -console

Il comando precedente prevede una installazione per la riga di comando. Chi volesse procedere in ambiente X può omettere il parametro -console.
Nel caso in cui l’installazione non andasse a buon fine, verificare che l’utente omnifind abbia i permessi di scrittura nella cartella prescelta per l’installazione.

Utilizzando i parametri di default, la directory di installazione dovrebbe essere: /opt/ibm/OmniFindYahooEdition, di conseguenza questa sarà la directory a cui faremo riferimento nei comandi successivi.

Qualora l’applicativo funzionasse alla fine dell’installazione, ritenetevi persone molto fortunate, nel mio caso infatti sono stati necessari altri passaggi.

Nel caso in cui l’esecuzione del programma non vada a buon fine, procediamo con alcune verifiche.
In primo luogo verifichiamo che tutte le librerie siano collegate correttamente:

ldd /opt/ibm/OmniFindYahooEdition/stellent.linux32/tsmanager

L’output dovrebbe essere simile al seguente:

linux-gate.so.1 => (0×00110000)
libpthread.so.0 => /lib/libpthread.so.0 (0x491c2000)
libACE.so.5.5.1 => /opt/…/stellent.linux32/libACE.so.5.5.1 (0×00125000)
libboost_date_time-gcc-mt-1_33_1.so.1.33.1 => /opt/…/stellent.linux32/libboost_date_time-gcc-mt-1_33_1.so.1.33.1 (0x0029b000)
libboost_filesystem-gcc-mt-1_33_1.so.1.33.1 => /opt/…/stellent.linux32/libboost_filesystem-gcc-mt-1_33_1.so.1.33.1 (0x002a9000)
libboost_program_options-gcc-mt-1_33_1.so.1.33.1 => /opt/…/stellent.linux32/libboost_program_options-gcc-mt-1_33_1.so.1.33.1 (0x002b9000)
libboost_regex-gcc-mt-1_33_1.so.1.33.1 => /opt/…/stellent.linux32/libboost_regex-gcc-mt-1_33_1.so.1.33.1 (0x002fd000)
libboost_serialization-gcc-mt-1_33_1.so.1.33.1 => /opt/…/stellent.linux32/libboost_serialization-gcc-mt-1_33_1.so.1.33.1 (0x0038f000)
libboost_signals-gcc-mt-1_33_1.so.1.33.1 => /opt/…/stellent.linux32/libboost_signals-gcc-mt-1_33_1.so.1.33.1 (0×00408000)
libdl.so.2 => /lib/libdl.so.2 (0x4cfdb000)
libts_utils.so => /opt/…/stellent.linux32/libts_utils.so (0x0041a000)
libts_logging_facility.so => /opt/…/stellent.linux32/libts_logging_facility.so (0×00431000)
libts_components.so => /opt/…/stellent.linux32/libts_components.so (0×00451000)
libts_soap_ext.so => /opt/…/stellent.linux32/libts_soap_ext.so (0×00461000)
libts_soap_ts_server.so => /opt/…/stellent.linux32/libts_soap_ts_server.so (0x004c9000)
libts_soap_ta_server.so => /opt/…/stellent.linux32/libts_soap_ta_server.so (0x0052f000)
libts_soap_ts_client.so => /opt/…/stellent.linux32/libts_soap_ts_client.so (0x0059e000)
libts_soap_std.so => /opt/…/stellent.linux32/libts_soap_std.so (0×00604000)
libts_soap_tss.so => /opt/…/stellent.linux32/libts_soap_tss.so (0×00687000)
libts_soap_ta_client.so => /opt/…/stellent.linux32/libts_soap_ta_client.so (0x006ea000)
libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0×00758000)
libm.so.6 => /lib/libm.so.6 (0x4cfe1000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x4d149000)
libc.so.6 => /lib/libc.so.6 (0x4ce99000)
/lib/ld-linux.so.2 (0x4ce7c000)
librt.so.1 => /lib/librt.so.1 (0x4447d000)

Nel caso in cui qualche libreria dovesse mancare, verifichiamo che selinux sia disabilitato e che libstc++ sia installato sul SO; quindi seguiamo le istruzioni riportate nel manuale per reinstallare OmniFind.

Se il servizio iptables è in uso da Linux, verifichiamo che la porta definita per contattare OmniFind sia accessibile. Di seguito le impostazioni da aggiungere al file /etc/sysconfig/iptables per abilitare i client a contattare il servizio sulla porta di default proposta dall’installazione (inserire prima del COMMIT):

-A RH-Firewall-1-INPUT -m state –state NEW -m tcp -p tcp –dport 8080 -j ACCEPT

Se anche in questo caso l’applicativo non parte, assicuriamoci che nel file /etc/hosts sia indicata la voce localhost:

::1 mycomputer.mydomain mycomputer localhost.localdomain localhost
127.0.0.1 localhost.localdomain localhost

Se il problema persiste, scrivete due righe sul problema, tenteremo insieme una soluzione.

Una volta che il servizio “parte” senza problemi, è necessario modificare le policy di selinux.
Chi avesse impostato selinux in modalità permissive può trovare tutte le modifiche da apportare dando uno sguardo ai log di sistema:

cat /var/log/messages | grep audit

chi avesse impostato Selinux in modalità enforced dovrà invece procedere per tentativi successivi.
In pratica si tratta di abilitare l’utente omnifind alla esecuzione delle librerie java. Evidenziamo di seguito i comandi impratiti da console per una singola libreria:

semanage fcontext -a -t textrel_shlib_t
/opt/ibm/OmniFindYahooEdition/_jvm/jre/bin/headless/LIBRERIA.so
restorecon /opt/ibm/OmniFindYahooEdition/_jvm/jre/bin/headless/LIBRERIA.so

Dove LIBRERIA è il nome del file inibito da Selinux.

A questo punto possiamo ripristinare selinux:

setenforce 1

Fare partire il servizio all’avvio:
Di seguito riportiamo una possibile soluzione per chi volesse far partire il crowler all’avvio di Linux:

cat > /etc/rc.d/init.d/omnifind <<EOF
#!/bin/sh
#
# chkconfig: – 99 31
# description: Starts and stops the Omnifind daemon \
#

# Source function library.
if [ -f /etc/init.d/functions ] ; then
. /etc/init.d/functions
elif [ -f /etc/rc.d/init.d/functions ] ; then
. /etc/rc.d/init.d/functions
else
exit 0
fi

# Avoid using root’s TMPDIR
unset TMPDIR

# Source networking configuration.
. /etc/sysconfig/network

# Check that networking is up.
[ ${NETWORKING} = "no" ] && exit 0

RETVAL=0

start() {
   KIND=”Omnifind”
   echo -n $”Starting $KIND service: “
   su -c /opt/ibm/OmniFindYahooEdition/bin/startup.sh omnifind
   RETVAL=$?
   echo
   return $RETVAL
}

stop() {
   KIND=”Omnifind”
   echo -n $”Shutting down $KIND services: “
   su -c /opt/ibm/OmniFindYahooEdition/bin/shutdown.sh omnifind
   RETVAL=$?
   echo
   return $RETVAL
}

restart() {
   stop
   start
}

case “$1″ in
start)
   start
   ;;
stop)
   stop
   ;;
restart)
   restart
   ;;
*)
   echo $”Usage: $0 {start|stop|restart}”
   exit 1
esac

exit $?
EOF

Il precedente comando consente di gestire Omnifind tramite chkconfig.
Per installare lo script è sufficiente impartire i seguenti comandi:

chmod 755 /etc/rc.d/init.d/omnifind
chkconfig –add omnifind
chkconfig –level 345 omnifind on

Considerazioni finali:
Secondo me OmniFind è un tool utile per le piccole aziende, almeno nella sua versione free.
Da tenere in considerazione che questa versione non gestisce la segregazione dei dati a nessun livello, di conseguenza, chi riesce a contattare il motore di ricerca, può ottenere tutti i dati indicizzati, senza discriminazioni.
E’ molto comodo da usare e riesce a tracciare il contenuto di: file PDF, files Word, files Compressi e siti web interni ed esterni alla rete locale.

Per saperne di più:
OmniFind Home Page
Cos’è un crowler