Serposcope, Docker & OpenSuSE

Ieri, in un momento di pausa, ho letto questo breve ma interessante articolo in cui si parla di come usare Serposcope in un container Docker.

Sulle prime ho pensato “per quale motivo installare Serposcope all’interno di un contenitore quando basta avere java installato sulla macchina per avviarlo con un semplicissimo comando?!”.
E subito dopo ho pensato “java???! Ma non ho nessuna intenzione di installare una jvm sul mio server”.

Ecco perché server Docker.

Con docker posso permettermi di usare su una macchina virtualmente separata non solo jvm ma diverse versioni dello stesso. Posso quindi separare due versioni dello stesso framework senza che uno confligga con l’altro. Insomma posso separare in modo più veloce e pulito ambiente di sviluppo con ambiente in produzione sullo stesso server.

Certo, questo in ambienti piccoli, dove non si ci può permettere di avere due o più server fisicamente separati.

Ma le potenzialità non si fermano a questo, ovvero si rende più facile distribuire il proprio software nel proprio ambiente senza curarsi di dove andrà installato.

Ma questa è un’altra storia.

I comandi usati sono stati

zypper in docker
systemctl enable docker
systemctl start docker
docker pull serphacker/serposcope
docker run -d -p 7134:7134 –name serposcope serphacker-serposcope

e a questo punto vi troverete serposcope che “gira” sulla porta 7134.

Insomma, più semplice di così!!

Raspberry & TouchScreen KumanTech 35

Recentemente ho acquistato un display con touchscreen da integrare sul Raspberry Pi che mi controlla la stampate 3D. Così, giusto per poter fermare la stampa lanciata da web senza dover riprendere il computer.
Seguendo questa guida, con il touchscreen in mio possesso si arriva ad avere un sistema non funzionante, ovvero un bellissimo quanto affascinante schermo bianco.
Sul sito del produttore c’è un laconico “non aggiornate il kernel” ma, senza aggiornamento, addio browser Chromium.
Leggendo i log del kernel si nota che sia lo schermo che il touch cercano di prendersi lo stesso GPIO 17

pinctrl-bcm2835 3f200000.gpio: pin gpio17 already requested by spi0.1; cannot claim for spi0.0

e da qui è partita la mia ricerca.

Ho scoperto che succede la stessa cosa con un altro schermo di fascia economica, del tutto simile a questo: un’anima pia ha fatto un’analisi del driver di quest’ultimo con l’ultimo kernel disponibile per raspbian (4.9) e ha scoperto che esso prenota l’interrupt per il touchscreen e poi, quando il kernel carica nuovamente il driver del touchscreen come gli viene imposto nel file config.txt, tenta nuovamente di occupare lo stesso interrupt, non completando il caricamento dello schermo e nemmeno quello del touch.

La stessa cosa vale per questo touchscreen della Kuman.

In definitiva è bastato commentare la riga incriminata e tutto ha iniziato a funzionare come si deve!!

Ovvero:

dtoverlay=tft35a:rotate=90
#dtoverlay=ads7846,cs=1,penirq=17,penirq_pull=2,speed=1000000,keep_vref_on=1,swapxy=1,pmax=255,xohms=60,xmin=200,xmax=3900,ymin=200,ymax=3900

MySQL e Cronjob

Spesso capita di dover eseguire delle azioni ripetitive e, generalmente, ci si affida a Cron.
Cron è affidabile senz’altro ma, se l’operazione ripetitiva riguarda la manutenzione di alcune tabelle piuttosto che l’eliminazione di alcuni record (temporanei, di sessione), significa dover creare un script (in php, in python, in bash) che stabilisca una connessione al database ed esegua la query.
Ma fare questo significa impegnare il processore in tre processi:

  1. Crontab, che deve tener conto dell’azione da eseguire e di quando eseguirla
  2. L’interprete dello script, che dovrà leggere ed eseguire le vostre istruzioni
  3. MySQL, che eseguirà il vero e proprio lavoro

Ma non si potrebbe ridurre tutto a un singolo processo? Sì, basta delegare MySQL a fare tutto da se, ovvero con il suo scheduler. Leggi tutto “MySQL e Cronjob”