Blog

Pubblicato il

Aggiornare un servizio senza fare restart

Una esigenza un po’ da nerd che nasce dalla necessità di minimizzare, in numero, le interruzioni dei servizi che stiamo esportando. Poniamoci nelle condizioni di dover aggiornare un servizio e successivamente effettuare un reboot perchè abbiamo anche patchato il kernel. In queste intricate condizioni non avremmo modo di interrompere il servizio meno di 2 volte, sia che decidessimo di effettuare l’aggiornamento prima oppure dopo il reboot.

Però, se stiamo usando un sistema basato su systemd abbiamo la possibilità di sfruttare le sue potenti peculiarità:

La strategia è semplice quanto geniale: consiste nell’unire sinergicamente le funzionalità:

Override

si tratta di una tecnica che consente la modifica della configurazione di default di un servizio

–runtime

Si tratta di un particolare attributo che rende temporaneo (fino al prossimo reboot) l’oggetto della modifica

ExecCondition

Si tratta di una funzionalità che pone sotto condizione l’esecuzione del servizio.


Unendo insieme queste funzionalità saremo in grado di applicare temporaneamente una modifica al servizio che gli impedirà di ripartire, anche a fronte di un aggiornamento apt.

Vediamo insieme un esempio pratico applicando la strategia descritta al servizio tor.service.

systemctl edit --runtime tor.service

In seguito a questo comando si aprirà un editor tramite il quale potremo applicare la modifica temporanea che ci serve, aggiungendo le seguenti righe che poi saranno sovrascritte alla configurazione di default:

[Service]
ExecCondition=/bin/false

Oppure, in alternativa, con un effetto forse ancora migliore:

systemctl mask --runtime tor.service

Riassumendo:
abbiamo temporaneamente aggiunto alla configurazione del nostro servizio una condizione che gli impedirà di essere eseguito fino al prossimo reboot, quindi siamo ora liberi di applicare l’aggiornamento che coinvolge il servizio senza temere che per questo venga riavviato: potremo contare dopo il reboot, quando cioè la configurazione temporanea che ne impedisce l’esecuzione sarà stata rimossa che il servizio sarà finalmente eseguito nella modalità aggiornata.

Pubblicato il

Client IRC con php – Semplice applicazione pratica

Il protocollo IRC è uno dei protocolli standardizzati più semplici in circolazione. La sua implementazione basilare consta di poche righe di codice. In questo spazio si intende fornire lo spunto dal quale, volendo, procedere autonomamente.

Il protocollo è specificato in RFC 1459 e successivamente modificato nelle RFC 2810 2811 2812 2813 7194

La più semplice implementazione che ho potuto definire consta di poche righe di codice:

<?php

$NL  = chr(012);
$CR  = chr(015);
$EM  = $CR.$NL;

$irc['network'] = "chat.freenode.net";
$irc['ircPort'] = 6667;
$irc['channel'] = "#satnogs";
$irc['usrName'] = "Nome";
$irc['reaName'] = "Mio Nome";
$irc['usrNick'] = "mioNick";
$irc['timeout'] = 1;

if(!$socket = fsockopen($irc['network'], $irc['ircPort'], $errno, $errmsg))
    die("$errmsg ErrNo($errno)\n");
if(!stream_set_blocking($socket, true))
    die("$errmsg ErrNo($errno)\n");

fputs($socket, "USER ".$irc['reaName']." Casa Telecom.net :".$irc['usrName'].$EM);
fputs($socket, "NICK ".$irc['usrNick'].$EM);

stream_set_timeout($socket, $irc['timeout']);
while(true) {

    $rawdata = fgets($socket, 512);
    if($last_err = error_get_last()) {
        echo "\rError occurred:\n";
        flush();
        var_dump($last_err);
        break;
    }

    if(!$rawdata) continue;

    $IRCMSG = preg_replace("/^([^".NULL.$NL.$CR."]*)".$CR.$NL."$/", '${1}', $rawdata);

    if(substr($IRCMSG, 0, 1) == '@')
        list($tags, $IRCMSG)    = explode(' ', substr($IRCMSG, 1), 2);
    if(substr($IRCMSG, 0, 1) == ':')
        list($source, $IRCMSG)  = explode(' ', substr($IRCMSG, 1), 2);
    list($command, $parameters) = explode(' ', $IRCMSG, 2);

    if(isset($source)) {
        if(preg_match("/!.*@/", $source))
            list($Snick, $Suser, $Shost) =
                explode(' ', preg_replace("/^([^!@]*)!([^!@]*)@(.*)$/", '${1} ${2} ${3}', $source), 3);
        else
            $Snick = $source;
    }

    if(isset($Snick))
        echo "($Snick) ";
    echo "[$command] {".$parameters."}\n";

    switch($command) {
    case "001":
        fputs($socket, "JOIN ".$irc['channel'].$EM);
        break;
    case "PING":
        fputs($socket,"PONG $parameters".$EM);
        break;
    }
}

?>

Fondamentalmente, eseguita la connessione al network IRC specificato nelle dichiarazioni iniziali, Il client comunica le proprie generalità e attende che vengano accettate con l’invio da parte del server di un “$command” di tipo “001”.
Quindi esegue il collegamento (Join) ad un canale e rimane in ascolto continuando a gestire la risposta ai PING di verifica inviati dal server.
I parametri delle dichiarazioni iniziali sono piuttosto stabili, ma possono e devono essere adattati alle personali preferenze.
Quello che si ottiene è lo spacchettamento al livello base di tutti i messaggi ricevuti dal server e la loro presentazione a schermo.
Si esce dal ciclo infinito con CTRL-C e si è liberi di arricchire il codice secondo le proprie esigenze e fantasie fino alla definizione di un completo Bot-Client IRC.
Buon divertimento.

Pubblicato il

Dovecot overview

Cos’è Dovecot ?

Per avere un’idea dell’operatività di Dovecot, seguiamo il percorso di un tipico messaggio di posta dal momento della sua creazione fino alla consegna e vediamo come Dovecot si inserisce in quest’ambito.

Per cominciare, qualcuno nel mondo crea un messaggio di posta usando un programma di posta elettronica. In generale, un programma che consente a qualcuno di inviare e ricevere e-mail è noto come Mail User Agent o MUA. Esempi di MUA tipici includono Mozilla Thunderbird e Microsoft Outlook Express. Qualunque cosa sia stata usata, è stato creato un messaggio e inviato al server di posta dell’utente. Il server di posta non interagisce con le persone direttamente come fa il MUA; piuttosto, il suo compito è ricevere e-mail da un altro computer e inviarlo ovunque sia necessario, oppure gestire la consegna finale dell’e-mail. Il “server di posta” è noto come Mail Transfer Agent o MTA. Quindi, il MTA controlla il messaggio per determinare il destinatario e interroga i server DNS (Domain Name System) per scoprire quale altro MTA è responsabile della gestione della posta elettronica per il destinatario in questione. Invia quindi il messaggio a quel MTA. A questo punto, il messaggio è passato dal computer dell’utente remoto al proprio server di posta e ha raggiunto il server di posta che gestisce la posta elettronica per il destinatario in questione. Ora cosa succede?
A seconda della configurazione di rete, è possibile che il messaggio venga inoltrato a un altro MTA. Ma ad un certo punto, un MTA si assumerà la responsabilità del messaggio e diventerà responsabile della consegna. A questo punto, il MTA trasmetterà il messaggio a un Mail Delivery Agent o MDA. Fondamentalmente, un MDA è responsabile per l’archiviazione del messaggio sul disco. Alcuni MDA fanno anche altre cose, come filtrare la posta o consegnare a sottocartelle. Ma è l’MDA che memorizza la posta sul server.
Ora è il momento di controllare la posta. Avvia il tuo MUA e interroga il tuo server di posta utilizzando uno dei protocolli standard: IMAP o POP3. Il server di posta conferma la tua identità, quindi recupera l’elenco dei messaggi dall’area di archiviazione della posta e li restituisce al MUA. Il tuo MUA quindi ti presenta questi messaggi e ora puoi leggere la tua posta

Diagramma di flusso tra moduli della funzionalità mail

Allora, dove si inserisce Dovecot in tutto questo ?

Come server IMAP e POP3, Dovecot fornisce un modo per Mail User Agents (MUA) per accedere alla loro posta. Pertanto, quando MUA di un utente contatta il server di posta, il software che risponde a tale richiesta è un server IMAP o POP3. I server IMAP e POP3 accettano le richieste dei MUA e rispondono a tali richieste accedendo ai messaggi di posta elettronica memorizzati sul server e trasmettendoli al MUA tramite IMAP o POP3. Dovecot è un programma che può fornire le funzionalità del server IMAP e POP3.
Inoltre, Dovecot fornisce funzionalità per la consegna del messaggio finale con il suo Local Delivery Agent o LDA. L’ADL è responsabile della memorizzazione dei messaggi di posta elettronica nell’archivio dei messaggi. La consegna locale può essere effettuata dal MTA stesso, o da un agente di recapito della posta separato o utilizzando l’LDA di Dovecot. La scelta viene effettuata in base ai requisiti della particolare installazione del server.
Si noti che Dovecot NON è responsabile della ricezione della posta da altri server. Dovecot gestisce solo i messaggi di posta elettronica (a) che escono dall’archivio dei messaggi locale, che escono dai client IMAP e POP3 e (b) i messaggi che sono già stati ricevuti dal MTA e che devono essere memorizzati nell’archivio dei messaggi locale. IMAP e POP3 sono i due protocolli comuni utilizzati dai MUA per comunicare con i server di archiviazione della posta. POP3 è comunemente usato dagli utenti che non hanno una connessione ad alta velocità al server di posta. Uno dei principi di base di POP3 è che i MUA scaricano la posta e la memorizzano localmente (sul computer dell’utente) – e quindi eliminano la posta dal server. IMAP è progettato per LAN e connessioni ad alta velocità. L’intento di IMAP è contattare il server ogni volta che è necessario leggere un determinato messaggio (a parte la memorizzazione nella cache specifica di MUA). Dovecot ha un numero di ottimizzazioni per IMAP che lo rendono eccezionalmente efficiente per la maggior parte degli scenari IMAP.
Dovecot non è coinvolto nella ricezione effettiva di e-mail. Tale funzionalità è fornita da un MTA come Exim o Postfix. Una volta che l’e-mail è stata ricevuta nel MTA, allora può essere consegnata direttamente dal MTA o da un’altra MDA, oppure può essere passata al LDA di Dovecot per la consegna finale. La scelta dipende da vari fattori specifici dell’installazione.
Esistono due principali opzioni di archiviazione della posta nel mondo *NIX:
1) mbox
2)Maildir

mbox memorizza più messaggi, a volte centinaia o migliaia di messaggi, in un singolo file. Maildir memorizza ciascun messaggio in un file separato. mbox e Maildir hanno un ampio supporto per vari software di posta elettronica inclusi MTA e MDA, e sono entrambi pienamente supportati da Dovecot. Dovecot offre anche alcuni formati di archiviazione della posta: sdbox e mdbox.
La configurazione di Dovecot comprende principalmente il tipo di archiviazione della posta, la posizione di archiviazione della posta, l’elenco degli utenti e l’elenco delle password.
Dovecot supporta attualmente una varietà di tipi di utente e password, tra cui *Nix passwd, shadow, PAM, LDAP, SQL e vpopmail. In genere è preferibile selezionare un tipo supportato da tutte le parti della soluzione di posta generale, inclusi MTA, MDA e Dovecot.
Dovecot funziona al meglio quando l’e-mail viene consegnata utilizzando l’LDA Dovecot che, se utilizzato, deve essere “collegato” al MTA in modo che l’MTA “sappia” come passare correttamente i messaggi all’LDA Dovecot. Quando si utilizzano i formati di archiviazione della posta di Dovecot (sdbox / mdbox), deve essere utilizzato Dovecot LDA poiché solo Dovecot può accedere a tali formati.
Facoltativamente, è possibile utilizzare una configurazione di consegna esistente senza utilizzare l’LDA Dovecot, utilizzando Dovecot esclusivamente come server IMAP e / o POP3. Tuttavia in tali casi è necessario prestare attenzione per garantire che MDA e Dovecot cooperino correttamente (ad esempio, quando si utilizza mbox è fondamentale utilizzare una strategia di mbox-locking compatibile per evitare il danneggiamento dei file mbox).

Pubblicato il

Prompt Unix colorato usando PuTTY.

Avendo notato che il terminale standard aperto su un sistema Linux fornisce di default all’interfaccia il prompt colorato, ho voluto ottenere lo stesso risultato anche sui terminali aperti da altri S.O. usando come interfaccia PuTTY.

Normalmente, se si apre una sessione terminale remota usando PuTTY sui sistemi moderni, si ottiene una finestra che è in grado di gestire i colori, ma che presenta comunque un prompt monocromatico.

In Internet si trovano facilmente guide con procedure che suggeriscono la modifica del file ~/.bashrc per ottenere un prompt colorato. Non gradendo la modifica non necessaria di componenti standard (come .bashrc), ho voluto cercare una maniera non invasiva e più corretta per ottenere il prompt colorato.

Vediamo insieme come:
cominciamo con il controllare il nostro .bashrc e andiamo alla ricerca della variabile color_prompt.
Nel mio caso si è subito evidenziata la soluzione del problema: la variabile $TERM deve assumere il valore xterm-color oppure *-256color per indurre automaticamente l’ambiente a presentare il prompt colorato. Oppure, in alternativa, levando il commento che precede la variabile force_color_prompt, si forza il settaggio (ultima riga commentata nella parte di .bashrc riportata).

# set a fancy prompt (non-color, unless we know we "want" color)
case "$TERM" in
xterm-color|*-256color) color_prompt=yes;;
esac

# uncomment for a colored prompt, if the terminal has the capability; turned
# off by default to not distract the user: the focus in a terminal window
# should be on the output of commands, not on the prompt
#force_color_prompt=yes

Andiamo ad impostare il parametro corretto in PuTTY per far si che la variabile $TERM si valorizzi nella maniera che vogliamo: nella sotto-sezione Data impostiamo nel campo xterm-type string il valore xtem-256color

Si torni su Session per salvare la sessione, e aprendo un nuovo terminale otterremo il prompt colorato che volevamo, senza modificare un solo bit sul sistema remoto:

Chapeau !
Su altri sistemi Linux, con altri settaggi, gli ambienti possono presentarsi in maniera diversa, e il procedimento dovrà essere adattato, ma resta comunque valido.

Pubblicato il

w3schools.com

Vorrei eleggere w3school.com sito patrimonio dell’umanità.

La pluralità è importante per diversificare, ciò nonostante mi chiedo la ragione dell’esistenza di siti alternativi sull’argomento.

w3school.com
THE WORLD’S LARGEST WEB DEVELOPER SITE

Pubblicato il

Ve lascerà l’amaro in bocca !

Era dai tempi dell’imperatore Augusto
delle malefatte de Nerone
che a Roma nun scoppiava sto trambusto
E se incendiava la pubblica opinione

So diventati tutti giustizieri
Rimbombano le grida dei partiti
Compresi quelli che fino all’altro ieri
Cor malaffare se so arricchiti

Contro la nuova giunta comunale
Arza la voce er ladro malandrino
E chi ha lucrato sulla capitale
Da oggi s’è scoperto paladino

Arza la voce chi s’è magnato tutto
Chi s’è venduto pe’ trenta denari
Chi s’è scoperto che era farabutto
Chi ha fatto er servo dei palazzinari

Arza la voce er giuda traditore
Chi t’ha mentito anno dopo anno
Chi a Roma nostra ja strappato er core
Chi ce s’è fatto ricco co l’inganno

Arza la voce er furbo parassita
Chi t’ha rubato er voto col ricatto
Chi ha fatto affari co la malavita
Chi co la mafia c’ha steccato er piatto

Chi t’ha tradito dopo l’elezioni
Chi t’ha ridotto servo der sistema
Chi te fa crede che c’ha le soluzioni
E invece è stato la causa der problema

Chi t’ha lasciato co le spalle ar muro
Chi t’ha condotto sul ciglio del burrone
Chi t’ha sottratto i sogni dal futuro
Chi t’ha scippato pure la pensione

Arza la voce er servo giornalista
Filosofi banchieri imprenditori
Urla indignato er finto moralista
Predicatori e falliti educatori

Er polverone che avete sollevato
Ve lascerà l’amaro nella bocca
E capirete che Roma v’ha sgamato
E che Virginia Raggi nun se tocca

(Marco Camerini)
Fonte

Pubblicato il

Guide Linux related su Web

Sono disponibili le seguente guide in ambiente Linux:

Manuale interattivo APACHE
Guida avanzata di scripting Bash
Linux Administration Made Easy
Guida dell’amministratore di sistema di Linux
Manuale avanzato di vi
Manuale di riferimento Coreutils 9.0
Manuale di riferimento Bash
Manuale di riferimento Screen
Manuale di riferimento Rsyslog

Si tratta principalmente di traduzioni di guide rilasciate da Linux Documentation Project Guides
Inoltre una raccolta di documenti HTML locale

Pubblicato il

Aggiornare chiavi GPG scadute

Se, in qualche circostanza, rilevate errori relativi alla validità delle chiavi GPG, per esempio “The following signatures were invalid: KEYEXPIRED”, suggeriamo le seguenti modalità di verifica e gestione:

apt-key list è il comando che elenca caratteristiche e chiavi GPG installate sul sistema, quindi per evidenziare quelle eventualmente scadute:

sudo apt-key list | grep "expired: "

nel caso di match, le chiavi GPG effettivamente scadute saranno elencate:

pub   2048R/479BC94B 2013-08-26 [expired: 2018-08-25

La parte evidenziata in grassetto, dopo lo “/” è la KEY e dovrà essere riportata per essere aggiornata:

sudo apt-key adv --keyserver keys.gnupg.net --recv-keys [KEY]

Se preferite gli automatismi, e ne comprendete l’operatività, potete usare il seguente comando:

sudo apt-key list  | grep "expired: " | sed -ne 's|pub .*/\([^ ]*\) .*|\1|gp' | xargs -n1 sudo apt-key adv --keyserver keys.gnupg.net --recv-keys
Pubblicato il

Transmission su QNAP

A partire dalla versione 4.3.2 del Firmware QNAP, Transmission smette di essere compatibile e scompare dal repository QNAP.

Una possibile soluzione è quella di installare qTransmission, disponibile su repository terze parti. Di seguito i passi da seguire se si decide di intraprendere questa strada.

Per iniziare accediamo al NAS e avviamo AppCenter, quindi andiamo a modificare le sue impostazioni facendo click sulla ruota dentata posta in alto a destra:

Fare click sulla ruota dentata evidenziata dal circolo rosso

Portiamoci sul tab Archivio e aggiungiamo il nuovo QNAP Club Store. associandogli il seguente URL: https://www.qnapclub.eu/it/repo.xml

Dal tab Archivio aggiungiamo il nuovo repository

Terminata l’operazione, se tutto è andato bene, troveremo nella pagina dell’APP Ceter l’icona del repository QNAP Club Store appena configurato.

QNAP Club Store

Ora che il repository è impostato basterà cercare Transmission e installarlo sul nostro NAS.