Ricerche IT

Una delle operazioni fondamentali da effettuare su un server è pianificare ed attuare una strategia per il salvataggio dei dati utilizzati sul server. In un sistema Linux esistono diversi sistemi per effettuare un backup, alcuni anche abbastanza evoluti come Amanda e Bacula (almeno per quel che ho letto, fino ad ora non li ho mai utilizzati), ma per backup non troppo complessi da effettuare su una macchina Linux (io ho preso come riferimento la mia installazione di Debian Sarge), si può utilizzare il comando tar, nato proprio con questo scopo; in questo caso, ipotizziamo di fare il salvataggio su un’unità a nastro SCSI, una Sony SDT-10000 DDS4, dispositivo localizzabile su Linux in /dev/st0. Per effettuare un backup della cartella /home/samba (e relative sottocartelle), utilizzare i comandi:

# cd /home
# tar cf /dev/st0 samba

In questo modo verrà effettuato direttamente il backup sull’unità a nastro di tutto il contenuto della cartella; in questo caso il salvataggio avviene sull’unità a nastro senza compressione, poiché ho letto da qualche parte che in caso di problemi, se si effettua un backup con compressione, viene perduto tutto ciò che verrebbe dopo il file "problematico". Se per problemi di spazio, si è comunque costretti ad utilizzare la compressione è possibile usare l’opzione -z.

Effettuato il backup, è possibile verificare il corretto salvataggio dei dati con il comando

# tar dvf /dev/st0

in modo da vedere se ci sono stati problemi durante il salvataggio.

E’ utile poter vedere anche quali file sono stati salvati su nastro, tramite il comando

# tar tf /dev/st0

Un’altra cosa utile è quella di redirigere l’output degli ultimi due comandi in un file di testo, in modo da poterli consultare molto più comodamente che non tramite console:

# tar dvf /dev/st0 > verificaBackup.txt
# tar tf /dev/st0 > listaFileBackup.txt

Da notare che gli ultimi due comandi hanno praticamente lo stesso output, e che, almeno il primo dei due, è meglio lanciarlo dalla directory da cui si è lanciato il comando per effettuare il salvataggio. Ora non rimane che vedere come si ripristinano i dati salvati su nastro:

# tar xf /dev/st0

In molti casi non è necessario ripristinare l’intero contenuto del nastro, ma solamente una sua parte, ad esempio:

# tar xf /dev/st0 samba/scambio

Ovviamente è possibile creare un piccolo script schedulabile tramite cron che effettui un salvataggio periodico dei nostri dati.

Su una rete di PC client Windows che superi la decina di host, per motivi di sicurezza e di gestione centralizzata di utenti e risorse (con tutto ciò che di positivo questo comporta), è una buona cosa avere a disposizione un dominio. Questa tipologia di dominio è stata introdotta da Microsoft, forse con NT 4 o con qualche versione precedente di NT, ed è stata poi aggiornata a partire da Windows 2000 Server con Active Directory. Se la rete non ha esigenze specifiche, sarebbe possibile comunque utilizzare anche un dominio NT invece di un dominio Active Directory. Samba permette di emulare un PDC di un dominio NT 4 e quindi di gestire utenti e risorse condivise per una rete di client Windows su un server Linux, cosa che consente di risparmiare centinaia di euro in piccole realtà che non hanno bisogno di soluzioni particolarmente sofisticate.

La prima cosa ovviamente consiste nell’installare Samba prendendo come riferimento una macchina con installato Debian Sarge, e quindi ho digitato il comando:

# apt-get install samba samba-common samba-doc cupsys cupsys-client libcupsys2-gnutls10 libkrb53 winbind smbclient libcupsys2 smbfs

A questo punto, faccio una copia del file di configurazione smb.conf e ne creo uno nuovo pulito, che andrò a personalizzarmi come meglio credo:

# mv /etc/samba/smb.conf /etc/samba/smb.old
# touch /etc/samba/smb.conf

Ora posso procedere alla configurazione di Samba editando il file smb.conf, che segue regole ben precise. Prima di tutto, va creata una sezione [global] in cui viene descritto il funzionamento generale di Samba, poi verranno create la condivisioni presenti sul server PDC con le relative impostazioni di protezione. Per fare questo, va editato il file smb.conf:

# nano /etc/samba/smb.conf

Ora va creata la sezione [global] ed impostate le direttive basilari:

[global]
workgroup = DOMAIN
netbios name = serverpdc
security = USER

La direttiva workgroup indica il nome del gruppo di lavoro o del dominio (a seconda della configurazione della direttiva security), netbios name indica il nome NetBIOS del server Samba così come verrà visto dai client Windows, mentre security indica il ruolo del server Samba: se impostato a USER indica che il server è un PDC di un dominio, mentre se impostato a SHARE, indica che il server fa parte di un gruppo di lavoro. Ci sono altre possibili impostazioni della direttiva security che al momento non sono importanti. Ora continuare la configurazione di Samba in questo modo:

smb passwd file = /etc/samba/smbpasswd
encrypt passwords = YES
log file = /var/log/samba/%m.log
max log size = 1000
log level = 1

La direttiva smb passwd file indica la posizione del file contenente le password di accesso per gli utenti Samba (esistono altri metodi più evoluti per svolgere la stessa funzione ma questo è il più semplice), encrypt password se impostato a true indica che verranno utilizzate password criptate per l’accesso al dominio. La direttiva log file indica la posizione dei file di log di Samba, e impostando il nome del file a %m.log, viene detto a Samba di creare un file di log per ogni macchina iscritta nel dominio (la variabile di Samba %m specifica il nome NetBIOS dei PC); max log size indica la dimensione massima (in KB) di ogni file di log di Samba, ed una volta raggiunta la dimensione massima il file di log viene rinominato con estensione .old, quindi, va calibrata bene la dimensione dei vari log soprattutto su reti medio-grandi, anche con l’aiuto della direttiva log level, che determina il dettaglio delle informazioni messe da Samba nei file di log, in genere il valore 1 è adeguato. La sezione [global] continua con queste impostazioni:

os level = 255
preferred master = YES
local master = YES
domain master = YES
wins support = YES

Le prime quattro direttive servono per forzare l’elezione del server Samba a Local Master Browser e Domain Master Browser, ruoli che permettono al server Samba di gestire la lista degli host presenti sulla rete locale fornendo questo servizio agli altri PC del gruppo di lavoro / dominio; os level impostato a 255 è il valore massimo, che rende sicura l’elezione del server Samba nei confronti degli altri PC in rete, anche se basterebbe un valore decisamente più basso. La direttiva wins support impostata a YES permette al PC Samba di agire come server WINS per la risoluzione dei nomi NetBIOS nei corrispondenti indirizzi IP.

hosts allow = 192.168.1.0/24 127.0.0.1
hosts deny = all
follow symlinks = NO

Queste sono impostazioni di sicurezza , in particolare hosts allow specifica gli hosts che hanno la possibilità di comunicare con il server Samba, con la successiva direttiva hosts deny = all che nega l’accesso a Samba a tutti gli host, tranne quelli specificati nella riga precedente, mentre follow symlinks, impostato a NO, impedisce ad un utente di seguire un link simbolico se questo si trova su una directory non condivisa.

domain logons = YES
logon home = \\serverpdc\homeuser
logon drive = U:
logon path = \\serverpdc\profili\%u
logon script = logon.bat
add machine script = /usr/sbin/useradd -d /dev/null -g computers -s /bin/false %u

Queste direttive indicano diverse impostazioni specifiche di un PDC Samba; domain logon = YES è la direttiva che imposta il server Samba come PDC, logon home e logon drive permettono di specificare una home directory specifica per ogni utente creato su Samba, mappando sui client l’unità di rete U: sulla condivisione "homeuser" che sarà definita più avanti nel file di configurazione. La direttiva logon path permette di abilitare i profili mobili (chiamati anche roaming profiles), che servono per avere i profili personali degli utenti del dominio sul server invece che sul client; ciò consente ad ogni utente di conservare lo stesso ambiente di lavoro su tutti i PC del dominio; secondo questa configurazione, dovrà essere creata una condivisione "profili" sul server Samba. La direttiva logon script permette di specificare un file batch da inserire nella condivisione "netlogon" (da creare) che verrà eseguito ad ogni accesso da parte degli utenti del dominio, mentre add machine script serve per creare automaticamente l’account corrispondente alla macchina come utente di sistema, senza shell ed appartenente al gruppo "computers" (questo gruppo può assumere il nome desiderato), da creare a parte come mostrato precedentemente.

L’ultimo passo, facoltativo, è quello di indicare a Samba di fungere da print server con l’utilizzo di Cups, tramite le direttive

printing = CUPS
printcap = CUPS

Ora è finita la sezione [global], quindi si può passare alla configurazione delle directory condivise. Per prima cosa creare la directory /home/samba che conterrà tutte le sotto-directory da condividere:

# mkdir /home/samba

ed aggiungere le seguenti directory:

# mkdir /home/samba/netlogon
# mkdir /home/samba/profili
# mkdir /home/samba/scambio

Ora si torna al file smb.conf per definire le condivisioni:

[netlogon]
path = /home/samba/netlogon
read only = YES
write list = root

Per prima cosa creiamo la condivisione [netlogon], in cui andremo a piazzare l’eventuale script di logon per i client Windows. Da notare le due notazioni read only impostata a YES la quale indica che l’accesso alla directory è accessibile solamente in lettura, mentre write list specifica quali utenti hanno l’autorizzazione ad accedere in lettura / scrittura alla directory (in questo caso solo l’utente root può svolgere questa funzione). Inoltre, l’eventuale creazione di un batch di avvio va fatta su un PC Windows, visto che il sistema operativo Microsoft gestisce in modo diverso l’interruzione di riga rispetto a Linux.

[profili]
path = /home/samba/profili/
read only = NO
writable = YES
browsable = NO
create mask = 0600
directory mask = 0700

Qui creiamo invece la condivisione [profili], che serve per indicare la directory in cui verranno memorizzati i singoli profili mobili degli utenti definiti su Samba. Le opzioni read only e writable sono impostate rispettivamente a NO e YES per fare in modo che la directory sia accessibile in lettura e scrittura, con i permessi indicati con le diciture create mask e directory mask, che consentono solo all’utente proprietario della directory di leggere e modificare il contenuto della cartella del proprio profilo; browsable impostato a NO significa che la condivisione non è visibile dalle risorse di rete ma rimane completamente accessibile conoscendone il percorso.

[homeuser]
path = /home/%u
writable = YES
browsable = NO
create mask = 0600
directory mask = 0700
hide dot files = YES

La condivisione [homeuser] rappresenta la home directory di ogni utente, e per comodità e per evitare problemi è meglio crearla in modo tale che l’utente Samba utilizzi la stessa home directory che utilizza il corrispondente utente Linux, com’è possibile vedere nella direttiva path, in cui è presente la variabile %u, la quale consente di definire la directory di ogni utente. Le autorizzazioni ricalcano quelle concesse nella condivisione [profili], ovvero l’unico utente abilitato in lettura e scrittura sulla share è il proprietario della cartella. In più esiste l’opzione hide dot files che consente di non visualizzare i file che iniziano con . (che Linux vede come file nascosti) sulle macchine Windows.

[scambio]
path = /home/samba/scambio
writable = YES
public = YES

La condivisione [scambio] è creata con l’obiettivo di avere un’area comune a tutti gli utenti della rete su cui tutti gli utenti possano leggere e scrivere dati, quindi basta impostare le direttive writable e public a YES per raggiungere lo scopo.

[printers]
path = /var/spool/samba
printable = YES
use client driver = YES

Per condividere stampanti su Samba, deve essere obbligatoriamente creata una condivisione [printers], che imporrà a Samba di condividere le stampanti installate su CUPS (la scelta di CUPS deriva dalle due direttive inserite nella sezione [global]). Path indica il percorso in cui è posizionato lo spooling sul quale transiteranno i job di stampa (se la directory non esiste, va creata in modo esplicito); printable impostato a YES significa che è possibile mandare job di stampa in spooling, mentre la direttiva use client driver impone ai client di installare il driver della stampante di rete quando questa viene installata su un client. Terminata la configurazione di smb.conf, rimangono altre cose da sistemare.

Per prima cosa, bisogna sistemare le autorizzazioni sulla directory /home/samba/profili, facendo in modo che tutti gli utenti della rete possano modificarne il contenuto, così che venga creata la directory del profilo per ogni utente, il cui accesso è regolato dalle direttive già impartite in smb.conf; inoltre, bisogna fare la stessa cosa per la directory scambio, in cui tutti gli utenti possono leggere e scrivere:

# chmod 777 /home/samba/profili
# chmod 777 /home/samba/scambio

Ora bisogna creare la coda di stampa su Linux per definire la stampante condivisa in Samba, quindi per prima cosa assicurarsi che la cartella /var/spool/samba esista, e poi creare la coda di stampa RAW tramite il comando:

# lpadmin -p STAMPANTECONDIVISA -v parallel:/dev/lp0 -E

dove al posto di STAMPANTECONDIVISA va messo un nome a nostra scelta che rappresenta il nome della stampante condivisa (ad esempio Laser1Piano) sul server Samba, mentre /dev/lp0 rappresenta la porta parallela del nostro PC. Creata la coda di stampa, va abilitata la stampa in RAW (cioè con l’invio dei dati grezzi alla stampante), questo serve poiché i driver della stampante devono essere installati lato client e non lato server, e quindi bisogna editare il file mime.types:

# nano /etc/cups/mime.types

decommentando la riga #application/octet e decommentare la stessa riga editando il file mime.convs:

# nano /etc/cups/mime.convs

Fatto questo, è necessario creare la directory /var/spool/samba ed assegnare i permessi in scrittura a tutti gli utenti, in modo che chiunque possa stampare sulla stampante condivisa appena creata:

# mkdir /var/spool/samba
# chmod 777 /var/spool/samba

Fatto questo e riavviato il demone cupsys, la stampante dovrebbe essere accessibile a tutti gli utenti. Nel mio caso, la stampante condivisa è un HP Laserjet 1005, e per questa stampante è necessario fare alcuni passaggi come avevo precedentemente descritto, in questo caso ho fatto un’aggiunta ed ho messo la riga cat /usr/share/foo2zjs/firmware/sihp1005.dl > /dev/lp0 nello script /etc/init.d/cupsys, in modo tale che il firmware della stampante venga inviato alla stampante stessa ad ogni avvio di CUPS. Senza questo accorgimento la stampante non vuole saperne di funzionare.

Ora bisogna creare gli utenti in Samba, infatti gli utenti di Linux non diventano automaticamente utenti di Samba, ma vanno "mappati" tra loro. Il primo utente da creare su Samba è l’utente root, che sarà anche l’amministratore del dominio Samba:

# smbpasswd -a root

e poi faremo in modo di associare il gruppo root di Linux al gruppo globale Domain Admins di Samba, poiché il gruppo Domain Admins è automaticamente amministratore sulle macchine locali una volta che queste sono iscritte al dominio, cosa molto utile per diversi motivi:

# net groupmap modify ntgroup="Domain Admins" unixgroup=root

E’ molto utile anche mappare il gruppo Samba Domain Users (che rappresenta il gruppo di tutti gli utenti del dominio) con il gruppo users di Linux, in questo modo gli utenti che verranno creati faranno automaticamente parte del gruppo Domain Users, utile in fase di assegnazione di permessi:

# net groupmap modify ntgroup="Domain Users" unixgroup=users

Ora è possibile creare gli utenti del dominio; il primo passo consiste nella creazione dell’utente sul sistema Linux, con il comando:

# useradd -m -g users nomeutente

dove l’opzione -m consente la creazione automatica della home directory all’interno della directory /home (cosa indispensabile altrimenti l’utente non si troverà connessa l’unità di rete U: rappresentante la propria home directory), l’opzione -g users assegna l’utente appena creato al gruppo users, mentre nomeutente rappresenta il nome che vogliamo dare a questo utente, ovviamente se abbiamo creato ulteriori gruppi per l’utilizzo in Samba, non sempre assegneremo l’utente appena creato al gruppo users; creato l’utente, bisogna assegnarli una password:

# passwd nomeutente

dopodiché verrà richiesto per due volte di inserire la password dell’utente. Arrivati qui è necessario creare l’utente in Samba con il comando:

# smbpasswd -a nomeutente

dove per nomeutente si intende il nome da assegnare all’utente in Samba; verrà richiesto di digitare due volte la password, ed è bene usare la stessa password per Linux e per Samba, onde evitare problemi. Per creare altri utenti e altri gruppi in Samba si può vedere un approccio leggermente alternativo qui.

Fatti questi passaggi abbiamo un server di dominio ed un print server in grado di servire una rete di client Windows.

N.B. Ho provato ad eseguire questi passaggi su Debian Etch ma con questa configurazione non funziona il join al dominio da parte dei client Windows XP, per qualche motivo che non ho ancora compreso e che sembrano legati alla versione di Samba in uso, più recente su Debian Etch.

Link di riferimento: HowToForge - Openskills - Linux Server Guida completa

Intelligent Message Filter (IMF) di Exchange Server 2003 archivia i messaggi di posta elettronica bloccati a livello di gateway in una cartella ben definita (qui maggiori dettagli). IMF però ha un difetto, cioè quello di non indicare il valore SCL (Spam Confidence Level) di ogni messaggio di posta; questo è un limite piuttosto antipatico, poiché in caso di falsi positivi bloccati a livello di gateway ed archiviati nell’apposita cartella non sapremo quali contromisure prendere.

Un modo per visualizzare il livello SCL delle singole mail però esiste, e consiste nella creazione di una voce di registro di sistema sul server Exchange, quindi andare in HKLM\Software\Microsoft\Exchange\ContentFilter e creare un nuova voce con valore DWORD e chiamarla ArchiveSCL e quindi impostarne il valore ad 1.

Ora i messaggi archiviati "per errore" da IMF nella cartella UceArchive avranno una nuova intestazione chiamata X-SCL, ed in cui a fianco compare il valore da 1 a 9 di SCL ed il corrispondente valore in percentuale. L’intestazione X-SCL è visibile semplicemente aprendo il file .eml con il blocco note.

Quando si devono esportare dei dati in una tabella di un database SQL, ovviamente la tabella di destinazione dovrà avere una chiave primaria, ed inoltre la tabella di destinazione potrà contenere dei vincoli Unique, in breve, situazioni in cui per uno o più campi non è possibile avere record duplicati.

Se la tabella di origine contiene record duplicati, ed abbiamo già impostato chiavi primarie, vincoli o indici sulla tabella di destinazione, l’esportazione non andrà a buon fine, proprio per i vincoli già impostati sulla tabella di destinazione che non permettono l’inserimento di dati se questi vincoli non vengono rispettati.

In questi casi è bene fare un’analisi preventiva sulla tabella di origine, cercando i record duplicati per capire dove intervenire per eliminarli. La ricerca di record duplicati viene effettuata tramite una semplice query come questa:

SELECT campo, count(*) AS numRecordDuplicati FROM tabellaEsempio GROUP BY campo HAVING count(*) > 1

Il risultato è una tabella in cui viene mostrato nella colonna "campo" il valore duplicato, mentre nella colonna "numRecordDuplicati" viene mostrato il numero di volte in cui il valore indicato nella colonna "campo" si ripete. Ora non rimane che analizzare i record duplicati facendo una query sulla tabella "tabellaEsempio" basata sui valori indicati ed analizzare i dati risultanti per verificare perché avviene la duplicazione.

Link di riferimento: html.it

Come tutti i sistemi operativi, Linux ha un proprio metodo per eseguire qualsiasi processo ad una determinata ora e per programmarne l’esecuzione ricorrente, in particolare ciò è possibile grazie al demone cron. Questo demone, ogni minuto controlla i file "crontab" presenti sul sistema, poiché non esiste solamente il file /etc/crontab di sistema, ma ogni utente ha la possibilità di definire il proprio file crontab; per definire un file crontab per l’utente corrente, digitare il comando

$ crontab -e

che aprirà un file di testo con nano pronto per essere editato a seconda dei processi che vorremo schedulare. Per controllare la programmazione di cron relativa al proprio utente, digitare il comando

$ crontab -l

e digitare di nuovo il comando

$ crontab -e

se si vuole modificare ulteriormente il proprio crontab.

Invece, come detto, se si vuole modificare la schedulazione "generale" del sistema, bisogna modificare il file /etc/crontab, di cui di seguito è riportato il contenuto predefinito presente su Ubuntu Server 6.10:

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

# m h dom mon dow user  command
17 *    * * *   root    run-parts –report /etc/cron.hourly
25 6    * * *   root    test -x /usr/sbin/anacron || run-parts –report /etc/cron.daily
47 6    * * 7   root    test -x /usr/sbin/anacron || run-parts –report /etc/cron.weekly
52 6    1 * *   root    test -x /usr/sbin/anacron || run-parts –report /etc/cron.monthly

I primi cinque valori indicano quando (od ogni quanto) i processi verranno eseguiti, in particolare, leggendo da sinistra verso destra, abbiamo:

• valore ‘m’: rappresenta il minuto dell’orario impostato;
• valore ‘h’: rappresenta l’ora dell’orario impostato;
• valore ‘dom’: rappresenta il giorno del mese (da 1 a 31)
• valore ‘mon’: rappresenta il mese dell’anno (da 1 a 12)
• valore ‘dow’: rappresenta il giorno della settimana (da 0 a 6, cioè da domenica a sabato)

Un tipico utilizzo di cron riguarda la procedura di backup dei dati, oppure, come in questo caso, l’aggiornamento periodico di un sistema Ubuntu tramite apt. Ad esempio, andiamo ad impostare l’aggiornamento di Ubuntu il primo di ogni mese alle ore 21. La riga corrispondente da aggiungere  al file /etc/crontab è la seguente:

0 21   1 * *   root    apt-get update && apt-get -y upgrade > /tmp/logcron.txt

Da notare l’opzione -y applicata al comando apt-get upgrade, che permette il download e l’installazione dei pacchetti di aggiornamento senza che compaiano richieste di conferma che di fatto impedirebbero l’esecuzione dell’istruzione, poiché il processo schedulato gira in background e non è possibile interagire con esso. La successiva istruzione > /tmp/logcron.txt permette di salvare l’output del comando nel file /tmp/logcron.txt cancellando tutto il contenuto del file di log, se si vuole fare aggiungere del contenuto al file di log invece di sovrascriverlo, utilizzare il simbolo >> al posto del simbolo >.

Sul sistema Ubuntu che ho utilizzato, ho abilitato l’utente root, non so se non abilitandolo la linea in crontab appena descritta porti all’esecuzione del processo. Inoltre, per questa che è essenzialmente una prova, ho messo il log nella cartella /tmp, magari se la schedulazione è sistematica, potrebbe valer la pena mettere il file di log in un’altra cartella (/var/log ?).

Link di riferimento: Wiki della comunità Ubuntu

Su un server Exchange con installato Intelligent Message Filter (IMF), la gestione dello spam avviene distinguendo ciò che il sistema ritiene palesemente spam e ciò che, nel dubbio, Exchange recapita all’utente nella cartella Posta indesiderata nella casella di posta. Ovviamente, ciò che non viene ritenuto spam, viene recapitato all’utente nella cartella predefinita Posta in arrivo, se si escludono eventuali regole.

Ciò che IMF ritiene spam al 100%, viene depositato sotto forma di file con estensione .eml (visualizzabile quindi con Outlook Express) nella cartella "C:\Program Files\Exchsrvr\Mailroot\vsi 1\UceArchive" (se non viene specificata una cartella diversa dalla cartella predefinita). Il problema principale di questo sistema è che, a quanto ne so, non esiste un modo per dire ad Exchange di cancellare il contenuto di questa cartella ogni settimana od ogni mese, e considerando che in una rete di medie dimensioni si possono tranquillamente ricevere migliaia di messaggi spam al giorno, la cartella UceArchive in un lasso di tempo relativamente breve può assumere proporzioni davvero notevoli.

Una soluzione artigianale ma efficace consiste nello schedulare un file batch che si occupi di cancellare il contenuto della cartella UceArchive una volta alla settimana oppure una volta al mese (questo dipende da quanti utenti sono presenti sulla rete locale e dal volume di mail indesiderate in arrivo sul server di posta), utilizzando un semplicissimo batch come questo:

c:
cd \
cd "program files\exchsrvr\mailroot\vsi 1\ucearchive"
del /q /f *.*

Il percorso mostrato nella terza riga del listato cambierà se è stato cambiato il percorso predefinito dell’installazione di Exchange. Salvando questo file con nome del_UceArchive.cmd e schedulando questo batch si mantiene pulita nel tempo la cartella UceArchive, evitando di sprecare inutilmente spazio.

Aggiornamento: link a programmi per gestire le mail contrassegnate come spam.