In un precedente articolo ho descritto come Modificare l’header di Apache, in questo articolo  vediamo come non mostrarlo affatto.

Molto probabilmente richiamando una URL inesistente o non gestita dall’applicazione che risiede sul nostro server, viene fuori qualcosa del genere:

In base a quanto descritto nell’articolo Modificare l’header di Apache, possiamo variare l’output che mostra le informazioni del server web.

Per non mostrare assolutamente niente, basta editare il file del virtualhost ad esempio /etc/apache2/sites-available/default, ed impostare la direttiva ServerSignature ad Off in questo modo:

ServerSignature Off

Ovviamente va restartato Apache prima di vedere attuata tale modifica.

Quali sono le opzioni di ServerSignature? Eccole:

• Off: Non visualizza niente nel footer
• On: Visualizza le informazioni come specificato in ServerTokens
• On: Visualizza le informazioni come specificato in ServerTokens ed aggiunge il link all’indirizzo e-mail specificato con ServerAdmin

Buon week-end a tutti.

Spero che tutti quelli che leggono IdeaFactory fanno uso di SSH per la connessione remota ai server. Non usate ASSOLUTAMENTE telnet o simili! I motivi sono ovvi…

Fatta la breve ma doverosa premessa veniamo al dunque.

Può capitare di ritrovare la propria sessione SSH terminata a causa di timeout per mancato utilizzo, come si risolve tutto ciò? Basta editare il file /etc/ssh/ssh_config (su sistemi Debian based) ed inserire questi parametri:

TCPKeepAlive yes
ServerAliveInterval 5
ServerAliveCountMax 60

Così facendo il client SSH terrà viva la connessione al server e quindi noi possiamo andarci a fare un meritato bagno caldo.

Ieri per purissimo caso ho scoperto l’ennesimo utilissimo comando da linea di comando: mtr.

Usiamo molto spesso traceroute e quotidianamente ping, con mtr li abbiamo entrambi e l’utilità è di facile spiegazione.

Spesso capita che il nostro adorato server dedicato non è raggiungibile per problemi di rete dovuti ai molteplici router intermedi, con mtr possiamo monitorare tutti gli hop intermedi e verificare ciò che accade quando li si attraversa.

Visto che è di certo l’ultimo post del 2009, vi aguro un felice anno nuovo!

p.s.: un ringraziamento a Iuri per avermi fatto notare mtr.

Il vostro adorato server vuole andare in ferie? Troppe richieste in arrivo? Bene limitiamole con iptables:

iptables -N rate-limit
iptables -A rate-limit -p tcp -m conntrack --ctstate NEW -m limit --limit 3/min --limit-burst 3 -j RETURN
iptables -A rate-limit -j DROP
iptables -I INPUT 1 -p tcp --dport 80 -j rate-limit

Cosa fa tutto ciò? Vediamolo in dettaglio…

Con “iptables -N rate-limit“, viene creata una nuova catena nella tabella di default che è quella “filter“.

Attraverso il connection tracking (modulo conntrack), diciamo a netfilter di limitare il numero di connessioni della catena “rate-limit” a 3 al minuto e il parametro “–limit-burst” indica il massimo burst (raffica) prima che il limite  li respinga.

Il 4 comando è autoesplicativo: quello che arriva alla catena “rate-limit” va cestinato!

L’ultima riga fa in modo che tutto ciò che sia diretto alla porta 80 (web) vada a finire nella catena “rate-limit” così è possibile controllare il numero di connessioni in entrata e se necessario respingerne alcune.

Ovviamente il mio è solo un esempio che può essere personalizzato in base alle proprie esigenze.

Buon iptables e felice anno nuovo!:)

Ho aggiornato WordPress in automatico dal pannello di controllo ma, come sempre mi succede, il plugin Lifestream, che utilizzo per mostrare su questo sito i feed provenienti dai più comuni social network, ha causato problemi.

Appena completato l’aggiornamento il sito non si vedeva più, ma siccome conosco la bestia, mi sono connesso in FTP ed ho rinominato la directory lifestream che si trova tra i plugins di WordPress.

Il sito è immediatamente tornato on-line e WordPress ha disattivato il plugin perché non lo trovava più, ho rinominato la directory di nuovo in lifestream e riattivando il plugin mi son trovato davanti ad un bel “Fatal error: Allowed memory size of…“.

Soluzione? Editare il file wp-settings.php situato nella root del sito e modificare il valore di WP_MEMORY_LIMIT:

if ( !defined('WP_MEMORY_LIMIT') )
define('WP_MEMORY_LIMIT', '32M');

Io l’ho settato a 64M e adesso funziona, forse TopHost si arrabbierà un pò…

Uso Eclipse (su Ubuntu) per scrivere codice PHP e dopo le difficoltà funzionali ormai superate, lo trovo uno strumento molto comodo.

Ho da poco scaricato la versione “Galileo” con PDT, ma installando il plugin Subclipse (versione 1.4) , necessario per avere il supporto SVN, ricevevo sempre questo errore: unable to load default svn client.

Ho risolto installando libsvn-java:

sudo apt-get install libsvn-java


e poi editando il file eclipse.ini presente nella directory di Eclipse ed aggiungendo queste righe:


-Djava.library.path=/usr/share/java/
-Djava.library.path=/usr/lib/jni/


Subito dopo la direttiva “-vmargs“.
Dopo il riavvio del programma, tutto sembra funzionare.

Buon coding a tutti!

Di solito viene usato il target LOG per impostare la scrittura dei log su file quando facciamo delle regole con iptables. Ma è comodo avere un file (a volte mastodontico) da anzalizzare? Meglio avere i dati in un database MySQL e lavorarci sopra attraverso tool appositi.

Ci viene in aiuto ULOG, un tool che lavora in userspace e permette   quindi,   tramite un   programma   in   continuo   ascolto,   di   gestire   tali   informazioni nella maniera più disparata.

Procediamo con l’installazione dei pacchetti necessari:

apt-get install ulogd ulogd-mysql

Adesso va creato il database con gli opportuni privilegi. Tralascio questa fase perché è banale, specie con phpMyAdmin.
Le struttura della tabella è scritta nel file /usr/share/doc/ulogd-mysql/mysql.table, quindi lo carichiamo nel database appena creato con:

mysql -u <utente> -p <nome_db> < /usr/share/doc/ulogd-mysql/mysql.table

Procediamo con la configurazione di ULOG editando il file /etc/ulogd.conf.

Nella sezione plugins va decommentato:

plugin="/usr/lib/ulogd/ulogd_MYSQL.so"

visto che i dati andranno sul un db MySQL.

Impostiamo l’account per l’accesso al database:

[MYSQL]
table="ulog"
pass="<password>"
user="<user>"
db="<database>"
host="localhost"

Bene, riavviamo ULOG:

/etc/init.d/ulogd restart

Proviamo il tutto impostando una regola di iptables con il target ULOG:

iptables -t nat -I POSTROUTING -s 192.168.1.0/24 -o eth0 -j ULOG

In breve: tutto quello che proviene dalla classe lan 192.168.1.0/24 ed esce dall’interfaccia eth0 (verso Internet) e quindi viene nattato, lo registriamo su MySQL. Ovviamente possiamo impostare qualsiasi regola di firewall con target ULOG per testarne il funzionamento.

MySQL ha qualche record in più? Bene, abbiamo finito.