Che spettacolo! MacBook del 2006.

macbook

 

Che bello! Un collega di ufficio si è presentato col suo bel MacBook uscito nel febbraio del 2006

(http://www.bit-tech.net/news/hardware/2006/02/15/macbook_pro_upgrade/1)

tirato a lucido e ancora perfettamente funzionante. Non può utilizzare più di 2 Gb di RAM (erano altri tempi) ma Debian 7 non sembra soffrirne troppo. Bella macchina, indistruttibile o quasi. Mi dice Matteo, il proprietario, che ci si sono anche seduti sopra! 🙂

 

Installiamo un Cloud Server sul Raspberry Pi2

Vediamo stavolta come trasformare il nostro piccolo Raspberry Pi2 in un cloud server, molto simile a Dropbox per esempio, solamente che a conservare i nostri dati condivisi saremo noi e non più un fornitore esterno. Per fare questo ci vuole una buona ADSL ovviamente, meglio se in fibra ottica, con un valore soprattutto in upload piuttosto alto per non penalizzare troppo la velocità di accesso ai nostri dati.

Ho scelto quello che mi sembra un ottimo prodotto, ownCloud (https://owncloud.org) disponibile anche in una versione non commerciale, che però non è affatto penalizzata nell’uso che intendiamo farne noi. Per chi volesse fare un confronto tra le caratteristiche della versione Community e quella Enterprise ecco un link dove vengono analizzate le differenze: https://owncloud.com/owncloud-server-or-enterprise-edition/

Esistono già pubblicati diversi articoli su come installare questo prodotto su Raspbian, ma dal momento che io ho utilizzato la Fedora 21 Remix minimal e ho notato alcune differenze nei pacchetti da installare (mi riferisco in particolare al PHP) vedremo qui di seguito la procedura da eseguire. La Fedora Minimal (è un immagine di solo 2 Gb) mi sembra perfetta per questo tipo di server; niente interfaccia grafica e solo il minimo indispensabile per installare poi solo i pacchetti che ci servono. Questo ovviamente garantisce maggiore stablilità e velocità di esecuzione dei processi. Dal momento che un Cloud è anche un contenitore di dati consiglio di utilizzare una microSD da almeno 32 Gb oppure ricorrere ad un hard disk esterno collegato al Raspberry per gestire la directory “data” del Cloud. Se gli hard disk esterni dovessero dare problemi di alimentazione con il Raspberry allora una penna USB da 128 Gb (ahimè, costa quanto il Raspberry stesso) farà al nostro caso.

Le immagini della Fedora possono essere scaricate a questo indirizzo:

http://ftp.halifax.rwth-aachen.de/fedora/linux/releases/21/Images/armhfp/

vanno decompresse con una utility capace di trattare il formato xz e poi è sufficiente rinominare il file raw in img per poterlo poi installare su di una microSD.

Essendo la versione “minimal” una distribuzione esclusivamente testuale richiede una certa familiarità con i comandi della shell Linux, compreso il fatto che una volta installata non è in grado di gestire un dongle wifi se non eseguendo delle procedure manualmente (esiste un altro articolo a questo proposito). Sostanzialmente avremo bisogno di installare, dato per scontato che il Raspberry acceda alla nostra rete locale ed a Internet:

web server Apache
PHP
SqLite (già presente anche nella minimal)
ownCloud

Apriamo una connessione SSH e lavorando da utente root digitiamo:

Finita l’installazione possiamo controllare da un pc collegato in rete che Apache funzioni, accedendo al sito del raspberry da browser con http://[IP_DEL_RASPBERRY]
Dovremo vedere la pagina di default di Apache.
Possiamo anche controllare se il modulo PHP di Apache funziona correttamente. Entriamo nella directory /var/www/html e apriamo un editor (vi o nano) per creare un file chiamato test.php
Inseriamo dentro questo codice e salviamo.

Di nuovo accediamo al sito del Raspberry stavolta con http://[IP_DEL_RASPBERRY]/test.php

Se tutto è andato bene dovremmo vedere la pagina di info del PHP con tutte le configurazioni correnti, sintomo che il modulo PHP di Apache sta funzionando.
Cancelliamo subito questo file, non è bene lasciarlo qui per motivi di sicurezza.
Rimanendo sempre nella directory /var/www/html scarichiamo il software relativo a ownCloud. Attualmente siamo alla versione 8.0.3 ma si potrebbe andare a controllare nel sito se esiste una versione successiva e modificare la riga seguente con il nuovo nome.

Qui abbiamo scaricato ownCloud, lo abbiamo decompresso, gli abbiamo assegnato i diritti di accesso all’utente che usa il web server Apache e abbiamo inserito le regole firewall per l’accesso esterno. Per far uscire il Raspberry su Internet servirà poi fare il forwarding della porta SSL 443 sul router, magari indirizzandola all’esterno su un’altra porta diversa dalla 443 per aumentare la sicurezza di accesso al cloud. Ora dobbiamo modificare alcuni file di configurazione.

Entriamo con un editor nel file /etc/httpd/conf/httpd.conf

Modifichiamo la sezione qui sotto in modo che la home page punti a ownCloud.

#
# DocumentRoot: The directory out of which you will serve your
# documents. By default, all requests are taken from this directory, but
# symbolic links and aliases may be used to point to other locations.
#
DocumentRoot “/var/www/html/owncloud”

Modifichiamo la direttiva AllowOverride impostandola ad All. Questo farà in modo che il file .htaccess (nascosto) presente nella directory ownCloud possa funzionare.

# AllowOverride controls what directives may be placed in .htaccess files.
# It can be “All”, “None”, or any combination of the keywords:
# Options FileInfo AuthConfig Limit
#
AllowOverride All

Ora passiamo alla configurazione dell’accesso SSL del sito di ownCloud.
Creiamo i certificati.

Entriamo nel file /etc/httpd/conf.d/ssl.conf e modifichiamo :

# General setup for the virtual host, inherited from global configuration
DocumentRoot “/var/www/html/owncloud”
ServerName [nomedeldominio]:443

# Server Certificate:
# Point SSLCertificateFile at a PEM encoded certificate. If
# the certificate is encrypted, then you will be prompted for a
# pass phrase. Note that a kill -HUP will prompt again. A new
# certificate can be generated using the genkey(1) command.
SSLCertificateFile /etc/pki/tls/certs/owncloud.crt
# Server Private Key:
# If the key is not combined with the certificate, use this
# directive to point at the key file. Keep in mind that if
# you’ve both a RSA and a DSA private key you can configure
# both in parallel (to also allow the use of DSA ciphers, etc.)
SSLCertificateKeyFile /etc/pki/tls/private/owncloud.key

Riavviamo Apache

e proviamo l’accesso https://

L’installazione è terminata, ora dobbiamo entrare nel sito e creare un’utenza amministrativa. Fatto questo si possono creare altri utenti usando un nuovo gruppo che potremo chiamare “user” per l’accesso ai dati. Il manuale d’uso di ownCloud è presente nelle cartelle visibili nel sito.

Il Cloud Server è impostato per accettare dowload di file grandi al massimo 512Mb. Questo valore si può cambiare portandolo fino al valore di 2 Gb agendo sul file nascosto /var/www/html/owncloud/.htaccess, cambiando le direttive
<IfModule mod_php5.c>
php_value upload_max_filesize 1G
php_value post_max_size 1G
php_value memory_limit 512M

che sul mio cloud ho modificato a 1 gigabyte. Una volta fatta la modifica è necessario far ripartire Apache.

Nel caso si voglia utilizzare un disco esterno (hdd o una chiave usb) per avere maggiore capacità rispetto alla microSD usata dal Raspberry il Cloud utilizza una directory chiamata “data” che si trova in /var/www/html/owncloud. Questa va replicata sull’unità esterna non dimenticando di assegnargli i diritti dell’utente apache:apache. Per cambiare il path usato da ownCloud si interviene nel file /var/www/html/owncloud/config/config.php agendo sulla direttiva

‘datadirectory’ => ‘/var/www/owncloud/data’,

che va aggiornata al nuovo mountpoint, eventualmente trasferendo i dati già esistenti.
Fatto ciò si può riavviare Apache e cancellare la vecchia directory data dopo aver controllato che tutto sia andato bene.

Sul sito ufficiale di ownCloud è possibile scaricare i client per gli ambienti Windows, Mac, Linux, Android e iOS in modo tale da tenere, come si fa in Dropbox, localmente una cartella sincronizzata sul proprio Pc o Device.

Schermata 2015-05-23 alle 20.10.28

Raspberry Pi2: collegare un HDD esterno alle porte USB

Il mio progetto per il secondo Raspberry Pi2 che ho acquistato sarebbe quello di utilizzarlo come un personal cloud, del tipo di quello fornito da Dropbox per intenderci. Per fare ciò ho pensato di servirmi di un disco da 2.5″ avanzatomi da un portatile “deceduto”. Il disco ha una capacità di 320 Gb e occupa 2 porte usb essendo dotato di un cavetto in grado di prelevare segnale e corrente da 2 porte usb separate. Non è un modello molto recente, anche se SATA e dichiara sull’etichetta un assorbimento max di corrente di 750mA. Mettiamoci qualcosa in più per la schedina del box esterno e probabilmente arriviamo a 800-850 mA. Il mio primo pensiero è stato: ce la farà il Raspberry ad alimentarlo? Infatti collego i due connettori al Pi2 e il disco faceva lampeggiare la sua spia rossa ed emetteva un rumore continuo, un “tac-tac”, sintomo che le testine non riuscivano a posizionarsi correttamente a causa della scarsa corrente fornita dalle porte.

Solito giro sui siti internet e scopro che probabilmente il Pi2 è impostato per fornire di default alle porte USB un totale di 500mA. Il sistema per aumentare questo limite per fortuna c’è e risiede in un parametro da inserire nel solito file /boot/config.txt.

Ovviamente vado a vedere e scopro che la Fedora 21 Remix minimal non ha messo niente in questo file. Per cui inserisco il valore;

max_usb_current=1  (1 sta per 1 ampere, ovvero 1000 mA)

salvo e faccio il reboot del Pi2. Ricollego il disco e stavolta va tutto bene. Lo partiziono, lo formatto, lo monto ed è pronto per accogliere i dati del mio futuro personal cloud. Ovviamente sto usando un alimentatore da 2A, per cui dovrei avere una sufficiente riserva di energia per alimentare tutto il resto. Lo terrò in prova e vedremo se il Raspberry si manterrà stabile.

pi2-hdd

RedHat 7: troppo presto per usarla?

Il “problema”, se proprio vogliamo chiamarlo così, è stato l’introduzione di systemd per la gestione dei servizi al posto dell’ormai collaudatissimo initd. Systemd è sicuramente più evoluto del suo predecessore ma quando si parla di server ci si chiede sempre se è in grado di fornire la stessa stabilità che si aveva in precedenza. Parallelizzare i processi di boot per velocizzarlo, riavviare automaticamente servizi in caso di errore va tutto bene, ma non è certamente ciò di più importante che ci si può aspettare da un server. Non voglio poi nemmeno prendere in considerazione Gnome 3 perché, trattandosi quella dei server di un’installazione completamente testuale, l’ambiente grafico diventa in assoluto ininfluente.

Al momento in cui scrivo siamo arrivati anche ad avere, grazie agli aggiornamenti in linea, la versione 7.1. Di fatto però, parlo per esperienza personale, negli ambienti di sviluppo/test e a maggior ragione nelle macchine di produzione si continua ad usare la RedHat 6.x e non è difficile imbattersi ancora in ambienti RedHat 5.x. Questo discorso vale ovviamente anche per la distribuzione “gemella” CentOS che molto spesso per motivi di costi viene usata al posto della RedHat.

E’ pur vero che già da diverso tempo questa soluzione è stata implementata su Fedora, ma si tratta di un sistema operativo dedicato agli ambienti desktop e non è soggetto agli stessi criteri di affidabilità e agli uptime mostruosi richiesti ad un server di produzione. D’altro canto non credo che vedrò mai in un data center un’installazione Fedora 21 Server, ne sono piuttosto certo.

Journal, che ha sostituito il tradizionale system log: non sono solo io a storcere il naso, ho sentito altri pareri di colleghi sistemisti non proprio entusiasti. Ne parlo qui in un altro articolo a proposito della Fedora Remix sul Raspberry; ho rimesso subito la situazione così com’era.

Comunque sia, il cammino oramai sembra questo per cui tanto vale cominciare a predisporre qualche ambiente, magari virtuale, dove testare in parallelo alle release precedenti progetti in fase di collaudo. Per gli ambienti di produzione, si sa, le cose procedono molto più lentamente e si aspetta sempre che qualcuno abbia il coraggio di osare per poi vedere come funziona il tutto.

Due link di riferimento, in inglese,  per approfondire il tema:

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/7.0_Release_Notes/index.html

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Migration_Planning_Guide/index.html

Fedora 21 remix minimal: /var/log/messages. Che fine ha fatto?

Il passaggio di molte distro di ultima generazione da un controllore di processi “storico” come initdsystemd ha creato non pochi problemi a chi come me, abituato a gestire da diverso tempo server Linux RedHat e CentOS, ha dovuto far fronte ad una nuova serie di comandi e procedure per gestire queste macchine. Quando si sospetta la presenza di qualche tipo di problema su questi server la prima cosa che si va a fare è andare a consultare il log di sistema per vedere se c’è qualche messaggio “sospetto” che possa indicarci la natura del problema. Il primo file che di solito si va a vedere è il classico (per chi usa Unix) /var/log/messages, consultabile da utente root. Qui vengono riportati dal sistema in tempo reale eventuali anomalie e messaggi di errore da parte del kernel e da altri sottosistemi che girano sul server.

Ebbene, il nuovo systemd ha eliminato questo utilissimo file di log a favore di un nuovo sistema che usa il comando journalctl per interrogare il system-log. Non voglio entrare adesso nel merito dell’utilizzo di questo nuovo comando, ma siccome sono piuttosto “affezionato” al caro e vecchio file messages, ecco come ripristinarne l’uso.

E’ sufficiente installare da Yum il vecchio demone rsyslog, abilitarlo al boot del server e farlo ripartire. Vediamo i comandi da dare (da root):

Fatto questo riavremo di nuovo i messaggi di sistema nel solito file /var/log/messages. Devo dire che le immagini di Fedora 21 remix dotate di interfaccia grafica non presentano questa nuova gestione, mentre la minimal sì.

Che devo dire….. toglietemi tutto ma lasciatemi il mio messages! 🙂

 

Fedora 21 Remix minimal: cambiare il fuso orario di default

Eh sì, perché una volta sistemata la nostra Fedora 21 per il Raspberry Pi2 se proviamo a dare il comando date abbiamo come risultato l’ora di New York, ovvero il fuso EDT. Meglio adottare il nostro fuso italiano o magari, perché no, come capita talvolta di fare con alcuni server impostarlo sul fuso internazionale UTC. Ci vuole un attimo, vediamo come:

L’elenco delle timezone disponibili si trova nella directory /usr/share/zoneinfo. Qui abbiamo file e directory (come ad esempio Europe) che scendono nel dettaglio della città di cui impostare il fuso orario. Andiamo ad esempio in /usr/share/zoneinfo/Europe dove c’è il file Rome.

E’ sufficiente copiare questo file sostituendo l’attuale /etc/localtime ed il gioco è fatto.

viene richiesto di sovrascrivere quello esistente, rispondiamo di sì. Adesso quando digitiamo il comando date otteniamo l’ora italiana in CET oppure in CEST quando è in vigore l’ora estiva.

 

Raspberry Pi2: proviamo la Ubuntu 15

Prima facevo riferimento alla Ubuntu 15.04, l’ultima versione della distro di Canonical.

Vale la pena di provarla e l’immagine preparata per il Raspberry PI2 è reperibile al link

https://ubuntu-mate.org/raspberry-pi/

E’ più avida di risorse della Raspian ma molto più rifinita e completa come dotazione iniziale di software.

Raspberry Pi2: usiamo tutto lo spazio sulla micro SD

Con l’installazione della Raspbian è prevista alla fine del setup  l’esecuzione di uno script chiamato raspi-config che è in grado di allargare tutto lo spazio occupato dalla distro alla max capacità della microSD che abbiamo usato. Questo perché le immagini delle distro Linux sono sempre di lunghezza fissa (2Gb, 4Gb, 8Gb, ecc.) ma può capitare, come nel mio caso, che abbiamo preferito usarne una da 16Gb o addirittura 32Gb. Altre distro invece non prevedono questo meccanismo gestito (Fedora Remix, Ubuntu, ad esempio) per cui bisogna provvedere a mano. Premetto che per chi non è abituato ad usare Linux è una cosa un po’ delicata e pericolosa (per i dati che sono nella SD voglio dire) per cui facciamoci prima un backup della microSD con una delle utility che ci sono in giro. Inoltre l’esempio che farò è basato sulla Ubuntu 15.04 per Raspberry che usa uno schema a 2 partizioni. Altre distribuzioni, come Fedora, creano 3 partizioni, quindi se si ha qualche dubbio, almeno per la prima volta, è meglio farsi aiutare dal classico “amico smanettone” per capire come funzionano esattamente le cose. Ad ogni modo supponiamo di aver installato la Ubuntu 15.04 sul nostro Raspberry.

Apriamo  un terminale e diamo il comando:

sudo fdisk /dev/mmcblk0

All’interno di fdisk digitare il comando “p” per vedere le partizioni esistenti.

Nel mio caso la Ubuntu è un’immagine di 4gb installato su una microSD da 32Gb. Stiamo per ora usando solo 1/8 dello spazio disponibile.

Individuare la partizione root (“/”). Nel nostro caso è la seconda:

Segnarsi il valore di Start della partizione root (la numero 2) che in questo caso è 133120.

Cancellare la partizione 2 con i comandi “d” e poi “2”

Creare una nuova partizione con il comando “n”

Renderla primaria con il comando “p”

Inserire il numero partizione “2”

Inserire come inizio il vecchio valore della partizione 2, ovvero “133120”

Premere INVIO per l’ultimo settore, che significa che occuperemo tutto lo spazio libero.

Confermare le modifiche con il comando “w”

Fdisk esce indicando con un messaggio che la nuova configurazione sarà attiva solo dopo il reboot. Facciamolo con il comando “sudo reboot” e aspettiamo che Ubuntu riparta.

Apriamo di nuovo un terminale e diamo il comando:

sudo resize2fs /dev/mmcblk0p2

Aspettiamo che ritorni il prompt ed esaminiamo la situazione con il comando

df -kh

Ora vedremo che la partizione denominata “/” si è espansa al massimo della microSD.

Devo dire che stranamente la Ubuntu 15.04 non ha previsto una partizione di swap, il che potrebbe in teoria portare al blocco del sistema operativo in alcuni casi. Lo spazio è poco, e le cose potrebbero anche andare bene così. Comunque terrò in prova la Ubuntu e se si dovesse sentire la mancanza di uno spazio di swap posterò anche la procedura, per i meno esperti, capace di creare una terza partizione di almeno 2 Gb riservata allo swap.

E’ arrivato!

2015-05-07 11.27.29

 

E’ arrivato il secondo Rasperry PI2. Stesso contenitore del precedente, ma a differenza del primo che era di colore nero, stavolta mi sono concesso un colore bianco Apple-like molto piacevole. Questo contenitore è piuttosto robusto, l’unico inconveniente è che, essendo stato progettato per il precedente B+, calza a pennello ma la feritoia al suo interno evidentemente prevista per la cpu del B+ non corrisponde se non parzialmente alla posizione della cpu del PI2, il che rende quasi impossibile  il piazzamento di un’aletta di raffreddamento per il processore.  “Quasi” significa che allargando in qualche modo il buco che si vede in figura si può ovviare al problema. Peccato, perché a parte questo inconveniente mi sembra un ottimo contenitore.

pi2

Dopo il primo PI2, che ho installato senza interfaccia grafica ed è dedicato esclusivamente a contenere questo sito, ho deciso di utilizzare quest’altro per testare proprio l’utilizzo delle interfacce grafiche, prima di dedicarlo a qualcosa di più produttivo. Fin qui mi sono accorto che la GUI della Fedora 21 remix non è proprio un campione di stabilità: è bastato il primo aggiornamento di sistema per far sì che Xfce ogni tanto desse in escandescenze, blinkando in nero lo schermo ripetutamente per circa 1 secondo ogni minuto o giù di lì, cosa molto fastidiosa. Midori, il browser web, tende a crashare piuttosto spesso e per metterlo in crisi bastano i siti dei più diffusi quotidiani nazionali, pieni di codice java, macromedia flash e paccottiglia varia. Senza mezze misure lo trovo praticamente inusabile, almeno allo stato attuale. Insomma, la Fedora Remix 21 mi piace molto se usata come server testuale ma per quanto riguarda Xfce e Midori non ci siamo proprio.

Raspian al contrario la trovo più adatta per l’uso desktop del Raspberry PI2. Anche Epiphany, il Web Browser in dotazione con la distribuzione carica piuttosto bene pagine complesse anche se mi sembra che non supporti comunque il codice di Flash. Tutto questo è comunque ancora frutto di un utilizzo di una manciata di minuti, per cui mi riservo di esprimere un giudizio più approfondito dopo almeno alcuni giorni di uso. In questo caso ho deciso di utilizzare una microSD di qualità elevata da “ben” 32 Gb, e devo dire che Raspian, con il solito script iniziale di configurazione raspi-config, mi ha permesso di utilizzare per intero l’intera capacità della scheda senza dover intervenire manualmente come avevo dovuto fare con la Fedora.

 

 

Raspberry Pi2: attenti al cavo HDMI

Il Raspberry Pi2 ha come uscita video (e anche audio) un connettore HDMI che in genere permette di collegarlo ad un televisore con l’entrata corrispettiva. Però se troviamo più comodo collegarlo ad un monitor per Pc abbiamo bisogno di comprare un cavo HDMI-DVI, e fin qui tutto bene perché i segnali sono digitali da entrambi i lati, oppure di un cavo HDMI-VGA.

Qui bisogna fare un po’ di attenzione, perché esistono in commercio dei cavetti HDMI-VGA (costo dai 3 euro ai 6 euro) che non funzionano. Il fatto è che lo standard HDMI è digitale mentre il segnale VGA è analogico, quindi da qualche parte bisogna pur provvedere a fare la conversione A/D. Questi cavetti si limitano semplicemente a passare il segnale da uno standard all’altro senza avere un convertitore incorporato. Succede quindi che collegandoli dal Raspberry ad un monitor VGA non funzionano. Si riconoscono perché sono semplicemente dei cavi, spesso dotati da ambo i lati di filtri anti-disturbo (sono dei rigonfiamenti cilindrici) ma nulla di più.

Tra l’altro il problema è che di solito vengono venduti nei negozi o nei siti online senza dare indicazione del fatto che non avendo un convertitore A/D nel passaggio del segnale nella maggior parte degli apparecchi non funzioneranno. E quindi basta fare un giro tra le recensioni di questi siti online per trovare pletore di utenti che li hanno comprati e dichiarano che, appunto, non funzionano.

Apparentemente si tratta di cavi “illogici”. Collegare un uscita digitale ad un’entrata analogica senza “toccare” il segnale non è una cosa che può funzionare. E allora, a cosa servono? Non è stato facile scoprirlo. Ho dovuto girare un po’ per i siti finchè ho trovato un venditore che dichiarava appunto che questo caso serviva solamente per collegare:

La playstation al monitor – Ricevitori HDTV – Proiettori – Dispositivi HDMI dotati di lettore DVD.

Insomma, esistono alcuni apparecchi con cui un cavo del genere funzionerà e che quindi si faranno carico al loro interno della conversione A/D, ma non Pc, Notebook e Monitor per Pc.

Quello che serve a noi invece è un cavetto dotato di un convertitore A/D che sarà alimentato dalla presa HDMI del Raspberry stesso, come questo mostrato qui sotto.

hdmi_vg

Ne esistono due tipi: quelli che portano solamente il segnale video e quelli che hanno anche un piccolo jack per il segnale audio. Decisamente più comodo il secondo tipo, con un costo che varia dai 15 euro ai 25 euro. Questi adattatori dichiarano esplicitamente di avere un convertitore A/D e finiscono immancabilmente con uno “scatolotto” che contiene la presa VGA femmina.