Archivi tag: bash

Docker – costruire i contenitori

Docker costruire i contenitori

Docker costruire i contenitori

Recentemente abbiamo parlato della virtualizzazione tramite Docker (vedi articolo Docker – cosi cambia la virtualizzazione) e, prima di proseguire sara’ meglio rifare una piccola introduzione.

Docker e’ indubbiamente una valida alternativa alla virtualizzazione tradizionale nel mondo Linux. Questo tipo di virtualizzazione, detta a “container” non emula un’ intero hardware come fanno invece gli hypervisor tipo VMware, Virtualbox, Xen o KVM, ma crea invece dei “contenitori” nel sistema operativo dove possono essere messe in esecuzione applicazioni di vario genere in modo del tutto separato una dall’altra.

Dato che con il cloud il ruolo del sistema operativo diventa sempre meno importante perchè si punta più sullo strato applicativo, PaaS, rendendo il tutto più flessibile. A questo punto se dovessimo far girare 1000 clienti su un ambiente condiviso, diventerebbe interessante disporre di una tecnologia di virtualizzazione che riduca al minimo fisiologico gli overhead.

La virtualizzazione classica non è così, perchè per ogni ambiente applicativo, riservato ad un cliente, si dovrebbe  lanciare una intera macchina virtuale con dentro l’intero sistema operativo. E allora perchè non condividere lo stesso sistema operativo e invece isolare solo gli ambienti di esecuzione delle applicazioni , tipo application server, DB ecc…

I container sono dunque alla base dei moderni servizi cloud di tipo PaaS (Platform as a service) che usano questo tipo di virtualizzazione per misurare il consumo di risorse ed assegnarne i limiti.

Ad esempio, se su uno stesso server fisico, con una soluzione di virtualizzazione di tipo hypervisor si possono ospitare, supponiamo 50 virtual machines, con la virtualizzazione a container si potra’ arrivare anche a 1000 container. Questo perchè un container di per sè è solo un contenitore di processi, mentre una virtual machine completa contiene tutto un ambiente operativo emulato.

Il container può anche essere portabile, infatti ci basta copiare la directory che contiene il filesystem modificato dall’utente dopo la creazione del container, un piccolo file di configurazione, ed il container diventera’ eseguibile su qualsiasi sistema che supporti LXC.

Il concetto è talmente interessante, che qualcuno ha pensato di fare un sistema operativo Linux interamente basato sui container, in cui non c’è nemmeno un package manager perchè si assume che gli applicativi saranno solo in forma di container. Coreos è nato proprio con il principio di supportare ambienti di esecuzione a container, togliendo dal sistema tutto quello che non è strettamente necessario per farlo funzionare.

INSTALLAZIONE

Abbiamo tre possibili metodi d’installazione :

1) Centos

sudo yum -y install docker-io

2) Debian/Ubuntu

sudo apt-get update 
sudo apt-get install docker.io 
sudo sudo apt-get install lxc-docker

3) Download con Curl

sudo curl -sSL https://get.docker.io/ubuntu/ | sudo sh

* Linkiamo docker alla nostra bash

ln -sf /usr/bin/docker.io /usr/local/bin/docker
sed -i '$acomplete -F _docker docker' /etc/bash_completion.d/docker.io

* Rendiamo docker attivo all’avvio

update-rc.d docker.io defaults

P.S.: Ci sono molti contenitori già disponibili nella community docker, che possono essere trovati attraverso una ricerca. Ad esempio con questo comando cerchero’ la parola debian:

# docker search debian

NAME    DESCRIPTION      STARS     OFFICIAL   AUTOMATED
debian  Debianbaseimage  310         [OK]
google/debian            31                     [OK]

….e molte altre che potrete leggere dall’output completo.

** Installiamo e facciamo provisioning con una immagine Centos

# docker pull blalor/centos  # GitHub blalor/docker-centos-base  image

oppure per chi fosse interessato ad una immagine con gia inserito il tool Ansible (per il Configuration Management ed IT Automation) di cui ho da poco parlato, potra’ scegliere quest’altra immagine.

sudo docker pull ansible/centos7-ansible # GitHub Ansible on Centos7
Pulling repository ansible/centos7-ansible
fff2afd18a57: Download complete

Avviamo un container docker

Attiveremo ora un contenitore centos-base con una shell bash, utilizzando il comando run. Docker eseguira’ questo comando in un nuovo contenitore, -i attribuisce stdin e stdout, -t assegna un terminale.

docker run -i -t centos /bin/bash

Questo è tutto! Adesso stai usando una shell bash all’interno di un contenitore centos.
Per scollegarsi dalla shell la sequenza di escape e’ : Ctrl-p + Ctrl-q.

Diamo un’occhiata ai processi attivi tramite :

# docker ps -a
CONTAINER   ID IMAGE          COMMAND     CREATED
fff2afd18a57     blalor/centos     /bin/bash         About an hour ago

Il Dockerfile
Per automatizzare la procedura di creazione e modifica di un container docker, possiamo utilizzare il Dockerfile, che è una delle parti principali di Docker, infatti attraverso il Dockerfile è possibile non solo fare il deploy istantaneo automatizzato di più istanze e più container, ma è anche possibile eseguire il provisioning di queste istanze, automatizzando task di gestione del sistema, installazione del software e molto altro.

Nel prossimo articolo vedremo un esempio utile, utilizzando ad esempio un’applicazione leggera, che puo’ lavorare molto bene in un contenitore, come NGINX, il noto server web/cached per la gestione di siti web/proxy ad alto carico.

#DockerContainerAvviato

Shellshock Bug verifichiamo il nostro sistema

Shellshock Bug

Shellshock Bug

I ricercatori di Red Hat hanno recentemente segnalato un particolare bug denominato “Shellshock” presente nella Shell che potrebbe mettere in serio pericolo milioni di sistemi Linux. A quanto pare questo bug potrebbe essere utilizzato da utenti malintenzionati per poter operare sul sistema operativo.

Shellshock pare sia un exploit molto più pericoloso di Heartbleed, che avrebbe potuto mettere letteralmente in ginocchio la maggioranza dei web server esistenti, perché permette di prendere il pieno controllo della macchina, non importa quale, ed eseguire del codice (ottenendo tutti i permessi d’amministrazione).

Cos’è e come funziona Shellshock?  In pratica, è una vulnerabilità del terminale, che gli utenti di Windows conoscono meglio come Prompt dei comandi,  che espone all’attacco una serie di servizi, da Apache al DHCP dei router ecc… Se la versione di BASH installata è afflitta dal bug, un malintenzionato potrebbe eseguire da remoto una serie d’operazioni, che spaziano dai comandi CGI ai demoni avviati in automatico dal sistema operativo. Significa che, senza una patch ad hoc chiunque potrebbe prendere possesso dei server.

Non è però ben chiaro come questi possano accederne dato che effettuare modifiche nel sistema, installazione di software ecc vengono richiesti i permessi di root. Da notare inoltre che Red Hat e le principali distribuzioni Linux hanno già risolto il bug, basterà quindi aggiornare la distribuzione o server Linux per risolvere questo problema.

Possiamo facilmente verificare se il nostro sistema operativo è o meno  “infetto” da Shellshock.

Basta semplicemente avviare il terminale e digitare:

env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

se avremo come risultato:

vulnerable
this is a test

vuol dire che nel nostro sistema è presente il bug Shellshock in bash

se invece abbiamo come risultato

this is a test

possiamo star tranquilli.

Per risolvere il problema bastera’ semplicemente aggiornare la Bash digitando da terminale:

Per Debian, Ubuntu e derivate:

sudo apt-get update
sudo apt-get install bash

Per Fedora, CentOS, Red Hat e derivate:

sudo yum install bash

Per openSUSE e derivate:

sudo zypper install bash

Per Arch Linux e derivate, Chakra, Manjaro ecc:

sudo pacman -Sy bash

Al termine bastera’ rilanciare il comando di verifica, ed ecco risolto il problema di Shellshock.

 

#ShellshockBugVerifichiamo

Virtualizzazione e provisioning senza sforzo

Vagrant Virtualization Box

Vagrant Virtualization Box

La virtualizzazione ha sicuramente cambiato il modo di lavorare e di pensare alla gestione dei sistemi informatici aziendali o dei service provider, ed il cloud ha aggiunto un’ulteriore strato, sia di liberta’, ma anche di complicazione in piu’, nella gestione dei nuovi sistemi ad alta affidabilita’ che devono essere in grado di scalare nel minor tempo possibile ecc….

Queste esigenze hanno portato alla nascita di innumerevoli sistemi di virtualizzazione, tra i piu’ conosciuti sicuramente ci sono Xen, Vmware, Kvm, Virtuozzo, Virtualbox, Openvz …..! che per certi versi si trasformano in un incubo per gli amministratori di sistema, costretti ad avere diversi ambienti di gestione delle VM su diversi sistemi e con molteplici file di configurazione da settare.

Infatti quando ci troviamo ad amministrare un ambiente cloud con molte macchine, il rischio di dover aggiungere una macchina in più e doverla successivamente configurare in poco tempo per il deploy e la messa in produzione insieme a tutte le altre è molto alto. In più, se siamo all’interno di un’architettura che deve scalare rapidamente per rispondere in modo agile alle esigenze degli utenti (e chiaramente dell’azienda), dover attendere l’installazione del sistema operativo e poi del software non è certamente divertente. Per tutte queste esigenze, Vagrant potrebbe risultare la giusta soluzione che può semplificarci la vita, permettendoci di aggirare tutte queste “rogne”

Vagrant è un gestore di macchine virtuali che può usare parecchi hypervisor tra cui VirtualBox, il predefinito, ma anche VMWare, Xen e KVM. Attraverso questo software infatti potremo basarci su una struttura di base comune a tutte le macchine, che contiene il sistema operativo (anche se poi vedremo come personalizzare questa alberatura), e mantenere degli step comuni nella configurazione delle nostre istanze virtuali, per poi dedicarci solo alle rifiniture, risparmiando tantissimo tempo grazie alle capacità di elaborazione dei datacenter che abbiamo in-house o magari in cloud.

Per inizializzare il nostro primo progetto Vagrant, abbiamo solo bisogno di spostarci in una directory vuota e dare il comando (avendo già installato il software):

Installazione Vagrant

### Verificare di aver installati i seguenti pacchetti : rubygems ruby1.9.1-dev virtualbox-4.2 (o superiori)
# sudo apt-get install vagrant
# vagrant plugin install vagrant-vbguest

Le Box di Vagrant
Il primo concetto fondamentale da fare nostro, per quanto riguarda Vagrant, è quello del concetto di Box. Una Box per quanto riguarda questo ambiente di virtualizzazione infatti è una vera e propria scatola che contiene il sistema operativo, e tutto quello di cui abbiamo bisogno come i software di base ed ogni loro configurazione di base. Al punto di partenza abbiamo delle Box rese disponibili dai server di Vagrant, ma possiamo tranquillamente aggiungerne altre: tutto quello di cui abbiamo bisogno è un po’ di fantasia coi nomi, e di conoscere l’URL remoto tramite il quale scaricare la Box (ne trovate parecchie già fatte su Vagrantbox.es oppure su Hasicorp), con questa sintassi da riga di comando.

# vagrant init
# vagrant box add name url

che, traducendolo con un esempio reale:

# vagrant box add precise32 http://files.vagrantup.com/precise32.box

Che non farà altro che aggiungere al nostro progetto Vagrant una Box Ubuntu 12.04 a 32 bit.

Il Vagrantfile
Una volta scaricata la nostra Box di partenza, possiamo cominciare a configurare il nostro progetto Vagrant tramite il Vagrantfile che abbiamo a disposizione e che si presenta essenzialmente come un file Ruby con vari namespace, ma niente paura, non è necessario conoscere direttamente Ruby per la configurazione (anche se può aiutare), ed è possibile fare riferimento alla documentazione per conoscere i vari prefissi e le possibilità che abbiamo a disposizione. Ogni volta che eseguiamo un comando Vagrant, il Vagrantfile viene cercato in tutte le directory di livello superiore nell’albero.

Il file può avere grossomodo un aspetto del genere:

Esempio di un cluster di 7 Boxes. Preso da:
### https://github.com/patrickdlee/vagrant-examples

domain   = 'example.com'
 
nodes = [
  { :hostname => 'ex7proxy',   :ip => '192.168.0.42', :box => 'precise32' },
  { :hostname => 'ex7db',      :ip => '192.168.0.43', :box => 'precise32' },
  { :hostname => 'ex7web1',    :ip => '192.168.0.44', :box => 'precise32' },
  { :hostname => 'ex7web2',    :ip => '192.168.0.45', :box => 'precise32' },
  { :hostname => 'ex7static1', :ip => '192.168.0.46', :box => 'precise32' },
  { :hostname => 'ex7static2', :ip => '192.168.0.47', :box => 'precise32' },
  { :hostname => 'ex7cache',   :ip => '192.168.0.48', :box => 'precise32' },
]
 
Vagrant::Config.run do |config|
  nodes.each do |node|
    config.vm.define node[:hostname] do |node_config|
      node_config.vm.box = node[:box]
      node_config.vm.host_name = node[:hostname] + '.' + domain
      node_config.vm.network :hostonly, node[:ip]
 
      memory = node[:ram] ? node[:ram] : 256;
      node_config.vm.customize [
        'modifyvm', :id,
        '--name', node[:hostname],
        '--memory', memory.to_s
      ]
    end
  end
 
  config.vm.provision :puppet do |puppet|
    puppet.manifests_path = 'puppet/manifests'
    puppet.manifest_file = 'site.pp'
    puppet.module_path = 'puppet/modules'
  end
end

Prima di arrivare a questo livello tuttavia, è necessario cominciare dalle basi: il primo file di configurazione di Vagrant che andremo a scrivere conterrà ben poche specifiche, e si baserà esclusivamente sulla Box che abbiamo scelto per la nostra prima macchina virtuale.

# Una singola Box.
#
Vagrant.configure(“2”) do |config|
config.vm.box = “precise32”
end

Esempio per una singola Box.

Vagrant.configure("2") do |config|
config.vm.box = "precise32"
end

Inoltre il Vagrantfile deve essere soggetto a version control (tramite git ad esempio) per tenere traccia di ogni modifica e rendere il tutto facilmente riportabile in una nuova architettura

Avviamo la Box

# sudo vagrant up
Bringing machine 'default' up with 'virtualbox' provider...
[default] Importing base box 'precise32'...
[default] Matching MAC address for NAT networking...
[default] Setting the name of the VM...
[default] Clearing any previously set forwarded ports...
[default] Clearing any previously set network interfaces...
[default] Preparing network interfaces based on configuration...
[default] Forwarding ports...
[default] -- 22 => 2222 (adapter 1)
[default] Booting VM...
[default] Waiting for machine to boot. This may take a few minutes...
[default] Mounting shared folders...
[default] -- /vagrant

Adesso che abbiamo il nostro progetto funzionante, basterà dare

# vagrant ssh
Last login: Fri Apr 15 05:43:58 2011 from 10.0.2.2
[vagrant@localhost ~]$

per collegarci ed esserne subito operativi all’interno della nostra box.

Provisioning
Vagrant non è solo un sistema per avviare velocemente delle macchine virtuali, infatti ci permette anche di controllarle, e di controllarne le impostazioni nel tempo, insieme al software installato. Possiamo quindi gestire la configurazione automatica secondo le nostre esigenze delle varie Box che abbiamo, attraverso una struttura di provisioning abbastanza flessibile che supporta normali shell script (Bash), il buon vecchio Puppet, ma anche Chef e Ansible.

Tramite questa infrastruttura possiamo modificare il Vagrantfile per eseguire quindi qualsiasi istruzione, che sia configurata per script Puppet oppure attraverso Bash. Ad esempio, possiamo utilizzare la piccola struttura riportata di seguito, che proviene direttamente dalla documentazione di Vagrant e che mostra come sia facile scriversi uno script di configurazione da mandare poi in pasto alla propria Box.

$script = <<SCRIPT
echo I am provisioning...
date > /etc/vagrant_provisioned_at
SCRIPT
Vagrant.configure("2") do |config|
config.vm.provision "shell", inline: $script
end

Non solo VirtualBox

Una volta imparato a usare Vagrant, avremo comunque basato tutto il nostro lavoro su VirtualBox. Tuttavia, potremmo anche avere qualcosa in contrario sull’uso di VirtualBox, e voler usare altri provider che ci permettano un’amministrazione più efficace o semplicemente il riciclo di competenze che già abbiamo. Ad esempio, Vagrant supporta tramite plugin anche l’integrazione con VMWare o con Xen; questi plugin sono installabili attraverso il gestore integrato nel software, semplicemente tramite un singolo comando, esattamente come in un classico gestore di pacchetti:

# vagrant plugin install vagrant-vmware-fusion

Oppure se invece di VMWare Fusion usate la variante Workstation:

# vagrant plugin install vagrant-vmware-workstation

Una volta installato il plugin, ed ovviamente il software di providing delle macchine virtuali che vogliamo testare, ci bastera’ modificare il Vagrantfile, con istruzioni come queste nell’ esempio:

Esempio tratto da [ http://puppetlabs.com/blog/new-vmware-provider-gives-vagrant-a-boost ]

config.vm.provider :vmware_workstation do |v|
v.vmx["memsize"] = "2048"
end

Vagrant può ovviamente essere configurato per essere alla base di una complessa configurazione in ambiente cloud, o della propria infrastruttura più modesta.

Se questo primo articolo vi ha incuriositi, la documentazione ufficiale, passo passo, vi sta aspettando : VAGRANT DOC

Nel prossimo articolo vedremo come sfruttare le potenzialita’ di Vagrant + Docker.

#VagrantVirtualizzazioneeProvisioning

Bloccare la pubblicita’ senza plug-in

Linux Ad Block

Linux Ad Block

 

Negli ultimi anni i banner pubblicitari presenti nelle pagine di molti siti si sono trasformati in un mostro incontrollato e soprattutto molto invasivo e, a causa dell’abuso da parte di alcuni, sono finiti per diventare la bestia nera di Internet, inducendo numerosi utenti a trovare un modo per bloccarli con i metodi più disparati.

 

Tra questi figurano ad esempio due note estensioni per browser, ad esempio su Chrome tra i piu’ conosciuti possiamo trovare AdBlock e AdBlock Plus, che svolgono egregiamente il proprio lavoro modificando al volo il foglio di stile delle pagine web impedendone la visualizzazione. D’altra parte questo vantaggio ha un peso materiale: entrambe le estensioni finiscono per appesantire notevolmente il browser, il che potrebbe essere uno svantaggio per molti.

In questo breve articolo verra’ illustrato un metodo efficace per bloccare la visualizzazione dei banner pubblicitari dei più noti circuiti pubblicitari, usando una versione modificata del file /etc/hosts

 

Bloccare la pubblicità senza AdBlock 

Il criterio che utilizzeremo è di per se molto semplice, infatti il file /etc/hosts permette di associare manualmente host ad indirizzi IP senza affidarsi alla risoluzione tramite server DNS; grazie al lavoro ed alla costanza di alcuni sviluppatori, è possibile scaricare un file modificato ad-hoc affinché agli host dei più noti banner pubblicitari venga automaticamente associato l’indirizzo IP 127.0.0.1, ovvero l’indirizzo locale della propria macchina (localhost).  Risultato:
i banner non verranno più visualizzati!

Senza dilungarci in ulteriori spiegazioni procediamo alla modifica: andiamo innanzitutto a creare un backup del file /etc/hosts presente nel nostro sistema operativo, da ripristinare in caso di problemi, dopodiché, andremo a creare uno script per il download/upgrade automatico del file che inseriremo nel nostro crontab.

*Preparazione
Creamo innanzitutto un backup del nostro file /etc/hosts originale da ripristinare in caso di problemi: per farlo, da terminale, digitiamo

# sudo cp /etc/hosts /etc/hosts.bak

Adesso creiamo lo script che sara’ in grado di scaricare automaticamente il nuovo file host, concedendogli eventualmente una serie di tentativi qualora la connessione ad Internet non fosse subito disponibile, quindi dal nostro terminale digitiamo

# sudo vim /usr/local/bin/adblock.sh

All’interno del file appena creato inseriamo quanto segue:

#!/bin/bash

exec 2> /tmp/adblock.log
exec 1>&2
set -x
wget -q -O - 1 --retry-connrefused http://someonewhocares.org/hosts/hosts | grep -P "^(127.0.0.1 |::1 |# )" > /etc/hosts

chmod 644 /etc/hosts

Salviamo il file ed usciamo dall’editor, dopodiché renderlo eseguibile con il comando

# sudo chmod +x /usr/local/bin/adblock.sh

Ora facciamo in modo di aggiungere il nostro nuovo script nel crontab del sistema in modo da farlo eseguire, in automatico, almeno ogni 4 ore (la scelta ottimale sta a voi).

Per coloro che non sono soliti ad utilizzare la gestione del crontab facciamo un breve ripasso sulla sua sintassi :

Esempi di sintassi dei comandi cron

Il file crontab deve rispettare una sintassi ben precisa, diversamente il sistema non accetterà le impostazioni. Quello che segue è un esempio generico:

5 3 * * * /usr/bin/apt-get update

L’esempio precedente eseguirà il comando apt-get update ogni giorno di ogni mese alle ore 03:05 (l’orario viene indicato nel formato a 24 ore).

La prima parte della voce descrive quando l’azione deve essere effettuata. Ci sono cinque campi (nell’esempio precedente, «5 3 * * *»), separati da uno spazio, ognuno dei quali accetta un numero, un asterisco o un testo appropriato. I campi specificano, in ordine (tra parentesi l’abbreviazione standard):

  • minuti, da 0 a 59 («m»);
  • ore, da 0 a 23 («h»);
  • giorno del mese, da 1 a 31 («dom»);
  • mese, da 1 a 12 («mon»);
  • giorno della settimana, da 0 (domenica) a 6 (sabato) («dow»)

 

Quelle che seguono sono alcune varianti della precedente pianificazione d’esempio:

Stringa

Descrizione

«12 03 * * *»

tutte le mattine, più o meno alle 3

« 12 03 15 * *»

tutti i 15 del mese, alla stessa ora

«12 03 31 * *»

7 volte l’anno, alla stessa ora

«0 12 * * 0»

ogni domenica, a mezzogiorno

«2 0 * * *»

ogni giorno, più o meno a mezzanotte

«02 03 * * 1,5»

ogni lunedì e venerdì, alle 3 del mattino circa

Altri esempi per aiutarvi a capire le varie combinazioni :

  • Esempio 1
1-30 * * * * /comando/da/eseguire

il comando verrà eseguito ogni giorno, ogni ora e quando i minuti vanno da 1 a 30.

  • Esempio 2
30 * 1-7 * * /comando/da/eseguire

il comando verrà eseguito i primi sette giorni di ogni mese, ad ogni ora e quando i minuti valgono 30.

  • Esempio 3
00 */2 15 * * /comando/da/eseguire

il comando verrà eseguito il quindicesimo giorno di ogni mese, ogni due ore.

  • Esempio 4
00 1-9/2 1 5 * /comando/da/eseguire

il comando viene eseguito il primo maggio alle 1,00 – 3,00 – 5,00 – 7,00 – 9,00. Cioè ogni due ore dalle 1,00 alle 9,00.

  • Esempio 5
00 1-10/2 1 5 * /comando/da/eseguire

il comando viene eseguito il primo maggio alle 1,00 – 3,00 – 5,00 – 7,00 – 9,00. Cioè ogni due ore dalle 1,00 alle 10,00. Si noti come l’ultimo valore utile dell’intervallo non coincida, in questo caso, con l’ora in cui viene fatta partire l’ultima esecuzione giornaliera del comando.

  • Esempio 6
00 13 2,8,14 * * /comando/da/eseguire

il comando verrà eseguito il secondo, l’ottavo e il quattordicesimo giorno di ogni mese alle 13.00

  • Esempio 7
30 13 1-15 4,10 * /comando/da/eseguire

il comando verrà eseguito i primi quindici giorni di aprile e ottobre alle 13,30.

  • Esempio 8
*/30 13,20 * 1-7,9-12 1-5 /comando/da/eseguire

il comando verrà eseguito nei giorni feriali (da lunedì a venerdì) di tutti i mesi tranne agosto, alle 13,00 – 13,30 – 20,00 – 20,30.

  • Esempio 9
00 14,19 1-15 * 5 /comando/da/eseguire

il comando verrà eseguito alle 14,00 e alle 19,00 dei primi quindici giorni di ogni mese e anche ogni venerdì.

** Ora per tornare al nostro esempio possiamo editare il file del nostro crontab tramite il comando

# crontab -e

ed in base agli esempi appena visti la riga di configurazione per far si che lo script venga eseguito ogni 4 ore di ogni giorno dell’anno sara’ la seguente :

# 00 */4 * * *  /usr/local/bin/adblock.sh

una volta salvato ed usciti non rimarra’ altro da fare che riavviare il servizio per far si che la modifica diventi operativa

# sudo /etc/init.d/cron restart

per verificare che effettivamente la schedulazione sia stata inserita verifichiamo tramite il comando

# crontab -l

Se doveste riscontrare problemi nella gestione della navigazione e voleste tornare alla configurazione iniziale vi bastera’ rieditare il crontab eliminando la stringa inserita e ripristinare il file hosts iniziale di cui avevamo fatto il backup tramite il comando :

# sudo mv /etc/hosts.bak /etc/hosts

Buon Anno!

#linuxadblocksenzaplugin

Programmare pensando da Sistemista

 

linux-python-logoUna domanda che mi faccio da quando lavoro come sistemista e’ : “quale linguaggio di programmazione dovrei imparare ??“; e’ una domanda facile da formulare, che dovrebbe presupporre un’altrettanto facile risposta, ma ahimè non é così semplice, perlomeno non nel mio caso. Certo, i linguaggi di programmazione non mancano ed in giro ci sono dozzine di fonti di ottima qualità, ma penso comunque che per poter fornire un consiglio si dovrebbe sempre poter conoscere bene chi pone la domanda, ossia:

 

  • il suo background è scientifico o umanistico?
  • conosci bene l’inglese? (poiche’ la maggior parte delle fonti che consiglierei sono in inglese)
  • qual’è la tua età? ecc…!

…..insomma sono tanti i fattori da considerare e tutti hanno il loro peso da non sottovalutare.
In tempi non troppo lontani programmare significava conoscere il funzionamento dei computer a basso livello, comprendere a fondo la loro teoria e la loro struttura. Ma oggi è molto diverso. La gran parte dei programmatori (web 3.0) sono orientati alle applicazioni web/cloud ed i vecchi linguaggi macchina, tipo Assembly, li ha solo sentiti nominare a scuola. Questo anche perche’ i linguaggi ad alto livello (Java, Python…) ci permettono di concentrarci sulla soluzione dei problemi (gli algoritmi) delegando al compilatore la creazione delle istruzioni di basso livello.

Certo questa e’ una buona notizia ma, partendo da me stesso, se non fai il programmatore ed un linguaggio di programmazione ti serve per crearti scripts di ottimizzazione dei sistemi , non e’ pensabile dover conoscere 5/6 linguaggi diversi ecco perche’ in campo sistemistico resistono gli ottimi script Bash oppure l’ardimentoso Perl.

Se mi avete seguito e siete almeno parzialmente d’accordo con l’analisi fatta vi ricompenso con lo stesso consiglio che mi sono dato qualche settimana fa: Python.

Non mi voglio dilungare nella presentazione di questo linguaggio di cui credo abbiate per lo meno sentito nominare, le cui caratteristiche principali di funzionalita’, operabilita’, performance ecc… lo rendono tra i migliori da imparare anche per usi che esulano dalla programmazione allo stato puro; per altri dettagli od info potete leggere l’articolo dal seguente URL “caratteristiche del linguaggio Python“.

Quello che voglio segnalare e’ che molto spesso nella grande, a volte troppa, quantita’ di materiale recuperabile, spesso non si trova qualcosa adatto davvero alle nostre esigenze e che renda l’avvicinamento e la comprensione di un nuovo linguaggio facile, senza annoiare.

Pensare da Informatico e’ un libro che svolge bene il suo compito avvicinando i nuovi utenti a questo ottimo linguaggio in modo guidato e lineare proprio perche’ frutto delle esigenze di un’insegnante che voleva spiegare ai propri alunni un nuovo modo di programmare. Il libro originale e’ in inglese ma ne esiste un’ottima versione PDF tradotta in Italiano, questo e’ il link per il download PDF , mentre questo e’ il link per la versione WEB .

La versione originale “How to Think a Computer Scientist ” sottotitolo (Learning with Python) 3rd edizione e’ scritta da [Peter Wentworth, Jeffrey Elkner, Allen B. Downey, and Chris Meyers ] .

Buona lettura !