Introduzione e installazione di LinuxIntroduzione e visione d'insieme Obiettivo: |
Linux AdministratorIntroduzione all'arte sistemistica Installare LinuxRaccolta informazioni. Scelta dell'hardware. Definizione degli obiettivi. Opzioni di installazione. CobblerDocumentation, examples and use of Cobbler Linux Provisioning System |
Assegnazione di IP e nomi in una LANIN questo capitolo si valutano le possibilità di usare Linux come server DHCP e come DNS resolver per una rete interna Obiettivo: |
DHCP serverProtocollo, installazione, configurazione ed uso di un server DHCP (ISC) Installazione e gestione di BINDInstallazione di BIND tramite RPM e sorgenti, file installati e posizioni. Gestione del servizio. Configurazione di BINDConfigurazione di BIND - In particolare la versione 9.x |
Condivisione dell'accesso ad InternetConoscere e implementare le soluzioni di accesso condiviso ad Internet con Linux Obiettivo: |
Linux firewalling: Introduzione a IptablesOverview, gestione, utilizzo di iptables su Linux per packet filtering iptables - Linux natting e packet manglingUtilizzo di iptables per natting, masquerading e mangling di pacchetti. SQUID Proxy serverInstallazione e configurazione del proxy server Squid Traffic monitoringTools per il monitoraggio del traffico IP |
Mail server in una rete localeLe problematiche e gli utilizzi di un server di posta interno. Obiettivo: |
Il protocollo SMTPSimple Mail Transfer Protocol: sintassi base Installazione e gestione di SendmailInstallazione di Sendmail tramite RPM e sorgenti, file installati e posizioni. Gestione del servizio Configurazione di SendmailFile di configurazione e settaggio dei parametri di Sendmail PostfixInstallazione, configurazione, gestione Soluzioni AntivirusRassegna delle soluzioni antivirus server based Meccanismi Anti-SpamVerifica relay e implementazione di sistemi anti-spam FetchmailOverview e approfondimenti su fetchmail |
Usare SambaAnalisi della configurazione di Samba, gestione del servizio, reperimento documentazione. Utilizzo si Samba in ambienti misti. Obiettivo: |
File sharing in una rete localeVisione d'insieme sul file sharing in LAN e le alternative possibili Il protocollo CIFS/SMBCommon Internet File System / Server Message Block Installazione e gestione di SambaInstallazione di Samba tramite RPM e sorgenti, file installati e posizioni - Gestione del servizio Documentazione e tool di configurazione di SambaManuali, libri, documentazione online, risorse e tool grafici di configurazione su Samba Configurazione di SambaFile di configurazione e settaggio dei parametri base e avanzati. SMB troubleshootingUtilizzo dei log, del debug e di altri strumenti di diagnosi. Stampa e condivisione stampantiLa stampa su Linux e la condivisione delle stampanti in rete. Reti miste Windows - LinuxCasi e situazioni comuni con rete miste Windows-Linux - WINS - PDC. Samba securityBreve rassegna della security history, problematiche attuali |
Linux Administrator |
Introduzione all'arte sistemistica |
Tipo Infobox: DESCRIPTION - Skill Level: 1- NOVICE - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2006-03-23 11:55:26
Spiegare cosa fa un sistemista non è sempre ovvio.
Definire quali sono i suoi compiti è quantomeno pretenzioso.
Inquadrare gli skill di cui ha bisogno è limitativo, visto che di fatto, in molte realtà, un sistemista deve poter gestire e configurare hardware e software eterogenei che richiedono conoscenze ed esperienza disparate.
Le attività sistemistiche su un server con qualsiasi sistema operativo variano a seconda delle funzioni della macchina e del contesto lavorativo.
Generalmente il sistemista si dovrebbe preoccupare di:
1- Partecipare a riunioni e fornire la propria opinione sulla definizione dell'infrastruttura informatica e la scelta e il dimensionamento dell'hardware da utilizzare;
2- Installare le macchine;
3- Eseguire le procedure di post-installazione standard (aggiornamento software, rimozione servizi inutili, hardening del sistema, installazione di script e procedure custom);
4- Installare, configurare e testare i servizi richiesti per la macchina;
5- Monitorare performance, sicurezza e funzionalità del sistema;
6- Assistere e assecondare le richieste dirette o indirette degli utenti del sistema (sviluppatori e utenti dei servizi);
7- Eseguire backup e ripristino dei dati;
8- Automatizzare varie procedure nel sistema;
8- Documentare approfonditamente il lavoro svolto.
Troppo spesso il sistemista:
1- Non viene interpellato per una consulenza sulle tecniche più adeguate per le esigenze richieste;
2- Racka, cabla, se necessario smonta e rimonta, e installa le macchine;
3- Non ha una procedura standard di post installazione a cui attenersi;
4- Installa e configura i servizi necessari per la macchina, non sempre li testa a dovere;
5- Non controlla quasi mai i log di sistema, non implementa procedure di controllo;
6- Asseconda gli utenti ma li odia;
7- A volte prevede il backup dei dati, raramente esegue test di recupero;
8- Ripete spesso i soliti comandi;
9- La migliore documentazione la mantiene in testa, il resto in qualche file sul proprio computer.
Generalmente il tutto si spiega e si tende a giustificare con la cronica mancanza di tempo, spesso basterebbe un po' di lucidità progettuale e lungimiranza per riuscire ad ottenere tutti i risultati e alla lunga risparmiare tempo.
- La documentazione è fondamentale: permette di mantenere memoria storica del funzionamento dei sistemi e mette in grado il sistemista di delegare a colleghi meno esperti o appena arrivati di svolgere correttamente il lavoro che dovrebbe svolgere da solo.
- La partecipazione alle decisioni tecniche va richiesta con la giusta insistenza. E se ci ritrova a dover eseguire lavori, imposti dall'altro e tecnicamente discutibili, è doveroso quantomeno esprimere il proprio dissenso e suggerire le alternative più adeguate.
- Nonostante il knowledge generalmente vasto e variegato che spesso un sistemista deve avere, il suo compito di fatto è oscuro ai molti e a volte considerato di importanza trascurabile. Di solito ci si accorge del contrario quando un sistema in produzione va down e qualcuno deve farlo tornare a a funzionare.
- L'utente che usa i servizi della macchina o lo sviluppatore che riempe i contenuti di un sito web, per quanto generalmente poco sensibili alle esigenze e condizioni del sistemista, NON può e NON deve essere considerato un nemico. Di fatto è il motivo per cui il sistemista lavora e, in ogni caso, non ce se ne può disfare. L'unico modo per conviverci al meglio è educarlo all'uso del sistema e capire cosa gli serve per ridurre problemi e tempi di implementazione.
- Per quanto possibile è sempre consigliabile mantenere hardware e software omogenei: hardware dello stesso fornitore e non eterogeneo riduce complicazioni e velcoizza la sostituzione di pezzi di ricambio. Sistemi allineati (stesso OS, stessa distribuzione, stessa versione) rendono più facile, comoda e rapida l'attività sistemistica: gli aggiornamenti di software e kernel possono essere più rapidi e viene ottimizzato il tempo per seguire le problematiche di sicurezza di un sistema operativo.
SOURCE: Linux Corso Base - Coresis - http://www.coresis.com/linux/corsobase/
SOURCE: La Vera Storia di Linux Torwalds - Articolo su Apogeo OpenPress - http://www.apogeonline.com/openpress/articoli/art_9.html
Tipo Infobox: TIPS - Skill Level: 1- NOVICE - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2006-03-24 12:43:11
Scegliere la distribuzione giusta fra le centinaia disponibili è impresa ardua, come lo è ottenere una risposta precisa da un "esperto di Linux".
Inevitabilmente, da bravo informatico, risponderebbe "dipende".
In genere, la migliore distribuzione da usare è quella che meglio si conosce e se si devono gestire diverse macchine è opportuno averle tutte con la stessa distribuzione e possibilmente versione, per facilità e rapidità di aggiornamente e manutenzione.
Qualunque sia la distro adottata è spesso consigliabile installarne l'ultima versione disponibile (contiene pacchetti e kernel più recenti) lasciando possibilmente passare almeno un mese dalla sua release per permettere il fixing dei bug e dei buchi di sicurezza più evidenti.
Fondamentale è comunque seguirne sul relativo sito le segnalazioni di aggiornamenti ("errata" o "patch"), possibilmente attivando sistemi di autoaggiornamento dei pacchetti.
Considerare che dopo l'installazione di una qualsiasi distribuzione, se si sta lavorando su un server che deve andare in produzione, sono auspicabili, consigliati e necessari una serie di interventi di post installazione:
- Aggiornamento di tutti i pacchetti per i quali esistono degli errata (nuove versioni che aggiornano bug o buchi di quelle rilasciata con il CDROM originale);
- Rimozione di tutti i servizi Internet non utilizzati;
- Eventuale aggiornamento del kernel;
- Configurazione dei servizi di produzione che si intende utilizzare;
- Implemementazione di script o configurazioni custom.
Nella scelta della distribuzione vanno valutati i seguenti aspetti e date risposte alle seguenti domande:
- In che contesto viene utilizzata?
Su un server, su un laptop, un dekstop... A seconda delle funzionalità richieste può essere adeguata una distribuzione piuttosto che un'altra.
Ci sono distribuzioni come Ubuntu, Mepis, Linspire, Xandros che sono particolarmente orientate al desktop e si differenziano per facilità di utilizzo o presenza di programmi per Internet e il multimedia in grado di soddisfare le tipiche esigenze di un poweruser.
Per un firewall esistono distribuzioni dedicate che possono risultare particolarmente comode e semplici da configurare.
Per un server è opportuno cercare distribuzioni con tempi di vita lunghi e in grado di riconoscere e supportare il proprio hardware.
- Che tempo di vita mi aspetto da questa installazione?
Un computer desktop può essere reinstallato in tempi relativamente brevi, quantomeno per rincorrere le nuove versioni di vari programmi comuni, un server può richiedere tempi di vita molto maggiori e questo influenza la scelta.
Un vizio comune a molte distribuzione sono i tempi di release estremamente rapidi, tali da rendere apparentemente obsoleta una versione dopo pochi mesi dal suo rilascio.
Questo vale in modo evidente con Fedora (una release indicativamente ogni 6 mesi, fine del supporto ufficiale di RedHat dopo 2 release) ma anche, in misura minore, per le versioni Personal/Professional di Mandriva, Suse e altre fra le distribuzioni principali.
Questa costante rincorsa è dovuta al tumultuoso e rapido sviluppo di software opensource e al fatto che difficilmente all'interno della stessa versione di una distribuzione viene fatto un "major upgrade" dei programmi forniti (per garantire la piena compatibilità e il funzionamento delle procedure di aggiornamento automatico del software (per bug e vulnerabilità di sicurezza)).
Fra le distribuzioni liberamente accessibili, Debian e in misura minore Slackware si distinguono per tempi di vita decisamente superiori. Debian, in particolare, ha un ramo "stable" particolarmente conservativo che ha tempi di vita molto lunghi a scapito di una certa obsolescenza del software fornito.
Se la necessità è di avere un sistema Linux per poche ore o alcuni giorni (per dimostrazioni, corsi, prove, test, ecc) le Live CD come Knoppix sono particolarmente indicate, in quanto non richiedono nemmeno l'installazione su hard disk.
- Quanto sono disposto a spendere per la licenza del mio Linux?
Le versioni commerciali delle distribuzioni Linux hanno tempi di vita e supporto generalmente maggiori e sono adatte ad ambienti in cui è prioritario avere garanzia di supporto duraturo rispetto ai costi di licenza.
RedHat, Suse/Novell, Mandriva forniscono tutte versioni "enterprise" a pagamento delle proprie distribuzione con tempi di supporto di vari anni e durata di vita del software molto superiori alle versioni liberamente distribuite dagli stessi produttori.
Nella analisi dei costi, ovviamente, vanno anche considerati il training del personale, la consulenza di esterni, i tempi di disservizio eventualmente dovuti a guasti o problemi, ecc.
- La distribuzione che voglio usare supporta l'hardware che ho a disposizione?
Per quanto il supporto hardware su Linux sia piuttosto avanzato esistono casi in cui va opportunamente verificato. In particolare non tutte le distribuzioni sono in grado di riconoscere immediatamente i device di un laptop (winmodem, scheda wireless connettori infrarossi ecc.) e, per sistemi di fascia medio/alta con controller scsi è schede di retei in gigabit è opportuno verificarne il supporto nella hardware compatibility list del produttore della distribuzione.
Installare Linux |
Raccolta informazioni. Scelta dell'hardware. Definizione degli obiettivi. Opzioni di installazione. |
Tipo Infobox: DESCRIPTION - Skill Level: 1- NOVICE - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2006-03-23 12:01:19
L'installazione di Linux è ormai una operazione piuttosto semplice, visto il progresso evidente che molte distribuzioni hanno avuto negli ultimi anni in termini di facilità d'uso.
Nonostante questo esistono alcune informazioni fondamentali che vanno conosciute, in particolare per i casi in cui si intende installare Linux su un computer dove è già installato, e si vuole mantenere, Windows.
Sapere com'è il proprio sistema, come e dove si vuole installare Linux, nel caso sia presente già un altro sistema operativo, è fondamentale, per cui è bene assicurarsi, prima di procedere, di conoscere le informazioni di base riguardo a:
- Hardware a disposizione. Solitamente durante l'installazione il proprio hardware viene rilevato automaticamente, ma possono esserci rari casi in cui questo non accade. In genere se si usa un PC standard con una nuova distribuzione non ci sono problemi nel riconoscimento di componenti e periferiche.
- Sapere quali e quanti Hard Disk sono presenti sul sistema, come sono partizionati, quali sono cancellabili. Queste informazioni sono visualizzabili durante l'installazione, ma si deve essere certi di sapere dove sono i dati (per esempio, una installazione di Windows esistente) che non si vogliono cancellare.
- Configurazione di rete, se prevista (indirizzo IP, subnetmask, nome macchina, server DNS).
- Il tipo di attività che si intende fare con Linux (si userà come workstation o come server? si installa su un portatile? Si ha idea di quale software si vorrà usare?).
Gli scenari possibili sono vari, dipendono dalle singole situazioni e possono riassumersi in questi casi generali:
- Installazione su un computer esclusivamente dedicato a Linux (con o senza dati presenti sull'hard disk, che comunque si intende cancellare). Questo è il caso più semplice e se si ha a che fare con hardware non particolarmente esotico (normale PC, di marca, o assemblato, con processore Pentium o superiore) non dovrebbe creare alcun problema con una distribuzione recente.
- Installazione su un PC dove è già presente Windows e si ha a disposizione un hard disk libero o una partizione completamente libera all'interno dell'hard disk con Windows. Anche in questo caso l'installazione può procedere senza particolari problemi: durante le sue fasi verranno evidenziate le partizioni presenti sull'hard disk e sarà possibile decidere di utilizzare per Linux quelle libere, senza toccare quelle in cui si trova Windows.
- Installazione su un PC dove è presente Windows e non è disponbile un hard disk aggiuntivo, spazio non partizionato o una partizione sacrificabile. Questo purtroppo, oltre ad essere il caso più ostico, per un normale computer domestico, è anche il più comune. In queste situazioni si possono seguire diverse strade:
-- Provare Linux con un Live CD (come Knoppix) che permette di usare Linux senza installarlo sull'harddisk, eseguendo il boot direttamente dal CDROM. Non è una soluzione definitiva (un sismile approccio ha degli inevitabili limiti e minori performance) ma può essere un ottimo modo per iniziare a familiarizzare con Linux senza alcun bisogno di installarlo e in completa sicurezza.
-- Procurarsi un hard disk aggiuntivo (di 1 GB o più) e aggiungerlo al proprio PC (indicativamente come Secondary Master, lasciando Windows sul Primary Master) per poterlo usare liberamente con Linux.
-- Creare dello spazio sull'hard disk esistente: se si hanno partizioni quasi vuote, spostare i dati presenti, in altre partizioni Windows e "sacrificare" la partizione semi-vuota per l'installazione Linux; alternativamente considerare la possibilità di usare strumenti come Fips o Partition Magic per Windows o Parted per Linux (lanciato da un Live CD) per ridurre la dimensione delle partizioni esistenti e creare spazio per Linux.
Fare massima attenzione a simili procedure: se fatte in modo scorretto o interrotte (per esempio da un blackout) possono definitivamente compromettere i dati presenti sul proprio hard disk. Un backup preventivo dei propri file, seppur di solito non necessario, è generalmente consigliato.
-- Installazione su PC con hardware particolare o architetture non basate su processori tipo Intel o AMD (i386).
In questi casi la procedura di installazione può essere più complicata (per la richiesta di driver aggiuntivi per gestire l'accesso al disco) o non riconoscere alcuni dispositivi e schede (per esempio i modem interni).
Se si vuole installare Linux su Mac o sistemi con architettura non Intel-like, sono necessarie distribuzioni particolari e procedure a volte più complesse.
HOWTO: The Linux Installation HOWTO - http://ldp.openskills.info/HOWTO/Installation-HOWTO/index.html
Tipo Infobox: DESCRIPTION - Skill Level: 1- NOVICE - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2003-09-20 11:13:35
Una scelta importantissima è quella della configurazione hardware, dal numero di interfacce di rete al numero di processori, dalla dimensione dei dischi fissi a quanta ram utilizzare.
Ormai Linux offre una vasta compatibilità con la maggior parte dell'hardware esistente, sia direttamente a livello di kernel ufficiale, sia con driver rilasciati direttamente dai produttori, inoltre, per il vero hacker, avendo a disposizione i sorgenti del kernel, c'è sempre la possibilità ultima di scriversi autonomamente i propri driver.
Segue un breve quadro sulla scelta dell'hardware, si rimanda ai link indicati per informazioni più dettagliate:
CPU
Le distribuzioni standard contengono un Linux predisposto per processori Intel Based a 32 bit. (dal 386 al Pentium 4 Intel, oltre a compatibili quali AMD Athlon, Cyrix, Transmeta ecc.) Se si vuole installare Linux su un Mac, una Sun o un Compaq Alpha si deve trovare una distribuzione per PowerPC, Sparc o Alpha.
La potenza del processore dipende ovviamente dalle applicazioni usate, un Pentium 2 o superiore basta per normali applicazioni server senza eccessivo carico. Esiste il supporto multiprocessore.
RAM
Come sempre, più ce n'è, meglio è. Se si usa Linux senza interfaccia grafica, le esigenze sono modeste: 64Mb bastano per un sistema base, ma sono ovviamente da aumentare per server che devono gestire volumi di traffico medio/alti o ospitare applicativi pesanti.
HARD DISK
La scelta fra un sistema (E)IDE o SCSI dipende essenzialmente dal budget a disposizione. In genere, prima di pensare ad un sistema SCSI è opportuno "carrozzare" la macchina con un buon processore e abbastanza memoria. Il supporto per schede SCSI è ottimo.
CDROM - FLOPPY
Un normale CD-ROM IDE o SCSI basta e avanza (di fatto, per un server, serve solo in fase di installazione). Il floppy può mancare se la motherboard supporta il boot direttamente dal CD (funzione comune in tutte le motherboard non vecchie). E' disponibile il supporto di CD-RW.
SCHEDA VIDEO
Per un server (su cui si avrà soltanto l'interfaccia a caratteri) basta una semplice VGA. Per un desktop con interfaccia visuale il minimo è una SVGA.
E' disponibile l'accelerazione 3D su schede che supportano OpenGL.
SCHEDA RETE
Si consiglia una scheda ethernet 10/100. Esistono driver per alcune schede gigabit, ma è opportuno verificarne l'esistenza per il proprio hardware.
Esiste anche il supporto per Token Ring, schede wireless e WAN cards.
ACCESSORI MULTIMEDIALI
Per un server non sono necessarie schede audio o accessori multimediali. I kernel dalla 2.4 in su, comunque supportano le Sound Blaster Live e Audigy, schede audio meno recenti e le periferiche USB. Esiste anche il supporto Firewire.
MODEM
I modem esterni (analogici o ISDN) su interfaccia seriale (meglio) o USB sono normalmente utilizzabili.
Possibili complicazioni esistono per modem interni (Winmodem), che in genere sono sconsigliabili e tipicamente si trovano su portatili.
LINK: Un sito completo sul Linux Hardware - http://www.linuxhardware.net/
LINK: Linux Hardware Database su ZDNET - http://lhd.zdnet.com/
HOWTO: The Linux 3Dfx HOWTO - http://ldp.openskills.info/HOWTO/3Dfx-HOWTO.html
HOWTO: Framebuffer HOWTO - http://ldp.openskills.info/HOWTO/Framebuffer-HOWTO.html
HOWTO: i810 with XFree86 4.x HOWTO - http://ldp.openskills.info/HOWTO/i810-HOWTO/index.html
HOWTO: Nvidia OpenGL Configuration mini-HOWTO - http://ldp.openskills.info/HOWTO/Nvidia-OpenGL-Configuration/index.html
HOWTO: ATI R200 + XFree86 4.x mini-HOWTO - http://ldp.openskills.info/HOWTO/XFree86-R200/index.html
HOWTO: Brief Introduction to Alpha Systems and Processors - http://ldp.openskills.info/HOWTO/Alpha-HOWTO.html
HOWTO: CPU Design HOW-TO - http://ldp.openskills.info/HOWTO/CPU-Design-HOWTO.html
HOWTO: The Elite's K7s5a mainboard HOWTO - http://ldp.openskills.info/HOWTO/K7s5a-HOWTO.html
HOWTO: Linux/MIPS HOWTO - http://ldp.openskills.info/HOWTO/MIPS-HOWTO.html
HOWTO: SPARC-HOWTO. - http://ldp.openskills.info/HOWTO/SPARC-HOWTO.html
HOWTO: CD-Writing HOWTO - http://ldp.openskills.info/HOWTO/CD-Writing-HOWTO.html
HOWTO: The Linux CD-ROM HOWTO - http://ldp.openskills.info/HOWTO/CDROM-HOWTO/index.html
HOWTO: Linux DVD HOWTO - http://ldp.openskills.info/HOWTO/DVD-HOWTO.html
HOWTO: Linux - Optical Disk HOWTO - http://ldp.openskills.info/HOWTO/Optical-Disk-HOWTO.html
HOWTO: The Linux keyboard and console HOWTO - http://ldp.openskills.info/HOWTO/Keyboard-and-Console-HOWTO.html
HOWTO: Remote Serial Console HOWTO - http://ldp.openskills.info/HOWTO/Remote-Serial-Console-HOWTO/index.html
HOWTO: Linux ATA RAID HOWTO - http://ldp.openskills.info/HOWTO/ATA-RAID-HOWTO/index.html
HOWTO: Linux DPT Hardware RAID mini-HOWTO - http://ldp.openskills.info/HOWTO/DPT-Hardware-RAID.html
HOWTO: Jaz-drive HOWTO - http://ldp.openskills.info/HOWTO/Jaz-Drive-HOWTO.html
HOWTO: The 3 Button Serial Mouse mini-HOWTO - http://ldp.openskills.info/HOWTO/3-Button-Mouse.html
HOWTO: Linux ACP Modem (Mwave) mini-HOWTO - http://ldp.openskills.info/HOWTO/ACP-Modem/index.html
HOWTO: Cable Modem Providers HOWTO - http://ldp.openskills.info/HOWTO/Cable-Modem/index.html
HOWTO: Modem-HOWTO - http://ldp.openskills.info/HOWTO/Modem-HOWTO.html
HOWTO: Linksys Blue Box Router HOWTO - http://ldp.openskills.info/HOWTO/Linksys-Blue-Box-Router-HOWTO/index.html
HOWTO: The Linux 2.4 SCSI subsystem HOWTO - http://ldp.openskills.info/HOWTO/SCSI-2.4-HOWTO/index.html
HOWTO: The Linux SCSI Generic (sg) HOWTO - http://ldp.openskills.info/HOWTO/SCSI-Generic-HOWTO/index.html
HOWTO: The Linux SCSI programming HOWTO - http://ldp.openskills.info/HOWTO/SCSI-Programming-HOWTO.html
HOWTO: The Linux MIDI-HOWTO - http://ldp.openskills.info/HOWTO/MIDI-HOWTO.html
HOWTO: Sound Blaster AWE 32/64 HOWTO - http://ldp.openskills.info/HOWTO/Soundblaster-AWE.html
HOWTO: Ftape-HOWTO - http://ldp.openskills.info/HOWTO/Ftape-HOWTO.html
HOWTO: Linux Touch Screen HOWTO - http://ldp.openskills.info/HOWTO/XFree86-Touch-Screen-HOWTO.html
HOWTO: The UPS Howto - http://ldp.openskills.info/HOWTO/UPS-HOWTO.html
HOWTO: Wireless Howto - http://ldp.openskills.info/HOWTO/Wireless-HOWTO.html
HOWTO: Linux Infrared HOWTO - http://ldp.openskills.info/HOWTO/Infrared-HOWTO/index.html
HOWTO: Linux PCI-HOWTO - http://ldp.openskills.info/HOWTO/PCI-HOWTO.html
HOWTO: Linux PCMCIA HOWTO - http://ldp.openskills.info/HOWTO/PCMCIA-HOWTO.html
HOWTO: Plug-and-Play-HOWTO - http://ldp.openskills.info/HOWTO/Plug-and-Play-HOWTO.html
HOWTO: Smart Card HOWTO - http://ldp.openskills.info/HOWTO/Smart-Card-HOWTO/index.html
HOWTO: VCR-HOWTO - Using your GNU/Linux computer as a VCR - http://ldp.openskills.info/HOWTO/VCR-HOWTO.html
Tipo Infobox: DISTRO - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2002-08-19 16:37:21
Molte distribuzioni hanno una propria pagina dedicata all'hardware supportato. Seguire i link per dettagli.
Considerare che il supporto hardware di Linux dipende dal kernel più che dalle singole distribuzioni.
Una distribuzione più recente ha maggiori probabilità di supportare una gamma maggiore di hardware, avendo, presumibilmente, un kernel più recente.
LINK: Red Hat - Linux Hardware Compatibility List - http://www.redhat.com/support/hardware/
LINK: Mandrake - Hardware Database - http://www.linux-mandrake.com/en/hardware.php3
LINK: Caldera - Compatible Hardware - http://www.caldera.com/support/hardware/
LINK: SUSE - Linux Component DataBase - CDB - http://hardwaredb.suse.de/index.php?LANG=en_UK
LINK: Yellow Dog Linux - Power PC hardware support - http://www.yellowdoglinux.com/support/hardware/
LINK: Mandrake - Hardware Database - http://www.linux-mandrake.com/en/hardware.php3
LINK: DMOZ - Categoria Linux Hardware Support - http://dmoz.org/Computers/Software/Operating_Systems/Linux/Hardware_Support/
LINK: Turbolinux - Hardware supported - http://www.turbolinux.com/hcl/
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2003-11-12 21:37:27
L'installazione di Linux si può eseguire seguendo metodi differenti: generalmente si usa il CD-ROM (ogni PC almeno dal 1998 in poi permette il boot diretto da CD) oppure via floppy ma sono possibili anche installazioni centralizzate via rete (via http, ftp, nfs, smb) particolarmente utili quando si devono gestire ed installare un gran numero di macchine.
Il primo e fondamentale punto da considerare è lo spazio su hard disk dove installare il sistema operativo.
E' necessario avere a disposizione un hard disk almeno parzialmente libero. Qualora fosse necessario liberare spazio su disco e creare una partizione, si può usare il programma Parted, gratuito per Linux e presente su un Live CD come Knoppix, o programmi per Windows come Partition Magic (commerciale) o Fips (gpl).
Solo quando si è sicuri di avere una partizione o un hard disk disponibile (i dati eventualmente presenti verrebbero cancellati), si può procedere con l'installazione vera e propria.
Sebbene ogni distribuzione utilizzi un proprio tool di setup, le procedure sono generalmente le stesse:
- Viene caricato da CD o floppy di boot un sistema Linux temporaneo, tramite il quale è possibile lanciare il tool di installazione ed eseguire tutte le operazioni previste.
- Viene partizionato lo spazio su disco disponibile secondo i criteri definiti dall'utente;
- Vengono formattate le partizioni create, con il filesystem scelto;
- Si selezionano i programmi da installare, scegliendoli individualmente o selezionando delle impostazioni di default a seconda del tipo di sistema che si sta creando: desktop, server, stazione di sviluppo, laptop ecc. Il sistema provvede automaticamente ad installare le dependencies (pacchetti non selezionati dall'utente ma necessari per poter far funzionare quelli scelti). Se il computer è per un uso personale (desktop) e lo spazio su Hard Disk non manca ( > 2Gb ) ci si può sbizzarrire ad installare un po' di tutto, per verificare la funzionalità di programmi diversi. I programmi scelti vengono copiati sulle partizioni appena formattate.
- Si sceglie se installare l'interfaccia a finestre X window o lasciare soltanto la shell (interfaccia testuale). Se la macchina che si sta installando è destinata a diventare un server si consiglia di rimuovere ogni programma legato a X window ed ogni applicazione ludica/multimediale.
- Si inseriscono parametri relativi alla configurazione di rete, password dell'utente root, eventuali utenti aggiuntivi, servizi da avviare al boot ecc.
- Si installa sul Master Boot Record (MBR) del computer un Linux Loader (LILO o GRUB sono i più comuni) che permette il boot di Linux al riavvio e di eventuali altri sistemi operativi presenti sul sistema.
- Si crea, facoltativamente, un floppy disk di ripristino che permette di caricare il sistema installato in caso di problemi con l'MBR o altri fasi del boot.
Alla fine dell'installazione si esegue un reboot e ci si ritrova, da subito (non sono necessari ulteriori riavvii) un sistema Linux completo, già provvisto di una moltitudine diprogrammi per tutti gli usi.
Il tempo totale di installazione può variare generalmente dai 20 ai 60 minuti.
SOURCE: The Linux Bootdisk HowTo - http://www.linuxdoc.org/HOWTO/Bootdisk-HOWTO/
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2003-09-20 11:44:54
In ambienti Unix e quindi anche su Linux esistono differenze fra i vari utenti, definite dai permessi e dall'acceso ai file e comandi che un'utente può lanciare.
Per convenzione i semplici utenti possono scrivere, leggere e modificare file solo all'interno del loro ambiente (home) e lanciare comandi che non influiscono sulla configurazione o il corretto funzionamento del sistema.
Per poter accedere completamente alle risorse del sistema bisogna accedere al sistema come superuser ovvero impersonificando l'utente root.
In fase di installazione di una macchina Linux si consiglia di scegliere una password di root piuttosto complicata (ma che si possa ricordare) e di creare immediatamente un normale utente con il quale eseguire le proprie funzioni più comuni.
In particolare si consiglia, per motivi di sicurezza, di non lanciare mai X window (l'interfaccia a finestre disponibile su Linux) come utente root su una macchina che ha accesso a reti esterne.
L'utente root è diverso dagli altri, in quanto ha pieno controllo del sistema.
Può infatti:
- Aggiungere, eliminare, modificare e cambiare la password degli altri utenti
- Installare e configurare tutti i servizi del sistema
- Accedere senza limitazioni (lettura e scrittura) a tutti i file presenti nel filesystem
- Gestire (avviare, terminare, modificare la priorità) tutti i processi
- Gestire l'hardware del computer
- Distruggere tutto con un solo comando (e tante altre brutte cose, il potere di root sul sistema è assoluto).
Inutile sottolineare che è molto importante che l'accesso a root sia limitato solo al proprietario o all'amministratore del sistema.
Tipo Infobox: DISTRO - Skill Level: 1- NOVICE - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2006-08-23 00:56:40
Qualunque appassionato di informatica o anche semplice curioso dovrebbe essere interessato a provare Linux e iniziare a vedere direttamente come funziona.
Per i pigri, gli insicuri o coloro che non se la sentono di fare una normale installazione di Linux sul proprio PC, esistono e sono ormai consolidate varie distribuzioni "LIVE" che permettono il caricamento di Linux direttamente dal CDROM, senza la necessità di installare alcunchè sul proprio prezioso e fragile hard disk.
Queste distribuzioni che bootano direttamente un sistema Linux completo dal CDROM possono essere usate in varie occasioni:
- Dimostrazioni dal vivo, in tempi rapidi, senza le potenziali complicazioni di un'installazione su Hard Disk;
- System Recovery, con la possibilità di operare sul sistema locale senza averlo bootato;
- Network monitoring in situazioni straordinarie, con la possibilità di sniffare, diagnosticare, eseguire test;
- Prove e valutazioni rapide e innocue di un sistema Linux sul proprio PC, senza il rischio di far danni.
Citiamo alcune delle distribuzioni LIVE CD più significative, si raccomanda sempre di utilizzare le più recenti e di considerare che l'esecuzione di molteplici applicazioni richiede memoria che va paginata sull'hard disk, se non basta la RAM.
In genere è fondamentale che la distribuzione riconosca la propria scheda di rete o modem, nel momento in cui questo avviene la configurazione del networking diventa semplice (tramite DHCP o configurazione manuale).
Alcune schede sonore o periferiche particolari (winmodem, schede integrate su motherboard ecc.) possono non essere rinosciute.
KNOPPIX - Impressionante, efficace e comoda.
Il tedesco Klaus Knopper ha fatto un gioiello di immagine ISO, basata su Debian. Due Gigabyte di software compresso su un CD di quasi 700 Mb (o molto di più nella versione DVD), un boot rapido ed efficiente nel riconoscimento dell'hardware locale, la possibilità di eseguire moltissimi programmi da un ambiente grafico completo (KDE di default) ne fanno la distribuzione ideale sia per dimostrazioni e valutazioni che per system recovery e network analysys.
In caso di carenza di RAM crea dello SWAP space sull'hard disk e per chi si affeziona puo' essere installato su Hard Disk.
KNOPILS - Il Knoppix italiano
KnopILS (il cui nome vuole ricordare KNOPPIX e ILS) è una KNOPPIX modificata con queste caratteristiche particolari:
- i pacchetti .deb installati appartengono tutti al ramo free di Debian GNU/Linux (o consentono una classificazione equivalente nel caso di pacchetti non ufficiali)
- la schermata di boot è in italiano
- la schermata ``F2`` iniziale è in italiano
- la tastiera predefinita è quella italiana
- la lingua predefinita è l'italiano
- quando possibile, sono presenti pacchetti localizzati
- altre modifiche minori (grafica, bug fixing ecc...)
Morphix - Derivazione modulare di Knoppix
Live cd basato su debian sid e derivato da Knoppix, è possibile vedere più ambienti grafici (Gnome, KDE, XFCE) in base alla iso che si utilizza. Comoda ed aggiornata ha la possibilità di essere customizzata in modo modulare ed installata su Hard Disk in modo estremamamente semplice.
LINUX BOOTABLE BUSINESS CARD Un Linux su una Business Card CD
In poco più di 100 Mb di CD (basta un Mini CD) permette il boot da CD di un sistema Linux grafico con un tool di diagnostica utili e gli strumenti essenziali per un system recovery (fdisk, lilo...).
LINUXCARE BOOTABLE TOOLBOX Essenziale e pratica.
Distribuzione che deriva dalla precedente e ne mantiene le caratteristiche.
Preente un pratico menu di diagnosi e setup del sistema.
DEMO LINUX Una derivazione Live basata su Mandrake e ben fornita.
Gnome, KDE, StarOffice, Gimp, Netscape e molti altro software comune in Linux.
DYNE:BOLIC A network streaming server on CD.
Curioso Live CD, che carica un ambiente grafico basato su Enlightement e presenta i programmi essenziali per l'uso di Internet e una suite di strumenti, basata sul software MUSE e il network PublicVoice per imbastire uno streaming server velocemente e facilmente. Puo' essere usato come un rapido sistema per mettere online una Internet Radio da qualsiasi postazione.
BACK TRACK - Probabilmente il LIVE CD relativo alla sicurezza più completo ed efficace. Comprende moltissimi e non comuni programmi relativi alle diverse facce del variegato mondo della sicurezza. E' basata su Slax, una Live a sua volta basata su Slackware.
LINK: Home Page KNOPPIX Linux - http://www.knoppix.net/
LINK: LINUXCARE BOOTABLE TOOLBOX (Live CD) Home Page - http://lbt.linuxcare.com/
LINK: DYNEBOLIC LIVE CD Home Page - http://dynebolic.org/
LINK: DEMO-LINUX Home Page - http://www.demolinux.org/
LINK: Home Page Distro Morphix - http://www.morphix.org/
LINK: Home Page knopILS - http://knopils.linux.it/
Cobbler |
Documentation, examples and use of Cobbler Linux Provisioning System |
Tipo Infobox: DESCRIPTION - Skill Level: 3- INTERMEDIATE - Autore: Lab42 'lab42' - Ultimo Aggiornamento: 2009-04-16 10:11:49
Cobbler is a provisioning tool that glues different technologies in order to make easy to build up the components of an efficient provisioning server, perfect for mass or frequent deployment of RedHat/Centos/Fedora Linux systems.
It's done for RedHat based distributions even if it's supposed to work also for Suse and Debian.
It provides in an easy way:
- PXE server support
- DHCP server integration
- Kickstart server with templates
- Easy yum repository management.
It's client, Koan, can install virtual machines or reinstall an existing metal system.
Official Site
Cobbler is mainly developed by Michael DeHaan of RedHat.
The Official site is http://fedorahosted.org/cobbler/ , rpm packages for RedHat / Centos are available in the EPEL repository.
Basic setup
yum install cobbler
Logic is easy:
1- you add / import distributions from CD or network
2- you add profiles and subprofiles for different kind of installations and kickstart templates
3- you may create systems based on existing profiles (MAC or IP addesses can be defined)
4- you can add Yum repositories to use with profiles
5- cobbler does the rest
1 - Import (makes a local copy of files) a distribution CD or ISO to provision with Cobbler
mount -t auto -o loop /data/iso/CentOS-5.1-i386-bin-DVD.iso /mnt/
Alternatively add a distro specifying where to find kernel and inird files (less common option).
cobbler import --mirror=/mnt/ --name=Centos5.1-i386
umount /mnt
cobbler distro add --name=RedHat5 --kernel=/path/to/vmlinuz--initrd=/path/to/initrd.img
2 - Cobbler makes 2 default profiles (normal and xen), you can add more profiles with a command like:
cobbler profile add --name=rhel5-base --distro=RHEL-5-i386
3- You can also create specific systems using defined profiles:
cobbler system add --name=mailserver --profile=rhel5-base
4- Add repositories to manage with cobbler (you can automatically mirror them):
cobbler repo add
--name=Centos-5.1-i386-CENTOSPLUS --mirror=ftp://ftp.sunet.se/pub/Linux/distributions/centos/5.1/centosplus/i386/
To refresh the local mirror and recreate repodata type or place in cron:
cobbler reposync
5- To apply all the configurations (stored in /var/lib/cobbler
) type cobbler sync
This updates files in:
/tftpboot
(accordind to templates in /etc/cobbler/pxe/*
)
(if dhcp support active, according to
/etc/dhcpd.conf/etc/cobbler/dhcp.template
)
/var/www/cobbler
(Visible via web, should not be touched, it's mantained and "cleaned" by Cobbler): The whole content of imported distros is copied in /var/www/cobbler/ks_mirror
.
External repositories file (see below) are copied in /var/www/cobbler/repo_mirror
, kickstart files are generated in /var/www/cobbler/kickstarts
and /var/www/cobbler/kickstarts_sys
Common commands
cobbler check
(verifies if there are problems with current setup)
cobbler list
(lists all the cobbler elements)
cobbler report
(detailed list of elements)
cobbler sync
(syncronizes the configuration to dhcp/pxe and data directories)
cobbler reposync
(syncronizes the configured mirrors of external repositories)
Cobbler configuration
Configurations are in /etc/cobbler/settings
Interesting parameters:
server: '<ip_server>'
(the IP of Kickstart server, commonly the cobbler server)
next_server: '<ip_server>'
(the IP of the PXE server, commonly the cobbler server)
manage_dhcp: 1
(default is "0". Activate it if you want to manage Dhcpd with cobbler. Edit, according to your needs, the template file /etc/cobbler/dhcp.template
)
snippetsdir: /var/lib/cobbler/snippets
(Add here custom snippets for kickstart templates)
A separate file is available for the configuration of modules and third party addons. In /etc/cobbler/modules.conf
you can define what kind of DNS/DHCP server to want to manage and authentication and authorization logics.
Web Interface
Most of the options available via the cobbler command line are available via Web. Cobbler web interface can be reached at: http://yourserver/cobbler/web/ .
(Note that in versions somehow older than Cobbler 0.8 it was http://yourserver/cobbler/webui/wui.html).
You can control access to the web interface in different ways, the easiest is to set in /etc/cobbler/modules.conf
something like:
[authentication]
module = authn_configfile
[authorization]
module = authz_allowall
these settings don't set any particular per user authorization scheme and use file based Digest authentication.
To redefine the password of the default "cobbler" user to access the web interface use the command (then restart apache and cobbler):
htdigest /etc/cobbler/users.digest "Cobbler" cobbler
Client side usage
Koan is cobbler's client:
yum install koan
(lists available profiles on the Cobbler server)
koan --server=192.168.0.42 --list-profiles
(lists available systems, if any)
koan --server=192.168.0.42 --list-systems
koan --virt --server=192.168.0.42 --profile=RHEL5-i386 --virt-name=web01
(installs a virtual guest using the indicated profile)
koan --virt --server=192.168.0.42 --profile=RHEL5-i386 --virt-name=web01 --nogfx
(installs a virtual guest from a console without graphic support).
Note: Default cobbler installations set "cobbler" as root password.
LINK: Cobbler Home Page - http://cobbler.et.redhat.com/
Tipo Infobox: DESCRIPTION - Skill Level: - Autore: Lab42 'lab42' - Ultimo Aggiornamento: 2009-04-16 10:38:35
A brief overview of the configurations settings you may activate on Cobbler, according to your needs.
Cobbler's configuration settings have evolved in its various versions, introducing new features and relative parameters.
In the /etc/cobbler/settings
file they are defined somehow without an apparent order and might seem more confusing than what they actually are.
These settings are generally relative to Cobbler 1.0 and later versions, most of them actually apply also to ealier versions, others have been introduced in more recent versions and some old settings have been deprecated.
Here we refer to production releases (evem numbers, so 0.9 is the development version of 1.0, 1.1 is devel of 1.2, 1.3 is devel of 1.4) but consider that the relevant features may have been introduced in the relative devel versions.
Here we consider what you have to define according to what you need.
Probably the most important and, for default behaviour, the only parameter to set it the IP of your cobbler server
server: 10.42.42.10
To enable web access you should edit /etc/cobbler/modules.conf
and activate an authentication module.
For a DIGEST local authentication set:
[authentication]
module = authn_configfile
(Then use htdigest /etc/cobbler/users.digest "Cobbler"
yourusername
to set the password for yourusername )
More info: https://fedorahosted.org/cobbler/wiki/CobblerWebInterface
If you want to manage a local DHCP server with Cobbler set:
manage_dhcp: 1
Other options related to DHCP:
restart_dhcp: 1
next_server: 10.42.42.10 # PXE server address (generally the Cobbler server)
dhcpd_bin: /usr/sbin/dhcpd
dhcpd_conf: /etc/dhcpd.conf
dnsmasq_bin: /usr/sbin/dnsmasq
dnsmasq_conf: /etc/dnsmasq.conf
In /etc/cobbler/modules.conf
you decide which DHCP program to use (isc or dnsmasq):
[dhcp]
module = manage_isc
More info: https://fedorahosted.org/cobbler/wiki/ManageDhcp
If you want to manage a local DNS server with Cobbler set:
manage_dns: 1
Other options related to DNS;
restart_dns: 1
bind_bin: /usr/sbin/named
manage_forward_zones: []
manage_reverse_zones: []
In /etc/cobbler/modules.conf
you define which DNS program to use (bind or dnsmasq):
[dns]
module = manage_bind
More info: https://fedorahosted.org/cobbler/wiki/ManageDns
Settings applied to the installed hosts
The root's password (default: "cobbler"):
default_password_crypted: "$1$mF86/UHC$WvcIcX2t6crBz2onWxyac."
Default DNS servers set on installed hosts (useless in DHCP environment):
default_name_servers: [ ]
If you want to configure on the installed host the yum repo used during installation, set:
yum_post_install_mirror: 1
Define Cobbler behaviour for installed systems: Set the following parameters to 1 if you plan to reinstall the same servers, otherwise leave them to 0:
allow_duplicate_hostnames: 0
# (Version 1.4)
allow_duplicate_ips: 0
allow_duplicate_macs: 0
Default kernel options when kickstarting (can be overriden):
kernel_options:
ksdevice: eth0
lang: ' '
text: ~
To enable syslogging of kickstart operations to the cobbler server, add something like:
syslog: '10.42.42.10:25150'
Default settings for virt installations (can be overriden):
default_virt_bridge: xenbr0
default_virt_type: xenpv
default_virt_file_size: 5
default_virt_ram: 512
PXE related settings:
enable_menu: 1
# (Version 1.2)
pxe_just_once: 0
pxe_template_dir: "/etc/cobbler/pxe"
tftpd_bin: /usr/sbin/in.tftpd
tftpd_conf: /etc/xinetd.d/tftp
Settings related to Cobbler server internals:
xmlrpc_port: 25151
register_new_installs: 0
run_install_triggers: 1
snippetsdir: /var/lib/cobbler/snippets
yumreposync_flags: "-l" # (Version 1.2)
yumdownloader_flags: "--resolve"
If you enable the authn_ldap module for Web authentication, here you define your LDAP settings:
ldap_server: "ldap.example.com"
ldap_base_dn: "DC=example,DC=com"
ldap_port: 389
ldap_tls: 1
ldap_anonymous_bind: 1
ldap_search_bind_dn: ''
ldap_search_passwd: ''
ldap_search_prefix: 'uid='
(Version 1.6) To enable auto-tracking via a scm of changes in /var/lib/cobbler set:
scm_track_enabled: 1
You can define which scm to use with:
scm_track_mode: "git"
(Version 1.4) To enable func installation and configuration on installed hosts set:
func_auto_setup: 1
You should then define you func master:
func_master: overlord.example42.com
More info: https://fedorahosted.org/cobbler/wiki/FuncIntegration
(Version 1.4) Integration with Configuration management systems (such as Puppet)
More info: https://fedorahosted.org/cobbler/wiki/UsingCobblerWithConfigManagementSystem
mgmt_classes: []
mgmt_parameters:
from_cobbler: 1
(Version 1.4) Power management settings:
More info: https://fedorahosted.org/cobbler/wiki/PowerManagement
power_management_default_type: 'ipmitool'
power_template_dir: "/etc/cobbler/power"
(Version 1.6) To enable the sending of a report email after an installation set:
build_reporting_enabled: 1
Mail content is based on /etc/cobbler/reporting/build_report_email.template
, other related options:
build_reporting_sender: ""
build_reporting_email: [ 'root@localhost' ]
build_reporting_smtp_server: "localhost"
build_reporting_subject: ""
Settings to integrate Cobbler with RHN or Spacewalk
More info: https://fedorahosted.org/cobbler/wiki/TipsForRhn
redhat_management_type: "off"
redhat_management_server: "xmlrpc.rhn.redhat.com"
redhat_management_key: ""
redhat_management_permissive: 0
(Version 1.6) If you want to record installations log on the cobbler server's /var/log/cobbler/anamon
directory (the kickstart templates must have the pre_anamon snippet ) set:
anamon_enabled: 1
Tipo Infobox: TIPS - Skill Level: 5- SENIOR - Autore: Lab42 'lab42' - Ultimo Aggiornamento: 2009-04-16 10:16:37
At first sight Cobbler logic about configuration and data files can be confusing.
Let's explore the most important locations of Cobbler world.
What's reported here applies to version 1.x, should work also for future versions and mostly works also for earlier versions, even if Cobbler developers have introduced not irrelevant changes in some files locations.
Configuration Files in /etc/cobbler
Configuration related items are placed in /etc/cobbler
Here you find the main configuration file: /etc/cobbler/settings
(note that this applies since version 1.x, earlier it was in an ankward /var/lib/cobbler/settings
- consider this when upgrading).
In /etc/cobbler
you find also the various default templaces for dhcp, dns, pxe, dnsmasq configuration.
In this directory you find also /etc/cobbler/users.digest
where are defined the usernames and passwords for web access, /etc/cobbler/modules.conf
for some modules settings (edit this to enable web access) and /etc/cobbler/users.conf
for more fine grained settings of users authorizations logics.
Repo data in /var/www/cobbler
The distros imported, the repos mirrored, the generated repo and kickstart files are all placed in /var/www/cobbler
. Be sure to have enough disk space available under this directory and consider it as something that shouldn't be touched by hand, as most of its parts are regenerated when you type cobbler sync
or updated you type cobbler import
or cobbler reposync
.
The contents of this directory are browsable at the address: http://your.cobbler.example.com/cobbler here you find these directories:
images/
- Kernel and initrd images of all the imported distros for network bootstrap.
ks_mirror/
- The mirrors of all the imported distros
repo_mirror/
- The mirrors of all the defined repos
Logs in /var/log/cobbler
Cobbler main log is /var/log/cobbler/cobbler.log
If it's enabled a syslog server for kickstarts in /var/log/cobbler/syslog
you find all the installation messages of your systems.
Cobbler data in /var/lib/cobbler
All the configurations you make with Cobbler about profiles, systems, distros and so on are placed in this directory. Backup it and you have your cobbler data safe (excluded the mirrors of distros and repos in /var/www/cobbler).
More precisely you find here:
configs/
- A directory where info about distros, repos, systems and profiles are saved
backup/
- A directory where the above files are automatically copied
snippets/
- A directory where you can place snippets to import in your kickstarts
triggers/
- A directory where you can place scripts to be executed as triggers on certain operations
kickstarts/
- A directory where there are the kickstart templates (previously in /etc/cobbler)
LINK: Cobbler Files Info - https://fedorahosted.org/cobbler/wiki/FilesystemInfo
Tipo Infobox: TIPS - Skill Level: - Autore: Lab42 'lab42' - Ultimo Aggiornamento: 2009-04-16 10:18:02
Cobbler Web Interface is a good frontend to easily manage most Cobbler operations. It permits to list, add and edit distros, profiles, subprofiles, systems, repos and kickstart files.
The setup of the WebUI has changed since version 0.7.x, what follows refers to the "new" way of set up, working from version > 0.7.x.
The Web Interface can be seen at the address: http://your.cobbler.server/cobbler/web
You need Apache and Cobbler services running.
You need to setup a username for accessing it (digest authentication).
You can change the password for the existing cobbler user:
htdigest /etc/cobbler/users.digest "Cobbler" cobbler
Or you can add other usernames/passwords:
htdigest /etc/cobbler/users.digest "Cobbler" yourname
Be sure to have in /etc/cobbler/modules
the following values:
[authentication]
module = authn_configfile
[authorization]
module = authz_allowall
For old Cobbler pre 1.0 versions be sure to have in /etc/cobbler/settings
the following values:
xmlrpc_rw_enabled: 1
xmlrpc_rw_port: 25152
Restart cobbler service in you changed any of the above settings:
service cobblerd restart
For debugging check these logs:
/var/log/cobbler/cobbler.log
/var/log/httpd/error.log
More complex setups are possible for managing authorization and authentication policies, refer to official documentation for details.
LINK: Cobbler Web Interface - https://fedorahosted.org/cobbler/wiki/CobblerWebInterface
Tipo Infobox: TIPS - Skill Level: 4- ADVANCED - Autore: Lab42 'lab42' - Ultimo Aggiornamento: 2009-03-27 13:09:38
Here follows an example of a Cobbler setup for provisioning Centos 5 with x86 architecture, using the most known extra repositories and some sample public mirror.
The same procedure can be easily adapted to other Centos versions or architectures, changing the specified urls and arch options.
You need at least 5Gb of space in /var/www/cobbler for importing the official DVD and not less that 30Gb of space for mirroring the additional repositories.
1 - Initial import from a Centos DVD. Place the DVD in your CD drive:
mount -t auto /dev/hdc /media/cdrom (if not autmounted)
cobbler import --mirror=/media/cdrom --name=Centos5 --arch=x86
If you have an ISO, you can import directly from it:
mount -t auto -o loop /path/to/file.iso /mnt/
cobbler import --mirror=/mnt --name=Centos5 --arch=x86
umount /mnt
After this import, that can last some minutes, the iso or DVD is no longer necessary for cobbler: all its files are copied.
2- Sync and show what has been done: you should hve 2 distros and 2 profiles for normal and xen Centos provisioning.
cobbler sync
cobbler list
distro Centos5-x86
profile Centos5-x86
distro Centos5-xen-x86
profile Centos5-xen-x86
3- Add extra repositories from sample mirrors (find a list of official mirrors on Centos site)
Updates:
cobbler repo add --name=Centos5-UPDATES --mirror=ftp://ftp.sunet.se/pub/Linux/distributions/centos/5/updates/i386/ --priority=40 --createrepo-flags="-c cache" --arch=x86
CentosPlus:
cobbler repo add --name=Centos5-CENTOSPLUS --mirror=ftp://ftp.sunet.se/pub/Linux/distributions/centos/5/centosplus/i386/ --priority=40 --createrepo-flags="-c cache" --arch=x86
Extras:
cobbler repo add --name=Centos5-EXTRAS --mirror=ftp://ftp.sunet.se/pub/Linux/distributions/centos/5/extras/i386/ --priority=40 --createrepo-flags="-c cache" --arch=x86
EPEL:
cobbler repo add --name=Centos5-EPEL
--mirror=http://www.mirrorservice.org/sites/download.fedora.redhat.com/pub/epel/5/i386/ --priority=50 --createrepo-flags="-c cache"
RPMFORGE (Dag and Others):
cobbler repo add --name=Centos5-RPMFORGE --mirror=http://apt.sw.be/redhat/el5/en/i386/dag/ --priority=90 --createrepo-flags="-c cache"
Note that EPEL and RPMFORGE may have problems when used at the same time. The use of priorities should solve most of them. If you want to use both, decide which one has to be selected first (lower priority) in case of conflicting packages.
4- Mirror your mirrors
cobbler sync
(syncs the newly added repos)
cobbler reposync
(makes a local mirror or the defined mirrors, requires Internet connection and may take a lot of time, especially at the first run).
It's a good practice to make a daily cron run of "cobbler reposync" in order to have your mirrors automatically updated.
Tipo Infobox: PATH - Skill Level: 5- SENIOR - Autore: Lab42 'lab42' - Ultimo Aggiornamento: 2009-03-27 13:22:59
Cobbler provides template files for dhcp/pxe/bind/dnsmasq configuration.
If you decide to manage there relevant services via cobbler, their configuration files are based on these templates that can be customized according to own needs.
Note that Cobbler overwrites and updates these configuration files if is configured to do that (for dhcp/dns/dnsmasq) every time you type cobbler sync.
/etc/cobbler/pxe/pxedefault.template
It's the main template file for PXE menu. Here you can change the PXE menus shown at boot time.
This template replaces /tftpboot/pxelinus.cfg/default
when cobbler sync
is run.
Important settings are:
TIMEOUT
: Idle Timeout. After this time PXE goes on with what is defined in ONTIMEOUT
MENU TITLE
: Just a string written at the beginning of the PXE menu
DEFAULT
: Default behaviour at PXE boot. Can be menu, to show the menu, the name of a label, to install what is defined in the label, local, to go on with a normal boot from local media.
PROMPT
: If set to 1 a simple prompt is shown.
In the template $pxe_menu_items
is replaced by all the systems and profiles configured in cobbler.
DEFAULT menu
PROMPT 0
MENU TITLE Lab42 | http://www.lab42.it
TIMEOUT 200
TOTALTIMEOUT 6000
ONTIMEOUT local
LABEL local
MENU LABEL (local)
MENU DEFAULT
LOCALBOOT 0
$pxe_menu_items
MENU end
/etc/cobbler/pxe/pxeprofile.template
The layout of the snippets of text to be inserted as single labels for a profile in place of $pxe_menu_items
in pxedefault.template
LABEL $profile_name
kernel $kernel_path
$menu_label
$append_line
/etc/cobbler/pxe/pxesystem.template
The layout of the snippets of text to be inserted as single labels for a system in place of $pxe_menu_items
in pxedefault.template
default linux
prompt 0
timeout 1
label linux
kernel $kernel_path
$append_line
/etc/cobbler/dhcp.template
Template for ISC dhcp configuration file. Here you can define custom settings for your network and leave cobbler automatically populate host definitions in $insert_cobbler_system_definitions
for defined systems (Mac address of the system is necessary here).
ISC dhcp config file is managed (overwritten) by Cobbler according to this template if you define manage_dhcp: 1
and manage_dhcp_mode=isc
in /etc/cobbler/settings
.
# generated from cobbler dhcp.conf template ($date)
ddns-update-style interim;
ignore client-updates;
allow booting;
allow bootp;
#if $omapi_enabled
omapi-port $omapi_port;
#end if
ignore client-updates;
set vendorclass = option vendor-class-identifier;
subnet 10.42.0.0 netmask 255.255.255.0 {
option routers 10.42.0.254;
option domain-name-servers 10.42.0.10;
option domain-name "lab42.it";
option subnet-mask 255.255.255.0;
range dynamic-bootp 10.42.0.100 10.42.0.199;
filename "/pxelinux.0";
default-lease-time 21600;
max-lease-time 43200;
server-name "start";
next-server $next_server;
}
[ ... ]
/etc/cobbler/dnsmasq.template
Template for dnsmasq configuration file.
Dnsmasq config file is managed (overwritten) by Cobbler according to this template if you define manage_dhcp: 1
and manage_dhcp_mode=dnsmasq
in /etc/cobbler/settings
.
# Cobbler generated configuration file for dnsmasq
/etc/cobbler/named.template
# $date
#
# resolve.conf .. ?
#no-poll
#enable-dbus
read-ethers
addn-hosts = /var/lib/cobbler/cobbler_hosts
dhcp-range=192.168.1.5,192.168.1.200
dhcp-option=3,$next_server
dhcp-lease-max=1000
dhcp-authoritative
dhcp-boot=pxelinux.0
dhcp-boot=net:normalarch,pxelinux.0
dhcp-boot=net:ia64,$elilo
$insert_cobbler_system_definitions
Template for bind's named.conf .
It's overwritten by Cobbler if you define manage_dns: 1
in /etc/cobbler/settings
.
options {
listen-on port 53 { 127.0.0.1; };
directory "/var/named";
dump-file "/var/named/data/cache_dump.db";
statistics-file "/var/named/data/named_stats.txt";
memstatistics-file "/var/named/data/named_mem_stats.txt";
allow-query { localhost; };
recursion yes;
};
logging {
channel default_debug {
file "data/named.run";
severity dynamic;
};
};
[ ... ]
DHCP server |
Protocollo, installazione, configurazione ed uso di un server DHCP (ISC) |
Tipo Infobox: DESCRIPTION - Skill Level: 3- INTERMEDIATE - Autore: Arnaldo 'homer' Zitti - Ultimo Aggiornamento: 2004-06-04 10:28:00
Il protocollo DHCP Dynamic Host Configuration Protocol fornisce un meccanismo per assegnare dinamicamente gli indirizzi IP ed i parametri di configurazione ad un host tramite TCP/IP.
Questo protocollo definito dalle RFC 1533, 1534, 1541 e 1542 è un'estensione del protocollo BOOTP. L'utilizzo del DHCP su una rete con un significativo numero di macchine ne permette una migliore e più semplice gestione, riducendo i possibili conflitti di indirizzo.
Attraverso DHCP infatti, oltre ad assegnare ad ogni macchina automaticamente un diverso indirizzo di rete e la relativa subnet mask, è possibile assegnare anche altri parametri come per esempio: l'indirizzo di broadcast, il nome del nodo e del dominio, il gateway predefinito, l'indirizzo del server di stampa, l'indirizzo del DNS ecc.
Per utilizzare questo protocollo deve essere configurata una macchina, il DHCP Server, che si fa carico di distribuire gli indirizzi e gli altri parametri di configurazione ai client che ne fanno richiesta. Il range degli indirizzi distribuibili è chiamato Scope, ed ogni configurazione è valida solo per un determinato periodo di tempo, chiamato tempo di lease, scaduto il quale il client deve richiedere nuovamente la configurazione. In sostanza il client affitta il suo indirizzo di rete per un determinato periodo di tempo.
Il processo per la configurazione di un client tramite DHCP avviene in quattro fasi:
1. Il client invia sulla rete un messaggio in broadcast (in quanto non conosce l'indirizzo del server) chiamato DHCPDISCOVER. Questo messaggio proverrà quindi da 0.0.0.0 e come destinazione avrà 255.255.255.255. Il messaggio DHCPDISCOVER contiene anche l'indirizzo MAC (univoco) della macchina che fa la richiesta.
2. Il server DHCP che riceve la richiesta invia in risposta un messaggio chiamato DHCPOFFER contenente un indirizzo selezionato dallo SCOPE e l'indirizzo MAC del client che ne ha fatto richiesta per far sì che l'offerta giunga al client corretto.
3. Il client, invia ora un messaggio DHCPREQUEST in broadcast indicando che ha accettato l'indirizzo IP offerto.
4. Infine il server DHCP invia un messaggio DHCPACK (ACKnowledgment) che conferma al client l'assegnazione dell'indirizzo con il relativo tempo di lease ed invia anche i vari parametri opzionali.
Nel caso in cui il server è impossibilitato ad assegnare la configurazione richiesta dal client invia un messagggio di tipo DHCPNACK (Negative ACKnowledgment) il quale indica che è necessario ripetere tutti i passi per ottenere una nuova configurazione.
Esempio che è possibile trovare nei log di un DHCP server Linux:
Joker dhcpd: DHCPDISCOVER from 00:48:54:6e:b0:4d (Enigma) via eth0
La macchina Joker (DHCP Server) riceve la richiesta da Enigma (DHCP Client) con MAC Address 00:48:54:6e:b0:4d
Joker dhcpd: DHCPOFFER on 192.168.0.100 to 00:48:54:6e:b0:4d (Enigma) via eth0
Joker offre a Enigma, identificato tramite il MAC 00:48:54:6e:b0:4d, l'indirizzo 192.168.0.100
Joker dhcpd: DHCPREQUEST for 192.168.0.100 (192.168.0.2) from 00:48:54:6e:b0:4d (Enigma) via eth0
Enigma accetta e richiede l'indirizzo 192.168.0.100
Joker dhcpd: DHCPACK on 192.168.0.100 to 00:48:54:6e:b0:4d(Enigma) via eth0
Joker assegna ad Enigma l'indirizzo richiesto
Il rinnovo DHCP avviene in tre fasi:
1. Ogni volta che il client DHCP viene riavviato, se il tempo di lease non è scaduto, viene richiesta la conferma per la configurazione corrente tramite uno scambio di messaggi DHCPREQUEST e DHCPACK.
2. Quando è trascorso il 50% del tempo di lease il client DHCP invia messaggio al server DHCP per rinnovare la configurazione in uso. Se il server riceve il messaggio ed è disponibile al rinnovo invia un messaggio DHCPACK con i parametri, altrimenti il client utilizza i proprio valori fino alla scadenza del lease.
3. Quando è trascorso l'85% del tempo di lease il client DHCP invia in broadcast una richiesta DHCP per rinnovare la configurazione. Se il DHCP server che aveva precedentemente concesso la licenza riceve il messaggio, la rinnova, altrimenti viene inviato un DHCPNACK e quindi il client dovrà ripetere le quattro fasi iniziali.
Tipo Infobox: COMMANDS - Skill Level: 3- INTERMEDIATE - Autore: Arnaldo 'homer' Zitti - Ultimo Aggiornamento: 2004-06-04 10:30:27
L'assegnazione degli indirizzi e la configurazione dei client di rete in modo dinamico è offerta, su un sistema GNU Linux, dal server dhcpd sviluppato dall'ISC (Internet Software Consortium). Dhcpd utilizza due principali file di configurazione dhcpd.conf per la configurazione e dhcpd.leases coma database dei lease.
Il server dhcp, viene solitamente fatto partire tramite gli script di avvio del sistema, la sua sintassi è la seguente: dhcpd [opzioni] [interfacce]
Tra le opzioni principali abbiamo:
-p numero porta UDP
: permette cambiare la porta di listening, di default è la 67;
-cf file di configurazione
: permette di definire un file di configurazione alternativo a quello predefinito;
-lf file di lease
: permette di definire un file alternativo a quello predefinito contenente le informazioni relative agli indirizzi IP rilasciati;
-q
: non stampa i messaggi di copyright all'avvio del servizio;
-d
: utile per il debug, visualizza i messaggi del server sullo standard error anzichè essere come di default essere loggati da syslog.
-t
: testa solamente la correttezza sintattica del file di configurazione dhcpd.conf;
-T
: testa solamente la corretteza del file di database dhcpd.leases;
Di default dhcpd si mette in in ascolto su tutte le interfacce che supportano il multicast (ovvero dove è possibile trasmettere pacchetti all’indirizzo IP 255.255.255.255), altrimenti con la relativa opzione è possibile specificare al server su quali mettersi in ascolto ignorando le altre.
LINK: ISC Dynamic Host Configuration Protocol (DHCP) - http://www.isc.org/products/DHCP/
Tipo Infobox: PATH - Skill Level: 3- INTERMEDIATE - Autore: Arnaldo 'homer' Zitti - Ultimo Aggiornamento: 2004-06-04 10:31:00
E' il database in cui vengono registrati gli indirizzi affittati da dhcpd ai client. Per ogni indirizzo rilasciato in lease viene accodata una voce a questo file. La sua posizione nel sistema può variare a seconda della distribuzione Linux.
E' un file ASCII, che non deve essere editato a mano e contenente tutte le informazioni necessarie al server riguardante il rilascio, il rinnovo e le scadenze dei lease. Dhcpd.leases deve esistere, anche se vuoto prima dell'avvio del demone dhcpd. E' possibile crearlo velocemente tramite il comando touch dhcpd.leases
.
Per evitare che il database di lease cresca eccessivamente, periodicamente, dhcpd.leases viene ricreato eliminando le voci scadute, mentre una copia di backup è salvata con il nome dhcpd.leases~
. In caso di crash del server prima che un file dhcpd.leases valido sia stato scritto su disco è possibile ripristinare il servizio rinominando dhcpd.leases~ in dhcpd.leases.
Il file di database presenta una forma strutturata, per ogni voce è presente l'indirizzo ip rilasciato e tra parantesi
graffe le relative dichiarazioni. Un esempio di voce aggiunta al file database è il seguente:
lease 192.168.0.80 { Ip rilasciato in affitto
starts 5 2003/04/11 18:37:21; Rilascio del lease (tempo GMT)
ends 1 2003/04/14 18:37:21; Scadenza del lease (tempo GMT)
binding state active;
next binding state free; Lo stato di binding attuale e lo stato successivo ovvero alla scadenza del lease
hardware ethernet 00:48:54:6f:2b:e6; Tipo (in questo caso ethernet) e MAC address dell'interfaccia che ha ricevuto l'indirizzo
uid "\001\000HTo+\346"; Identificativo del client
client-hostname "Apollo13"; Nome del client che ha ricevuto in affitto l'indirizzo
}
Tipo Infobox: PATH - Skill Level: 3- INTERMEDIATE - Autore: Arnaldo 'homer' Zitti - Ultimo Aggiornamento: 2003-05-15 18:17:54
E' il file contenente la configurazione del server DHCP (ISC) che viene letto all'avvio del servizio. In caso si decida di apportare variazioni al funzionamento del server è necessario arrestare e riavviare dhcpd affinchè dhcpd.conf venga riletto.
Un esempio di configurazione:
#
# Configurazione parametri Globali
#
ddns-update-style ad-hoc; Opzione riguardante il metodo di aggiornamento dinamico del Domain Name System
option subnet-mask 255.255.255.0; Definizione della maschera di sottorete
option broadcast-address 192.168.0.255; Definizione indirizzo di broadcast per la rete
default-lease-time 259200; Il tempo di lease è quantificato in 3 giorni
max-lease-time 518400; Il tempo massimo per cui il client può utilizzare l'indirizzo affittato è quantificato in 6 giorni
option routers 192.168.0.1; Indicazione del router che fa da gateway verso Internet o altre reti
option domain-name-servers 212.216.112.112, 212.216.172.62; Specifica i server DNS per la risoluzione degli indirizzi
option domain-name "Zeta.net"; Definizione nome di dominio della rete
# Configurazione delle Subnet
subnet 192.168.0.0 netmask 255.255.255.0 { Definizine della subnet da configurare
range 192.168.0.3 192.168.0.50; Definizione di un primo intervallo di indirizzi da affittare
range 192.168.0.100 192.168.0.150; Definizione di un secondo intervallo di indirizzi da affittare
# Configurazione Gruppi Host
group {
option routers 192.168.0.2;
option subnet-mask 255.255.255.0;
option domain-name-servers 195.130.224.18;
Ridefinizione di alcuni parametri globali in modo
specifico per il gruppo di host elencati all'interno del blocco group
host plutone { Identificazione dell'host da configurare
option host-name "Plutone.Zeta.net"; Assegnamento del nome Host
hardware ethernet 00:A0:78:8E:9E:AA; Identificazione tramite Mac Address della scheda di rete
fixed-address 192.168.0.51; Assegnamento di un IP fisso
}
host saturno {
option host-name "Saturno.Zeta.net";
hardware ethernet 00:48:54:6E:B0:4D;
fixed-address 192.168.0.52;
}
}
Tipo Infobox: DESCRIPTION - Skill Level: 3- INTERMEDIATE - Autore: Arnaldo 'homer' Zitti - Ultimo Aggiornamento: 2004-06-04 10:29:33
La configurazione di un DHCP Server ISC avviene attraverso un file di configurazione strutturato in maniera particolare, la cui conoscenza è fondamentale per sfruttarne a pieno le caratteristiche.
La configurazione del server si basa sul file /etc/dhcpd.conf
, un file di testo, composto da istruzioni la cui sintassi è di tipo case insensitive e all'interno del quale è possibile lasciare linee vuote o inserire commenti i quali devono iniziare con il carattere #.
La struttura del file, ricorda dal punto di vista sintattico il linguaggio C, in quanto sono presenti blocchi di istruzioni, e istruzioni annidate, tra parantesi graffe. In particolare si possono individuare due categorie di istruzioni, i parametri (parameter statements) e le dichiarazioni (declaration). Mentre i parametri definiscono in che modo si deve comportare il server, le dichiarazioni vengono utilizzate per descrivere la topologia della rete.
La struttura del file è la seguente:
parametro valore;
parametro valore;
...
dichiarazione {
parametro valore;
...
sotto-dichiarazione {
parametro valore;
...
}
}
Le istruzioni in testa al file, al di fuori di ogni dichiarazione rappresentano i parametri globali. Essi sono validi in ogni sottorete utilizzata salvo una loro ridefinizione all'interno di successive direttive di dichiarazione. Le istruzioni all'interno di un blocco definito da parentesi graffe { } sono valide solamente per quel blocco in relazione all'oggetto (sottorete, host, gruppo di host ecc.) che definiscono.
Le direttive di dichiarazione sono:
subnet ip netmask sottorete {
: definisce la sottorete per la quale applicare i parametri definiti;
[parametro] valore;
}
shared-network nomerete {
: è utilizzata per il raggruppamento della configurazione di più sottoreti, in particolare quando si definiscono più sottoreti che condividono la medesima rete fisica;
[parametro] valore;
dichiarazione {
...
}
}
group {
: permette di definire un gruppo di host che hanno parametri di configurazione comune;
[parametro] valore;
}
La direttiva subnet riveste un particolare importanza perchè è la minima unità di informazione da inserire nel file dhcpd.conf. Senza la specificazione di almeno una subnet con un range di indirizzi validi non è possibile avviare il server.
Tra i parametri di configurazione più utilizzati abbiamo:
default-lease-time
secondi: definisce la durata della configurazione per l'interfaccia di rete;
max-lease-time
secondi: definisce il tempo massimo per la durata della configurazione per l'interfaccia di rete;
range indirizzo
ip iniziale indirizzo ip finale: definisce il pool di indirizzi utilizzabili da rilasciare ai client;
option subnet-mask
subnetmask: definisce la maschera di sottorete;
option broadcast-address
indirizzo di broadcast: definisce l'indirizzo di broadcast;
option routers
indirizzo ip del router: definisce l'indirizzo ip del gatway predefinito;
option domain-name-servers
indirizzo dns: definisce l'indirizzo ip del/dei server DNS;
option domain
nome dominio: definisce il nome di dominio della rete
Sotto la directory /usr/doc/
dell'applicazione è possibile trovare un esempio di dhcpd.conf.
Tipo Infobox: ETCETERA - Skill Level: 2- JUNIOR - Autore: Arnaldo 'homer' Zitti - Ultimo Aggiornamento: 2005-06-21 16:40:33
Configurazione dinamica indirizzo di rete in ambiente Windows XP e possibili alternative.
Per fare in modo che all'avvio il sistema acquisisca tramite il protocollo DHCP l'indirizzo di rete, è necessario impostare il radio button "Ottieni automaticamente un indirizzo IP" nel tab Generale della scheda Protocollo Internet TCP/IP. Per fare questo è possibile cliccare con il tasto destro su Risorse di rete, scegliere Properietà, quindi Connessione alla rete locale (LAN) poi cliccare nuovamente con il tasto destro e scegliere ancora Proprieta'.
CONFIGURAZIONE ALTERNATIVA
E' possibile configurare Windows XP in modo da utilizzare un indirizzo IP a scelta dell'amministratore della macchina qualora il DHCP Server di rete non risulti disponibile. Anche in questo caso, è necessario aprire le proprietà di Protocollo Internet TCP/IP in cui è possibile trovare il tab Configurazione Alternativa il quale permette di impostare un indirizzo IP privato a propria scelta.
Le modifiche in oggetto devono essere effettuare con i privilegi di Administrator.
Installazione e gestione di BIND |
Installazione di BIND tramite RPM e sorgenti, file installati e posizioni. Gestione del servizio. |
Tipo Infobox: DESCRIPTION - Skill Level: 3- INTERMEDIATE - Autore: lorenzo 'lorenz' urbinati - Ultimo Aggiornamento: 2004-06-04 10:31:51
BIND, acronimo di Berkeley Internet Domain Name, è sviluppato e mantenuto dalla ISC, Internet Software Consortium (http://www.isc.org/products/BIND/).
BIND è un pacchetto software composto principalmente da:
- Un Domain Name Service server chiamato named.
- Una libreria per la risoluzione dei nomi.
- Alcune utility di configurazione e dei tool per la gestione del servizio (rndc, named-checkconf).
Attualmente la versione più recente è la 9.2.2 (marzo 2003).
Premesso che la maggioranza delle distribuzioni Linux permette l'installazione e l'aggiornamento del pacchetto attraverso sistemi binari (rpm per RedHat, Mandrake o Suse, deb per Debian) può essere utile all'amministratore di sistema, vuoi per abilitare qualche feature in fase di compilazione o perchè la versione presenta qualche baco, scaricare il pacchetto dei sorgenti.
Questo può essere fatto tramite l'immenso network di sourceforge/freshmeat.net o direttamente dal sito ufficiale.
Una volta scaricato e scompattato il pacchetto si può procedere alla compilazione con il classico:
./configure
make
Ci sono diverse variabili settabili al momento del lancio di configure, vediamo le principali:
--with-libtool
: per abilitare l'uso delle shared library.
--with-openssl
: per abilitare l'uso della crittografia per l'autenticazione sicura (DNSSEC), nel caso openssl fosse installata in un path diverso da quello standard, si può specificare con:
--with-openssl=/prefix
--enable-libbind
: per abilitare l'uso delle librerie libbind di BIND versione 8, visto che attualmente le librerie di BIND 9 sono ancora considerate in sviluppo, può essere interessante l'uso di quelle meno recenti ma più stabili.
--enable-threads
o --disable-threads
a seconda se la nostra macchina è multiprocessore o no, notare che configure dovrebbe verificare da solo questa variabile, è utile avere la possibilità di specificarla.
--prefix=/...
: di default named viene installato in /usr/local
con questa variabile si può specificare un'altra directory.
--sysconfdir
: permette di specificare un'altra directory dove installare il file di configurazione (named.conf) diversa da quella standard /etc
.
--localstatedir
permette di specificare una directory diversa dallo standard /var per run/named.pid
.
NOTA BENE: se si specifica la variabile --prefix
questa modifica anche i valori standard delle ultime due variabili descritte che diventeranno:
$PREFIX/etc/named.conf
e $PREFIX/var/run/named.pid
Di norma quindi se si specifica la variabile --prefix
va ricordato di specificare anche le altre due.
Ad ogni modo se si vuole avere un prospetto completo di tutte le opzioni del configure si usa:
./configure --help
Si procede ad installare il pacchetto con:
make install
SOURCE: Sito dell'Internet Software Consortium - http://www.isc.org/products/BIND/
Tipo Infobox: DESCRIPTION - Skill Level: 3- INTERMEDIATE - Autore: lorenzo 'lorenz' urbinati - Ultimo Aggiornamento: 2004-06-04 10:32:44
Il pacchetto BIND dalla versione 9.x.x contiene l'utility rndc per la gestione e controllo del servizio. Rndc comunica con il named attraverso una connessione TCP inviando comandi autenticati tramite una signature digitale.
In caso si stesse utilizzando BIND 8.x.x il suo corrispettivo tool si chiama ndc e ha poche differenze con l'attuale rndc.
Se si desidera utilizzare rndc per gestire il named bisogna innanzi tutto lavorare sul file di configurazione /etc/named.conf
e su /etc/rndc.conf
.
Esiste un comodo tool per creare un rndc.conf e si chiama rndc-confgen
, questa utility ha diverse opzioni per le quali rimando alla sua pagina del manuale in linea Unix.
Lanciando come root il comando senza opzioni si ottiene sullo standard output (quindi facilmente ridirezionabile ad un file) una serie di direttive da aggiungere poi a mano nei rispettivi file di configurazione:
bash-2.05a# rndc-confgen
# Start of rndc.conf
key "rndc-key" {
algorithm hmac-md5;
secret "m7Umc6qeKl1Q0eeMjVSq0g==";
};
options {
default-key "rndc-key";
default-server 127.0.0.1;
default-port 953;
};
# End of rndc.conf
# Use with the following in named.conf, adjusting the allow list as needed:
# key "rndc-key" {
# algorithm hmac-md5;
# secret "m7Umc6qeKl1Q0eeMjVSq0g==";
# };
#
# controls {
# inet 127.0.0.1 port 953
# allow { 127.0.0.1; } keys { "rndc-key"; };
# };
# End of named.conf
Una volta editato i due file rndc.conf
e named.conf
mantenendo queste direttive così come sono avremo la possibilità di utilizzare rndc solo da locale, dall'host cioè che fornisce il servizio named.
Per utilizzare rndc da remoto sarà importante cambiare la direttiva controls
in modo che rispecchi la nostra configurazione di rete e sarà necessario avere sulla macchina amministrativa un rndc.conf con la giusta chiave. Lo scambio di questo secret può avvenire in diversi modi, via email o via telefono, è importante ricordare che chiunque conosca la shared-key sarà ammesso al canale di controllo di named con ovvie ripercussioni sulla sua sicurezza, la chiave quindi va custodita con cura e non bisogna scordare che i file di configurazione devono essere leggibili da un ristretto gruppo di utenti "trusted".
La sua sintassi è la seguente:
rndc [opzioni] [comandi]
Vediamo ora le principali opzioni di rndc:
-c config_file
: permette di specificare un diverso file di configurazione dallo standard /etc/rndc.conf
.
-k key_file
: permette di specificare un diverso key_file dallo standard /etc/rndc.key
che verrà utilizzato per autenticare i comandi inviati al server in caso un rndc.conf
non sia presente (per approfondimenti leggere il manuale in linea unix di rndc-confgen
).
-s server
: permette di specificare un server a cui inviare i comandi. Se usata questa opzione sovrascrive la direttiva default-server
di rndc.conf
.
-y key_id
: rndc generalmente va a cercare nel file di configurazione del named l'istanza che identifica la chiave da usare per il sign delle comunicazioni. Questa opzione permette di specificare la chiave che si desidera utilizzare.
Per la gestione del server DNS rndc accetta vari comandi:
halt
: Ferma immediatamente il servizio DNS.
querylog
: Abilita il logging delle query che il named riceve dai suoi clienti.
refresh
: Fa effettuare al named un refresh dei suoi file di zona.
reload
: Simile al refresh permette di far rileggere al named i file di zona senza però fargli "pulire" la cache. In più accetta come parametro il nome del singolo file di zona evitando così di oberare il server nella lettura di file che non hanno subito cambiamenti. La sintassi così è: rndc reload file_di_zona
stats
: Esegue un dump delle statistiche attuali del server nel file /var/named/named.stats
.
stop
: Ferma il server in maniera "pulita" perchè permette al server di salvare ogni dynamic-update o qualunque dato IXFR prima di uscire.
restart
: Fa ripartire il server facendogli salvare tutti i dynamic-update e i dati IXFR e facendogli rileggere tutti i suoi file compreso il named.conf
Tipo Infobox: COMMANDS - Skill Level: 3- INTERMEDIATE - Autore: lorenzo 'lorenz' urbinati - Ultimo Aggiornamento: 2003-05-16 15:18:46
Il server DNS di BIND è un demone chiamato named, il quale è principalmente gestito attraverso il suo file di configurazione ma supporta diverse opzioni direttamente dalla riga di comando.
Lanciato senza invocare alcuna opzione, named legge il suo file di configurazione, i relativi file di zona e resta in ascolto delle query.
Le sue opzioni non sono molte ma spesso vitali per aggiungere alcuni parametri di funzionamento non specificabili nel suo file di configurazione.
La sua sintassi è: named [opzioni]
Opzioni:
-c file_alternativo
: Permette di indicare al named un file di configurazione diverso da /etc/named.conf
. Per garantire che named rilegga correttamente il file dato dopo che ha cambiato la directory di lavoro come specificato con l'opzione directory
del file di configurazione bisogna specificare il PATH assoluto per il file.
-d valore
: Abilita il debug_mode. Va specificato il valore di verbosità del debug, un numero più alto indica messaggi di debug più accurati.
-f
: Fa girare il server in foreground.
-g
: Fa girare il server in foreground e invia tutti i messaggi di errore allo standard error (stderr).
-n #cpus
: Specifica il numero di cpu presenti sulla macchina. Questo fa creare tante threads quante che sono le cpu. Se non specificato named cerca di capire quante cpu sono presenti e attiva tanti processi quante cpu. Se non riesce crea un'unica thread per lavorare.
-p
: Permette di specificare una porta diversa dalla default 53 da usare per restare in ascolto delle query.
-s
: Stampa a monitor le statistiche dell'uso della memoria e poi esce. Questa opzione è intesa per l'uso da parte dei programmatori e verrà presto eliminata.
-t directory
: Fa cambiare directory "root" del processo (chroot()
) prima che venga letto il file di configurazione. E' intesa per l'uso associato con l'opzione -u
perchè constringere un processo ad una determinata directory non ha effetto se questo gira con i permessi di root che come si sa non ha limiti all'interno del file system.
-u user_id
: Cambia l'utente proprietario del processo dopo che aver eseguito quelle operazioni che richiedono i privilegi dell'utente root. Molto importante ai fini della sicurezza garantisce che in caso di compromissione del servizio non ci siano i privilegi per danneggiare ulteriormente il sistema.
-v
: stampa la versione del programma e esce.
SOURCE: Pagina del manuale in linea -
Configurazione di BIND |
Configurazione di BIND - In particolare la versione 9.x |
Tipo Infobox: DESCRIPTION - Skill Level: 3- INTERMEDIATE - Autore: lorenzo 'lorenz' urbinati - Ultimo Aggiornamento: 2003-05-14 19:17:43
La configurazione di bind, versione 9.x.x viene gestista dal file named.conf generalmente posto in /etc
o in /etc/bind
. Questo file che è un normale file di testo ASCII contiene direttive e commenti. Specifica inoltre i file delle zone e la loro ubicazione nel filesystem.
Per un elenco completo delle direttive utilizzabili (ne esistono realmente tante) e dei loro valori di default consultare il manuale ufficiale di BIND, generalmente posto in /usr/doc
o /usr/share/doc
. Le principali distribuzioni personalizzano la posizione di questi file, rivolgersi alla documentazione della propria distribuzione per la loro localizzazione.
Molti parametri possono essere lasciati al loro valore di default ma è bene specificare i più importanti anche perchè possono essere vitali ai fini della sicurezza del servizio.
Da ricordare: Ogni direttiva termina con un ";
". Tra parentesi graffe si inseriscono le direttive relative ad una direttiva principale. I commenti sono gli stessi che si utilizzano in linguaggio C, "//
"per aprire e chiudere o "/*
" per aprire e "*/
" per chiudere.
Vediamo le direttive principali e la loro sintassi:
acl: Access Control List. Questa direttiva permette di assegnare un nome arbitrario ad un determinato range di indirizzi per facilitarne poi la loro gestione in altre specifiche del named.conf.
La sua sintassi è la seguente:
acl nome-acl {
lista_di_indirizzi
};
Da notare: La acl e il suo rispettivo range di indirizzi va definito all'interno del file prima che possa essere utilizzata in qualunque altra direttiva. In sostanza named legge il suo file di configurazione dal principio alla fine e non ha la capacità di fare l'inverso.
Alcune acl sono implementate di default:
any: Tutti gli host.
none: Nessun host.
localhost: Corrispondenza per l'host locale.
localnets: Corrispondenza per ogni host presente nella rete in cui named è in ascolto.
controls: Permette la definizione di un canale usato dal system administrator per gestire il servizio. Questi canali sono principalmente usati dall'utility rndc per inviare comandi al server.
controls {
inet ( indirizzo_ip | * ) [ port numero_porta ] allow { acl }
keys { lista_chiavi };
};
key: Definisce una chiave segreta per l'autenticazione mediante signature (TSIG, DNSSEC) viene detta shared perchè è condivisa dal server e delle applicazioni che ne fanno uso.
key nome_chiave {
algorithm stringa;
secret stringa;
};
Il nome della chiave è arbitrario, va poi ovviamente ripetuto uguale in tutte le direttive che lo richiedono.
La direttiva algorithm in teoria potrebbe essere di tipo qualunque ma attualmente (BIND 9.2.2, marzo 2003) named supporta esclusivamente hmac-md5
.
La direttiva secret specifica una stringa a 64 bit utilizzata da algorithm per il signing delle connessioni.
include: Permette di definire un file esterno da cui estrapolare ulteriori direttive.
include nome_del_file;
Può essere utile nel caso in cui si ha necessità di dare l'accesso in lettura al named.conf a un gruppo di utenti ma non si vuole che la secret key sia accessibile. Si specifica così il parametro key
in un file esterno non leggibile e lo si "include" nel named.conf.
option: Sarebbe necessario redarre un how-to separato per descrivere tutte le opzioni possibili che sono numerosissime, rimando ancora alla documentazione ufficiale inclusa col pacchetto named per un'overview più dettagliata.
La sintassi è:
option {
directory /var/named;
listen-on { indirizzo_interfaccia; };
ulteriori opzioni ...;
};
Nel campo option si fanno rientrare numerose direttive:
directory: Specifica la directory di lavoro di named. Se non dichiarata named userà la directory da cui viene lanciato. Di norma si indica la directory dove si trovano i file di zona. Uno standard comune è che sia /var/named
ma non è obbligatorio.
pid-file: Si usa se si vuole utilizzare una directory differente dalla default /var/run
per salvare il pid-file. Named quando parte avvia più di un processo, il pid-file è usato da alcune applicazioni per conoscere il numero del processo "parente" quello cioè che ha poi generato gli altri processi "figli".
port: Serve a specificare una porta udp/tcp diversa dalla standard 53. E' inteso per l'utilizzo nei test di debug visto che un server che lavora su una porta diversa dalla 53 sarà completamente impossibilitato a comunicare con il resto del Domain Name System globale.
notify: Questa opzione ha una sintassi definibile come "booleana" in quanto accetta parametri come yes o no. Serve a impedire o permettere che il server notifichi i cambiamenti dei suoi file di zona ai server presenti nel record di risorsa NS e ai server specificati con l'opzione also-notify. Può essere specificato anche come opzione per singolo file di zona. Il suo valore di default è yes.
recursion: Anch'essa di sintassi booleana, se posta come yes il server cercherà di elaborare una risposta ad una query del client anche se non presente nella sua cache. Notare che se posta come no non impedisce ai client di ottenere una risposta dalla cache del servizio, l'unica cosa sarà che non vi saranno aggiunte nella cache in seguito a query dei clients. Il suo valore se non specificato è yes. Questa opzione può difendere il named da attacchi tipo DNS-poisoning che utilizzano la funzione di recursive quering.
forwarders: Con questa opzione posso definire gli indirizzi di altri server DNS ai quali il named si appoggerà per le risposte a query di cui non ha autorità e solitamente si definiscono i DNS del proprio Internet Service Provider. Di norma quando il server non ha la risposta in cache si appoggia ai root servers a meno che non si sia specificata questa opzione, in questo caso si possono tranquillamente eliminare i riferimenti alla zona radice "." nel named.conf.
forward: Serve a specificare la policy da usare in caso una richiesta non autoritativa non sia presente nella cache e si siano specificati dei forwarders. I suoi parametri sono first e only.
allow-notify: Permette di specificare una lista di indirizzi (o anche una precedentemente definita acl) a cui è permesso notificare i cambiamenti di un file di zona. Può essere specificata come opzione di una singola direttiva di zona e in tal caso sovrascrive la direttiva globale.
allow-transfer: Permette la specifica di una lista di indirizzi (o una acl) a cui è concesso effettuare un trasferimento di zona. Può essere specificato per un singolo file di zona e in tal caso sovrascrive l'opzione globale.
allow-recursion: Specifica la lista di indirizzi o l'eventuale acl ai quali è concesso effettuare query ricorsive. Si ricordi che non permettere ad un host di avere risposte a query ricorsive non impedisce che le ottenga se presenti in cache.
listen-on: Quando viene lanciato il named si mette in ascolto su tutte le interfacce disponibili per cui se un host ha tre schede di rete e quindi tre indirizzi ascolterà su tutti e tre più la loopback. Con questa opzione si può dire a named su quali indirizzi ascoltare e su quali no. Non si può specificare il nome dell'interfaccia (es. eth0) ma si deve usare il suo indirizzo IP.
Per finire il named.conf contiene le direttive dei file di zona che altro non sono che la loro dichiarazione e l'associazione al corrispettivo file del database DNS.
La sintassi è la seguente:
zone "db.esempio" {
type master;
file "/var/named/db.esempio";
};
Dove zone è la dichiarazione per la zona la quale comprende l'opzione type che ne identifica il tipo, master o slave, e l'opzione file che indica dove si trova il corrispettivo file del database.
Occorre che vi sia una direttiva per ogni file di zona più la specifica per la zona radice e una per i record PTR di localhost.
Dichiarazione per la zona radice:
zone "." IN {
type master;
file "/var/named/root.hint";
};
Dichiarazione per localhost:
zone "0.0.127.in-addr.arpa" IN {
type master;
file "/var/named/127.0.0.db";
};
Come già detto la direttiva per la zona radice può essere omessa nel caso in cui si sia specificata l'opzione forwarders. Il file root.hint è il file contenente le informazioni sui server radice del sistema DNS, potrebbe essere il caso di aggiornarlo ed è recuperabile all'indirizzo ftp://ftp.rs.internic.net.
SOURCE: Documentazione acclusa al pacchetto BIND. -
Tipo Infobox: PATH - Skill Level: 3- INTERMEDIATE - Autore: lorenzo 'lorenz' urbinati - Ultimo Aggiornamento: 2003-05-23 14:48:01
Il file di gestione principale per la configurazione di Bind può essere molto diverso a seconda del tipo di server che si intende implementare.
La sua posizione standard è nella directory /etc
ma talvolta alcune distribuzioni lo collocano in /etc/bind/
. Se si compila dai sorgenti si può decidere dove collocarlo con il flag --sysconfdir
.
Vediamo un esempio per un server caching-only o recursive che dir si voglia, un server che non è autoritativo per domini pubblici e demanda la risoluzione dei nomi ai server dell'Internet Service Provider mantenendo una cache dei record richiesti diminuendo il traffico di rete e i tempi di query DNS.
In fondo alla configurazione sono presenti degli esempi per delle zone relative alla rete locale in cui si trova il server.
acl "local" { 192.168.0.0/24; };
Definire una acl è una cosa che facilita parecchio la gestione del file di configurazione anche se non è obbligatoria, è comoda nel caso il server si trovi in una rete complessa e si abbia da configurare gli accessi in modo fine..
key rndc-key {
algorithm hmac-md5;
secret "fFh4kjMNL=\spI";
};
Dichiarazione di una shared key. La stessa stringa dovrebbe trovarsi anche all'interno dell'rndc.conf per permettere la gestione sicura mediante autenticazione degli accessi. Si possono specificare più chiavi per diversi tipi d'uso o avvalersi solo di una chiave per tutte le operazioni.
controls {
inet 127.0.0.1 port 953
allow { 127.0.0.1; } keys { "rndc-key"; };
inet 192.168.0.1 port 953
allow { local; } keys { rndc-key };
};
Definizione di un canale per le comunicazioni amministrative con il server. In questo caso con inet si stabilisce la socket TCP di ascolto e la sua porta il cui valore di default è 953. Nel secondo caso il canale di controllo è settato per restare in ascolto sull'interfaccia con indirizzo 192.168.0.1. Con allow definisco invece chi è autorizzato a collegarsi al canale di controllo in questo caso da localhost e dagli host appartenenti alla acl "local" a patto che abbiano la definizione della chiave rndc-key nel rndc.conf.
options {
directory "/var/named/";
pid-file "/var/named/run/named.pid";
forwarders { DNS1_ISP; DNS2_ISP; };
DNS1_ISP e DNS2_ISP vanno sostituiti con gli indirizzi IP dei server DNS a cui il nostre server rivolgerà tutte le richieste
#forward first;
In questo caso è inserito un commento perchè forward first è il valore di default. Se invece si specifica forward only
o forward-only
si impedisce ogni query del nameserver a DNS diversi dai forwarders.
listen-on { 127.0.0.1; 192.168.0.1; };
Stabilisce gli indirizzi ip delle interfacce presenti sul server in cui si deve porre in ascolto per delle richieste, in questo caso esclusivamente sulla rete locale e la loopback. Se non specificato di default ascolterà su tutte le interfacce disponibili.
query-source address * port 53;
Con una wildcard * definisco gli indirizzi delle interfacce che named userà per rivolgere le richieste che non hanno ancora un record nella cache e definisco che utilizzi la porta 53. Questo è utile nel caso il server si trovi dietro un firewall che filtra i pacchetti UDP anche se non è valido per quanto riguarda le operazioni che implicano l'uso del TCP in cui usa sempre una porta casuale tra la 1024 e la 65535.
allow-query { 127.0.0.1; "local"; };
listen-on-v6 { "none"; };
notify no;
};
Stabilisce il comportamento del server in caso di cambiamenti nei file di zona di default è yes e che nel caso di un server cache-only non serve visto che non comunica con altri nameserver fuorchè i suoi forwarders.
//zone "." in {
// type hint;
// file "named.root";
//};
In questo caso è commentato vista la presenza dell'opzione forwarders non è più necessario che il nameserver utilizzi i server del dominio radice per le richieste non presenti in cache. Questo è fattibile per la verità solo se si specifica forward-only
perchè altrimenti se i forwarders non hanno la risposta o comunque tardano a rispondere di default named interpellerà i DNS del dominio radice.
zone "0.0.127.in-addr.arpa" {
type master;
file "127.0.0.db";
};
Si definisce la zona per la risoluzione inversa di "localhost". Notare che non necessita del flag IN perchè la loopback è in realtà una rete virtuale che nulla ha a che vedere con Internet.
zone "0.168.192.in-addr.arpa" IN {
type master;
file "192.168.0.db";
};
Occorrenza per il file incaricato della risoluzione inversa per la rete 192.168.0.0/24
zone "local" IN {
type master;
file "local";
};
Va definita per indicare al nameserver che la zona local non contiene nessun record.
zone "esempio.local" IN {
type master;
file "esempio.local";
};
Definisce il file dei nomi di dominio per la rete esempio.local
Tipo Infobox: PATH - Skill Level: 3- INTERMEDIATE - Autore: lorenzo 'lorenz' urbinati - Ultimo Aggiornamento: 2004-05-21 18:42:11
Vediamo la configurazione di un server DNS autoritativo: primario (master) per la zona esempio.com e secondario (slave) per la zona extra.esempio.com.
acl "slaves" { numero_ip_slave1; numero_ip_slave2; };
Definisco una acl per i server slave del master per la zona esempio.com
key rndc-key {
algorithm hmac-md5;
secret "fFh4kjMNL=\spI";
};
controls {
inet 127.0.0.1 port 953
allow { 127.0.0.1; } keys { "rndc-key"; };
};
In questo caso il canale di controllo è posto solo sulla loopback. Resta comunque valida l'ipotesi di inserire una acl che stabilisca quali host amministrativi hanno accesso.
logging {
channel security_info {
file "/var/log/named-auth.log";
severity info;
print-category yes;
print-severity yes;
print-time yes;
};
category security { security_info; };
};
Abilito il log per i messaggi della categoria security nel file /var/log/named-auth.log e faccio in modo che salvi i messaggi dalla priorità info in su stampando il tipo, la severità e l'ora.
options {
directory "/var/named/";
pid-file "/var/named/run/named.pid";
query-source address * port 53;
allow-query { any; };
listen-on-v6 { "none"; };
recursion no;
};
In questo caso l'opzione allow-query è settata in modo globale ma va ricordato che è preferibile inserirlo come direttive per singolo file di zona e nel nostro caso per la zona su cui ha autorità il server, esempio.com. Specificando "recursion no" disabilito la possibilità che richieste ricorsive vengano processate dal server.
zone "." in {
type hint;
file "named.root";
};
zone "0.0.127.in-addr.arpa" {
type master;
file "127.0.0.db";
notify no;
};
Disabilito la notifica alla zona dell'host locale
zone "1.168.192.in-addr.arpa" IN {
type master;
file "192.168.1.db";
allow-transfer { "slaves"; };
};
Specifica per la risoluzione inversa della zona esempio.com
zone "0.0.10.in-addr.arpa" IN {
type slave;
file "10.0.0.db";
masters 10.0.0.54
};
Specifica per la risoluzione inversa della zona extra.esempio.com, indicando 10.0.0.54 come server DNS primario
zone "esempio.com" IN {
type master;
file "esempio.com.db";
allow-transfer { "slaves"; };
};
Specifica per la zona su cui il server ha autorità e di cui solo gli host presenti nella acl "slaves" hanno il permesso di eseguire un trasferimento di zona
zone "extra.esempio.com" IN {
type slave;
file "extra.esempio.com.db";
masters 10.0.0.54
};
Specifico l'indirizzo del server master per la zona extra.esempio.com
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: lorenzo 'lorenz' urbinati - Ultimo Aggiornamento: 2003-05-23 21:25:17
Vista la struttura e la sintassi del named.conf passiamo ora ad analizzare i file di zona, semplici file di testo in cui si specificano le informazioni necessarie per la risoluzione dei nomi di dominio in indirizzi numerici e viceversa. Anche in questo caso si ha una sintassi specifica e alcune convenzioni da conoscere.
Vediamo in primis la struttura di un file di zona per la risoluzione dei nomi di dominio in indirizzi numerici. Questo file si vedrà essere il più importante in quanto contiene tutti i dati e i record necessari per la configurazione del dominio, del server di posta e degli alias, per citarne alcuni. Il file in questione si chiama esempio.com.db.
Per chiarezza lascerò come esempio l'intero file dopo di che mi addentrerò nella spiegazione della sua struttura.
$ORIGIN .
$TTL 172800 ; 2 days
esempio.com IN SOA ns1.esempio.com. root.ns1.esempio.com. (
2003021512 ; serial
28800 ; refresh (8 hours)
7200 ; retry (2 hours)
604800 ; expire (1 week)
86400 ; minimum (1 day)
)
NS ns1.esempio.com.
$ORIGIN esempio.com.
$TTL 3600 ; 1 hour
dhcpclient A 192.168.0.98
TXT "311e98e7bea987126c3037d1b1f4c7b99d"
$TTL 172800 ; 2 days
ns1 A 192.168.0.1
mac A 192.168.0.2
linux A 192.168.0.3
windows A 192.168.0.4
webftp A 192.168.0.5
mail A 192.168.0.6
;Aliases
www.esempio.com. CNAME webftp.esempio.com.
ftp.esempio.com. CNAME webftp.esempio.com.
win.esempio.com. CNAME windows.esempio.com.
;Definisco il mail server per il dominio
esempio.com. MX 10 mail.esempio.com.
esempio.com. MX 20 mail.nostroisp.com.
$ORIGIN .
Questo flag indica un nome di dominio che viene automaticamente appeso a tutti i nomi del file di zona che non terminano con un punto finale. In questo esempio si può vedere che sono specificate due direttive $ORIGIN. La prima va a completare la direttiva "esempio.com" mentre la seconda specifica il completamento per i nomi degli host. Alcuni la considerano obsoleta ma vale la pena conoscerla e capirne il significato.
$TTL 172800 ; 2 days
Questo campo indica il default time-to-live. Come si vede si applica globalmente a tutti i record che precedono qualunque altra direttiva di TTL, che può essere indicata anche per singolo host. Il nameserver specifica questo valore in tutte le risposte per la zona o il dato record indicando per quanto tempo gli altri nameservers possono tenerlo in cache. Se si ha un file di zona che subisce poche modifiche è consigliabile specificare un valore alto anche se è sconsigliabile superare la settimana.
esempio.com IN SOA ns1.esempio.com. root.ns1.esempio.com.
Questa è la parte principale del file di zona e serve a indicare lo Start of Authority per la zona esempio.com. In questo caso ns1.esempio.com è il nome del server autoritativo per la zona. Se ne può specificare uno solo e non di più. A seguire abbiamo un record che può creare confusione. Indica l'indirizzo del responsabile della gestione per la zona. I nameservers non utilizzaranno mai questa risorsa che è ad uso esclusivo di chi vuole comunicare con il gestore del dominio. Non si specifica l'indirizzo comune "root@ns1..." ma si deve sostituire l'@ con il punto, questo perchè la sintassi dei file di zona vuole che il simbolo @ si usi come il flag $ORIGIN. Può essere specificato un host differente da quello autoritativo ad esempio root.mail.esempio.com.
I campi chiusi tra le parentesi sono principalmente per gli slave server.
(
2003021512 ; serial
Indicazione del numero di serie. Importante aggiornarlo quando si eseguono modifiche al file per far sapere agli slave che si sono effettuati dei cambiamenti.
28800 ; refresh (8 hours)
Indica agli slave della zona ogni quanto devono verificare che i file sul master sono o meno cambiati. Va prestata attenzione al valore che si da soprattutto nel caso sia basso. Si sappia che uno slave effettua una SOA query per ogni zona ad intervalli specificati nel refresh e si tratta di una operazione molto intensiva in termini di utilizzo di CPU
7200 ; retry (2 hours)
Questo campo indica allo slave ogni quanto tempo riprovare a connettersi al master in caso un refresh non sia andato a buon fine (potrebbe essere momentaneamente down)
604800 ; expire (1 week)
Con expire indico allo slave dopo quanto tempo deve considerare una data zona non più valida. Deve necessariamente essere maggiore dei valori di refresh e di expire altrimenti considererebbe espirati i valori di una zona prima di averla caricata.
86400 ; minimum (1 day)
Questo campo è un TTL. Serve ad indicare quanto tempo un risposta negativa ad una query va tenuta dal nameserver nella cache.
)
NS ns1.esempio.com.
NS, nameserver, indica il nameserver o i nameservers autoritativi per una zona. In caso vi siano due o più DNS per una data zona vanno specificati qua.
$ORIGIN esempio.com.
$TTL 3600 ; 1 hour
dhcpclient A 192.168.0.98
TXT "311e98e7bea987126c3037d1b1f4c7b99d"
Questo record è per un host che utilizza il DHCP. Viene inserito dal server DHCP tramite update dinamico delle zone. Il campo TXT indica una stringa identificativa per il dato host ed è per uso interno al server DHCP ma può essere utilizzata per qualunque tipo di informazione si voglia specificare. In questo caso il TTL è al minimo visto che un record per un client non dotato di un indirizzo statico è soggetto a cambiamenti frequenti.
$TTL 172800 ; 2 days
ns1 A 192.168.0.1
mac A 192.168.0.2
linux A 192.168.0.3
windows A 192.168.0.4
webftp A 192.168.0.5
mail A 192.168.0.6
Questa è la parte che associa i nomi delle macchine ai loro ip. Il flag A sta per Address e indica che si tratta di record per la risoluzione da nome ad indirizzo.
;Aliases
www.esempio.com. CNAME webftp.esempio.com.
ftp.esempio.com. CNAME webftp.esempio.com.
win.esempio.com. CNAME windows.esempio.com.
Con questi campi invece definisco gli alias per alcuni host del dominio. L'esempio dimostra che è possibile assegnare più nomi ad un host. In questo caso il server web e ftp sono la stessa macchina raggiungibile sia se la si cerca come "www.esempio.com" che come "ftp.esempio.com".
;Definisco il mail server per il dominio
esempio.com. MX 10 mail.esempio.com.
esempio.com. MX 20 mail.nostroisp.com.
Con i record MX specifico quali host si occupano dell'instradamento della posta per il dominio esempio.com. Il valore numerico che segue il record MX indica la priorità. In questo caso se invio una mail ad un utente che si trova nel dominio esempio.com il mio client mail cercherà di inviare al server mail.esempio.com per primo. In caso questo fosse troppo occupato o comunque non disponibile il mio mailer si appoggerebbe a mail.nostroisp.com un server fornito dall'Internet Service Provider di esempio.com. Si possono specificare più server con lo stesso valore di priorità ed è consigliabile utilizzare valore numerici che abbiano un certo margine tra loro, questo solo per fini di comodità nell'amministrazione. Ad esempio se in questa zona si decide di implementare un nuovo mail server che poniamo sia una macchina molto potente e posta su un link molto veloce basterebbe dargli un valore di 5 o di 15 a seconda delle preferenze ma se avessimo usato valori tipo 1,2,3.. ci troveremmo obbligati a ristudiare il nostro file di zona. Se si vuole definire un server con priorità massima si può utilizzare il valore 0.
Per finire alcune note. In questo esempio si sono utilizzati valori numerici per indicare i TTL, i refresh, l'expire.. e sono posti con come unità il secondo quindi una settimana diventa 608400 secondi. Dalla versione 8 di BIND in poi si possono specificare anche con degli "argomenti" quindi 3600 secondi diventano 1h e così via si possono specificare valori di 2h35m, due ore e trentacinque minuti, 1d, un giorno, 2w, due settimane. Notare inoltre che la sintassi del file delle zone vuole che i commenti inizino con un ";". Va ricordato infine che vi sono molti record di cui non ho parlato, alcuni obsoleti altri poco usati, se si vuole averne un prospetto più chiaro fare riferimento alla documentazione ufficiale del bind.
SOURCE: DNS and BIND. isbn:0-596-00158-4 -
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: lorenzo 'lorenz' urbinati - Ultimo Aggiornamento: 2004-05-21 18:38:45
Abbiamo visto il file di zona per il dominio esempio.com ora vediamo il suo corrispettivo file per la risoluzione inversa. Anche questa volta lascio l'intero file disponibile per poi addentrarmi nelle sue caratteristiche.
Vediamo il file 192.168.0.db:
$TTL 2D
0.168.192.in-addr.arpa. IN SOA ns1.esempio.com. root.ns1.esempio.com. (
2003021502 ;serial
28800 ;refresh
7200 ;retry
604800 ;expire
28800 ) ;minimum
IN NS ns1.esempio.com.
1 IN PTR ns1.esempio.com.
2 IN PTR mac.esempio.com.
3 IN PTR linux.esempio.com.
4 IN PTR windows.esempio.com.
5 IN PTR webftp.esempio.com.
6 IN PTR mail.esempio.com.
Innanzi tutto occorre fare una premessa. Come si può vedere e come già trattato altre volte in questo file non ci sono in realtà riferimenti numerici bensì troviamo questo strano "in-addr.arpa".
Se volessimo cercare, conoscendo un indirizzo ip, il suo corrispettivo nome DNS il nameserver sarebbe costretto a cercare nell'intero albero DNS dal suo dominio di competenza fino alla radice per poi ridiscendere al dominio a cui appartiene l'ip eseguendo una ricerca all'interno dei file delle zone singolo record per singolo record. Come si può immaginare, visto il grande numero di indirizzi numerici esistenti, visto che molti amministratori creano subnet diverse nelle loro reti delegandole poi ad altri DNS, visto che gli indirizzi ip sono di diverse classi, privati e pubblici questo lavoro sarebbe impossibile per il DNS. In più il Domain Name Space indicizza i suoi dati, incluso quelli numerici per nome. Per questo visto che è semplice trovare le informazioni quando si fornisce il nome del dominio che mantiene i dati, gli sviluppatori hanno pensato di creare un dominio a se, che tratta gli indirizzi numerici come "etichette", in-addr.arpa. In questo modo il dominio in-addr.arpa comprenderà 256 sotto-domini i quali includeranno altri 256 sotto-domini il quale includerà altri 256 sotto-domini fino all'ultimo campo numerico di un ip che fornirà il nome di dominio completo per un dato host. La sua rappresentazione così diviene invertita, 192.168.0.1 diventa 1.0.168.192.in-addr.arpa., questo perchè si segue la relazione con il dominio radice ".". In questo modo l'indirizzo ip sarà letto correttamente nel nome di dominio.
192.168.0.1 = 1.0.168.192.in-addr.arpa. = ns1.esempio.com.
Analizziamo ora il nostro file:
$TTL 2D
0.168.192.in-addr.arpa. IN SOA ns1.esempio.com. root.ns1.esempio.com.
In questo caso il primo campo dopo il TTL poteva essere rappresentato con un @ facente riferimento all'origine specificata nella direttiva "zone" del named.conf e che viene appesa a tutti i nomi nel file che non terminano con un punto finale (
2003021502 ;serial
28800 ;refresh
7200 ;retry
604800 ;expire
28800 ) ;minimum
Questi campi hanno lo stesso significato spiegato nel file di zona "esempio.com.db".
IN NS ns1.esempio.com.
Si definisce il o i DNS autoritativi per la zona
1 IN PTR ns1.esempio.com.
2 IN PTR mac.esempio.com.
3 IN PTR linux.esempio.com.
4 IN PTR windows.esempio.com.
5 IN PTR webftp.esempio.com.
6 IN PTR mail.esempio.com.
Infine si specificano i nomi numerici delle macchine e i loro relativi nomi di dominio. Il flag PTR sta per Pointer e indica che si tratta di record per la risoluzione da indirizzo a nome. In questo esempio ho lasciato il flag IN diversamente da quanto fatto nel precedente esempio questo perchè la sua presenza, in specialmodo per i record delle macchine è implicita. Sta alla preferenza dell'amministratore e di solito lo si usa perchè si ottengono dei file più completi ed esaustivi. Come si nota ho usato solo il campo dell'ip che identifica l'host tralasciando il resto che viene automaticamente appeso ad ogni record che non termina con un punto.
Tipo Infobox: TIPS - Skill Level: 4- ADVANCED - Autore: lorenzo 'lorenz' urbinati - Ultimo Aggiornamento: 2003-05-31 22:09:35
Spesso succede che per necessità ci si trovi costretti a utilizzare il proprio nameserver sia per gestire le richieste della rete interna che le richieste provenienti da Internet.
Ci sono diversi modi di configurare il BIND per questo tipo di lavoro e uno dei più innovativi implementato dalla versione 9.1.x in su è l'uso dell'istruzione view.
Le views permettono di presentare una configurazione del nameserver per una comunità di host e una differente configurazione per un'altro gruppo di host. La sua sintassi è la seguente:
view "internal" {
};
Il nome che si da alla view è arbitrario e è buona norma che sia descrittivo per il tipo di lavoro che andiamo ad eseguire. Non è obbligatorio che sia quotato tra virgolette ma è consigliabile visto che si potrebbero usare nomi che collidono con direttive interne al named. Per specificare quali hosts vedono cosa e quali vedono altro si utilizza l'istruzione match-clients
view "internal" {
match-clients { 192.168.0.0/24; };
}
Volendo si può utilizzare una acl precedentemente assegnata:
acl "intranet" { 192.168.0.0/24; };
view "internal" {
match-clients { "intranet"; };
};
All'interno dell'istruzione view si possono definire molte direttive, si possono specificare le direttive per le zone, descrivere i nameserver remoti con l'istruzione server o configurare direttive key per l'uso di TSIG.
Si possono inoltre definire all'interno dell'istruzione view praticamente quasi tutte le options ricordando che sovrascriveranno ogni opzione globale precedentemente specificata per quegli host che rientrano nella direttiva match-clients
acl "intranet" { 192.168.0.0/24; };
view "internal" {
match-clients { "intranet"; };
recursion yes;
};
Vediamo ora un esempio di configurazione utilizzando le views:
acl "intranet" { 192.168.0.0/24; };
Definisco un Access Control List per gli host della rete interna
options {
directory /var/named;
pid-file /var/run/named.pid;
};
L'opzione directory può essere inclusa nella direttiva view nel caso ad esempio si abbiano molti file di zona e si voglia mantenere in directory separate i file interni e i file esterni.
view "internal" {
match-clients { "intranet"; };
Non specifico una opzione recursion perchè il suo valore di default è yes.
zone "esempio.com" {
type master;
file "esempio.com.db";
};
zone "0.168.192.in-addr.arpa" {
type master;
file "192.168.0.db";
};
};
view "external" {
match-clients { any; };
recursion no;
zone "esempio.com" {
type master;
file "esempio.com.db.external";
};
zone "0.168.192.in-addr.arpa" {
type master;
file "192.168.0.db.external";
};
};
In questo caso si può notare che si utilizzano diversi file di zona per la view internal e per la external; questo non è necessariamente obbligatorio ad esempio si possono comunque utilizzare gli stessi file e definire solo chi ha la possibilità di effettuare recursive quering.
Quando ci si appresta a scrivere file di configurazione che utilizzano le direttive view bisogna prestare attenzione ad alcune regole:
Innanzi tutto l'ordine in cui si specificano le direttive, nel nostro caso per esempio se avessimo specificato prima la direttiva "external" questa avrebbe inevitabilmente occluso la direttiva interna perchè la direttiva esterna ha come match-clients chiunque.
E' importante inoltre ricordare che anche se si specifica una sola direttiva view tutte le direttive zone vanno poi specificate al suo interno.
SOURCE: DNS and BIND, isbn 0-596-00158-4 -
Tipo Infobox: TIPS - Skill Level: 3- INTERMEDIATE - Autore: lorenzo 'lorenz' urbinati - Ultimo Aggiornamento: 2003-05-31 22:02:40
A meno da non acquistare dei costosi libri, la documentazione che spiega chiaramente come far si che il DHCP aggiorni i file di zona del DNS è realmente scarna e criptica.
Vediamo brevemente cosa si deve fare dal lato named per prepararlo a questo tipo di aggiornamenti.
Un server DHCP per comunicare con named e fargli aggiornare i file di zona utilizza il DNS Dynamic Update. Se si vuole approfondire l'argomento la request for comments interessata è la rfc 2136. Questo è disponibile dalla versione 8 del BIND e superiori, in precedenza non si era prevista questa funzione visto che si considerava il DNS un database per dati statici e che subivano pochi cambiamenti tranquillamente gestibili a mano dall'amministratore. Con l'ingrandirsi delle reti e l'ampiamento dell'uso di sistemi per l'assegnazione automatica degli ip si è reso necessario trovare uno strumento in grado di tenere traccia di questi cambiamenti, di inserire nuovi records e di cancellarli.
Qui vedremo quali direttive si rendono necessarie nel named.conf per implementare l'update dinamico di un server DHCP presente sulla stessa macchina.
key DHCP_UPDATER {
algorithm HMAC-MD5;
secret "Yj95beDnn=34fghSN";
};
Nonostante sia possibile con l'istruzione allow-update specificare un lista di indirizzi ip o una acl per controllare gli update dinamici è sconsigliato per ragioni di sicurezza e preferibile utilizzare TSIG per le autenticazioni. Pertanto si crea l'istanza per la chiave che il server DHCP userà per autenticare i suoi update. Nel dhcpd.conf si dovrà creare l'istanza per la chiave corrispondente
controls {
inet 127.0.0.1 port 953
allow { 127.0.0.1; } keys { "DHCP_UPDATER"; };
};
Stabilisco il canale di controllo attraverso il quale il mio server DHCP si connetterà per inviare i dati da aggiornare. In questo caso solo localhost ha la possibilità di accedervi.
options {
directory "/var/named";
pid-file "/var/run/named.pid";
};
zone "." in {
type hint;
file "named.root";
};
zone "0.0.127.in-addr.arpa" {
type master;
file "127.0.0.db";
};
zone "0.168.192.in-addr.arpa" IN {
type master;
file "192.168.0.db";
allow-update { key DHCP_UPDATER; };
};
Per singolo file di zona delineo la direttiva che conceda la possibilità di update solo ai possessori della chiave giusta.
zone "esempio.com" IN {
type master;
file "esempio.com.db";
allow-update { key DHCP_UPDATER; };
};
Vediamo ora come named processa le richieste di update. Come immaginabile dovrebbe incrementare il numero di serie ogni volta che viene aggiunto o eliminato un record. Quando una richiesta di update arriva al server quest'ultimo dovrebbe andare ad aggiornare il relativo file di zona. Riscrivere un file di zona ogni volta che un update viene processato in casi in cui ci si trovi in un contesto di rete molto grosso e con molti update come immaginabile diventa un lavoro realmente oneroso per il server con il rischio che non sia possibile riuscire a processarli tutti. Infatti sia BIND 8 che BIND 9 quando ricevono una richiesta di update dinamico salvano questo record su un file di log che serve a tenere traccia dei nuovi record. In questo modo il nameserver ha sempre in memoria un file di zona con tutti i nuovi record ma si appresta a riscrivere i file di zona a intervalli (generalmente un'ora) prestabiliti. BIND 8 in seguito cancella questi file mentre BIND 9 li conserva perchè vengono utilizzati anche per gli incremental zone transfers. In BIND 9 questi file sono salvati con come nome il nome del file di zona e con estensione .jnl
, infatti vengono chiamati journal files. Non c'è da stupirsi infatti se ci si ritrova la directory contenente i file di zona piena di questi jnl files.
Per finire vediamo in breve quello che si dovrebbe aggiungere al dhcpd.conf per il nostro esempio.
Innanzi tutto la direttiva ddns-update-style
va settata utilizzando il metodo "interim". Esiste anche il metodo ad-hoc ma è deprecato e considerato obsoleto. Se si desidera approfondire l'argomento leggere il man per il dhcpd.conf.
Infine vanno date le specifiche per l'uso della chiave per l'autenticazione sicura.
La sintassi è la seguente:
key DHCP_UPDATER {
algorithm HMAC-MD5;
secret "Yj95beDnn=34fghSN";
};
zone esempio.com. {
primary 127.0.0.1;
key DHCP_UPDATER;
};
zone 0.168.192.in-addr.arpa. {
primary 127.0.0.1;
key DHCP_UPDATER;
};
In questo caso come si vede con l'istruzione primary definisco dove si trova il nameserver che in questo caso è localhost ma che va modificato se il dhcp e il DNS sono su due host differenti. Notare anche che nella direttiva zone si deve aggiungere il punto finale anche se in caso non presente il dhcp server dovrebbe aggiungerlo da solo.
(F)AQ: registare sul ddns client windows95/98 -
(F)AQ: i client windows 95/98 non si registrano -
Linux firewalling: Introduzione a Iptables |
Overview, gestione, utilizzo di iptables su Linux per packet filtering |
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Giorgio 'neo' Colombo - Ultimo Aggiornamento: 2005-05-14 23:11:57
Netfilter è il framework con cui vengono gestite tutte le operazioni di firewalling, natting e manipolazione di pacchetti nel kernel Linux.
Netfilter viene gestito con il comando iptables con cui si determinano e configurano tutte le regole con cui gestire il traffico di rete.
Breve storia dei firewall Linux
Il codice di firewalling di Linux ha subito diverse modifiche nella storia del kernel.
Nella versione 2.0.x viene usato il sistema ipfwadm che viene sostituito nelle versione 2.2.x dalle ipchains che introducono il concetto di catene di regole (access-list) a cui un pacchetto può essere indirizzato.
Dalla versione 2.4 in poi il kernel si basa sull'infrastruttura netfilter/iptables che permette con semplicità estrema di configurare un firewall di fare packet filtering (stateless, statefull), diversi tipi di NAT (Network Address Translation) e packet mangling (modifica di alcuni flag dei pacchetti trattati).
Il progetto NETFILTER/IPTABLES nasce da Paul "Rusty" Russell e dal Core Team (i quali tutt'ora continuano il lavoro di sviluppo), nel lontano 1999.
Componenti
Il framework netfilter/iptables si può identificare in diversi componenti:
1- la parte riguardante il kernel, ovvero tutto il codice che lavora in kernel space e che con diversi moduli introduce funzionalità base e avanzate.
In quasi tutte le distribuzioni netfilter è installato, in alcune specifiche sulla sicurezza possono essere anche installati moduli aggiuntivi sperimentali.
2- L'interfaccia utente, ovvero sostanzialmente il comando iptables
che permette di impostare regole e gestire il firewall.
Solitamente fornita con un pacchetto chiamato... iptables.
LINK: Home Page del progetto Netfiltering/Iptables - http://www.netfilter.org/
HOWTO: Elenco di How-To ufficiali Netfiltering/Iptables - http://www.netfilter.org/documentation/index.html#HOWTO
LINK: Info, link utili da linuxGuruz.org - http://www.linuxguruz.org/iptables/
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2005-05-15 13:32:22
E' essenziale capire e familiarizzare con la logica di iptables prima di cimentarsi nella stesura delle policy di un firewall, altrimenti si rischia di non ottenere i risultati voluti o comprometterne la funzionalità.
Logica di tabelle, catene, regole.
Di default iptables lavora su 3 tabelle (tables) (filter, nat, mangle) che prevedono diverse catene (chains) (INPUT, OUTPUT, FORWARD, PREROUTING, POSTROUTING...) all'interno delle quali esistono elenchi di regole (rules).
Ogni regola identifica pacchetti di rete secondo diversi criteri sulla base di variegati match (tcp, udp, state, pkttype e molti altri, alcuni sperimentali) con le relative opzioni e termina con un target che determina cosa fare del pacchetto matchato (ACCEPT, DROP, REJECT, SNAT, DNAT, LOG...).
Tabella di filter
Quando si usa il comando iptables questa è la tabella di default, implicita.
Prevede 3 catene di default che di fatto corrispondono alle possibili destinazioni del pacchetto rispetto alla macchina che funziona da firewall:
INPUT
Catena in cui passano tutti i pacchetti in entrata dalle interfacce di rete del sistema. Si usa comunemente per permettere o negare l'accesso da IP remoti a porte locali.
OUTPUT:
Considera tutti i pacchetti che sono originati ed escono dal proprio sistema. Si usa per controllare il traffico in uscita, sia per le risposte a pacchetti permessi in INPUT che per nuove connessioni in uscita.
FORWARD:
Riguarda i pacchetti che devono "attraversare" il firewall, avendo IP sorgente e destinazione diversi da quello della macchina su cui gira iptables.
Si usa tipicamente su router o firewall di rete.
Tabella di nat
Questa tabella riguarda alcune alterazioni che si possono fare su un pacchetto, in particolare la variazione degli IP e delle porte sorgenti o di destinazione . Viene richiamata con l'opzione -t nat
e prevede le seguenti catene di default:
PREROUTING
- Catena in cui vengono processati i pacchetti in ingresso, prima che il sistema prenda le decisioni di routing. Si usa tipicamente per fare destination natting usando il target DNAT
.
POSTROUTING
- Catena in cui passano i pacchetti dopo che sono stati routati sulla interfaccia di destinazione. Si usa per modificare l'IP e/o la porta sorgente di un pacchetto, tipicamente usato su default gateway di una rete con funzioni di Port Address Translation (su Linux definito Masquerading). Prevede i target SNAT
e MASQUERADE
.
OUTPUT
- Catena utilizzata per modificare l'IP sorgente di un pacchetto uscito dal sistema stesso.
Tabella di mangle
Si può utilizzare per modificare vari parametri negli header di un pacchetto. Viene richiamata con -t mangle
e prevede le catene di default PREROTING, INPUT, FORWARD, OUTPOUT, POSTROUTING. L'uso più comune è per alterare il TOS di un pacchetto IP. Non ci si ritroverà ad usarla spesso.
Il comando iptables
Iptables è sia il nome dell'infrastruttura a catene con cui si definiscono le policy di firewalling di un sistema basato su netfilter che il comando, utilizzabile da shell, con cui si configura e gestisce il tutto.
La sua sintassi è piuttosto variegata e prevede opzioni e impostazioni anche sulla base dei moduli aggiuntivi supportati e permette di: azzerare le catene esistenti, aggiungere regole, rimuovere regole, impostare le policy di default, creare nuove catene custom, azzerare i contatori ecc.
Comodi comandi ausiliari sono iptables-save
e iptables-restore
che si usano rispettivamente per salvare e ripristinare le configurazioni del firewall.
Le impostazioni sono immediatamente applicate sul sistema fino al momento in cui non si riavvia, per ripristinarle dopo un reboot, è necessario salvare su un file.
Le distribuzioni Linux possono avere file diversi di configurazione e diversi script di avvio, con cui le iptables sono gestite come un servizio, ma la sintassi del comando iptables resta comunque comune.
Attraversamento delle catene
La sequenza con cui vengono processate le varie catene dal Kernel ha questa logica, nel caso si faccia forwarding:
RETE A - MANGLE PREROUTING - NAT PREROUTING - ROUTING - FILTER FORWARD - ROUTING - RETE B
Oppure, per pacchetti in entrata o in uscita:
RETE A - MANGLE PREROUTING - NAT PREROUTING - ROUTING - FILTER INPUT - LOCAL PROCESS - MANGLE OUTPUT - NAT OUTPUT - FILTER OUTPUT - ROUTING - RETE B
I pacchetti attraversano le catene che sono destinati a percorrere, secondo l'ordine delle regole impostate. Se un pacchetto matcha le condizioni definite in una regola, allora segue le indicazioni specificate nel target (ACCEPT, DROP, DNAT) e , in molti casi, interrompe l'attraversamento. Se non matcha nessuna regola di una catena, segue la policy di default impostata per quella catena.
Per questo motivo è fondamentale l'ordine con cui sono inserite le regole in una catena.
Tipo Infobox: COMMANDS - Skill Level: 3- INTERMEDIATE - Autore: Giorgio 'neo' Colombo - Ultimo Aggiornamento: 2005-05-23 14:29:18
Iptables è il comando utilizzato per settare, modificare e cancellare rule riguardanti il packet filtering del kernel linux.
Di seguito verranno riportati le principali opzioni e le sintassi più utilizzate:
Aggiunge una regola alla fine della catena scelta oppure la modifica o cancella:
iptables -[ADC] chain rule-specification [options]
Sostituisce regola o la inserisce all'inizio della catena
iptables -[RI] chain rulenum rule-specification [options]
Visualizza, svuota o azzera i contatori della catena selezionata:
iptables -[LFZ] [chain] [options]
Crea o aggiunge una nuova catena
iptables -[NX] chain
Setta la policy di default della catena
iptables -P chain target [options]
COMANDI
-A, --append
Aggiunge una regola in fondo alla catena
-D, --delete
Cancella una regola
-R, --replace
Esegue il replace di una regola
-I, --insert
Inserisce la regola all'inizio della catena o alla posizione indicata.
-L, --list
Visulizza l'elenco delle regole inserite
-F, --flush
Svuota le catene predefinite
-Z, --zero
Azzera i contatori di ogni catena
-N, --new-chain
Crea una nuova catena custom
-X, --delete-chain
Cancella una catena (creata dall'utente)
-P, --policy
Setta la policy di default per una catena
PARAMETRI
-p ,--protocol [protocol]
Specifica su quale protocollo deve matchare la regola
-s, --source address[/mask], -src
Specifica l'IP sorgente.
-d, --destination address[/mask], -dst
Specifica l'IP destinazione
-j, --jump
Specifica il target a con cui gestire il pacchetto matchato: può essere una catena custom o un target esistente (drop,accept etc..)
-i, --interface
Specifica da quale interfaccia è in entrata un pacchetto. Opzione valida solo per INPUT, FORWARD e PREROUTING.
-o, --out-interface
Specifica l'interfaccia d'uscita di un pacchetti. Opzione valida per FORWARD, OUTPUT e POSTROUTING.
TARGET
DROP
I pacchetti che "matchano" la regola vengono droppati.
ACCEPT
I paccheti che "matchano" la regola vengono fatti passare.
RETURN
Il pacchetto smette di attraversare la catena e passa a quella successiva o segue il comportamente di default
QUEUE
Se il kernel lo supporta il pacchetto passa a livello user-space dove può essere manipolato da programmi vari.
REJECT
Il pacchetto viene rifiutato con un messaggio di notifica al mittente (es: icmp destination unreachable)
LOG
Il pacchetto viene loggato via syslog.
MARK
Il pacchetto viene marcato per essere gestito da programmi in user space.
MASQUERADE
L'IP del pacchetto viene mascherato.
MIRROR
Viene rimandato al mittente un pacchetto speculare a quello ricevuto
REDIRECT
Il pacchetto viene redirezionato ad una porta locale
ALTRE OPZIONI
-v --verbose
Abilita il verbose mode
-n
Abilita la visualizzazione numerica, senza DNS reverse lookup
--linenumbers
Quando viene eseguito il list delle regole viene aggiunto un numero ad ogni regola che corrisponde la posizione della regola nella sua catena.
!
Inverte il significato dell'opzione che lo segue
Tipo Infobox: COMMANDS - Skill Level: 4- ADVANCED - Autore: Giorgio 'neo' Colombo - Ultimo Aggiornamento: 2002-10-03 18:07:14
Comando su Linux che permette di configurare in run-time e visualizzare alcuni parametri del kernel.
Particolarmente utile per il tuning del sistema, in particolare:
- Tuning dei Parametri della Network
- Tuning dei Parametri della memoria virtuale
- Tuning dei Parametri del filesystem
Per verificare le opzioni:
sysctl [-n] [-e] variable ...
sysctl [-A]
Per modificare le opzioni:
sysctl [-n] [-e] -w variable=values
Per rileggere il file di condfigurazione:
sysctl [-n] [-e] -p [file di configurazione]
-A
Printa in stdout tutti i valori attualmente disponibili
-n
Disabilita il print in stdout del nome della variabile
-e
Ignora eventuali errori nel nome della variabile
-w
Opzione per modificare il settaggio di sysctl
-p
Carica le opzioni di sysctl da un file. Default /etc/sysctl.conf
Tipo Infobox: PATH - Skill Level: 3- INTERMEDIATE - Autore: Giorgio 'neo' Colombo - Ultimo Aggiornamento: 2004-04-01 12:13:42
File di configurazione contenente le opzioni del kernel modificabili in run-time.
Di seguito verra' riportato un esempio di questo file con alcune opzioni abilitate di default da RedHat.
E' fondamentale abilitare net.ipv4.ip_forward (forwarding dei pacchetti IP) se il proprio Linux deve fare da firewall/router.
Di fatto vengono modificati i parametri contenuti nel /proc filesystem.
Abilitando (1) ,disabilitando (0), o il Tuning di alcuni parametri del kernel:
Precisamente si possono modificare i valori del kernel in run-time per i seguenti campi
- Virtual memory
- File System
- Network
Ecco il cat del file in configurazione RedHat Standard:
[neo@dido neo]$ cat /etc/sysctl.conf
# Disables packet forwarding
net.ipv4.ip_forward = 0
# Enables source route verification
net.ipv4.conf.default.rp_filter = 1
# Disables the magic-sysrq key
kernel.sysrq = 0
A causa di un bug di alcuni router, inoltre, se l'ECN (Explicit Congestation Notification) è abilitato, ciò che sta dietro a tali router NON sarà raggiungibile.
Il tutto si risolve disabilitando l'ECN nel kernel, intervenendo in /etc/sysctl.conf con una riga tipo:
net.ipv4.tcp_ecn= 0
iptables - Linux natting e packet mangling |
Utilizzo di iptables per natting, masquerading e mangling di pacchetti. |
Tipo Infobox: DESCRIPTION - Skill Level: 3- INTERMEDIATE - Autore: Giorgio 'neo' Colombo - Ultimo Aggiornamento: 2004-06-04 10:47:19
NAT ovvero Network Address Tranlation permette di manipolare un pacchetto IP modificando l'indirizzo IP sorgente o di destinazione.
Ovviamente il dispositivo che esegue il NAT quando riceve il pacchetto di ritorno esegue l'operazione inversa, sulla base di una tabella di natting che si tiene in memoria.
Il Nat viene utilizzato in varie occasioni, dove si ha la necessità ad esempio di redirezionare il traffico su un unico IP, oppure forwardare il traffico con una certa porta di destinazione ad un'altro host oppure su un'altra porta.
Su Linux si usa definire il natting con due modalità specifiche:
SNAT: Source NAT, cioè l'alterazione dell'IP sorgente del primo pacchetto che apre la connessione. Avviene sempre dopo che il pacchetto ha subito il routing (post-routing).
Un esempio di SNAT è il masquerading, con cui tutti gli IP sorgenti di una rete locale vengono convertiti in un unico IP sorgente (del dispositivo che fa masquerading) con cui i pacchetti vengono mandati in rete.
DNAT: Destination NAT, cioè l'alterazione dell'IP di destinazione del primo pacchetto.
A differenza del SNAT il DNAT avviene sempre prima che il pacchetto subisca il routing (pre-routing).
Una forma di DNAT è il port-forwarding e trasparent proxy.
Per quanto riguarda iptables, le catene (chain) da considerare per i vari tipi di NAT sono:
PREROUTING (DNAT, per i pacchetti in arrivo).
Esiste inoltre un "caso speciale" chiamato redirection. E' un DNAT effettuato esclusivamente sull'interfaccia di ingresso del pacchetto. Ovvero si può eseguire un redirect di tuti i pacchetti provenienti su eth0 con destination port 80 e redirezionarli sempre su eth0 ma sulla porta 12345.
OUTPUT (DNAT, per i pacchetti generati della macchina locale)
POSTROUTING (SNAT, per i pacchetti in uscita)
Esempi di NAT:
Port forwarding
iptables -A PREROUTING -t nat -p tcp -d 10.0.0.150 --dport 8080 -j DNAT --to 172.16.1.128:80
Ovvero tutti i pacchetti che hanno destinazione 10.0.0.150 sulla porta 8080vengono riderizionati al'ip 172.16.1.128 alla porta 80.
Source Natting
iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to 10.0.0.1
Tutti i pacchetti che escono dall'interfaccia eth0, subiscono una variazione dell'ip sorgente in 10.0.0.1
iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to 10.0.0.1-10.0.0.254
Come sopra, con la differenza che l'ip sorgente può essere alterato sia in 10.0.0.1 o 10.0.0.154
Masquerading
iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE
Tutto ciò che passa in uscita dal proprio modem viene mascherato con l'ip pubblico assegnato dal proprio ISP.
Destination Natting
iptables -t nat -A PREROUTING -p tcp --dport 80 -i eth1 -j DNAT --to 10.0.0.1:8080
Tutti i pacchetti TCP, arrivati dall'interfaccia eth1 con destinazione porta 80 vengono "dirottati" all'ip 10.0.0.1 alla porta 8080.
LINK: How-to NAT in italiano - http://www.netfilter.org/documentation/HOWTO/it/NAT-HOWTO.txt
Tipo Infobox: DESCRIPTION - Skill Level: 4- ADVANCED - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2005-05-22 20:39:41
Segue un esempio di script che esegue il masquerading di una rete locale e il destination natting di un server PPTP interno a dei limitati IP pubblici.
Può essere modificato e adattato ai propri scopi.
#!/bin/sh
#
# masquerading.sh - Version 20040531 - Coresis
#
#### DEBUGGING ###
set -x
### FLUSHING CHAIN ### Azzera e pulisce ogni regola esistente
/sbin/iptables -F
/sbin/iptables -F -t nat
/sbin/iptables -X
/sbin/iptables -Z
### DEFAULT CHAIN ### Imposta le policy di default
/sbin/iptables -P INPUT DROP
/sbin/iptables -P FORWARD DROP
/sbin/iptables -P OUTPUT DROP
/sbin/iptables -t nat -P POSTROUTING DROP
/sbin/iptables -t nat -P PREROUTING DROP
### SETTING IPFORWARDING ### Abilita il forwarding di pacchetti non locali - FONDAMENTALE
/bin/echo "1" > /proc/sys/net/ipv4/ip_forward
### DISABLE RESPOND TO BROADCAST ### Non risponde ai ping inviati al browadcast della subnet
/bin/echo "1" > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
### ENABLE BAD ERROR MESSAGE PROTECTION ### Ignora finti messaggi di errore ICMP
/bin/echo "1" > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses
### DISABLE ICMP REDIRECT ACCEPTANCE ### Non accetta pacchetti ICMP di route redirection
/bin/echo "0" > /proc/sys/net/ipv4/conf/all/accept_redirects
### SETTING ANTISPOOFING PROTECTION ###
/bin/echo "1" > /proc/sys/net/ipv4/conf/all/rp_filter
### DON'T RESPOND TO BROADCAST PINGS ###
/bin/echo "1" > /proc/sys/net/ipv4/conf/all/log_martians
### Qui vengono definite alcune variabili che successivamente sono usate nelle regole - MODIFICARE SECONDO I PROPRI PARAMETRI
# External Public Interface
EXTIF="eth1"
# Internal Private Interface
INTIF="eth0"
# Host Public IP (su eth1)
EGO="211.121.111.111"
# Internal LAN IP (su eth0)
LANIN="10.0.0.0/24"
# Trusted public network (da cui si permettono collegamenti SSH)
TRUSTED="13.18.151.0/24"
# IP/rete di un utente esterno abilitato a connetterci al server VPN interno
USER="112.56.10.32/28"
# IP Interno del server VPN
VPNSERVER="10.0.0.77"
# RFC IPs Classi di indirizzi dedicate a utilizzi privati o particolari e non routate su Internet
LOOPBACK="127.0.0.0/8"
CLASS_A="10.0.0.0/8"
CLASS_B="172.16.0.0/12"
CLASS_C="192.168.0.0/16"
CLASS_D_MULTICAST="224.0.0.0/4"
CLASS_E_RESERVED_NET="240.0.0.0/5"
# ANTISPOOF Adesso iniziano le regole vere e proprie. Le prime sono generiche regole anti-spoof per IP noti dall'interfaccia pubblica.
/sbin/iptables -A INPUT -i $EXTIF -s $EGO -j DROP
/sbin/iptables -A INPUT -i $EXTIF -s $CLASS_A -j DROP
/sbin/iptables -A INPUT -i $EXTIF -s $CLASS_B -j DROP
/sbin/iptables -A INPUT -i $EXTIF -s $CLASS_C -j DROP
/sbin/iptables -A INPUT -i $EXTIF -s $CLASS_D_MULTICAST -j DROP
/sbin/iptables -A INPUT -i $EXTIF -s $CLASS_E_RESERVED_NET -j DROP
/sbin/iptables -A INPUT -i $EXTIF -d $LOOPBACK -j DROP
# LOOP RULE Permettiamo il traffico di loopback
/sbin/iptables -A INPUT -i lo -j ACCEPT
/sbin/iptables -A OUTPUT -o lo -j ACCEPT
# LAN IN ACCESS Regole che permettono l'accesso al firewall Linux dagli IP della rete Interna - Potrebbero essere più ristrette e limitarsi all'IP dell'amministratore
/sbin/iptables -A INPUT -i $INTIF -s $LANIN -j ACCEPT
/sbin/iptables -A OUTPUT -o $INTIF -d $LANIN -j ACCEPT
# LAN IN OUT Seguono le regole che gestiscono il masquerading della rete interna
/sbin/iptables -A FORWARD -s $LANIN -d 0/0 -j ACCEPT Forwarda tutti i pacchetti dalla rete interna a qualsiasi destinazione
/sbin/iptables -A FORWARD -m state --state ESTABLISHED,RELATED -d $LANIN -j ACCEPT Permette il forwarding di tutti i pacchetti correlati a comunicazioni esistenti
/sbin/iptables -t nat -A POSTROUTING -o $EXTIF -s $LANIN -j MASQUERADE Maschera gli IP sorgenti Interni con l'IP dell'interfaccia pubblica
# GENERAL Regole generali per permettere all'host locale di collegarsi a IP remoti e ricevere i pacchetti di risposta (Nota: si riferiscono alle attività che vengono fatte direttamente dalla macchina Linux locale e non dagli host che la usano come firewall)
/sbin/iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
/sbin/iptables -A OUTPUT -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
# SSH Regole per permettere l'accesso al server SSH locale da un IP esterno fidato precedentemente indicato
/sbin/iptables -A INPUT -s $TRUSTED -p TCP --dport 22 -j ACCEPT
# VPN NATTING Esegue un DNAT di un server VPN che usa pptp (TCP porta 1723) e GRE (IP type 47) e permette l'accesso al server solo da un IP sorgente definito
/sbin/iptables -A FORWARD -s $USER -p TCP --dport 1723 -j ACCEPT
/sbin/iptables -t nat -A PREROUTING -d $EGO -p tcp --dport 1723 -j DNAT --to-dest $VPNSERVER:1723
/sbin/iptables -t nat -A PREROUTING -d $EGO -p 47 -i eth1 -j DNAT --to-dest $VPNSERVER
# LOGGING Log di tutti i pacchetti, esclusi i broadcast, prima di essere droppati dalla regole di default. I logging viene fatto con livello debug per isolarlo da altri log di sistema. Per cui è necessario scrivere in /etc/syslog.conf una riga tipo:
kern.debug /var/log/iptables.log
/sbin/iptables -A INPUT -m pkttype --pkt-type ! broadcast -j LOG --log-level=DEBUG --log-prefix="[INPUT DROP] : "
/sbin/iptables -A OUTPUT -m pkttype --pkt-type ! broadcast -j LOG --log-level=DEBUG --log-prefix="[OUTPUT DROP] : "
SQUID Proxy server |
Installazione e configurazione del proxy server Squid |
Tipo Infobox: PATH - Skill Level: 3- INTERMEDIATE - Autore: Giorgio 'neo' Colombo - Ultimo Aggiornamento: 2005-04-27 11:04:44
Il file di configurazione principale di Squid è squid.conf
, il prefix cambia a seconda del package utilizzato per l'installazione, esempio il prefix del file di configurazione dei sorgenti è /usr/local/etc
mentre per l'rpm di redhat è /etc/squid
.
Il file di configurazione base risulta essere molto verboso e ostico per il numero di parametri configurabili, ma teoricamente si potrebbe commentare tutte le voci e il demone partirebbe con i valori settati a quelli di default.
Di seguito sono riportati le principali opzioni settabili nel file di configurazione con relativa spiegazione:
http_port
Specifica la porta ove squid si metterà in ascolto, come nell'esempio è possibile specificare più porte, La porta di default è 3128
Esempio: http_port 7575 8080
cache_dir
Specifica la directory ove risiede la cache gestita da squid; i valori a seguire risulatano essere, la dimensione della cache in mega (512) e il numero delle sottodirectory di primo livello (16) e secondo (256). Come nel caso di http_port è possibile specificare più entry per lo stesso operatore.
I valori di default sono: 100 16 256.
Esempio: cache_dir /var/cache/ 512 16 256
cache_effective_user , cache_effective_group
Parametro per specificare l'owner dei processi di squid.
Per motivi di sicurezza è bene evitare di utilizzare l'owner di root ma di un utente creato ad hoc.
Di default, se le opzioni sono commentate, l'owner del processo corrisponde a quello dell'utente che ha lanciato il demone.
Esempio:
cache_effective_user squid
cache_effective_group squid
cache_peer
Abilitata questa opzione, squid ha la possibilità di comunicare con altri squid nella stessa network, con una specificata gerarchia, per gestire in modo più funzionale la cache distribuita nei vari nodi.
Esempio: cache_peer proxy.openskills.info parent 3128 3130 default
Il primo campo specifica l'hostname dell'affiliato ovvero l'host con il quale comunicherà per l'interrogazione della cache. Il secondo campo specifica un vero e proprio grado di parentela fra i due host. Il terzo campo specifica la porta http del server destinatario, mentre il quarto valore specifica la porta ICP (UDP) query port, ovvero la porta utilizzata per l'interrogazione della cache remota, l'ultimo e quinto valore specifica le opzioni.
cache_mem
Specifica l'ammontare della shm (shared memory) in mega da dedicare alla cache. Da ricordare che squid di fatto acquisisce tre volte tanto il valore specificato
cache_mgr
Parametro per configurare l'email del "cache manager", visualizzato anche nelle pagine di errore.
acl, http_access, icp_access
L'uso delle acl permette usufruire di uno strumento molto flessibile per il controllo degli accessi alle risorse del proxy. Tipicamente viene utilizzata la regola generale di negare a tutti quanti e di limitare l'accesso ai soli host appartenenti alle proprie network ma è possibile limitare l'accesso per altre discriminanti come l'ora locale e il dominio di destinazione, per il tipo di browser o addirittura per la comunity SNMP.
Per definire le acl occorre differenziare due elementi:
classi : Identificano le regole che gestiscono l'accesso per un gruppo di client con una determinata descriminante. Per esempio per ip o per dominio.
operatori : Gestiscono le regole o le stessi classi per uno specifico protocollo. Esempio: http_access, icp_access and snmp_access
Esempio di classe:acl all src 0.0.0.0/0.0.0.0
Creazione di una acl chiamata "all" che identifica tutti i client (src 0.0.0.0/0.0.0.0)
Esempio di operatore:http_access deny all
Uso dell'operatore http_access per negare l'accesso in modo indiscriminato.
Sintassi acl
acl name type (string|"filename") [string2] [string3] ["filename2"]
La sintassi minima prevede come primo argomento un nome univoco per determinare la acl stessa(name), il tipo della acl come secondo argomento (type) e come terzo argomento la descriminante (string)
Sintassi operatore
operatore allow|deny [!]aclname [& [!]aclname2 ... ]
il primo argomento specifica l'azione ovvero permette (allow) o nega (deny) l'acl che segue. L'acl deve essere specificata con il suo nome e possono essere specificate + acl sulla stessa linea di configurazione.
SOURCE: Official Docs - http://squid-docs.sourceforge.net/latest/html/x495.html
Tipo Infobox: TIPS - Skill Level: 4- ADVANCED - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2007-04-13 15:27:39
E' possibile configurare Squid per autenticare gli utenti che possono usare il proxy usando le credenziali di un dominio Active Directory o di tipo NT4.
L'autenticazione si basa su winbind, il demone fornito con Samba che permette l'autenticazione degli utenti locali di una macchina Linux su un domain controller di un dominio di tipo Active Directory o NT4.
Il servizio winbind deve essere in esecuzione (anche non configurato) e la macchina su cui gira Squid deve aver joinato il dominio.
In /etc/squid/squid.conf
devono essere presenti le seguenti configurazioni:
Settaggi relativi al sistema di autenticazione:
auth_param ntlm program /usr/bin/ntlm_auth --helper-protocol=squid-2.5-basic
Alternativa che negozia automaticamente la password dell'utente loggato sul dominio
auth_param ntlm program /usr/bin/ntlm_auth --helper-protocol= squid-2.5-ntlmssp
Se si vuole permettere accesso solo a utenti del gruppo "navigatori" del dominio "DOMINIO" usare invece questa alternativa:
auth_param ntlm program /usr/bin/ntlm_auth --helper-protocol=squid-2.5-ntlmssp --require-membership-of="DOMINIO+navigatori"
Notare che è necessario avere "winbind separator = +
" in smb.conf (il file di configurazione di Samba) se si lascia il separator normale \ non funziona!
Le seguenti righe devono essere invece sempre presenti:
auth_param ntlm children 5
auth_param ntlm max_challenge_reuses 0
auth_param ntlm max_challenge_lifetime 2 minutes
auth_param ntlm use_ntlm_negotiate on
E' poi necessario configurare le acl di Squid per forzare la richiesta di autenticazione (cambiare gli ip della local_network secondo le proprie esigenze):
acl password proxy_auth REQUIRED
acl local_network src 192.168.171.0/24
http_access allow local_network password
Tipo Infobox: TIPS - Skill Level: 3- INTERMEDIATE - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2007-04-13 15:48:18
E' possibile configurare Squid per filtrare tutte le richieste web che vengono eseguite dagli utenti con l'antivirus engine ClamAV.
Uno dei metodi utilizzabili prevede la configurazione di SquidClamAVredirector.
Scaricare SquidClamAVredirector dal sito ufficiale.
Prerequisiti sono Squid, ClamAV, Python e le librerie Python per interfacciarsi con ClamAV: pyclamav disponibili all'indirizzo: http://xael.org/norman/python/pyclamav/ .
Installazione pyclamav (Usare l'ultima versione disponibile)
Scaricare PyClamav dal sito ufficiale
tar -zxvf pyclamav-0.3.2.tar.gz
cd pyclamav-0.3.2
python setup.py build
python setup.py install
Installazione SquidCLamAV Redirector (SCAVR):
Scaricare SCAVR dal sito ufficiale.
tar -zxvf SCAVR.tar.gz
cp SquidClamAV_Redirector.py /usr/local/bin/
chmod +x /usr/local/bin/SquidClamAV_Redirector.py
cp SquidClamAV_Redirector.conf /usr/local/squid/etc/
chown squid /usr/local/squid/etc/SquidClamAV_Redirector.conf
vi /usr/local/squid/etc/SquidClamAV_Redirector.conf
Esempio di SquidClamAV_Redirector.conf
[SquidClamAV]
# restricted = http://virus.jackal-net.at/infected.php?virus=restricted
virusurl = http://10.0.0.178/infected.php
#virusurl = http://virus.jackal-net.at/infected.php
cleancache = 300
ForceProtocol = http or https
MaxRedirection = 99
MaxRequestsize = 2Mb
log_priority = LOG_INFO
log_facility = LOG_LOCAL6
acceptredirects = 300 301 302 303
MIMETypes = all image/bmp image/gif image/jpeg image/png image/tiff text/html
Timeout = 60.0
[Debug]
Infected = true
Clean = true
Error = true
Ignored = true
[Extensions]
pattern = all .jpg .exe .zip .rar .ar .com .bzip .gz
## [Proxy]
### http = http://localhost:3128
[Whitelist]
www.jackal-net.at = 0
Configurazione Squid
In squid.conf
inserire le seguente righe, utilizzando ovviamente i path corretti relativi a dove si è copiato lo script SquidClamAV_Redirector.py (deve essere eseguibile) sul proprio sistema:
redirect_program /usr/local/bin/SquidClamAV_Redirector.py -c /usr/local/etc/squid/SquidClamAV_Redirector.conf
redirect_children 5
redirector_access deny localhost
http_reply_access allow all
NOTA: La direttiva "redirector_access deny localhost" va messa dopo "acl localhost src 127.0.0.1/255.255.255.255" (che già esiste).
LINK: SquidClamAV Redirector - http://www.jackal-net.at/tiki-read_article.php?articleId=1
Tipo Infobox: TIPS - Skill Level: 4- ADVANCED - Autore: Andrea 'franz' Francesconi - Ultimo Aggiornamento: 2004-07-16 00:31:01
Già discussi e ridiscussi sono i benefici di un proxy all'interno nella infrastruttura di rete, primo fra tutti la gestione centralizzata delle restrizioni ai siti consentiti alla navigazione. La personalizzazione in questo contesto può essere mirata nel dettaglio, inutile dire che la presenza di numerose macchine sotto proxy aumenta proporzionalmente le difficoltà di gestione, favorendo ad esempio la possibilità di abusi da parte di utenti legittimi.
La funzione del Transparent Proxy è quella di intercettare ogni richiesta di un particolare servizio (in questo caso richiesta HTTP) per poi redirigerla a un proxy (Squid) affinchè svolga tutte le funzioni del caso (semplice content filtering piuttosto che caching). Nel dettaglio la funzionalità di intercettare traffico appartiene ai vari packet filtering, Squid assolve eslusivamente i compiti di proxy.
I benefici portati da una implementazione simile sono notevoli: la forzatura a utilizzare il proxy lato client è trasparente per l'utente; l'amministratore è relativamente certo di controllare il traffico HTTP per tutte le workstation che gestisce.
L'analisi viene effettuata su un'unica macchina che assolve entrambi i compiti di packet filtering e proxyserver (opzione sicuramente discutibile).
Si considera la config di Squid:
...
# Forzo il binding di Squid su localhost
http_port 127.0.0.1:3128
...
# Direttive minime per le funzionalità di proxy
httpd_accel_host virtual
httpd_accel_port 80
httpd_accel_with_proxy on
httpd_accel_uses_host_header on
L'opportuna gestione delle ACL di Squid terminerà la config del proxy, implementando politiche di navigazione per indirizzi ip / subnet ip che daranno origine alla richiesta.
Lato packet filtering si considera la configurazione per pf (OpenBSD):
#/etc/pf.conf
...
rdr on $int_if inet proto tcp from any to any port www -> 127.0.0.1 port 3128
...
e iptables (Linux):
#iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 3128
in entrambi i casi si redirige il traffico HTTP sullo Squid locale.
Osservazioni
Come già accennato risulta sicuramente discutibile la scelta di integrare packet filter e proxy sulla stessa macchina, da valutare in base al contesto di utilizzo della soluzione.
Inoltre, l'attuale configurazione redirige OGNI richiesta HTTP, incurante della sorgente e delle destinazione del traffico (da rivalutare con l'eventualità di webserver all'interno della rete).
Infine, una centralizzazione di questo tipo porta a un "single point of failure" rappresentato dal proxy; anche in questo caso risulta doverosa l'analisi sulla eventuale implementazione di una soluzione ridondata.
Tipo Infobox: TIPS - Skill Level: 2- JUNIOR - Autore: Massimo 'maxgrante' Caselli - Ultimo Aggiornamento: 2004-05-31 18:24:30
Tra i molteplici vantaggi di SQUID c'è da considerare il logging delle navigazioni effettuate tramite proxy da parte dei client che lo utilizzano.
Vediamo alcune configurazioni che si possono fare in squid.conf per customizzare il logging in base alle proprie esigenze.
ATTIVAZIONE LOGGING CON LO STILE DI QUELLO DEI WEB SERVER
emulate_httpd_log off/on
Di default SQUID logga con una sua propria modalità e quindi il default di questo parametro di configurazione è impostato ad OFF.
Esempio di logging secondo il formato nativo di Squid:
1084289766.082 410 blasco.intranet TCP_MISS/200 28491 GET http://openskills.info/ - DIRECT/213.198.151.253 text/html
Impostando ad ON il suddetto parametro Squid inizierà a loggare nel seguente modo:
blasco.intranet - - [11/May/2004:17:29:33 +0200] "GET http://openskills.info/modify/modify.php? HTTP/1.0" 200 16486 TCP_MISS:DIRECT
Indubbiamente l'emulazione del logging stile web server rende l'analisi dei log di più facile lettura e risulta utilizzabile da un maggior numero di programmi di analisi e statistiche di traffico.
ATTIVAZIONE LOGGING CON DNS LOOKUP
log_fqdn off/on
Anche per questa configurazione di SQUID il default è OFF e non abilita un reverse lookup per ottenere il come completo di ogni IP che si collega al proxy.
E' sempre consigliabile lasciare il default in quanto la risoluzione dell'hostname da parte di SQUID può introdurre delle latenze e rallentare il proxy, ovviamente in alcuni casi però può essere utile attivare questa opzione.
Ovviamente per ottenere effetto sulle proprie modifiche occorre riavviare il servizio squid.
Tipo Infobox: TIPS - Skill Level: 4- ADVANCED - Autore: Andrea 'franz' Francesconi - Ultimo Aggiornamento: 2004-04-30 11:11:51
Le ragioni che portano all'utilizzo di un proxy sono molteplici, considerate le numerose funzioni che tale apparato è in grado di soddisfare. Nel dettaglio, il reverse proxy risulta indicato nel caso in cui sia necessario eseguire relay di un client esterno verso un server interno. I vantaggi di una simile implementazione spaziano da motivi prestazionali (riducendo il carico del server) fino a considerazioni che riguardano la security, sia dell'applicazione che del server che la ospita.
La configurazione di esempio sotto riportata simula l'implementazione di un reverse proxy per un server web installato su una diversa macchina.
# Forzo l'ascolto di Squid sulla porta 80
http_port 80
# Definisco una ACL...
acl allowed_hosts src 0.0.0.0/0.0.0.0
# ... e ne autorizzo il traffico sopra definito
http_access allow allowed_hosts
# Definisco l'indirizzo IP del server web interno
httpd_accel_host 192.168.51.67
# Definisco la relativa porta sul quale è in ascolto il server interno
httpd_accel_port 9900
# Le richieste non presenti in cache vengono dirottate sul server interno
httpd_accel_single_host on
# Attivo funzioni di application proxy e caching
httpd_accel_with_proxy on
# Da abilitare nel caso in cui il server interno utilizzi VirtualHost
httpd_accel_uses_host_header off
Tipo Infobox: TIPS - Skill Level: 3- INTERMEDIATE - Autore: Andrea 'franz' Francesconi - Ultimo Aggiornamento: 2004-05-31 18:22:26
Squid contiene funzionalità di proxy "anonimizzante", permettendo di nascondere al sito visitato l'IP dal quale ha origine la richiesta HTTP client.
Le istruzioni da aggiungere al file di configurazione squid.conf
:
# Disabilito il sistema di cache logging
cache_access_log /dev/null
cache_store_log none
cache_log /dev/null
# Eventuali ip loggati vengono forzati a 0.0.0.0
client_netmask 0.0.0.0
# Tutti possono accedere al proxy
http_access allow all
# Forzo il client a non fornire alcuna identità al server richiedente
forwarded_for off
# Disabilito le statistiche sui client che si connettono
client_db off
Le istruzioni sopra riportate permettono la non tracciabilità da parte del server verso il client autore della richiesta HTTP, ma non riguardano la cifratura del traffico tra il client e il server proxy; con uno sniffer potrebbe essere possibile analizzare il traffico, poichè non criptato.
Una comunicazione sicura in questo senso può essere implementata con:
- Squid in modalità SSL (su HTTPS), con cifratura appunto SSL del traffico tra client e proxy server;
- tunnel SSL (con stunnel) tra client e server.
Tipo Infobox: TIPS - Skill Level: 4- ADVANCED - Autore: Roberto 'rpennol' Pennolino - Ultimo Aggiornamento: 2004-04-19 22:35:16
Il Web Proxy Autodiscovery Protocol è un protocollo di livello 7 elaborato da un gruppo di produttori software (Microsoft, RealNetworks, Sun Microsystem ed InkTomi.....) che consente all'utente finale di configurare il proprio browser web in maniera trasparente, ovvero senza fare ricorso ad alcuna configurazione manuale.
Il protocollo WPAD permette ad alcuni browser (quali ad esempio Microsoft Internet Explorer) di autoconfigurare il proxy server tramite un semplice javascript che viene cercato automaticamente all'indirizzo (se esiste) http://wpad[.dominio.it]//wpad.dat
Alcuni grossi Internet Provider (tin.it per esempio) preferiscono indicare agli utenti il percorso del file di autoconfigurazione. Ma in piccole realtà aziendali è preferibile far fare tutto al browser.
Fondamentale è configurare regolarmente il proxy server Squid e poi:
- Modificare il file /etc/mime.types
per specificare il MIME TYPE dei file .dat
- Creare nella document root di APACHE il file wpad.dat
- Creare un alias di tipo “wpad.dominio.it” sul server web su cui abbiamo creato il file wpad.dat
Ma procediamo con ordine.
Innanzitutto apriamo con un editor di testo il file mime.types
presente in /etc ed aggiungiamo la riga:
application/x-ns-proxy-autoconfig pac dat
Creiamo nella document root del server web configurato per rispondere a wpad.dominio.it (generalmente /var/www/html) il file wpad.dat
con un semplice javascript tipo:
function FindProxyForURL( url, host )
{
if( isPlainHostName( host ) || // se nessun dominio viene specificato
dnsDomainIs( host, "intranet.palermo" ) || // se viene richiesto un url del dominio locale indicato
shExpMatch( url, "https*" ) || // se si usano protocolli sicuri
shExpMatch( url, "snews*" ) )
return "DIRECT";|| // Non si usa alcun proxy
else
return "PROXY 192.168.1.1:3128; " + // Altrimenti usare il proxy indicato
"DIRECT";
}
Dove:
192.168.1.1 -> indirizzo ip del proxy server
3128 -> posta di default di ascolto del server proxy SQUID
intranet.palermo -> dominio (in questo caso non esistente nella realtà) locale per il quale non usare il proxy
Editiamo il file relativo agli indirizzi dns per la zona dominio.it inserendo (nel caso di utilizzo di una distribuzione Fedora Core 1 sotto /var/named/chroot) la riga che fa riusolvere wpad.dominio.it con lìIP del server web dove è stato inserito il file wpad.dat:
wpad IN A 192.168.1.10
Rifacciamo partire SQUID, NAMED e HTTPD.
Selezioniamoo in Microsoft Internet Explorer Strumenti -> Opzioni Internet -> Connessioni -> Impostazioni LAN -> Configurazione automatica (rileva impostazioni automaticamente).
In questo modo il browser utilizzerà il proxy in modo trasparente all’utente.
Tipo Infobox: TIPS - Skill Level: 3- INTERMEDIATE - Autore: Massimo 'maxgrante' Caselli - Ultimo Aggiornamento: 2004-05-31 18:03:10
All'interno di un'azienda la navigazione spesso viene gestita dal Proxy per svariati motivi:
- Autorizzazione alla navigazione tramite autenticazione degli utenti
- Gestione Access List che permettono di autorizzare/negare la navigazione alle macchine ad esempio in base agli indirizzi IP
- Logging di tutte le richieste fatte dai singoli client che navigano sulla linea internet aziendale
- Risparmio di banda grazie alla gestione da parte del proxy da parte del proxy server
- Possibilità di blocco di diversi indirizzi web.
La scelta del proxy server ricade quasi esclusivamente su Squid per le sue performance, affidabilità e per il fatto che è Open Source e quindi nella visione (distorta) di questo fenomeno da parte dei dirigenti aziendali, gratuito.
Squid può essere configurato per limitare l'accesso o meno a determinati siti web, per fare ciò bisogna utilizzare il TAG url_regex
con cui è possibile indicare i file contenenti la lista delle parole chiave selezionate che non possono essere presenti negli URL richiesti dal client.
Esempio:
acl badlanguage url_regex "/etc/squid/squidblock/badlanguage.txt"
acl entertainment url_regex "/etc/squid/squidblock/entertainment.txt"
acl games url_regex "/etc/squid/squidblock/games.txt"
acl mp3 url_regex "/etc/squid/squidblock/mp3.txt"
acl pirates url_regex "/etc/squid/squidblock/pirates.txt"
acl porno url_regex "/etc/squid/squidblock/porno.txt"
A questo punto basta applicare le ACL che abbiamo appena definito tramite il TAG http_access
come nell'esempio:
http_access deny badlanguage
http_access deny entertainment
http_access deny games
http_access deny mp3
http_access deny pirates
http_access deny porno
Per poter avere una lista aggiornata di siti web da bloccare si segnalano un paio di siti che forniscono e aggiornano i files contenenti i vari domini negati:
http://www.squidblock.com
http://www.squidguard.org
In particolare quest'ultimo permette tramite un semplice script sul server di scaricare gli aggiornamenti che sono veramente molto frequenti.
LINK: SquidGuard - Tool e blacklist per Squid - http://www.squidguard.org
LINK: SquidBlock: Elenco di blacklist di siti da integrare in Squid - http://www.squidblock.com
LINK: Malware Block List (for Squid & SpamAssassin) - http://www.malware.com.br/
LINK: DansGuardian Home Page - http://dansguardian.org/
Tipo Infobox: TIPS - Skill Level: 3- INTERMEDIATE - Autore: lorenzo 'lorenz' urbinati - Ultimo Aggiornamento: 2003-06-30 21:45:28
I parametri da inserire nel file di configurazione di squid per abilitare l'autenticazione base degli utenti non sono molti e i commenti all'interno del file sono molto chiari e specifici.
Se ci si avvale di un'installazione di default di squid non occorre compilare programmi aggiuntivi come consigliato nello squid.conf. Bisogna operare sulla direttiva auth_param. Di norma i valori di default saranno sufficienti e occorrerà in caso si desideri abilitare l'autenticazione base scommentare la riga che riguarda questo tipo.
La riga dovrebbe apparire come segue
#auth_param basic program < uncomment and complete this line >
Quello che occorre è specificare il percorso del programma esterno che si occupa di autenticare gli utenti e il percorso del file delle password.
Per un'autenticazione base il programma che occorre si chiama ncsa_auth e si trova su RedHat9.0 in /usr/lib/squid/
Per il file delle password il percorso è arbitrario e va creato con il comando di Apache htpasswd.
La sua sintassi è la seguente
htpasswd -c [nome del file] [nome dell'utente]
Se non ci si trova nella directory scelta per questo file occorrerà specificare l'intero percorso oltre al nome del file.
Una volta effettuata questa operazione la riga del file squid.conf deve essere modificata come segue:
auth_param basic program /usr/lib/squid/ncsa_auth /etc/squid/squidpasswd
Ora non resta che specificare una acl che abiliti l'autenticazione con l'istruzione proxy_auth.
acl nomeacl proxy_auth REQUIRED
e di seguito permettere l'accesso a questa acl
http_access allow nomeacl
In questo modo all'accesso di un browser al proxy si dovrebbe aprire una finestra che chiede di inserire utente e password.
Questa forma di autenticazione, come detto, è base e i parametri utente e password sono inviati in chiaro; per approfondire e implementare un'altro tipo di autenticazione leggere la documentazione ufficiale di squid. Da notare che si possono specificare più metodi in comune e verranno considerati dal client in ordine di sicurezza dalla più alta a quella base.
LINK: Integrating Squid and Samba3 with NTLM authentication - http://mkeadle.org/?p=13
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Massimo 'maxgrante' Caselli - Ultimo Aggiornamento: 2004-05-31 18:24:15
Il proxy server è uno strumento che permette di condividere tra più client un singolo accesso ad Internet, gestendo una cache delle informazioni precedentemente scaricate che consente di risparmiare banda e velocizzare la navigazione.
SQUID è un software che ci permette di implementare un proxy server sulla nostra rete interna senza grandi difficoltà e con ottimi risultati.
SQUID supporta oltre al protocollo HTTP anche FTP, Gopher, SSL e altri protocolli Internet.
L'installazione più semplice avviene tramite RPM, addirittura in molti casi l'installazione avviene direttamente dall'installazione della nostra distribuzione Linux. Per sapere se Squid è già installato sul nostro sistema è possibile verificarlo con il classico comando:
rpm -q squid
Se squid è già installato procedere con lo scaricamento dell'ultima release stabile per la propria distribuzione linux ed eseguire:
rpm -U squid-2.x.x-xx.i386.rpm
Nel caso non sia già installato eseguire invece il comando:
rpm -iv squid-2.x.x-xx.i386.rpm
A questo punto SQUID sarà installato nel nostro sistema ed avviabile tramite il comando /etc/init.d/squid start
. Il primo avvio potrebbe impiegare un pò di tempo in quanto dovrà settare la cache in /var/spool/squid
. Con il file di configurazione di default il servizio dovrebbe risultare da subito avviabile senza particolari interventi sulla configurazione e restare in ascolto sulla porta di default 3128.
E' probabile che a questo punto sia comunque necessario configurare squid per permettere di essere utilizzato dai client abilitati. Intervenire su /etc/squid/squid.conf
(sempre ben commentato) per il tuning della configurazione.
Traffic monitoring |
Tools per il monitoraggio del traffico IP |
Tipo Infobox: TIPS - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2005-04-28 11:17:49
Breve guida alla configurazione di MRTG su Fedora.
Quanto qui riportato può essere adattato a qualsiasi distribuzione.
Le fasi essenziali per mettere in funzione un sistema di monitoraggio basato su MRTG sono:
- Configurazione di una community (read only) sugli apparati di frete da monitorare
- Installazione di MRTG
- Scelta della directory dove mettere i file (log e graifici) di MRTG. Si consiglia una sottodirectory per ogni host monitorato
- Creazione dei file di configurazione (uno per ogni apparato monitorato) con cfgmaker
- Creazione della pagina di indice per i grafici delle interfacce dell'host, con indexmaker
- Configurazione di Apache per esportare via http la directory dove MRTG salva i grafici
- Schedulazione, tramite cron, dell'esecuzione di mrtg (una per ogni file di configurazione)
Vediamo, velocemente, come procedere su Fedora/RedHat, utilizzando i path e gli standard propri del pacchetto rpm di mrtg per Fedora.
In questo esempio si valuta il monitoraggio di un unico apparato.
Installazione:
yum install mrtg
Elenco dei file installati (non necessario ma sempre interessante):
rpm -ql mrtg
Creazione di un file di configurazione secondo le logiche di Fedora (nell'esempio l'apparato monitorato ha IP 192.168.1.100 e community "prova"):
cfgmaker [email protected] --global "WorkDir: /var/www/mrtg" > /etc/mrtg/mrtg.cfg
Prova di funzionamenteo (non necessaria ma utile). Notare che è necessario modificare la variabile d'ambiente LANG, perchè quella di default su Fedora è in formato Unicode (es: en_US.UTF-8) e crea problemi con vari programmi Perl, tra cui lo stesso MRTG:
export LANG=C
mrtg /etc/mrtg/mrtg.cfg
Creazione di un file html con l'elenco delle interfacce monitorate sulla base del file di configurazione appena creato:
indexmaker /etc/mrtg/mrtg.cfg > /var/www/mrtg/index.html
Configurazione di Apache per permettere l'accesso ai grafici di MRTG da indirizzi esterni a localhost.
vi /etc/httpd/conf.d/mrtg.conf
Modificare Allow from 127.0.0.1 in, per esempio, Allow from 192.168.0.
Riavviare Apache:
/etc/init.d/httpd reload
A questo punto dovrebbe essere possibile visualizzare i grafici di MRTG del nostro server Linux con IP ipotetico 192.168.0.2 all'URL : http://192.168.0.2/mrtg
La schedulazione di mrtg usando il file di configurazione /etc/mrtg/mrtg.cfg è già operativa grazie al file di cron, installato con il pacchetto rpm: /etc/cron.d/mrtg
.
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Arnaldo 'homer' Zitti - Ultimo Aggiornamento: 2003-06-27 00:18:25
Ntop è uno dei più diffusi ed apprezzati programmi di network monitoring. Si basa sulle librerie libcap ed è stato sviluppato per girare su molteplici piattaforme. E' stato sviluppato in Italia e rilasciato sotto licenza GPL.
Ntop è un utility di Traffic Monitoring (e non solo) sviluppata traendo ispirazione dal programma Unix per la visualizzazione dei processi top. Tra le caratteristiche maggiormente volute dagli sviluppatori quella di essere portabile in modo da girare su diverse piattaforme Unix.
Sono disponibili versioni per: Linux, IRIX, Solaris, Sparc, HP-UX, FreeBSD, AIX e MacOSX.
Ntop può utilizzare anche software esterni per i propri compiti come per esempio nmap, lsof o mySql ma è fondamentale la presenza della libreria libpcap utilizzata per l'analisi dei pacchetti.
Le modalità di utilizzo di ntop sono due:
- interactive: visualizza le informazioni tramite la shell in modo simile a top (funzione a breve non più supportata);
- web mode: grazie al web server incorporato è possibile visualizzare le informazioni fornite collegandosi tramite browser all'indirizzo hostname:numero-porta (Es.: http://enigma:3000/ oppure http://192.168.0.2:3000) ;
Le principali funzioni svolte da ntop sono:
- Misurazione del traffico
- Monitoraggio del traffico
- Ottimizzazione e pianificazione della rete
- Individuazione di problemi di sicurezza
Misurazione del traffico
Ntop raccoglie le informazioni osservando il traffico che passa sulla rete e generando statistiche per ogni host monitorato. Ogni pacchetto viene catturato e classificato in base alla coppia sorgente:destinazione.
Le informazioni visualizzate da ntop per ogni host sono le seguenti:
- Dati Inviati/Ricevuti: Traffico totale generato o ricevuto dall'host, classificato in base al protocollo e protocollo IP;
- Utilizzo di banda: Valore attuale, medio e picchi di utilizzo della banda;
- Ip Multicast: Totale traffico Multicast generato o ricevuto dall'host;
- Sessioni TCP: Sessioni TCP stabilite, e relative statistiche di traffico;
- Traffico UDP: Traffico UDP ordinato per porta;
- Servizi TCP/UDP: Elenco dei servizi TCP e UDP utilizzati e degli ultimi cinque host che li hanno utilizzati;
- Distribuzione del traffico: Traffico locale, traffico verso hosts remoti, traffico da hosts remoti;
- Distribuzione del traffico IP: Rapporto tra TCP e UDP;
Le statistiche visualizzate a livello globale sono:
- Distribuzione del traffico: Rapporto tra traffico locale e traffico remoto ;
- Distribuzione pacchetti: Il numero totale di pacchetti ordinati per dimensione, rapporto fra unicast e broadcast e fra traffico IP e traffico non IP;
- Utilizzo della banda: Valore attuale, medio e picchi di utilizzo della banda;
- Distribuzione vari protocolli: Distribuzione del traffico in relazione al protocollo e alle coppie sorgente:destinazione;
- Matrice del traffico interno: Monitoraggio del traffico per ogni coppia di Host;
- Flussi di rete: Flussi di traffico di particolare interesse per l'amministratore;
Monitoraggio del traffico
Il monitoraggio del traffico consiste nel controllare quando la rete presenta un carico eccessivo oppure non sono rispettate le policy stabilite. Ntop è utile per vedere rapidamente una situazione anomala la quale può derivare per esempio da errate configurazioni di networking. Tra i tipi di problemi individuati da ntop abbiamo:
- Uso di indirizzi IP duplicati;
- Identificazione di con schede di rete configurate in modalità "promiscuous mode";
- Errata configurazione di software di rete (ricavata in basi all'analisi dei protocolli);
- Uso non consentito di protocolli;
- Uso improprio di servizi;
- Identificazione di router (Workstation configurate da router e che permettono quindi traffico non consentito);
- Eccessivo utilizzo di banda.
Ottimizzazione e pianificazione della rete
Analizzando i risultati ottenuti da ntop è possibile individuare protocolli inutilmente attivi sulla rete, problemi di routing oppure host che generano un inutile spreco di banda e prendere quindi le dovute azioni al fine di migliorare le performances della rete.
Individuazione di problemi di sicurezza
Sotto il profilo security, ntop è in grado di individuare casi di IP Spoofing, schede di rete in promiscuous mode, attacchi di tipo Denial of Services, Troian Horses su porte note, e portscanning. Una volta individuato un problema di sicurezza sono disponibili diverse opzioni per segnalarlo al network administrator (e-mail, SNMP oppure SMS) oppure porre in essere specifiche azioni al fine di limitare o bloccare l'attacco.
LINK: Home page ntop - http://www.ntop.it/
SOURCE: ntop Documentation - http://www.ntop.it/documentation.html
Tipo Infobox: ETCETERA - Skill Level: 2- JUNIOR - Autore: Arnaldo 'homer' Zitti - Ultimo Aggiornamento: 2004-06-04 10:49:10
Tra gli ambienti per cui è stato sviluppato ntop sono presenti anche i sistemi Windows 95/98/ME/NT/2K/XP.
Mentre le varie versioni Unix sono distribuite free of charge, la versione precompilata completa per Windows è disponibile a pagamento. Gli autori hanno fatto questa scelta in quanto lo sviluppo per questo ambiente comprende i costi per la lincenza del sistema operativo e per il relativo software di sviluppo.
La versione Windows fa comunque parte dello stesso albero sorgente delle versioni Unix ed il codice è liberamente scaricabile. Una versione demo precompilata è disponibile per il download sul sito degli autori, ma con la limitazione alla cattura di 1000 pacchetti. Per usufruire della full version sono possibili due vie: ricompilare i sorgenti togliendo la limitazione oppure registrare la propria versione di ntop per Windows in modo da ottenere quella senza restrizioni.
LINK: ntop Windows Version - http://www.ntop.it/support.html
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Arnaldo 'homer' Zitti - Ultimo Aggiornamento: 2004-11-30 16:45:44
MRTG (Multi Router Traffic Grapher) è uno strumento per il traffic monitoring di rete in grado di generare una serie di pagine HTML contenenti la rappresentazione grafica del traffico.
Questo tool, rilasciato sotto licenza GPL, consiste sostanzialmente in due componenti principali: uno script in linguaggio Perl ed un programma scritto in linguaggio C. Lo script Perl, grazie all'ausilio del protocollo SNMP (Simple Network Management Protocol) legge i contatori di traffico dei router, mentre il programma C si occupa di tenere traccia del traffico letto e di generare la rappresentazione grafica in formato PNG visualizzabile successivamente tramite un web browser.
MRTG fa uso di alcune librerie esterne: gd per la grafica, libpng per le immagini PNG e zlib per comprimere le immagini create. Se queste librerie non sono già presenti nel proprio sistema è necessario installarle.
Le caratteristiche principali di MRTG sono:
- Portabilità: E' disponibile per diverse veresioni UNIX ed anche per Windows;
- Perl: Il programma è scritto in Perl ed il codice è liberamente disponibile e modificabile;
- Supporto SNMP: possibilità di monitorare qualsiasi variabile SNMP ed anche SNMPv2;
- Log di lunghezza costante: viene utilizzato un algoritmo che permette di mantenere costante la dimensione dei log;
- Identificazione affidabile interfaccia di rete: MRTG per identificare l'interfaccia di rete di un router puo' utilizzare oltre all'indirizzo IP anche la descrizione oppure l'ethernet address (MAC);
- Performance: le parti critiche del codice sono state scritte in linguaggio C;
- Personalizzazione: le pagine HTML prodotte da MRTG sono completamente personalizzabili;
- Grafica Free: le immagini PNG sono generate dalle librerie open source gd;
- Configurazione automatica: la configurazione è facilitata da alcuni tools forniti a corredo del programma;
- RRDtool: esiste la possibilità di utilizzare RRDtool (creato dallo stesso autore) per generare i grafici;
SOURCE: Home Page MRTG - http://people.ee.ethz.ch/~oetiker/webtools/mrtg/
Tipo Infobox: COMMANDS - Skill Level: 2- JUNIOR - Autore: Arnaldo 'homer' Zitti - Ultimo Aggiornamento: 2004-06-04 10:49:26
E' l'eseguibile dell'utilty di traffic monitoring ntop.
Ntop permette di monitorare il traffico di rete in base ad un numero decisamente elevato di opzioni. Di seguito alcune tra le più utilizzate.
La sintassi è:
ntop [opzioni]
@nomefile
: è possibile utilizzare un file, contenente linee vuote o linee di commento (le quali inziano con #), dove inserire tutte le opzioni con cui lanciare ntop. Questa caratteristica puo' essere usata anche in combinazione con opzioni date a linea di comando;
-a <percorso>
: per default ntop non mantiene traccia delle connessioni al suo web server. Tramite questa opzione è possibile specificare il file di log relativo agli accessi. Il formato di logging è simile a quello di Apache Web Server;
-d
: avvia ntop come demone in background senza occupare nessuna finestra di terminale;
-l <nomefile>
: salva i dati sul file specificato in formato leggibile da tcpdump;
-h
: visualizza l'help in linea sulle opzioni disponibili:
-i
: specifica quali interfacce vengono utilizzate da ntop;
-l <nomefile>
: salva i dati sul file specificato in formato pcap;
-m <indirizzo>
: Indica le subnets da consideare locali;
-n
: visualizza l'indirizzo IP anzichè il nome simbolico dell'interfaccia;
-p
: specifica i protocolli TCP/UDP da monitorare;
-u
: indica i privilegi utente con i quali gira ntop, se non specificato viente utilizzato nobody;
-z
: disabilita il tracking delle sessioni TCP;
-r <percorso>
: specifica il tempo in secondi per gli aggiornamenti dei dati;
-V
: stampa la versione di ntop ed esce;
-w <porta>
: avvia il web server incorporato sulla porta specificata (di default viene avviato sulla porta 3000);
-A
: setta la password di amminstratore di ntop ed esce;
-D
: identifica il dominio locale (utile se ntop non riesce ad indentificarlo automaticamente);
-E
: permette a ntop di avvelersi dell'ausilio di tools esterni;
-L <facility>
: utilizza syslog anzichè lo standard output per visualizzare i log;
-M
: mantiene le statistiche separate per ogni interfaccia di rete;
-P <percorso>
: specifica dove si trova il database con le password di ntop;
-W <porta>
: avvia il web server con supporto SSL sulla porta specificata (di default porta 3001)
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Arnaldo 'homer' Zitti - Ultimo Aggiornamento: 2004-06-01 22:32:06
L'installazione di ntop può essere eseguita tramite compilazione dei sorgenti oppure scaricando i pacchetti di precompilati disponibili per la propria distribuzione Linux.
PREREQUISITI
Prereqisito fondamentale prima di installare ntop è la presenza delle librerie libpcap.
INSTALLAZIONE TRAMITE RPM
E' possibile reperire i pacchetti RPM da uno dei molti mirror di SourgeForge.net:
[root@Enigma software]# wget http://switch.dl.sourceforge.net/sourceforge/ntop/ntop-2.2-0.i386.rpm
--22:55:55-- http://switch.dl.sourceforge.net/sourceforge/ntop/ntop-2.2-0.i386.rpm
=> `ntop-2.2-0.i386.rpm'
Resolving switch.dl.sourceforge.net... done.
Connecting to switch.dl.sourceforge.net[195.176.255.8]:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 3,465,148 [application/x-rpm]
100%[=================================================================================>] 3,465,148 4.18K/s ETA 00:00
23:09:12 (4.18 KB/s) - `ntop-2.2-0.i386.rpm' saved [3465148/3465148]
Il pacchetto RPM di ntop richiede la presenza di rrdtool, librrd.so.0, libcrypto.so.2, libssl.so.2. Solo gli ultimi due file menzionati sono necessari per il programma, mentre i file relativi ad rrd non sono indispensabili almeno che non si decida di utilizzare RRDtool per la generazione dei grafici. Una volta effettuata questa scelta è possibile installare il programma:
[root@Enigma software]# rpm -ivh --nodeps ntop-2.2-0.i386.rpm
Preparing... ########################################### [100%]
1:ntop ########################################### [100%]
In questo caso si è scelto di non utilizzare gli rrdtool e quindi si è utilizzato rpm con l'opzione --nodeps altrimenti l'installazione si sarebbe bloccata per problemi di dipendenze
INSTALLAZIONE TRAMITE COMPILAZIONE DEI SORGENTI
Anche per la versione in sorgente è possibile usufruire di vari mirror:
root@Joker:/software# wget http://switch.dl.sourceforge.net/sourceforge/ntop/ntop-2.2.tgz
--08:04:56-- http://switch.dl.sourceforge.net/sourceforge/ntop/ntop-2.2.tgz
=> `ntop-2.2.tgz'
Resolving switch.dl.sourceforge.net... done.
Connecting to switch.dl.sourceforge.net[195.176.255.8]:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 2,551,153 [application/x-gzip]
100%[==================================================================================>] 2,551,153 3.57K/s ETA 00:00
08:16:42 (3.57 KB/s) - `ntop-2.2.tgz' saved [2551153/2551153]
Una volta scaricati i sorgenti è necessario scompattarli.
root@Joker:/software# tar -zxvf ntop-2.2.tgz
A questo punto verrano create due directory rispettivamente per le librerie grafiche /ntop-2.2/gdchart0.94c/
e /ntop-2.2/ntop/
per il programma vero e proprio:
root@Joker:/software/ntop-2.2# ls
gdchart0.94c ntop
Per prima cosa è necessario compilare le librerie grafiche:
root@Joker:/software/ntop-2.2# cd gdchart0.94c/
root@Joker:/software/ntop-2.2/gdchart0.94c# ./configure
...
Configurazione delle librerie GD
root@Joker:/software/ntop-2.2/gdchart0.94c# cd gd-1.8.3//libpng-1.2.4
root@Joker:/software/ntop-2.2/gdchart0.94c/gd-1.8.3/libpng-1.2.4# cp scripts/makefile.linux Makefile
root@Joker:/software/ntop-2.2/gdchart0.94c/gd-1.8.3/libpng-1.2.4# make
...
Compilazione delle librerie per la gestione delle immagini in formato PNG
root@Joker:/software/ntop-2.2/gdchart0.94c/gd-1.8.3/libpng-1.2.4# cd ../../zlib-1.1.4/
root@Joker:/software/ntop-2.2/gdchart0.94c/zlib-1.1.4# ./configure
root@Joker:/software/ntop-2.2/gdchart0.94c/zlib-1.1.4# make
...
Compilazione delle librerie zlib per la decompressione PNG
root@Joker:/software/ntop-2.2/gdchart0.94c/zlib-1.1.4# cd ..
root@Joker:/software/ntop-2.2/gdchart0.94c# make
Infine compilazione delle librerie GD
Una volta compilate le librerie di supporto si può passare alla directory ntop per la parte principale del programma:
root@Joker:/software/ntop-2.2# cd ntop
root@Joker:/software/ntop-2.2/ntop# ./configure
Welcome to ntop, Version 2.2
copyright (c) 1998-2003 Luca Deri
Configuration script version v2.2.000-2003-04-14
...
root@Joker:/software/ntop-2.2/ntop# make
...
root@Joker:/software/ntop-2.2/ntop# make install
CONFIGURAZIONE POST INSTALLAZIONE
La prima volta che il programma viene eseguito, deve essere creato l'utente administrator di ntop. Questo può essere fatto grazie all'ausilio dell'opzione -A
:
Ntop viene quindi lanciato con l'opzione -A
:
root@Joker:# ntop -P /usr/share/ntop -u ntop -A
Wait please: ntop is coming up...
18/Jun/2003 09:04:04 Initializing gdbm databases
18/Jun/2003 09:04:04 THREADMGMT: Started thread (1026) for network packet analyser
18/Jun/2003 09:04:04 THREADMGMT: Idle Scan thread (0) started
18/Jun/2003 09:04:04 THREADMGMT: Packet processor thread (1026) started...
18/Jun/2003 09:04:04 THREADMGMT: Started thread (2051) for idle hosts detection
18/Jun/2003 09:04:04 THREADMGMT: Started thread (3076) for DNS address resolution
18/Jun/2003 09:04:04 THREADMGMT: Address resolution thread started...
Please enter the password for the admin user: ntop2003
Please enter the password again: ntop2003
18/Jun/2003 09:05:49 Admin user password has been set
A questo punto ntop è pronto per l'utilizzo. Può essere lanciato da linea di comando all'occorenza oppure dedicare ad esso un macchina per il monitoraggio della rete e lanciarlo tra gli script d'avvio.
Tipo Infobox: DESCRIPTION - Skill Level: 3- INTERMEDIATE - Autore: Arnaldo 'homer' Zitti - Ultimo Aggiornamento: 2008-04-13 15:44:24
MRTG è disponibile in rete sia in formato RPM che sorgente, di seguito la procedura di installazione e la configurazione di base per potere utilizzare questo strumento.
PREREQUISITI
L'utilizzo di MRTG per il monitoring del traffico necessita di avere installati alcuni software sulla propria macchina per poterlo utilizzare. In particolare deve essere presente un interprete Perl con il quale è sono stato scritto gran parte del codice del programma, e le librerie per la creazione e gestione dei grafici, ovvero zlib, libpng e gd. Ultimo requisito è l'esistenza un un agent SNMP sull'apparato da monitorare, in quanto MRTG ricava da esso i dati.
INSTALLAZIONE DA SORGENTI
E' possibile procedere al download dei sorgenti tramite il sito degli autori <a href="http://www.mrtg.org">http://www.mrtg.org:
root@Joker:/software# wget
http://people.ee.ethz.ch/~oetiker/webtools/mrtg/pub/mrtg-2.9.29.tar.gz
--02:44:15 --http://people.ee.ethz.ch/%7Eoetiker/webtools/mrtg/pub/mrtg-2.9.29.tar.gz
=> `mrtg-2.9.29.tar.gz.1'Resolving people.ee.ethz.ch... done.
Connecting to people.ee.ethz.ch[129.132.2.204]:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1,026,837 [application/x-tar]
100%[=================================================================================>] 1,026,837
4.32K/s ETA 00:00 02:48:09 (4.32 KB/s) - `mrtg-2.9.29.tar.gz.1' saved [1026837/1026837]
Successivamente si procede alla scompattazione dei sorgenti:
root@Joker:/software# tar xvfz mrtg-2.9.29.tar.gz
mrtg-2.9.29/ANNOUNCE
mrtg-2.9.29/THANKS
mrtg-2.9.29/CHANGES
mrtg-2.9.29/COPYING
...
mrtg-2.9.29/doc/mrtg.html
mrtg-2.9.29/doc/mrtg.pod
mrtg-2.9.29/doc/mrtg.txt
Una volta scompattati i sorgenti e' necessario posizionarsi nella directory appena creata e lanciare direttamente il comando ./configure
o ./configure --help
per le opzioni di configurazione:
homer@Joker:/scambio$ cd mrtg-2.9.29
root@Joker:/software/mrtg-2.9.29# ./configure --prefix=/usr/local/mrtg
checking for gcc... gcc checking for C compiler default output... a.out
checking whether the C compiler works... yes
...
ordering CD from http://people.ee.ethz.ch/~oetiker/wish .... just kidding ;-)
Infine per terminare l'installazione si utilizzano i classici make
e make install
:
root@Joker:/scambio/mrtg-2.9.29# make
gcc -DGFORM_GD=gdImagePng -g -O2 -Wall -Wpointer-arith -Wcast-align -Wmissing-declarations -Wnested-externs -Winline -W -DHAVE_CONFIG_H -c ./src/rateup.c -o bin/rateup.o
In file included from /usr/include/string.h:360,
...
/usr/bin/perl -0777 -p -i~ -e 's@^#!\s*/\S*perl@#! /usr/bin/perl@' ./bin/cfgmaker ./bin/indexmaker ./bin/mrtg
/usr/bin/perl -0777 -p -i~ -e 's@GRAPHFMT="...";@GRAPHFMT="png";@' ./bin/mrtg ./bin/indexmaker
root@Joker:/scambio/mrtg-2.9.29# make install
/bin/sh ./mkinstalldirs /usr/local/mrtg/bin
mkdir /usr/local/mrtg
mkdir /usr/local/mrtg/bin
...
for x in ./doc/*.1; do \
/usr/bin/ginstall -c -m 644 $x /usr/local/mrtg/man/man1; done
INSTALLAZIONE DA RPM
Per quanto riguarda i pacchetti RPM aggiornati e' possibile trovarli sul sito di Henry Gomez <a href="http://ftp.falsehope.com/home/gomez/">http://ftp.falsehope.com/home/gomez/:
[root@Enigma software]# wget http://ftp.falsehope.com/home/gomez/mrtg/mrtg-2.9.22-2.7.2.i386.rpm
--02:35:49-- http://ftp.falsehope.com/home/gomez/mrtg/mrtg-2.9.22-2.7.2.i386.rpm
=> `mrtg-2.9.22-2.7.2.i386.rpm' Resolving ftp.falsehope.com... done.
Connecting to ftp.falsehope.com[12.163.168.5]:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1,011,368 [application/x-rpm]
100%[=================================================================================>] 1,011,368 4.87K/s ETA 00:00
02:39:13 (4.87 KB/s) - `mrtg-2.9.22-2.7.2.i386.rpm' saved [1011368/1011368]
In seguito si installa il pacchetto:
[root@Enigma software]# rpm -ivh mrtg-2.9.22-2.7.2.i386.rpm
warning: mrtg-2.9.22-2.7.2.i386.rpm: V3 DSA signature: NOKEY, key ID 307a10a5
Preparing... ########################################### [100%]
1:mrtg ########################################### [100%]
CONFIGURAZIONE
Una volta installato, MRTG deve essere configurato in modo e quindi istruito su quali device di rete deve monitorare. Il file di configurazione e' mrtg.cfg
e puo' essere generato grazie all'ausilio dell'utility cfgmaker fornita con il programma.
root@Joker:/# /usr/local/mrtg-2/bin/cfgmaker \
indica la password SNMP per l'apparato da interrogare
--global "Workdir: /home/homerweb/arnaldotest" \ Workdir indica la directory in cui verrano salvate le pagine HTML generate
--global "options[_]: bits, growright" \ Indica di utilizzare i bit com unita' di misura e che la direzione del grafico e' da sinstra a destra
--output /etc/mrtg.cfg \ Indica il percorso ed il nome del file di configurazione
jkrnet@joker
--base: Get Device Info on jkrnet@joker:
--base: Vendor Id:
--base: Populating confcache
--snpo: confcache jkrnet@joker: Descr lo --> 1
--snpo:confcache jkrnet@joker: Descr eth0 --> 2
--snpo: confcache jkrnet@joker: Ip 127.0.0.1 --> 1
--snpo: confcache jkrnet@joker: Ip 192.168.0.1 --> 2
--snpo: confcache jkrnet@joker: Type 24 --> 1
--snpo: confcache jkrnet@joker: Type 6 --> 2
--snpo: confcache jkrnet@joker: Eth --> 1
--snpo: confcache jkrnet@joker: Eth 00-48-54-6e-e4-a2 --> 2
--base: Get Interface Info
--base: Walking ifIndex
--base: Walking ifType
--base: Walking ifAdminStatus
--base: Walking ifOperStatus
--base: Walking ifSpeed
--base: Writing /etc/mrtg.cfg
Vengono acquisite le informazioni per la configurazione e generato il relativo file
A questo punto MRTG ha tutti i dati necessari per essere avviato.
UTILIZZO DI MRTG
E' possibile utilizzare MRTG in due modi, inserire una entry nel file di configurazione di crontab in modo da eseguirlo ad intervalli regolari, oppure avviarlo tra gli script di avvio come demone.
Per quanto riguarda l'utilizzo con crontab e' possibile inserire una riga di configurazione simile a:
root@Joker:/# crontab -l
...
# CONFIGURAZIONE MRTG
*/5 * * * * /usr/local/mrtg/bin/mrtg /etc/mrtg.cfg --logging /var/log/mrtg.log
Esegue mrtg ogni 5 minuti, utilizzando come configurazione quanto definito in /etc/mrtg.cfg ed
eseguendo il log delle operazioni in /var/log/mrtg.log
Nel caso si voglia invece utilizzare MRTG come demone si deve aggiungere a mrtg.cfg la riga: RunAsDaemon: yes
e richiamare tra gli script d'avvio MRTG.
Una volta creato l'utente mrtg per avviare il programma e' possibile scrivere uno script d'avvio come:
[root@Enigma /]# cat /etc/rc.d/init.d/mrtg
#! /bin/sh
cd /usr/local/mrtg/bin && ./mrtg --user=mrtg-user \
/etc/mrtg.cfg --logging /var/log/mrtg.log
In questo caso mrtg viene avviato con le credenziali dell'utente mrtg-user, leggendo
la configurazione /etc/mrtg.cfg e abilitando il logging
Infine sara' necessario inserire un link in /etc/rc3.d/
come S91mrtg
per avviare MRTG quando il sistema entra nel runlevel 3.
LINK: MRTG Templates Repository - http://www.somix.com/support/mrtg_repository.php
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Arnaldo 'homer' Zitti - Ultimo Aggiornamento: 2005-06-14 10:44:37
Scritto da Alexei Vladishev, e disponibile per diverse piattaforme quali Linux, Solaris, HP-UX, AIX, Free BSD, Open BSD, OS X, e Windows, Zabbix è un tool di network e system monitoring che permette di generare report e grafici, sullo stato di salute di un sistema e notificare eventuali anomalie via mail.
Tra i dati analizzati da Zabbix: carico del processo, numero di processi nel sistema, numero di processi attivi, attività dei dischi, stato della partizione di swap, e della disponibilità di memoria ecc.
Il funzionamento di Zabbix è di tipo client/server. Sulle macchine da monitorare dette client vengono installati degli agent, i quali inviano i dati su una macchina server che si occuperà di memorizzare i valori in un database. E' quindi possibile, definire dei trigger in modo da segnalare al verificarsi di determinate condizioni, al system administrator eventuali anomalie, attraverso mail, oppure avvalendosi di programmi esterni per l'invio di SMS o altri metodi di notifica.
Tra le caratteristiche principali:
- supporto di polling e trapping come metodo di cattura degli eventi di sistema;
- server disponibile per Linux, Solaris, HP-UX, AIX, Free BSD, Open BSD, OS X;
- client nativo disponibile per Linux ,Solaris, HP-UX, AIX, Free BSD, Open BSD, OS X, Windows NT4.0, Windows 2000, Windows 2003, Windows XP;
- monitor senza l'ausilio di agent esterni;
- autenticazione;
- interfaccia web;
- notifica via email;
Zabbix è un software open source, distribuito sotto licenza GPL. Per essere utilizzato necessita di Apache Web Server, PHP, ed un motore database quale MySQL oppure PostgreSQL.
LINK: Zabbix Home Page - http://www.zabbix.com/
Il protocollo SMTP |
Simple Mail Transfer Protocol: sintassi base |
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Arnaldo 'homer' Zitti - Ultimo Aggiornamento: 2004-06-04 11:50:33
Simple Mail Transfer Protocol (SMTP) è il protocollo utilizzato per trasmettere messaggi di posta elettronica tra due host.
SMTP utilizza il protocollo di trasporto TCP, ed in particolare un SMTP server rimane costantemente in ascolto sulla porta 25. Il server SMTP si occupa poi di trasferire i messaggi nelle caselle di posta (mailbox) dei destinatari, oppure qualora non fosse il diretto responsabile di queste, inoltrarli (operazione di relay) al server che provvederà a farlo. La sintassi dei comandi è case-insensitive, ed è composta da istruzioni seguite da uno o più parametri terminate da un CRLF (Invio).
Il protocollo è descritto nella RFC 821, ma lavora in stretta collaborazione con altri standard come la RFC 822 che descrive la sintassi degli headers della mail, la RFC 1049 che definisce le strutture dati per interpretare correttamente il contenuto delle mail e la RFC 974 che si occupa del routing delle mail tramite DNS.
Lo standard definito dalla RFC 821, aveva diversi limiti riguardanti per esempio la dimensioni dei messaggi oppure la trasmissione di mail non in inglese o diverse dal semplice plain text. Per ovviare a questa restrizione è stato necessario estendere il protocollo tramite la RFC 1425 riguardante le SMTP Service Extensions.
I principali comandi SMTP:
HELO
: Identifica il client SMTP al server SMTP;
EHLO
: E' possibile usare anche questo comando per identificarsi, se il server supporta le SMTP Service Extensions riponderà in modo positivo altrimenti con un errore di tipo 500 (Syntax Error);
MAIL FROM:
<indirizzo mittente>: Indicata la mailbox del mittente del messaggio;
RCPT TO:
<indirizzo destinatario> : Indica la mailbox del desinatario (Recipient). E' possibile specificare attraverso molteplici RCPT TO diversi destinatari;
DATA
: Indica al server che quanto digitato successivamente saranno i dati del messaggio di posta;
RSET
: Annulla i comandi (Reset) precedentemente inviati nella sessione SMTP corrente;
VRFY
<stringa>: Chiede al server se la stringa di testo immessa rappresenta un
nome utente presente ed in tal caso visualizza l'intero indirizzo;
HELP
: Visualizza i comandi disponibili sul server;
NOOP
: Non esegue nessuna operazione restituisce solo un messaggio 250 (Ok) se il server risponde;
QUIT
: Termina la sessione SMTP corrente;
Una sessione SMTP attraversa almeno sei fasi:
1. Il client SMTP contatta il server sulla porta TCP 25. Se questo è in ascolto e la connessione è accettata risponde con un messaggio 220 (Ready);
2. Il client chiede di stabilire la sessione SMTP inviando il comando HELO
seguito dal FQDN (Fully Qualified Domani Name). Se il server accetta rispondo con un messaggio 250 (Ok);
3. Il client indica il proprio indirizzo tramite il comando MAIL FROM:
<indirizzo mittente>. Il server risponde con 250 (Ok) per ogni destinatario accettato;
4. Successivamente il client indica al server i destinatari del messaggio tramite RCPT TO:
<indirizzo destinatario> ed il server risponde per ogni destinatario accettato un codice 250 (Ok);
5. Il client comunica al server l'intenzione di scrivere il corpo del messaggio con DATA.
Il server risponde con un codice 354 e indica come marcare il termine del messaggio. I campi come Date, Subject, To, Cc, From vanno inseriti tra i dati della mail;
6. Completato il messaggio da scrivere tramite .
il server memorizza la mail. A questo punto è possibile, scrivere un nuovo messaggio oppure inviare il comando QUIT
, dopo il quale il server invia i messaggi e risponde con un codice 221 (Closing) e la connessione TCP viene terminata;
Esempio di una sessione SMTP da linea di comando:
homer@Joker:~$ telnet smtp.springmail.it 25
Trying 195.130.225.171...
Connected to smtp.springmail.it.
Escape character is '^]'.
220 mail.springmail.it ESMTP Service (6.5.032) ready
Tramite il programma telnet viene contattato il server SMTP sulla pora TCP 25
E' possibile notare dal messaggio ESMTP Service che il server supporta le SMTP Service Extensions
HELO
250 mail.springmail.it Missing required domain name in HELO, defaulted to your IP address [62.10.125.229]
Il client si identifica tramite il comando helo (non iniviando un nome di dominio, viene utilizzato l'indirizzo IP)
L'autenticazione avviene con HELO anziché EHLO e quindi il client non usufruisce delle SMTP Service Extensions qui supportate
HELP
214-Valid SMTP commands:
214- HELO, EHLO, NOOP, RSET, QUIT, STARTTLS
214- MAIL, RCPT, DATA, VRFY, EXPN, HELP, ETRN
214-For more info, use HELP <valid SMTP command>
214 end of help
HELP QUIT
214-Syntax: QUIT
214-Purpose: request closing of the connection
214 end of help
Il client richiede una lista dei comandi disponibili tramite help e successivamente un aiuto per il comando QUIT
MAIL FROM:<[email protected]>
250 MAIL FROM:<[email protected]> OK
RCPT TO:<[email protected]>
250 RCPT TO:<[email protected]> OK
DATA
Inizia l'inserimento del corpo della mail
354 Start mail input; end with <CRLF>.<CRLF>
From:Homer
To:Arnaldo
Subject:Il protocollo SMTP
Ciao,
questa mail serve per illustrare
il protocollo SMTP
---
Arnaldo aka [Homer]
.
250 Mail accepted
Il comando "." punto termina l'inserimento del messaggio; Il server SMTP lo accetta
QUIT
221 mail.springmail.it QUIT
Connection closed by foreign host.
La connessione TCP termina e si ritorna al prompt
homer@Joker:~$
Il client di posta elettronica (Kmail, Outlook o Eudora) si occupa solitamente di comunicare con il server al posto nostro in base alla propria configurazione.
Installazione e gestione di Sendmail |
Installazione di Sendmail tramite RPM e sorgenti, file installati e posizioni. Gestione del servizio |
Tipo Infobox: DESCRIPTION - Skill Level: 3- INTERMEDIATE - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2004-06-02 12:03:57
Sendmail può essere lanciato in diversi modi per eseguire operazioni diverse.
Alcune opzioni possibili corrispondono a comandi con nomi diversi, che di fatto eseguono Sendmail con modalità specifiche.
A titolo di reference vengono elencate le principali opzioni con cui Sendmail può essere lanciato.
hoststat (sendmail -bh)
Stampa statistiche sullo stato persistente dell'host, con informazioni sulle mail che ha gestito. Questo è possibile solo se è attivata l'opzione HostStatusDirectory:
sendmail.cf: O HostStatusDirectory=/path/to/dir
sendmail.mc: define(`confHOST_STATUS_DIRECTORY',`/path/to/dir')
Con hoststat -v
vengono visuliazzate le righe di info per esteso.
purgestat (sendmail -bH)
Ripulisce (rimuove) tutte le statistiche sullo stato persistente dell'host, presenti nella directory definita con l'opzione HostStatusDirectory.
Questo secondo il manuale, di fatto, almeno sul Sendmail di RedHat 9, con attivata la suddetta opzione, questo comando non sembra avere alcun effetto.
mailq (sendmail -bp)
Visualizza l'elenco delle mail in coda. La directory in cui sono salvate è definita con l'opzione QueueDirectory:
sendmail.cf: O QueueDirectory=/path/to/dir
sendmail.mc: define(`confQUEUE_DIR',`/path/to/dir')
Di default è /var/spool/mqueue
newaliases (sendmail -bi)
Ricostruisce il database degli alias generando il file /etc/aliases.db
(di solito, se si usa il database db di default) rendnedo attive le modifiche fatte su /etc/aliases
.
Considerare che gli script di startup (/etc/init.d/sendmail start
) previsti in molte distribuzioni automaticamente prima di lanciare il demone Sendmail eseguono un newaliases.
smtpd (sendmail -bd)
Lancia Sendmail in daemon mode, lasciando il processo in ascoltro sulla porta 25 (di default) e restituendo la shell. E' la modalità tipicamente utilizzata su un server SMTP che riceve posta.
sendmail -bm (default)
Invocato con questa opzione di default Sendmail invia il messaggio che gli arriva in standard input ai destinatari specificati come argomento della command line.
sendmail -bs
Questa è la modalità con cui lanciare Sendmail tramite (X)inetd: viene invocato in foreground, accetta i messaggi in stdin, consegna il messaggio e si chiude. In server di posta che lo utilizzano in questo modo (e non come demone sempre attivo) è opportuno processare periodicamente la coda dei messaggi in uscita (crontabbando un sendmail -q
)
sendmail -bt
Entra in modalità di test, con cui è possibile verificare come funzionano le regole di instradamento della posta. Si presenta una shell in cui è possibile premere ? per visualizzare un elenco dei comandi possibili.
Utile per troubleshooting e debugging avanzati.
sendmail -C /path/to/sendmail.cf
Utilizza un file di configurazione alternativo rispetto al solito /etc/sendmail.cf o /etc/mail/sendmail.cf. Utile per test sulle configurazioni.
sendmail -q
Processa la coda di mail in uscita. Comodo se si non si vogliono aspettare i tempi preimpostati e si vuole immediatamente processare la posta in coda. Può essere lanciato anche mentre un'altra istanza di Sendmail è in esecuzione in daemon mode.
sendmail -q30m
Esegue Sendmail in background e processa la coda di posta ogni 30 minuti. Può essere utile su sistemi che si colelgano in dialup ad Internet per evitare di alzare una connessione ogni volta che c'è un messaggio in uscita.
sendmail [email protected]
Processa tutta la posta in coda che ha come destinatari degli indirizzi che terminano con @dominio.com
sendmail -d (sendmail -d0-99.1)
Esegue Sendmail in debugging mode, utile per ottenere una grande quantità di informazioni su come è stato compilato e come gestisce e processa le sue macro. Esistono numerose modalità di debugging, definibili con una coppia di numeri separati da un punto che definisce la categoria di debugging e il livello di verbosità.
Se non si specifica nulla Sendmail di default visualizza il debugging per tutte le categorie (0-99) con livello 1.
Notare che in modalità di debug Sendmail funziona normalmente, per cui è possibile scrivere l'indirizzo del destinatario e il corpo del testo (da concludere con un punto "." e un INVIO) e vedere come Sendmail processa il messaggio
Alcune interessanti parametri (il secondo valore, che indica il livello di debug, può arrivare a 127, ma si consiglia di non superare il valore 99, anche se spesso gli output sono uguali anche a differenza di livello):
sendmail -d0.20
- Visualizza informazioni sulla versione, le opzioni compilate, il nome locale e le regole di delivery
sendmail -d8.20
- Visualizza informazioni sulle procedure di DNS lookup per il record MX del dominio destinatario.
sendmail -d10.20
- Visualizza informazioni sul destinatario del messaggio
sendmail -d11.20
- Traccia informazioni sulla consegna del messaggio
sendmail -d21.2
- Traccia le macro per il rewriting degli indirizzi
sendmail -d27.9
- Traccia le operazioni di aliasing
sendmail -d31.2
- Traccia il processing degli header della mail
sendmail -d41.50
- Informazioni sulla coda dei messaggi
sendmail -d48.2
- Traccia le chiamate ai rule sets check_
sendmail -d0-99.3
- Visualizza informazioni di debug su ogni categoria, con livello di verbosità 3
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2004-06-02 12:43:02
Generalmente su gran parte delle distribuzioni Linux, Sendmail viene installato di default e in molti casi viene eseguito all'avvio per restare in ascolto sulla porta 25 del localhost.
In questo modo viene usato per inviare la posta locale, ma non rimande in ascolto su un indirizzo pubblico.
Il pacchetto con cui viene fornito è sendmail ma in molti casi, se si vuole usare Sendmail su un server di posta SMTP che deve ricevere posta via rete, è necessario installare anche il pacchetto sendmail-cf che contiene le macro M4 necessarie per processare il file /etc/mail/sendmail.mc
(avente un formato semplice e comodo da modificare) e generare il file di configurazione /etc/mail/sendmail.cf
(con una sintassi piuttosto complessa ed intricata.
Installazione da RPM
La procedura è la solita. Ecco un esempio su Fedora 2:
rpm -i sendmail-8.12.11-4.6.i386.rpm
Fra i file installati si segnalano:
/etc/mail/ La directory dove sono inseriti tutti i file di configurazione
/etc/mail/access Il file che definiscea chi Sendmail permette il relay e a quali host vengono rifiutati
/etc/mail/local-host-names L'elenco dei domini per cui Sendmail riceve posta
/etc/mail/sendmail.cf Il file di configurazione
/etc/mail/sendmail.mc Il file M4 "human readable" con cui viene generato sendmail.cf
/etc/rc.d/init.d/sendmail Lo script di avvio e gestione del servizio Sendmail
/etc/sysconfig/sendmail Parametri e impostazioni che definiscono con quali argomenti viene lanciato Sendmail
/usr/sbin/sendmail.sendmail Il programma sendmail vero e proprio, per permettere la coesistenza con altri MTA (Postfix) il comando /usr/sbin/sendmail è un link che punta al file /etc/alternatives/mta che a sua volta è un link al programma vero e proprio
/var/log/mail/statistics File di statistiche sui movimenti di posta
/var/spool/mqueue La directory che contiene i messaggi di posta in coda
Installazione da sorgenti
Compilare Sendmail dai sorgenti è particolarmente semplice. Basta scaricare dal sito ufficiale i sorgenti:
[al@localhost al]$ wget ftp://ftp.sendmail.org/pub/sendmail/sendmail.8.12.11.tar.gz
Scompattarli:
[al@localhost al]$ tar -zxvf sendmail.8.12.11.tar.gz
Lanciare lo script Build che provvede a compilare i sorgenti (di fatto è un make):
[al@localhost al]$ cd sendmail-8.12.11 ; ./Build
Copiare i file nelle directory di installazione (bisogna avere i privilegi di root):
[al@localhost sendmail-8.12.11]$ su ; ./Build install
Configurazione di Sendmail |
File di configurazione e settaggio dei parametri di Sendmail |
Tipo Infobox: DESCRIPTION - Skill Level: 3- INTERMEDIATE - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2003-10-03 08:58:23
La configurazione di Sendmail tramite il file sendmail.mc risulta particolarmente comoda e semplice anche se bisogna sempre ricordarsi di processare questo file con il preprocessore di macro m4 per ottenere il file sendmail.cf effettivamente usato dal programma.
Per farlo basta una riga tipo:
m4 sendmail.mc > sendmail.cf
Le macro che permettono di convertire un file sendmail.mc nel file sendmail.cf sono generalmente distribuite indipendentemente dal pacchetto di Sendmail per permettere una gestione più agevole degli aggiornamenti.
Su Linux tipicamente sono presenti nel pacchetto sendmail-cf.*.rpm
Le caratteristiche sintattiche di base di un file .mc:
- Le macro sono definite con una riga tipo: define(macro,valore)
- Si possono utilizzare degli apici (il primo è inverso, il secondo dritto) per impedire che il preprocessori interpreti i contenuti di un argomento: define(`macro',`valore')
- Il preprocessore m4 analizza il testo in input come un flusso di caratteri, per evitare che venga interpretata una riga si usano i caratteri dnl (Delete through New Line) che possono essere usati sia come i # per commentare una riga:
dnl define(`macro',`valore')
(la riga di configurazione non viene considerata)
sia a termine riga per evitare che venga generato uno spazio vuoto nel file di configurazione:
define(`macro',`valore')dnl
(la riga di configurazione viene considerata e viene ignorato tutto quello che è scritto dopo dnl fino a fine riga).
Ricordarsi che gli argomenti delle macro sono generalmente messi fra apici (prima inverso: ` e poi dritto: ').
Per costruire un file di configurazione m4 minimo sono necessarie le seguenti direttive:
OSTYPE()
- OBBLIGATORIO. Esempio: OSTYPE(`linux')
Definisce il sistema operativo su cui gira Sendmail. Un elenco dei SO supportati può essere visibile in /usr/share/sendmail-cf/ostype
o nella analoga directory in cui sono contenuti le macro di configurazione di sendmail.
MAILER()
- OBBLIGATORIO. Esempio: MAILER(`smtp')
Definisce l'egente di consegna di posta utilizzato. Sendmail supporta non solo il protocolli SMTP, ma anche metodi più antichi (tipo UUCP) o diversi. In genere su un server di posta normale è definito MAILER(`smtp')
per la gestione della posta in rete, e MAILER(`procmail')
o MAILER(`local')
per il delivery della posta locale.
DOMAIN()
- RACCOMANDATO. Esempio: DOMAIN(`generic')
Imposta una macro specifica per il dominio indicato. Il generic si riferisce ad una configurazione standard, buona per molti usi.
FEATURE()
- RACCOMANDATO. Esempio: FEATURE(`use_cw_file')
Molte funzionalità utili di Sendmail sono configurabili con specifiche features, che vanno dichiarate nel file .mc.
Fra queste segnaliamo:
FEATURE(`always_add_domain')
- Aggiunge sempre il nome di dominio agli indirizzi presenti negli header dei messaggi, anche se si riferiscono ad utenti locali, per cui non si è esplicitato un dominio.
FEATURE(`domaintable')
- Attiva il supporto di un file domaintable
in cui sono indicati (a sinistra in ogni riga) nomi di dominio la cui posta la si vuole far convergere nel proprio dominio locale (a destra in ogni riga). Questa feature può avere come ulteriore argomento un path alternativo e un alternativo tipo di DB di gestione del file (di default si utilizza un hash db standard): FEATURE(`domaintable',`hash -o /etc/mail/domaintable.db')
.
Una simile riga su sendmail.mc produrrà su sendmail.cf la seguente configurazione:
Kdomaintable hash -o /etc/mail/domaintable.db
R$* < @ $+ > $* $: $1 < @ $(domaintable $2 $) > $3
FEATURE(`genericstable')
- Attiva il supporto del file genericstable
in cui è possibile specificare come cambiare l'indirizzo del mittente (a sinistra) con un indirizzo alternativo (a destra).
Ha una logica simile a domaintable: il file di configurazione è un normale testo ASCII che viene convertito in un .db che di fatto è quello utilizzato da Sendmail. Anche in questo caso è possibile indicare path del file e database utilizzato: FEATURE(`genericstable',`hash -o /etc/mail/genericstable.db')
FEATURE(`local_procmail')
- Utilizza procmail per il delivery della mail locale.
FEATURE(`mailertable')
- Permette di utilizzare un file mailertable
per gestire metodi e rotte di delivery della posta custom. In /etc/mail/mailertable
(default sui Sendmail recenti), che funziona come gli altri file da convertire in .db, va scritto, in ogni riga: dominio a cui è destinata la posta (es: dominio.com) - metodo di delivery e dominio o indirizzo email di destinazione (es: smtp:[email protected]).
SOURCE: Manuale in linea. Documentazione pacchetto BIND -
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2004-06-03 20:37:03
Sendmail nel mondo Unix è noto per avere il file di configurazione più complesso che sia mai stato concepito da uno sviluppatore umano.
Geek humour in rete si spreca sulle caratteristiche di questo file e in genere su Sendmail stesso, un mostro sacro della posta elettronica che non nasconde le sue antichità, nel bene e soprattutto nel male.
Il file di configurazione è /etc/sendmail.cf
, a volte si trova in /etc/mail/sendmail.cf
o in altre posizioni.
Questo file ha una struttura che appare estremamente complessa perchè ha una sintassi molto ridotta ai minimi termini: i comandi sono tutti di una singola lettera e si aspettano argomenti che spesso sono di 2 sole lettere.
A vederlo sembra uno scherzo di natura informatica, un insieme di caratteri senza senso, ma una volta conosciuta la sua logica, in parte le nebbie si dipanano.
Dalla versione 8 in poi, Sendmail può essere configurato anche tramite un file chiamato sendmail.mc
che contiene comandi molto più semplici da intuire ma che va di fatto convertito, tramite un preprocessore di macro m4, nel file sendmail.cf vero e proprio.
Questa distinzione va ben compresa: il file di configurazione di Sendmail rimane sempre sendmail.cf, ma invece che editarlo direttamente, è possibile generarlo da un file sendmail.mc che ha una sintassi e una logica più semplice e che richiede di essere "precompilato" sulla base di regole e macro che generalmente vengono fornite su un pacchetto a parte nelle varie distribuzioni Linux (sendmail-cf.*.rpm).
Ogni volta che si modifica sendmail.mc va quindi rigenerato il relativo sendmail.cf:
m4 /etc/mail/sendmail.mc > /etc/mail/sendmail.cf
. Nel corso della sua storia e nelle sue incarnazioni su diversi Unix flavour, Sendmail ha disseminato file di configurazione in posti diversi, con le ultime versioni si è cercato di fare pulizia e uniformare la situazione. Segue un elenco, tratto dalla documentazione ufficiale dove si vede come sono cambiate le posizioni e i nomi di alcuni file comunemente usati in Sendmail:
Vecchia posizione Nuova posizione
/etc/bitdomain /etc/mail/bitdomain
/etc/domaintable /etc/mail/domaintable
/etc/genericstable /etc/mail/genericstable
/etc/uudomain /etc/mail/uudomain
/etc/virtusertable /etc/mail/virtusertable
/etc/userdb /etc/mail/userdb
/etc/aliases (oppure: /etc/sendmail/aliases ; /etc/ucbmail/aliases ; /usr/adm/sendmail/aliases ; /usr/lib/aliases ; /usr/lib/mail/aliases ; /usr/ucblib/aliases)
/etc/mail/aliases
/etc/sendmail.cw (oppure: /etc/mail/sendmail.cw ; /etc/sendmail/sendmail.cw)
/etc/mail/local-host-names
/etc/sendmail.ct /etc/mail/trusted-users
/etc/sendmail.oE /etc/mail/error-header
/etc/sendmail.hf (oppure: /etc/mail/sendmail.hf ; /usr/ucblib/sendmail.hf ; /etc/ucbmail/sendmail.hf ; /usr/lib/sendmail.hf ; /usr/share/lib/sendmail.hf ; /usr/share/misc/sendmail.hf ; /share/misc/sendmail.hf)
/etc/mail/helpfile
/etc/service.switch /etc/mail/service.switch
/etc/sendmail.st (oppure /etc/mail/sendmail.st ; /etc/mailer/sendmail.st ; /etc/sendmail/sendmail.st ; /usr/lib/sendmail.st ; /usr/ucblib/sendmail.st)
/etc/mail/statistics
HOWTO: Sendmail + UUCP HOWTO - http://ldp.openskills.info/HOWTO/Sendmail+UUCP.html
HOWTO: sendmail address rewriting mini-HOWTO - http://ldp.openskills.info/HOWTO/Sendmail-Address-Rewrite.html
Tipo Infobox: DESCRIPTION - Skill Level: 3- INTERMEDIATE - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2003-09-03 12:55:09
Esistono diversi modi per supportare la tecnica POP-before-SMTP su Sendmail, che permette di usare un server SMTP remoto, che normalmente non permette il relay, dopo che ci si è autenticati via pop3 o imap sul server stesso.
Fra i vari approcci al problema tipicamente il più utilizzato è quello di usare un programma, generalmente eseguito come demone, che controlla i log di posta, identifica i tentitivi di login pop3 o Imap eseguiti con successo e scrive in un database gli indirizzi IP dei client remoti, questo database viene poi controllato da Sendmail (opportunamente configurato) per aprire il relay agli indirizzi ivi contenuti.
Abbiamo trovato particolarmente rapido ed efficace il tool log2db per convertire in un db Berkeley (db 1, 2, 3, 4) le entry di un file di log e la macro popauth fornita direttamente dal sito di Sendmail.
Ecco la procedura utilizzata:
Installare e configurare log2db
Normale procedura, verificare su http://www.bestbits.at/log2db/ se esistono versioni più recenti:
[al@giraffa al]$ wget http://www.bestbits.at/log2db/log2db-0.5.7.tar.gz
[...]
[al@giraffa al]$ tar -zxvf log2db-0.5.7.tar.gz
[...]
[al@giraffa al]$ cd log2db-0.5.7
[al@giraffa log2db-0.5.7]$ ./configure
[...]
[al@giraffa log2db-0.5.7]$ make
gcc -o log2db.o -g -O2 -Wall -DVERSION=\"0.5.7\" -Iinclude -c log2db.c
gcc -o regsubst.o -g -O2 -Wall -DVERSION=\"0.5.7\" -Iinclude -c regsubst.c
gcc -o log2db log2db.o regsubst.o -ldb
[al@giraffa log2db-0.5.7]$ su
Password:
[root@giraffa log2db-0.5.7]# make install
/usr/bin/install -c -m 755 --strip log2db /usr/local/sbin
/usr/bin/install -c -m 755 log2db-wrapper /usr/local/sbin
A questo punto editare /usr/local/sbin/log2db-wrapper
(uno script shell che invoca il comando log2db
e gli passa gli argomenti corretti) per adattarlo al proprio sistema, in particolare verificare la posizione del log del server pop3/imap (su Linux di solito /var/log/maillog
e commentare/scommentare le regole di pattern matching relative al proprio server di posta (di default si adatta a Qpopper). Correggere eventualmente il path del file log2db: nella versione utilizzata (0.5.7) è /usr/sbin/log2db ma il comando viene installato in /usr/loacl/sbin/log2db.
Dopo le configurazioni del caso si può lanciare il wrapper in background e aggiungerlo ad uno script di startup: /usr/local/sbin/log2db-wrapper &
Configurare Sendmail
Seconda parte del lavoro è la configurazione di Sendmail. Anche in questo caso le vie possono essere varie, ma la migliore e la più semplice è quella che passa per sendmail.mc. Aggiungere a questo file le righe:
define(`POP_B4_SMTP_TAG', `')
HACK(`popauth')
e scaricare la macro m4 popauth da http://www.sendmail.org/~ca/email/rules/popauth.m4 (evitare copia e incolla, per non rischiare di avere problemi con tab e spazi vari). Questa macro va copiata nella sottodirectory hack
all'interno dei file necessari per la configurazione di Sendmail. Su RedHat questi stanno in /usr/share/sendmail-cf/
e sono forniti dal pacchetto sendmail-cf, su altri *nix possono stare altrove, ma in ogni caso se m4 non trova il file lo comunica in stderr:
[root@giraffa log2db-0.5.7]# m4 /etc/mail/sendmail.mc > /dev/null
/etc/mail/sendmail.mc:145: m4: Cannot open /usr/share/sendmail-cf/hack/popauth.m4: No such file or directory
Ecco quindi la procedura usata su una RedHat9 (dopo aver modificato /etc/mail/sendmail.mc), ovviamente sarebbe sempre opportuno eseguire una copia dei file modificati:
[root@giraffa log2db-0.5.7]# wget http://www.sendmail.org/~ca/email/rules/popauth.m4
[...]
[root@giraffa log2db-0.5.7]# mv popauth.m4 /usr/share/sendmail-cf/hack/
[root@giraffa log2db-0.5.7]# m4 /etc/mail/sendmail.mc > /etc/mail/sendmail.cf
[root@giraffa log2db-0.5.7]# /etc/init.d/sendmail stop
[root@giraffa log2db-0.5.7]# /etc/init.d/sendmail stop
[root@giraffa log2db-0.5.7]# /etc/init.d/sendmail start
A questo punto Sendmail è pronto per appoggiarsi ad db /etc/mail/popauth.db
per aprire il relay agli indirizzi li presenti. Questo database viene costantemente aggiornato da log2db (eseguito tramite il wrapper e lasciato in background) e può essere monitorato con il comando log2db --db=/etc/mail/popauth.db --dump
.
Esiste la possibilità di aggiungere a mano dei indirizzi IP: (es: log2db --db=/etc/mail/popauth.db --add 192.168.0.1
), di rimuoverli ecc.
Per verificare se tutto funziona, tenere sotto controllo il log di posta e provare ad inviare posta da un IP remoto, che normalmente non viene relayato dopo aver eseguito un login pop3 sullo stesso server.
SOURCE: Relay control in sendmail for roaming users - http://www.sendmail.org/~ca/email/roaming.html
Postfix |
Installazione, configurazione, gestione |
Tipo Infobox: DESCRIPTION - Skill Level: 3- INTERMEDIATE - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2005-04-28 15:09:13
In questa breve guida si affronta l'installazione di Mailscanner integrato con Postfix su Fedora/RedHat. Quanto qui indicato si può applicare senza sostanziali differenze anche su altre distribuzioni.
Rimozione di Sendmail e installazione Postfix :
yum install postfix
rpm -e sendmail
La configurazione di Postfix va fatta secondo le proprie necessità. Semplificando al massimo, verificare e modificare i seguenti parametri in /etc/postfix/main.cf
:
myhostname, mydomain, inet_interface, mydestination, mynetworks.
Installazione di Mailscanner. Rigorosamente consigliato è l'uso dell'ottimo installer per sistemi basati su RPM dal sito ufficiale (prendere l'ultima versione stable):
wget
http://www.sng.ecs.soton.ac.uk/mailscanner/files/4/rpm/MailScanner-4.39.6-1.rpm.tar.gz
L'installazione richiede compilatore e strumenti per creare rpm, se non sono già installati procedere con yum:
yum install rpm-build
yum install gcc
Procedere con l'installazione. La fase di compilazione può durare qualche minuti, in quando l'installer ricrea ed installa i pacchetti RPM per il propri sistema dai rispettivi sorgenti:
tar -zxvf MailScanner-4.39.6-1.rpm.tar.gz
cd MailScanner-4.39.6-1
./install.sh
L'integrazione con Postfix è semplice, aggiungere alla fine di /etc/postfix/main.cf
la riga:
header_checks = regexp:/etc/postfix/header_checks
e creare il file /etc/postfix/header_checks
con questo contenuto:
/^Received:/ HOLD
La configurazione di MailScanner prevede numerose opzioni che possono essere adattate alle proprie esigenze. Le modifiche fondamentali su /etc/MailScanner/Mailscanner.conf
sono:
Run As User = postfix
Run As Group = postfix
Incoming Queue Dir = /var/spool/postfix/hold
Outgoing Queue Dir = /var/spool/postfix/incoming
MTA = postfix
Assicurarsi che l'utente postfix con cui gira Postfix e lo steso Mailscanner abbia permesso di lettura e scrittura sulle directory usate per le code di Mailscanner:
chown -R postfix /var/spool/MailScanner
A questo punto si può provare a riavviare i servizi Mailscanner e Postfix e guardare gli header delle mail in entrata e in uscita: se esistono header aggiunti da Mailscanner, facilmente riconoscibili, il filtro e attivo e la sua configurazione dipende da come si vuole integrare con sistemi antivirus e antispam. Considerare che porvvede lo script di avvio di MailScanner ad avviare Posftix:
/etc/init.d/postfix stop
/etc/init.d/MailScanner restart
Quando tutto funziona secondo le ns esigenze possiamo configurare l'avvio dei servizi al boot:
chkconfig --level 345 postfix off
chkconfig --level 345 MailScanner on
Per integrare Mailscanner con l'antispam Spamassassin aggiungere/modificare le seguenti righe in /etc/MailScanner/Mailscanner.conf
:
Use SpamAssassin = yes
SpamAssassin User State Dir = /var/spool/MailScanner/spamassassin
Ricordarsi di creare questa directory con i giusti permessi:
mkdir /var/spool/MailScanner/spamassassin
chown postfix.postfix /var/spool/MailScanner/spamassassin
Per integrarlo con l'antivirus ClamAV editare MailScanner.conf con:
Virus Scanners = clamav
Monitors for ClamAV Updates = /var/lib/clamav/*.cvd
LINK: Sito Ufficiale MailScanner - http://www.mailscanner.info
SOURCE: HowTo Mailscanner+Postfix su Debian - http://www.debianitalia.org/modules/wfsection/article.php?articleid=77
LINK: MailWatch for MailScanner - http://mailwatch.sourceforge.net/
Tipo Infobox: DESCRIPTION - Skill Level: 3- INTERMEDIATE - Autore: Massimo 'maxgrante' Caselli - Ultimo Aggiornamento: 2005-01-05 16:16:54
Una richiesta sempre più frequente quando si installa e configura un mail server linux è la possibilità che quest'ultimo processi le email in arrivo per filtrare i virus, e le email di spam.
Tutto ciò è facilmente applicabile utilizzando i seguenti applicativi:
- Postfix (MTA)
- ClamAV (Engine Antivirus)
- Clamsmtpd (per gestire il passaggio della posta da Postfix a ClamAV)
- Procmail (per gestire il delivery della posta e filtrarla con Spamassassin)
- Spamassassin
Supponiamo di avere già installato Postfix e Spamassassin (tipicamente presenti come pacchetti in molte distribuzioni).
Gli altri due programmi (ClamAV e Clamsmtpd) sono invece, generalmente, da scaricare e da compilare a mano.
La versione ultima di ClamAV al momento in cui si scrive questo infobox è la 0.80 che potete trovare qui:
Clamav
Per quando riguarda invece Clamsmtpd l'ultima è la 1.2 disponibile qui:
Clamsmtpd
Dopo aver scaricato i due pacchetti spostiamo in /usr/local/src e scompattiamoli.
Per l'installazione e compilazione vi rimando a questo infobox. La configurazione la vedremo invece insieme.
CONFIGURAZIONE CLAMD
Di seguito vediamo cosa cambiare in /etc/clamd.conf per quello che vogliamo andare a fare:
LocalSocket /tmp/clamd
Commentare la seguente linea perchè andremo a far ascoltare il demone clamd sulla socket TCP 3310, per farlo scommentare la seguente riga:
TCPSocket 3310
Il resto della configurazione di default va benissimo così com'è.
FRESHCLAM
Freshclam è il sistema utilizzato da ClamAV per aggiornare il proprio database. Il default di /etc/freshclam.conf va bene in quanto sarà in modalità demone che provvede ad aggiornare il sistema AV ogni 2 ore.
INSTALLAZIONE E CONFIGURAZIONE CLAMSMTPD
Questo fantastico software ci permette di impostare e gestire i vari passaggi che devono avvenire tra Postfix e ClamAV per i processi di filtering delle email che arrivano all'MTA.
Prima di tutto dobbiamo compilare il programma, per farlo spostiamoci in clamsmtpd-1.2 sotto /usr/local/src.
La compilazione avviene in modo standard ./configure; make; make install
;
Al termine del tutto bisogna però spostare in /etc il file di conf che è presente nei sorgenti: cp clamsmtpd-1.2/doc/clamsmtpd.conf /etc/
.
Fatto questo vediamo come configurarlo secondo le nostre esigenze:
Rispetto alla configurazione di default bisogna apportare i seguenti cambiamenti:
OutAddress: 127.0.0.1:10026
Output address
ClamAddress: 127.0.0.1:3310
Parametro che imposta dove ascolta Clamd
Avviare il demone clamsmtpd con il seguente comando:
/usr/local/sbin/clamsmtpd -f /etc/clamsmtpd.conf
IMPOSTARE POSTFIX PER UTILIZZARE I DUE SOFTWARE INSTALLATI
A questo punto basta dire a Postfix che le email che arrivano devono essere passate a clamsmtpd che provvederà a passarle a clamav e se CLEAN le rigirerà a Postfix per lo smistamento o, come nel nostro caso, per i controlli di antispam.
Per farlo basta aggiungere a /etc/postfix/main.cf
le seguenti righe:
content_filter = filter:127.0.0.1:10025
receive_override_options = no_address_mappings
Ed in fondo a /etc/postfix/master.cf
:
# SMTP filter (used by content_filter)
filter unix - - n - 16 smtp
-o smtp_send_xforward_command=yes
# For injecting mail back into postfix from the filter
127.0.0.1:10026 inet n - n - 16 smtpd
-o content_filter=
-o receive_override_options=no_unknown_recipient_checks,no_header_body_checks
-o smtpd_helo_restrictions=
-o smtpd_client_restrictions=
-o smtpd_sender_restrictions=
-o smtpd_recipient_restrictions=permit_mynetworks,reject
-o mynetworks_style=host
-o smtpd_authorized_xforward_hosts=127.0.0.0/8
UTILIZZO DI SPAMASSASSIN
Dato per scontato che spamassassin sia installato, il modo più semplice per utilizzarlo è di gestire il tutto tramite procmail, per quanto questa soluzione non sia l'ideale per grossi volumi di posta.
In pratica bisogna configurare Postfix per gestire il local delivery delle email tramite procmail. Per fare ciò basta scommentare la seguente linea di /etc/postfix/main.cf
:
mailbox_command = /usr/bin/procmail
IMPORTANTE: prima di riavviare il servizio di postfix bisogna configurare /etc/procmailrc con cui configuriamo a livello globale sulla configurazione di procmail.
Editare /etc/procmailrc
come segue:
DROPPRIVS=yes
LOGFILE=/var/log/procmail.log
VERBOSE=yes
:0fw
* < 256000
## | spamc -f
| /usr/bin/spamassassin
:0:/tmp/spam.lock
*^X-Spam-Flag: YES
/var/spool/mail/spam
Spieghiamo ora brevemente le parti importanti di procmailrc:
- LOGFILE specifichiamo il file dove procmail logga le attività che svolge.
- * < 256000 Specifichiamo a procmail di chiamare spamassassin SOLO per le email più piccole di 256K, in caso contrario si rischia di appesantire il processo di parsing delle email stesse
- | /usr/bin/spamassassin Specifica di usare il binario di spamassassin (non uso il spamd perchè ho avuto problemi di mailbox bloccate quando muore il demone)
- *^X-Spam-Flag: YES - /var/spool/mail/spam
Se trova il flag nell'header dell'email (inserito da spamassassin per le email ritenute spam) sposta la mail in una mailbox chiamata appunto "spam"
Per concludere tenete presente che in caso di traffico mail notevole è necessaria una macchina ben carrozzata.
Tipo Infobox: TIPS - Skill Level: 3- INTERMEDIATE - Autore: Alessandro 'ask' Nasuti - Ultimo Aggiornamento: 2004-11-12 17:44:53
Il protocollo SMTP offre una serie di comandi utili per visualizzare informazioni inerenti il server di posta. Questi comandi però possono esser sfruttati per scopi non del tutto etici.
Per evitare ciò è consigliabile disabilitare alcuni comandi tra cui il VRFY che permette la verifica di inidirizzi email sul server. Ad Esempio:
telnet pippo.com 25
220 pippo.com ESMTP Postfix
vrfy pippo
252 pippo
Nel file di configurazione di Postfix ( main.cf
) inserire la seguente dichiarazione:
# disabilita il comando VRFY
disable_vrfy_command = yes
Per attivare la modifica alla configurazione di postfix è necessario ricaricare il servizio ( /etc/init.d/postfix reload
)
telnet pippo.com 25
220 pippo.com ESMTP Postfix
vrfy pippo
502 VRFY command is disabled
Il comando VRFY sul server pippo.com è disabilitato.
LINK: SMTP COMMAND - http://www.networksorcery.com/enp/protocol/smtp.htm
Tipo Infobox: PATH - Skill Level: 2- JUNIOR - Autore: Arnaldo 'homer' Zitti - Ultimo Aggiornamento: 2008-02-18 23:49:39
E' il file di configurazione attraverso il quale specificare gli alias di posta del mailserver Postifx.
E' un file di testo, può contenere linee vuote e di commento (le quali iniziano con il carattere #). Può risiedere in /etc/posftix/
oppure in /etc/
. Ogni entry deve essere nel formato nome:valore
. Impostando webmaster:homer
sul sistema Joker.net, si indica a Postfix di reindirizzare le mail dirette all'utente [email protected] all'utente [email protected].
La parte nome
di ogni linea di configurazione è intesa come locale, di conseguenza non è neccessario aggiungere il nome di dominio.
Per quanto riguarda la parte valore
, essa può essere può contenere diversi tipi di destinazione:
- address: Un indirizzo email compatibile alla RFC 822;
- file/name: La mail viene accodata al file specificato. E' possibile utilizzare normali file, ma anche file speciali come /dev/null
;
- | comando: Le mail possono essere inviate tramite pipe ad un comando;
- :include:/file/name: La mail viene inviata agli indirizzi elencati nel file specificato;
Esempio di configurazione:
# Basic system aliases -- these MUST be present
#
MAILER-DAEMON: postmaster
postmaster: root
root: homer
# Alias generali
bin: root
daemon: root
named: root
nobody: root
uucp: root
www: root
ftp-bugs: root
postfix: root
# Alias locali
arnaldo: homer
webmaster: homer
Reindirizzamento di tipo address: le mail dirette ad hannibal vengono inviate ad alberto:
hannibal: alberto
Reindirizzamento file/name: Le mail inviate a bart verrano accodate nel file bartmail
bart: /home/bart/bartmail
La mail inviata a programmatori verrà inviata a tutti gli indirizzi presenti all'interno del file programmers-list.txt:
programmatori: :include:/list/programmers-list.txt
Una volta aggiunti i nuovi alias, al fine di rendere effettive le modifiche, è necessario lanciare il comando newaliases
, il quale si occuperà di aggiornare il database degli alias.
Tipo Infobox: TIPS - Skill Level: 4- ADVANCED - Autore: lorenzo 'lorenz' urbinati - Ultimo Aggiornamento: 2003-08-04 20:12:05
Amavisd è un demone scritto in Perl che permette di chiamare programmi esterni in grado di scomprimere, decodificare e classificare il contenuto dei messaggi e degli allegati di posta.
Accetta le mail dall'MTA usato, chiama moduli Perl esterni e programmi che controllano il messaggio di posta e infine li riinoltra all'MTA per la consegna, il rifiuto o la quarantena del messaggio.
Per usare amavisd-new bisogna assicurarsi che si stia utilizzando una versione di Postfix abbastanza recente e che supporti il parametro content_filter = valore
Innanzi tutto occorre creare un utente e un gruppo per usare questo demone.
Di norma si usa amavis come utente e sweep come gruppo. Per motivi di sicurezza non usare assolutamente utenti di sistema come nobody o altri relativi al sistema di posta come maildrop.
Il file una volta scompattato non occorre di compilazioni, all'interno del pacchetto si trovano l'eseguibile amavisd
e il suo file di configurazione amavis.conf
più uno script di init da inserire nella directory relativa ai file di init del sistema. Questi file vanno copiati nelle loro giuste directory prestando attenzione ai permessi e agli utenti che ne hanno la proprietà. Come home directory per l'utente si può definire /var/amavis/
o /var/lib/amavis/
#cp ./amavisd /usr/sbin/
#chown root /usr/sbin/amavisd
#chmod 755 /usr/sbin/amavisd
e di conseguenza il file di configurazione
#cp ./amavisd.conf /etc/
#chown root /etc/amavisd.conf
#chmod 644 /etc/amavisd.conf
Può essere utile creare una directory che serva da destinazione per i messaggi in quarantena.
#mkdir /var/quarantena
chown amavis.amavis /var/quarantena/
chmod 750 /var/quarantena/
A questo punto sarà necessario editare il file di configurazione amavisd.conf e di conseguenza anche i file di configurazione di Postfix.
Nel amavisd.conf
sarà importante fare attenzione ad alcuni parametri in particolare anche se è consigliabile leggerlo tutto perchè le opzioni possibili sono numerose.
Innanzi tutto si settano i parametri $daemon_user
e $daemon_group
specificando l'utente e il gruppo scelto per far girare il demone. In questo modo al momento del lancio, come root, di amavisd, automaticamente parte come se lanciato dall'utente specificato.
Le opzioni
$HOME
per definire la home directory dell'utente amavis.
$TEMPBASE
dove si definisce la directory in cui vengono temporaneamente posti i messaggi in elaborazione.
$QUARANTINEDIR
la directory di quarantena in cui i messaggi sospetti o certamente infetti vengono riposti per un eventuale controllo e pulizia.
E' possibile anche non creare nessuna directory di quarantena e fare in modo che tutta la mail destinata a questa "coda" sia inviata ad un account di posta preposto per questo.
Si crea una voce relativa nel file /etc/aliases
o a seconda dell'installazione /etc/postfix/aliases
infected = /var/spool/mail/infected
e a seconda che si desideri o meno un mailbox-style aggiungere uno slash finale. Lanciare il comando newaliases
o postalias /etc/postfix/aliases
per aggiornare il database.
Infine specificare nel file amavisd.conf la direttiva
$virus_quarantine_to = 'infected@';
in modo da inviare tutta la posta in quarantena all'indirizzo infected.
Sarà necessario poi prestare attenzione agli altri parametri presenti nella 'Section I', $mydomain
e @local_domains_acl = valore
, e per finire agire sui valori di specifica del software antivirus usato nella 'Section VII'. A questo punto amavisd può essere lanciato e se dovessero mancare alcuni prerequisiti, come qualche modulo Perl, uscirà con un errore mostrando una lista di cosa è venuto a mancare.
Configurato amavisd sarà necessario lavorare sui file di configurazione di Postfix main.cf e master.cf.
Nel master.cf dovranno essere aggiunte le seguenti voci
smtp-amavis unix - - y/n - 2 smtp
-o smtp_data_done_timeout=1200
-o disable_dns_lookups=yes
127.0.0.1:10025 inet n - y/n - - smtpd
-o content_filter=
Dove y/n corrispondono al campo "chroot" e serve ad indicare se si è o meno in un ambiente di lavoro chroot.
Infine con il comando
#postconf -e 'content_filter = smtp-amavis:[127.0.0.1]:10024'
si modifica il main.cf e si fa in modo che Postfix inizi a inviare tutta la posta che riceve ad amavisd.
Effettuare un relaod della configurazione con il comando
#postfix reload
Controllare i file di log di Postfix e di amavisd per verificare che tutto funzioni. Volendo all'interno della directory del pacchetto Amavis è presente una sotto-directory test-messages
contenente alcuni file utili per testare il funzionamento del nuovo sistema di filtraggio della posta.
Tipo Infobox: TIPS - Skill Level: 3- INTERMEDIATE - Autore: Fabrizio 'bluviolin' Tarizzo - Ultimo Aggiornamento: 2003-07-16 14:54:07
Come ottimizzare Postfix su workstation con connessione ad Internet non permanente.
La configurazione di Postfix generalmente utilizzata su macchine con una connessione non permanente ad Internet (ad esempio una workstation casalinga) prevede l'uso della direttiva defer_transports=smtp
, che consente di mantenere in coda la posta inviata evitando l'avvio automatico di connessioni PPP indesiderate.
La posta in giacenza verrà effettivamente inviata alla successiva connessione, tramite un postfix flush
nello script /etc/ppp/ip-up
.
Ciò è scomodo, in quanto costringe l'utente ad eseguire manualmente il flush
se desidera inviare un messaggio mentre la connessione è già attiva.
Una configurazione più funzionale istruisce Postfix a mantenere la posta in coda mentre la workstation non è connessa ad Internet e a spedirla immediatamente quando la connessione è attiva.
Ciò è possibile grazie al comando postconf
, aggiungendo le seguenti istruzioni in /etc/ppp/ip-up
o, meglio, in /etc/ppp/ip-up.local
(ricordo che per ragioni di sicurezza questi script vengono eseguiti in un environment protetto, le variabili di ambiente non sono disponibili ed è pertanto obbligatorio specificare il path per esteso di ciascun comando):
# Istruisce Postfix per inviare subito la posta
/usr/sbin/postconf -e "defer_transports="
/usr/sbin/postfix reload
# Invia la posta in coda
/usr/sbin/sendmail -q >dev/null 2>/dev/null &
In /etc/ppp/ip-down.local
rimettiamo le cose a posto:
/usr/sbin/postconf -e "defer_transports=smtp"
/usr/sbin/postfix reload
Tipo Infobox: TIPS - Skill Level: 3- INTERMEDIATE - Autore: lorenzo 'lorenz' urbinati - Ultimo Aggiornamento: 2004-06-04 11:53:19
Postfix è integrabile con diversi sistemi di autenticazione, di controllo dei virus, di applicativi webmail e può raggiungere livelli molto elevati di complessità strutturale. Molti strumenti e metodi utilizzati con Sendmail sono disponibili anche con Postfix.
Sul sito ufficiale del pacchetto alla pagina http://www.postfix.org/addon.html sono disponibili diversi riferimenti a utility, patch e documentazione per implementare diverse funzioni.
Attualmente Postfix è integrabile con molti dei principali sistemi di posta pop3/imap come Cyrus IMAP, Qpopper, Courier-imap, con vari software antivirus, con sistemi di controllo delle autenticazioni before-smtp come DRAC, whoson o pop-before-smtp o con sistemi anti-UCE come SpamAssassin. Alcune di queste funzioni implicano la ricompilazione del pacchetto, altre necessitano di particolari accorgimenti, come spesso succede nel mondo Linux ci sono molti modi di ottenere lo stesso effetto ed è difficile stabilire quale sia il migliore.
Un metodo di autenticazione molto usato è pop-before-smtp.
Per far questo si può utilizzare DRAC Dinamic Relay Authorization Control, un demone che si occupa di scrivere un database di indirizzi autenticati attraverso pop3/imap ma implica alcuni fattori poco favorevoli quali l'uso di Remote Procedure Call e quindi la necessità di avere portmap attivo e il fatto di dover ricompilare i demoni usati per pop3/imap, si può usare whoson una patch per Postfix che quindi implica la sua ricompilazione oppure usare pop-before-smtp un demone scritto in Perl.
L'ultima è probabilmente la soluzione più funzionale e pratica, non implica ricompilazioni particolari ed è portabile su molte piattaforme differenti, unico neo che potrebbe far preferire DRAC a questo metodo è che non opera da remoto implica per ciò che i file necessari siano presenti sulla macchina del server di posta.
Il pacchetto, disponibile su sourceforge si può trovare in formato rpm o in formato tar.gz, una volta appurato che siano presenti i modili Perl necessari per far funzionare pop-before-smtp installabili attraverso un Bash script all'interno della directory contrib dei sorgenti scaricati, chiamato getfromcpan
che li scarica, ne crea il pacchetto rpm e se lanciato come root li installa o per i puristi con il comando Perl per accedere all'immenso archivio dei moduli di Perl:
#perl -MCPAN -e 'install Time::HiRes'
#perl -CPAN -e 'install File::Tail'
#perl -MCPAN -e 'install Date::Parse'
#perl -MCPAN -e 'install Net::Netmask'
A questo punto premesso di avere un'installazione funzionante di un sistema di posta, in questo caso poniamo un server pop3 e Postfix, sarà necessario lavorare principalmente sulla configurazione di pop-before-smtp e sul main.cf di Postfix.
Il file di configurazione principale pop-before-smtp-conf.pl
è molto ben commentato ed è consigliabile leggerlo tutto per chiarire appieno il funzionamento e le possibili configurazioni, di norma si dovrà fare attenzione ad alcuni parametri:
# Set the log file we will watch for pop3d/imapd records.
Con questo commento inizia la sezione che specifica il log file del server pop3d/imapd. Notare che è presente del codice che tenta di effettuare questa operazione automaticamente.
if (!-f $file_tail{'name'}) {
foreach (qw( /var/log/mail/info /var/log/mail.log
/var/log/messages /var/adm/messages )) {
if (-f $_) {
$file_tail{'name'} = $_;
last;
}
}
}
Mentre sarà importante fare attenzione alle definizioni della variabile $pat
per determinare le azioni da eseguire sui file di log, di cui il default è
# For UW ipop3d/imapd and their secure versions. This is the DEFAULT.
$pat = '^(... .. ..:..:..) \S+ (?:ipop3s?d|imaps?d)\[\d+\]: ' .
'(?:Login|Authenticated|Auth) user=\S+ ' .
'host=(?:\S+ )?\[(\d+\.\d+\.\d+\.\d+)\]';
Sarà necessario identificare il server pop3d/imapd usato e scommentare le righe di codice che lo riguardano.
A questo punto se è tutto a posto si potrà lanciare il comando o usando
#/usr/sbin/pop-before-smtp
o a seconda della distribuzione lo script di init
/etc/init.d/pop-before-smtp start
Di default dovrebbe creare il file pop-before-smtp.db
nella directory /etc/postfix/
e sarà necessario configurare il main.cf di conseguenza agendo sul parametro di restrizione dei recipienti
smtpd_recipient_restrictions = permit_mynetworks,reject_non_fqdn_recipient,
check_client_access hash:/etc/postfix/pop-before-smtp,
check_relay_domains
In questo modo quando un client si autenticherà via pop da qualunque indirizzo ip, poniamo dei dipendenti che viaggiano spesso e si collegano con il modem, il demone pop-before-smtp aggiornerà il file database contenente le informazioni sul client di modo che Postfix ne conceda l'inoltro (relay) della posta. I metodi possibili per gestire l'autenticazione per limitare il relay di Postfix sono molte, questo è forse uno dei metodi più semplici e pratici ma consigliabile fare riferimento alla documentazione presente in Internet per questo argomento che spesso contiene informazioni molto utili per la comprensione delle architetture implementabili con Postfix.
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: lorenzo 'lorenz' urbinati - Ultimo Aggiornamento: 2003-07-15 20:55:17
Di default Postfix accetta esclusivamente connessioni dal network locale e dai domini che ospita ma in situazioni di rete complesse può essere necessario assumere un maggiore controllo sulle connessioni al server.
Per questo vengono incontro numerosi parametri del file main.cf con cui è possibile effettuare diversi controlli sul traffico di posta del server.
Attraverso il main.cf si può:
Stabilire il comportamento del server al momento della connessione del client.
Si lavora a livello del protocollo SMTP andando a modificare il comportamento del server.
Ad esempio costringendo il server ad accettare connessioni strettamente aderenti allo standard stabilito nella rfc 821 o modificandone il comportamento in concomitanza con alcuni comandi SMTP.
I parametri per queste operazioni riguardano comandi interni al protocollo SMTP, è consigliabile leggere le RFC sull'argomento e fare riferimento alla documentazione ufficiale del pacchetto.
Un parametro tra questi che può essere importante è
smtpd_helo_restrictions = valori
che permette di definire diverse regole di comportamento del server in relazione a quali host possono inviare un comando HELO
, l'inizio di norma di qualunque connessione SMTP. Questo parametro è equivalente e viceversa ad altri utilizzabili nel main.cf, come restringere i nomi dei client o i loro indirizzi IP con il parametro
smtpd_client_restrictions = valori
oppure agire sul campo sender
smtpd_sender_restrictions = valori
o sul comportamento del relay della posta
smtpd_recipient_restrictions = valori
Effettuare controlli sugli header di un messaggio e sul corpo dei messaggi.
Stabilendo delle regole di filtraggio delle intestazioni di un messaggio contenenti informazioni sul tipo di programma client e sulle macchine attraverso cui il messaggio è passato dando la possibilità in questo modo di implementare delle liste nere di server da cui non accettare mai la posta e filtrando i contenuti di un messaggio stabilendo delle liste di termini non permessi. Per i parametri e il metodo da usare per implementare questo tipo di controlli fare riferimento alla documentazione ufficiale di Postfix
Restringere l'inoltro della posta per quanto riguarda l'utente specificato nel campo "sender".
In questo modo si può stabilire che il server non accetti posta da client che non specificano un nome di dominio FDQN oppure accettare l'inoltro solo da utenti definiti.
Il parametro che si occupa di questa operazione è
smtpd_sender_restrictions = valori
La sua sintassi, simile nei parametri complementari visti in precedenza, permette di restringere l'uso del server di posta agendo sul campo sender. Opzioni possibili per questo sono
reject_unknown_sender_domain
reject_non_fqdn_sender
oppure un file database con le specifiche per i sender autorizzati con l'utilizzo di una sintassi particolare tipo_file:percorso_file
hash = /etc/postfix/access
Agire sui recipient di inoltro della posta.
Stabilendo regole sulla funzione di relay del server e agendo in sostanza sugli indirizzi concessi nel campo SMTP RCPT TO
di modo da limitare o dare accesso per il relay della posta a client non appartenenti alla sotto-rete del server. Questo metodo è consigliato quando si utilizzano controlli di accesso tipo pop-before-smtp
che permette l'uso del relay solo a client che si sono autenticati via pop precedentemente.
Il parametro principale è
smtpd_recipient_restrictions = valori
le cui opzioni impongono che sia presente sempre una voce tipo reject, defer, defer_if_permit o reject_unauth_destination altrimenti il server rifiuterà comunque la ricezione di posta.
Per esempio quindi si userà
smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination
Questo parametro è utilizzabile anche specificando un'opzione di controllo sui client
check_client_access = tipo_file:percorso_file
Le combinazioni di parametri e opzioni possono rendere una configurazione molto complessa e le possibilità offerte sono innumerevoli, è consigliabile prima di approfondire con la configurazione accertarsi di aver compreso come funziona il protocollo SMTP visitando il sito delle request for comments http://www.rfc-editor.org e cercando le rfc 821 e 2821.
SOURCE: Documentazione ufficiale - http://www.postfix.org/docs.html
SOURCE: Specifiche SMTP - http://www.groovyweb.uklinux.net/index.php?page_name=smtp%20commands
Tipo Infobox: COMMANDS - Skill Level: 2- JUNIOR - Autore: lorenzo 'lorenz' urbinati - Ultimo Aggiornamento: 2003-07-15 21:06:26
Mentre postsuper effettua operazioni di carattere amministrativo sui file delle code in Postfix, all'utente finale viene fornito uno strumento per agire sui propri file di posta. In se implementa operazioni che tradizionalmente sono disponibili con il comando sendmail di Postfix. Questo comando è ideato per essere set-group ID (SGID) di modo che possa comunicare con i processi appartenenti ai demoni interni al sistema di posta.
La sua sintassi
postqueue [-c directory_file_conf] [-f][-p] [-s sito] [-v]
Le opzioni sono poche
-c directory_file_conf
: Specifica la directory dove si trova il file di configurazione. A dimostrazione dell'attenzione prestata alla sicurezza per evitare che un utente smaliziato sia in grado di usare il set-group ID per i propri discutibili motivi, non si può in realtà specificare una directory arbitraria. Una directory arbitraria e concessa solo se se elencata nel file main.cf con il parametro alternate_config_directories oppure se il comando è lanciato dall'super-utente root.
-f
: Pulisce la coda. In sostanza tenta l'inoltro di tutta la posta in coda.
-p
: Produce una lista dei file nelle code. Usa uno stile alla "sendmail".
Per ogni file in coda mostra l'ID, la misura del messaggio, l'orario di arrivo, chi lo ha inviato e i recapiti a cui va inoltrato. Se la posta in questione non è stata inoltrata per qualche motivo mostra la ragione di questo fallimento. L'ID di un messaggio a volte viene mostrato seguito da un carattere speciale.
Se si trova un asterisco "*
" il messaggio si trova nella coda active e sta per essere inoltrato.
Se invece è presente un simbolo "!
" il messaggio si trova nella coda holde non sarà inoltrato finchè l'amministratore non lo rilascierà.
-s sito
: Con questa opzione si stabilisce l'inoltro di tutta la posta in coda per il dominio specificato. Di norma sono ammessi tutti i domini per cui Postfix è abilitato come relay-server o quelli presenti nel parametro di configurazione fast_flush_domains.
-v
: Opzione per avere maggiori informazioni sullo stato dei processi messi in atto dal comando. Se usato più volte abilita ulteriori informazioni. Da intendersi per l'uso in casi di debugging.
Tipo Infobox: COMMANDS - Skill Level: 3- INTERMEDIATE - Autore: lorenzo 'lorenz' urbinati - Ultimo Aggiornamento: 2003-07-15 21:07:11
Questo comando è inteso per la gestione e la manutenzione dei processi nelle code di Postfix. L'uso di questo comando è inteso per il superutente, l'amministratore del sistema mentre l'utente semplice per agire sui file di una coda Postfix può usare postqueue
.
La sua sintassi
postsuper [-psv] [-c directory_file_conf] [-d][-h][-H][-r] [id_coda] [directory_coda]
Di default postsuper effettua le operazioni su tutte le directory di coda di Postfix, quindi incoming, active e deferred le principali code per i file di mail, e sulle directory con i log files, bounce, defer, e flush.
Le sue opzioni
-c directory_file_conf
: Specifica la directory dove si trova il main.cf per l'istanza di Postfix su cui si desidera lavorare.
-d id_coda
: Questa opzione elimina un messaggio che ha l'id specificato dalla code (di default: hold, incoming, active e deferred). Se si usa come id il simbolo "-
" il programma legge gli id dallo standard input. Questo rende possibile usare postsuper all'interno di script.
Per rimuovere tutti i messaggi si usa il suffisso ALL
che va specificato in maiuscolo per motivi di sicurezza. Se si definisce una coda in particolare verranno cancellati tutti i messaggi per quella coda:
postsuper -d ALL deferred
eliminerà tutti i file di posta presenti nella coda deferred.
Occorre notare che l'id di un file in coda viene riutilizzato dal sistema di posta. Questo comporta il rischio di eliminare il messaggio errato. Per esempio, il queue manager cancella il messaggio indicato da postsuper perchè ha finito il suo ciclo all'interno del sistema. Arriva posta nuova e ad un messaggio viene dato l'id che postsuper ha richiesto di rimuovere. Il messaggio nuovo viene eliminato al posto di quello giusto.
Occorre quindi prestare attenzione se si desidera eliminare dei messaggi mentre il sistema di posta è attivo.
-h id_coda
: Questa opzione sposta il messaggio definito dalla coda o dalle code (di default, incoming, active e deferred) alla coda hold di modo che nessuna operazione di inoltro venga effettuata prima del suo rilascio da parte del postmaster. Anche con questa opzione se al posto di un id di messaggio si utilizza il simbolo "-
" il programma legge gli id dall'input di tastiera. Anche questa opzione supporta la chiave ALL
che va utilizzata in maiscolo per forzare l'attenzione su questa delicata operazione.
-H id_coda
: Con questa opzione si esegue il rilascio della posta messa "on hold", trattenuta nella coda hold. La posta rilasciata viene messa all'interno della coda deferred Anche per questa funzione valgono le chiavi ALL
e "-
"
-p
: Pulisce i vecchi file temporanei che vengono creati in caso di un crash del sistema o del software di posta.
-r id_coda
: Rielabora nuovamente il messaggio specificato dall'inizio come fosse appena arrivato. Il messaggio viene preso dalla coda o dalle code (di default: hold, incoming, active e deferred). Per riimpostare file multipli è consigliato usare l'opzione più volte. Anche questo parametro supporta le chiavi "-
" e ALL
. Un messaggio riinserito in coda viene spostato nella coda maildrop da dove viene copiato dal pickup daemon in un nuovo file. Questo viene rielaborato, subendo nuovamente le operazioni di address rewriting e sostituzione. Questa operazione è utile quando si sono modificate alcune regole o la mappatura virtuale. Va ricordato che gli id delle code sono riutilizzati e quindi c'è una minima possibilità di effettuare questa operazione su un file sbagliato ma senza particolari conseguenze (non viene eliminato) e solo se il sistema di posta è attivo.
-s
: Questa operazione è importante e andrebbe eseguita sempre prima che Postfix venga lanciato. Effettua un controllo strutturale dei file e ripara gli errori.
In sostanza rinomina i file il cui nome non è associato all'inode giusto. Questo è utile in caso si stia recuperando la posta di un'altra macchina o da un backup. Infine sposta i file che non si trovano al posto giusto e rimuove le sotto directory che non sono più necessarie.
-v
: Abilita i messaggi per propositi di debug e testing. L'uso multiplo di questa opzione abilita maggiori informazioni.
Tipo Infobox: COMMANDS - Skill Level: 3- INTERMEDIATE - Autore: lorenzo 'lorenz' urbinati - Ultimo Aggiornamento: 2003-06-30 21:18:47
Il comando postconf è una utility a riga di comando che permette diverse operazioni su un file di configurazione di Postfix. Con postconf si possono consultare i parametri presenti al momento nel sistema di posta, si può editare il file specificato, si possono verificare i valori di default per una particolare direttiva.
postconf [-dhmlnv] [-c directory_file_conf] [parametro ...]
postconf [-ev] [-c directory_file_conf] [parametro=valore ...]
La maggior parte delle opzioni riguardano principalmente il controllo dei valori configurati e di quelli standard.
-c directory_file_conf
: Permette di specificare la directory che contiene i file di configurazione su cui si desidera agire.
-d
: Mostra i valori di default per tutti i parametri.
-h
: Mostra esclusivamente i valori e non il nome dei parametri configurati.
-m
: Mostra una lista delle tipologie di tabelle supportate.
-l
: Mostra una lista di metodi per il lock delle mailbox.
-n
: Mostra tutti i valori che non sono default nel file specificato.
-e
: Questa è l'opzione più importante perchè è necessaria per editare un particolare parametro del file di configurazione.
Per avere un quadro quanto più complessivo delle numerose opzioni di Postfix occorre fare riferimento a diverse fonti. Con l'ausilio dei commenti del main.cf
standard, della lettura dei file di esempio e grazie a questa utility è possibile ottimizzare al meglio il proprio MTA (Mail Transfer Agent) e adattarlo a diverse architetture di accesso dati. Una grande utilità di questo comando è che se lanciato senza opzioni mostra tutti i valori della configurazione attuale in modo da avere una idea complessiva di tutti i parametri presenti nei file di esempio.
Tipo Infobox: COMMANDS - Skill Level: 2- JUNIOR - Autore: lorenzo 'lorenz' urbinati - Ultimo Aggiornamento: 2004-06-04 11:59:07
La suite di Postfix si compone di numerosi demoni e di una decina di comandi che servono a regolare specifiche operazioni. Il principale e più importante è il comando postfix che serve a controllare il programma stesso. Con esso si avvia o si ferma il demone master del sistema di posta, si verifica lo stato o si ricarica la configurazione.
La sua sintassi è semplice e senza troppe opzioni, ma ha vari sotto-comandi.
postfix [-Dv] [-c directory_file_conf] comando_interno
-D
: Usata solo con il sotto-comando start
permette di lanciare i demoni di postfix sotto il controllo delle direttive di debug specificate nel main.cf.
-v
: Anche questa opzione è orientata al debug del software, si possono specificare più volte per avere ancora più informazioni.
-c
: Permette di specificare una directory alternativa a quella di default in cui il comando andrà a cercare i file di configurazione. Utile nel caso si stiano eseguendo più server di posta sulla stessa macchina.
I comandi interni regolano diverse operazioni
start
: Avvia il sistema di posta. Effettua anche un controllo della configurazione come se si usasse il comando check
.
stop
: Ferma il sistema di stampa regolarmente. I processi in corso hanno modo di terminare quanto prima ma completando le loro operazioni.
abort
: Ferma il sistema di stampa forzatamente. I processi in corso sono costretti a fermarsi immediatamente.
check
: Verifica la configurazione del sistema di posta e mostra degli alert per errori nei permessi dei file o delle directory.
flush
: Forza l'inoltro di ogni messaggio in attesa di essere inviato. Utile nel caso si usi una connessione verso Internet di tipo PPP o ISDN che non è sempre attiva.
reload
: Permette di ricaricare i file di configurazione senza fermare il sistema di posta.
Questo comando va utilizzato esclusivamente dall'utente root.
HOWTO: postfix -
Tipo Infobox: DESCRIPTION - Skill Level: 4- ADVANCED - Autore: lorenzo 'lorenz' urbinati - Ultimo Aggiornamento: 2003-06-30 21:06:44
Una volta configurato il server con i parametri per l'invio, la ricezione e l'inoltro della posta si può prendere in considerazione l'ottimizzazione del servizio e un maggiore controllo delle sue funzioni.
Esistono molte possibilità per definire il comportamento di Postfix e in special modo per controllarne gli accessi, sia da un punto di vista di consumo delle risorse sia dal controllo di cosa può passare e cosa invece no per evitare, ad esempio, l'invio massivo attraverso il server di UCE (Unsolicited Commercial Email) o comunemente SPAM. Per controllare l'invio di SPAM di default l'SMTP-server di Postfix accetta esclusivamente la posta per il network o il dominio locale e per i domini ospiti del server, in modo che dagli estranei non si accetti alcuna connessione. Esistono diversi modi per assumere maggior controllo su questa problematica usando liste di accesso in stile Sendmail o RBL (Real Time Blackhole List) e per un approfondimento si può fare riferimento alla documentazione ufficiale disponibile sul sito di Postfix, www.postfix.org, o nella directory di sistema dedicata alla documentazione dei pacchetti installati.
E' importante inoltre controllare le quantità di posta processabile, ad esempio per limitare il numero di processi contemporanei anche se si dispone di un limite massimo di 1000 client.
default_process_limit = valore
permette di controllare il numero di processi in uscita e in entrata. Di default è settato a 100 ma nel caso di una piccola rete casalinga andrebbe benissimo un valore di 10 mentre per un mail server principale di un provider andrebbe meglio un valore di 1000 o 10000.
Per controllare che il server non sia usato per un attacco tipo DoS o per spam si usano alcune variabili che ai loro valori di default dovrebbero andare benissimo.
initial_destination_concurrency = valore
(default:2)
che controlla quanti messaggi sono inizialmente inviati verso la stessa destinazione prima di attuare un invio multiplo.
local_destination_concurrency_limit = valore
(default:2)
che controlla quanti messaggi sono inviati contemporaneamente allo stesso recipiente locale.
default_destination_concurrency_limit = valore
(default:20)
che impone il limite di messaggi inviabili contemporaneamente alla stessa destinazione.
Ulteriori parametri permettono quanto meno di limitare l'uso del server da parte di client sbadati o maliziosi, rallentando di fatto le loro connessioni fino a chiuderle senza troppi imbarazzi. Il server incrementa un conteggio per sessione degli errori dovuti a richieste da parte dei client non riconosciute valide o sconosciute e di tutte le richieste che in qualche modo violano le regole UCE. Questo conteggio si azzera quando un messaggio viene inviato correttamente. Se il conteggio aumenta il server limita i danni rallentando il client.
Le variabili che controllano queste funzioni sono:
smtpd_error_sleep_time = valore
(va bene il valore di default:1)
che in sostanza cerca di evitare gli errori di un client quando il conteggio è ancora basso ponendo un tempo limite in cui il server resta in pausa mentre comunica l'errore al client.
smtpd_soft_error_limit = valore
di default 10 stabilisce che quando il numero di errori per sessione supera il valore impostato il server attende il valore del conteggio in secondi prima di rispondere ad un'altra richiesta del client.
smtpd_hard_error_limit = valore
di default 20 e stabilisce che al superare nel conteggio del valore impostato il server SMTP taglia la connessione.
SOURCE: Documentazione ufficiale - http://www.postfix.org/docs.html
Tipo Infobox: DESCRIPTION - Skill Level: 3- INTERMEDIATE - Autore: lorenzo 'lorenz' urbinati - Ultimo Aggiornamento: 2003-06-30 21:02:29
Postfix principalmente si controlla attraverso due importanti file, "main.cf" e "master.cf".
Rispettivamente regolano il comportamento generale dell'applicazione e la configurazione del master daemon che gestisce il comportamento di tutti i demoni che compongono questo sistema di posta.
Di norma il master.cf può essere lasciato intatto a meno che non si stia lavorando su configurazioni più complesse come ad esempio intergrare Postfix con Cyrus.
Il main.cf è il file più importante. Attraverso questo file è possibile configurare Postfix come un semplice relay server per una piccola rete casalinga fino ad arrivare a configurazioni di alto livello per sistemi "enterprise".
Il file si presenta molto ben commentato e spesso i valori di default vanno benissimo, ma rimane un file complesso e molto grosso, i diversi parametri sono molti, più di 250 stando a quanto scritto nelle primissime righe di commento. Per questo generalmente Postfix dispone di un nutrito set di file di esempio e molto utili se si desidera conoscere molti parametri di default che non sono presenti nel main.cf a installazione completata. Ci si può inoltre aiutare usando il comando postconf
.
Le direttive vengono separate tra di loro e riunite in categorie (Queue and process ownership, Internet host and domain name, Sending mail...) facilitando in questo modo la comprensione del significato dei singoli parametri.
Di norma per avere un sistema di posta funzionante non occorre che modificare poche variabili.
- Quale dominio usare per la posta in uscita.
- Quale invece di cui ricevere la posta.
- Quali client hanno modo di inviare la posta attraverso il server.
La direttiva
myorigin = valore
permette di specificare il dominio da usare per la posta inviata attraverso questo server. Il valore di default è la variabile $myhostname
ma a meno che non si utilizzi il server per una piccola rete locale sarà opportuno modificarlo con $mydomain
.
myorigin = $mydomain
mydestination = valore
specifica per quali domini il sistema di posta deve instradare localmente i messaggi anzichè inviarli ad un altro server. Generalmente si compone di una lista di nomi, si possono specificare anche file o tabelle, di norma occorrerà aggiungere $mydomain
ai valori di default in modo che il server sia il mail server del dominio.
mydestination = $myhostname localhost.$mydomain $mydomain
Dove i primi due valori sono quelli di default.
mynetworks = valore
Questa variabile volendo permette di impostare host per host le macchine che possono usare il server per l'inoltro dei messaggi. Di default si usa la direttiva complementare mynetworks_style.
mynetworks_style = [class] [subnet] [host]
subnet è il valore di default e indica che Postfix inoltrerà la posta per tutti i client nella sottorete locale.
class Postfix considererà validi tutti i client provenienti dal network di classe A, B o C a cui è collegato.
host l'inoltro sarà abilitato esclusivamente per la macchina locale.
myhostname = valore
Questo parametro permette di specificare una importante direttiva usata da altri parametri del file di configurazione con la variabile $myhostname
. Il nome dell'host va specificato nella forma FQDN (Fully Qualified Domain Name). Di default Postfix usa il nome dell'host locale ma se questo non fosse un nome di dominio completo o fosse in ascolto su un'interfaccia virtuale si deve specificare il nome di dominio completo per il server.
myhostname = mail.esempio.com
myhostname = mail.virtualesempio.com
mydomain = valore
Permette di specificare il dominio a cui appartiene il server. Di norma è usato il valore di $myhostname
togliendo la prima parte del nome a meno che non si riduca ad un dominio di primo livello.
mydomain = esempio.com
Configurati questi parametri si dovrebbe cominciare ad avere un server di posta utilizzabile.
Nel caso in cui la macchina che si sta usando possiede più di un indirizzo su un'interfaccia di rete o più interfaccie verrà utile specificare inoltre
inet_interfaces = valore
Di default in ascolto su tutti gli indirizzi (all
) con questa direttiva si possono specificare le interfaccie virtuali.
inet_interfaces = virtual.esempio.com
Perchè la modifica di questa variabile sia effettiva non basta effettuare un reload ma si deve fermare e riavviare il sistema di posta.
SOURCE: Documentazione ufficiale - http://www.postfix.org/docs.html
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: lorenzo 'lorenz' urbinati - Ultimo Aggiornamento: 2003-06-30 20:57:39
La maggior parte delle principali distribuzioni Linux comprende i pacchetti rpm di Postfix nel CD di installazione. Alcune come Suse lo hanno ormai sostituito a Sendmail nell'installazione di default. In certi casi comunque potrebbe essere necessario installare dai sorgenti.
Sul sito di Postfix, http://www.postfix.org, si trovano le indicazioni per scaricare i sorgenti dell'applicazione. Si noterà che, fedelmente al proposito di sostituire il diffusissimo Sendmail, è ormai disponibile il supporto per la compilazione su quasi tutte le versioni unix esistenti a patto di seguire in certi casi pochi accorgimenti.
Una volta scaricato e scompattato il pacchetto, cambiata la directory di lavoro in quella dei sorgenti appena creata, si può procedere con l'installazione.
All'interno dei sorgenti, tra i diversi file, si troveranno oltre alla documentazione ufficiale alcuni file utili per cominciare il processo di installazione. In caso si stia utilizzando un SO come Solaris che ha notevoli differenze da Linux, pur restando uno unix, nel file INSTALL si troveranno consigli utili per la compilazione su questa piattaforma e su altre che impongono diversi parametri.
Se si compila su un sistema che usa le GCC, vedi Linux, con il comando
make
si dà inizio al processo di compilazione. I parametri definibili in questa fase sono per lo più inerenti alla modifica della posizione di default dei file di configurazione o dei programmi che compongono Postfix.
Eseguita questa fase si procede nell'installazione. Si dovrà creare un utente dedicato che non necessita ne di una home directory ne di una shell con il comando
adduser postfix -s /bin/false -d /dev/null
e settare un record nel file delle password con il comando
passwd -l postfix
Dopo di che sarà necessario creare due gruppi, postfix e postdrop usando il comando groupadd
.
Queste operazioni sono necessarie per il successo dell'installazione.
Si procede con il comando
make install
per concludere l'installazione. Questo comando nel caso di Postfix è interattivo, permettendo di specificare parametri diversi da quelli di default, ponendo semplici domande e mostrando inoltre quali sono i valori standard.
Una volta installato tutto senza particolari modifiche ai valori standard si troveranno all'interno della directory /etc/postfix
tutti i file di configurazione e le tabelle.
Il file più importante è il main.cf
dove si specificano quasi tutti i parametri di configurazione, ma anche master.cf
, che regola il comportamento del programma master che si occupa di gestire gli altri programmi che compongono postfix e i parametri con cui questi programmi vengono eseguiti. Un'altro file di grande importanza e che generalmente viene editato prima di procedere con l'avvio del server è il file /etc/aliases
che a volte può trovarsi dentro la directory /etc/postfix/
. Ricordarsi che ogni volta che questo file viene modificato occorre lanciare il comando newaliases
perchè le modifiche abbiano effetto.
La directory radice dove si troveranno tutte le code si trova in /var/spool/postfix/
.
La documentazione verrà salvata in /usr/share/doc
o in /usr/doc
ma può cambiare a seconda della distribuzione usata.
La suite di postfix si compone di numerose applicazioni. Alla fine dell'installazione, se eseguita con i valori standard si troveranno tutti i demoni all'interno della directory /usr/libexec/postfix/
.
%ls -al /usr/libexec/postfix
drwxr-xr-x 2 root root 536 2003-05-31 22:24 .
drwxr-xr-x 100 root root 35976 2003-06-17 15:20 ..
-rwxr-xr-x 1 root root 159994 2003-03-17 16:35 bounce
-rwxr-xr-x 1 root root 192637 2003-03-17 16:35 cleanup
-rwxr-xr-x 1 root root 147535 2003-03-17 16:35 error
-rwxr-xr-x 1 root root 146107 2003-03-17 16:35 flush
-rwxr-xr-x 1 root root 185928 2003-03-17 16:35 lmtp
-rwxr-xr-x 1 root root 206273 2003-03-17 16:35 local
-rwxr-xr-x 1 root root 102287 2003-03-17 16:35 master
-rwxr-xr-x 1 root root 180167 2003-03-17 16:35 nqmgr
-rwxr-xr-x 1 root root 145316 2003-03-17 16:35 pickup
-rwxr-xr-x 1 root root 165959 2003-03-17 16:35 pipe
-rwxr-xr-x 1 root root 130586 2003-03-17 16:35 proxymap
-rwxr-xr-x 1 root root 174767 2003-03-17 16:35 qmgr
-rwxr-xr-x 1 root root 158236 2003-03-17 16:35 qmqpd
-rwxr-xr-x 1 root root 146374 2003-03-17 16:35 showq
-rwxr-xr-x 1 root root 227117 2003-03-17 16:35 smtp
-rwxr-xr-x 1 root root 257641 2003-03-17 16:35 smtpd
-rwxr-xr-x 1 root root 139319 2003-03-17 16:35 spawn
-rwxr-xr-x 1 root root 164847 2003-03-17 16:35 tlsmgr
-rwxr-xr-x 1 root root 150312 2003-03-17 16:35 trivial-rewrite
-rwxr-xr-x 1 root root 162184 2003-03-17 16:35 virtual
Le utility di gestione del servizio invece saranno all'interno della directory /usr/sbin/
%ls -al /usr/sbin/post*
-rwxr-xr-x 1 root root 132952 2003-03-17 16:35 /usr/sbin/postalias
-rwxr-xr-x 1 root root 27185 2003-03-17 16:35 /usr/sbin/postcat
-rwxr-xr-x 1 root root 145688 2003-03-17 16:35 /usr/sbin/postconf
-rwxr-sr-x 1 root postdrop 95451 2003-03-17 16:35 /usr/sbin/postdrop
-rwxr-xr-x 1 root root 69141 2003-03-17 16:35 /usr/sbin/postfix
-rwxr-xr-x 1 root root 75112 2003-03-17 16:35 /usr/sbin/postkick
-rwxr-xr-x 1 root root 71534 2003-03-17 16:35 /usr/sbin/postlock
-rwxr-xr-x 1 root root 68576 2003-03-17 16:35 /usr/sbin/postlog
-rwxr-xr-x 1 root root 125326 2003-03-17 16:35 /usr/sbin/postmap
-rwxr-sr-x 1 root postdrop 85781 2003-03-17 16:35 /usr/sbin/postqueue
-rwxr-xr-x 1 root root 84165 2003-03-17 16:35 /usr/sbin/postsuper
LINK: Postfix - Tutorial passo-passo per l'installazione di postfix con supporto mysql tables su MAC OS X - http://www.kdev.it/postfix.html
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: lorenzo 'lorenz' urbinati - Ultimo Aggiornamento: 2003-06-30 20:52:16
Postfix nasce con l'intento di sostituire Sendmail come server di posta. E' stato concepito quindi con un occhio di riguardo alla compatibilità con questo sistema di modo da facilitarne la migrazione.
Inoltre è studiato con molta attenzione nei riguardi della sicurezza tanto da venire considerato da molti il più sicuro mailer in circolazione.
Questo sistema di posta anzichè essere costituito da un unico grosso programma che effettua la maggior parte delle azioni è suddiviso in diversi programmi che svolgono una azione specifica e un programma principale che si occupa di chiamare il programma giusto quando necessario e di gestire le varie azioni. Solo il programma master necessita di privilegi elevati e va infatti lanciato da root, gli altri invece possono girare con privilegi molto bassi, ad esempio usando un utente creato appositamente, inoltre possono essere eseguiti in un ambiente "gabbia" chroot.
In questo modo si ha un isolamento dei singoli processi con un maggior controllo sulle singole azioni eseguite dal server. Inoltre è pensato per resistere a condizioni di lavoro con carichi di traffico elevati e utilizza particolari routines per evitare che un eventuale crash possa compromettere il comportamento dell'intera macchina. Oltre a non avere nessun programma SUID, Postfix non "crede" al contenuto delle code e in se non conosce il contenuto dei file in coda. I programmi che si occupano di un passaggio dell'elaborazione dati effettuano i controlli degli stessi allo scopo di indirizzarli verso il programma o la coda giusta.
Ogni programma che compone questo complesso sistema agisce in modo autonomo senza avere processi "figli" e in questo modo si cerca di evitare relazioni tra i processi che potrebbero condizionare il comportamento dei child in caso il processo "genitore" sia compromesso.
I dati che vengono ricevuti dalla rete vengono opportunamente filtrati e subiscono controlli diversi dai singoli programmi che si occupano della loro elaborazione, inoltre si evita di salvare tali dati sul disco ma vengono processati in primis dal programma e susseguentemente passati al programma successivo.
Postfix si avvale principalmente di quattro importanti code:
maildrop, incoming, active, deferred
La posta viene innanzitutto depositata in maildrop da dove dopo alcune elaborazioni passa alla coda incoming, questa coda è per la posta che è appena arrivata e che non è ancora stata elaborata dal manager delle code. La coda active invece è una piccola zona in cui la posta al suo interno è aperta dal manager ed è in attesa di essere instradata. Quella posta che non può, per vari motivi, essere instradata viene mandata alla coda deferred.
Il gestore delle code mantiene in memoria solo i dati presenti nella coda active in questo modo si evita che il processo si intasi in caso di una grossa mole di traffico.
Oltre a queste code Postfix mantiene due spazi "parcheggio" una si chiama hold e contiene tutti quei messaggi che sono congelati nella coda e per i quali non viene attuato nessun tentativo di smistamento. L'unico modo di rilasciare questi messaggi è con il comando postsuper. Il secondo parcheggio invece si chiama corrupt e al suo interno vengono salvati quei file che non sono riconosciuti validi, e vengono lasciati lì per permettere all'amministratore di controllarli.
Soluzioni Antivirus |
Rassegna delle soluzioni antivirus server based |
Tipo Infobox: TIPS - Skill Level: 4- ADVANCED - Autore: lorenzo 'lorenz' urbinati - Ultimo Aggiornamento: 2003-08-04 20:12:05
Amavisd è un demone scritto in Perl che permette di chiamare programmi esterni in grado di scomprimere, decodificare e classificare il contenuto dei messaggi e degli allegati di posta.
Accetta le mail dall'MTA usato, chiama moduli Perl esterni e programmi che controllano il messaggio di posta e infine li riinoltra all'MTA per la consegna, il rifiuto o la quarantena del messaggio.
Per usare amavisd-new bisogna assicurarsi che si stia utilizzando una versione di Postfix abbastanza recente e che supporti il parametro content_filter = valore
Innanzi tutto occorre creare un utente e un gruppo per usare questo demone.
Di norma si usa amavis come utente e sweep come gruppo. Per motivi di sicurezza non usare assolutamente utenti di sistema come nobody o altri relativi al sistema di posta come maildrop.
Il file una volta scompattato non occorre di compilazioni, all'interno del pacchetto si trovano l'eseguibile amavisd
e il suo file di configurazione amavis.conf
più uno script di init da inserire nella directory relativa ai file di init del sistema. Questi file vanno copiati nelle loro giuste directory prestando attenzione ai permessi e agli utenti che ne hanno la proprietà. Come home directory per l'utente si può definire /var/amavis/
o /var/lib/amavis/
#cp ./amavisd /usr/sbin/
#chown root /usr/sbin/amavisd
#chmod 755 /usr/sbin/amavisd
e di conseguenza il file di configurazione
#cp ./amavisd.conf /etc/
#chown root /etc/amavisd.conf
#chmod 644 /etc/amavisd.conf
Può essere utile creare una directory che serva da destinazione per i messaggi in quarantena.
#mkdir /var/quarantena
chown amavis.amavis /var/quarantena/
chmod 750 /var/quarantena/
A questo punto sarà necessario editare il file di configurazione amavisd.conf e di conseguenza anche i file di configurazione di Postfix.
Nel amavisd.conf
sarà importante fare attenzione ad alcuni parametri in particolare anche se è consigliabile leggerlo tutto perchè le opzioni possibili sono numerose.
Innanzi tutto si settano i parametri $daemon_user
e $daemon_group
specificando l'utente e il gruppo scelto per far girare il demone. In questo modo al momento del lancio, come root, di amavisd, automaticamente parte come se lanciato dall'utente specificato.
Le opzioni
$HOME
per definire la home directory dell'utente amavis.
$TEMPBASE
dove si definisce la directory in cui vengono temporaneamente posti i messaggi in elaborazione.
$QUARANTINEDIR
la directory di quarantena in cui i messaggi sospetti o certamente infetti vengono riposti per un eventuale controllo e pulizia.
E' possibile anche non creare nessuna directory di quarantena e fare in modo che tutta la mail destinata a questa "coda" sia inviata ad un account di posta preposto per questo.
Si crea una voce relativa nel file /etc/aliases
o a seconda dell'installazione /etc/postfix/aliases
infected = /var/spool/mail/infected
e a seconda che si desideri o meno un mailbox-style aggiungere uno slash finale. Lanciare il comando newaliases
o postalias /etc/postfix/aliases
per aggiornare il database.
Infine specificare nel file amavisd.conf la direttiva
$virus_quarantine_to = 'infected@';
in modo da inviare tutta la posta in quarantena all'indirizzo infected.
Sarà necessario poi prestare attenzione agli altri parametri presenti nella 'Section I', $mydomain
e @local_domains_acl = valore
, e per finire agire sui valori di specifica del software antivirus usato nella 'Section VII'. A questo punto amavisd può essere lanciato e se dovessero mancare alcuni prerequisiti, come qualche modulo Perl, uscirà con un errore mostrando una lista di cosa è venuto a mancare.
Configurato amavisd sarà necessario lavorare sui file di configurazione di Postfix main.cf e master.cf.
Nel master.cf dovranno essere aggiunte le seguenti voci
smtp-amavis unix - - y/n - 2 smtp
-o smtp_data_done_timeout=1200
-o disable_dns_lookups=yes
127.0.0.1:10025 inet n - y/n - - smtpd
-o content_filter=
Dove y/n corrispondono al campo "chroot" e serve ad indicare se si è o meno in un ambiente di lavoro chroot.
Infine con il comando
#postconf -e 'content_filter = smtp-amavis:[127.0.0.1]:10024'
si modifica il main.cf e si fa in modo che Postfix inizi a inviare tutta la posta che riceve ad amavisd.
Effettuare un relaod della configurazione con il comando
#postfix reload
Controllare i file di log di Postfix e di amavisd per verificare che tutto funzioni. Volendo all'interno della directory del pacchetto Amavis è presente una sotto-directory test-messages
contenente alcuni file utili per testare il funzionamento del nuovo sistema di filtraggio della posta.
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2003-09-02 19:29:17
Molti fra i maggiori produttori di antivirus forniscono soluzioni per sistemi Linux, in particolare orientati a mail server, dove maggiore può essere l'utilizzo di un Antivirus con funzioni di protezione della posta anche per client Windows.
L'offerta di F-Prot per sistemi Linux si compone di:
F-Prot for Linux Workstation - Orientata a singoli utenti e al momento poco utile, vista la scarsa diffusione di virus per Linux;
F-Prot for Linux Mail Servers - La soluzione ideale per ISP e aziende che hanno un server di posta basato su Linux (Sendmail, Postfix, Qmail..)
F-Prot for Linux File Servers - Utile su file e ftp server di una rete locale aziendale.
L'engine di virus scanning e il database dei virus sono gli stessi delle rispettive versioni per Windows e vengono costantemente aggiornati. La versione per Mail Servers ha le seguenti componenti:
- F-Prot Antivirus Command-Line Scanner ( f-prot [options] [file or directory]
)
- F-Prot Antivirus Daemon Scanner ( f-protd /path/to/data/directory/
)
- F-Prot Antivirus Updater ( check-updates.pl [options]
)
- F-Prot Antivirus Mail Scanner ( scan-mail.pl [-backup]
)
- F-Prot Antivirus Preloadable Library Call Wrapper ( f-prot.so
)
L'installazione è piuttosto semplice, può essere eseguita direttamente tramite pacchetto RPM o DEP o scompattando un tar.gz e seguendo le relative istruzioni. Tutti i file vengono scritti nella directory /usr/local/f-prot
e a questi si aggiungono dei link simbolici per i comandi di basi in PATH tipici (bin, sbin), gli script di gestione del servizio f-protd in /etc/init.d/f-protd
e i relativi link SysV nelle directory rc#.
Alcuni comandi di F-Prot si basano su Perl 5 e richiedono i seguenti moduli:
scan-mail.pl: MIME::Base64, MIME::QuotedPrint
check-updates.pl: NET::FTP, IO::File, HTTP::Request, HTTP::Response, LWP::UserAgent
I signature files, contenenti le definizioni dei virus sono /usr/local/f-prot/MACRO.DEF
, SIGN.DEF
, SIGN2.DEF
, questi possono venir aggiornati tramite il comando check-updates.pl che va, ovviamente, inserito nel crontab (ad esempio con: 30 4,16 * * * /usr/local/f-prot/tools/check-updates.pl -cron
).
FileSystem Scan
Lo scan di virus sul filesystem può avvenire tramite il comando f-prot che ha varie funzioni e opzioni come:
f-prot /var -dumb -disinf -list
- Esegue uno scan sulla directory /var (e sottodirectory) senza considerare il tipo di file (-dumb), provando a disinfettare i file infetti (-disinf) e visualizzando tutti i file controllati (-list).
f-prot -virlist
- Visualizza l'elenco dei virus che possono venir riconosciuti.
Mail Delivery Scan
F-Prot può facilmente interfacciarsi con qualsiasi sistema di posta che si appoggia a Procmail per il delivery locale dei messaggi (o altri che permettano di passare e far filtrare da un programma esterno la mail prima di salvarla sulla casella postale del destinatario).
Per integrare F-Prot con Procmail basta editare /etc/procmailrc
oppure ~/.procmailrc
(per configurazioni relative a singoli utenti) ed aggiungere un testo tipo:
:0 fw
| /usr/local/f-prot/tools/scan-mail.pl
Allo script scan-mail.pl possono essre aggiunte opzioni come -backup
per eseguire una copia di tutte le mail e -quarantine
per copiare tutti i messaggi originali poi modificati perchè contenenti un virus. Le copie vengono messe nella directory /usr/local/f-prot/backup/
.
E' opportuno considerare che questo metodo controlla i virus solo sulle mail in entrata (nel momento in cui stanno per essere consegnata ad una casella postale locale) e non quelle in uscita. Per un controllo su tutte le mail che vengono gestite dal server esiste la possibilità di fare un:
Mail In-Transit Scan
Questo metodo utilizza il plugin libmilter per Sendmail, per cui non viene ufficialmente supportato su altri SMTP server. La configurazione è semplice, invece di intervenire su .fetchmail.rc si deve editare /tec/mail/sendmail.mc
ed aggiungere righe come:
INPUT_MAIL_FILTER(`f-prot-milter', `S=/var/run/f-prot.sock, F=T, T=E:5m')
Dopo va ricreato il file di configurazione definivo di Sendmail (m4 /etc/mail/sendmail.mc > /etc/mail/sendmail.cf
) e riavviato il servizio. Lo script scan-mail.pl va quindi avviato con l'opzione -milter
(lo si può fare editando direttamente le variabili definite nel codice Perl).
SOURCE: F-Prot Antivirus for Linux Mail Servers - http://www.f-prot.com/support/helpfiles/unix/linux_ms/index.html
Tipo Infobox: DESCRIPTION - Skill Level: 3- INTERMEDIATE - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2004-05-19 18:08:54
ClamAV è uno dei più interessanti progetti OpenSource per lo scanning di virus.
Rilasciato sotto GPL, è Posix compliant e quindi disponibile per varie piattaforme *nix (Linux, *BSD, Solaris, MacOs X, lo stesso CygWin... ) e, rispetto ad altri progetti simili, ha il fondamentale pregio di mantenere un database in costante aggiornamento.
La versione analizzata, 0.70, identifica più di 20000 virus, è in grado di scompattare file compressi e di analizzare documenti di Office per Macro virus. NON corregge i file infetti, ma, nella sua applicazione più comune (antivirus correlato ad un sistema di posta) questa mancanza è assolutamente ininfluente.
INSTALLAZIONE
E' possibile scaricare sorgenti e binari precompilati per diverse distribuzioni dal sito ufficiale www.clamav.net.
Per compilare ClamAv è necessario avere i seguenti pacchetti: zlib, zlib-devel, oltre ovviamente alla suite gcc. Sono inoltre consigliati bzip2, bzip2-devel, gmp.
Per usarlo è necessario avere un utente non privilegiato con cui farlo eseguire:
groupadd clamav
useradd -g clamav -s /bin/false -c "Clam AntiVirus" clamav
Si può quindi procedere alla scompattazione del tar.gz scaricato:
tar -zxvf clamav-x.yz.tar.gz
cd clamav-x.yz
E alla compilazione (qui viene specificato di mettere il file di configuazione sotto /etc ):
./configure --sysconfdir=/etc
make
su -c "make install"
Binari e librerie vengono copiati in /usr/local, il file di configurazione, vista l'opzione --sysconfdir sopra specificata, diventa /etc/clamd.conf
.
Una volta eseguita l'installazione è possibile testate l'engine su dei file d'esempio forniti con il tar.gz:
clamscan -r -l scan.txt clamav-x.yz
CONFIGURAZIONE
Il file di configurazione /etc/clamav.conf
(o /usr/local/etc/clamav.conf
se si sono compilati direttamente i sorgenti senza aver impostato specifici parametri) contiene le varie voci che determinano il funzionamento di ClamAV. I parametri impostati di default sono generalmente adeguati e non è necessario modificarli per poter iniziare ad usarlo, bisogna solo provvedere a commentare la riga Example
(il che, quantomeno, obbliga l'utente a dare un'occhiata al file di configurazione ed avere barlumi di consapevolezza sulla sua logica).
Si segnalano comunque impostazioni quali:
LogFile /tmp/clamd.log
, LogFileMaxSize 2M
, LogVerbose
, LogSyslog
determinano posizione, dimensioni, verbosità ed eventuale utilizzo di Syslog per il file di log.
DatabaseDirectory /var/lib/clamav
la directory in cui viene scritto il database con le signature dei virus riconosciuti
TCPSocket 3310
, TCPAddr 127.0.0.1
la porta e l'indirizzo a cui si mette in ascolto clamd (di default si binda ad ogni indirizzo disponibile)
MaxConnectionQueueLength 15
, MaxThreads 5
il numero massimo di connessioni contemporanee e di thread su clamd (aumentare su sistemi con grossi carichi)
StreamMaxLength 10M
VirusEvent /usr/local/bin/send_sms 123456789 "VIRUS ALERT: %f: %v"
quale comando eseguire nel caso venga intercettato un virus
User clamav
L'utente con cui viene eseguivo clam. Di default "clamav", va creato in fase di installazione e deve avere permessi di lettura e scrittura sui log e il database dei virus.
ScanOLE2
, ScanMail
, ScanArchive
definiscono se eseguire scan su file Microsoft Office, su caselle postale e su file compressi. Notare che lo scan di mailbox è disabilitato di default.
ArchiveMaxFileSize 10M
, ArchiveMaxFiles 1000
[...] parametri vari che determinano dimensioni degli archivi su cui eseguire gli scan.
CONFIGURAZIONE AUTO AGGIORNAMENTO: FRESHCLAM
Freshclam è lo strumento migliore per tenere aggiornato il database di virus su cui lavora l'engine di ClamAV.
Può essere eseguito via command line e schedulato per un aggiornamento automatico, oppure essere lanciato come demone in costante esecuzione. Il suo file di configurazione è /etc/freshclam.conf
dove vengono definite informazioni quali:
DatabaseDirectory /var/lib/clamav
- La directory dove Clam trova il database dei virus, deve essere uguale a quanto definito in clamav.conf
UpdateLogFile /var/log/clamav/freshclam.log
- Il file dove vengono loggate le operazioni di freshclam, deve appartenere all'utente clamav e può avere permessi 0600
NotifyClamd /etc/clamav.conf
- Notifica clamd (va indicato il path corretto del suo file di conf) ogni volta che vengono aggiunti virus al database, in modo da riavviarlo per ricaricare il database aggiornato.
DatabaseMirror database.clamav.net
L'indirizzo da cui scaricare gli aggiornamenti. Il valore preimpostato è l'ideale perchè punta ad un pool, gestito con un round-robin DNS, di mirror ufficiali
Esistono altre opzioni che permettono di usare un proxy http, di eseguire comandi custom ad ogni aggiornamento o errore, di gestire la frequenza degli aggiornamenti (in modalità demone) o il numero di tentativi, ecc.
Per eseguire freshclam in daemon mode basta lanciare:
/usr/local/bin/freshclam -d
per lanciare una esecuzione schedulata, aggiungere a /etc/crontab
una riga tipo:
N * * * * /usr/local/bin/freshclam --quiet
dove N è un numero da 00 a 59 che indica il minuto in cui eseguire l'aggiornamento (ogni ora).
USARE CLAMAV
Clamav, in se, si "limita" ad analizzare il contenuto di un file o di un flusso di dati e ad individuare eventuali virus sulla base del database di firme che viene tenuto aggiornato con freshclam.
La sua natura aperta, comunque, gli permette di essere integrato ed interagire con altri programmi per poter essere utilizzato come antivirus su un server di posta o un file server o per eseguire un check direttamente su dei file specificati.
La modalità di funzionamento è duplice: esiste la possibilità di utilizzare l'engine tramite il comando clamscan
oppure di usufruire del demone clamd
.
clamscan se lanciato senza argomenti fornisce alcune informazioni e statistiche sul numero di virus riconosciuti, se viene seguito dal nome di una directory del file sistem, esegue un check di tutti i file ivi contenuti. Fra le opzioni e gli utilizzi più utili:
clamscan -r /home
Esegue lo scan ricursivo (-r
) di tutto il contentuto della directory /home
clamscan -r /home -l /var/log/antivirus.log
Salva il report dello scan di /home sul file antivirus.log (a video, in standard error, vengono visualizzati tutti i file contollati
clamscan -r /home -i
Stampa a video solo i nomi dei file infetti (oltre al report finale) e quindi risulta decisamente meno verboso.
Il demone clamd può stare in ascolto su una socket Unix (opzione di default: LocalSocket /tmp/clamd
nel file di conf) o, in alternativa, su una porta TCP (opzione TCPSocket 3310
).
Per eseguirlo basta lanciare il comando clamd
. Se si vuole usare un file di configurazione diverso da quello di default si puà usare l'argomento --config-file
, se si vuole abilitare il debug mode usare --debug
Il demone si presta ad integrarsi ed essere usato come filtro da parte di vari programmi esterni ed ha, comunque, un suo client chiamato clamdscan
che ha sostanzialmente le stesse opzioni di clamscan.
Se si ha clamd in esecuzione basta digitare clamdscan /home
, per esempio, per eseguire il controllo dei file in /home.
Notare che quando si usa clamdscan, si accede ai file da controllare tramite clamd per cui l'utente con cui il demone gira (di default clamav) deve averne almeno accesso in lettura.
MODALITA' D'USO
Essendo ClamAV fondamentalmente un filtro, che riceve un file in input e lo rilascia in output dopo aver verificato se contiene virus, i suoi ambiti di utilizzo sono svariati e si integrano con software e soluzioni diversi.
Sendmail Milter
Sendmail ha la possibilità con il supporto milter, di integrarsi con dei filtri che analizzano la mail mentre sta per essere ricevuta (e quindi prima del delivery completo).
Se si compila ClamAv con l'opzione (sono necessarie le librerie di development libmilter):
./configure --enable-milter
dopo la compilazione ci si ritroverà il file /usr/local/sbin/clamav-milter
(se si installa ClamAV tramite un pacchetto, il supporto milter con file clama-milter dovrebbero essere già presenti).
VA quindi configurato sendmail per usare il milter clamav, in /etc/mail/sendmail.mc
aggiungere:
INPUT_MAIL_FILTER(`clmilter',`S=local:/var/run/clmilter.sock,F=, T=S:4m;R:4m')dnl
define(`confINPUT_MAIL_FILTERS', `clmilter')
In clamav.conf
definire:
LocalSocket /var/run/clamd.sock
ScanMail
StreamSaveToDisk
A questo punto, oltre ad riavviare i servizi Sendmail e ClamAv si deve avviare il servizio clamav-milter:
/usr/local/sbin/clamav-milter -lo /var/run/clmilter.sock
Se si è fatta una installazione tramite rpm si avranno i seguenti file chiave:
/etc/rc.d/init.d/clamav-milter Script di gestione del servizio
/etc/sysconfig/clamav-milter File di configurazione con gli argomenti da passare al programma
/usr/sbin/clamav-milter Il binario di clamav-milter
Utilizzo di procmail
A differenza della precedente, in questa modalità il filtro viene fatto sulle mail quando sono state già ricevute dal server SMTP e prima di essere "consegnate", tipicamente tramite procmail, ad una casella postale locale.
Il vantaggio è che procmail di fatto può essere integrato con qualsiasi server SMTP.
Di fatto esistono diverse soluzioni e script che tramite procmail e clamav filtrano la posta. Ne citiamo alcuni:
clamassassin - Ha una logica simile a Spamassassin: la mail viene passata ad uno script perl che usando clam aggiunge un header specifico alle mail infette, le quali vengono poi redirezionate o cancellate, da una seconda regola di procmail.
trashcan - Incluso nel pacchetot ufficiale, si presta in particolare per singole postazioni, non su server di posta.
clamscan-procfilter - Semplcie script perl con una logica simile a quella di Clamassassin
Integrazione con Amavisd-NG
Amavis-Ng è una riscrittura di amavis (http://sourceforge.net/projects/amavis) dopo l'installazione basta scommentare in amavis.conf
la riga:
virus-scanner = CLAM
e eventualmente cambiare il path di clamscan:
[CLAM]
clamscan = /usr/local/bin/clamscan
Altri
Per un elenco completo dei plugin e delle possibilità di interazione di ClamAv con software vari (non soltanto in riferimento alla posta, è possibile anche integrarlo con Samba o con Apache) con relative istruzioni, fare riferrimento alla documentazione HTML ufficiale, nella parte relativa al "Third Party Software"
LINK: Risorse (sftware, pacchetti) correlate a ClamAV - http://clamav.or.id/
LINK: Clam AntiVirus HomePage - http://www.clamav.net
Tipo Infobox: TIPS - Skill Level: 3- INTERMEDIATE - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2004-05-19 18:15:02
Un sistema molto semplice e comunque abbastanza efficace per filtrare una buona quantità di Virus, seppur in modo grossolano, è quello di implementare direttamente a livello di Procmail, senza l'uso di filtri esterni, un meccanismo di controllo per tutte le mail che hanno allegati sospetti.
Ecco come può apparire un /etc/procmailrc
o un $HOME/.procmailrc
:
:0
Si sposta la mail nella casella postale virus (che potrà essere controllata dall'utente POP£ virus
* ^X-Attachments:.*name=".*\.(pif|scr|bat|vbs|vba|lnk|com)" Si controlla il nome dell'attachment e se termina con una delle estensioni riportate (tutte tipiche di alcuni virus e difficilmente usate per scopi legittimi)....
/var/spool/mail/virus
Meccanismi Anti-Spam |
Verifica relay e implementazione di sistemi anti-spam |
Tipo Infobox: TIPS - Skill Level: 2- JUNIOR - Autore: Alessandro 'ask' Nasuti - Ultimo Aggiornamento: 2004-06-04 12:00:59
Esistono in rete strumenti che permettono di verificare le possibilità di relay offerte da un server di posta.
Uno dei metodi più efficaci e utili è offerto dal sito mail-abuse.org che oltre a fornire informazioni varie permette di eseguire un relay test telnettando un server dedicato direttamente dal proprio server di posta:
telnet relay-test.mail-abuse.org
Il server remoto automaticamente visualizza il risultato di una serie di test su varie forme di relay permesse dal server SMTP locale.
Alcune possono essere necessarie (il relay per la ricezione di mail per domini locali) di altri se ne può abusare per l'invio di spam e vanno corrette.
Fra i siti dove è possibile controllare se si è inseriti in qualche Black List di IP usati per inviare spam si segnalano:
http://openrbl.org/ - OpenRBL
Ottimo ed essenziale sito che permette di verificare un indirizzo su molteplici black-list ed ottenere rapidamente altre informazioni come whois/dns lookups
http://moensted.dk/spam/ - drbcheck: dr. Jørgen Mash's DNS database list checker
La lodevole iniziativa di un sysadmin che permette il check di un indirizzo su moltissime liste, alcune delle quali non sono vere e proprie black list (in alcune è normale ritrovarci il proprio indirizzo)
http://ordb.org/ - ORDB
Database pubblico di relay aperti.
http://mail-abuse.org/cgi-bin/lookup - MAPS RBL
Pionieri delle RBL, offrono, commercialmente, l'uso di diverse black list basate su diversi criteri.
http://www.spamcop.net/ - Spam Cop
Altra storica black list, nota, suo malgrado e senza colpe, per essere stata coinvolta in un Hoax, a sua volta diffuso via spam.
LINK: OpenRPL: Ricerca in varie black list - http://openrbl.org/
Tipo Infobox: TIPS - Skill Level: 3- INTERMEDIATE - Autore: Alessandro 'ask' Nasuti - Ultimo Aggiornamento: 2003-05-22 22:39:18
Le versioni di Sendmail dalla 8.9 non permettono di default l'invio di posta (relay) a nessuno tranne localhost.
Su un server SMTP che debba offrire un servizio pubblico si devono configurare gli indirizzi che possono inviare posta e i domini per cui si ricevono email.
Una configurazione troppo aperta su chi può usare il servizio può essere sfruttata per azioni di spam, anche verso terzi, al contempo si ricorre sempre più spesso a Black List con liste di indirizzi IP da cui rifiutare posta.
Nel file /etc/mail/relay-domains
(default) si possono indicare i domini ai quali aprire il relay. Nella configurazione m4 le principali FEATURE per gestire relay e meccanismi antispam sono:
- FEATURE(relay_hosts_only)
In relay-domains si devono specificare tutti i singoli host, invece del solo nome di dominio, a cui aprire il relay
- FEATURE(relay_entire_domain)
Apre al relay tutto il dominio locale del server SMTP
- FEATURE(access_db)
Gestisce l'accesso al server per ogni host inserito nel file /etc/mail/access
(il file ha formato tipo: esempio.com RELAY)
- FEATURE(dnsbl)
Si rifiutano le email provenienti da indirizzi inseriti nella Realtime Blackhole List (RBL), basata su DNS, specificata
SOURCE: Allowing controlled SMTP relaying in Sendmail 8.9 and later - http://www.sendmail.org/tips/relaying.html
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2003-05-23 21:01:25
Quasi tutti sono d'accordo sul fatto che lo SPAM (invio su larga scala di mail non richieste) sia un distrubo, per non dire una piaga, di cui si può volentieri fare a meno e da cui ci si deve difendere.
Tecnicamente è possibile inviare spam utilizzando un qualsiasi server SMTP in rete, che per intrinseca natura permette il RELAY, cioè la possibilità di essere utilizzato per inviare posta, ai suoi client.
I problemi da affrontare, per gli amministratori di un server di posta sono di molteplice natura:
1- Impedire che il proprio server sia utilizzato per inviare spam in rete;
2- Limitare e filtrare il più possibile le mail di spam destinate agli utenti locali;
3- Evitare che il proprio server sia inserito in Black List contenenti indirizzi di server usati per spam di
1- Tipicamente un server di posta viene configurato per permettere il relay sono a client di indirizzi IP o domini specifici o a quelli che si autenticano in qualche modo.
Il problema quindi può venire da qualsiasi utente che è autorizzato ad usare il server e ne abusa consapevolmente, perchè lui è lo spammer, o senza saperlo, perchè vittima di qualcuno o qualcosa che abusa del suo computer.
Questo vale anche e soprattutto per server in rete, anche con tutt'altre funzioni, nel momento in cui vengono violati da un cracker che si mette ad utilizzarli per spammare ferocemente.
A questo proposito buona pratica è:
- Verificare che il proprio server di posta non abbia relay aperti a indirizzi che non siano autorizzati, controllati e considerati fidati (tramite siti web o servizi in rete dedicati, o verifiche da indirizzi arbitrari). Evitare di fare controlli basati su nomi di dominio (manipolabili) e farli solo sulla base degli indirizzi IP sorgenti.
- Limitare sul server il numero massimo di mail che un client può inviare in un dato lasso di tempo. Facendo attenzione a casi in cui l'invio di grandi quantità di messaggi è legittimo (mailing list, newsletter ecc).
- Monitorare le attività di invio di mail, possibilmente con statistiche visuali, che possano velocemente mostrare se ci sono comportamenti anomali ed eccessivi volumi di messaggi.
- Impedire, ovviamente, che qualcuno violi uno dei propri server e lo utilizzi abusivamente per spammare.
2- Le attività volte a limitare l'arrivo di eccessivo spam sulle caselle di posta locali sono altrettanto necessarie.
I metodi di difesa sono vari, il più comodo e diffuso è quello di appoggiarsi ad una o più RBL, black list, mantenute da organizzazioni o società, che contengono elenchi di indirizzi che sono stati utilizzati per l'invio di spam in passato o che si basano su principi diversi (relay aperti, indirizzi IP assegnati a dialup, socks proxy aperti...).
In questo senso considerare che:
- Ci sono diversi metodi per eseguire un controllo su queste liste di indirizzi. Quello più comune è di appoggiarsi ad un server dns che comunica al server di posta se un indirizzo è nella sua black list (DNSBL).
- Non esagerare nell'implementare troppi DNSBL sullo stesso server di posta, soprattutto se questi gestisce grossi volumi: comportano ciascuno una query DNS esterna per ogni messaggio in arrivo.
- Fare attenzione alle Black List che si utilizzano, alcune sono troppo restrittive e limitano la possibilità di ricevere posta da troppi server smtp legittimi: nessuno vuole lo spam, ma molti non sono disposti a perdere mail potenzialmente importanti per difendersene.
- Su server di posta eseguire un controllo sul reverse degli IP da cui arrivano i messaggi. E' una misura che può essere pericolosa (creando falsi negativi e respingendo mail validi da server con DNS misconfigurato) e tuttosommato facilmente bypassabile da chi invece vuole veramente fare spam, per cui va valutata con estrema prudenza.
- Tenere sotto controllo cosa viene regolarmente rifiutato, farsi un'idea dei flussi di posta, sia per capire quanto possano essere efficaci i filtri implementati sia per cercare di verificare se generano falsi negativi.
- Per valutare quali RBL possono fare al proprio caso, verificare le statistiche che si trovano in rete.
Una piuttosto interessante è quella di OpenRBL, che da un'idea di quali RBL sono più aggressive: http://openrbl.org/stats.htm
3- Le stesse black list che si utilizzano per bloccare l'arrivo di posta indesiderata si possono rivelare un'arma a doppio taglio nel momento in cui un PROPRIO server di posta si ritrova su di esse.
Questo può capitare per vari motivi ma di fatto è un problema perchè impedisce al server di offrire un servizio completo ai suoi client, avendo altri server in rete, che utilizzano le black list in cui si è incappati, che rifiutano di accettare la posta, anche legittima, dei propri utenti.
Generalmente tutte le black list permettono di rimuovere un indirizzo, dopo che è dimostrato che non ha più relay aperti e non può essere utilizzato di nuovo per inviare spam. Il problema è che le black list sono molte e che non sempre sono rapide nell'aggiornare i propri database.
Si consiglia di verificare regolarmente gli indirizzi dei propri server di posta su siti che permettono ricerche multiple su diverse liste. Fra questi segnaliamo OpenRBL e DRBcheck
LINK: drbcheck: dr. Jørgen Mash's DNS database list checker - http://www.moensted.dk/spam/
Tipo Infobox: DESCRIPTION - Skill Level: 4- ADVANCED - Autore: lorenzo 'lorenz' urbinati - Ultimo Aggiornamento: 2003-06-30 21:06:44
Una volta configurato il server con i parametri per l'invio, la ricezione e l'inoltro della posta si può prendere in considerazione l'ottimizzazione del servizio e un maggiore controllo delle sue funzioni.
Esistono molte possibilità per definire il comportamento di Postfix e in special modo per controllarne gli accessi, sia da un punto di vista di consumo delle risorse sia dal controllo di cosa può passare e cosa invece no per evitare, ad esempio, l'invio massivo attraverso il server di UCE (Unsolicited Commercial Email) o comunemente SPAM. Per controllare l'invio di SPAM di default l'SMTP-server di Postfix accetta esclusivamente la posta per il network o il dominio locale e per i domini ospiti del server, in modo che dagli estranei non si accetti alcuna connessione. Esistono diversi modi per assumere maggior controllo su questa problematica usando liste di accesso in stile Sendmail o RBL (Real Time Blackhole List) e per un approfondimento si può fare riferimento alla documentazione ufficiale disponibile sul sito di Postfix, www.postfix.org, o nella directory di sistema dedicata alla documentazione dei pacchetti installati.
E' importante inoltre controllare le quantità di posta processabile, ad esempio per limitare il numero di processi contemporanei anche se si dispone di un limite massimo di 1000 client.
default_process_limit = valore
permette di controllare il numero di processi in uscita e in entrata. Di default è settato a 100 ma nel caso di una piccola rete casalinga andrebbe benissimo un valore di 10 mentre per un mail server principale di un provider andrebbe meglio un valore di 1000 o 10000.
Per controllare che il server non sia usato per un attacco tipo DoS o per spam si usano alcune variabili che ai loro valori di default dovrebbero andare benissimo.
initial_destination_concurrency = valore
(default:2)
che controlla quanti messaggi sono inizialmente inviati verso la stessa destinazione prima di attuare un invio multiplo.
local_destination_concurrency_limit = valore
(default:2)
che controlla quanti messaggi sono inviati contemporaneamente allo stesso recipiente locale.
default_destination_concurrency_limit = valore
(default:20)
che impone il limite di messaggi inviabili contemporaneamente alla stessa destinazione.
Ulteriori parametri permettono quanto meno di limitare l'uso del server da parte di client sbadati o maliziosi, rallentando di fatto le loro connessioni fino a chiuderle senza troppi imbarazzi. Il server incrementa un conteggio per sessione degli errori dovuti a richieste da parte dei client non riconosciute valide o sconosciute e di tutte le richieste che in qualche modo violano le regole UCE. Questo conteggio si azzera quando un messaggio viene inviato correttamente. Se il conteggio aumenta il server limita i danni rallentando il client.
Le variabili che controllano queste funzioni sono:
smtpd_error_sleep_time = valore
(va bene il valore di default:1)
che in sostanza cerca di evitare gli errori di un client quando il conteggio è ancora basso ponendo un tempo limite in cui il server resta in pausa mentre comunica l'errore al client.
smtpd_soft_error_limit = valore
di default 10 stabilisce che quando il numero di errori per sessione supera il valore impostato il server attende il valore del conteggio in secondi prima di rispondere ad un'altra richiesta del client.
smtpd_hard_error_limit = valore
di default 20 e stabilisce che al superare nel conteggio del valore impostato il server SMTP taglia la connessione.
SOURCE: Documentazione ufficiale - http://www.postfix.org/docs.html
Tipo Infobox: TIPS - Skill Level: 3- INTERMEDIATE - Autore: Roberto 'rpennol' Pennolino - Ultimo Aggiornamento: 2004-05-15 13:38:41
Lo spam è un fenomeno in crescita esponenziale.
L'uso quotidiano della posta elettronica e di Internet agevola sicuramente questo tipo di "pubblicità indesiderata". Molto spesso le mail di spam provengono da domini che non esistono o che non sono registrati come MX (Mail eXchanger) sui DNS.
Per chi utilizza Sendmail esiste un modo semplice per arginare il problema spam. Basta commentare la riga:
FEATURE(`accept_unresolvable_domains')dnl
che diventa in questo modo:
dnl FEATURE(`accept_unresolvable_domains')dnl
nel file /etc/mail/sendmail.mc
Di default Sendmail accetta posta da qualsiasi dominio, commentando la FEATURE si impone a Sendmail di non accettare mail da domini non risolvibili (di cui non è stato configurato il reverse DNS). Questo intervento, però, irschia di impedre la ricezione di mail da server SMTP validi per i quali non è stato correttamente configurato il DNS.
Fetchmail |
Overview e approfondimenti su fetchmail |
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Massimo 'maxgrante' Caselli - Ultimo Aggiornamento: 2004-06-02 10:00:42
Fetchmail è il più conosciuto software di mail retrieving per Linux, permette di collegarsi a diversi server di posta (POP3, IMAP4, ESMTP ETRN...) per lo scaricamento della mail da molteplici account e di smistare i messaggi sul server locale.
Un grande vantaggio nell'utilizzo di fetchmail è la garanzia che se il messaggio non viene smistato sul proprio MTA locale non viene perso, infatti al prossimo controllo di posta verrà nuovamente scaricato e fetchmail riproverà a smistarlo sino a quando non ci sarà un esito positivo.
Ci sono due modi per utilizzare fetchmail, da linea di comando passando determinati parametri, oppure utilizzando il file di configurazione ~/.fetchmailrc
, che quindi può essere gestito autonomamente da ogni utente del sistema.
AMBITI DI UTILIZZO
Spesso nasce l'esigenza all'interno di un'azienda di dotare tuui i propri dipendenti di posta elettronica per la comunicazione interna e di dover fornire ad altri "privilegiati" anche una mailbox raggiungibile da Internet.
In questi casi si può centralizzare lo scaricamento della posta, configurando i client per scaricare la propria posta esclusivamente da un mail server interno aziendale, dove fetchmail ha provveduto a scaricare la posta dal server di posta pubblico.
Un vantaggio di questo approccio è la possibilità di schedulare lo scaricamento via Internet dalla posta tramite fetchmail e risulta particolarmente utile (anche se in disuso) per società che si connettono ad Internet tramite connessioni dial-up.
Fetchmail inoltre permette di "sfioccare" tutta la mail pervenuta ad un account di posta pubblico (tipicamente un alias per ogni indirizzo di un dominio) in diverse caselle postali locali.
Inoltre, dotare i propri dipendenti di mailbox può causare il fatto che questi ultimi utilizzino la mailbox aziendale anche per scopi privati al di fuori dell'azienda, in tal caso con fetchmail il SysAdmin può attivare svariate mailbox pubbliche senza però fornire la password al dipendente che conoscerà solo quella della propria mail locale, raggiungibile solo dall'interno della rete aziendale.
Il fatto di diventare un punto intermedio fra il client (il comune programma di posta usato dagli utenti) e il server che riceve posta per i proprio domini, lo mette in grado di operare quelle funzioni di filtro (antispam, antivirus, aliasing e filtri custom) che è possibile centralizzare solo quando si ha il controllo del server di posta.
A prescindere dalle motivazioni e le scelte tecniche, Fetchmail di fatto non modifica la logica di configurazione dei client (devono sempre collegarsi ad un server POP3 o IMAP4 per scaricare la posta) e la necessità di avere un server di posta pubblico configurato come MX per i propri domini.
Solitamente Fetchmail si installa sulla stessa macchina in cui viene depositata la posta, per cui su questo sistema deve essere presente un server POP3/IMAP4. Il local delivery può essere fatto tramite un MDA (Sendmail Postfix ecc) o programmi come Procmail.
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Massimo 'maxgrante' Caselli - Ultimo Aggiornamento: 2004-06-02 10:04:20
Fetchmail può essere attivo sul sistema sia come demone, in cui a livello di file di configurazione si definisce ogni quanto tempo scaricare la posta, che in modalità standalone, demandando ad un lancio manuale o a cron le tempistiche di esecuzione.
La scelta di utilizzare l'una o l'altra soluzione è dipendente dal contesto di utilizzo di Fetchmail. Vediamo di seguito due casi dove in uno è meglio usare il software come demone e nell'altro lanciato da crontab.
SERVER LINUX CHE SI CONNETTE AD INTERNET IN DIAL UP
Anche se ormai in disuso Linux è spesso utilizzato come default gateway per reti LAN che lo utilizzano come dial up server per la condivisione della navigazione e il natting dei client/firewall.
In una situazione del genere è consigliabile eseguire Fetchmail da crontab in quanto è possibile impostare non solo il tempo tra un'esecuzione e l'altra ma anche i giorni in cui deve essere eseguito. Es. dal lunedì al venerdì dalle 08.00 alle 19.00
SERVER LINUX CHE SI CONNETTE AD INTERNET TRAMITE CONNESSIONE ALWAYS ON
In una situazione simile è inutile usare fetchmail da crontab ma conviene eseguirlo come demone all'avvio della macchina e lasciarlo in backgroud nel sistema.
Tipo Infobox: PATH - Skill Level: 3- INTERMEDIATE - Autore: Massimo 'maxgrante' Caselli - Ultimo Aggiornamento: 2004-06-02 11:55:52
Quando viene eseguito fetchmail utilizza di default il file di configurazione .fetchmailrc
sito nella home dell'utente. Spesso il file di conf va creato in /root/.fetchmailrc
essendo fetchmail eseguito come utente root, anche se questo può comportare complicazioni in termini di sicurezza.
Scaricamento di account POP3
Di seguito analizziamo brevemente la sintassi del file di configurazione per lo scaricamento di posta da un account POP3:
poll mail.openskills.info with proto POP3 user 'max' there with password 'prova' is maxgrante' here options keep
Analizzando attentamente la sintassi si capisce facilmente che viene settato con poll il server di posta esterno (mail.openskills.info), si specificano utente e password della mailbox remota (max, prova) con il relativo protocollo (POP3) ed infine viene detto a fetchmail a quale mailbox locale inoltrare la mail (maxgrante).
Naturalmente sul nostro server locale deve girare un MTA (sendmail, postfix ecc...) che possa ricevere la mail ed inoltrarla localmente. L'opzione keep dice a fetchmail di non cancellare la copia del messaggio sul server.
Ovviamente si possono aggiungere eventuali altri pop/imap server con i relativi account sulle diverse mailbox remote da far gestire al programma.
Scaricamento di un account multidrop
Uno dei punti di forza di Fetchmail è che può essere utilizzato per dividere la posta destinata ad un singolo account pubblico in diversi account locale.
Un esempio:
poll mail.openskills.info user 'info' there with password 'prova' to pippo pluto 'paperone'='paperino' here
In questo caso viene controllata la casella postale info e la mail viene smistata agli utenti locali pippo, pluto e paperino, considerando che tutta la mail destinata a paperone (sul server remoto) viene redirezionata all'utente paperino locale.
File sharing in una rete locale |
Visione d'insieme sul file sharing in LAN e le alternative possibili |
Tipo Infobox: DESCRIPTION - Skill Level: 1- NOVICE - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2004-06-04 10:26:11
Quasi ogni ufficio ormai ha una rete di computer su cui operano tecnici e impiegati vari.
Generalmente via rete vengono scambiati file e condivise stampanti, anche se ovviamente le applicazioni possono essere molteplici.
Lo scenario di una rete in cui viene fatto file sharing può presentare diverse topologie e logiche:
- Condivisioni distribuite, presente su computer client diversi
- Condivisioni distribuite su diversi file-server
- Condivisione centralizzata su un singolo server
In genere è preferibile centralizzare su uno o più file server tutti i documenti aziendali che vanno condivisi. Questo facilità le operazioni di backup, l'omogeneità e l'integrità delle informazioni, la gestione di permessi sugli accessi.
Dato per assodato che in ufficio medio, tutti i documenti dovrebbere risiedere su un server centrale, che, a partire dalla scheda di rete utilizzata, dovrebbe avere dell'hardware adeguato al suo ruolo, resta da definire il protocollo con cui condividerli.
Se si lavora in un ambiente Unix, dove Unix sono sia i server che le workstation, l'uso di NFS sembra la scelta logica.
Se, più probabilmente, si lavora su una rete per gran parte composta da client Windows, è più logico utilizzare il protocollo CIFS/SMB su cui nativamente si appoggiano le reti Windows.
In questo caso il server centrale può comunque essere una macchina Unix/Linux con Samba e dovrebbe diventare almeno un WINS server per la rete locale, aumentando decisamente la velcoità di browsing delle risorse di rete senza particolari complicazioni in termini di configurazione e setup.
Se i client sono tutti almeno Windows 2000, XP o successivi, esiste la possibilità di accedere al file server centrale via WebDAV, soluzione particolarmente interessante nei casi in cui i file condivisi debbano essere raggiungibili anche via browser (HTTP).
Se la rete è unicamente basata su Mac, AppleTalk o AFS sono la soluzione semplice ed immediata.
Se si lavora in un ambiente Novell, si può considerare Netware su un server centrale, sapendo che il supporto sui vari sistemi operativi è disponibile.
Quando invece si ha a che fare con reti miste, dove sia client che server montano sistemi operativi diversi, gli scenari si allargano e diventano meno definiti. In genere, tramite funzionalità native o programmi di terze parti, con qualsiasi sistema operativo recente si è in grado di utilizzare tutti i protocolli utilizzati, per cui ogni caso richiederebbe valutazioni specifiche.
Una raccomandazione di massima, in questi casi, è comunque la centralizzazione dei dati su un server centrale, a cui accedere via IP utilizzando uno dei protocolli citati (quello supportato nativamente dalla maggior parte dei client, in linea di massima).
Tipo Infobox: DESCRIPTION - Skill Level: 1- NOVICE - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2004-06-04 10:26:48
Per valutare quale soluzione di file sharing scegliere sulla propria rete locale è opportuno valutare cosa viene offerto e supportato sui sistemi operativi da desktop più comuni sul mercato.
WINDOWS
Su tutti i sistemi Microsoft, da Windows 3.11 in poi, è nativo il supporto di CIFS/SMB che è il protocollo utilizzato sulle normali Reti Windows che si possono browsare da Explorer o Gestione Risorse.
Il supporto NFS è previsto o tramite software di terze parti (in genere a pagamento) o con il Windows Services for Unix CD per Win2000 di Microsoft.
Il supporto AppleShare e Novell è nativo in Windows (i driver non vengono installati di default e su XP AppleTalk non è più supportato).
MAC
Sul mondo Apple va fatta una distinzione.
Mac OS X supporta nativamente praticamente tutto: SMB/CIFS, Novell, NFS, AppleTalk, WebDAV, su Mac OS precedenti il supporto per protocolli di rete non Apple non è sempre nativo e in alcuni casi ci si deve rivolgere a prodotti di tezri.
LINUX
Il supporto per tutti i file system di rete noti è presente anche se non sempre viene attivato sulle installazioni di default. Samba per SMB/CIFS, netaTalk per Apple Talk, un server NFS e Novell permettono a Linux di operare sia come client che come server in ambienti di rete eterogenei.
A livello pratico l'implementazione di alcuni servizi non è sempre semplicissima.
UNIX
In genere tutto il software opensource disponibile su Linux è compilabile su qualsiasi dialetto Unix, per cui vale quanto detto per Linux.
Tipo Infobox: DESCRIPTION - Skill Level: 1- NOVICE - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2004-06-04 09:53:35
Quando le prime reti di computer iniziarono ad affermarsi negli uffici e negli ambienti lavorativi, il principale utilizzo che se ne faceva era la condivisione dei file fra i diversi computer, permettendo agli utenti di lavorare sugli stessi documenti senza doverseli "scambiare" con mezzi molto meno efficaci (floppy disk e analoghi).
La condivisione dei file, pur essendo una delle prime applicazione pratiche in una rete locale, resta un punto chiave per l'ottimizzazione dei processi e dei flussi informativi dentro un'azienda.
Oltre a rendere più comodi e rapidi gli scambi di informazione dentro un'azienda, comporta una serie di problematiche che si legano direttamente alle funzionalità che fornisce.
La sicurezza in tutte le sue sfaccettature è la più importante:
se un file può essere accessibile via rete, si deve prevedere un meccanismo di controllo su chi può leggerlo, chi può modificarlo e chi non deve nemmeno sapere che esiste.
Se lo stesso file è usato contemporaneamente da più persone si devono evitare sovrascritture o di dati o incongruenze e, nello stesso momento, assicurarsi che tutti lavorino sulla stessa copia, e non ci siano altre copie in giro che possano avere livelli di aggiornamento incoerenti.
La riservatezza dei documenti viene gestita tipicamente vincolando l'accesso ai dati all'inserimento di una login e una password, che permettono di identificare l'utente e quali permessi ha sul file.
Il backup dei file condivisi è ovviamente fondamentale e risulta molto più comodo da gestire se tutti i file vengono condivisi su un server centrale. E' generalmente una pessima idea lasciare che i singoli utenti condividano file direttamente dalle loro macchine.
La disponibilità dei documenti è fondamentale nel momento in cui gli utilizzatori non possono più accedere agli stessi (per problemi hardware, di rete, di applicativo ecc.) e si vedono limitati nella loro possibilità di lavorare.
Tutte queste componenti vanno considerate nell'implementare una infrastruttura di file sharing in grado di rispondere alle esigenze richieste, e sono da dimensionare sulla base dei livelli di criticità dei volumi di traffico previsti.
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2003-06-08 00:04:34
La funzione di un file server è ovviamente quella di mettere a disposizione e condividere via rete file di varia natura a client eterogenei.
La modalità di condivisione può presentare una varietà di situazioni che vanno valutate:
- Protocollo di file sharing
Se ne possono usare diversi, volendo si possono anche usare contemporaneamente in modo da condividere tramite vie diverse la stessa directory locale. In linea di massima in un ambiente prevalentemente basato su client Windows la scelta d'obbligo è SMB, se i client sono Unix è più comodo NFS. Se il parco macchine è piuttosto eterogeneo (Windows, Max, Unix...) probabilmente SMB risulta la soluzione più comodamente implementabile.
Se i file vanno consultati solo in lettura, ha senso considerare l'uso di un server web, che permetta il browsing fra le directory e risulta particolarmente comodo in quanto a supporto di client eterogenei.
Se c'è una necessità di accesso anche in scrittura si può considerare WebDAV, ma solo se i client lo supportano.
- Password e gestione degli accessi
In ambienti reali l'accesso ai file richiede generalmente una login e una password e spesso è necessario gestire diverse login contemporaneamente con diversi livello di accesso ai file.
In questo senso è utile prevedere, in ambienti business, diversi gruppi, dai nomi generici relativi alle funzioni e alle categorie del caso (es: contabilità, magazzino, commerciale, direzione, produzione e via dicendo). Ad ogni gruppo è quindi possibile aggiungere i singoli membri, possibilmente identificati con nome e cognome, con password che hanno una scadenza e divisione dei file in directory basate su potenziali gruppi di accesso (gestire i diritti di accesso al livello di singoli file e non di directory può diventare piuttosto scomodo)
E' logico aspettarsi che un singolo utente possa far parte di più gruppi e che ci siano gruppi a loro volta composti da altri gruppi di utenti.
La logica con cui si possono scegliere i gruppi, i diritti di accesso in lettura o scrittura a date directory, la divisione stessa dei file in directory dipende dai contesti particolari ma va studiata sulla base delle esigenze attuali e di quelle prevedibili per il futuro.
- Struttura di rete
Un file server tipicamente deve gestire un traffico di rete superiore alla media, per cui anche la struttura del network in cui si trova deve essere adeguatamente disegnata.
La porta di rete a cui viene collegato il server dovrebbe essere la più performante possibile (100Mbit o 1Gbit), scelta su uno switch centrale, che possa essere ugualmente accessibile da parte degli hub o degli switch perimetrali. Il link dovrebbe essere full duplex e senza errori, il cavo di rete, come qualsiasi componente fisico del file server, dovrebbe essere in un modo fisicamente protetto e riparato.
- Hardware
Il sistema su cui gira un file server dovrebbe essere ragionevolmente protetto e ridondato, dal momento che questa funzione è spesso critica in una azienda. La ridondanza, che non esclude un valido meccanismo di backup, può venire fatta tipicamente a livello degli hard disk, con un RAID 1 o un RAID 5 e, in casi particolarmente critici, utilizzando un cluster.
Su un file server le componenti solitamente più sotto pressione sono gli hard disk (per questo è consigliabile valutare l'uso di hard disk SCSI) e il network (schede di rete almeno a 100Mbit). Memoria, soprattutto, e CPU vanno dimensionate rispetto alle proprie esigenze.
Di memoria, come sempre, più ce n'è e meglio è: secondo il Samba team sono necessari circa 460 Kb di memoria per ogni client che si collega ad un Samba 2.2.5 (su Windows 2000 bastano circa 330 Kb).
Se la memoria e il resto delle risorse bastano, Samba scala meglio di Windows quando molti client (più di 50) contemporaneamente accedono al server: il troughtput compessivo rimane tendenzialmente stabile senza decadere eccessivamente.
La CPU va dimensionata al carico e in certe situazioni può essere raccomandabile un sistema biprocessore rispetto ad uno, a parità di potenza di calcolo, a singola CPU: più processori degradano meno le performance del sistema quando è sotto stress.
Tendenzialmente un file server particolarmente utilizzato non dovrebbe svolgere altre funzioni, almeno di giorno, quando si presume debba svolgere gran parte della sua attività.
I dati condivisi dovrebbero stare su uno o più hard disk separati, rispetto a quelli dove sono presenti i file di sistema. Se questo non è possibile, prevedere almeno l'uso di partizioni distinte.
- Backup
Il backup dei file condivisi da un file server è fondamentale. Il supporto su cui viene fatta la copia dovrebbe essere rimuovibile (harddisk, nastri ecc.) e regolarmente portato in località remote. Si può prevedere un server che svolga la duplice funzione di backup dei dati e di macchina di standby, da attivare in tempi rapidi (automaticamente o in modo manuale) in caso di guasti del server principale.
- Sicurezza
Un file server per natura è una macchina delicata che può contenere file e documenti riservati. E' altamente improbabile che un simile sistema debba stare su IP pubblico, per cui sia il suo IP, sia gli IP dei suoi client, dvrebbero appartenere ad una rete privata.
L'accesso a tutti i documenti che non siano di pubblico dominio dovrebbe avvenire tramite password (non è il caso di regalare fiducia incondizionata a chiunque abbai accesso fisico alla rete locale).
A livello di host security, si dovrebbero disattivare tutti i servizi inutilizzati e mantenere aggiornati almeno quelli che ascoltano su porte raggiungibili via rete. Avere un sistema su una rete interna lo rende ragionevolmente sicuro da attacchi direttamente dall'esterno, ma non da attacchi perpetrati da host locali.
Se possibile evitare anche che il file server possa accedere ad Internet, semplicemente non impostandogli un default gateway: gli aggiornamenti del software, l'uso di mail e DNS e varie altre operazioni che richiedono la rete possono appoggiarsi ad altri server interni.
- Logging
A parte i meccanismi di logging di sistema, volti ad individuare eventuali problemi hardware, software o di sicurezza, può aver senso loggare ogni accesso, quantomeno in scrittura, sui file condivisi.
Nel log dovrebbe comparire il nome dell'utente che ha modificato o scritto un file.
I log vanno, come sempre, ruotati e archiviati, per evitare che crescano a dismisura andando ad esaurire lo spazio su disco.
Il protocollo CIFS/SMB |
Common Internet File System / Server Message Block |
Tipo Infobox: DESCRIPTION - Skill Level: 3- INTERMEDIATE - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2006-02-28 14:31:06
Quando si parla di NetBios, NetBEUI e SMB si rischia spesso di far confusione fra protocolli, livelli di applicazione, definizione e contesti. Non è un caso, questi sono argomenti di fatto anomali, nel mondo del networking, che si trascinano dietro due decenni di utilizzi in rete e relative implementazioni.
Cerchiamo di chiarire le cose a grandi linee, in modo da poter meglio individuare gli argomenti che ci interessano e contestualizzarli correttamente.
NetBios strettamente parlando più che un protocollo è un interfaccia di programmazione (API) fatta sviluppare da IBM nel 1983 per permettere a delle applicazioni di comunicare scambiandosi file e messaggi sui PC network del tempo, che avevano un basso numero di host e non prevedevano ancora l'uso del protocollo IP (già presente ma usato più su WAN che in LAN) per le comunicazioni di rete.
Con l'introduzione di Token Ring, IBM nel 1985 definì delle estensioni a NetBios (NetBIOS Extended User Interface NetBEUI) che permettevano di appoggiarsi ad un data-link 802.2 (Token Ring o Ethernet).
Microsoft ha iniziato ad usare NetBEUI come protocollo di rete su Windows for Workgroup (Windows 3.1) e poi su tutte le versioni successive ma, al contempo, con la diffusione di Novell IPX e di IP, si è iniziato a veicolare NetBios anche su IPX e IP, oltre che su altri protocolli.
E' quindi possibile trovare NetBios (tipicamente proposto come protocollo a livello di sessione) nella sua incarnazione originaria, come NetBIOS Frames Protocol (NBF) detto anche semplicemente NetBios o NetBEUI, che copre i livelli di network e trasporto, oppure incapsulato su IPX o TCP/IP con questi ultimi a gestire il network e transport layer e NetBios posizionato come session layer.
Il protocollo Server Message Block (SMB) e il suo derivato Common Internet File System (CIFS) agiscono a livello applicativo, direttamente su NetBEUI, NetBios su IPX o NetBios su IP (chiamato anche NBT o NetBT), CIFS, invece, nelle sue recenti versioni può anche essere trasportato direttamente dal TCP/IP, senza layer NetBios intermedio.
Caratteristiche di NetBios
L'indirizzamento di NetBios è flat, basato sul semplice nome di un host (generalmente fino a 15 caratteri) e senza elementi gerarchici (come il DNS) che di fatto lo rendono inadatto per gestire il routing fra network diversi. Il nome NetBios è lo stesso che viene utilizzato dai procotolli superiori come SMB/CIFS.
Per impedire che due host nella stessa rete abbiamo lo stesso nome viene utilizzato il protocollo Name Management Protocol (NMP), tramite il quale, a colpi di broadcast, un host annuncia la sua presenza in rete e avverte quando un nuovo host con lo stesso nome prova ad apparire.
Nella comunicazione fra host si usano lo User Datagram Protocol (UDP, diverso dall'UDP usato su IP), unreliable e basato su datagrammi fino a 512 byte e il Session Management Protocol (SMP), bidirenzionale, reliable e basato su sessioni che vengono stabilite fra due host. Meccanismi di controllo e di monitoring vengono gestiti dal Diagnostic and Monitoring Protocol (DMP).
Attualmente la forma maggiormente utilizzata è quella di NetBios incapsulato su TCP/IP (NetBios over TCP/IP o NBT). Questo standard è definito nelle RFC 1001 e RFC 1002 dove si affrontano le problematiche relative all'associazione di un nome di host ad un indirizzo IP (broadcast o server di nomi centralizzato) e i metodi di comunicazione (a datagrammi o a sessioni).
Le porte utilizzate per questi servizi sono:
netbios-ns 137/udp # NETBIOS Name Service
netbios-dgm 138/udp # NETBIOS Datagram Service
netbios-ssn 139/tcp # NETBIOS Session Service
Gestione dei nomi su NetBios
I nomi di host di NetBios su TCP/IP (che coincidono con i nomi SMB) possono essere registrati (annunciati) e risolti (trovati) sul network locale sia tramite broadcast che tramite un server di nomi centralizzato (NBNS NetBios Name Server, su sistemi Windows l'implementazione di un NBNS è il WINS server) che risulta, soprattutto su reti affollate, molto più efficace.
A seconda di come un host è configurato per gestire i nomi assume un tipo di nodo diverso:
b-node - Host che usa solo broadcast per la risoluzione e la registrazione degli host name.
p-node - Host che usa un server centrale (comunicazione point-to-point) per risoluzione e registrazione
m-node - Host che usa broadcast per la registrazione e la risoluzione, inoltre se porta a termine con successo una registrazione lo notifica ad un server NBNS, che viene usato anche quando la risoluzione via broadcast non ha successo.
h-node (hybrid) - Host che usa un server NBNS per risoluzione e registrazione dei nomi e, nel caso in cui il server NBNS non sia disponibile utilizza i broadcast. Questa modalità è stata introdotta da Microsoft, non appare nelle RFC 1001 e 1002.
Il tipo di nodo, su Windows, è visibile nell'output del comando ipconfig /all
dove si parla di NodeType
I nomi possono essere lunghi 15 caratteri (byte) e contenere caratteri alfanumerici standard ( a-z, A-Z, 0-9, ! @ # $ % ^ & ( ) - ' ). Il sedicesimo e ultimo byte indica il tipo di risorsa, a seconda del valore esadecimale indicato corrisponde una diversa risorsa, alcuni esempi:
00 - Normale workstation
03 - Servizio di messaggistica (WinPopup)
1B - Domain Master Browser
20 - Fileserver
NetBios inoltre prevede il concetto di gruppo (i Workgroup in ambiente Windows).
Principi di SMB
SMB è un protocollo di livello applicativo utilizzato per la condivisione di directory fra computer, la stampa via rete e lo scambio di file e messaggi. Si basa su una struttura client-server ed ha una logica di tipo request-response. Dalla sua introduzione originaria ha subito varie modifiche e varianti che modificano e aggiungono nuovi SMB (Server Message Blocks, di fatto i "comandi" utilizzabili). Su Windows 95 e NT per esempio viene utilizzata la variante NT LM 0.12, che viene supportata, fra gli altri, anche da Samba, un implementazione OpenSource del protocollo che è utilizzabile su gran parte degli Unix in circolazione.
SOURCE: NetBios, NetBEUI, NBF, SMB, CIFS Networking - http://ourworld.compuserve.com/homepages/timothydevans/contents.htm
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2003-03-25 16:09:46
Microsoft utilizza NetBios e SMB come protocolli di rete per condividere risorse su Windows fin da Windows 3.1. Rispetto alle versioni esistenti di questi protocolli ha introdotto alcune estensioni proprietarie:
- Domini Windows
- Browsing
- Server WINS
I Domini Windows
Fondamentalmente un dominio Windows è un workgroup con un server che agisce come Domain Controller con funzioni di autenticazione centralizzata per l'accesso alle risorse (file, stampanti, login sul sistema...) da parte tutti gli host che fanno parte del dominio.
Vengono usati protocolli differenti per Windows 95/98, Windows NT e Windows 2000 (dove il concetto di dominio viene ulteriormente allargato con le Active Directory).
Il Primary Domain Controller (PDC) è il server che mantiene un database di tutte le password (SAM): quando un client cerca di accedere alle risorse di un server, quest'ultimo verifica sul PDC se login e password fornite sono valide. Se questo accade al client viene permesso l'accesso alle risorse richieste e fornito un token di autenticazione con cui automaticamente riesce ad accedere ad altre risorse in rete accessibili dalla stessa login.
Il database delle password viene automaticamente copiato ad uno o più Backup Domain Controller (BDC) che possono essere utilizzati per autenticare i clinet nel caso in cui i PDC risulti inaccessibile.
Browsing
Per rendere più rapida l'individuazione degli host e delle risorse in una rete locale, Microsoft ha introdotto il Local Master Browser un computer che ha il ruolo di mantenere la lista degli host in rete (browse list) e che fa da riferimento per tutte le richieste e gli aggiornamenti da parte delle altre macchine in rete.
Praticamente ogni macchina Windows può agire da Local Master Browser o da Backup Browser (host che riceve la browse list da un Master Browser e viene utilizzata in caso di inagibilità di quest'ultimo). Queste funzionalità vengono definite automaticamente dagli host NetBios in una rete locale tramite una procedura chiamata elezione in cui tutti gli host partecipano tramite broadcast. A seconda del sistema operativo, della versione di protocollo utilizzata, del tempo di uptime nella rete e del nome dell'host viene automaticamente deciso chi deve operare come Master Browser e questo rimane tale fino a quando resta connesso o un nuovo host con migliori credenziali si aggiunge alla rete.
Quando si clicca, in Windows, su Risorse di Rete di fatto si ottiene dal Master Browser la browse list degli host in rete (notare che questa potrebbe essere non perfettamente aggiornata, con alcuni host che risultano presenti anche se magari sono spenti o disconnessi e non hanno avuto modo di comunicarlo al Master Browser), quando si clicca sul singolo host si ottiene l'elenco delle sue risorse condivise.
Server WINS
Il Windows Internet Name Service (WINS) è l'implementazione Microsoft di un NetBios Name Server (NBNS) che ha la funzione di mantenere la lista dei nomi NetBios degli host in rete e dei relativi indirizzi IP. Ovviamente questo serve quando si usa NetBios over TCP/IP ed è una soluzione consigliabile quando si ha una rete medio grande o si devono connettere workgroup presenti su network IP differenti.
Anche in questo caso, oltre ad un Primary Wins Server possono esistere uno o pià Secondary Wins Server con funzioni di ridondanza e backup.
Installazione e gestione di Samba |
Installazione di Samba tramite RPM e sorgenti, file installati e posizioni - Gestione del servizio |
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Giorgio 'neo' Colombo - Ultimo Aggiornamento: 2004-06-04 10:57:16
Installazione step by step di samba attraverso i pacchetti RPM e la compilazione dei sorgenti.
TAR.GZ - COMPILAZIONE DEI SORGENTI:
- Download dei sorgenti
Si scarica il tar.gz di Samba dal sito ufficiale o uno dei suoi mirror:
root@SATURNO root]# wget ftp://it.samba.org/pub/samba/samba-latest.tar.bz2
--16:45:01-- ftp://it.samba.org/pub/samba/samba-latest.tar.bz2
=> `samba-latest.tar.bz2'
Resolving it.samba.org... done.
Connecting to it.samba.org[217.56.103.6]:21...
[...]
- Scompattazione sorgenti
[root@SATURNO root]# tar -jxvf samba-latest.tar.bz2
[..]
[root@SATURNO root]# cd samba-2.2.8/
[root@SATURNO samba-2.2.8]# ls -l
total 102
-rw-r--r-- 1 783 783 17982 May 4 1996 COPYING
Directory contenente documentazione di vario genere e in vari formati
drwxr-xr-x 10 783 783 1024 Feb 5 17:24 docs
Directory contenente esempi di file di configurazione oltre a tools o script per la gestione della configurazione di samba
drwxr-xr-x 16 783 783 1024 Mar 15 05:28 examples
-rw-r--r-- 1 783 783 4551 Apr 30 2002 Manifest
Directory contenente files di configurazione e relativi script per la creazione di package per vari OS e distribuzioni di Linux
drwxr-xr-x 15 783 783 1024 May 3 2002 packaging
Directory contenente sorgenti di un semplice monitoring della shared memory
drwxr-xr-x 2 783 783 1024 May 3 2002 pcp
-rw-r--r-- 1 783 783 0 Aug 21 1997 Read-Manifest-Now
-rw-r--r-- 1 783 783 8412 Feb 28 16:56 README
-rw-r--r-- 1 783 783 1894 Apr 14 2001 Roadmap
Directory contenente i sorgenti
drwxr-xr-x 33 783 783 1024 Mar 15 05:28 source
Directory contenente il tool swat per la configurazione di samba via web
drwxr-xr-x 5 783 783 1024 Mar 15 05:28 swat
Directory contenente, script, sorgenti e altro per eseguire alcuni test su samba
drwxr-xr-x 9 783 783 1024 Mar 15 05:28 testsuite
-rw-rw-r-- 1 783 783 59481 Mar 15 05:44 WHATSNEW.txt
-Compilazione sorgenti
La compilazione dei sorgenti avviene come nella maggior parte dei casi con il lancio dello script configure per il settaggio di alcuni parametri e il comando make per la compilazione e installazione dei sorgenti.
[root@SATURNO samba-2.2.8]# cd source/
Per richiamare l'elenco delle opzioni e la relativa spiegazione, lanciare il seguente comando:
[root@SATURNO source]#./configure --help
Di seguito sono riportate le opzioni con relativa spiegazione utilizzati per la creazione dell' RPM per la distribuzione redhat.
Imposta il prefisso del path di installazione
--prefix=%{prefix} \
Imposta la directory ove il sistema scrive tutte quelle informazioni come log, pidfile etc.
--localstatedir=/var \
Imposta la directory contenente tutti i file di configurazione
--with-configdir=/etc/samba \
Specifica la directory ove viene messo smbpasswd
--with-privatedir=/etc/samba \
Specifica la directory dove risiedono i code page files
--with-codepagedir=/etc/codepages \
Abilita l'uso dei path fhs-compliant
--with-fhs \
Abilita il supporto per quota
--with-quotas \
Include il supporto per MS Dfs
--with-msdfs \
Abilita il supporto per smbmount
--with-smbmount \
Abilità il supporto per l'uso di PAM password database
--with-pam \
Include anche il modulo smbpass
--with-pam_smbpass \
Abilita il supporto del logging via syslog
--with-syslog \
Include utmp accounting
--with-utmp \
Specifica dove vengono installati i file riguradanti a swat
--with-sambabook=%{prefix}/share/swat/using_samba \
--with-swatdir=%{prefix}/share/swat \
Abilita la compilazione delle librerie dinamiche del client
--with-libsmbclient
[root@SATURNO source]# ./configure --prefix=/usr \
--localstatedir=/var \
--with-configdir=/etc/samba \
--with-privatedir=/etc/samba \
--with-codepagedir=/etc/codepages \
--with-fhs \
--with-quotas \
--with-msdfs \
--with-smbmount \
--with-pam \
--with-pam_smbpass \
--with-syslog \
--with-utmp \
--with-sambabook=/usr/share/swat/using_samba \
--with-swatdir=/usr/share/swat
[...]
checking for poptGetContext in -lpopt... yes
checking whether to use included popt... no
checking configure summary... yes
updating cache ./config.cache
creating ./config.status
creating include/stamp-h
creating Makefile
creating script/findsmb
creating include/config.h
Compilazione dei sorgenti
[root@SATURNO source]# make
Using FLAGS = -O -Iinclude -I./include -I./ubiqx -I./smbwrapper -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -DLOGFILEBASE="/var/log/samba" -DCONFIGFILE="/etc/samba/smb.conf" -DLMHOSTSFILE="/etc/samba/lmhosts" -DSWATDIR="/usr/share/swat" -DSBINDIR="/usr/sbin" -DLOCKDIR="/var/cache/samba" -DCODEPAGEDIR="/etc/codepages" -DDRIVERFILE="/etc/samba/printers.def" -DBINDIR="/usr/bin" -DPIDDIR="/var/run/samba" -DLIBDIR="/usr/lib" -DHAVE_INCLUDES_H -DPASSWD_PROGRAM="/usr/bin/passwd" -DSMB_PASSWD_FILE="/etc/samba/smbpasswd" -DTDB_PASSWD_FILE="/etc/samba/smbpasswd.tdb"
[...]
Installazione
[root@SATURNO source]# make install
[...]
INSTALLAZIONE TRAMITE RPM
L'installazione completa di samba via rpm richiede più package scaricabili da repository come http://www.rpmfind.net oppure nel caso di Redhat ci si può appoggiare anche al suo repository di errata.
Supponiamo di aver scaricato i seguenti RPM:
Package principale contenente documentazione, manuali e binari per attivare il servizio.
samba-2.2.7-4.8.0.i386.rpm
Package contenente le utility e relativi manuali per il mounting delle share
samba-client-2.2.7-4.8.0.i386.rpm
Package contenente file di necessari sia al client che al server come l'utility smbpasswd o le code pages
samba-common-2.2.7-4.8.0.i386.rpm
Utility per la configurazione di samba via web
samba-swat-2.2.7-4.8.0.i386.rpm
Installazioe di tutti i vari rpm relativi a samba
[root@SATURNO root]# rpm -ihv samba-*.rpm
warning: samba-2.2.7-4.8.0.i386.rpm: V3 DSA signature: NOKEY, key ID db42a60e
Preparing... ########################################### [100%]
1:samba-common ########################################### [ 25%]
2:samba ########################################### [ 50%]
3:samba-client ########################################### [ 75%]
4:samba-swat ########################################### [100%]
Visualizzazione di ciò che i vari rpm hanno installato
[root@SATURNO root]# rpm -qil samba
[...]
File di configurazione per logrotate
/etc/logrotate.d/samba
File di configurazione per PAM
/etc/pam.d/samba
Script di gestione del servizio
/etc/rc.d/init.d/smb
File contenente la correlazione unix_name e smb_name
/etc/samba/smbusers
File contenente le opzioni passate ai vari demoni
/etc/sysconfig/samba
Uility per la creazione di file unicode per samba
/usr/bin/make_unicodemap
Script relativo alla gestione del file smbpasswd
/usr/bin/mksmbpasswd.sh
Script per la gestione degli utenti samba
/usr/bin/smbadduser
/usr/bin/smbcontrol
/usr/bin/smbstatus
/usr/bin/tdbbackup
Librerie e file header
/usr/include/libsmbclient.h
/usr/lib/libsmbclient.a
/usr/lib/samba/vfs
/usr/lib/samba/vfs/recycle.so
Binari relativi ai demoni
/usr/sbin/nmbd
/usr/sbin/smbd
Documnetazione
/usr/share/doc/samba-2.2.7
/usr/share/doc/samba-2.2.7/COPYING
/usr/share/doc/samba-2.2.7/LDAP
/usr/share/doc/samba-2.2.7/LDAP/README
/usr/share/doc/samba-2.2.7/LDAP/export_smbpasswd.pl
/usr/share/doc/samba-2.2.7/LDAP/import_smbpasswd.pl
/usr/share/doc/samba-2.2.7/LDAP/ldapchpasswd
/usr/share/doc/samba-2.2.7/LDAP/ldapsync.pl
[...]
Manuali
/usr/share/man/man1/make_unicodemap.1.gz
/usr/share/man/man1/smbcontrol.1.gz
/usr/share/man/man1/smbstatus.1.gz
/usr/share/man/man5/smbpasswd.5.gz
/usr/share/man/man7/samba.7.gz
/usr/share/man/man8/nmbd.8.gz
/usr/share/man/man8/pdbedit.8.gz
/usr/share/man/man8/smbd.8.gz
Directory di appoggio
/var/cache/samba
/var/log/samba
/var/run/samba
/var/spool/samba
[root@SATURNO root]# rpm -qil samba-common
[...]
Script di gestione del demone windbind
/etc/rc.d/init.d/winbind
File di configurazione
/etc/samba
/etc/samba/lmhosts
/etc/samba/smb.conf
Librerie dinamiche
/lib/libnss_winbind.so
/lib/libnss_winbind.so.2
/lib/libnss_wins.so
/lib/libnss_wins.so.2
/lib/security/pam_winbind.so
utility e binari di vario genere per l'amministrazione del servizio e degli utenti di samba
/usr/bin/make_printerdef
/usr/bin/make_smbcodepage
/usr/bin/smbpasswd
/usr/bin/testparm
/usr/bin/testprns
/usr/bin/wbinfo
/usr/sbin/winbindd
Manuali
/usr/share/man/man1/make_smbcodepage.1.gz
/usr/share/man/man1/testparm.1.gz
/usr/share/man/man1/testprns.1.gz
/usr/share/man/man1/wbinfo.1.gz
/usr/share/man/man5/lmhosts.5.gz
/usr/share/man/man5/smb.conf.5.gz
/usr/share/man/man8/smbpasswd.8.gz
/usr/share/man/man8/winbindd.8.gz
Directory contenente i codepages
/usr/share/samba
/usr/share/samba/codepages
[...]
[root@SATURNO root]# rpm -qil samba-client
[...]
links a /usr/bin/smbmount,binario per il mounting delle share
/sbin/mount.smb
/sbin/mount.smbfs
Utility per l'interrogazione del server smb e per il mountig delle share
/usr/bin/nmblookup
/usr/bin/rpcclient
/usr/bin/smbcacls
/usr/bin/smbclient
/usr/bin/smbmnt
/usr/bin/smbmount
/usr/bin/smbprint
/usr/bin/smbspool
/usr/bin/smbtar
/usr/bin/smbumount
Manuali
/usr/share/man/man1/nmblookup.1.gz
/usr/share/man/man1/rpcclient.1.gz
/usr/share/man/man1/smbcacls.1.gz
/usr/share/man/man1/smbclient.1.gz
/usr/share/man/man1/smbtar.1.gz
/usr/share/man/man8/smbmnt.8.gz
/usr/share/man/man8/smbmount.8.gz
/usr/share/man/man8/smbspool.8.gz
/usr/share/man/man8/smbumount.8.gz
Per la gestione del servizio ci si può appoggiare allo script: /etc/init.d/smb, specificando come parametro l'azione da eseguire, esempio start, stop o restart.
Opzioni disponibili:
- start : Avvia il servizio smb
- stop : killa i processi smb
- restart : Esegue in successione stop e start
- reload : esegue il reload del file di configurazione
- status : visualizza lo status dei demoni
- condrestart : Esegue il restart del servizio
Per richiamare le singole opzioni utilizzabili lanciare lo script senza argomenti
[root@SATURNO root]# /etc/init.d/smb
Usage: /etc/init.d/smb {start|stop|restart|reload|status|condrestart}
Esempi di avvio, restart e stop
[root@SATURNO root]# /etc/init.d/smb start
Starting SMB services: [ OK ]
Starting NMB services: [ OK ]
[root@SATURNO root]# /etc/init.d/smb restart
Shutting down SMB services: [ OK ]
Shutting down NMB services: [ OK ]
Starting SMB services: [ OK ]
Starting NMB services: [ OK ]
[root@SATURNO root]# /etc/init.d/smb stop
Shutting down SMB services: [ OK ]
Shutting down NMB services: [ OK ]
Tipo Infobox: COMMANDS - Skill Level: 3- INTERMEDIATE - Autore: lorenzo 'lorenz' urbinati - Ultimo Aggiornamento: 2003-05-31 21:25:07
La suite Samba risulta essere veramente ricca di tools e script per la configurazione gestione e uso dei suoi servizi, uno di questi è molto utile per verificare prima di lanciare il demone che tutto sia a posto all'interno del file di configurazione.
testparm esegue un controllo sul file di configurazione specificato che per default, se si è installato dai sorgenti è dir_samba/lib/smb.conf
, dopo di che se è tutto ok stampa a monitor "Loaded services file OK." più qualche informazione ulteriore e dopo aver premuto [enter] mostra tutti i settaggi e come sono configurati.
La sua sintassi:
testparm [opzioni] path_file_conf [hostname indirizzo_IP]
Per l'ultimo campo quando si specifica l'hostname va sempre specificato anche l'indirizzo IP e in questo modo si effettua una verifica dei parametri host allow
e host deny
nel smb.conf per verificare che il dato host abbia accesso al server Samba.
Le opzioni sono:
-h
: Per avere in output un brief delle opzioni e della sintassi.
-L nome_server
: Per modificare il valore della macro %L nel valore nome_server.
-s
: Fa in modo che non faccia premere all'utente il tasto [enter] per avere il dump dei settaggi.
Tipo Infobox: COMMANDS - Skill Level: 3- INTERMEDIATE - Autore: lorenzo 'lorenz' urbinati - Ultimo Aggiornamento: 2003-05-31 21:29:06
nmblookup è un'utility che permette la risoluzione dei nomi NetBIOS in indirizzi IP.
Il comando permette di effettuare richieste di nomi NetBIOS per la loro risoluzione in indirizzi IP usando NetBIOS over TCP/IP.
Le sue opzioni gli permettono di effettuare query dirette ad una particolare area broadcast o ad una macchina specifica. Tutte le richieste vengono inoltrate usando UDP.
Un po come nslookup è utile per recuperare informazioni su una rete NetBIOS dai semplici indirizzi a informazioni particolari come __MSBROWSE__ usate dai servizi dei nomi di Windows per fornire servizi di directory.
La sua sintassi è:
nmblookup [-opzioni] nome
Supporta varie opzioni che ne regolano il comportamento:
-A
: Interpreta un nome come un indirizzo IP e segue una richiesta node-status su quell'indrizzo.
-B indirizzo_broadcast
: Invia le richieste ad un particolare indirizzo broadcast. Il suo default è di utilizzare il valore di broadcast dell'interfaccia di rete primaria oppure come definito dal parametro interfaces
del smb.conf.
-h
: Stampa a monitor un breve brief dei comandi.
-M
: Effettua la ricerca del master browser locale. Viene eseguita una richiesta broadcast delle macchine che rispondono al nome speciale __MSBROWSE__ e poi chiede le informazioni a quella macchina al posto di effettuare un richiesta broadcast per la macchina cercata.
-R
: Abilita le richieste ricorsive. Si usa per effettuare richieste ad un WINS server.
-S
: Una volta ricavato l'indirizzo IP del nome richiesto effettua una richiesta node-status restituendo tutti i tipi di risorsa che la macchina ha e il loro valore numerico.
-s
: Permette di specificare il file di configurazione smb.conf da utilizzare.
-U indirizzo_unicast
: Effettua un richiesta unicast all'indirizzo specificato, si usa insieme all'opzione -R per fare richieste a server WINS sulla rete locale.
Vediamo l'otput di un node-status:
bash-2.05a$ nmblookup -A 192.168.0.1
Looking up status of 192.168.0.1
SMBSRV <00> - B
SMBSRV <03> - B
SMBSRV <20> - B
WORKGROUP <00> -
WORKGROUP <1e> -
__MSBROWSE__ <01> -
Tipo Infobox: COMMANDS - Skill Level: 3- INTERMEDIATE - Autore: lorenzo 'lorenz' urbinati - Ultimo Aggiornamento: 2004-01-21 12:27:41
Abbiamo visto che anche con smbclient si possono gestire i back-up di risorse condivise ma nella suite Samba esiste un comando prettamente dedicato a questo lavoro, smbtar.
In realtà smbtar è uno shell script che gira sopra smbclient e permette di eseguire back-ups e restores usando opzioni più comprensibili. Le sue funzionalità sono simili a quelle del comando unix tar.
Supporta svariate opzioni, vediamone alcune delle principali, consiglio comunque di dare sempre un'occhiata alla relativa pagina di man per un prospetto completo.
-d directory
: Passa alla directory specificata prima di eseguire il backup o il restore dei file.
-N nomefile
: Esegue il backup solo dei file più recenti dell'ultima modifica al file specificato. Utile per i backup incrementali (vedi man).
-p password
: Indica la password da utilizzare per accedere alla risorsa condivisa.
-r
: Esegue il restore della risorsa condivisa dal file .tar specificato.
-s nomeserver
: Indica il nome della macchina che serve la risorsa condivisa interessata.
-t nastro
: Può essere una device, un'unità nastro o un file. Se non definito il default è la variabile di ambiente $TAPE e se non esiste il file tar.out.
-u utente
: Indica l'utente con il quale si desidera connettersi alla risorsa condivisa. Si può specificare anche la password nella forma nomeutente%password.
-x risorsacondivisa
: Permette di specificare il nome della risorsa condivisa a cui si desidera accedere. Di default usa backup che è un nome comune per risorse dedicate al backup e al restore.
Vediamo un esempio dell'uso del comando:
smbtar -s nomepc -x nomeshare -u nomeutente -p password -t backup.tar
SOURCE: Pagina man del comando. -
Tipo Infobox: COMMANDS - Skill Level: 3- INTERMEDIATE - Autore: lorenzo 'lorenz' urbinati - Ultimo Aggiornamento: 2004-06-04 11:08:27
Ci sono diversi modi di accedere a risorse condivise con SMB e uno di questi è usare smbclient. Il suo uso non si discosta molto dall'usare un normale client ftp fuorchè il fatto che utilizza un diverso protocollo.
Questo comando è considerato tra i più usati della suite Samba. Non solo è una comoda utility per trasferire files da e verso risorse Samba ma ne permette anche l'archiviazione, è utile per il testing del server e per controllare quali servizi sono attivi.
La sua sintassi è:
smbclient //server/risorsa [-opzioni]
Le opzioni di smbclient sono molte, consultare la pagina man del comando per averne un prospetto completo, vediamo qui alcune delle più importanti.
-s config_file
: Permette di specificare un file di configurazione di Samba da usare.
-M NetBIOS_name
: Questa opzione permette di inviare un messaggio WinPopUp ad una macchina della rete. Una volta stabilita la connessione si digita il messaggio terminandolo con un ctrl+D
. Non c'è modo di sapere se il messaggio è arrivato a destinazione o meno e il limite dato dal protocollo è che non si superino i 1600 bytes. Può essere utile il suo uso associato a cat, ad esempio cat messaggio.txt | smbclient -M PIPPO
-n NetBIOS_name
: Con questo comando posso scegliere un nome NetBIOS a mio piacimento. Se non specificato Samba usa il nome del'host locale con lettere maiuscole.
-h
: Stampa a monitor un brief delle principali opzioni.
-I
: Permette di specificare l'indirizzo ip di una risorsa condivisa a cui si vuole accedere. In questo modo si forza il client a non cercare assolutamente di risolvere il nome della risorsa e di connettersi alla macchina specificata.
-U username[%password]
: Con questa opzione mi è possibile specificare un utente e eventualmente una password da usare per accedere a una data risorsa.
-A nome_del_file
: Questa opzione può essere utilizzata al posto di quella appena vista e permette di specificare un file da cui attingere lo USER e la PASSWD. E' stata studiata principalmente per l'uso negli script. Si può specificare anche il nome del dominio. La sintassi è:
username = valore
password = valore
domain = valore
-L
: Questa opzione è utile in fase di testing e permette di listare tutte le risorse condivise di un dato host.
-W WORKGROUP
: Questa opzione può essere necessaria per collegarsi ad alcuni server e permette di specificare un diverso WORKGROUP (dominio) da quello specificato nel smb.conf per la connessione in oggetto.
-T opzioni_di_tar
: Questa opzione permette di lavorare sui file di una risorsa per scopi di backup e di restore. Ha numerose sotto-opzioni, fare riferimento alle pagine man di smbclient per un prospetto completo. Vediamo un esempio di sintassi:
smbclient //server/nome_risorsa -Tsotto-opzioni
Le sotto-opzioni sono quasi complementari a quelle che usa il comando tar originale.
c
: Crea un nuovo archivio tar. Va seguito poi il nome dell'archivio.
x
: Estrae i file da un archivio.
N
: Sta per "newer than". Permette di archiviare solo i file più nuovi di un file che si specifica.
Quando si lancia senza paramentri smbclient si comporta come un client ftp da riga di comando e ci presenta un prompt così:
smb:\
In modalità interattiva si possono eseguire numerose operazioni, vediamone alcune:
?
: Questo comando stampa un lista informativa dei comandi e ne descrive brevemente il significato. Si può farlo seguire da il nome di un comando e stamperà una descrizione della sua funzione. Si può usare anche help
.
!
: Apre una shell sulla macchina locale. Si può farlo seguire dal comando che si vuole eseguire.
cancel id_stampa
: Permette di cancellare un job di stampa dalla coda sulla stampante. Va specificato il numero di job che si intende eliminare.
cd directory
: Permette di cambiare directory. Se usato senza specificare il path si comporta come pwd
mostrando la directory corrente.
del stringa
: Cancella dal server tutti i file della directory corrente che hanno una corrispondenza della stringa.
dir stringa
: Una lista di file contenenti la data stringa presenti nella directory di lavoro viene recuperata e mostrata.
exit
: Termina la connessione con il server e esce.
get file_remoto nome_file_locale
: Recupera un file definito e lo salva in locale con il nome specificato.
lcd directory
: Cambia la directory locale. Anche qui se non specificata la directory stampa il path della directory locale corrente.
ls stringa
: uguale a dir
.
mget stringa
: Permette di scaricare più di un singolo file o directory.
md
o mkdir
nome_directory: Crea una directory all'interno di quella attuale.
mput stringa
: Permette di mandare in upload più file o directory che hanno in comune la stringa specificata
print nome_file_stampa
: Stampa attraverso una stampante condivisa il file specificato.
put nome_file_locale nome_file_remoto
: Esegue l'upload di un file locale e se specificato lo rinomina nel nome dato.
queue
: Mostra la lista dei file in attesa di stampa.
rm stringa
: Rimuove tutti i file che hanno corrispondenza con la stringa data.
rmdir nome_directory
:rimuove la directory specificata.
tar
: Oltre all'uso dell'opzione -T in modo interattivo si usa questo comando. Supporta le stesse opzioni di -T.
Tipo Infobox: COMMANDS - Skill Level: 3- INTERMEDIATE - Autore: lorenzo 'lorenz' urbinati - Ultimo Aggiornamento: 2004-06-04 11:07:47
Se una volta configurato il server Samba si desidera accedere alle risorse condivise come se fossero parte del filesystem Unix e non come se si accedesse ad una risorsa esterna, ad esempio usando smbclient, si dovrà "montare" la risorsa così come si montano le diverse partizioni del disco.
In questo modo sarà possibile eseguire operazioni sui file condivisi da una macchina Windows ad esempio come se si trattasse di file unix e quindi usando tutti i fantastici e versatilissimi comandi unix, grep, sort, df, du, ls, etc... etc.
Per far questo si utilizzano alcune utility fornite con il pacchetto Samba.
Smbmount, ristretta esclusivamente ai sistemi Linux è equivalente a usare il comando mount -t smbfs
. Per utilizzarla è necessario aver compilato i sorgenti assicurandosi che nel configure si sia abilitata l'opzione --with-smbmount
e bisogna accertarsi che il kernel abbia abilitato il supporto per il filesystem smb/cifs.
Smbmount è un demone e quindi una volta lanciato anche se si è smontata la risorsa continuerà ad essere attivo tra i processi listabili con un ps
o con top
. Per eseguire le operazioni si avvale del comando smbmnt.
Vediamo la sintassi e le opzioni possibili.
smbmount servizio punto_di_mount [ -o opzioni ]
Le opzioni si specificano separate con una virgola e con il modello chiave=valore, le più importanti sono:
username=arg
: Permette di specificare un utente con il quale accedere alla risorsa. Se non specificato verrà utilizzato l'utente dato dalle variabili di ambiente. Supporta anche l'uso di sintassi come user%password o user/workgroup o anche user/workgroup%password.
password=arg
: Permette di specificare una password. Se non definita si userà la variabile di ambiente PASSWD e se non trova nessuna password che vada bene, a meno che non si sia definita l'opzione guest, ci restituirà un prompt per digitarla.
credentials=nome_del_file
: Permette di definire un file esterno per la specifica dell'utente e della password. La sintassi del file sarà:
username = valore
password = valore
In questo modo si può evitare di avere queste specifiche in file condivisi da altri utenti nel sistema come /etc/fstab
.
netbiosname=arg
: Permette di specificare un nome netbios per la sorgente. Se non specificato viene usato il nome dell'host locale.
uid=arg
: Permette di specificare un utente che sarà proprietario per tutti i file presenti nella risorsa, si può specificare usando l'id numerico per l'utente o il suo nome.
gid=arg
: Permette di specificare il gruppo propietario per tutti i file della risorsa montata. Si può definire per id o per nome.
port=arg
: Specifica una porta diversa dalla standard 139 per comunicare con la risorsa remota.
fmask=arg
: Definisce i permessi dei file della risorsa montata. Se non specificato si usa la umask corrente.
dmask=arg
: Come sopra ma per le directory.
debug=arg
: Permette la specifica per il debug delle operazioni che si effettuano. Un valore consigliato può essere 4, se si specifica un valore troppo alto si rischia di avere troppi messaggi che impediscono poi la visualizzazione dei dati interessanti.
ip=arg
: Setta l'ip o il nome dell'host remoto a cui ci si vuole connettere.
workgroup=arg
: Permette di specificare il workgroup a cui si riferisce la risorsa condivisa da montare.
guest
: Non richiede una password.
rw
: Monta la risorsa in read and write mode.
ro
: Monta la risorsa in read-only mode
Una volta montata la risorsa la si può smontare con l'equivalente di umount, smbumount. Per la verità si è pensato a questo eseguibile per dare ai normali utenti più versatilità sulle risorse montate. Infatti questo comando è setuid ed è immaginabile che mettere setuid umount sia una cosa da pazzi. Root potrà comunque smontare le risorse con umount.
Non ha opzioni e la sua sintassi è:
smbumount punto_di_mount
I comandi appena descritti valgono per l'uso su sistemi Linux ma se si sta usando Solaris? O HP-UX?
Per questo è stato studiato un'altro metodo che, purtroppo ancora imperfetto e in via di sviluppo, permette di effettuare operazioni sui file di risorse condivise senza avere un supporto smbfs. Si abilita il suo uso in fase di compilazione dei sorgenti con l'opzione, da passare al configure
, --with-smbwrapper
e si utilizza per le operazioni l'eseguibile smbsh.
Smbsh quando lanciato fornisce un albero di directory sotto /smb
. Le sotto directory di /smb
corrispondono ai server e le loro sottodirectory agli share su disco e di stampa. Crea di fatto una subshell e i comandi impartiti dal suo prompt interagiscono con i file come se si trattassero di file locali al sistema unix della macchina.
Ha varie opzioni:
-d
: Setta il livello di debug dell'applicazione e quindi anche di log, i suoi valori vanno da 0 a 10. Il livello 0 registra solo i messaggi più importanti, l'uno è normale e da 3 in su è inteso solo per il debug visto il forte carico di lavoro a cui sottopone Samba.
-l file
: Imposta il nome del file di log da usare.
-P prefisso
: Imposta una divesa directory da /smb
su cui montare il filesystem SMB.
-R ordine
: Imposta l'ordine di risoluzione dei nameservers. Accetta i quattro paramentri lmhosts, host, wins e bcast in qualsiasi ordine.
-U utente
: Supporta il modo username%password
-W workgroup
: Imposta il workgroup NetBIOS al quale il client si connette.
Tipo Infobox: COMMANDS - Skill Level: 3- INTERMEDIATE - Autore: Giorgio 'neo' Colombo - Ultimo Aggiornamento: 2004-06-04 11:06:42
Utility che permette di gestire (inviare comandi / messaggi ) ai demoni di smbd, nmbd e winbindd.
smbcontrol [ -d ] [ -s ] -i
oppure
smbcontrol [ -d ] [ -s ] destination message-type [ parameter ]
-d
Specifica il livello di debug (Accetta valori interi da 0 a 10)
-s
Specifica il file di configurazione
-i
Abilita l'interctive mode,
destination
Per destination si intende a quale processo dovrà essere inviato il messaggio, è possibile specificare sia l'ID oppure sia il nome: nmbd o smbd.
La differenza fra i due target nmbd e smbd oltre al nome del processo consiste nel fatto che il messaggio con destinazione nmbd viene mandato in modalità broadcast a tutti i processi nmbd attivi in quel momento mentre per smbd verrà inviato un singolo messaggio al processo con l'ID specificato nel pid file (smbd.pid)
message-type
Specifici che tipo di messaggio viene inviato. Ecco alcuni esempi:
- close-share
: Termina tutte le sessioni correnti dei client connessi alla share, come argomento si aspetta il nome della share.
- debug
: Setta il debug level
- force-election
: Forza l'elezione del master browser, unico target possibile è nmbd
- ping
: Invia dei ping ai processi evidenziati, stessa modalità dei pacchetti ICMP.
Come parametro si aspetta il numero di ping da inviare di conseguenza i PONG dei singoli processi.
- profile
: Invia un messagio ad un processo smbd per modificare i parametri del profile. I parametri possono essere settati ad on/off per attivarli o disattivarli oppure flush e count per azzerare o attivare i vari counter.
parameter
Parametri richiesti dal messaggio inviato, Es il livello di debugging o il numero di ping da inviare ad un certo processo.
Esempi:
Invio di ping ai processi nmbd
[root@trinity root]# smbcontrol smbd ping 1
PONG from PID 585
PONG from PID 30423
PONG from PID 29124
PONG from PID 29220
PONG from PID 29414
PONG from PID 29139
PONG from PID 29151
Abilitazione dell'interactive mode
[root@trinity root]# smbcontrol -i
visualizzazione dell'help
smbcontrol> ?
<destination> <message-type> <parameters>
<destination> is one of "nmbd", "smbd" or a process ID
<message-type> is one of: debug, force-election, ping, profile, profilelevel, debuglevel, printer-notify, close-share
Tipo Infobox: COMMANDS - Skill Level: 3- INTERMEDIATE - Autore: Giorgio 'neo' Colombo - Ultimo Aggiornamento: 2003-04-04 21:24:55
Comando utile per debugging e gestione del servizio di smb, poichè permette di visualizzare a video un report sullo status delle connessioni.
smbstatus [opzioni] [-s configuration file] [-u username]
-s
Specifica il file di configurazione
-u
Visualizza solo le informazioni sull'utente specificato
-b
Visualizza un report minimo
-d
Visualizza un reposrt verboso
-p
Visualizza la lista dei processi smb
Visualizzazione dello status delle connessioni smb
[root@trinity root]# smbstatus
Samba version 2.2.7
Service uid gid pid machine
----------------------------------------------
nas root root 13039 castro (10.0.1.170) Fri Apr 4 10:26:33 2003
simone simone simone 12811 fox (10.0.1.163) Fri Apr 4 09:38:55 2003
fulvio fulvio fulvio 12808 yakumoscio (10.0.1.6) Fri Apr 4 09:37:55 2003
massimo massimo massimo 12803 blasco (10.0.1.18) Fri Apr 4 09:35:28 2003
IPC$ mas mas 12924 data (10.0.0.37) Fri Apr 4 09:48:48 2003
archive root root 13039 backup (10.0.1.70) Fri Apr 4 10:27:06 2003
aler aler aler 13266 jam (10.0.1.154) Fri Apr 4 11:05:53 2003
No locked files
Visualizzazione dei processi smb
[root@trinity root]# smbstatus -p
Samba version 2.2.7
Service uid gid pid machine
----------------------------------------------
13388
13039
[...]
Tipo Infobox: COMMANDS - Skill Level: 2- JUNIOR - Autore: Giorgio 'neo' Colombo - Ultimo Aggiornamento: 2003-04-04 21:27:21
Utility per il cambio della password di Samba.
smbpasswd [opzioni] [utente] [password]
-L
Permette di specificare le opzioni che solo l'utente root può utilizzare anche come utenti normali. Utilizzato per test o cambiamenti del file smbpasswd in locale.
-r remote hostname
Opzione che permette di specificare l'host remoto su cui cambiare la password per samba. Se si omette il valore di defaul è localhost
-t
Forza il cambiamento della password di un trusted machine account. Account creato per "registrare" la macchina nel dominio gestito dal smb server
-U username[%pass]
Opzione che permette di specificare, l'utente a cui verrà modificata la password. Opzione utilizzabile solo se affiancata all'opzione -r
-a
Opzione per aggiungere nuovi utenti nel file smbpasswd. L'utente che si vuole inserire deve già esistere come utente del sistema con la relativa entry nel file /etc/passwd
-s
Abilita il silent mode e si aspetta di leggere la nuova e vecchia password dallo standard input
-S
Permette di visualizzare il domain SID
-d
Opzione per disabilitare l'utente dal file smbpasswd in locale
-e
Opzione per abilitare l'utente dal file smbpasswd locale
-m
Opzione per specificare l'account è un account relativo ad un host
-n
Permette di settare la password a NULL
-x
Opzione che permette di cancellare l'utente dal file smbpasswd locale
-j Domain
Opzione utilizzata per registrare il server smb in un dominio NT
Nel caso in cui non venga specificato l'utente il comando interpreterà utilizzerà l'utente stesso che ha lanciato il comando per eseguire le operazioni.
Esempio:
Cambio della password dell'utente neo sul server smb trinity
[neo@dido neo]$ smbpasswd -r trinity -U neo
Old SMB password:
New SMB password:
Retype new SMB password:
Password changed for user neo
Tipo Infobox: COMMANDS - Skill Level: 2- JUNIOR - Autore: lorenzo 'lorenz' urbinati - Ultimo Aggiornamento: 2003-05-31 21:34:20
Un server Samba si compone di due principali demoni:
smbd per i servizi di condivisione di file e stampanti.
nmbd per il servizio di risoluzione dei nomi NetBIOS e di assistenza al browsing delle risorse.
Entrambi questi demoni si appoggiano al file smb.conf per funzionare e hanno opzioni da riga di comando specialmente per effettuare test e debug dei rispettivi servizi.
Smbd e nmbd necessitano di essere avviati insieme per poter garantire un funzionamento corretto del server Samba. E' consigliabile infatti far gestire il loro avvio da uno script di avvio e le principali distribuzioni vengono già fornite di comodi script come /etc/init.d/samba
anche se la loro posizione varia tra le diverse distribuzioni.
In altri casi si può usare il super-demone di gestione dei servizi inetd o infine si possono avviare da riga di comando ma a patto di essere l'utente root.
smbd: Come detto questo demone è responsabile della gestione delle risorse condivise, siano esse dischi o stampanti, tra il server Samba e i suoi client. Fornisce i servizi di condivisione dei file e delle stampanti, di browsing ai client di una o più sotto-reti e di gestione di tutti i messaggi di notifica che client e server si scambiano. Infine si occupa di autenticare gli utenti e di controllare le risorse condivise.
Smbd rilegge il suo file di configurazione automaticamente ogni minuto. Si può forzare il server a rileggere il suo file di configurazione con un SIGHUP. Ricaricare il file comunque non influirà sui client già connessi i quali dovranno sconnettersi e riconnetersi perchè le modifiche abbiano effetto.
Il modo esatto di lanciarlo e con l'opzione -D
che lo porta ad avviarsi come demone. Questa è anche l'opzione di default.
Le sue opzioni a parte quella appena descritta sono finalizzate al debug e sono principalmente ad uso degli sviluppatori. Con -h
si può avere la lista di queste, per approfondirle fare riferimento alla pagina di man.
nmbd: Questo demone è in realtà un semplice name server che imita le funzionalità di un WINS o di un NetBIOS name server. Ascolta e cattura le richieste per il name server e risponde con le informazioni in suo possesso. Si occupa inoltre di mantenere una lista per il browse delle risorse di rete e partecipa alla scelta del browsing. Se attivo il server WINS nmbd tiene il database dei nomi e degli indirizzi in un file chiamato wins.dat
. Un demone nmbd può anche rispondere alle richieste del protocollo di browsing delle Risorse di Rete di Windows. Il browsing è una serie di protocolli di annuncio, annuncio di servizi o di directory condivise che fornisce una directory dinamica che contiene i server e i dischi e le stampanti presenti nella rete NetBIOS. Se nmbd è il master browser locale mantiene i databases di browsing nel file browse.dat
.
Anch'esso se lanciato con l'opzione -D
si comporta come un demone andando in background e ascoltando sulla sua porta. Il resto delle opzioni anche in questo caso serve principalmente per effettuare test particolari e verifiche per gli sviluppatori. Con l'opzione -h
se ne può avere un brief veloce.
Documentazione e tool di configurazione di Samba |
Manuali, libri, documentazione online, risorse e tool grafici di configurazione su Samba |
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: lorenzo 'lorenz' urbinati - Ultimo Aggiornamento: 2003-06-03 21:08:32
Quando ci si appresta a configurare approfonditamente un samba server ci si scontra inevitabilmente con la grande quantita di opzioni globali e di share. Averne un prospetto completo a mente è un'impresa titanica e a questo scopo ci si può avvalere di un comodo strumento di configurazione, swat.
Swat, Samba Web Administation Tool, viene comunemente installato con il pacchetto Samba e se si utilizza una distribuzione che installa la suite non necessita di ulteriori modifiche, a parte forse scommentarne la voce relativa nel file /etc/inetd.conf
a seconda della distribuzione.
In effetti si tratta di un servizio che viene generalmente invocato da inetd e fornisce un'interfaccia web utile per creare e modificare il file smb.conf e per studiarne le opzioni.
E' buona norma comunque se si vuole utilizzarlo controllare prima di tutto due file:
- /etc/services
e verificare che sia presente ed eventualmente aggiungere la voce:
swat 901/tcp
Definizione non ufficiale e che in alcune reti potrebbe entrare in conflitto con altri servizi
- /etc/inetd.conf
e verificare o aggiungere la riga:
swat stream tcp nowait.400 root /percorso/eseguibile/swat swat
Dove il percorso al file può variare a seconda della distribuzione usata o dove si è deciso di installare Samba
Una volta eseguite queste semplici operazioni si può aprire il nostro web browser preferito e digitare: http://localhost:901/
Ci apparirà una finestra che ci chiede di inserire nome utente e password e dovremo usare l'utente root e la sua relativa password di sistema.
A questo punto si ha accesso ad una serie di menu che in poco tempo ci permetterà di creare un file di configurazione per Samba. La cosa che trovo più utile e importante è che per ogni opzione settabile si ha un link ad un help che ne descrive il significato, i valori di default e così via. Non solo, prima l'ho descritto come tool anche per studiare, infatti sotto il menu HOME si ha la possibilità di accedere comodamente a un grande quantità di documentazione, pagine man e vari how-to, permettendo così di iniziare la nostra configurazione con un comodo appoggio per imparare.
Va ricordato che nonostante sia possibile collegarsi anche da macchine remote, swat non ha di default la possibilità di usare password crittografate con di conseguenza il rischio che qualcuno sulla rete possa sniffare i pacchetti e leggere in chiaro la password dell'utente root sul samba server. Esiste la possibilità di criptare le password anche se swat non lo supporta nativamente. Si può trovare un breve how-to introduttivo su www.samba.org chiamato swat_ssl.html.
Un'altro grande difetto di swat è il fatto che utilizzato su un file esistente ne modificherà anche il layout. Tutti i commenti eventualmente aggiunti e le opzioni include e copy verranno cancellati.
Questo ne fa a mio avviso un ottimo punto di partenza per il principiante, permettendo di creare un primo file di configurazione e in seguito editarlo finemente con un editor di testi.
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: lorenzo 'lorenz' urbinati - Ultimo Aggiornamento: 2003-06-04 01:11:21
Se si ci si è appena avvicinati all'argomento e si desidera imparare a configurare un server Samba si avrà quasi certamente l'imbarazzo della scelta.
La documentazione non manca, a partire dal pacchetto dei sorgenti per arrivare a innumerevoli siti italiani e stranieri, passando per varie mailing-list.
Risorse locali
Innanzi tutto se si è scaricato il pacchetto contenente i sorgenti una volta scompattato si troveranno al suo interno alcune directory molto interessanti:
docs
e examples
Dentro docs troveremo tutta la documentazione necessaria, in html e in txt, molti howtos, le faq e un comodo pdf che raggruppa molti howtos: il Samba-HOWTO-Collection.pdf.
Di solito tutto questo materiale, se la propria distribuzione ha provveduto ad installare Samba si trova nella directory di sistema dedicata alla documentazione che generalmente si trova a partire dalla directory /usr
e se si è compilato dai sorgenti si troveranno questi file dove specificato dal configure
.
Come visto parlando dell'utility swat si può accedere a parecchia di questa documentazione nella sua pagina menu HOME.
Samba.org
Non dovesse bastare il primo posto dove cercare è dal sito di samba, www.samba.org.
Quando si accede alla pagina iniziale si trova una lista di mirror sparsi per il mondo. Attualmente ne esiste uno in Italia ma è per il download dei pacchetti, consiglio di usare un mirror vicino a noi per la visualizzazione del sito, tipo quello in Austria, di modo da non oberare di lavoro il server principale e anche per avere velocità di caricamento maggiori dovute alla vicinanza.
Molti how-to si trovano solo in questo sito, a volte perchè molto recenti, per questo consiglio vivamente a chiunque voglia cimentarsi seriamente con Samba di far diventare questo sito temporaneamente la sua homepage iniziale. Oltre alla documentazione sul sito si trovano tutte le mailing-lists ufficiali con le modalità di iscrizione e consultabili on-line.
Risorse online
A questo punto questo potrebbe essere sufficiente ma se si desidera approfondire basta andare su Google linux (www.google.com/linux) e cercare la parola chiave "samba" per trovare innumerevoli risorse. Anche se si cerca tra le pagine in italiano aggiungendo documentazione alle parole chiave si è proiettati in una spirale enorme di risorse.
Vediamo alcuni dei siti più interessanti per documentazione in italiano:
Esiste un libro, tradotto in italiano, che si chiama "Usare Samba" e comprabile in qualunque buona libreria convenzionata con la o'Reilly ma anche disponibile gratuitamente on-line all'url http://www.hopslibri.it/samba/root.html
Si tratta però della traduzione della prima edizione, tenerlo a mente perchè parecchie cose potrebbero e sono cambiate, resta comunque molto importante per comprendere meglio certi concetti che in lingua originale sono un po oscuri.
Un how-to che dà dei buoni spunti su cui lavorare si trova su
http://www.valtellinux.it/howto/samba/SMB-HOWTO.html
Un'altro how-to, tral'altro inserito nel mitico progetto "Appunti di informatica libera", è disponibile all'indirizzo
http://scuola.linux.it/docs/samba/samba.html
Un articolo che nello specifico tratta dell'implementazione di un samba server come Domain Controller in una rete windows:
http://mercury.chem.pitt.edu/~sasha/LinuxFocus/Italiano/March2002/article177.shtml
Per finire segnalo un simpatico sito che con un po di ironia offre alcune discussioni su problemi riscontrabili nella configurazione di vari servizi tra cui anche Samba raggiungibile su http://www.campana.vi.it/ottavio/linux/4pinguiniinpadella/4pinguiniinpadella.html
Mi sono fermato nella mia ricerca alla terza pagina di google ed ho omesso alcuni siti perchè trattavano argomenti basandosi su vecchie versioni di Samba o perchè fin troppo specifici. Come riscontrerete anche voi con un po di pazienza e delle ricerche mirate si possono trovare spunti e consigli utilissimi, raccomando di verificare sempre che il sito o l'how-to o il manuale trovati siano attuali prima di perdere i capelli chiedendosi perchè la tale opzione non funziona.
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: lorenzo 'lorenz' urbinati - Ultimo Aggiornamento: 2003-06-06 00:28:28
Oltre all'ufficiale strumento di gestione swat compreso nella suite Samba in rete si possono trovare altri validi tool per configurare e lavorare con Samba.
Basta una semplice ricerca su freshmeat per accorgersi del grande numero di applicazioni disponibile.
Vediamo alcune valide alternative tra i tanti progetti presenti.
Utility di configurazione
Se si utilizza Webmin per amministrare il server ci si può avvalere di un suo modulo, solitamente installato di default ma scaricabile e installabile anche dopo in caso ad esempio si fosse in precedenza scelto di eliminarlo perchè inutilizzato.
Questo modulo permette di creare o editare il file smb.conf
, aggiungere shares e opzioni. Esiste anche un'altro modulo che non fa parte però di quelli standard di Webmin e che permette di editare i netlogon files, si chiama smblogin e si può reperire su freshmeat.
Smbconftool di cui ne parla bene anche lo stesso sito di Samba, è scritto in java e ha la peculiarità di non cancellare i commenti come invece fa swat. Si possono avere maggiori informazioni alla pagina http://www.eatonweb.com/samba/
I due principali Desktop Enviorment, KDE e Gnome, hanno entrambi la possibilità di usare delle applicazioni per configurare il server Samba.
Per Gnome esiste un progetto che però al momento il sito non è raggiungibile e si chiama Gnosamba.
Per KDE invece esiste un plugin per il Control Center che permette di abilitare un'interfaccia in cui poter settare praticamente quasi tutte le opzioni di configurazione e di creare, distruggere, modificare gli shares. Il suo nome è KSambaPlugin ed è disponibile su freshmeat.
Ci sono altri strumenti per la configurazione di Samba, scritti in linguaggi differenti e a volte nati per configurare server Unix e poi allargati alla gestione del smb.conf.
Utility per lavorare
Esistono svariati progetti per utilizzare gli strumenti della suite Samba quali smbclient o smbmount. Spesso si tratta di semplici frontend che utilizzano i comandi di Samba altre volte sono applicazioni più complesse.
xSMBrowser è una comoda GUI che permette di usare smbclient da un'interfaccia grafica. In se può essere paragonato a client ftp come gftp o kbear e infatti la somiglianza è grande, ci presenta una finestra con il filesystem locale e una con il filesystem remoto. Permette tutte le operazioni che si possono fare con smbclient.
Un'altro comodo frontend è Jags o Jagsmm acronimo per "Just another gnome samba-client" usa le librerie gtk e fornisce un'interfaccia al comando smbmount permettendoci di esplorare la rete e di montare le risorse disponibili.
A jags si appoggia una comoda utility trovabile su freshmeat, SambaSentinell che è una GUI in gtk per il comando smbstatus, permette di controllare lo stato dei samba server e delle relative connessioni ai loro share, mostrando l'utente connesso, il suo ip, i file che ha usato e addirittura di "uccidere" un processo in atto. In realtà questo strumento non richiede espressamente la presenza di jags ma se si vuole abilitarne la funzione di montaggio delle risorse condivise si deve averlo installato e funzionante.
LinNeighborhood è un'altra semplice GUI a smbmount e permette di effettuare il browse delle risorse condivise e di montare quelle di interesse.
I due principali desktop enviorment, KDE e gnome, sono dotati entrambi di applicazioni per esplorare networks Samba e per montare gli share.
Per gnome esiste Gnomba progetto a quanto pare rimasto offline per un certo periodo e ora ripreso. Il programma si può scaricare alla pagina http://gnomba.sourceforge.net/. Permette di scansire la rete alla ricerca di risorse condivise, offre un'interfaccia per la navigazione delle stesse e infine permette di montare localmente gli share.
Per KDE si trovano vari progetti tra cui komba2 che avvalendosi di praticamente quasi tutti gli strumenti di samba (smbmount, smbstatus, nmblookup, testparm) permette di navigare tra le risorse condivise e accedere agli share montandoli in locale.
Configurazione di Samba |
File di configurazione e settaggio dei parametri base e avanzati. |
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2003-03-25 17:14:42
La configurazione di Samba (i demoni smbd e nmbd) viene gestita dal file smb.conf, un normale file di testo ASCII con queste caratteristiche di massima:
- I parametri di configurazione vengono forniti nella forma opzione = valore
- Il file viene diviso in più sezioni che definiscono una share (condivisione), oltre alla sezione generale [global]
. Ogni sezione si indica fra parentesi quadre: [printers]
- Le righe di commento sono precedute da asterisco (#) o punto e virgola (;)
- Righe di configurazione possono estendersi su più righe di smb.conf utilizzando una backslash (\) a fine riga
- Le opzioni e i valori sono case insensitive, ma se si indica un path nel file system questo è case sensitive
- Per separare una serie di valori possono essere usati sia virgole (,) che spazi vuoti ( )
- Possono essere utilizzate delle variabili, precedute dal simbolo percento (%) all'interno dei valori (es: path = /home/%u
)
- Si può includere a smb.conf un altro file di configurazione con l'opzione include (es: include = /etc/samba/smb.conf.%a
)
Le opzioni di configurazione possono essere di 2 tipi fondamentali:
- global, appaiono solo nella sezione [global] e definiscono i comportamente generali del server Samba
- share, appaiono all'interno di specifiche share e definiscono il comportamento riguardo alla specifica share. Se appaiono in [global] definiscono i comportamenti di default.
Qualsiasi opzione deve essere inclusa una una sezione. Esistono le seguenti sezioni speciali:
[global] Sempre presente, di solito ad inizio file, definisce le opzioni di default valide per tutte le condivisioni (possono essere sovrascritte da opzioni contrarie presenti nelle specifiche sezioni) e i parametri generali di configurazione del server.
[printers] E' una sezione speciale utilizzata per condividere l'accesso via rete a delle stampanti
[homes] E' una sezione speciale che coincide con la home directory di un utente autenticato. Di fatto è una condivisione generica con il nome dell'utente che accede a Samba.
Oltre a queste sezioni speciali ne possono esistere un numero arbitrario di altre, il nome di ogni sezione coincide con il nome della relativa condivisione, così come appare al client SMB.
Tipo Infobox: DESCRIPTION - Skill Level: 3- INTERMEDIATE - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2003-05-07 12:50:04
La sezione [global] è praticamente presente in ogni smb.conf.
Qui si definiscono le configurazioni generali riguardanti il server Samba e i suoi comportamenti di default.
Vediamo nel dettaglio alcune opzioni:
CONFIGURAZIONI BASE NETBIOS
Netbios name
Definisce il nome NetBios della macchina, così come viene visualizzato in rete. Di default coincide con il nome DNS per la parte relativa all'host (es: pippo.dominio.it prende di default il nome PIPPO). Es:
netbios name = PLUTONE
Server string
E' il commento che si può leggere visualizzando i dettagli su un host in rete. non è indispensabile ma può essere utile per indicare le funzioni o le caratteristiche della macchina. E' possibile usare variabili, per esempio:
server string = File Server - Samba %v (%h)
Workgroup
Definisce il workgroup di cui fa parte il server Samba. Di default il valore è "WORKGROUP", definito in fase di compilazione, ma può essere cambiato. Es:
workgroup = INTRANET
Netbios aliases
Questa opzione permette di assegnare più nomi NetBios allo stesso server oltre a quello definito con netbios name, in modo da farlo comparire fra le Risorse di rete di Windows come macchine diverse, su cui è necessario eseguire login autonomi, anche se di fatto restano lo stesso server. Questa funzionalità può essere utile. per esempio, per raggruppare su un singolo server diversi server SMB che prima risiedevano su macchine diverse senza modificare alcun parametro sui client. Es:
netbios aliases = vendite marketing amministrazione
GESTIONE DEL NETWORKING
Hosts allow - Hosts deny
Queste opzioni definiscono l'accesso al server. Hanno la stessa logica dei file /etc/hosts.allow e hosts.deny, possono essere presenti sia nella [global] che definiti per singola share. Come argomento si aspettano l'IP di una network o di un host (considerando che la rete 192.168.0.0/24, per esempio, si indica 192.168.0.) oppure un singolo hostname (pippo.dominio.com) o un nome di dominio o sottodominio (.dominio.com).
Sono accettati anche gli argomenti speciali ALL (tutti gli IP) e EXCEPT, seguito da indirizzi o nomi di host.
Samba segue una logica ben precisa per gestire gli accessi con queste opzioni:
- Se non sono definite, viene permesso l'accesso da ogni IP
- Se sono definite nella [global] queste si applicano ANCHE per le singole share (anche se si sono specificate a livello di share)
- Se esiste solo hosts allow
viene permesso quanto specificato come argomento e vengono esclusi tutti gli altrti IP
- Se esiste solo hosts.deny
sarà permesso l'accesso a tutti gli IP tranne a quelli specificati come argomento
- Se esistono sia hosts allow
che hosts.deny
vengono esclusi TUTTI gli IP tranne quelli che sono presenti in hosts.allow E non sono presenti in hosts.deny.
Nell'esempio che segue viene dato accesso a 192.168.0.10 e a tutti gli host della rete 10.0.0.0/24 tranne 10.0.0.15:
hosts allow = 10.0.0. 192.168.0.10
hosts deny = 10.0.0.15
Questo esempio corrisponde a:
hosts allow = 192.168.0.10 10.0.0. EXCEPT 10.0.0.15
Se invece si vuole permettere l'accesso solo alla rete 192.168.0.0/16 si può scrivere semplicemente:
hosts allow 192.168.
che coincide con:
hosts deny = ALL EXCEPT 192.168.
Interfaces - Bind Interfaces only
interfaces
definisce su quale interfacce di rete dell'host locale Samba si metterà in ascolto. Di default Samba utilizza l'interfaccia di rete principale, ma se si vuole che resti in ascolto su altre interfacce o si vuole essere certi che Samba scelga l'interfaccia voluta, queste vanno specificate tramite il loro indirizzo IP:
interfaces = 10.0.0.3/24 192.168.0.4/255.255.255.0
Il comando bind interfaces only
può avere valore yes
o no
(default). Se viene abilitato Samba ignorerà ogni pacchetto, anche di broadcast, che origina da rete diverse da quelle specificate con interfaces
. Notare che se si abilita, è necessario includere esplicitamente il localhost (127.0.0.1) nell'elenco delle interfacce su cui Samba deve stare in listening.
bind interfaces only = yes
GESTIONE DEL LOGGING
Log file
Specifica su quale file Samba va a scrivere i suoi log. L'argomento può contenere delle variabili, per cui è possibile avere diversi file di log per ogni utente, per tipo di client ecc. Per creare un log diverso per ogni client NetBios, per esempio, si può scrivere:
log file = /var/log/samba.log.%m
Log level
Specifica il livello di logging da usare, va da 0 (minimo) a 10 (estremamente verboso). Il valore di default è 1, su un server normale dovrebbe essere di 1 o 2, se si deve fare un po' di troubleshooting usare il livello 3, valori superiori servono soprattutto a chi sviluppa su Samba e rallentano notevolmente le operazioni:
log level = 2
Max Log Size
Definisce la dimensione massima in Kilobyte dei file di log. Quando viene raggiunto il limite, il file di log viene rinominato aggiungendo il suffisso .old (vengono eliminati eventuali file .old esistenti creati precedentemente) e si riparte con un file di log vuoto. Il valore di defalt è 5000 Kb, il valore suggerito dipende fondamentalmente dallo spazio su disco disponibile, evitare di impostare un valore troppo alto che rischia di occupare tutto lo spazio (considerando anche il file .old):
max log size = 2000
Debug Timestamp
Con questa opzione è possibile specifcare se inserire data e ora per ogni riga di log generata. Coincide con l'opzione timestamp logs
. Il valore di default è yes per cui nei log sono indicate data e ora in cui avvengono gli eventi. Per non specificare il timestamp scrivere:
debug timestamp = no
Syslog e syslog only
Queste opzioni regolano la possibilità di usare il demone syslog, invece o parallelamente al logging diretto.
Per poter usare il syslog è necessario compilare Samba con configure --with-syslog
e configurare /etc/syslog.conf
per gestire la facility daemon. Ad esempio con una riga tipo:
daemon.* /var/log/daemon.log
Il valore specificato (da 0 a 10, default 1) indica quali messaggi di log inviare a syslog e, in riferimento agli argomenti dell'opzione log level, cosa loggare direttamente sui file di log interni. Ad esempio:
log level = 3
syslog = 2
Con queste opzioni i log di livello 0 e 1 (inferiori a 2) vengono mandati a syslog, quelli di livello 2 e 3 (compresi tra syslog e log level) vengono scritti sul file di log interno.
Per loggare solo su syslog si deve attivare l'opzione syslog only:
syslog only = yes
GESTIONE DEL BROWSING
Local master - Domain master
Queste opzioni servono per spingere Samba a cercare di diventare rispettivamente Local Master Browser (il server che mantiene la browse list per una rete IP) e Domain Master Browser (il server che mantiene la browse list per un intero workgroup, anche esteso su più reti IP, nel qual caso raccoglie e coordina lo scambio di browse list dai Local Master Browser remoti). Di default Samba ha attivata l'opzione Local Master (con cui semplicemente gli viene detto di partecipare alle elezioni, senza la certezza di vincerle) e non ha attivata l'opzione Domain Master (è bene che il Domain Master Browser sia la stessa macchina che fa eventualmente da Primary Domain Controller, sia esso un Samba o un Windows server). Le impostazioni di default sono quindi:
local master = yes
domain master = no
Preferred Master - OS Level
Con queste opzioni si gestisce il comportamento di Samba nelle elezioni e la sua possibilità di vincerle.
La prima impone a Samba di chiamare un'elezione ogni volta che entra in rete e gli imposta una probabilità leggermente superiore di vincerle rispetto ad altre macchine con lo stesso livello. E' bene impostarla a yes quando si configura Samba come Domain Master Browser o Local Master Browser:
preferred master = yes
domain master = yes
E' comunque raccomandabile non avere troppe macchine in rete (Windows o Samba) che cercano di partecipare alle elezioni per evitare inutili e ripetuti broadcast e possibili incongrenze sulla browse list di riferimento.
L'opzione OS Master, invece setta esplicitamente il livello con cui Samba si presenta alle elezioni. Può avere valore da 0 a 255, più è alto e maggiore la possibilità di diventare Master Browser. Un valore di 34 basta per far vincere tutte le elezioni con server Windows ad eccezione di un PDC. Il valore di default è 20. Il seguente esempio dovrebbe bastare per vincere ogni elezione (ovviamente ad eccezione di altri server Samba con un OS level superiore):
os level = 65
.
Announce As - Announce version
Queste opzioni definiscono come Samba si presenta in rete. Announce as può avere come valori Win95, NT o WfW il default è:
announce as = NT
Announce version specifica la versione di Samba. Attualmente si presenta di default come:
announce version = 4.9
Generalmente non serve cambiare queste impostazioni di default.
remote browse sync - remote announce
Queste opzioni permettono di sincronizzare la browse list di un server Samba quando esistono diversi local master su reti diverse.
La prima permette di richiedere la sincronizzazione della brose list dai server delle reti remote specificate:
remote browse list = 10.0.0.255 192.168.0.255
Con la seconda opzione si può esplicitamente annunciare il server locale, con un workgroup arbitrario, ai server sulla rete remota specificata:
remote announce = 192.168.0.255/WROKGROUP
In entrambi i casi si possono indirzare direttamente gli IP dei server remoti o gli indirizzi di broadcast della loro rete (in questo caso il "directed broadcast" deve poter essere consentito sulla rete remota, di default i router Cisco non lo permettono).
GESTIONE DELLE PASSWORD
E' importante configurare la logica con cui Samba gestisce l'autenticazione e come eventualmente sincronizza le sue password con quelle di sistema. I dati relativi agli utenti sono mantenuti nel file smbpasswd
, che a sua volta si può modificare con l'omonimo comando shell.
Sulla gestione delle password esistono varie opzioni di configurazione.
encrypt passwords
Di default ha valore NO, non prevedendo l'invio in chiaro delle password via rete. Sui Windows recenti, comunque, (tutti esclusi NT4 pre SP3 e Windows 95) le password vengono inviate criptate. Per cui o si modifica il registro (esiste .reg adatto nel tar.gz ufficiale) sui Windows o, meglio, si abilita la criptazione delle password:
encrypt passwords = yes
.
password level
Di default samba esegue il matching delle password in lowercase (con caratteri minuscoli), compresa la prima lettera.
Password level permette di specificare, come nel caso di username level, quante lettere al massimo si possono rendere maiuscole per i tentativi di connettersi ad una smb share.
password level = 2
null password
Abilita o Disabilita la possibilità di utilizzare password (cryptate e non cryptate) pari a null.
Il valore di default è NO.
password level = yes
smb passwd file
Specifica il path del file contenente le password cryptate.
Il valore di default è : /usr/local/samba/private/smbpasswd
smb passwd file = /etc/samba/smbpasswd
CONFIGURAZIONE DEI DOMINI
SAMBA permette di usufruire dei domini di windows in varie modalità:
- PDC, samba può essere configurato come primary domain controller per i client windows/unix.
- BDC, (backup domain controller) features non del tutto funzionante per le versioni correnti (2.x), occorre aspettare la versione 3.x per avere il supporto completo.
- Host, facente parte di un dominio esistente.
Di seguito sonon riportate alcune opzioni utili per configurare il logon dei client nel dominio:
domain logons
Permette di loggarsi nel dominio tramite samba configurato come PDC server.
domain logons = yes
logon script
Specifica lo script che verrà lanciato sui client una volta loggati nel dominio.
logon script = logon.bat
logon home
Specifica l'home dell'utente, per i comandi DOS NET.
logon home = \\server\home\%U
logon path
Identifica la locazione dei roaming file.
logon path = \\server\profile\%U
RISOLUZIONE DEI NOMI CON SAMBA
E' possibile utilizzare una o più delle seguenti modalità di risoluzione dei nomi:
- Broadcasting
- LMHOST file
- Unix /etc/host o NIS
- WINS (Windows Internet Name Service), samba ha la facoltà di appoggiarsi ad un WINS server esterno oppure configurare lo stesso SAMBA per fungere da WINS server.
name resolve order
Opzione che permette di specificare con quali metodi e il rispettivo ordine da utilizzare per la risoluzione dei nomi.
name resolve order = wins hosts bcast
wins server
Permette di appoggiarsi ad un wins esterno specificando semplicemente l'IP, sarà SAMBA stesso a ridirigere le singole richieste al server specificato.
wins server = 10.0.0.100
wins proxy
Abilita il forwarding di tutte le richieste di risoluzione dei nomi anche ad WINS che sono esterni alla subnet del SAMBA server.
wins proxy = yes
wins support
Abilita il WINS server di SAMBA.
wins support = yes
dns proxy
Permette di appoggiarsi al DNS configurato sul server SAMBA (/etc/resolv.conf) per la risoluzione dei nomi fallita tramite WINS.
dns proxy = yes
Tipo Infobox: COMMANDS - Skill Level: 3- INTERMEDIATE - Autore: Giorgio 'neo' Colombo - Ultimo Aggiornamento: 2003-05-31 21:47:24
Client per il managment delle ACL delle share SMB in un server NT.
smbcacls //server1/share1 filename [options]
Opzioni Comuni:
-U
Opzione per specificare l'utente utilizzato per conettersi al servizio remoto
-A [acls]
Aggiunge una ACL all'access list specificata
-D [acls]
Elimina le ACL specificate in linea di comando
-n
Visualizza le ACL in formato numerico
Formato ACL:
Le ACL sono formate da singole o più entry separate dalla virgola o più semplicemente ogni entry deve corrispondere ad una nuova linea. Esempio:
Specifica il numero della revisione della ACL lato NT server
REVISION:<revision number>
Owner e Group specificano owner e group sid dell'oggetto
OWNER:<sid or name>
GROUP:<sid or name>
ACL
ACL:<sid or name>:<type>/<flags>/<mask>
Tipo Infobox: DESCRIPTION - Skill Level: 3- INTERMEDIATE - Autore: Giorgio 'neo' Colombo - Ultimo Aggiornamento: 2003-05-16 15:25:24
Le opzioni inserite nella sezione [share] fanno riferimento alla configurazione da applicare alla singola risorsa condivisa o alle share di sistema come [netlogon] o [printer] per abilitare/disabilitare alcune funzioni di samba stesso.
CONFIGURAZIONI BASE PER LE SINGOLE SHARE
Le seguenti opzioni sono le tipiche opzioni utilizzate in tutti i tipi di share e ne definiscono i caratteri generali come per esempio il nome della risorsa che si condivide.
[nome share]
Il nome delle singole share è settato con la seguente entry [nome share] nel file di configurazione dopo le opzioni relative alla sezione [global].
[docs]
path
Sinonimo di directory, indica il path locale della risorsa da condividere tramite Samba.
Nel caso in cui la share si riferisce ad una stampate identifica la directory che avrà la funzione da spool per la stampante stessa.
path = /home/docs
comment
E' possibile affiancare un commento al nome delle share, che verrà visualizzato lato client. Utile per descrivere il contenuto della risorsa.
comment= Documenti comuni
GESTIONE ACCESSI
La gestione degli accessi alle risorse può avvenire in vari modi a seconda del tipo di configurazione adottata nelle global options.
valid users - invalid user
La prima opzione viene utilizzata per specificare gruppi o utenti che possono accedere alla risorsa, la seconda invece per negarne definitivamente l'accesso.
valid users = pippo pluto joe
admin user
Determina quali utenti che accedono alla risorsa possono eseguire operazioni da utente root.
admin user = joe
guest ok
Abilita l'accesso alla risorsa all'utente guest.
guest ok = yes
guest account
Unix account utilizzato come guest access. L'account di default è nobody.
guest account = webmaster
guest only
Di default settata a no, limita l'accesso alla risorsa all'utente guest.
guest only = no
writable (write ok) -read only
Opzioni utilizzabili sia nella sezione global che share permette di abilitare o disabilitare gli attributi di scrittura.
I valori di default permettono la sola lettura (read only = yes e writable = no).
read only = no
writable = yes
browsable
Nega o permette la visualizzazione nella lista delle risorse del server samba. Di default è settata a yes.
browsable = yes
read - write list
Opzioni che permettono di eseguire un override della configurazione base di una share per la lista degli utenti specificati.
Rispettivamente, read list permette l'accesso con i soli diritti di lettura ad una share scrivibile mentre write list specifica quali utenti possono accedere, anche con i permessi di scrittura, ad una risorsa configurata per acconsetire gli accessi in sola lettura.
write list = webmasters developers
max connections
Specifica il numero massimo di connessioni ad una share. Settata di default a 0, permette connessioni illimitate alle risorse.
max connections = 10
SYSTEM SHARE
Samba prevede delle share con un nome specifico per abilitare alcune features o lo sharing di risorse particolari come stampanti.
netlogon
Share indispensabile nel caso in cui samba server faccia da PDC, permette il logon dei client nel dominio. Questa share deve avere le seguenti caratteristiche:
- Il nome non è modificabile, [netlogon]
- Non è possibile visualizzarla e scriverci.
- Non è possibile accederci come utente guest.
[netlogon]
Comment = share to domain logon
path = /samba/logon
public = no
writabl e = no
browsable = no
profile
E' possibile specificare tramite la share [profile] la risorsa che dovrà fungere da repository per tutti i roaming profile. Questa share non deve essere visualizzata nelle risorse dispobilli del server ma deve essere possibile scriverci.
[profile]
comment = Profili Utenti
path = /samba/profile
create mode = 0600
directory mode = 0700
writable = yes
browsable = no
homes
Share che visualizza in modo automatico la home dell'utente, senza dover mettere le relative entry nel file smb.conf per i singoli utenti. Tale share che prende il nome dell'utente è visibile e scrivibile solo dall'utente con cui si è eseguito il login sul server.
[homes]
comment = Home Directories
valid users = %S
read only = No
create mask = 0664
directory mask = 0775
browseable = No
Tipo Infobox: TIPS - Skill Level: 3- INTERMEDIATE - Autore: Roberto 'rpennol' Pennolino - Ultimo Aggiornamento: 2004-06-02 15:46:11
Esiste la possibilità di vietare il salvataggio di files con una determinata estensione in una cartella condivisa tramite SAMBA.
Occorre semplicemente aggiungere nella sezione [global] del file smb.conf
(/etc/samba/smb.conf) il seguente parametro:
veto files = /*.mp3/ /*.wav/ /*.mpeg/ /*.avi/
In questo caso non è permesso il salvataggio di files con estensione: mp3, wav, mpeg ed avi.
SMB troubleshooting |
Utilizzo dei log, del debug e di altri strumenti di diagnosi. |
Tipo Infobox: DESCRIPTION - Skill Level: 3- INTERMEDIATE - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2004-01-19 13:34:11
Il mondo delle reti CIFS presenta insidie di varia natura, il protocollo è a suo modo contorto e le implementazioni di diversi produttori possono dar luogo a problematiche diverse.
Per diagnosticare problemi con Samba esistono vari strumenti a disposizione degli utenti:
- I log di Samba stesso
- I vari tool Samba presenti nel pacchetto ufficiale
- Genericamente, i vari strumenti di sistema disponibili su Unix e Windows per diagnosticare problemi di rete e servizi.
I LOG DI SAMBA
Sono tipicamente fra le prime cose da guardare. Nel file di configurazione è possibile definire vari parametri tra cui:
log file = %m.log
- Il nome e la logica con cui vengono salvati i log (possono essere divisi per utente, macchina ecc);
debug level = 2
- La verbosità dei log stessi, con valori che vanno da 0 (nessun logging) a 10 (maggimo debugging). Un valore di debug di 3 o superiore è già fin troppo verboso e va usato solo per diagnosi, in quanto tende a rallentare il sistema.
E' possibile modificare il livello di logging inviando al processo smbd i segnali SIGUSR1 per incrementarlo di uno e SIGUSR2 per diminuirlo di uno.
UTILITY SAMBA
Varie sono le utility di Samba per diagnosticare problemi.
testparm
serve per verificare la correttezza della sintassi del file di configurazione e per verificare se un dato host può collegarsi alla macchina Samba locale (sulla base delle access list di smb.conf, altri impedimenti dovuti a iptables o altro non sono contemplati): testparm hostname 10.0.0.150
, per esempio, elenca per tutte le condivisioni del proprio sistema, se l'host 10.0.0.150 ha diritto di accesso.
smbclient
è comodo per enumerare le condivisioni di un server e capire come e cosa esporta. smbclient -L 10.0.0.150
enumera tutte le condivisioni di 10.0.0.150. Viene chiesta una password, dare invio per fare un accesso anonimo o specificare -U utente
(e poi relativa password) per accedere con specifiche credenziali.
nmblookup
si usa per ottenere i nomi NetBIOS e i relativi IP degli Host in rete, tramite broadcast o query diretta, nmblookup -d 3 '*'
, per esempio, individua, nella propria rete (dominio di broadcast), gli host che rispondono ad una query nmb.
UTILITY UNIX
La diagnosi di problemi con Samba coinvolge anche problematiche di rete: server e client devono poter comunicare via IP e avere accesso alle porte netbios-ns 137/udp, netbios-dgm 138/udp, netbios-ssn 139/tcp e microsoft-ds 445/tcp (usata da CIFS, se non è raggiungibile si usa la 139) non ci devono quindi essere firewall o altri impedimenti che impediscano lo scambio di dati.
La diagnosi inoltre coinvolge l'effettiva esistenza di un server in ascolto sulla porta 139 o 445 e l'eventuale sniffing dei pacchetti in transito. Comandi utili per queste attività sono:
ping
Comando tipico per testare la connettività di rete IP fra due host, in ogni caso da affiancare a un test diretto tipo telnet 10.0.0.150 139
per verificare se alla porta 139 del server indicato risponde qualcosa.
Su un server Samba, per verificare che il servizio sia partito e sia in ascolto e disponibile in rete, digitare netstat -natp
e cercare righe tipo tcp 0 0 0.0.0.0:139 0.0.0.0:* LISTEN 4608/smbd che indicano che il processo smbd è in ascolto (LISTEN) sulla porta 139 su tutti gli indirizzi (0.0.0.0, basterebbe anche l'indirizzo dell'interfaccie di rete).
Verificare inoltre che non si siano firewall esterni o interni che impediscano l'accesso alla prota 139 tcp (con iptables -L -n
si visualizzano le regole di firewalling sul proprio Linux).
Se il client può accedere via rete al server e su questo è in esecuzione il processo che gestisce SMB, eventuali problemi possono essere dovuti al protocollo SMB/CIFS stesso (autenticazione, ecc), per cui possono essere utilizzati i comandi Samba sopra indicati o si può provare a diagnosticare cosa accade sniffando direttamente i pacchetti con strumenti come tcpdump
(analizza solo le intestazioni dei pacchetti) o ethereal
(visualizza e analizza tutto il contenuto di un pacchetto).
A livello applicativo, sul server Samba, può servire utilizzare strumenti come ps -adef
per verificare che i processi smbd e nmbd siano in esecuzione, strace -p #PID
per analizzare a basso livello le chiamate di sistema del processo di cui si è indicato il PID, lsof
per visualizzare i file aperti dai processi in esecuzione.
Stampa e condivisione stampanti |
La stampa su Linux e la condivisione delle stampanti in rete. |
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Alessandro 'ask' Nasuti - Ultimo Aggiornamento: 2003-03-26 23:07:01
LPR (Line Printer Protocol) è il protocollo utilizzato per la comunicazione di stampa tra client e server, basato sul TCP. La porta sui cui va in ascolto è di default la 515, risponde a richieste provenienti dalle porte sorgenti da 721 a 731.
[pippo@SATURNO root]$ cat /etc/services | grep printer
printer 515/tcp spooler # line printer spooler
printer 515/udp spooler # line printer spooler
Nei sistemi Unix standard vi sono una serie di programmi che interagiscono con il processo di stampa:
- lpr ha il compito di gestire la coda di stampa
- lpq visualizza la coda di stampa
- lprm rimuove file dalla coda di stampa
- lpc programma di controllo della stampa e stampanti
LPRng di Patrick Powell è un altro software di stampa che migliora alcune funzionalità di sicurezza e portabilità rispetto a lpr.
LPRng può essere integrato con Samba, permette autenticazioni di stampa sicure supportando i principali software di crittografia.
LINK: SOURCE - http://www.ietf.org/rfc/rfc1179.txt?number=1179
LINK: SOURCE - http://www.lprng.com
Tipo Infobox: COMMANDS - Skill Level: 3- INTERMEDIATE - Autore: lorenzo 'lorenz' urbinati - Ultimo Aggiornamento: 2003-06-23 22:16:41
Questo comando permette di visualizzare e modificare i settaggi per le opzioni e i valori di default da riga di comando.
La sua sintassi è complessa può variare a seconda del lavoro che si sta compiendo e può essere riassunta così
lpoptions [opzioni]
Un esempio:
lpoptions -h nome_server -d destinazione/istanza -o opzione=valore .... -o opzione=valore
Se lanciato senza argomenti mostra le opzioni settate per la coda di stampa di default. Le opzioni sono:
-E
: Abilita l'uso di connessioni criptate per comunicare con il server. Occorre aver abilitato il supporto OpenSSL per il server.
-d destinazione/istanza
: Specifica la stampante predefinita per la destinazione dichiarata. Se si utilizza un'istanza che, per chiarire, può essere paragonabile alla definizione di una coda si setta l'istanza come predefinita. Questa opzione sovrascrive la definizione della stampante di default per l'utente corrente.
-h nome_server
: Definisce il server cups con cui interagire.
-l
: Lista tutte le opzioni specifiche di stampa e indica con un simbolo asterisco *
quelle correntemente usate.
-o opzione=valore
: Permette la specifica delle varie opzioni. Con il chiave -l si possono ricavare le opzioni e i loro valori possibili.
-p destinazione/istanza
: Definisce la stampante o un'istanza a cui applicare le opzioni che si specificheranno. Se l'istanza non esiste ne viene creata una con il nome usato.
-r opzione
: Rimuove l'opzione specificata.
-x destinazione/istanza
: Rimuove tutte le opzioni per la destinazione o la coda definita.
Questo comando si appoggia su due distinti file di sistema. Uno, il principale, viene modificato quando l'utente root utilizza il comando e per installazioni di default si trova in /etc/cups/
e si chiama lpoptions
. Le definizioni in questo file coinvolgono tutte le destinazioni/istanze per tutti gli utenti. Per i settaggi del singolo utente queste informazioni sono salvate in un file all'interno della home dell'utente e si chiama .lpoptions
Tipo Infobox: COMMANDS - Skill Level: 2- JUNIOR - Autore: lorenzo 'lorenz' urbinati - Ultimo Aggiornamento: 2003-06-23 22:14:56
Oltre alla utile e pratica interfaccia web la suite Cups integra al suo interno vari comandi per la sua gestione e configurazione. Il comando lpadmin permette di configurare le stampanti e le classi con le rispettive code ed è utile conoscerlo in casi in cui si sia impossibilitati ad usare un browser.
Questo comando è molto utile se si deve abilitare la stampante predefinita, se si deve modificare code o stampanti, per aggiungere o eliminare classi e stampanti. La sua sintassi è
lpadmin [ opzioni ] destinazione/opzioni_stampante
Dove per destinazione si intende una stampante o una classe e le opzioni_stampante vengono specificate come vedremo dopo la chiave -o.
Le opzioni e le variabili settabili non sono moltissime:
-E
: Questa opzione può avere due significati diversi a seconda se utilizzata come opzione prima di ogni altra o di norma in fondo alla riga di comando. Nel primo caso implica l'uso di una connessione criptata con il server. Occorre aver configurato il server per l'uso di OpenSSL. Di norma se usata così necessita dell'opzione -h nome_server. Nel secondo caso abilita o disabilita la stampante, ha un significato equivalente ai comandi enable
e disable
.
-h nome_server
: Permette di specificare il server a cui inviare i comandi.
-c classe
: Aggiunge la stampante dichiarata alla classe.
-i interfaccia
: Si usa per specificare un file di interfaccia in sile System V, generalmente uno script, non può essere utilizzato con l'opzione -P file_PPD
-m modello
: Specifica un file System V o PPD situato nella directory dei modelli generalmente /usr/share/cups/model
.
-o opzione
: Questa chiave è molto importante e raggruppa sotto di se numerose sotto-opzioni per definire particolari specifiche per la coda.
-o nome=valore
: Permette di settare una opzione per un file PPD o una stampante.
-o job-k-limit=valore
: Specifica il limite di grandezza in Kilobyte su una base per singolo utente.
-o job-page-limit=valore
: Specifica il limite massimo di pagine stampabili in un singolo processo di stampa su una base per singolo utente. Le stampe su fronte-retro sono contate come due pagine.
-o job-quota-period=valore
: Specifica il periodo di accesso su una base per singolo utente. Il valore va specificato in secondi.
-r classe
: Rimuove la stampante dichiarata dalla classe. Se si sta eliminando l'ultima stampante di una classe quest'ultima verrà eliminata.
-u allow/deny:utente,utente
: [ -u deny:all; -u allow:none ] Specifica i permessi degli utenti su una specifica stampante.
-v device-URI
: Specifica il percorso per la device usata da una determinata stampante.
-D info
: Permette di specificare una descrizione della stampante.
-L locazione
: Setta una locazione per la stampante specificata.
-P file_PPD
: Specifica un file Postscript Printer Description da usare con la stampante.
-d destinazione
: Setta come default la destinazione per la stampante o la classe dichiarata.
-x destinazione
: Elimina la destinazione per la stampante o la classe dichiarata.
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: lorenzo 'lorenz' urbinati - Ultimo Aggiornamento: 2003-06-23 21:56:29
Aggiungere una stampante in stile BSD in una rete Samba necessita di poche semplici configurazioni. Una volta configurato il sistema di stampa e accertato che tutto funzioni correttamente occorre per lo più lavorare sul file smb.conf.
In questo caso innanzi tutto si dovrà aggiungere alle opzioni [global] del server samba le seguenti direttive:
printing = bsd
printcap name = /etc/printcap
Con queste righe si specifica che si tratta di un sistema di stampa stile BSD e che il percorso del file di definizione delle stampanti è /etc/printcap
.
In seguito si dovranno definire lo share [printers] per le stampanti:
[printers]
comment = All Printers
security = server
path = /var/spool/lpd/lp
printable = Yes
create mask = 0600
browseable = No
e quello per la stampante specifica:
[deskjet]
security = server
path = /var/spool/lpd/lp
printer name = lp
writable = yes
guest ok = yes
printable = yes
print command = lpr -r -h -P %p %s
In questo modo si definisce il comportamento del samba server e con l'opzione print command si dichiara il programma di stampa e i parametri che ne regolano il risultato. In questo esempio si stabilisce inoltre che le autenticazioni sono gestite sulla rete SMB/CIFS da un server preposto ma questo non è obbligatorio.
Assicurandosi che il percorso specificato per la stampante corrisponda a quello inserito nel file printcap con una configurazione di questo tipo si può cominciare a stampare.
Essendo comunque un sistema complesso e ricco di variabili, tra cui ad esempio l'enorme numero di diversi modelli di stampanti in circolazione, è consigliabile fare riferimento alla documentazione ufficiale per configurazioni particolari.
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: lorenzo 'lorenz' urbinati - Ultimo Aggiornamento: 2003-06-23 21:54:11
Per poter usare Cups in una rete windows, permettendo la stampa remota ai client Microsoft oppure usando una stampante condivisa da uno di essi, occorre utilizzare Samba che dalla versione 2.0.6 supporta l'interazione con questo potente sistema di stampa. Dalla versione 2.2 di Samba in poi si ha anche la possibilità di esportare i driver necessari per la stampa con Windows.
Gli accorgimenti da prendere per poter far stampare della macchine windows sulla rete usando una stampante linux configurata con cups non sono molti e riguardando in special modo la configurazione del server Samba.
Innanziutto occorrerà aggiungere alla opzioni globali i seguenti parametri
[Global]
printing = cups
printcap name = cups
A questo punto non dovrebbe essere necessaria alcuna altra configurazione per poter stampare attraverso cups anche se di norma sarà necessario definire anche la sezione [printers]
che permette a Samba di caricare come risorse condivise tutte le stampanti definite nel sistema di stampa e di configurarne alcuni parametri specifici.
[printers]
comment = All Printers
path = /var/tmp
printable = Yes
create mask = 0600
browseable = No
Volendo si può inoltre esportare i driver necessari ai client Windows e a tale scopo viene in aiuto un comodo comando cupsaddsmb che permette di esportare i drivers cups.
Una volta scaricati i driver e copiati nella directory drivers
all'interno della directory radice che di norma si trova in /usr/share/cups
e facendo attenzione perchè i nomi siano in maiuscolo si configura smb.conf aggiungendo lo share [print$] nel modo che segue
[print$]
comment = Printer Drivers
path = /var/lib/samba/drivers
write list = root
create mask = 0664
directory mask = 0775
A questo punto configurate le share [printers]
e [print$]
si può usare il comando cupsaddsmb per esportare i drivers.
Un comando di questo tipo aggiunge i driver a tutte le code di stampa per l'utente root
#cupsaddsmb -U root -a
L'opzione -a serve a specificare tutte le code configurate nel sistema cups.
Questo comando permette anche di aggiungere coda per coda in modo di permettere una configurazione fine della stampa remota per i client windows.
Se invece si desidera raggiungere una stampante condivisa da una macchina Windows usando cups si possono usare due metodi:
Il primo usa l'implementazione del protocollo lpd e il TCP/IP Printing Service di Windows mentre il secondo usa il protocollo SMB/CIFS.
All'interno di /usr/lib/cups/backend/
la directory in cui si trovano quei programmi che permettono a Cups di interagire con le device, dovrebbe trovarsi un link simbolico chiamato smb che punta al comando smbspool
, se non è così è necessario crearlo.
Infine con il comando lpadmin o con l'interfaccia web di amministrazione si creeranno le definizioni delle diverse code e stampanti che usano come device URI delle stringhe nella forma
smb://server/nome_risorsa
smb://workgroup/server/nome_risorsa
smb://user:pass@server/nome_risorsa
Tipo Infobox: PATH - Skill Level: 3- INTERMEDIATE - Autore: lorenzo 'lorenz' urbinati - Ultimo Aggiornamento: 2004-01-21 12:35:14
Il file di configurazione principale del sistema di stampa cups. Gestisce principalmente il comportamento del demone che fornisce i servizi di stampa e di amministrazione attraverso la sua interfaccia web. Permette di definire se occorre l'uso di cifratura delle comunicazioni, definire gli accessi alle risorse del server e se il server debba o meno notificare con messaggi broadcast la sua presenza e le code disponibili sulla rete.
Generalmente a installazione compiuta si ha un esempio di questo file con tutte le opzioni e i loro valori di default all'interno della directory di cups in /etc o dove specificato in fase di compilazione. Le direttive all'interno del cupsd.conf sono davvero molte e se i commenti del file non bastassero la sua documentazione è ampia. In se la sua struttura è uguale a quella di Apache così come la sua sintassi.
I valori di default a parte qualche configurazione fine possono andare benissimo specie in network non troppo grossi e con un traffico di rete medio.
Un file strutturato in questo modo potrebbe andare benissimo per un server in una piccola rete locale:
#cat /etc/cups/cupsd.conf
LogLevel info
Port 631
Browsing Off
BrowseAddress 192.168.0.255
< Location />
Order Deny,Allow
Deny From All
Allow From 127.0.0.1
Allow From 127.0.0.2
Allow From 192.168.0.*
</Location>
In questo caso definisco l'accesso alla radice del sistema cups. Permetto così ai client remoti di stampare attraverso questo server, la location /printers che non è definita perchè "eredita" i settaggi della location radice /. Per questa direttiva non è specificata alcuna autenticazione degli accessi
< Location /admin >
AuthType Basic
AuthClass System
Queste direttive permettono di specificare l'autenticazione per la location /admin basata su una verifica degli utenti nel sistema, appartenenti al gruppo di sistema modificabile con la direttiva Systemgroup. Si specificano sempre racchise in un'istanza < Location>
Order Deny,Allow
Deny From All
Allow From 127.0.0.1
</Location>
Tipo Infobox: DESCRIPTION - Skill Level: 3- INTERMEDIATE - Autore: lorenzo 'lorenz' urbinati - Ultimo Aggiornamento: 2003-06-14 15:24:06
Cups è a tutti gli effetti il sistema di stampa proposto come autorevole sostituto dei metodo di stampa BSD.
Rivoluziona l'intero concetto di stampa, gestendo i filtri in proprio e infatti incorpora molti di questi programmi al suo interno ad esempio una versione specifica di ghostscript.
Il sistema cups utilizza un protocollo derivato da http chiamato IPP (Internet Printing Protocoll, rfc 2568) e incorpora un server http che gli permette di mantenere un'interfaccia amministrativa via web in ascolto sulla porta 631. Per determinare il comportamento di questa interfaccia e in generale del sistema di stampa si lavora sul file di configurazione cupsd.conf
che solitamente si trova dentro /etc/cups
. Questo file ha una sintassi ispirata al file di configurazione di Apache. In questo file si specificano il nome della macchina, il linguaggio di default, i parametri di accesso e la directory radice del sistema, tutti i parametri specifici della applicazione, file di log e comportamenti particolari in caso di eventi differenti.
Cups inoltre gestisce le informazioni necessarie all'elaborazione dati per la specifica stampante usata tramite dei file contenenti istruzioni di tipo MIME, chiamati file PPD e generalmente posti in /usr/share/cups/model/
.
Con cups si è in grado di configurare stampanti locali e inoltre permette di aggiungere stampanti remote sia che utilizzino il protocollo IPP che LPD. Supporta inoltre la stampa via SMB in un network Samba.
Con il comando lpadmin si possono aggiungere od eliminare stampanti logiche, inoltre una volta definite si possono abilitare o disabilitare e si possono definire le policy per i processi di stampa. In questo modo si ha la possibilità di amministrare i comportamenti di una determinata stampante. Se si disabilita una stampante questa continuerà ad accettare comunque i processi di stampa inserendoli nella sua coda e senza stamparli mentre se si è definito che deve rifiutare i processi di stampa non verrà accodata nessuna stampa.
Si possono stabilire inoltre delle classi che riuniscono sotto di se diverse stampanti, permettendo così una gestione anche di gruppo. Se un utente invierà un processo alla classe sarà cups a stabilire a quale stampante va inviato. Le classi accettano gli stessi parametri enable e disable, accept e refuse in modo da permettere una gestione complessiva per gruppi di stampanti logiche. Va tenuto conto tuttavia che le stampanti logiche non subiscono le direttive riferite ad una classe sicchè si può disabilitare una classe ma far elaborare processi di stampa ad una stampante del gruppo.
Le informazioni sulle stampanti e sulle classi vengono memorizzate rispettivamente su i file /etc/cups/printers.conf
e su /etc/cups/classes.conf
, due file che volendo sono editabili a mano ma che generalmente si gestiscono sempre attraverso i comandi di amministrazione tra cui lpadmin.
Per lavorare con cups si utilizzano i comandi standard del sistema BSD, lp o lpr. Per definire code di stampa remote si utilizza una sintassi del genere nome-coda@host-remoto.
Per compatibilità con programmi che potrebbero richiederne la presenza, cups permette di aggiornare il file printcap
e nel caso si desiderasse mantenere intatto questo file per il suo uso con sistemi BSD esiste una direttiva di configurazione che permette di specificarne uno alternativo, anche perchè comunque al suo interno si troveranno le specifiche per le stampanti ma i record classici di specifica delle stesse non sono necessari.
Questo versatile e potente sistema di stampa permette di gestire anche delle direttive per i client.
Il file principale per questo è /etc/cups/client.conf
ma si possono definire direttive per singolo utente in un file chiamato .cupsrc
posizionato all'interno della home directory delllo stesso. Un uso classico di questi file che generalmente sono vuoti può essere quello di specificare un percorso di una stampante predefinita per un utente diversa dalla stampante predefinita sulla workstation.
Tipo Infobox: PATH - Skill Level: 3- INTERMEDIATE - Autore: lorenzo 'lorenz' urbinati - Ultimo Aggiornamento: 2003-06-14 15:36:17
Il file centrale di un sistema di stampa LDP, BSD da cui si definiscono le stampanti, le diverse code a loro assegnate e i filtri da utilizzare. Come tanti file di configurazione si tratta di un file di testo soggetto a particolari regole di sintassi.
In questo esempio si definisce una stampante predefinita chiamata lp o HP Deskjet950 connessa al computer via usb che ha assegnata una coda di stampa nella directory /var/spool/lpd/lp. I backslash servono a dichiarare una continuazione di riga e non sono obbligatori se si usa un sistema di stampa LPRng ma alcuni wizard di configurazione li usano probabilmente per maggiore portabilità.
# Stampante predefinita
lp | HP Deskjet950:\
:lp=/dev/usb/lp0:\
:sd=/var/spool/lpd/lp:\
:sh:\
:mx#0:\
:if=/percorso/del/filtro:
:lf=/var/spool/lpd/lp/log:\
:af=/var/spool/lpd/lp/acct:\
I record sono specifiche per una stampante e defiscono il comportamento della coda.
In questo esempio
lp la device configurata e connessa alla stampante
sh specifica se stampare un foglio separatore tra i differenti processi di stampa e in questo caso è impostato in modo da non stampare nessun foglio.
mx limita la grandezza massima dei file da stampare. Nell'esempio è impostato a zero, nessun limite.
sd specifica il percorso alla cartella utilizzata per la coda di stampa.
if input filter, definisce il filtro usato per la conversione dati.
Per gli ultimi due, il file di log della direttiva lf e il file di registrazione informazioni sui processi di stampa della direttiva af devono prima essere creati perchè il sistema di stampa possa scriverli.
Per aggiungere una coda di stampa remota si utilizzano i record rm e rp.
# Stampante condivisa in rete da un printserver
printserver:\
:sd=/var/spool/lpd/printserver:\
:sh:\
:mx#0:\
:if=/percorso/del/filtro:
:rm=printserver.esempio.com:\
:rp=lp:\
I quali rispettivamente indicano il server remoto su cui è disponibile la coda di stampa e il nome della coda remota da utilizzare. In questo caso si usa una coda remota in stile BSD.
Da notare inoltre che usando lp come nome della stampante si definisce il nome standard della stampante predefinita modificabile attraverso la variabile di ambiente $PRINTER.
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: lorenzo 'lorenz' urbinati - Ultimo Aggiornamento: 2003-06-14 15:31:15
Esistono diversi sistemi di stampa per Linux, oltre al classico lpd o anche detto BSD system, si trovano parecchi progetti diversi che offrono sistemi di stampa. La scelta può essere dettata dalla distribuzione che si sta utilizzando ma nessuno impedisce di installare il proprio. Ovviamente occorre sceglierne uno visto che non si possono utilizzare due sistemi diversi contemporaneamente.
LPD
L'originale e ormai classico BSD Unix Line Printer Daemon, è stato lo standard Unix per anni.
E' praticamente disponibile su ogni versione di Unix e nonostante sia ormai superato è un valido sistema di stampa di base. Con stampanti moderne occorre un ulteriore lavoro di configurazione con l'ausilio di script per i filtri e programmi front-end.
LPD è anche il nome dato al protocollo di stampa descritto nella rfc 1179. Questo protocollo è di fatto lo standard per la comunicazione con networks di stampa.
Se si medita di utilizzare LPD è comunque consigliabile l'uso di LPRng che offre una più evoluta forma di configurazione e supporta la cifratura delle connessioni, praticamente ogni versione di Unix abbastanza recente dovrebbe utilizzarlo ma ognuno aggiunge e modifica per cui è veramente difficile stabilire quale versione di lpd si stia utilizzando.
Riferirsi alla documentazione del sistema operativo Unix installato per approfondimenti.
Esistono diversi sistemi front-end per usare lpd e vista la complessità dell'argomento è più semplice usarne uno per configurare le stampanti. Tra questi xpdq per la sua semplicità è consigliato da Grent Taylor il curatore del Printig-HOWTO ma le principali distribuzioni generalmente forniscono una propria interfaccia per la configurazione.
PDQ
L'autore di questo software ironizza con il significato di questo nome e lo definisce "Print don't Queue". In effetti questo sistema di stampa rivoluziona il concetto di stampa in stile BSD facendo effettuare il lavoro di elaborazione dati alla workstation. In un contesto di rete con un print server a cui si collegano le workstation evita di sovraccaricare di lavoro il server portandolo ad un miglioramento delle prestazioni ed evitando la perdita di processi di stampa. Infatti questo sistema fa effettuare tutto il lavoro di filtraggio all'utente che genera il lavoro. Questo può avere dei difetti in caso di elaborazioni complesse rallentando la macchina su cui si sta lavorando, inoltre con l'uso di particolari driver per stampanti ad alta risoluzione ghostscript deve effettuare tutto il lavoro di traduzione prima che il processo possa essere inviato e si rischia di attendere diversi minuti prima che la stampa inizi.
Nel pacchetto è compreso xpdq un comodo front-end che permette di configurare e aggiungere le stampanti. Maggiori informazioni sul sito del progetto http://pdq.sourceforge.net/.
LPRng
In molti unix recenti si userà questo software che in se migliora e perfeziona il classico lpd aggiungendo features come l'assenza di eseguibili SUID e il supporto di autenticazioni con PGP e Kerberos infatti potrebbe essere considerato un lpd con un occhio in più alla sicurezza.
Inoltre rende la configurazione di network anche molto grossi ( tante workstation, diverse stampanti) più semplice e mantenibile.
Sul sito ufficiale http://www.lprng.com/ si può trovare tutta la documentazione relativa al pacchetto.
PPR
Questo sistema di spooling è dedicato a sistemi di stampa Postscript ma ha la capacità di utilizzare anche ghostscript per l'uso con stampanti.
Maggiori informazioni si possono trovare sul sito http://ppr.sourceforge.net/
CUPS
E' un sistema di stampa che si pone come standard sostitutivo di LPD anche dal punto di vista del protocollo utilizzato, per il quale Cups utilizza una implementazione di IPP (Internet Printing Protocoll) un protocollo simile ad http.
Fornito di interfacce di amministrazione sia web che gui e anche di un'interfaccia a riga di comando è considerato un potente sistema di stampa. Supporta la stampa remota attraverso Samba. Puntando il browser all'indirizzo locale localhost:631
si accede all'interfaccia che permette di aggiungere stampanti, configurarle, controllare i processi in corso e quelli compiuti. Inoltre si può visitare il sito ufficiale all'indirizzo http://www.cups.org/, una sorgente riccha di documentazione e informazioni sui driver.
SOURCE: Printing-HOWTO - http://www.tldp.org/
Tipo Infobox: DESCRIPTION - Skill Level: 3- INTERMEDIATE - Autore: lorenzo 'lorenz' urbinati - Ultimo Aggiornamento: 2003-06-14 15:27:41
Non tutte le stampanti possono essere utilizzate con Linux. Come capire se la propria stampante va bene e dove trovare la relativa documentazione.
Se la propria stampante è una stampante Postscript non si necessita di driver speciali. Nella maggioranza dei casi però si dovrà scoprire se per la propria stampante esiste il driver Postscript che sia in grado di generare dati in un linguaggio comprensibile dal modello che si possiede.
Per capire se la stampante che si possiede è supportata vi sono diverse risorse online dove andare a cercare e ovviamente all'interno della directory dedicata alla documentazione che varia e si può trovare generalmente a partire dalla directory /usr
.
Esiste inoltre un how-to chiamato Printing-HOWTO che se non installato con la distribuzione in uso può essere recuperato a partire dall'indirizzo www.tldp.org, il quale raccoglie realmente quasi tutto quello che occorre sapere per affrontare l'argomento e i riferimenti ad ulteriore documentazione più specifica.
Sul sito www.linuxprinting.org si trova oltre a molta documentazione sull'argomento, il database delle stampanti supportate con i riferimenti ai relativi driver.
Una volta trovati i riferimenti per la stampante occorre capire se il pacchetto Ghostscript installato comprenda anche il driver che serve con il comando gs -h
che ci restituirà una lista dei driver disponibili.
Le ultime versioni di ghostscript comprendono ormai il supporto per quasi tutte la ultime stampanti uscite e si possono trovare ulteriori riferimenti sul sito www.cs.wisc.edu/~ghost/ a meno che non si abbia acquistato un modello che lavora con driver proprietari dipendenti dalla piattaforma (generalmente Microsoft).
Queste stampanti si chiamano GDI; GDI è un'interfaccia di sviluppo concepita da Microsoft per la rappresentazione grafica. Il problema non è rappresentato dall'interfaccia di sviluppo ma dal fatto che queste stampanti sono indirizzabili solo attraverso un linguaggio di stampante proprietario.
Alcune di queste oltre alla modalità GDI supportano, previa configurazione, anche un linguaggio standard. Di solito la modalità viene stabilita al momento dell'installazione, sicchè se si è utilizzato un'altro sistema operativo e si è abilitata la modalità GDI occorre, utilizzando il primo sistema operativo usato, riportarla alla modalità standard. Per alcune di queste stampanti è possibile che esista anche un driver per Linux, fare riferimento alla documentazione acclusa alla stampante e visitare il sito del produttore.
LINK: Linux Printing con Database stampanti supportate - http://www.linuxprinting.org/
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: lorenzo 'lorenz' urbinati - Ultimo Aggiornamento: 2003-06-14 15:20:05
Prima di affrontare i diversi sistemi di stampa esistenti per Linux occorre comprendere il funzionamento dell'interazione tra il sistema operativo e la stampante.
Con Linux si comunica con le stampanti attraverso le code di stampa (print queue).
I dati da stampare vengono memorizzati temporaneamente nella coda da dove lo spooler si occuperà di inoltrarli alla stampante. Spesso i dati da stampare non si trovano nel formato giusto per poter essere inviati direttamente alla stampante e di solito devono prima essere convertiti in un formato comprensibile di modo che possano essere emessi correttamente.
I filtri della stampante si occupano proprio di questo lavoro di traduzione dei dati in un linguaggio comprensibile alla stampante e che permetta di stamparli mantenendo le loro forma originale.
Vediamo alcuni esempi di linguaggi di stampanti standard.
Testo in ASCII: La maggior parte di stampanti è in grado di emettere direttamente testi ASCII.
Postscript: E' il linguaggio standard di Unix/Linux e permette di stampare direttamente su stampanti Postscript. Queste stampanti sono molto costose a causa della complessità di questo linguaggio che costringe ad una laboriosa elaborazione dei dati per giungere al risultato finale. In più a causa di un mero problema di licenze i costi aumentano e vanno tenuti presente in caso si meditasse l'acquisto di una di queste potenti stampanti.
Ghostscript : In realtà non è un linguaggio bensì si tratta di un software che mantiene un database di driver per stampanti e si occupa di tradurre i dati in un linguaggio adatto alla stampante in uso.
Il processo di stampa avviene in questo modo:
1. L'utente o l'applicazione genera un incarico di stampa.
2. I dati vengono memorizzati temporaneamente nella coda di stampa da cui lo spooler li inoltra al filtro della stampante.
3. Il filtro della stampante determina il tipo di dati da stampare. Se i dati non sono Postscript vengono convertiti nel linguaggio standard, ad esempio se si tratta di dati ASCII con il programma a2ps vengono convertiti in dati Postscript. Se la stampante è Postscript i dati vengono elaborati e stampati. Nel caso in cui la stampante non sia Postscript, nella maggioranza dei casi quindi, il programma Ghostscript utilizzando il driver adatto al modello di stampante genera i dati specifici della stampante e li invia in stampa.
4. Una volta che l'incarico di stampa e stato correttamente inviato lo spooler si occupa di cancellare i dati dalla coda di stampa.
HOWTO: The Linux Printing HOWTO - http://ldp.openskills.info/HOWTO/Printing-HOWTO/index.html
HOWTO: The Linux Printing Usage HOWTO - http://ldp.openskills.info/HOWTO/Printing-Usage-HOWTO.html
Tipo Infobox: COMMANDS - Skill Level: 3- INTERMEDIATE - Autore: lorenzo 'lorenz' urbinati - Ultimo Aggiornamento: 2003-06-23 22:20:46
Questo comando della suite Cups permette di monitorare i processi di stampa e visualizzare informazioni sulle stampanti e le code presenti nel server.
Nonostante la presenza della comoda interfaccia web per controllare i processi e lo stato delle stampanti cups include lpstat una comoda utility da riga di comando.
La sua sintassi:
lpstat -opzioni
Se usato senza alcuna opzione lpstat stampa a monitor tutti i jobs accodati per l'utente che lo ha lanciato. Le sue opzioni sono uguali per alcuni casi a quelle usate in lpadmin e lpoptions.
-E
: Forza l'uso di connessioni cifrate con il server.
-h nome_server
: Specifica il server con cui si vuole interagire.
-a stampante/i
: Mostra lo stato di una o più stampanti restituendo informazioni sull'accettazione dei processi. Se usato senza specificare la stampante mostra tutte le stampanti e le istanze/code configurate e che accettano i jobs.
-c classe/i
: Mostra le classi e le stampanti comprese nella loro dichiarazione. Se usato senza argomenti mostra tutte le classi presenti nel sistema e se non fosse presente neanche una classe non restituisce nessun output.
-d
: Mostra la destinazione di default.
-l
: Mostra una lista delle stampanti, delle classi e dei jobs attivi.
-o destinazione/i
: Mostra le code di stampa per la o le destinazioni specificate. Se si omette la destinazione mostra tutti i jobs in coda.
-p stampante/i
: Mostra le stampanti e se accettano o meno i processi di stampa. Se usato senza specificare una o più stampanti mostra queste informazioni per tutte le stampanti.
-r
: Permette di verificare se il server CUPS sia attivo o no.
-R
: Mostra l'ordine dei jobs nella coda di stampa.
-s
: Mostra un sommario dello stato delle stampanti includendo la destinazione di default, le classi e le stampanti membro per ciascuna classe e tutte le stampanti associandole alla loro device-URI. E' equivalente ad usare insieme le opzioni -d, -c e -v.
-t
: Mostra un elenco completo di informazioni di stato per tutte le stampanti e le classi definite, è equivalente ad usare insieme le opzioni -r, -d, -c, -a, -p, -v e -o.
-u utente/i
: Permette di verificare i processi di stampa attivi per l'utente specificato. Se usato omettendo l'utente si ottiene una lista dei jobs associati all'utente corrente.
-W numero_job
: Permette la verifica dello stato dei jobs in esecuzione e di quelli eseguiti.
Reti miste Windows - Linux |
Casi e situazioni comuni con rete miste Windows-Linux - WINS - PDC. |
Tipo Infobox: SAMPLE - Skill Level: 3- INTERMEDIATE - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2005-04-29 11:10:09
Segue un esempio di configurazione di un PDC di un dominio NT4 che agisce anche da Master Browser e Wins Server.
[global]
workgroup = LAB42
server string = Samba Server PDC
log file = /var/log/samba/%m.log
max log size = 50
socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192
printcap name = /etc/printcap
# Segue una direttiva comoda per creare automaticamente degli account macchina su /etc/passwd quando un nuovo computer joina il dominio
add machine script = /usr/sbin/useradd -d /dev/null -g machines -s /bin/false -M %u
# Le direttive che indicano a Samba di fare il PDC e permettere il login sugli ost che fanno parte del dominio
domain master = Yes
domain logons = Yes
# Direttive riguardanti la funzionalità di Master Browser
preferred master = Yes
os level = 250
# Direttive riguardanti la funzionalità di Wins Server
dns proxy = No
wins support = Yes
idmap uid = 16777216-33554431
idmap gid = 16777216-33554431
[homes]
comment = Home Directories
read only = No
browseable = No
[printers]
comment = All Printers
path = /var/spool/samba
guest ok = Yes
printable = Yes
browseable = No
[Documenti]
path = /tmp
guest ok = Yes
[Privato]
comment = Documenti Privati
path = /var/log
read only = No
Tipo Infobox: DESCRIPTION - Skill Level: 3- INTERMEDIATE - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2005-04-29 11:43:32
Samba può svolgere le attività di PDC, Primary Domain Controller, in una rete di client Windows (o mista).
Le funzionalità supportate sono:
- Login sul dominio (domain logon) per client Windows NT/2000/XP.
- Sicurezza a livello utente per client Windows 9x/ME (questi client non hanno il concetto di dominio, ma supportano il login su un dominio)
- Roaming profiles, per avere utenti che possono loggarsi su client diversi mantenendo il proprio ambiente.
- Browse list e master browser
- Policy di sistema in stile NT4
- Possibilità di ottenere la lista degli utenti/gruppi presenti sul PDC Samba
- Gestione Active Directory (introdotta, parzialmente, dalla versione 3.x)
Le funzionalità ancora non supportate sono:
- Possibilità di fare da Domain Controller in un dominio ADS (Active Directory)
- Utilizzo come BDC (Backup Domain Controller) in un dominio NT4 con PDC Windows.
Per configurare Samba come PDC di un dominio Windows è necessario:
1- Installare Samba su un server Linux/Unix (tramite sorgenti o RPM)
2- Configurare smb.conf
3- Creare directory per i roaming profile e i domain logons
4- Aggiungere le login e le password per gli utenti e le macchine del dominio
5- Configurare i client Windows per unirsi al dominio.
Le istruzioni che seguono si applicano sia alla versione 2 che alla 3, tranne per la parte relativa alla direttiva add machine script.
1- Installazione di Samba
L'installazione per un PDC non richiede particolari accorgimenti rispetto ad una normale installazione di Samba, tramite rpm o tar.gz.
2- Configurazione di smb.conf
Vediamo un esempio del file di configurazione di un Samba PDC. Varie impostazioni sono comuni a qualsiasi installazione Samba, alcune sono specifiche per un PDC (domain master = yes , security = user , encrypt passwords = yes), altre sono necessarie se si vuole supportare l'esecuzione sul client di uno script al login (logon script e condivisione [netlogon] ) o l'uso dei roaming profiles (logon path , condivisione [profiles]).
Valutare attentamente quest'ultima opzione: ha la comodità di separare l'uso di una singola macchina fisica da un singolo utente (tutti gli utenti possono usare tutte le macchine), ma comporta ad ogni login il caricamento o la sincronizzazione di tutti i "Documents and Settings" Windows fra il client e il server, con un potenziale carico sul network non indifferente e maggiori attese da parte dell'utente.
Fatto il login l'utente agirà sui file della macchina locale, che poi vengono a loro volta sincronizzati con quelli sul server al momento del logout.
[global] ; Settaggi generali (validi su ogni configurazione Samba)
workgroup = intranet E' il nome del Dominio e/o del Workgroup
netbios name = serverone E' il nome del server Samba
server string = Samba PDC - Versione %v La descrizione del server
socket options = TCP_NODELAY IPTOS_LOWDELAY SO_SNDBUF=8192 SO_RCVBUF=8192 Settings TCP consigliabili di default
; Settaggi per un PDC e un master browser
os level = 64 Imposta il valore con cui partecipare alle elezioni per il Master Browser
preferred master = yes Forza una elezione quando si avvia e vi partecipa con maggiori possibilità di successo
local master = yes Fa partecipare Samba alle elezioni per il Local Master Browser
domain master = yes La riga che indica a Samba di operare com PDC
; Gestione utenti e sicurezza
security = user Impone di autenticare gli utenti localmente. E' necessario su un PDC Samba
encrypt passwords = yes Cripta login e password in fase di autenticazione: obbligatorio su un PDC e necessario per interagire senza problemi con client Windows NT o successivi
domain logons = yes Permette ai client Windows di loggarsi sul dominio autenticandosi con il server Samba
hosts allow = 127.0.0.1 192.168.0.0/255.255.255.0 Permette l'accesso solo dal localhost e dalla rete 192.168.0.0/24
add machine script = /usr/sbin/useradd -d /dev/null -g machines -s /bin/false -M %u (Solo su Samba 3) Aggiunge automaticamente al sistema l'account di una nuova macchina che entra nel dominio
; Gestione logging
log file = /var/log/samba/log.%m Definisce la posizione dei log e indica di creare log diversi on i nomi delle rispettive macchine client
log level = 2 Imposta a 2 il livello di logging, visualizzando tutti i file letti e scritti
max log size = 50 Imposta a 50 Kb la dimensione massima dei file di log
; User profiles, home directory e netlogon (a queste configurazioni in [global] vanno SEMPRE aggiunte le definizioni rispettivamente di [homes] , [profiles] e [netlogon] riportate più sotto
logon home = \\%L\%U\.profile Definisce la posizione del file .profile (per client Win9x/ME) in \\nomeserver\nomeutente
logon path = \\%L\profiles\%U Definisce la posizione della directory profiles (per client WinNT/2k/XP) in \\nomeserver\profiles\nomeutente
logon drive = H: Crea l'unità di rete H: al login su client Windows
logon script = netlogon.bat Specifica quale script eseguire sul client ad ogni login. Lo script viene cercato nella directory definita nella condivisione [netlogon]
[homes] Share speciale, che definisce la posizione delle home directory
comment = Home Directory per ogni User Descrizione della condivisione
browseable = no E' bene non rendere pubblicamente visibile le home dei singoli utenti
writeable = yes Ogni utente deve poter scrivere nella sua home
[profiles] Share speciale dove vengono scritti i file di profilo per i gli utenti roaming. Ad ogni login e logout il suo contenuto viene sincronizzato con la cartella dei documenti sul computer locale (C:/Documenti/NomeUtente.dominio)
path = /home/profiles La directory locale sul server Samba dove sono salvati i profili. Qui vengono, automaticamente, create delle sottodirectroy con i nomi degli utenti
writeable = yes I profili sono sincronizzati con il client al login e al logout e devono essere scrivibili
browseable = no Come per le home, anche i profili non devono essere visibili agli altri utenti
create mask = 0600 La maschera con cui vengono creati i file: Pieni permessi all'owner, nessun permesso per gli altri utenti
directory mask = 0700 La maschera con cui vengono create le directory: per l'owner devono essere anche eseguibili (sfogliabili)
[netlogon] Condivisione speciale che contiene gli script che vengono eseguiti sui client Windows al login sul dominio. Devono essere eseguibili su Windows e possono essere utilizzati per varie operazione di amministrazione centralizzata (backup di dati locali, aggiornamento programmi o antivirus, mappatura di nuove condivisioni di rete ecc.)
path = /home/netlogon La directory sul server in cui sono contenuti, in sottodirectory con nome uguale al login dell'utente, gli script definiti con la direttiva "logon script"
read only = yes Questi script devono essere accessbili solo in lettura...
write list = @admin ... tranne agli utenti del gruppo (@) admin
browseable = no Questa è una condivisione di servizio che è inutile mostrare agli altri utenti
3- Creazione delle directory supplementari
E' importante creare directory per i profile e i netlogon definiti in smb.conf con nomi e permessi corretti.
Sulla base della configurazione di esempio sopra riportata vanno eseguite le seguenti operazioni sul server Samba (come root):
[root@sambaserver root]# groupadd admin Si crea il gruppo admin, composto da utenti che possono editare gli script di logon. Considerare che questi script sono particolarmente importanti, in termini di sicurezza, visto che vengono eseguiti sui client Window
[root@sambaserver root]# mkdir -m 0775 /home/netlogon Crea la directory /home/netlogon, leggibile ed eseguibile da utti gli utenti e modificabile solo da owner e ownergroup
[root@sambaserver root]# chown root.admin /home/netlogon Si imposta root come owner della directory e admin come gruppo (con permessi di scrittura)
[root@sambaserver root]# mkdir /home/profiles Si crea una directory per i profili (uguale a quella definita in smb.conf)
[root@sambaserver root]# chmod 1757 /home/profiles Si imposta lo sticky bit e si rende questa directory scrivibile da root e le sue sottodirectory gestibili dai rispettivi utenti, senza possibilità di modificare quelle degli altri
4- Aggiungere login e password
Gestire gli utenti di un dominio con Samba non è una procedura immediata e vanno considerati alcuni aspetti fondamentali:
- Samba utilizza come file delle password /etc/samba/smbpasswd
(di default) che presenta una riga per ogni utente (sia di un dominio che di un server con normale autenticazione). In questo file è prevista una riga (con login , password criptata e altri dati) per ogni utente.
- Per ogni utente presente sul file smbpasswd DEVE essere presente un rispettivo utente sul normale file degli utenti Unix /etc/passwd
. Questo perchè Samba agisce sul sistema locale come un normale processo Unix e, anche se viene eseguito come root, accede al filesystem con i permessi degli utenti secondo quanto configurato.
- Quando Samba agisce come PDC, oltre a creare una login (sia in /etc/samba/smbpasswd che in /etc/passwd) per ogni utente, si deve creare una login speciale per ogni macchina del dominio. Questa login, definita trust account o computer account ha il nome NetBios del computer seguito dal segno dollaro ($). Al primo login da parte del trust account viene generata una sorta di password che viene utilizzata per autenticare le comunicazioni fra il PDC e il client e assicurarsi che non ci siano altre macchine che possano unirsi al dominio con lo stesso nome NetBios.
- La gestione delle login (sia per gli utenti che per i computer, sia su smbpasswd che su passwd) può essere fatta in maniera manuale, con i comandi sotto riportati, o in maniera automatica, tramite l'uso della direttiva add user script
- Windows9x/ME anche se possono eseguire un login su un dominio, NON sono strutturati per essere dei client a pieno titolo di un dominio in quanto non ne rispettano le logiche di sicurezza e trust.
Per aggiungere un computer account al dominio manualmente seguire la seguente procedura:
[root@sambaserver root]# groupadd machines Crea un gruppo per tutte i computer account
[root@sambaserver root]# useradd -g machines -d /dev/null -s /bin/false nomeNetBios$ Aggiunge al sistema una login, membro del gruppo machines, senza home directory, senza shell, con nome uguale al nome NetBios della macchina seguito dal segno $. Notare che questo account serve a Samba per agire sul sistema, ma è bene che non possa essere utilizzato per una normale login.
[root@sambaserver root]# passwd -l nomeNetBios$ Viene messo un lock sulla password, in modo da lasciarla nulla e non renderla modificabile se non da root
[root@sambaserver root]# smbpasswd -a -m nomeNetBios Si crea un nuovo computer account per /etc/samba/smbpasswd e si imposta la relativa password. L'opzione -a permette di crearlo, se non esiste, l'opzione -m indica che si tratta di un machine account, il nome NetBios della macchina da aggiungere NON va seguito da $, in questo caso, in quando questo carattere viene aggiunto automaticamente. Non è necessario ricordare la password inserita in quanto viene gestita direttamente fra PDC e client del dominio
Se si vuole evitare di aggiungere a mano un nuovo account per ogni macchina del dominio, si può provare ad aggiungere, come sopra indicato, la seguente riga a smb.conf (valida solo per Samba 3):
add machine script = /usr/sbin/useradd -d /dev/null -g machines -s /bin/false -M %u
Verificare il path e la sintassi del comando useradd e assicurarsi di avere il gruppo machines già creato (groupadd machines
).
Per aggiungere a mano le login degli utenti (non delle macchine) del dominio:
[root@sambaserver root]# useradd pippo Aggiunge l'utente al /etc/passwd di sistema
[root@sambaserver root]# passwd pippo Gli imposta la password. Se l'utente non deve accedere al sistema Unix, impostagli una shell nulla in /etc/passwd
[root@sambaserver root]# smbpasswd -a pippo Aggiunge l'utente pippo a /etc/samba/smbpasswd e gli imposta la password
NOTA: Quando si configura un client Windows NT/2k/XP per farlo diventare parte di un dominio, viene richiesta una password di amministratore. In questa situazione si deve usare la login di root con la relativa password, per cui è necessario aggiungere l'utente root anche al smbpasswd:
[root@sambaserver root]# smbpasswd -a root
Notare che se per caso si cambia la password di root con passwd e non la si aggiorna anche con smbpasswd, la password che fa testo è la seconda, quella presente in /etc/samba/smbpasswd.
Per questo ed altri motivi, una volta creato un utente è buona cosa fare in modo che la sua password sul sistema Unix sia allineata con quella usata da Samba via rete. Per fare in modo che una password cambiata tramite Samba si rispecchi anche sul /etc/passwd locale si devono aggiungere a smb.conf simili righe di configurazione:
unix password sync = yes Imposta la sincronizzazione delle password fra Samba e il sistema Unix locale
La procedura di matching per gestire le richieste in output di passwd. Assicurarsi che sul proprio sistema siano utilizzate le stesse parole
passwd program = /usr/bin/passwd %u La riga di comando per cambiare la password Unix. %u è la login dell'utente
passwd chat = *New*UNIX*password* %n\n *Retype*new*UNIX*password* %n\n *Enter* new*UNIX*password* %n\n *Retype*new*UNIX*password* %n\n *passwd: *all* authentication*tokens*updated*successfully*
Purtroppo questa procedura non funziona al contrario: se si cambia con passwd una password Unix, si dovrà cambiarla a mano con smbpasswd per tenere sincronizzata la password Unix con la password Samba.
5- Configurazione dei client
La configurazione di un sistema Windows per unirsi ad un dominio, varia a seconda della versione:
Windows 95/98/ME:
- Verificare che sia installato il "Client per Reti Microsoft" fra le proprietà di rete
- Assicurarsi che il Client per Reti Microsoft sia selezionato come protocollo di rete primario (Pannello di Controllo -> Rete -> Logon di rete primario).
- Andare su Pannello di Controllo -> Rete -> Client per reti Microsoft -> Proprietà -> Logon su Dominio NT.
- Se si è configurata su smb.conf l'opzione "add user script", selezionare il checkbox Crea un Computer Account, altrimenti creare a mano sul server Samba un utente con il nome della macchina Windows.
- Inserire il nome del proprio dominio e cliccare OK.
Windows NT:
- Andare su Pannello di Controllo -> Rete -> Identificazione Rete -> Proprietà
- Selezionare Dominio e inserire il nome del prorio dominio
- Selezionare Crea un Computer Account
- Alla richiesta della password di un amministratore inserire la login e la password di root, ricordarsi che l'utente root deve essere aggiunto a smbpasswd.
- Dovrebbe comparire un messaggio che ci da il benvenuto sul dominio.
Windows 2000:
Le procedure sono uguali a quelle per Windows NT tranne che i settaggi di rete sono trovati sotto Pannello di Controllo -> Sistema -> Identificazione Rete (oppure, sul Desktop, cliccare col tasto destro del mouse sull'icona Risorse del Computer, selezionare Proprietà, cliccare sulla tab Identificazione Rete e sul tasto Proprietà).
Windows XP:
La procedura con Windows XP è più complessa (lamentele a Microsoft che usa cambiare le specifiche e le implementazioni dei suoi protocolli anche per rendere più complicata l'interoperabilità con soluzioni alternative).
Notare che solo XP Professional Edition può essere usato per far parte di un dominio, Windows XP Home Edition non può far parte di un dominio (Samba o Windows based).
- Aprire l'editor delle policy di Sicurezza Locale (Start->Pannello di controllo->Strumenti di Aministrazione->Criteri di protezione locali->Criteri locali->opzioni di protezione)
- Disabilitare la voce "Domain member: Digitally encrypt or sign secure channel (always)" (Membro di dominio: aggiunta crittografia of irma digitale ai dati del canale protetto (sempre) )
- Disabilitare la voce "Domain member: Disable machine account password changes" (Controller di dominio: rifiuta cambio password account computer)
- Disabilitare la voce "Domain member: Require strong (Windows 2000 or later) session key" (Membro di dominio: richiesta chiave di sessione avanzata (Windows 2000 o versioni successive) )
- Scaricare da Samba.org (http://de.samba.org/samba/ftp/docs/Registry/WinXP_SignOrSeal.reg) la patch per il registro WinXP_SignOrSeal. Per applicarla cliccare due volte sul file .reg e rispondere Si alle domande
- A questo punto ci si può unire al dominio come su Windows NT/2000: Tasto destro su Risorse del Computer, selezionare Proprietà, Nome del Computer e tasto Modifica uppure cliccare su Identificazione di Rete ed eseguire il Wizard.
Linux/Unix:
Anche dei sistemi Linux, ovviamente, possono unirsi ad un dominio con un PDC Samba e se sono dei file server, si può configurare Samba per permettere l'autenticazione tramite il dominio.
Su smb.conf ci devono essere le seguenti righe:
[global]
workgroup =
netbios name =
security = DOMAIN
encrypt passwords = Yes
password server =
preferred master = False
domain master = False
Ovviamente sul PDC Samba deve essere creato un computer account per il nostro Samba locale (con il nome specificato in netbios name) e, anche in questo caso, il computer locale deve preventivamente unirsi al dominio, con una procedura che è paragonabile a quelle viste sopra per client Windows. Sul Linux/Unix locale basta scrivere:
smbpasswd -j
Bisogna fornire la password di root del PDC Samba (ricordarsi che è la password salvata in smbpasswd e non in passwd/shadow, nel caso fossero diverse).
LINK: Sistemisti Indipendenti: Samba: PDC in rete locale - http://www.sistemistiindipendenti.org/modules.php?name=News&file=article&sid=42
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2006-03-26 18:57:04
Le possibilità di interoperabilità fra client e server Windows e Samba in una rete locale per la condivisione dei file sono varie e si possono raggruppare in due scenari di riferimento:
- Windows server con client misti (Windows, Linux/Unix, MacOS).
- Linux/Unix Samba server con client misti.
E' possibile configurare Samba per:
- Operare come Primary Domain Controller (PDC di un dominio NT, ma non Domain Controller di una Active Directory) di una rete mista, gestendo anche i profili di macchine Windows e il login sul dominio. Una simile opzione permette ad una macchina Linux con Samba di eseguire le stesse funzioni di un PDC di dominio NT.
- Operare come normale File Server per client misti. I metodi di autenticazione possono essere vari e a seconda del metodo utilizzato possono essere necessari diversi interventi sul server e sui client.
- Operare come Domain Member con le funzionaità di file server accessibili sulla base delle login e password del dominio. Samba può essere parte sia di un dominio NT (Samba 2 o superiori) che di una Active Directory (Samba 3 o superiori)
- Operare come WINS server (o essere configurato per utilizzare un altro WINS server). In questo caso la configurazione è semplice, rapida ed efficace, non presentando particolari problemi di compatibilità e interoperabilità.
- Operare come Master Browser in una rete mista.
Samba NON permette invece di gestire una macchina come Backup Domain Controller di un PDC Windows, non può essere un Backup Browser e non può essere un Secondary Wins Server.
Sul lato client, invece, non ci sono particolari problemi ad usare Samba per connettersi a server Windows o Linux: la condivisione di rete remota viene normalmente montata sul file system locale e ci si può normalmente accedere con i permessi concessi.
LINK: The Story of Samba: Linux's Stealth Weapon - http://www.linux-mag.com/1999-09/samba_01.html
HOWTO: The Samba 2.2 PDC FAQ - http://de.samba.org/samba/ftp/docs/htmldocs/samba-pdc-faq.html#AEN263/htmldocs/samba-pdc-faq.html
Samba security |
Breve rassegna della security history, problematiche attuali |
Tipo Infobox: TIPS - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2003-05-21 21:33:58
Nell'Aprile 2003 è stata resa pubblica una seria vulnerabilità in Samba che, sfruttando un buffer overflow nella funzione call_trans2open di trans2.c, permette di eseguire comandi arbitrari su un server remoto con i permessi con cui gira il processo Samba: root.
Praticamente il tipo di security bug più temibile e pericoloso.
Questa vulnerabilità (codice CVE: CAN-2003-0201) segue di poche settimane un altro problema nella gestione di pacchetti SMB/CIFS frammentati (CVE: CAN-2003-0085), un problema dovuto alla non corretta gestione del cambio delle password criptate (CVE: CAN-2002-1318) e un problema nella gestione di file reg (CVE: CAN-2003-0086).
Queste vulnerabilità sono effettivamente gravi e vengono solo parzialmente mitigate dal fatto che è improbabile che esistano server Samba direttamente accessibili da Internet.
Sono affette dal Remote Buffer Overflow della CAN-2003-0201 tutte le versioni precedenti la 2.2.8a (che rispetto alla 2.2.8 ha solo la correzione dell'errore) e la 2.0.10a. Non ne sono affette le versioni del branch 3.x. Anche il progetto parallelo Samba-TNG è vulnerabile fino alla versione 0.3.2 esclusa.
Sono già in circolazione degli exploit in grado di sfruttare questa vulnerabilità, per cui è assolutamente necessario aggiornare il proprio Samba server ad una versione patchata o installare ex-novo una versione corretta.
I casi citati sono indicativo di quanto sia importante avere sistemi aggiornati e, possibilmente, server Samba non direttamente accessibili in Internet.
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2003-06-05 19:10:18
A titolo esemplificativo elenchiamo una lista di vulnerabilità di Samba nel corso degli anni.
L'elenco è stato ottenuto da Security Focus, in alcuni casi si applica a strumenti di gerstione (SWAT), in altri, in particolare gli ultimi elencati, si applica a versioni di Samba recenti, che vanno assolutamente patchate.
2003-05-16: Samba Multiple Unspecified Remote Buffer Overflow Vulnerabilities
2003-05-16: Samba 'call_trans2open' Remote Buffer Overflow Vulnerability
2003-05-16: Samba SMB/CIFS Packet Assembling Buffer Overflow Vulnerability
2003-05-14: Samba REG File Writing Race Condition Vulnerability
2003-05-02: Samba Server Encrypted Password Buffer Overrun Vulnerability
2002-09-18: Samba Improperly Terminated Struct Buffer Overflow Vulnerability
2001-11-03: Samba Remote Arbitrary File Creation Vulnerability
2001-06-28: Samba Insecure TMP file Symbolic Link Vulnerability
2000-11-01: SAMBA SWAT Symlink Vulnerability
2000-11-01: SAMBA SWAT Logging Failure Vulnerability
2000-11-01: SAMBA SWAT Logfile Permissions Vulnerability
2000-09-11: NT Authentication PAM Modules Buffer Overflow Vulnerability
1999-07-21: Samba Pre-2.0.5 Vulnerabilities
1999-06-01: SAMBA Long Password Buffer Overflow Vulnerability
SOURCE: Security Focus - Vulnerabilities Archive - http://online.securityfocus.com/bid
Fonte: OpenSkills.info | Rilasciato sotto licenza Creative Commons Attribuzione - Non commerciale - Condividi allo stesso modo. |