Ubiquiti AirControl su Fedora 33

Pubblicato il Pubblicato in #sysadmin

Non essendo uno sviluppatore Java ed avendo a che fare -fortunatamente- con pochissima roba in Java ci sono stato un po’ a capire perché lanciando AirControl ottenevo solo una finestra nera. Qualche anno fa, sempre con AirControl, avevo avuto bisogno di esportare una variabile di ambiente (che ho perso e non ricordo più) per farlo partire… era legata all’accelerazione grafica, tanto che -visto che AirControl non è più sviluppato in favore di UNMS- mi ero convinto non ci fosse nulla da fare e che il problema fosse legato a Wayland o X.Org. Conoscendo davvero poco le differenze tra versioni di JRE/JDK che pensavo essere retrocompatibili mi ero convinto definitivamente che quindi la finestra nera era per forza qualcosa di legato al rendering/compositing della mia scheda video.

Minchiate: è una questione di versione di Java. Non chiedetemi perché, non lo voglio nemmeno sapere! Di Java mi serve solo AirControl e così mi sta benone.

Fedora 33 esce con java-11-openjdk di default che è una dipendenza di libreoffice. AirControl ha invece bisogno che java-1.8.0-openjdk sia il JRE di default per girare correttamente. Quindi:

$ sudo dnf install java-1.8.0-openjdk icedtea-web

[...]

$ sudo alternatives --config java

Ci sono 2 programmi che forniscono 'java'.

  Selezione    Comando
-----------------------------------------------
 + 1           java-1.8.0-openjdk.x86_64 (/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.272.b10-0.fc33.x86_64/jre/bin/java)
*  2           java-11-openjdk.x86_64 (/usr/lib/jvm/java-11-openjdk-11.0.9.11-0.fc33.x86_64/bin/java)

Invio per mantenere l'attuale selezione[+], o inserire il numero di selezione: 1

PS: proprio oggi leggevo che Python sta scalando Java nella classifica dei linguaggi più utilizzati, ci sarà un motivo :-)

rsync su cygwin tra NTFS ed exFAT

Pubblicato il Pubblicato in #sysadmin

Per una serie di questioni prolisse da raccontare mi sto ritrovando ad usare Windows 7 e dover fare dei backup di dati con rsync su cygwin verso un hard disk esterno USB formattato in NTFS.

Il problema è proprio questo, NTFS. Credevo fosse il filesystem più compatibile tra dispositivi diversi, invece quest’ultimo è exFAT perchè non ha tutta la parte dei permessi ed ownership dei file che tra sistemi diversi diventa un bagno di sangue.

Certo, da un punto di vista Enterprise questi medatati sono sicuramente utili ed importanti, ma per una singola persona no: usate exFAT che la tab sicurezza-col-tasto-destro-proprietà nemmeno ce l’ha!

$ rsync -avr /cydrive/$ORIGINE/ /cygdrive/$DESTINAZIONE/ --progress --delete --size-only --no-perms -O

ISPConfig: snippet per reverse proxy con socket.io

Pubblicato il Pubblicato in #sysadmin

Qualche settimana fa stavo uscendo pazzo per un problema alla UI di una web app dietro reverse proxy, mi sono accorto che era un problema sul reverse proxy ispezionando la pagina con le WebTools di Chrome e notando che alcune richieste non andavano a buon fine: tutte quelle di socket.io.

ISPconfig -> Siti -> [vhost sito] -> Opzioni -> Direttive Apache

ProxyRequests Off
ProxyPreserveHost On
ProxyPass /.well-known/ !
ProxyPass /               http://10.8.10.11/
ProxyPassReverse /  http://10.8.10.11/

ProxyVia on      
RewriteEngine On

RewriteEngine On
RewriteCond %{HTTP:Connection} Upgrade [NC]
RewriteCond %{HTTP:Upgrade} websocket [NC]
RewriteRule /(.*) ws://10.8.10.11:8080/$1 [P,L]

ProxyPass               /socket.io http://10.8.10.11:8080/socket.io
ProxyPassReverse        /socket.io http://10.8.10.11/socket.io

Raccogliere i log da remoto con rsyslog, differenziarli in base all’IP e ruotarli con logrotate

Pubblicato il Pubblicato in #sysadmin

Le indicazioni di questo post sono state testate con delle antenne Ubiquity e sono valide per qualsiasi sistema che utilizzi ancora rsyslog e logrotate e qualsiasi hardware che sia in grado di spedire i propri log in remoto. Lo scenario è quello di un logserver Debian che riceve i syslog di access points e stations e li divide in base all’IP di provenienza.

Per prima cosa bisogna dire ad rsyslog di ascoltare su una porta UDP o TCP per poter ricevere i log, su /etc/rsyslog.conf decommentare le righe inerenti al protocollo che si desidera utilizzare:

# provides UDP syslog reception
$ModLoad imudp
$UDPServerRun 514

# provides TCP syslog reception
#$ModLoad imtcp
#$InputTCPServerRun 514

Successivamente, sempre su /etc/rsyslog.conf o come snippet in /etc/rsyslog.conf.d/ vanno inserite direttive tipo queste:

if $fromhost-ip startswith '192.168.10.' then /var/log/ubnt-stations.log
& ~
if $fromhost-ip startswith '192.168.2.' then /var/log/ubnt-stations.log
& ~

if $fromhost-ip startswith '192.168.1.' then /var/log/ubnt-APs.log
& ~

Molto utile ed importate è la riga ” & ~ ” posta immediatamente dopo la singola direttiva, vuol dire: “fermati li dove hai loggato e non andare avanti”, per evitare di spammare altri logfile tipo syslog o messages. Un restart di rsyslogd ed andiamo avanti.

Ultimo step è quello di configurare logrotate per ruotare anche questi nuovi logfile ed evitare che /var/log/ si riempia troppo presto. Le politiche più adatte spettano a voi, potete anche riciclare delle impostazioni già esistenti tra /etc/logrotate.conf.d/ o crearne una vostra, a seconda di quanto vi serva tenere i log.

Nel mio caso bastava una settimana ed ho aggiunto quei file di log (anche con wildcard) allo stesso snippet che fa ruotare syslog, ovvero ogni giorno e per una settimana, /etc/logrotate.conf.d/rsyslog:

/var/log/syslog
/var/log/ubnt-*.log
{
        rotate 7
        daily
        missingok
        notifempty
        delaycompress
        compress
        postrotate
                invoke-rc.d rsyslog rotate > /dev/null
        endscript
}

Moodle, opcache e le pagine bianche

Pubblicato il Pubblicato in #sysadmin

Mi è capitato di installare Moodle su ISPConfig e riscontrare spesso e volentieri delle pagine bianche nell’interfaccia di admin che lo rendevano davvero poco utilizzabile. Dopo un po’ di troubleshooting ed una ricerca sono riuscito a trovare il problema: opcache, parte di Zend. Conosco ancora poco moodle e non so il motivo esatto di questo comportamento nè quanto possa effettivamente giovarne in performances riuscendolo a farlo funzionare correttamente con opcache attivo… resta il fatto che disattivando opcache scompaiono le pagine bianche.

La direttiva per disattivarlo è opcache.enable:

php.ini:

opcache.enable = 0

apache (conf vhost o .htaccess):

php_admin_value opcache.enable Off
php_flag opcache.enable Off

Riapplicare i filtri #sieve ad una maildir da riga di comando

Pubblicato il Pubblicato in #sysadmin

Anche se dovecot ha il suo tool per riapplicare i filtri sieve a maildirs già esistenti, su un sistema di posta già configurato ed in produzione può essere più conveniente reimmettere le email nell’intera catena di filtri.

Questa serie di comandi combinati in una riga permettono di rispedire tutti i messaggi presenti in una cartella Maildir rifacendoli passare per la catena di filtri sieve.  E’ molto utile per testare le modifiche alle regole:

$ cd mail-storage/dominio.it/utente/
$ for i in cur/* ; do (/usr/lib/dovecot/deliver -d utente@dominio.it < $i ; echo rm $i) ; done

Vi consiglio di testarlo su una cartella con poche email prima di togliere echo a rm.