Guida comandi linux

L'articolo Guida ai comandi Linux più utilizzati da Terminale sembra essere il primo su Cesare Bordi | Innovation Manager & Back-end Developer.

Architettura REST: cos’è?

Additional constraints can then be applied to form a new architectural style that better reflects the desired properties of a modern Web architecture.

REST vede la luce dieci anni dopo la nascita del World Wide Web, piattaforma per la condivisione di documenti distribuiti su server connessi tra loro. L’acronimo REST (REpresentational State Transfer) viene introdotto nel 2000 nella tesi “Architectural Styles and the Design of Network-based Software Architectures” di Roy Fielding definendo così uno stile architetturale basato sul Web che fissa un insieme di principi per la progettazione di un sistema hypermedia distribuito.

REST è quindi un modello di progettazione e non va confuso con un protocollo (non definisce messaggi) nè con una specifica (non definisce uno standard), ma opera ad un livello di astrazione superiore.
Non è quindi del tutto corretto confrontarlo con il protocollo SOAP anche se entrambi sono oggi ampiamente usati nello sviluppo dei Web Service.

In estrema sintesi:

REST detta le regole per creare una piattaforma per l’elaborazione distribuita dei dati sfruttando l’architettura Web già dotata di tutto ciò che occorre: da una parte un’infrastruttura basata su protocolli ben definiti (HTTP in primis) dall’altra le informazioni viste come risorse mappate univocamente (URI).

I principi dell’architettura REST

Iniziare con un approccio “Null Style”

Il “Null Style” è il punto di partenza: un sistema in cui non ci sono confini distinti tra i componenti (risorse) che andranno connessi. I seguenti principi dell’architettura REST rappresentano i vincoli per standardizzare l’accesso alle risorse distribuite in questo scenario.

Client-Server

L’architettura REST applica il paradigma SoC (Separation of Concerns), “separazione dei compiti“, al sistema di funzionamento Client-Server (Richiesta-Risposta). Il vincolo Client-Server favorisce un’architettura distribuita in cui lo sviluppo applicativo lato client è indipendente da quello lato server. Questo spiega anche perché REST non si preoccupa dei linguaggi e dei metodi di sviluppo.

Stateless

La comunicazione tra utente del servizio (client) ed il servizio (server) deve essere priva di stato: ogni richiesta del client deve contenere tutte le informazioni necessarie al server per comprendere la richiesta e non deve sfruttare informazioni di sessione memorizzate sul server. E’ il client a gestire la sessione e, se necessario, dovrà ricevere opportune informazioni nella risposta del server.
Il vincolo stateless ha benefici sul monitoraggio delle richieste, sull’affidabilità e sulla scalabilità: non dovendo mantenere dati in sessione sarà più facile scalare orizzontalmente il servizio creando istanze parallele poste dietro ad un load balancer.

Cache

Nell’architettura REST il vincolo di Cache impone che le risposte siano etichettate come memorizzabili nella cache o meno. L’utilizzo della cache da parte di client, server o componenti middleware consente di ridurre le interazioni con la rete a tutto vantaggio delle performance.

Uniform Interface

L’architettura REST impone un vincolo di uniformità dell’interfaccia di accesso ai dati gestiti dal servizio, svincolandolo dalla specifica implementazione sottostante. Questo deve avvenire attraverso ulteriori sotto-vincoli.

Identificazione delle risorse

In REST ogni informazione è una risorsa, vista come qualsiasi cosa possa essere nominata: un documento, un’immagine, il meteo di oggi, …
Una risorsa può essere mutabile (l’ultima revisione di un documento) o immutabile nel tempo (la specifica revisione di un documento), l’unica cosa che deve essere statica è la semantica della sua mappatura, per questo motivo viene data una grande importanza all’identificazione univoca di una risorsa (URI) e alla necessità di mantenerla nel tempo.
Tale sotto-vincolo sottolinea lo scopo organizzativo proprio dei nomi di domino Internet.

Rappresentazione delle risorse

Una risorsa può essere rappresentata in molti modi diversi (HTML, XML, JSON, SVG, JPG, …) attraverso dati, metadati descrittivi ed eventuali “control data“. I dati di controllo possono definire lo scopo di un messaggio di richiesta o risposta, il suo comportamento o stato. Ad esempio possono specificare come gestire la cache di una riposta o la necessità di creare una risorsa sulla base dei dati e delle caratteristiche presenti nella richiesta.

Collegamenti tra risorse

L’architettura REST è pensata per connettere risorse tramite collegamenti ipertestuali. Questo principio è anche noto come HATEOAS (Hypermedia As The Engine Of Application State). Un Client deve quindi apprendere dalla rappresentazione di un risorsa fornita dal server (risposta) l’eventuale relazione con ulteriori risorse.
Ad esempio, richiedendo una fattura, la risposta dovrebbe contenere anche il link alla relativa anagrafica cliente.

Layered System

Un’architettura REST prevede più livelli architettonici, indipendenti l’uno dall’altro, frapposti fra client e server.
Gli strati intermedi possono avere scopi specifici durate il transito dei dati come ad esempio la sicurezza, il caching o il balancing.
I livelli potranno essere modificati in base all’evolversi dello scenario.

Code-On-Demand

L’ultimo vincolo di code-on-demand è facoltativo e consente ad un’implementazione REST di estendere le funzionalità del client scaricando ed eseguendo il codice sotto forma di applet o script. Ciò appare oggi abbastanza scontato e potrebbe rendere questo vincolo facoltativo quasi paradossale, ma non lo era nel 2000 quando i contenuti Web erano per lo più pagine statiche renderizzate dal browser.

Differenza tra architettura REST ed servizio RESTful

Eroneamente usati come sinonimi, REST è il nome dello “stile architetturale” mentre RESTful viene utilizzato per qualificare un Web Service che rispetta i vincoli dell’architettura REST.

Architettura REST: i contro

• L’architettura REST si può applicare solo in ambito Web a differenza del protocollo SOAP.
• A causa del vincolo stateless c’è la possibilità di un aumento dei dati di ambiente restituiti ripetutamente in una serire di richieste (overhead per interazione). Il vincolo di Cache cerca di compensare questo aspetto.
• A causa del vincolo stateless, spostando il controllo sul client si riduce il controllo da parte del server sul comportamento coerente dell’applicazione.

L'articolo Architettura REST per sviluppare Web Service sembra essere il primo su Cesare Bordi | Innovation Manager & Back-end Developer.

Problema: utilizzando il terminale di linux dovete lanciare un comando o uno script che richiederà molto tempo, ma non potete lasciar aperto il terminale o la sessione di ssh per tutte le ore o i giorni che impiegherà…

Soluzione: ci viene in aiuto il comando screen, vero e proprio “moltiplicatore di terminali” con il quale possiamo aprire una nuova sessione “virtuale” che  rimarrà aperta anche quando chiuderemo la sessione corrente.

Eseguendo infatti screen seguito dal comando che si vuole lanciare, nel nostro caso direttamente la bash,

screen bash

istanzieremo la bash nel nuovo terminale virtuale dal quale potremo lanciare il nostro comando dalla lunga esecuzione.

All’interno della sessione di screen potremo compiere varie operazioni:

• premendo ctrl+a+c creeremo un nuovo terminale.
• premendo ctrl+a+n passeremo al terminale successivo.
• premendo ctrl+a+p passeremo al terminale precedente.
• premendo ctrl+a+d torniamo alla nostra sessione, mantenendo in esecuzione i comandi pendenti eseguiti in quella di screen.

Ricollegandoci in un secondo momento potremo usare il comando seguente per riaprire una precedente sessione:

screen -r 1234

Dove ovviamente 1234 è il SID della sessione che desideriamo riaprire.

Digitando “screen -r”, nel caso ci siano più sessioni attive, viene mostrato l’elenco delle sessioni e dei relativi PID.

Per killare una sessione di screen:

screen -X -S 1234 quit

L'articolo Screen: terminale permanente con un comando linux sembra essere il primo su Cesare Bordi | Innovation Manager & Back-end Developer.

Aprire il terminale e digitare il seguente comando per aprire l’editor testuale Nano con i privilegi di amministratore:

sudo nano /etc/hosts

Aggiungere in una riga qualsiasi la riga che associa il nuovo IP al dominio desiderato. Es:

80.70.60.120 nomedominio.ext

Premere le combinazioni di tasti CTRL+O e poi INVIO per salvare e CTRL+X per chiudere Nano.

In alternativa si possono usare utility free per switchare rapidamente diversi file hosts come SwitchHost! o Gas Mask.

L'articolo Modificare file hosts su Mac OSX sembra essere il primo su Cesare Bordi | Innovation Manager & Back-end Developer.

Credo che qualsiasi programmatore si sia trovato nella condizione di dover cercare un determinato valore di un campo ricorrente in molteplici record per sostituirlo con uno diverso.

Diciamo ad esempio di voler sostituire in una tabella di dati anagrafici il termine “maschio” con “M” nel campo “genere”.

Problema: come fare quindi per eseguire un “cerca e sostituisci” in massa su tutti i record interessati della tabella MySql?

Soluzione: detto fatto, basta sfruttare l’apposita string function REPLACE di MySQL opportunatamente combinata con un UPDATE:

UPDATE `nomeTabella` SET `nomeCampo` = REPLACE(`nomeCampo`, ‘cosaTrovare‘, ‘cosaSostituire‘);

Se l’applichiamo al nostro esempio otterremo:

UPDATE `Anagrafica` SET `genere` = REPLACE(`genere`, 'maschio', 'M');

L'articolo MySql: cerca e sostituisci in una query per web developer sembra essere il primo su Cesare Bordi | Innovation Manager & Back-end Developer.

Per fare questo dovremo utilizzare il protocollo HTTPS che abbina il comune HTTP ad un ulteriore protocollo di crittografia asimmetrica.
HTTPS è infatti l’acronimo di HyperText Transfer Protocol over Secure Socket Layer.
Questo sistema di sicurezza è stato pensato proprio per evitare che attraverso tecniche di man in the middle un malintenzionato possa fare sniffing dei dati scambiati bidirezionalmente fra server e client.

Problema: se “tirar su” un server LAMP è ormai alla portata di tutti i web developer grazie alle molte distribuzioni out of the box, abilitare l’https è già un’operazione più specificatamente sistemistica, ma ugualmente attuabile in pochi minuti.

Spiegazione: su Ubuntu Server, così come in molte altre distribuzioni, il modulo SSL è già presente nell’installazione base di Apache.
Bisogna solo attivarlo con il seguente comando che abilita anche la porta 443 di default per l’https.

sudo a2enmod ssl

Dovremo quindi predisporre una cartella in cui generare i nostri certificati di sicurezza. Consiglio di creare una sottocartella dentro a quella di apache.

Nel caso di Ubunti dovremo lanciare il comando

sudo mkdir /etc/apache2/ssl

In altre distribuzioni come centOS la sottocartella può essere creata con i comando

sudo mkdir /etc/httpd/ssl

Per ottenere chiave privata e certificato utilizzeremo openssl attraverso il seguente comando, riportando i percorsi corretti, scegliendo la crittografia RSA a 2048 bit e una validità di 365 giorni.

sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/apache2/ssl/apache.key -out /etc/apache2/ssl/apache.crt

Nel caso openssl non fosse presente, si può installare mediante il seguente comando su Ubuntu (o analoghi su altre distro)

apt-get install openssl

La procedura di creazione dei certificati pone alcune domande alle quali si può rispondere abbastanza liberamente, es:

Country Name (2 letter code) [AU]:IT
State or Province Name (full name) [Some-State]:Modena
Locality Name (eg, city) []:Modena
Organization Name (eg, company) [Internet Widgits Pty Ltd]:communicationBox
Organizational Unit Name (eg, section) []:Development
Common Name (e.g. server FQDN or YOUR name) []:NomeMioServer
Email Address []:maimaildiriferimento@dominio.it

A questo punto il grosso del lavoro è fatto, non resta che settare i virtual host per indicare di sfruttare la cominicazione sicura sulla porta 443 e chiave e certificato appena creati.

Nella cartella /etc/apache2/sites-available/ è solitamente già presente un file di esempio denominato default-ssl.conf che possiamo modificare o utilizzare come modello per creare il nostro file:

sudo nano /etc/apache2/sites-available/default-ssl.conf

<VirtualHost *:80>
        ServerAdmin webmaster@localhost

        DocumentRoot /var/www/html
        <Directory />
                Options FollowSymLinks
                AllowOverride All
        </Directory>
        <Directory /var/www/>
                Options -Indexes +FollowSymLinks +MultiViews
                AllowOverride All
                Order allow,deny
                allow from all
        </Directory>

        ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/
        <Directory "/usr/lib/cgi-bin">
                AllowOverride None
                Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
                Order allow,deny
                Allow from all
        </Directory>

        ErrorLog ${APACHE_LOG_DIR}/error.log

        # Possible values include: debug, info, notice, warn, error, crit,
        # alert, emerg.
        LogLevel warn

        CustomLog ${APACHE_LOG_DIR}/access.log combined

        Alias /doc/ "/usr/share/doc/"
        <Directory "/usr/share/doc/">
                Options MultiViews FollowSymLinks
                AllowOverride None
                Order deny,allow
                Deny from all
                Allow from 127.0.0.0/255.0.0.0 ::1/128
        </Directory>

</VirtualHost>

Ora la configurazione è terminata, dobbiamo abilitare come di consueto il virtual host:

sudo a2ensite default-ssl.conf

Infine riavviamo il servizio per rendere effettive le modifiche:

sudo service apache2 restart

Ora, sincerandosi che il firewall della nostra connessione consenta il traffico sulla porta 443, puntiamo sull’ip del server, o sul dominio impostato nel virtualhost, ad esempio https://123.123.123.123.
Comparirà un avviso che ci avverte che il certificato non è attendibile, questo è normale in quanto lo abbiamo autogenerato e non acquistato da un ente certificatore. Basterà procedere “accettando i rischi” per navigare in maniera sicura. Naturalmente, per siti o app pubbliche, è vivamente consigliato l’acquisto di un certificato verificato per non “spaventare” l’utente con questo avviso.

L'articolo Sicurezza: abilitare HTTPS in Apache2 su Ubuntu server sembra essere il primo su Cesare Bordi | Innovation Manager & Back-end Developer.

Il codice proposto dallo stesso WordPress che solitamente si utilizza per abilitare il rewriting e far così scomparire dalla url “index.php” è il seguente:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

Questa regola eseguirà il rewrite di ogni percorso della url sott’intendendo la presenza di /index.php

Problema: può però essere necessario escludere una cartella (o più) da questa regola generale per caricare ad esempio file che devono essere accessibili attraverso un link diretto o script di varia utilità.

Soluzione: è possibile modificare la regola in modo da segnalare una directory (o più) che faccia eccezione rispetto alla regola generale attraverso la seguente istruzione:

RewriteCond %{REQUEST_URI} !^/(Cartella1|Cartella2|Cartella3).*$

Ecco come apparirà il blocco di codice completo:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index.php$ - [L]
RewriteCond %{REQUEST_URI} !^/(Cartella1|Cartella2|Cartella3).*$
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

L'articolo WordPress: escludere una cartella dal rewriting url di Apache sembra essere il primo su Cesare Bordi | Innovation Manager & Back-end Developer.

Problema: come disabilitare il directory browsing di Apache2?

Soluzione: per prima cosa bisogna aprire il file della configurazione di default di apache2, nel mio caso denominato “000-default.conf” e rimuovere dalle options il modulo “Indexes” appunto.

Quindi troveremo una riga simile a questa:

Options Includes Indexes FollowSymLinks MultiViews

che diventerà:

Options Includes FollowSymLinks MultiViews

poi dovremo riavviare il servizio:

sudo service apache2 reload

Non sempre questo unico accorgimento risolve il problema, quindi consiglio di lanciare i seguenti comandi per disabilitare il modulo autoindex di Apache:

sudo a2dismod autoindex
sudo service apache2 restart

L'articolo Apache directory browsing: disabilitare la visualizzazione delle cartelle sembra essere il primo su Cesare Bordi | Innovation Manager & Back-end Developer.