Salone d'Inverno

 

Monday

... scalpo...

... che poi, c'era anche una canzone... ma non mi ricordo che altro consiglio dava... mah!?!?!

P.S.: ... adesso ho freddo alla nuca... :-(

... random pics + pile up...

... che poi, visto che capita raramente, guidare con la neve mi piace; è un qualcosa di diverso dalla routine di tutti i giorni. La nave cambia il paesaggio che ti circonda e le abitudini della gente che lo popola; è un qualcosa di "magico" per il sottoscritto... tutto questo finché non ti tamponano a 50 metri da casa e all'alba del weekend!!!

... in galera!!!

Momenti deliziosi con Spike di Me First...

Comunicazione interna: 16 Febbraio Bologna - Zona Roveri...

No words needed...

https://it.wikipedia.org/wiki/Renzo_Pasolini

... 35...

[...]I was a child adult, a walking insult
Every shot got more difficult [...]

... random pics...

Workshoppers di nodeschool.io su Ubuntu 16.04.1 LTS

Ammettiamo di voler provare il workshopper javascripting di nodeschool.io.
Presupponendo di non aver nemmeno mai installato node e npm:

sudo apt update
sudo apt install -y nodejs
sudo apt install -y npm

Ora per installare il workshopper si può procedere come da istruzioni con npm:

sudo npm install -g javascripting

Se proviamo a far partire lo script:

$ javascripting
/usr/bin/env: "node": File o directory non esistente

Il "problema" è dato dal fatto che, per motivi che non ho ancora approfondito, l'eseguibile di Node fornito da Canonical si chiama nodejs e non node come sarebbe "canonico". La mia personale soluzione, come al solito grezza e brutale, è stata quella di creare un link simbolico in maniera che l'eseguibile potesse essere richiamato anche come node:

sudo ln -s /usr/bin/nodejs /usr/bin/node

P.S: penso le cose e mi dimentico di dirle...

Forzare HTTPS per applicativi LAMP su OpenShift

Qualche tempo fa, con il compare Cranix, abbiamo deciso di provare a migrare un nostro applicativo LAMP di "produzione" da un hosting che non ci soddisfaceva troppo (di cui non è carino fare il nome) ad OpenShift. Fra i vari vantaggi che la piattaforma offre c'è la possibilità di usare, da subito e con setup di default, HTTPS come trasporto per servire le pagine; unica limitazione delle versione gratuita è l'impossibilità di usare una chiave "custom" ma le funzionalità restano complete.
Se usare connessioni criptate è da sempre una "best practice" da questo mese sembra debba, finalmente, diventare una "necessità": https://www.miamammausalinux.org/2016/12/chrome-si-muove-verso-un-web-piu-sicuro/.

Forse esistono metodi più eleganti per forzare un'applicativo LAMP qualunque ad usare la versione Sicura del protocollo, anche quando la richiesta da parte del client viene fatta su HTTP "liscio", ma nel nostro caso una funzione richiamata all'inizio dello Script Router è sembrata la soluzione ideale. Tuttavia l'implementazione che avevamo usato quando l'applicativo risiedeva sul precedente hosting causava un bel Error 310 (ERR_TOO_MANY_REDIRECTS). Gli stack LAMP non sono tutti uguali e, almeno quando ci si affida ad hosting "preconfigurati", bisogna adattare il proprio codice alla configurazione presente... con buona pace della portabilità!

/*
* Forza l'uso du HTTPS - SSL su OpenShift
*/

function requireSSL( ) {
 if( ! isset( $_SERVER['HTTPS'] ) && $_SERVER['HTTPS'] !== "1" ) {
  header( "Location: https://" . $_SERVER["HTTP_HOST"] . $_SERVER["REQUEST_URI"] );
  exit();
 }
}

Per forzare il passaggio ad HTTPS di ogni richiesta pervenuta ad una data pagina basta richiamare, prima dell'emissione di qualsiasi output verso il client [si sta usando header()], la funzione senza nessun parametro:

requireSSL();

... se avete uno Script Router quello è l'unico punto in cui intervenire...

Balasso: discorso di Capodanno 2017