Ubiquiti AirControl su Fedora 33

Pubblicato il Lascia un commentoPubblicato 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: (altro…)

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. (altro…)

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.

Trovare ed eliminare i Core Dump files

Pubblicato il Pubblicato in #sysadmin

I file core dump vengono generati dal sistema operativo dopo un crash di un processo e contengono un dump della memoria del sistema ed altre informazioni utili alla diagnosi del bug applicativo o sistemistico che ha causato il crash.

La loro dimensione varia da quanta memoria stava utilizzando il processo che è crashato ed in alcune situazioni possono creare qualche fastidio sui server, sia per l’effettivo spazio su disco che occupano sia perchè solitamente non sfuggono ai controlli di sicurezza che comunque li scansionano generando alert ed aggiungendo carico di lavoro alla macchina.

Su linux il nome del file è core.$PID, con find e le regex è possibile trovarli e cancellarli in sicurezza, se non vi interessa tenerli per fare del debugging:

find /home -type f -regex ‘.*/core.[0-9]*$’ -exec rm -f {} ;

;)

Risolvere il problema di surriscaldamento delle schede video ibride ATI/AMD, spegnendone una

Pubblicato il Pubblicato in #sysadmin

Questo post è per chi ha un portatile con una scheda video ibrida AMD/ATI non più supportata dai driver Catalyst (fglrx).

Facciamo un po’ di chiarezza, anche se è alquanto difficile fare chiarezza sullo stato dei driver proprietari Catalyst e capire quali schede video siano davvero supportate e quali no, tra Catalyst e Catalyst Legacy, Xorg e kernel che cambiano le ABI e rompono la compatibilità binaria con i vecchi driver… so solo che leggo nella pagina degli ultimi rilasci di AMD che la mia scheda video dovrebbe essere supportata in produzione su Ubuntu 12.10 ed invece non funziona.

Prima di oggi l’unica soluzione che i motori di ricerca mi suggerivano era: “comprati un’altra scheda video o cambia portatile“. Tanto che mi ero convito che fosse davvero l’ultima soluzione e stavo iniziando a preparmi a vendere un portatile per il quale ho sudato sette camicie a staccare lo stampino di WINDOWS per attaccarci su quello di UBUNTU. Figuratevi a venderlo… «…si però se ci installi una distro con un kernel maggiore del 3.2 surriscalda troppo e si spegne perchè non ci sono i driver della scheda video…», chi cazzo se lo sarebbe comprato, per usarlo con WINDOWS ma con lo stampino di UBUNTU. Avrei potuto venderlo solamente ad un fanatico di WINDOWS che lo avrebbe usato come dimostrazione che GNU/Linux non funziona.

Invece no. Me lo tengo. Perchè funziona. Con i driver opensource che funzionano meglio degli fglrx.

Continuiamo a fare chiarezza, ma stavolta riguardo i driver opensource, perchè con i Catobrepa… Catobepla… Catoblepa… Catalyst ho chiuso.

Lo stato dei driver opensource è ottimo, il #pobblema è un altro: è necessario SPEGNERE la scheda video dedicata, perchè altrimenti sembra che resti attiva, a palla, e si surriscaldi fino a far andare in protezione il sistema in estate o a tenere le ventole al massimo in inverno, quando di certo non va in protezione ma ci diventi cretino e sordo. Semplicemente basta spegnerla. E come si fa?

echo OFF > /sys/kernel/debug/vgaswitcheroo/switch

Con questo comando si dice al kernel di SPEGNERE la scheda che non si sta utilizzando.

Su qualsiasi distro, perchè è una questione di kernel, se nel vostro sysfs esiste quel percorso potete controllare le due schede video, scegliere quale delle due usare e spegnere l’altra. Magicamente la temperatura inizierà a diminuire, le ventole a rallentare, lo stesso comportamento di quando si usano gli fglrx.

Adesso sto utilizzando la scheda video integrata e va benone con i driver opensource, molto meglio di quella discreta con i driver fglrx: l’esperienza desktop in generale è molto più fluida, non c’è proprio paragone.

E’ non è finita… chi è nella mia stessa condizione ha notato anche che il portatile, senza gli fglrx, ha problemi a spegnersi ed a riavviarsi. Credevo fosse un problema di ACPI, ed in effetti in tutto ciò c’entra l’ACPI ma siamo sempre li: visto che una scheda video non è SPENTA il sistema semplicemente ASPETTA che si spenga inibendo il riavvio e lo spegnimento.

Adesso il mio portatile si spegne e si riavvia tranquillamente, senza dover forzare l’operazione con il tasto hardware e con tutti i rischi del caso.

Vediamo velocemente come liberarci dai Catalyst, o fglrx che dir si voglia. Ho solo questo portatile HP Pavilion dv6 3034sl e non so per altri modelli di schede video, a quanto ho capito dovrebbe funzionare per tutte le schede video ibride riconosciute come tali dal kernel.

1. Rimuovere i Catalyst

sudo apt-get autoremove –purge fglrx*

2. Riavviare il computer

3. Rilassarsi e prepararsi ad ignorare il fastidio delle ventole a palla ed il calore sotto la mano destra

4. Controllare nei log di Xorg quale scheda video attualmente si sta utilizzando (dovrebbe essere quella integrata di default, o comunque quella legata al primo framebuffer /dev/fb0).

$ more /var/log/Xorg.0.log
[    24.620] (–) PCI:*(0:1:5:0) 1002:9712:103c:1440 rev 0, Mem @ 0xd0000000/268435456, 0xf0400000/65536, 0xf0300000/1048576, I/O @ 0x00004000/256
[    24.620] (–) PCI: (0:2:0:0) 1002:68c1:103c:1440 rev 0, Mem @ 0xe0000000/268435456, 0xf0200000/131072, I/O @ 0x00003000/256, BIOS @ 0x????????/131072

è quella con l’asterisco, nel mio caso la 4200 (che mi basta ed AVANZA, io nemmeno la volevo un’altra)

$ lspci
01:05.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI RS880M [Mobility Radeon HD 4200 Series]
02:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI Madison [Radeon HD 5000M Series] (rev ff)

5. aggiungere queste righe a /etc/rc.local prima di exit 0

echo OFF > /sys/kernel/debug/vgaswitcheroo/switchecho low > /sys/class/drm/card0/device/power_profileecho low > /sys/class/drm/card1/device/power_profile

ovvero: spegni l’altra scheda ; imposta il profilo energetico basso ad entrambe (per scrupolo, visto che l’altra è spenta)

Maggiori info: http://wiki.ubuntu-it.org/Hardware/Video/GraficaIbrida/Vga_switcheroo

sudo senza password e le distro moderne, tipo #ubuntu

Pubblicato il Pubblicato in #sysadmin
«L’esperto è colui che evitando tutti i piccoli errori punta dritto alla catastrofe» 
(cit. Arthur Bloch)

Dunque facciamo gli esperti e vediamo la maniera più semplice, veloce, sicura e potenzialmente insicura per diminuire drasticamente la frequenza con cui sudo ci chiede di verificare tramite password se siamo davvero noi a richiedergli i privilegi di amministratore:

sudo visudo

---

come esemplificato sotto, spostate il cursore sulla riga dopo il commento, yy = copia la riga e p = incollala immediatamente sotto, commentate la vecchia riga e tenetevela di backup, non si sa mai; modificate la nuova riga appena incollata ciò vuol dire letteralmente: "gruppo(%) sudo? allora NO PASSWORD amigos!"

---

# Allow members of group sudo to execute any command
#%sudo ALL=(ALL:ALL) ALL
%sudo  ALL=NOPASSWD: ALL

---

:wq

Vi avevo detto la maniera più semplice e veloce sicura perchè si abilita una funzionalità di sudo strettamente dal suo file di configurazione e col suo comando di configurazione, senza mettere le mani da altre parti o peggio abilitare l’utente root (e ora vi spiego perchè IMHO); potenzialmente insicura perchè comunque ormai sudo la password non ve la chiede più, ne a voi ne a tutti gli altri utenti amministratori, appartenenti al gruppo sudo.

Abilitare l’utente root ed acquisirne i privilegi con su direttamente, su una distro moderna che integra ed utilizza già sudo e te lo mette a disposizione pure già configurato, a volte può essere necessario, sicuramente è da provare almeno una volta nella vita ma FWIW sudo -i vi da una shell di root esattamente come su, senza dover abilitare la password di root, se proprio avete bisogno di vedere root@localhost:~# per smontare una partizione.

Montare una immagine disco VDI di VirtualBox (quasi) in loopback

Pubblicato il Pubblicato in #sysadmin

Grazie a questo post (in inglese) ho scoperto che è possibile montare ed accedere ad una o più partizioni contenute in una immagine disco VDI, in una maniera molto simile al loopback: tramite il Network Block Device e le utility di qemu. Verificate che nel sistema sia installato l’eseguibile qemu-nbd, casomai installatelo dal pacchetto qemu-kvm.

qemu-nbd si occupa di collegare una immagine disco ad un device node nbd /dev/nbdX e di esporne al sistema le partizioni contenute come sottodevice.

sudo -i
modprobe nbd

#per collegare il file .vdi al device
qemu-nbd -c /dev/nbd0 <vdi-file>

#per scollegarlo dopo aver smontato i filesystem
qemu-nbd -d /dev/nbd0

Una volta collegata l’immagine appariranno i sottodevice /dev/nbdXpY, ad esempio la partizione che da dentro virtualbox sarebbe /dev/sda1 diverrà accessibile su /dev/nbd0p1, e così via.