EUCOOKIELAW_BANNER_TITLE

Let’s Encript!

Il mio script per l’aggiornamento automatico dei certificati.

#!/usr/bin/python
#
# checkcert 1.0 (python 2.7)
# (C) 2015 Giorgio L. Rutigliano, www.iltecnico.info, www.i8zse.eu
# licenza GNU-GPL
#
import subprocess
import datetime
import os
import smtplib


def expdays(cert):
   #
   # recupera la data di scadenza, la converte in formato iso e calcola il numero di giorni rimanenti
   # restituisce il numero di giorni mancanti alla scadenza
   # cert -> filename certificato
   #
   cmd='date --date="$(openssl x509 -in '+cert+' -noout -enddate | cut -d= -f 2)" --iso-8601'
   p=subprocess.Popen(cmd, shell=True, stdout=subprocess.PIPE)
   out,err=p.communicate()
   p.wait()
   exp=[int(i) for i in out.split('-')]
   d1=datetime.datetime.now()
   d2=datetime.datetime(*exp)
   return (d2-d1).days

def renewcert(w,d,e):
   #
   # richiede l'aggiornamento del certiticato
   # w -> path root website
   # d -> lista domini del certificato
   # e -> email
   # restituisce stdout del comando
   #
   cmd='/usr/share/letsencrypt/letsencrypt-auto certonly --webroot -w '
   cmd+=w
   for i in d:
      cmd+=' -d '+i
   cmd+=' --renew-by-default --email '+e
   p=subprocess.Popen(cmd, shell=True, stdout=subprocess.PIPE)
   out,err=p.communicate()
   p.wait()
   return cmd+'\n'+out

def restart(serv):
   #
   # riavvia un servizio
   # serv -> nome del servizio
   # restituisce stdout del comando
   #
   cmd='service '+serv+' restart'
   p=subprocess.Popen(cmd, shell=True, stdout=subprocess.PIPE)
   out,err=p.communicate()
   p.wait()
   return cmd+'\n'+out

def mailto(fema,dema,subj,msg):
   #
   # invia una email
   # fema -> from
   # dema -> to
   # subj -> subject
   # msg  -> body
   #
   bod = "From: Check Certificati srv6 <'+fema+'>\n"
   bod+= "To: Sysadmin <'+dema+'>\n"
   bod+= "Subject: '+subj+'\n\n"+msg
   s = smtplib.SMTP('smtp.email.loc')
   s.sendmail(fema, [dema], bod)
   s.quit()


f=open('checkcert.lst','r')
log=open('checkcert.log','w')
certs=f.readlines()
f.close()
errori=""
rinnovi=""
ema='sysadmin@dommain.loc'

for dom in certs:
   xx=dom.strip().split('|')
   wd=xx[0]
   dom=xx[1].split(';')
   certfile='/etc/letsencrypt/live/'+dom[0]+'/cert.pem'
   days=0
   if os.path.isfile(certfile):
      days=expdays(certfile)
   log.write('dominio '+dom[0]+' scade in '+str(days)+' giorni\n')
   if days<15:
      log.write('rinnovo dominio '+dom[0]+'\n')
      out=renewcert(wd,dom,ema,log)
      log.write(out+'\n')
      if os.path.isfile(certfile):
         days=expdays(certfile)
         if days<15:
            log.write('errore aggiornamento dominio '+dom[0]+'\n')
            errori+="Dominio "+dom[0]+", scade in "+str(days)+" giorni\n"
         else:
            rinnovi+="Dominio "+dom[0]+'\n'

if (errori<>''):
   mailto(ema,ema,'Errore aggiornamento certificati',errori)

if (rinnovi<>''):
   mailto(ema,ema,'Certificati rinnovati',rinnovi)
   log.write(restart('apache2'))

log.close()

Il file di configurazione ha questo formato:

/var/www/dom1|dom1.loc;www.dom1.loc
/var/www/dom2|dom2.loc;www.dom2.loc

Path della root del dominio, seguita dal nome e da eventuali alias.

Lo script è lanciato da cron.daily ed utilizza come autenticatore webroot, mentre apache ` configurato manualmente. Lo script verifica la scadenza del certificato, se ` inferiore a 15 giorni lo rinnova. Se un rinnovo non va a buon fine invia una email di alert.

Lo stesso script può essere utilizzato anche per i server di posta elettronica, che possono essere configurati in questa maniera:

/etc/postfix/main.cf

smtpd_tls_cert_file=/etc/letsencrypt/live/<dominio>/fullchain.pem
smtpd_tls_key_file= /etc/letsencrypt/live/<dominio>/privkey.pem
smtpd_use_tls=yes

/etc/dovecot/conf.d/10-ssl.conf

ssl_cert = </etc/letsencrypt/live/<dominio>/fullchain.pem
ssl_key = </etc/letsencrypt/live/<dominio>/privkey.pem
ssl_ca = </etc/letsencrypt/live/<dominio>/chain.pem
ssl_verify_client_cert = yes

Il restart dei servizi interessati (apache per il webserver, dovecot e postfix nel caso di server di posta) è in stile init, i miei server sono systemd-free ūüėČ

Pubblicato in Linux, Sicurezza Taggato con: ,

DNS dinamico con OVH

OVH fornisce un comodo servizio di dns dinamico, una feature molto comoda per chi ha servizi remoti su connessioni xDSL che non dispongono di un IP statico.

E’ una possibilit√† che consente di svincolarsi dai servizi pi√Ļ o meno gratuiti, e di disporre sicuramente di una maggiore affidabilit√† complessiva.

Per la configurazione dei client io utilizzo normalmente ddclient, mentre la determinazione dell’IP dinamico la gestisco attraverso un semplice script, da caricare su di un qualsiasi server web: checkip.php:

<?php echo $_SERVER['REMOTE_ADDR']; ?>

La mia configurazione è la seguente:

daemon=300                # un check ogni 5 minuti
syslog=yes                # log via syslog
mail=root                 # tutti i messaggi a root
pid=/var/run/ddclient.pid # PID.
cache=/var/cache/ddclient/ddclient.cache # Cache
#
# Confidurazionbe dynhost
#
protocol=dyndns2
server=www.ovh.com
login=<id_login>
password=<password>
#
# Determinazione dell'ip pubblico
# check via web
use=web, web=http://www.my.site/checkip.php
#
# il nome dei dynhost da aggiornare
<dynhost>

 

Pubblicato in Linux, Script Taggato con: , ,

Device mapping su ESXi

Su Esxi ci sono situazioni in cui non è possibile attivare la mappatura diretta di un disco fisico ad una macchina virtuale, dato che la relativa opzione è disattivata.

L’operazione rimane comunque fattibile, ma deve essere fatta utilizzando la connessione ssh.

Bisogna quindi preventivamente attivare il servizio SSH dal client (security profile -> services properties -> ssh) e collegarsi al server esxi.

E’ necessario conoscere l’ID del disco per cui attivare il mapping. Si pu√≤ ricavare anche dal client, ma la cosa pi√Ļ immediata √® posizionarsi su /dev/disks e visualizzarne il contenuto con ls -l: l’ID del disco che ci interessa √® facilmente individuabile dalla matricola, ed avr√† un formato tipo:

t10.ATA_____WDC_WD6400AACSXX00G8B0________________________WD2DWCAUF1143740

Dobbiamo poi scegliere su quale datastore creare il device mapping. Ovviamente se ne abbiamo solo uno la scelta è obbligata, ma ci serve comunque saperne il nome.

Una volta in possesso dei due elementi possiamo procedere, con il comando:

vmkfstools -z /vmfs/devices/disks/<ID disco> /vmfs/volumes/<nome datastore>/<nome mapping>.vmdk</pre>

oppure

vmkfstools -r /vmfs/devices/disks/<ID disco> /vmfs/volumes/<nome datastore>/<nome mapping>.vmdk</pre>

Nel primo comando l’opzione -z crea un mapping come physical device, nel secondo (-r) come virtual. La prima opzione dovrebbe essere di uso generale, ma ho riscontrato che in qualche caso FreeBSD non gestisce correttamente i physical device mapping. La seconda √® limitata in capacit√† a 2TBytes.

A questo punto √® possibile importare il disco nella nostra macchina virtuale: aggiungendo un disco ci baster√† scegliere l’opzione gi√† esistente e selezionare il file .vmdk che abbiamo creato nel passo precedente.

Pubblicato in Virtualizzazione Taggato con: , ,

Statistiche apache con GoAccess

Goaccess √® un ottimo analizzatore per i logfile di apache. Leggero e velocissimo, ha una peculiarit√† che ¬†lo rende pi√Ļ unico che raro, la possibilit√† di lavorare direttamente da una console terminale, locale o remota che sia, utilizzando come opzione standard le librerie ncurses.

E’ quindi utilissimo per vedere cosa¬†sta succedendo, in tempo reale, sul nostro server. La visualizzazione √® molto chiara, con una serie di pannelli che mostrano l’andamento degli elementi chiave che interessano a tutti gli amministratori di sistema.

GoAccess √® presente nei repository delle distribuzioni principale, ma la versione di debian wheezy √® molto antiquata (0.5). E’ quindi conveniente installarla scaricando direttamente la tarball dal sito del progetto e compilarlo localmente.

Per la compilazione è necessario installare preventivamente le dipendenze, costituite da libglib2.0-dev e da libncurses5-dev.  Se si vuole utilizzare la persistenza dei dati sono necessarie anche le librerie libtokyocabinet-dev e libbz2-dev.

Per la compilazione è sufficiente seguire la procedura standard:

./configure --enable-geoip --prefix= --exec-prefix=/usr --mandir=/usr/share/man
make
make install

Per potere abilitare la persistenza bisogna specificare l’opzione di confiurazione¬†–enable-tcb=btree.

Una volta compilato ed installato per utilizzarlo basta lanciarlo con l’opzione di base:

goaccess -f <logfile>

Pubblicato in Linux, Tools Taggato con: ,

Intermezzo

Una vignetta simpatica mediata dal gruppo hackerrank con l’hashtag #ProgrammersUnderstand… sante parole ūüėČ

programmerknows

 

Pubblicato in Blog Taggato con: ,

Problemi con CRON

A chi non è mai capitato di avere problemi con script lanciati via cron, che invece eseguiti da shell funzionano perfettamente?

Come √® noto, il problema dipende dall’ambiente in cui sono eseguiti gli script di cron, dato che per ragioni di sicurezza √® molto pi√Ļ restrittivo di quello di root.

Come risolvere? Ovviamente testando gli script nello stesso environment in cui saranno poi lanciati dal daemon.

Io uso questo semplice metodo:

Creo preventivamente uno snapshot delle variabili di ambiente di cron aggiungendo temporaneamente un nuovo evento

mm hh * * * env > /root/.crondef

sostituendo a mm e hh i minuti e l’ora di un paio di minuti nel futuro, attimo in cui l’evento creer√† un file /root/.crondef contenente la definizione dell’ambiente di cron. Su debian wheezy il file ha questi elementi:

SHELL=/bin/sh
PATH=/usr/bin:/bin
PWD=/root
LANG=it_IT
SHLVL=1
HOME=/root
LOGNAME=root
_=/usr/bin/env

Una volta creato il file, la riga temporanea non serve pi√Ļ e pu√≤ essere rimossa dalla tavola di cron.

Uso poi uno script che lancia il comando cron da testare nello stesso ambiente che troverà quando sarà istanziato dal daemon:

#!/bin/bash
if [ "-$1-" == "--" ]
   then
     echo "uso testcron <comando>"
     exit
fi
env - `cat /root/.crondef` $1
echo "<--------------->"
echo "Terminato con stato: $#"
<

Il comando avrà a disposizione le stesse risorse di quando sarà temporizzato, per cui diventa semplice correggerne i problemi, nella stragrande maggioranza dei casi dovuti ad errori di path.

Pubblicato in Linux, Script, Tools Taggato con: , ,

PHP & Spam

Tutti, prima o poi, hanno dovuto affrontare la situazione di un sito compromesso che inizia ad essere utilizzato come veicolo di propagazione di spam. E siccome prevenire √® meglio che curare, ritengo sia utile predisporre un ambiente in grado di limitare i danni in caso uno dei siti ospitati sui nostri server venga ‘bucato’. Queste sono alcune delle ricette che uso per implementare quelle che considero protezioni di base.

1. Disabilitare l’invio diretto di posta

La prima cosa che faccio √® quello di disabilitare l’invio diretto di posta. Io solitamente utilizzo Postfix come MTA, e questo comportamento si implementa facilmente inserendo una linea in /etc/main.cf del tipo:

authorized_submit_users = root vmail amavis

con cui si nega agli utenti diversi da root, vmail ed amavis di inviare posta. Ove fosse necessario consentirne l’invio per determinate applicazioni, queste devono essere configurate per accedere all’MTA via smtp autenticato. In questo modo √® possibile imporre tutte le regole comunemente utilizzate per le operazioni di relay.¬† Per l’abilitazione √® necessario usare un replacement della funziona mail() come questa (il codice non √® mio):

function pear_mail($to,$subject,$message,$headers="") {
    // Richiede PEAR Mail e Net_SMTP
    require_once("Mail.php");
    function split_headers( $headers )
    {
        $header_array = array();
        $lines = explode("\n",$headers);
        foreach ($lines as $line) {
            $kv = explode(":",$line,2);
            if (!empty($kv[1])) {
                $header_array[trim($kv[0])] = trim($kv[1]);
            }
        }
        return $header_array;
    }

    $mailer = Mail::factory('smtp',array('host'=>'127.0.0.1','port'=>'25'));
    $header_list = split_headers($headers);
    $header_list['Subject'] = $subject;
    return $mailer->send($to,$header_list,$message);
}

che utilizza la stessa sintassi della funzione php e quindi può essere implementata semplicemente. Configurare il server SMTP in php.ini sarebbe inutile, visto che lo scopo è quello di disabilitare la funzione mail() nativa.

2. Abilitare il logging delle chiamate alla funzione mail()

Ruotare la posta via SMTP autenticato sicuramente riduce le chance che un malware ha di inviare spam, ma √® allo stesso tempo utile avere una indicazione del fatto che una condizione anomala √® presente sul¬† nostro server: la stessa vulnerabilit√† potrebbe essere utilizzata per altri fini. Dato che gli script bucati continueranno a tentare di inviare la posta utilizzando la funzione built-in mail() di PHP, possiamo usare questo come una sorta di campanello d’allarme.

La prima azione da fare è quella di abilitare il logging dei messaggi inviati mediante la funzione incriminata, è sufficiente inserire in php.ini una voce

mail.log = /var/log/mail_php.log

perche l’interprete php scriva nel file indicato una voce per ogni chiamata alla funzione, contenente tutto ci√≤ che ci serve:

mail() on [/var/www/htmp/testmail.php:2]: To: user@domain.xx -- Headers:

L’errore apparir√† nel log del mailer:

postfix/sendmail[15395]: fatal: User www-data(33) is not allowed to submit mail

così come nel report giornaliero (io utilizzo pflogsumm):

Fatal Errors
------------
  sendmail (total: 7)
         7   User www-data(33) is not allowed to submit mail

La presenza dei quali indica che c’√® una situazione anomala che richiede la mia attenzione.

3. Bloccare il traffico in uscita SMTP per apache

Se il malware ha un proprio server SMTP, come nel caso del CryptoPHP, i vincoli precedenti non hanno effetto, ma bisogna agire sulle regole di iptables per bloccare il traffico in uscita. In questo caso possiamo usare due approcci.

Il primo, meno restrittivo, consiste nel bloccare il traffico verso le porte SMTP generato da processi con l’uid di apache:

# blocco delle connessioni SMTP in uscita per apache
/sbin/iptables -A OUTPUT --dst 127.0.0.1 -p tcp --dport 25 -j ACCEPT
/sbin/iptables -A OUTPUT -p tcp --dport 25 -m owner --uid-owner 33 -j DROP
/sbin/iptables -A OUTPUT -p tcp --dport 465 -m owner --uid-owner 33 -j DROP
/sbin/iptables -A OUTPUT -p tcp --dport 587 -m owner --uid-owner 33 -j DROP
# log traffico generato da utenti diversi da postfix
/sbin/iptables -A OUTPUT -p tcp --dport 25 -m owner ! --uid-owner 107 -j LOG
/sbin/iptables -A OUTPUT -p tcp --dport 465 -m owner ! --uid-owner 107 -j LOG
/sbin/iptables -A OUTPUT -p tcp --dport 587 -m owner ! --uid-owner 107 -j LOG

Queste regole accettano il traffico verso il server locale, ma bloccano quello generato da apache (uid 33), inoltre loggano il traffico di utenti diversi da postfix (uid 107).
Un secondo approccio, pi√Ļ restrittivo, blocca il traffico per tutti gli utenti diversi da postfix:

# blocco delle connessioni SMTP
/sbin/iptables -A OUTPUT --dst 127.0.0.1 -p tcp --dport 25 -j ACCEPT
/sbin/iptables -A OUTPUT -p tcp --dport 25 -m owner ! --uid-owner 107 -j DROP
/sbin/iptables -A OUTPUT -p tcp --dport 465 -m owner ! --uid-owner 107 -j DROP
/sbin/iptables -A OUTPUT -p tcp --dport 587 -m owner ! --uid-owner 107 -j DROP

Ovviamente se il server ha sia un indirizzo ipv4 che ipv6 le regole vanno inserite in entrambe le definizioni di iptables, ricordo che localhost in ipv6 è ::1.

Per rilevare queste condizioni anomale, che implicano la presenza di vulnerabilità sul server, è utile aggiungere una istruzione per registrare il drop in syslog, tipo:

/sbin/iptables -A OUTPUT -p tcp --dport 25 -m owner ! --uid-owner 107 -j LOG

in modo che sia rilevabile nell’analisi del log ed essere utilizzato come allarme.

Non è certo la panacea di tutti i mali, ma sono aggiustamenti che svolgono efficacemente il loro lavoro.

Pubblicato in Linux, Prevenzione, Sicurezza Taggato con: , ,

Controllo snapshot zfs

Nelle mie strategie di backup zfs ha un ruolo importante, viste le feature del filesystem, ed in particolare, del supporto degli snapshot. Per la gestione uso come linee guida questo script bash:

#!/bin/bash
# snapctl 1.3 (C) Giorgio Rutigliano 2015
#
POOL="zfs-pool"
BASE="/mnt/storage/"
LOGF="/var/log/backup/snaplog"

function purgesnap()
# cancella gli snap con radice $1 a partire dalla posizione $5 in elenco
{
#echo $1, $2
SNAPS="$(ls -lad $BASE/.zfs/snapshot/$1* | awk -F '/' '{print $NF}' | sort -nr | tail -n +$2)"
for SNAP in $SNAPS
do
zfs destroy $POOL@$SNAP
echo "cancellazione $SNAP"
done
}
function timer()
{
if [[ $# -eq 0 ]]; then
echo $(date '+%s')
else
local  stime=$1
etime=$(date '+%s')

if [[ -z "$stime" ]]; then stime=$etime; fi

dt=$((etime - stime))
ds=$((dt % 60))
dm=$(((dt / 60) % 60))
dh=$((dt / 3600))
printf '%d:%02d:%02d' $dh $dm $ds
fi
}

TODAY=$(date +%Y-%m-%d)
TRM=$(timer)
GDS=$(date +%a)
GDM=$(date +%d)
echo ">>> Inizio $TODAY -----------" >>$LOGF
#
# snapshot mensile
#
if [ $GDM -eq 1 ]
then
zfs snapshot $POOL@montly-$TODAY >>$LOGF
else
#
# snapshot settimanale
#
if [ $GDS == "Sun" ]
then
zfs snapshot $POOL@weekly-$TODAY >>$LOGF
else
#
# snapshot giornaliero
#
zfs snapshot $POOL@daily-$TODAY >>$LOGF
fi
fi
purgesnap "daily" 8
purgesnap "weekly" 5
purgesnap "montly" 13

zfs list -t snapshot>>$LOGF
echo -e "<<< Fine -- $(date) -- Tempo impiegato: $(timer $TRM) \n" >>$LOGF

Il codice è lanciato via cron alla mezzanotte. Crea uno snapshot e cancella quelli vecchi, tenendo in linea gli ultimi 7 giorni, le ultime quattro settimane e gli ultimi dodici mesi, rendendo possibile il recupero di file vecchi con una certa granularità.

Pubblicato in Linux, Script, ZFS Taggato con: ,

debian-ZFS non si installa su wheezy

ZFS è una tecnologia di filesystem che presenta numerosi vantaggi rispetto al tradizionale ext3/4. Nata originariamente in ambiente Solaris è stata portata su molte piattaforme, linux compresa. Il supporto è previsto solo su sistemi a 64-bit, ed in effetti ZFS richiede una adeguata quantità di RAM per operare correttamente. Maggiori informazioni possono essere reperite su zfsonlinux.org.

Seguendo le istruzioni presenti sul sito, per√≤, l’installazione su Wheezy non arriva a termine: va in blocco al momento della creazione del modulo kernel con il messaggio

Building initial module for 3.2.0-4-amd640

In effetti il package debian-zfs non gestisce in maniera corretta la lista delle dipendenze.
Per completare correttamente l’installazione io ho utilizzato questa procedura, partendo¬†da una installazione¬†pulita di Wheezy via netinstall, in modo da avere il sistema aggiornato:

apt-get install build-essential zlib1g-dev uuid-dev libblkid-dev libselinux-dev parted lsscsi wget
wget http://archive.zfsonlinux.org/debian/pool/main/z/zfsonlinux/zfsonlinux_4_all.deb
dpkg -i zfsonlinux_4_all.deb
apt-get update
apt-get install debian-zfs

In questo modo il package viene installato correttamente ed è possibile procedere alla creazione dei pool zfs.

Pubblicato in Linux, ZFS Taggato con: , ,

Systemd, cui prodest?

Credo che siano molto poche le persone interessate al mondo linux che non siano a corrente delle polemiche sull’implementazione di molte distribuzioni linux del pacchetto systemd in sostituzione del veterano SysVinit.

Su questo punto si √® scritto di tutto e di pi√Ļ e abbiamo assistito ad una netta separazione di posizioni, quasi si fosse tifoserie accese¬†ad una partita di calcio.

La questione √® per√≤ molto complessa. SysVInit √® oggettivamente un sistema antiquato, con un elenco di noti difetti, il principale dei quali √® sicuramente la grande lentezza derivante dall’approccio seriale all’avvio dei servizi. L’idea di sostituirlo con un prodotto pi√Ļ moderno e meglio ingegnerizzato √®, quindi, tutt’altro che sbagliata. Peraltro, la creatura di¬†Lennart Poettering non √® la prima a tentare questa impresa.

Il problema reale √® che systemd sta andando ben oltre questo encomiabile tentativo, ma¬†sta fagocitando al suo interno tutta una serie di servizi che con la gestione dei processi e la creazione dello ‘spazio utente’ poco hanno a che fare. Approccio, questo, che viola radicalmente le logiche della filosofia Unix, che sono alla base non solo dei Linux che usiamo oggi, ma in larga parte di quella che √® l’informatica moderna.

Chi, come me, ha iniziato l’attivit√† in un fase storica in cui i sistemi proprietari erano assolutamente predominanti, ha ben chiaro quale impatto questa filosofia abbia avuto nell’evoluzione dei sistemi, e quanto siano importanti siano i precetti che¬†Mike Gancarz, componente del team di sviluppo di X Window, deline√≤ venti anni or sono:

  • Piccolo √® bello.
  • Ogni programma fare una cosa, e bene.
  • Crea un prototipo appena possibile.
  • Preferisci¬†la portabilit√† all’efficienza.
  • Memorizza i dati in semplici file di testo.
  • Utilizza¬†il potere del software a tuo¬†vantaggio.
  • Usa¬†gli script di shell per migliorare potenza¬†e portabilit√†.
  • Evita di usare “interfacce utente progioniere” (1).
  • Fai di¬†ogni programma un filtro.

Così come sono da tenere a mente le parole di Doug McIlroy, capo del centro di ricerca scientifica dei Bell Labs ed inventore della unix pipe, che ebbe ad affermare

La filosofia Unix è: scrivi programmi che fanno una sola cosa, e la fanno bene. Scrivi programmi che lavorino assieme. Scrivi programmi che gestiscano flussi di testo, perché questa interfaccia è universale.

Ed¬†√® andato ancora oltre, ¬†raccontando¬†l’approccio che avevano ai Bell Labs

Tutto era piccolo… ed il mio cuore ha un colpo¬†per Linux quando ne vedo le dimensioni (…) Solitamente sedevamo nella unix room e discutetevamo: “Cosa possiamo togliere? Perch√© c’√® quella opzione?” Spesso √® perch√© c’√® qualche deficienza nella progettazione di base – non hai centrato il giusto punto. Anzich√® aggiungere una opzione, ragiona su cosa ti abbia forzato ad aggiungere quella opzione.

E’ evidente che l’approccio seguito dal team di sviluppo di systemd sia diametralmente opposto alle filosofie che hanno fanno, di unix prima e di linux poi, un elemento cos√¨ importane nell’evoluzione dell’informatica di oggi. Non solo: √® evidente che il¬†processo che ha in carico il PID 1 √® quello pi√Ļ delicato di tutto il sistema operativo. Un processo per il quale sarebbe¬†giusto e prudente applicare tutte le precauzioni possibili, dato che potenzialmente pu√≤ compromettere la stabilit√† dell’intero sistema. Ma anche in questo caso, nonostante il recente caso del bug ‘debug’, la scelta di sostituire il lento, vecchio, ma affidabilissimo SysVinit √® proseguita senza alcun problema e/o ripensamento. Come mai?

Ricordo sempre il vecchio detto ¬†“a pensar male spesso si finisce per avere ragione“, e temo che le ragioni siano tutt’altro che tecniche. ¬†Systemd √® nato sotto l’ombrello di RedHat, che nel mondo linux ha un grande peso e vaste ramificazioni, sia con il progetto Fedora, che con la sostanziale acquisizione del progetto Centos. Ho l’impressione che systemd stia diventando¬†il cavallo di troia per consolidare ed estendere questo predominio commerciale nel mondo Linux.¬†La filosofia unix rende, per progetto, ogni elemento facilmente sostituibile con alternative. La filosofia di systemd (che mi ricorda tanto quella componenti di altri sistemi operativi commerciali) √® quella di accentrare in s√© tutto ci√≤ che sia¬†accentrabile. Questo, unito al design progettuale che esclude la portabilit√†, ed al fatto che gi√† si iniziano a vedere sottosistemi che sono dipendenti da systemd, mi lascerebbe pensare che certe scelte siano tutt’altro che casuali;¬†che lo scopo sia solo quello di affermare la posizione di predominio di RedHat, cercando nel contempo di estendere la penetrazione di Linux verso una clientela normalmente interessata ad altre famiglie di sistemi operativi.

Quindi, tornando alla domanda del titolo, systemd: cui prodest?

Temo a pochi, non credo proprio all’ecosistema linux.


(1) le CUI (captive user interface) √® uno stile di interazione con i programmi che prevede che l’input venga gestito (fatto ‘prigioniero’) dal programma e che sia necessario interagire con esso per terminarne l’esecuzione e restituire il controllo¬†all’interfaccia di comandi del sistema operativo. E’ il motivo per cui la quasi totalit√† dei programmi unix sono controllati da ¬†opzioni (‘switch’) inseriti sulla linea di comando al momento di lanciare il programma. Ci√≤ permette sia l’esecuzione da parte degli utenti, ma anche di essere inseriti in script senza problemi.

Pubblicato in Linux Taggato con: ,