Dopo l’intervento al ginocchio, eccomi di nuovo a scrivere su IdeaFactory e voglio iniziare scusandomi con tutti quelli che mi hanno scritto o contattato via Facebook e non hanno ancora ricevuto risposta.

Purtroppo non è facile stare seduti davanti ad un PC (anche se è un bel iMac) dopo un intervento al ginocchio.

Ma veniamo all’articolo. Forse il titolo non rende l’idea ma l’argomento di oggi risponde a questa domanda: avendo due connessioni ad Internet collegate alla mia Linux box che funge da router, come faccio a gestire il fail di una delle connessioni inoltrando a quella funzionante il traffico?

Per meglio comprende l’articolo, vi consiglio di spulciare velocemente due miei vecchi post:

1. iproute: load balance verso 2 gateway (IMPORTANTISSIMO!)
2. iproute: load balance verso 2 gateway della stessa rete

Rinfrescata la memoria sul routing di Linux, passiamo ad analizzare la logica di funzionamento dello script. Read the rest of this entry »

Con questo articolo inauguro una serie di post dedicati alla configurazione di un server di posta moderno, sicuro ed affidabile basato, ovviamente, su Debian ed equipaggiato con ciò che io personalmente reputo il meglio.

Premetto che non basterà seguire alla lettera ciò che io descriverò per ritrovarsi una black box che una volta installata gestisce la posta fin che morte non vi separi. Dico questo perché un servizio come la posta elettronica va seguito e monitorato e spesso è necessario un sistemista (io [pubblicità progresso gratuita ]) che abbia capacità di problem solving notevoli per far sì che la fruizione del servizio non sia mai interrotta.

Cosa ci occorre per mettere su un servizio di posta elettronica con i fiocchi?

Ecco la lista della spesa:

• Un mail transfer agent (MTA)
• Un server POP3 ed IMAP
• Un validissimo sistema anti-spam
• Un aggiornatissimo sistema anti-virus
• Una moderna webmail
• Tool di corredo

Il miglior MTA? Postfix!

Nel mondo opensource c’è una vasta gamma di server SMTP ma i più famosi ed utilizzati sono:

• Postfix
• Exim
• qmail
• Sendmail

Read the rest of this entry »

L’editor di default di Debian Lenny è Nano. Io non ho niente contro Nano ma preferisco Vi, quindi, quando il mio server utilizza un editor, ad esempio quando viene richiamato un crontab -e, voglio il mio editor prferito.

Ci sono due strade percorribili, una è la Debian Way l’altra è quella maccheronica. Descriverò quella alla Debian Way e lascio ai commenti l’opportunità di descrivere quella maccheronica!:)

Con il comando update-alternatives –config editor vien fuori:

Ci sono 5 alternative che forniscono `editor'.
Selezione Alternativa
-----------------------------------------------
1 /bin/ed
+ 2 /bin/nano
3 /usr/bin/vim.tiny
4 /usr/bin/vim.basic
* 5 /usr/bin/vim.nox
Premi invio per mantenere il default[*], o inserisci il numero da selezionare:

Facile no? Ovviamente bisogna aver installato l’editor che si vuole impostare come default altrimenti la lista mostrata sarà molto misera.

Adesso chiedo a voi: qual’è il modo maccheronico per cambiare editor?

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!:)