Come Cambiare Sfondo in Modo Periodico su Ubuntu

Stranamente Ubuntu Unity non prevede un meccanismo per cambiare lo sfondo periodicamente selezionando delle immagini da una cartella come invece è possibile fare su praticamente ogni altro desktop environment.

A questo è comunque possibile ovviare con facilità sfruttando il comando
gsettings
che permette di gestire da linea di comando molte delle impostazioni dell’interfaccia grafica.

Il comando per cambaire lo sfondo è molto semplice

gsettings set org.gnome.desktop.background picture-uri “file://
e potete testarlo con un’immagine a vostra scelta.

Il secondo obiettivo che ci eravamo posti è quello scegliere un’immagine casualmente un’immagine da una cartella. Si può fare in modo molto semplice con gli strumenti della shell unix. In primo luogo usiamo find per farci dare l’elenco dei file con i path assoluti, utilizziamo poi sort per mischiare casualmente l’eleco; sort, infatti, con l’opzione
-R restituisce un’ordinamento casuale. Usiamo infine
head
per selezionare il primo elemento della lista.

find |sort -R |head -1
Per combinare le due cose utiliziamo le variabili della shell

export SFONDO=”$(find |sort -R |head -1)”; gsettings set org.gnome.desktop.background picture-uri \”file://${SFONDO}\”
L’ultimo cosa che ci rimane da fare è rendere periodica questa operazione. Per farlo useremo ovviamente
crontab
ma il comando così comè non funzionerebbe perché gsettings, per funzionare correttamente utilizza le variabili di ambiente e crontab crea un ambiente “anomalo” in cui molte di queste variabili o non sono definite o hanno valori specifici.

Per il nostro script ci serve il valore di
DBUS_SESSION_BUS_ADDRESS
. Possiamo vederne il valore con un semplice echo

echo $DBUS_SESSION_BUS_ADDRESS
Questa variabile permette a gsettings di sapere su quale ambiente grafico andare ad agire e deve essere letta “live” cambiando ad ogni sessione grafica. Per recuperarla bisogna fare un po’ di passi. In primo luogo
pgrep
ci permette di recuperare il PID del processo. Con questa operazione possiamo andare a recuperare il valore della variabile dalle informazioni in proc

export PID=$(pgrep gnome-session)
grep -z DBUS_SESSION_BUS_ADDRESS /proc/${PID}/environ
infine awk ci permette di separare il valore dal nome della variabile

grep -z DBUS_SESSION_BUS_ADDRESS /proc/${PID}/environ|awk -F= ‘{print $2″=”$3}’
Non ci rimane che eseguire
crontab -e
ed inserire una riga con la schedulazione voluta ed i comandi

*/10 * * * * export PID=$(pgrep gnome-session);export DBUS_SESSION_BUS_ADDRESS=$(grep -z DBUS_SESSION_BUS_ADDRESS /proc/${PID}/environ|awk -F= ‘{print $2″=”$3}’) ;export SFONDO=”$(find |sort -R |head -1)”; gsettings set org.gnome.desktop.background picture-uri \”file://${SFONDO}\”
L’*/10 sta ad indicare che il comando deve essere eseguito ogni 10 minuti.

Approfondisci

Utilizzare Squid come Reverse Proxy

Squid è un prodotto eccellente per fare da web cache; sia che si voglia alleggerire il carico sulla connessione, sia che si voglia fare del filtraggio a livello applicativo sia che si abbia la necessità di fare del monitoraggio molto dettagliato dell’uso del web su di una rete, la flessibilità di questo applicativo permette di intervenire praticamente su ogni aspetto del protocollo http e non solo.

Segnalo fin da subito che squid, come tutti i prodotti di web cache, richiede un’ attenzione particolare alla configurazione, in particolare per l’aspetto dei permessi; si corre il rischio, infatti, di mettere su internet un server proxy che può essere usato da terzi per mascherare le proprie attività.

Oggi voglio mostrare come configurare squid per usarlo come reverse-proxy. Si parla di proxy quando la cache viene messa davanti ai client e risolve al posto di questi le chiamate su internet. Si parla di reverse-proxy quando il server viene posto davanti ai web server e raccoglie al posto dei server web le chiamate dei client.

La ragione base per cui si fa questo è migliorare le prestazioni incidendo il meno possibile sui costi. I server cache infatti mantengono in memoria e/o su disco le risposte alle richieste più frequenti dei client e rispondono direttamente senza convolgere i server web; infatti sono in genere in grado si rispondere ad un numero di richieste molto più alto di un server web che sempre più spesso deve essere configurato per gestire elaborazioni pesanti.

Squid è un prodotto molto consolidato ed è presente oramai sui tutte le distribuzioni linux. Per istallarlo quindi in genere la cosa più semplice è ricorrere ai tool della propria distribuzione. Su Debian/Ubuntu:

sudo aptitude update
sudo aptitude search squid
sudo aptitude install squid
La configurazione di default di squid è molto ben fatta e contiene così tanti commenti da essere quasi completamente autoesplicativa; merita un’esame se si vuole utilizzare questo prodotto. Nel nostro caso però la costruiremo da zero. Come risulta dalla documentazione ufficiale ci sono più possibilità per la configurazione in modalità Reverse Proxy; ne analizzeremo una di uso ragionevolmente generale.

http_port 80 accel defaultsite=[server name] vhost

cache_peer [IP sorgente 1] parent 80 0 no-query originserver name=RevPro1
acl web1 dstdomain [accelerated domains list 1]

cache_peer [IP sorgente 2] parent 80 0 no-query originserver name=RevPro2
acl web2 dstdomain [accelerated domains list 2]

http_access allow web1
http_access allow web2
cache_peer_access RevPro1 allow web1
cache_peer_access RevPro2 allow web2

cache_dir diskd /var/cache/squid3 1000 32 32 Q1=64 Q2=72
cache_mem 1024 MB

cache_replacement_policy heap LFUDA
memory_replacement_policy heap GDSF
cache_swap_low 90
cache_swap_high 95
Vediamo ora questa configurazione in maggiore dettaglio:

http_port 80 accel defaultsite=[server name] vhost
In questo modo si dice a squid che lavorerà in modalità reverse-proxy e con che tipo di configurazione. Defaultsite conviene valorizarlo con il nome del server web, quali sono i siti di cui si fa reverse proxy viene specificato più avanti. Vhost specifica che la discriminante per la scelta del server di origine sarà il dominio.

cache_peer [IP sorgente 1] parent 80 0 no-query originserver name=RevPro1
Definiamo qui un server web di cui fare reverse proxy e assegniamo un nome a questa definizione (RevPro1).

acl web1 dstdomain [accelerated domains list 1]
Definiamo una lista di siti web (separati da spazi) di cui si vuole fare reverse proxy e le assegnamo un nome (web1).

cache_peer [IP sorgente 2] parent 80 0 no-query originserver name=RevPro2
acl web2 dstdomain [accelerated domains list 2]
Ripeto per un secondo server origin e una seconda lista di siti.

http_access allow web1
http_access allow web2
dico a squid che deve rispondere alle richieste (dei client) relative alle due liste di siti web1 e web2.

cache_peer_access RevPro1 allow web1
cache_peer_access RevPro2 allow web2
Associo le origin alle liste dei siti supponendo che un dato server web di origine serve alcuni dei siti mentre l’altro serve gli altri.

cache_dir diskd /var/cache/squid3 1000 32 32 Q1=64 Q2=72
cache_mem 1024 MB

cache_replacement_policy heap LFUDA
memory_replacement_policy heap GDSF
cache_swap_low 90
cache_swap_high 95
Infine queste righe configurano la cache.

Come quasi sempre su squid si definiscono degli oggetti per definire attività da permettere o vietare; si definiscono delle acl per definire il “chi” ed infine si associano questi due tipi di informazione in righe dove si definisce chi può fare cosa.

Come sempre prima di mettere in produzione un server con squid è bene leggerne la documentazione ufficiale.

Approfondisci

Replica Master Master per MySQL

ediamo ora come implementare una replica master-master per MySQL.

Per prima cosa bisogna scaricare il database MySQL. Per questo ambiente di test scarichiamo il pacchetto binario dal sito MySQL,

Ad esempio su di una distribuzione debian-like procederemo come al solito con

aptitude search mysql
aptitude install mysql-server
Andiamo ora a creare due istanze del db.

Creiamo come root le datadir

mkdir /var/lib/mysql-mm-1
mkdir /var/lib/mysql-mm-2
Sempre come root prepariamo le configurazioni

cp -rp /etc/mysql/my.cnf /etc/mysql-mm-1/my.cnf
cp -rp /etc/mysql/my.cnf /etc/mysql-mm-2/my.cnf
Editiamo ora il file my.cnf fino ad ottenere per il nodo 1 qualche cosa come

[client]
port = 3307
socket = /var/run/mysqld/mysqld-mm-1.sock

[mysqld_safe]
socket = /var/run/mysqld/mysqld-mm-1.sock
nice = 0

[mysqld]
user = mysql
pid-file = /var/run/mysqld/mysqld-mm-1.pid
socket = /var/run/mysqld/mysqld-mm-1.sock
port = 3307
basedir = /usr
datadir = /var/lib/mysql-mm-1
tmpdir = /tmp
lc-messages-dir = /usr/share/mysql
skip-external-locking
key_buffer = 16M
max_allowed_packet = 16M
thread_stack = 192K
thread_cache_size = 8
myisam-recover = BACKUP
query_cache_limit = 1M
query_cache_size = 16M
log_error = /var/log/mysql/error-mm-1.log
server-id = 11
log_bin = /var/log/mysql/mm-1-bin.log
expire_logs_days = 10
max_binlog_size = 100M

[mysqldump]
quick
quote-names
max_allowed_packet = 16M

[mysql]

[isamchk]
key_buffer = 16M
e per il nodo 2 qualche cosa come

[client]
port = 3308
socket = /var/run/mysqld/mysqld-mm-2.sock

[mysqld_safe]
socket = /var/run/mysqld/mysqldi-mm-2.sock
nice = 0

[mysqld]
user = mysql
pid-file = /var/run/mysqld/mysqld-mm-2.pid
socket = /var/run/mysqld/mysqld-mm-2.sock
port = 3308
basedir = /usr
datadir = /var/lib/mysql-mm-2
tmpdir = /tmp
lc-messages-dir = /usr/share/mysql
skip-external-locking
bind-address = 127.0.0.1
key_buffer = 16M
max_allowed_packet = 16M
thread_stack = 192K
thread_cache_size = 8
myisam-recover = BACKUP
query_cache_limit = 1M
query_cache_size = 16M
log_error = /var/log/mysql/error-mm-2.log
server-id = 12
log_bin = /var/log/mysql/mm-2-bin.log
expire_logs_days = 10
max_binlog_size = 100M

[mysqldump]
quick
quote-names
max_allowed_packet = 16M

[mysql]
[isamchk]
key_buffer = 16M
da notare in questi file:

port: ho usato porte non standard e diverse per i due nodi
server-id: ho dato due valori diversi ai due nodi
log-bin: ho abilitato i binary log
datadir: specifica per ogni nodo.
Devo ora popolare le directory dei dati:

mysql_install_db –user=mysql –defaults-file=/etc/mysql-mm-1/my.cnf
mysql_install_db –user=mysql –defaults-file=/etc/mysql-mm-2/my.cnf
Posso ora avviare i due database

mysqld_safe –defaults-file=/etc/mysql-mm-1/my.cnf &
mysqld_safe –defaults-file=/etc/mysql-mm-2/my.cnf &
Al primo avvio dovranno essere generati tutta una serie di file ma dopo un po’ i due database dovrebbero essere accessibili:

mysql –port 3307 –host 127.0.0.1 –user=root
mysql –port 3308 –host 127.0.0.1 –user=root
NB: su Ubuntu apparmor impedisce di eseguire questa procedura. Per escluderlo

aa-complain /usr/sbin/mysqld
Trattandosi di due istanze appena create non ci dobbiamo preoccupare allineare la situazione iniziale dei due nodi mysql imprtando dei backup.

Procediamo quindi a configurare il nodo mysql due come replica del nodo mysql uno.

Per prima cosa dobbiamo vedere lo stato come master del nodo uno:

mysql –port 3307 –host 127.0.0.1 –user=root
show master status\G
otterremo qualche cosa come

*************************** 1. row ***************************
File: mm-1-bin.000005
Position: 107
Binlog_Do_DB:
Binlog_Ignore_DB:
1 row in set (0.00 sec)
Nel caso avessimo ripristinato da un backup avremmo dovuto far riferimento a informazioni analoghe ma prese al momento del backup.
Abilitiamo ora la prima replica

mysql –port 3307 –host 127.0.0.1 –user=root
change master to MASTER_HOST=’127.0.0.1′, MASTER_PORT=3307 , MASTER_USER=’root’ , MASTER_LOG_FILE = ‘mm-1-bin.000005′, MASTER_LOG_POS =107;
show slave status\G
Ho qui utilizzato l’utente root. In condizioni non di test bisognerebbe utilizzare un utente con gli appositi permessi (REPLICATION_CLIENT, REPLICATION_SLAVE).
Lo stesso per l’altro nodo

mysql –port 3308 –host 127.0.0.1 –user=root
change master to MASTER_HOST=’127.0.0.1′, MASTER_PORT=3308 , MASTER_USER=’root’ , MASTER_LOG_FILE = ‘mm-2-bin.000005’, MASTER_LOG_POS =107;
show slave status\G

Approfondisci

Come Cambiare Sender in Gmail

La posta di gmail offre uno strumento poco noto ma molto utile. Risulta essere possibile inviare posta con un sender differente dall’account con cui si è fatto login.

Questa feature di gmail può tornare utile in almeno due casi
se si hanno diverse caselle di posta sfruttando il cambio di sender e la possibilità di scaricare posta da altre caselle, per concentrare la gestione della propria posta in un unico punto.
se si gestisce un dominio con centinaia di caselle su cui con ogni probabilità verranno richieste caselle non personali di cui è fin troppo facile perdere traccia, da la possibilità di limitare gli utenti alle caselle personali e usare i gruppi per tutte le caselle funzionali come le varie webmaster, postmaster etc.. Il vantaggio è doppio: igruppi non si pagano e l’amministratore può ricostruire facilmente da chi vengono letti.

Per sfruttare questa feature bisogna
Fare login sulla webmail
entrare nei settings del proprio account
Selezionare il tab Accounts
selezionare “Add another address you own”
Sulla finestra di pop-up inserire il nome che si vuole mostrare accanto all’indirizzo nell’header From:”
Sulla finestra di pop-up inserire l’email che si vuole nel campo From
Sulla finestra di pop-up togliere il check “Treat as an alias box”
Selezionare Next Step
Si riceverà sull’altro account (o gruppo) un’email con un link di autorizzazione
Confermare selezionando il link nell’email
Tornare alla finestra di pop-up e concludere la procedura.

Da questo momento è possibile mandare la posta con un altro Sender.

Approfondisci

Come Gestire i Log su Linux con Syslog

Una necessità primaria dei sistemi di produzione è la raccolta e la gestione dei log.

Sempre di più i log vengono generati in enorme quantità e quando l’infrastruttura cresce oltre un certo livello diventa fondamentale passare ad un sistema che ne gestisca la centralizzazione.

Su Linux generalmente si usa una qualche versione del demone syslog (su ubuntu ad esempio ci sono tre opzioni dsyslog, rsyslog, syslog-ng) a questo scopo. Questi sistemi si occupano sia della gestione locale dei log sia della loro eventuale centralizzazione e mettono a disposizione strumenti per filtrare le informazioni più importanti o per integrarsi con sistemi di monitoraggio come nagios o con sistemi di reportistica come logstash. La scelta di un file come repository finale dei dati non è obbligata ma questi sistemi permettono di passare i dati a molti altri tipi di repository.

Farò riferimento per i dettagli a syslog-ng.

Conviene immaginare questi sistemi come a gestori di flussi di informazioni nei quali ci sono dei punti di entrata (un server apache ad esempio), delle regole di elaborazione più o meno complesse e dei punti di uscita (tipicamente un file, altri server syslog nei sistemi centralizzati, database etc..). La configurazione rispecchia questa prospettiva.

Una volta definiti delle opzioni generali si definisco le sorgenti dei log. Questa ad esempio raccoglie le informazioni che tipicamente finiscono sui log standard di sistema.

source s_src { unix-dgram(“/dev/log”); internal();
file(“/proc/kmsg” program_override(“kernel”));
};
Altre tipiche sorgenti di dati saranno delle porte in ascolto su protocolli udp o tcp

source s_udp_apache {
udp(ip(0.0.0.0) port(8515));
};
source s_tcp_apache {
tcp(ip(0.0.0.0) port(8515));
};
utili sia per la costruzione di sistemi gerarchici che permettano la centralizzazione dei log sia come sistema semplice per separare su molti canali i log.
Tra le possibili sorgenti ci sono anche i file

source s_apache_access {file(“/var/log/apache2/access.log” log_fetch_limit(100) log_iw_size(1000)); };
utili ad esempio per raccogliere i log anche di sistemi che hanno solo questa.

Il secondo elemento chiave della configurazione sono le destinazioni dei flussi di log. Anche in questo caso è possibile inviare i log su di un file locale, su un canale tcp o udp nel caso di sistemi gerarchici per la gestione di log.

destination d_auth { file(“/var/log/auth.log”); };
destination d_udp_system { udp(vip-syslog.de.prod port(8514));};
destination d_tcp_system { tcp(vip-syslog.de.prod port(8514));};
Ci sono molte possibili altre destinazioni tra cui stream unix, o mongodb.

Il terzo elemento della configurazione è filter. Come il nome lascia intuire questo elemento serve a definire delle regole per selezionare un sottoinsieme dellerighe in arrivo. L’elemento tradizionale per suddividere i log è la selezione della facility, ma filter permette di agire su svariati elementi tra cui l’host di invio, il livello del messggio (notice, warn, error…) appositi tag assegnati alla riga di log o anche regular expression sul contenuto.

filter f_err { level(err); };
filter f_mail { facility(mail) and not filter(f_debug); };
I vari elementi della configurazione devono essere poi combinati con un’ultimo elemento della configurazione:

log { source(s_src); filter(f_auth); destination(d_auth); };
log { source(s_apache_extranet); destination(d_apache_extranet); flags(flow_control); };
La combinazione di questi elementi permette una grande flessibilità nella gestione del log. Tornerò su questo tema per approfondirne il filtraggio ed altre opzioni.

Approfondisci