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.

Installare BackupPC su CentOS

BackupPc è sicuramente una comoda soluzione per fare il backup di più macchine in rete.
Al momento in cui scrivo, CentOS non prevede un pacchetto all’interno della propria distribuzione, rendendo l’uso del software non proprio agevole. Per questo motivo ho deciso di scrivere questa breve guida che spiega come installare e configurare il software.

Come sempre, prima di partire è bene disabilitare temporaneamente SELinux ed Iptables. Questi verranno riabilitati alla fine dell’installazione:

/usr/sbin/service iptables stop
bash: /usr/sbin/service: No such file or directory
[root@francesca /]# /sbin/service iptables stop
Flushing firewall rules:                                   [  OK  ]
Setting chains to policy ACCEPT: filter                    [  OK  ]
Unloading iptables modules:                                [  OK  ]

Come dicevamo prima, non potendo usare il repository di default, dovremo utilizzarne uno esterno:

yum install backuppc
Loaded plugins: fastestmirror, priorities
Loading mirror speeds from cached hostfile
...
Setting up Install Process
No package backuppc available.
Nothing to do

Abbiamo dunque bisogno di un repository di test. Istruzioni su come attivare repository esterni alla distribuzione sono disponibili qui.

Se avete seguito le istruzioni relative ai repository riportate nell’articolo, potrete installare backuppc tramite il comando:

yum --enablerepo=c5-testing install backuppc mod_perl httpd

Il comando provvederà ad installare anche eventuali dipendenze:

Dependencies Resolved

================================================================================
 Package                       Arch     Version              Repository    Size
================================================================================
Installing:
 backuppc                      i386     3.1.0-1.el5.centos   c5-testing   667 k
Installing for dependencies:
 perl-Archive-Zip              noarch   1.16-1.2.1           base         138 k
 perl-Class-Singleton          i386     1.03-1.2.el5.rf      rpmforge      14 k
 perl-Compress-Raw-Bzip2       i386     2.021-1.el5.rf       rpmforge     108 k
 perl-Compress-Raw-Zlib        i386     2.021-1.el5.rf       rpmforge     169 k
 perl-DateTime                 i386     0.4305-1.el5.rf      rpmforge     134 k
 perl-DateTime-Format-Mail     noarch   0.3001-1.el5.rf      rpmforge      25 k
 perl-DateTime-Format-W3CDTF   noarch   0.04-1.el5.rf        rpmforge      16 k
 perl-DateTime-Locale          noarch   0.4001-1.el5.rf      rpmforge     1.7 M
 perl-DateTime-TimeZone        i386     0.46-1.el5.rf        rpmforge     361 k
 perl-File-RsyncP              i386     0.68-1.el5.rf        rpmforge     179 k
 perl-HTML-Parser              i386     3.55-1.fc6           base          92 k
 perl-HTML-Tagset              noarch   3.10-2.1.1           base          15 k
 perl-IO-Compress              noarch   2.021-1.el5.rf       rpmforge     238 k
 perl-List-MoreUtils           i386     0.25.1-1.el5.rf      rpmforge     104 k
 perl-Params-Validate          i386     0.91-1.el5.rf        rpmforge     104 k
 perl-Time-modules             noarch   2006.0814-1.el5.rf   rpmforge      38 k
 perl-XML-Parser               i386     2.34-6.1.2.2.1       base         210 k
 perl-XML-RSS                  noarch   1.45-1.el5.rf        rpmforge      62 k
 perl-libwww-perl              noarch   5.805-1.1.1          base         376 k

Transaction Summary
================================================================================
Install     20 Package(s)
Update       0 Package(s)
Remove       0 Package(s)

Total download size: 4.7 M

Configurare il frontend
Ora è la volta di Apache che verrà utilizzato come frontend per la gestione dei backup. Seguendo l’HOW-TO riportato sul sito di CentOS la configurazione sarà modificata per consentire l’esecuzione di Apache come utente diverso.
A mio parere questo potrebbe avere implicazioni non trascurabili sulla sicurezza e sull’assetto della distribuzione, senza considerare il fatto che Apache verrebbe dedicato interamente al backup.

Preferisco invece eseguire una seconda istanza del webserver con i soli plug-in necessari a far giare BackupPC. Per questo motivo copiamo il file di configurazione esistente in un nuovo file:

cp /etc/httpd/conf/httpd.conf /etc/httpd/conf/backuppc_httpd.conf

modificando i paramentri essenziali:

PidFile run/backuppc_httpd.pid
Listen 81
User backuppc
#Allow from all

Possiamo inoltre disabilitare tutti i plug-in che non sono necessari al frontend. Per comodità riporto un file di configurazione utile come esempio:

ServerTokens OS
ServerRoot "/etc/httpd"
PidFile run/httpd_backuppc.pid
Timeout 120
KeepAlive Off
MaxKeepAliveRequests 100
KeepAliveTimeout 15
Include conf.d/perl.conf

StartServers       8
MinSpareServers    5
MaxSpareServers   20
ServerLimit      256
MaxClients       256
MaxRequestsPerChild  4000

StartServers         2
MaxClients         150
MinSpareThreads     25
MaxSpareThreads     75
ThreadsPerChild     25
MaxRequestsPerChild  0

Listen 81

LoadModule auth_basic_module modules/mod_auth_basic.so
LoadModule auth_digest_module modules/mod_auth_digest.so
LoadModule authn_file_module modules/mod_authn_file.so
LoadModule authn_alias_module modules/mod_authn_alias.so
LoadModule authn_anon_module modules/mod_authn_anon.so
LoadModule authn_dbm_module modules/mod_authn_dbm.so
LoadModule authn_default_module modules/mod_authn_default.so
LoadModule authz_host_module modules/mod_authz_host.so
LoadModule authz_user_module modules/mod_authz_user.so
LoadModule authz_owner_module modules/mod_authz_owner.so
LoadModule authz_groupfile_module modules/mod_authz_groupfile.so
LoadModule authz_dbm_module modules/mod_authz_dbm.so
LoadModule authz_default_module modules/mod_authz_default.so
#LoadModule ldap_module modules/mod_ldap.so
#LoadModule authnz_ldap_module modules/mod_authnz_ldap.so
LoadModule include_module modules/mod_include.so
LoadModule log_config_module modules/mod_log_config.so
LoadModule logio_module modules/mod_logio.so
LoadModule env_module modules/mod_env.so
LoadModule ext_filter_module modules/mod_ext_filter.so
LoadModule mime_magic_module modules/mod_mime_magic.so
LoadModule expires_module modules/mod_expires.so
LoadModule deflate_module modules/mod_deflate.so
LoadModule headers_module modules/mod_headers.so
LoadModule usertrack_module modules/mod_usertrack.so
LoadModule setenvif_module modules/mod_setenvif.so
LoadModule mime_module modules/mod_mime.so
#LoadModule dav_module modules/mod_dav.so
LoadModule status_module modules/mod_status.so
LoadModule autoindex_module modules/mod_autoindex.so
LoadModule info_module modules/mod_info.so
#LoadModule dav_fs_module modules/mod_dav_fs.so
LoadModule vhost_alias_module modules/mod_vhost_alias.so
LoadModule negotiation_module modules/mod_negotiation.so
LoadModule dir_module modules/mod_dir.so
LoadModule actions_module modules/mod_actions.so
LoadModule speling_module modules/mod_speling.so
LoadModule userdir_module modules/mod_userdir.so
LoadModule alias_module modules/mod_alias.so
LoadModule rewrite_module modules/mod_rewrite.so
#LoadModule proxy_module modules/mod_proxy.so
#LoadModule proxy_balancer_module modules/mod_proxy_balancer.so
#LoadModule proxy_ftp_module modules/mod_proxy_ftp.so
#LoadModule proxy_http_module modules/mod_proxy_http.so
#LoadModule proxy_connect_module modules/mod_proxy_connect.so
LoadModule cache_module modules/mod_cache.so
LoadModule suexec_module modules/mod_suexec.so
LoadModule disk_cache_module modules/mod_disk_cache.so
LoadModule file_cache_module modules/mod_file_cache.so
LoadModule mem_cache_module modules/mod_mem_cache.so
LoadModule cgi_module modules/mod_cgi.so
LoadModule version_module modules/mod_version.so

#ExtendedStatus On

User backuppc
Group apache

ServerAdmin root@localhost
#ServerName www.example.com:80
UseCanonicalName Off
#DocumentRoot "/var/www/html"
DocumentRoot "/var/lib/backuppc"

    Options FollowSymLinks
    AllowOverride None

    UserDir disable
    #UserDir public_html

DirectoryIndex index.html index.html.var

AccessFileName .htaccess

    Order allow,deny
    Deny from all

TypesConfig /etc/mime.types

DefaultType text/plain

#   MIMEMagicFile /usr/share/magic.mime
    MIMEMagicFile conf/magic

HostnameLookups Off

ErrorLog logs/backuppc_error_log

LogLevel warn

LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined
LogFormat "%h %l %u %t \"%r\" %>s %b" common
LogFormat "%{Referer}i -> %U" referer
LogFormat "%{User-agent}i" agent

CustomLog logs/backuppc_access_log combined

ServerSignature On

Alias /icons/ "/var/www/icons/"

    Options Indexes MultiViews
    AllowOverride None
    Order allow,deny
    Allow from all

    # Location of the WebDAV lock database.
    DAVLockDB /var/lib/dav/lockdb

IndexOptions FancyIndexing VersionSort NameWidth=* HTMLTable

AddIconByEncoding (CMP,/icons/compressed.gif) x-compress x-gzip

AddIconByType (TXT,/icons/text.gif) text/*
AddIconByType (IMG,/icons/image2.gif) image/*
AddIconByType (SND,/icons/sound2.gif) audio/*
AddIconByType (VID,/icons/movie.gif) video/*

AddIcon /icons/binary.gif .bin .exe
AddIcon /icons/binhex.gif .hqx
AddIcon /icons/tar.gif .tar
AddIcon /icons/world2.gif .wrl .wrl.gz .vrml .vrm .iv
AddIcon /icons/compressed.gif .Z .z .tgz .gz .zip
AddIcon /icons/a.gif .ps .ai .eps
AddIcon /icons/layout.gif .html .shtml .htm .pdf
AddIcon /icons/text.gif .txt
AddIcon /icons/c.gif .c
AddIcon /icons/p.gif .pl .py
AddIcon /icons/f.gif .for
AddIcon /icons/dvi.gif .dvi
AddIcon /icons/uuencoded.gif .uu
AddIcon /icons/script.gif .conf .sh .shar .csh .ksh .tcl
AddIcon /icons/tex.gif .tex
AddIcon /icons/bomb.gif core

AddIcon /icons/back.gif ..
AddIcon /icons/hand.right.gif README
AddIcon /icons/folder.gif ^^DIRECTORY^^
AddIcon /icons/blank.gif ^^BLANKICON^^

DefaultIcon /icons/unknown.gif

#AddDescription "GZIP compressed document" .gz
#AddDescription "tar archive" .tar
#AddDescription "GZIP compressed tar archive" .tgz

ReadmeName README.html
HeaderName HEADER.html

IndexIgnore .??* *~ *# HEADER* README* RCS CVS *,v *,t

AddLanguage ca .ca
AddLanguage cs .cz .cs
AddLanguage da .dk
AddLanguage de .de
AddLanguage el .el
AddLanguage en .en
AddLanguage eo .eo
AddLanguage es .es
AddLanguage et .et
AddLanguage fr .fr
AddLanguage he .he
AddLanguage hr .hr
AddLanguage it .it
AddLanguage ja .ja
AddLanguage ko .ko
AddLanguage ltz .ltz
AddLanguage nl .nl
AddLanguage nn .nn
AddLanguage no .no
AddLanguage pl .po
AddLanguage pt .pt
AddLanguage pt-BR .pt-br
AddLanguage ru .ru
AddLanguage sv .sv
AddLanguage zh-CN .zh-cn
AddLanguage zh-TW .zh-tw

LanguagePriority en ca cs da de el eo es et fr he hr it ja ko ltz nl nn no pl pt pt-BR ru sv zh-CN zh-TW

ForceLanguagePriority Prefer Fallback

AddDefaultCharset UTF-8

AddType application/x-compress .Z
AddType application/x-gzip .gz .tgz

AddHandler type-map var

AddType text/html .shtml
AddOutputFilter INCLUDES .shtml

Alias /error/ "/var/www/error/"

        AllowOverride None
        Options IncludesNoExec
        AddOutputFilter Includes html
        AddHandler type-map var
        Order allow,deny
        Allow from all
        LanguagePriority en es de fr
        ForceLanguagePriority Prefer Fallback

BrowserMatch "Mozilla/2" nokeepalive
BrowserMatch "MSIE 4\.0b2;" nokeepalive downgrade-1.0 force-response-1.0
BrowserMatch "RealPlayer 4\.0" force-response-1.0
BrowserMatch "Java/1\.0" force-response-1.0
BrowserMatch "JDK/1\.0" force-response-1.0

BrowserMatch "Microsoft Data Access Internet Publishing Provider" redirect-carefully
BrowserMatch "MS FrontPage" redirect-carefully
BrowserMatch "^WebDrive" redirect-carefully
BrowserMatch "^WebDAVFS/1.[0123]" redirect-carefully
BrowserMatch "^gnome-vfs/1.0" redirect-carefully
BrowserMatch "^XML Spy" redirect-carefully
BrowserMatch "^Dreamweaver-WebDAV-SCM1" redirect-carefully

alias /backuppc /usr/share/backuppc

   SetHandler perl-script
   PerlResponseHandler ModPerl::Registry
   PerlOptions +ParseHeaders
   Options +ExecCGI
   Order deny,allow
   Deny from all
   Allow from 192.168.0
   Allow from 127.0.0.1
   AuthName "Backup Admin"
   AuthType Basic
   AuthUserFile /var/lib/backuppc/passwd/htpasswd
   Require valid-user

Per verificare che il file sia formalmente valido possiamo eseguire un test preliminare:

/usr/sbin/httpd -f /etc/httpd/conf/backuppc_httpd.conf -t
Syntax OK

Prima di provare il servizio impostiamo una password per l’accesso al frontend:

htpasswd -c /var/lib/backuppc/passwd/htpasswd backup_manager
New password: your_password
Re-type new password: your_password
Adding password for user backup_manager

Arriva ora il momento di avviare una seconda instanza di Apache per verificare che tutto sia in ordine:

/usr/sbin/httpd -f /etc/httpd/conf/backuppc_httpd.conf -k start

Se tutto funziona correttamente possiamo procedere con le opportune modifiche necessarie a far partire il servizio all’avvio del sistema. Anche in questo caso faremo una copia del file utilizzato dal webserver:

cp /etc/init.d/httpd /etc/init.d/backuppc_httpd

Anche in questo caso per comodità riporto un esempio:

#!/bin/bash
#
# backuppc_httpd   Startup script for the Apache HTTP Server (BackupPC)
#
# chkconfig: - 90 34
# description: BackupPC stand alone web server 

# 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 1

RETVAL=0

start() {
   KIND="BackupPC Web Server"
   echo -n $"Starting  service: "
   /usr/sbin/httpd -f /etc/httpd/conf/backuppc_httpd.conf -k start && echo "OK" || echo "Error"
   RETVAL=0
   echo
   return
}

stop() {
   KIND="BackupPC Web Server"
   echo -n $"Shutting down  services: "
   /usr/sbin/httpd -f /etc/httpd/conf/backuppc_httpd.conf -k stop && echo "OK" || echo "Error"
   RETVAL=0
   echo
   return
}

restart() {
   stop
   sleep 5
   start
}

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

exit 0

Useremo chkconfig per rendere il servizio attivo all’avvio:

/sbin/chkconfig backuppc_httpd --add
/sbin/chkconfig --level 2345 backuppc_httpd on

Configurare BackupPC
Finito con il frontend passiamo a personalizzare il file /etc/BackupPC/config.pl che contiene i parametri necessari al backup. L’articolo si occupa di spiegare come configuare CentOS per la corretta esecuzione del pacchetto. Per maggiori informazioni è necessario seguire l’help online.

Una modifca importante da fare però riguarda la necessità di dover dare all’utente backuppc l’accesso all’intero file system tramite il comando tar altrimenti non sarà possibile procedere con il backup completo del sistema. Editiamo il file /etc/sudoers impostando i seguenti parametri:

#Defaults    requiretty
Defaults !lecture

backuppc ALL=NOPASSWD:/bin/gtar,/bin/tar

Come abbiamo già fatto per il frontend, possiamo abilitare l’avvio automatico del servizio tramite chkconfig:

chkconfig backuppc on

Prima di concludere
Al momento in cui scrivo questo articolo, esiste un piccolo baco facile da risolvere. Se per caso i link alla documentazione in linea non dovessero funzionare, potete eseguire i seguenti comandi per ripristinarli:

mkdir /usr/doc
ln -s /usr/share/doc/backuppc*/BackupPC.html /usr/doc/BackupPC.html

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