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.

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).

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.

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

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

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

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

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.

SSH con autenticazione basata su certificato.

Il protocollo SSH offre un ottimo livello di sicurezza, ma quando viene esposto ad accesso da Internet diventa rapidamente oggetto di frquenti tentativi di accesso non autorizzati.

Utilizzare certificati basati su chiave pubblica e privata è senz’altro una buona misura di sicurezza che è opportuno considerare.

la crittografia asimmetrica, o più semplicemente la crittografia basata su chiave pubblica e privata è alla base dei moderni sistemi di crittografia ed è opportuno conoscerne almeno i principi di funzionamento. A tale scopo può essere utile la definizione disponibile su Wikipedia: Crittografia asimmetrica. Sostanzialmente dalla chiave privata può essere derivata la chiave pubblica, ma non viceversa e un contenuto crittografato con chiave privata può essere portato in chiaro tramite la chiave pubblica così come un contenuto crittografato tramite chiave pubblica può essere portato in chiaro tramite la chiave privata. Se pubblico un contenuto crittografato tramite chiave privata, tutti coloro che sono in possesso della chiave pubblica saranno in grado di riportare in chiaro la mia pubblicazione avendo inoltre la certezza che sia stato davvero io a fare la pubblicazione, inquanto solo io sono in possesso della chiave privata. D’altra parte, se pubblico un contenuto crittografato tramite la chiave pubblica di un’altra persona, solo lei sarà in grado di riportare in chiaro la mia pubblicazione, indipendentemente dal numero delle persone che la riceveranno. Sono possibili anche combinazioni complesse dei metodi di crittografia citati, ma quelli elencati sono e restano fondamentali.

Tecnologicamente il funzionamento di questo tipo di crittografia è particolarmente robusto, a patto che il proprietaro custodisca in maniera adeguata il suo certificato (contenente la chiave privata e la possibilità di derivare la chiave pubblica). Se anche solo un’altra persona entrasse in possesso della chiave privata tutto il meccanismo sarebbe compromesso e non offrirebbe più acuna garanzia.

Vediamo ora come utilizzare questo meccanismo per autenticarci in maniera sicura usando ssh.

La prima operazione da effettuare è la generazione della coppia di chiavi pubblica e privata che saranno successivamente utilizzate. Il collegamento avviene da un client verso un server. La chiave privata va custodita sul client ed è quindi naturale che venga generata proprio sul client. Il comando da impartire per la generazione delle chiavi è: ssh-keygen -t (tipo di codifica) -b (lunghezza della chiave) -C (un commento che ci aiuti ad identificare il prorietario del certificato) verranno usati user-id e nome del client che useremo per il collegamento.

ssh-keygen -t rsa -b 2048 -C <user-id>@<client-name>

Poiché non lo abbiamo dichiarato, il comando ci chiede in maniera interattiva la conferma del percorso da utilizzare per l’archiviazione delle chiavi. Di default propone la cartella .ssh sotto la home dell’utente che genera la chiave. Se ci sono ragioni particolari è possibile modificare il percorso di default. Eseguito il comando avremo archiviato i due certificati identificati come id_rsa (privata) e id_rsa.pub (pubblica). Come già detto in precedenza, la chiave privata deve essere conservata gelosamente, mentre perché il meccanismo funzioni, la chiave pubblica va consegnata e installata opportunamente nel server che vogliamo che ci riconosca: l’installazione della chiave pubblica avviene aggiungendola alla lista contenuta nel file authorized_keys nella cartella .ssh sotto la home dello user, nel server con cui ci vogliamo collegare. E’ possibile usare un normale editor di testi, ma è preferibile usare un apposito script preposto a questo scopo:

ssh-copy-id -i ~/.ssh/id_rsa user@host

Verranno chieste, dal server remoto (host), le credenziali di accesso e successivamente la chiave pubblica sarà installata, rendendo automatico, d’ora in poi, il riconoscimento dell’utente.

Suggerimenti:

1) vale la pena verificare che i permessi dei file id_rsa e id rsa.pub siano settati rispettivamente a -rw——- e -rw-r–r–
un settaggio più permissivo non consentirà un corretto funzionamento.

2) E’ possibile che il server che si vuole connettere non accetti accessi basati su credenziali (usr/pwd). In tal caso, da una connessione abilitata si potrà intervenire sul file di configurazione /etc/ssh/sshd_config andando ad agire sulla direttiva:

PasswordAuthentication

E’ anche possibile che il client dal quale ci si vuole connettere non consenta accessi basati su credenziali (usr/pwd). In tal caso si può intervenire sul file /etc/ssh/ssh_config andando ad agire sulla stessa direttiva indicata precedentemente.

Se l’argomento vi ha, per qualche motivo, interessato particolarmente, forse vorrete proseguire con la lettura anche di questo articolo: Disabilitare accesso SSH con credenziali