Archivi tag: debian

Modificare l’MTA di default su CentOS 6

SO: Linux, , , , , , , ,

Ho già parlato più volte di exim, definendolo come uno degli MTA più performanti in circolazione.

Exim_logo.jpg

Essendo la mia formazione sui sitemi *nix derivata principalmente da Debian, preferisco usare il suddetto MTA piuttosto che postfix e qmail. Badate bene, però, che non sto facendo un paragone tra i software in questione: la mia è semplicemente una scelta di ordine pratico, ovvero preferisco avere a che fare con applicativi che già conosco perchè, in tal modo, posso ridurre notevolmente la percentuale di errori ed i tempi di troubleshooting.

Dopo questa breve premessa veniamo al dunque: da 3 anni a questa parte i server sotto la mia gestione sono principalmente dei CentOS/Red Hat, i quali si avvalgono di postfix come MTA di default.

Per sostituire postfix con exim occorre seguire questi step:

1) scaricare exim mediante il comando:

 [root@server exim]#  yum install exim

2) stoppare postfix e rimuoverlo dalla lista dei demoni da avviare al boot:

[root@server exim]#  service postfix stop 

[root@server exim]#  chkconfig –level 2345 postifx off

3) abilitare exim come MTA di default ed avviarlo:

[root@server exim]#  chkconfig –level 2345 exim on

[root@server exim]#  service exim start

A questo punto possiamo fare una prova di invio email. Per far ciò è sufficiente utilizzare il comando mail e dare un’occhiata al file di log associato ad exim, ovvero /var/log/exim/main.log.

Se effettivamente l’invio avviene mediante exim il suddetto file dovrebbe popolarsi di nuove entry. Nel caso in cui ciò non avvenga possiamo lanciare il comando:

[root@server exim]# alternatives –display mta

per visualizzare gli MTA disponibili e successivamente procedere con la scelta del Mail Transfer Agent da utilizzare:

[root@server exim]# alternatives –config mta

There are 2 programs which provide ‘mta’.

  Selection    Command
———————————————–
*+ 1           /usr/sbin/sendmail.postfix
   2           /usr/sbin/sendmail.exim

Enter to keep the current selection[+], or type selection number: 2

digitando semplicemente 2.

Tentiamo l’invio di una nuova email e tutto dovrebbe funzionare correttamente.

A presto.

Wake on LAN su minipc ASUS at-3iont-i

Networking, , , , , , , , , ,

Premesso che il BIOS installato sulla mobo in questione presenta numerose limitazioni, ho deciso comunque di provare ad abilitare il Wake On LAN sul mio server casalingo (Debian).

Per prima cosa, ho provato ad individuare la voce del BIOS che mi consentisse di abilitare la suddetta funzionalità. Purtroppo però, la specifica versione di software presente sulla mia scheda madre non consente di attivare esplicitamente il WOL dalla scheda Gigabit Ethernet integrata, cosa che mi ha lasciato a dir poco sbalordito.

Nonostante ciò è comunque possibile:

1) abilitare il Wake dopo la pressione di un determinato tasto della keyboard PS2 (funzione testata da me personalmente e funzionante);

2) abilitare il Wake da mouse PS2;

3) abilitare il Wake da interfaccia PCI-Express;

4) schedulare il Wake in una data/ora ben precisa.

Ma queste opzioni non includono, ovviamente, il WOL da scheda di rete integrata.

Ho dunque creato uno scrip che consentisse di attivare la suddetta funzione, utilizzando un tool esterno, ovvero ethtool.

Per installarlo è sufficiante digitare:

nightfly@nightbox:~$ sudo apt-get install ethtool

Ad installazione completata, creiamo un file di testo vuoto:

nightfly@nightbox:~$ sudo nano autowol

il cui contenuto dovrà essere:

#!/bin/bash
ethtool -s eth0 wol g
exit 0

salviamo il file e rendiamolo eseguibile:

nightfly@nightbox:~$ sudo chmod a+x autowol

Lanciamo lo scrip e verifichiamo che il WOL mediante magic packet (g) sia effettivamente attivo:

nightfly@nightbox:~$ sudo ethtool eth0

Lo stralcio di output che ci interessa dovrà essere simile al seguente:

Supports Wake-on: pumbg
        Wake-on: g

La prima riga ci conferma che la scheda eth0 supporta il WOL, la seconda riga, invece, ci fornisce informazioni sul tipo di WOL attivo (magic packet).

Fatto ciò, è necessario che tale opzione venga attivata automaticamente ad ogni avvio del sistema (e prima dello spegnimento). Per fare questo si può copiare il suddetto scrip nella directory /etc/init.d e successivamente usare il comando:

nightfly@nightbox:/etc/init.d$ update-rc.d -f autowol defaults

Bene, a questo punto ho deciso di dare inizio ai miei test. Per prima cosa ho scaricato un software gratuito (per ambienti Windows e dotato di GUI) in grado di forgiare i magic packet. Il tool a cui mi riferisco è questo:

http://www.depicus.com/downloads/WakeOnLanGui.zip

La cosa bella di questo software è che ci permette di scegliere la porta (UDP) su cui inoltrare il magic packet, riuscendo dunque ad aggirare eventuali restrizioni imposte dal PAT (in questo modo potremo utilizzare il WOL anche da remoto).

wolgui.jpg

Per accendere il nostro server da remoto sarà sufficiente riempire i campi richiesti dal suddetto tool, ovvero:

1) MAC address della macchina che si vuole avviare;

2) indirizzo IP (oppure hostname) pubblico della macchina;

3) porta (UDP).

Solitamente il WOL si avvale della porta 7 o 9 (UDP) ma vi consiglio di forwardare porte più alte in modo da complicare la vita ad eventuali scrip kiddie (sai che piacere lasciare il server spento e ritrovarselo accesso di punto in bianco?).

In definitiva, i test hanno dato questo esito:

1) se il server è spento (S5) il WOL non funziona;

2) se il server è sospeso (S3, con RAM alimentata), il WOL funziona;

3) se il server è ibernato (S4), ovvero il dump della RAM si trova nell’area swap dell’HD, il WOL non funziona.

Quindi, così come stanno le cose il WOL è quasi inutile. Nei prossimi giorni vedrò di aggiornare il BIOS ed eventualmente di acquistare una scheda Ethernet PCI-Express.

Speriamo bene.

PS: per maggiori dattagli sui power state ACPI potete consultare questa pagina.

PPS: potete operare con i power state direttamente da CLI utilizzando il comando pmi action <stato>.

AGGIORNAMENTO del 16/04/2020

Finalmente ho trovato un po’ di tempo per lavorarci e credo di aver risolto il problema. E’ stato sufficiente modificare un’opzione del BIOS, ovvero:

Power -> Control EuP

portandola da “Enabled” a “Disabled”.

In soldoni, tale opzione (Energy Using Products), se abilitata, disattiva il WOL quando il sistema si trova in S4 (hibernate) oppure in S5 (spento).

Ergo, adesso il WOL funziona anche a PC spento.

Proxy Squid e Calamaris

Sicurezza, , , , , ,

Consentire agli utenti della propria LAN l’accesso ai siti Web mediante Proxy è ormai una prassi. Analizzare i relativi file di log, però, risulta essere un’operazione piuttosto tediosa, indi per cui è molto conveniente utilizzare dei software in grado di generare i report degli accessi in modo automatico.

Se il proxy che avete tirato su è Squid e non implementate meccanismi di autentica (ad esempio NTLM), potete usare Calamaris come generatore di report.

 

squidlogo.jpg

L’installazione e la configurazione di tale applicativo è piuttosto semplice. Infatti, per installarlo basta digitare:

nightfly@nightbox:~$ sudo apt-get install calamaris

Ad installazione completata possiamo passare alla configurazione. Per prima cosa creiamo la directory calamaris in /var/www:

nightfly@nightbox:~$ sudo mkdir -p /var/www/calamaris

e le sottodirectory daily, weekly e monthly, in cui andranno salvati rispettivamente i report giornalieri, settimanali e mensili:

nightfly@nightbox:~$ sudo mkdir -p /var/www/calamaris/daily

nightfly@nightbox:~$ sudo mkdir -p /var/www/calamaris/weekly

nightfly@nightbox:~$ sudo mkdir -p /var/www/calamaris/monthly

assegniamo i giusti permessi alle directory appena create:

nightfly@nightbox:~$ cd /var/www

nightfly@nightbox:/var/www$ sudo chown nomeutente:nomeutente -R calamaris

A questo punto possiamo creare il primo report, digitando:

nightfly@nightbox:/var/www$ sudo calamaris -a -F html /var/log/squid/access.log > /var/www/calamaris/index.html

Il report sarà visualizzabile mediante browser alla seguente URL:

http://vostroippubblico/calamaris

Per consentire solo ad uno specifico utente la visualizzazione del report occorre creare un file .htaccess recante le seguenti direttive:

 AuthName "Sezione riservata Calamaris"
 AuthType Basic
 AuthUserFile /etc/apache2/passwd
 Require user <nome utente>

ovviamente il nome utente deve essere presente nel file /etc/apache2/passwd (in cui viene fatta l’associazione tra l’utente stesso ed il digest della sua password)

Infine, modifichiamo il file /etc/apache2/apache2.conf in questo modo:

 <Directory /var/www/calamaris>
 AllowOverride AuthConfig
 </Directory>

Salviamo il tutto e riavviamo apache:

nightfly@nightbox:~$ sudo service apache2 restart

Per ricevere i report direttamente via email (oltre ad ottenere il loro salvataggio nelle dir precedentemente create), possiamo modificare come segue il file cron.conf posizionato in /etc/calamaris:

daily:vostro.indirizzo@email.it:/var/www/calamaris/daily/index.html:both:'Squid giornaliero'
 weekly:vostro.indirizzo@email.it:/var/www/calamaris/weekly/index.html:both:'Squid settimanale'
 monthly:vostro.indirizzo@email.it:/var/www/calamaris/monthly/index.html:both:'Squid mensile'

Inoltre, sarà necessario abilitare la cache di squid (se non l’avete ancora fatto), decommentando la direttiva cache_dir presente nel file /etc/squid/squid.conf.

Done, enjoy!

Visualizzare data ed ora di un comando nel file history

SO: Linux, , , , ,

Qualche tempo fa, mentre lavoravo per il progetto PIT di Selex Communications, è sorta la necessità di appurare quale degli n-NOC avesse lanciato un reboot su uno dei router di una sala operativa. Poichè l’history non riportava alcuna informazione sulla data e sull’ora di esecuzione del comando, non è stato possibile individuare con certezza il responsabile, quindi la questione si è risolta con un nulla di fatto.

Alla luce di ciò, ho deciso di scrivere questa breve guida in cui viene descritta la procedura per aggiungere il datetime al file history nell’ambito dei sistemi basati su Debian.

bash

Per prima cosa è necessario editare il file nascosto .bashrc presente nella home dell’utente:

nightfly@nightbox:~$ sudo nano .bashrc

e successivamente aggiungere la seguente direttiva:

HISTTIMEFORMAT="%d/%m/%y %T "

In particolare, ogni comando presente nel file history verrà proceduto da giorno (%d), mese (%m), anno (%y) ed ora (%T) (nel formato hh:mm:ss) di esecuzione dello stesso.

Subito dopo esserci riloggati alla macchina digitiamo il comando:

nightfly@nightbox:~$ history

il cui output sarà simile al seguente:

 1995  12/06/11 11:49:57 history
 1996  12/06/11 11:49:57 exit
 1997  12/06/11 11:26:49 history
 1998  12/06/11 11:50:17 sudo nano .bashrc
 1999  12/06/11 11:53:13 history

Ovviamente tale operazione non è retroattiva, nel senso che tutti i comandi precedenti alla modifica del file .bashrc avranno come datetime quello della modifica stessa.

A presto.