Io speriamo che me la cavo

Ciao,

questo post è  così !

 

Joyent’s Triton at Barton’s Blog

Intro: Setting up Joyent’s Triton in Dell’s CTO lab; post 1

The platform supporting Joyent’s Triton in Dell’s CTO lab – post 2

Installation details for Joyent’s Triton in Dell’s CTO lab; post3

SmartOS Project-FiFo and metrics

just to enjoy

smartOS_FiFO_metrics

 

who help me 😉

Creating a KVM clone with SmarOS

Tratto da  [smartos-discuss]: Cloning woes

Q:
I would like to create a KVM VM clone,   I rather go the quick and
dirty way and not deal with datasets, I followed the wiki however is
outdated those instructions aren’t working.https://wiki.smartos.org/display/DOC/Managing+Datasets
Has the process of creating a KVM clone changed?
zfs snapshot disk
zfs clone
vmadm createAny clues? Maybe an step by step?Thx.
A:

I have not tried it myself but…

vmadm create (source kvm)
… install OS in KVM …
vmadm stop (source kvm)
vmadm create (new kvm)
zfs destroy zones/{new kvm}-disk0
zfs snapshot zones/{source kvm}-diks0@base
zfs clone zones/{source kvm}-disk0@base zones/{new kvm}-disk0
vmadm start (new kvm)

Is how I would do it.

Jorge Schrauwen
ps.
Ho provato e funziona :)

Zeroshell on SmartOS

hello world  !!

Zeroshell as KVM  guest on SmartOS

 

ZeroshellOnSmartOS

my json file to build the vm

kvm.json
{
 "brand": "kvm",
 "vcpus": 1,
 "autoboot": false,
 "ram": 1024,
 "alias": "zeroshell-3.4.0",
 "resolvers": [
 "8.8.4.4",
 "8.8.8.8"
 ],
 "disks": [
  {
  "boot": true,
  "model": "ide",
  "size": 5120
  }
   ],
  "nics": [
  {
  "nic_tag": "switch1",
  "model": "e1000",
  "ip": "10.0.0.75",
  "netmask": "255.255.255.0",
  "gateway": "10.0.0.1",
  "primary": 1,
  "allow_ip_spoofing": "1"
  },
  {
  "nic_tag": "switch2",
  "model": "e1000",
  "ip": "192.168.20.1",
  "netmask": "255.255.255.0",
  "allow_ip_spoofing": "1"
  }
 ]
}

we test the json file with

$ vmadm validate create -f kvm.json

and then

$ vmadm create -f kvm.json

vmadm boot 9a581ac1-a508-4ad1-b564-49262e15a54e order=d cdrom=/Zeroshell-3.4.0.iso,ide

but before to run that, I have already get the iso image in right place /zones/9a581ac1-a508-4ad1-b564-49262e15a54e/root

$ ls /zones/9a581ac1-a508-4ad1-b564-49262e15a54e/root/
dev                  lib                  smartdc              tmp                  var
etc                  sbin                 startvm              usr                  ZeroShell-3.4.0.iso
$ vmadm list

UUID                                  TYPE  RAM      QUOTA  CPU_SHARE  IO_PRIORITY  NICS.0.IP             NICS.1.IP             ALIAS       STATE
9a581ac1-a508-4ad1-b564-49262e15a54e  KVM   512      10     100        100          10.0.0.75          192.168.20.1                     zeroshell-3.4.0  running
$ dladm show-vnic | grep 9a58 
net0         switch1    0     12:ea:9a:82:ff:db fixed       0    9a581ac1-a508-4ad1-b564-49262e15a54e
net1         switch2    0     b2:3e:bb:1f:42:83 fixed       0    9a581ac1-a508-4ad1-b564-49262e15a54e

so two “etherstub” frontend and backend :-)

Now we try to connect to web gui, at this point there is a little trick … In Zeroshell you have to declare who is enabled to connect, and can be done from “HTTPS Web Interface Settings”. By default just subnet 10.0.0./8, 172.16.0.0./12 and 192.168.0.0./16 are enabled to connect. In my case I’m connecting from internet, this is my topology

INTERNET ——HN—–VM_PROXY—–VM1,VM2,ZS1,ZS2

So connection to ZS are coming from public ip and vm_proxy send request to ours vm, in this case I can’t connect to web gui of Zeroshell; but we have also a vnc console

$ vmadm info 9a581ac1-a508-4ad1-b564-49262e15a54e | json vnc
{
  "host": "IP PUBLIC",
  "port": 57213,
  "display": 51313
}

Note: at moment no vnc password is request, but man of vmadm tell us:

vnc_password:

This property allows you to set a password which will be required when
connecting to the VNC port. IMPORTANT: this password will be visible
from the GZ of the CN and anyone with access to the serial port in the
guest. Set to an empty string (default) to not require a password at
this level.

type: string (8 chars max)
vmtype: KVM
listable: no
create: yes
update: yes
default:

Now we have access to zeroshell console user=admin password=zeroshell (just with default profile), and the trick is:

  #iptables -F

:-) and then you can open the web gui and complete the configuration: create profile, activate profile – but again you have to flush iptables; last time – and add ETH00 or your static public ip from you connect in “HTTPS Web Interface Settings”

HTTPSWEBINTEFACESETTINGS

logadm (parte I)

Ciao.

ho tradotto per me il fantastico Less-known-Solaris-features-logadm di  Joerg Moellenkamp
per poter routare i logfiles  presenti in una fantastica SmartOS che tra le altre cose è in produzione :)

p.s.
Gli eventuali errori sono i miei :-)  l’idea di questo post è nel logadm (parte 0).
p.p.s.
Ora finalmente vado a mangiare la pasta al forno di Maria con i fagliolini paesani.

 

Less known Solaris features – logadm

TUESDAY, MARCH 2. 2010

Ordine nella tua directory dei log

Uno dei compiti regolari di un qualunque amministratore “decente” dovrebbe
essere ordinare la directory dei log. I logfiles sono veramente utili,
quando qualcosa va storto, ma spesso questi riempiono le direcories con i
dati. Sebbene a volte sia utile avere logfiles molto vecchi
la maggior parte delle volte tu desideri solo accedere direttamente quelli recenti

logadm

Uno dei maggiori enigmi con solaris è che poca gente conosce lo strumento “logadm”. Questo è diponibile con Solaris dalla versione Solaris 9.
Comunque è ancora uno dei segreti ben mantenuti di Solaris nonostatnte il fatto che lo strumento sia ben documentato e già utilizzato in Solaris.
Io spesso mi meraviglio cosa gli utenti Solaris pensano, dove questo .0-file é stato creati.

Capacità

Per tutti i compiti usuali che circondano la manipolazione dei log file tu puoi usare il comando logadm. Questo è uno strumento capace di:

* ruotare i log (mediante copia/troncamento o spostamento)
* configurare delle regole, quando una rotazione di un log deve aver luogo. Queste regole possono esser basate su …
* la dimensione del file di log
* il timpo dell’ultima rotazione del log
* eseguire comandi prima e dopo una rotazione del logfile
* comprimere i files di log ruotati basandosi su regole
* specificare i tuoi comandi per copiare/muovere i files
* specificare i comandi che devono esser usati al posto di una semplice
* cancallazione per la scadenza dei files.

Come funziona

logadm è lo strumento per configurare così come per eseguire la rotazione dei
log, Per ruoatte automaticamente ruotare i log, logadm
è eseguito mediante il cron una volta al giorno. Osserviamo il crontab dell'utente root
 
jmoekamp@hivemind:/var/squid/logs# crontab -l
[... CDDL Header omitted ...]
#
10 3 * * * /usr/sbin/logadm
15 3 * * 0 [ -x /usr/lib/fs/nfs/nfsfind ] && /usr/lib/fs/nfs/nfsfind
30 3 * * * [ -x /usr/lib/gss/gsscred_clean ] && /usr/lib/gss/gsscred_clean
30 0,9,12,18,21 * * * /usr/lib/update-manager/update-refresh.sh

Così come puoi aver già riconosciuto, lo script logadm è eseguito giornalmente alle 3:10 am nella configurazione standard di Solaris.

MA come la rotazione stessa è fatta? Bene, esattamente come tu dovresti fare digitando il comandi nella shell. logadm fà lo
stesso lavoro – ma automaticamente. Genera una sequenza di comandi per ruotare i log e li invia ad una C shell per l’esecuzione.

Il lato pratico di logadm

Configuriamolo

Sebbene sia possibile invocare la rotazione completamente dalla linea di comando ogni volta, questo non è un metodo agevole per
ruotare i log. In quasi tutti i casi tu dovrari configurare il servizio logadm al fine di ottenere la rotazione automaticamente.
Ma come questo è fatto ?

logadm.conf

L’esecuzione giornaliera di logadm dipende da un file di configurazione. Quando tu non specifichi un file di configurazione, questo
è il predefinito /etc/logadm.conf. La configurazione è abbastanza corta e normalmente ruota i soliti sospetti. Il seguente file è
leggermente più esteso, come la configurazione preconfigurata non usa tulle le azioni importanti

jmoekamp@hivemind:~$ cat /etc/logadm.conf
 [... CDDL Header omitted ...]
 /var/log/syslog -C 8 -P 'Sat Feb 20 02:10:00 2010' -a 'kill -HUP `cat /var/run/syslog.pid`'
 /var/adm/messages -C 4 -P 'Sat Feb 20 02:10:00 2010' -a 'kill -HUP `cat /var/run/syslog.pid`'
 /var/cron/log -P 'Thu Dec 17 02:10:00 2009' -c -s 512k -t /var/cron/olog
 /var/lp/logs/lpsched -C 2 -N -t '$file.$N'
 /var/fm/fmd/errlog -M '/usr/sbin/fmadm -q rotate errlog && mv /var/fm/fmd/errlog.0- $nfile' -N -s 2m
 /var/fm/fmd/fltlog -A 6m -M '/usr/sbin/fmadm -q rotate fltlog && mv /var/fm/fmd/fltlog.0- $nfile' -N -s 10m
 smf_logs -C 8 -s 1m /var/svc/log/*.log
 /var/adm/pacct -C 0 -N -a '/usr/lib/acct/accton pacct' -g adm -m 664 -o adm -p never
 /var/log/pool/poold -N -a 'pkill -HUP poold; true' -s 512k
 /var/squid/logs/access.log -P 'Tue Feb 23 06:26:23 2010' -C 8 -c -p 1d -t '/var/squid/logs/access.log.$n' -z 1

Puoi editare questo file direttamente, ma è preferibile cambiarlo con il comdado logadm stesso. Commetiamo alcume linee di
questa configurazione

Rotazione standard del log – introduzione di -C, -P e -a

[...]
 /var/log/syslog -C 8 -P 'Sat Feb 20 02:10:00 2010' -a 'kill -HUP `cat /var/run/syslog.pid`'
 [...]

Questa riga è responsabile della rotazione di /var/log/syslog. L’opzione -C 8 specifica che logadm deve mantenre 8 vecchie
versioni prima che spirino ( leggi: cancelli) i vecchi logfiles. Con l’opzione -a ‘kill -HUP `cat /var/run/syslog.pid`’
il syslog riceve il segnale di HUP dopo la rotazione. Il syslogd necessuta di ricreare il file e il riavvio del logging.

L’opzione -P non è nella versione originale (pristine) del file. Quelle opzioni verranno inserite quando esegui il comando logadm. Con
questa opzione, indica a logadm quando è stata l’ultima rotazione. logadm la inserisce ogni qualvota ruota il logfile. Questo è
importante da sapere, che questo tempo è GMT, così non meravigliarti dello scarto con il tempo locale mostrato dai logfiles.

In questo istruzione non trovi una configurazione del tempo o della dimensione che porta alla rotazione dei log. In questo caso i
valori predefiniti “1 byte e una settimana” sono per cominciare. Così /var/log/syslog è ruotato quando l’utima rotazione è stata una
settimana nel passato e il file è almeno un Byte di dimensione.

Esplicita definizione di un intervallo di tempo di rotazione – introduzione di -p

Con -p tu puoi controllare il periodo tra le rotazioni dei log. Per esempio 1d specifica che tu ruoti i file di log con una schedulazione
giornaliera

[...]
 /var/squid/logs/access.log -C 8 -c -p 1d -t '/var/squid/logs/access.log.$n' 
 [...]

Così questo logfile è ruotato ogni giorno da logadm inizializzato mediante una riga nel crontab

Un template per i nomi dei log ruotati – introduzione di -t

-t specifica il modo, come i nomi per i logfiles sono creati da logadm. Il template per
il nuovo nome non è solo una stringa fissa, tu puoi usare diverse variabili per controllare il nome del file

[...]
 /var/squid/logs/access.log -C 8 -c -p 1d -t '/var/squid/logs/access.log.$n'
 [...]

Questo è un esempio relativamnete semplice .$n è la versione numerica del file, partendo da 0.
Così la configurazione porterà ad un nome file come questo:

-rw-r----- 1 webservd webservd 652486 2010-02-22 16:36 /var/squid/logs/access.log.0

$n è solo uno delle possibile variabili da usare nel template. La pagina di man logadm specifica ulteriori variabili.

Esplicita definizione della massima dimensione del logfile – introduzione di -s
A volte tu vuoi impostare al tuo logfile un limite basato sulla dimensione del del file e non basato sull’inter
vallo temporale. L’opzione -s permette di farlo:

[...]
 /var/cron/log -P 'Thu Dec 17 02:10:00 2009' -c -s 512k -t /var/cron/olog
[...]

Con questa opzione logadm ruoterà il logfile appena è 512k o più grande nell’istante dell’esecuzione
di logadm.

Specificare entrambi: Spazio e tempo

Quando tu specifichi una dimensione massima per il logfile (-s) così come il massimo periodo per il logfile (-p),
entrambe le condizioni sono connesse con un AND. Così la condizione predefinita ‘1 byte e 1 settimana’ posso essere così
tradotte: Ruota quando il logfile ha una dimensione di almeno 1 byte AND vecchio di una settimana, così un logfile vecchio di una settimana
ma di dimensione zero non è ruotato dalla configurazione predefinita.

Copia e troncamneto al posto di muovere – introduzione di -c

Ruotare logfiles non è semza problemi. Alcune applicazioni non gradiscono se tu semplicemente muovi il file lontano. Loro possono
usare il file ruotato invece di uno nuovo, o semplicemnete semplicemente non creano un nuovo logfile. Così tu devi riavviare il servizio
o inviare un segnale. C’è una alternativa. E’ chiamato troncare/troncaggio

[…]
/var/cron/log -P ‘Thu Dec 17 02:10:00 2009’ -c -s 512k -t /var/cron/olog
[…]

L’opzione -c forza logadm ad usare cp al posto di mv per ruotare il log. Per ottenere un nuovo inizio
nel nuovo log /dev/null e copiato nel logfile corrente per rendere il file di 0 byte. Questo aggira la necessità
del riavvio dell’applicazione per riavviare il logging.

Compressione dopo la rotazione – intriduzione di -z

A causa della loro struttura, i file di log possono ottenere un eccellente rapporto di compressione. Così è ragionevole
comprimerli dopo la rotazone. Tu lo puoi configurare con la sessione -z. Comunque spesso è in qualche misura impraticable lavorare
con i file compressi, il parametro dopo -z forza logadm a non comprimere un dato numero dei più recenti file di log. Facendo questo
tu hai i logfiles recenti disponibili senza decomprimerli, senza sacrificare spazio lasciando tutti i file non compressi.

[...]
 /var/squid/logs/cache.log -C 8 -c -p 1d -t '/var/squid/logs/access.log.$n' -z 1
 [...]

-z 1 configura logadm a lasciare il più recente logfile invariato e comprimere
il successiovo.. Questo risulta dai seguenti file:

jmoekamp@hivemind:/var/squid/logs$ ls -l /var/squid/logs/access*
 -rw-r----- 1 webservd webservd 0 2010-02-23 07:26 /var/squid/logs/access.log
 -rw-r----- 1 webservd webservd 652486 2010-02-22 16:36 /var/squid/logs/access.log.0
 -rw-r----- 1 webservd webservd 39411 2010-02-22 09:22 /var/squid/logs/access.log.1.gz

Una rotazione dei log che non deve essere mai eseguita automaticamente – introduzione di -p never

In un primo momento, questa riga sembra veramente strana:

[...] 
 /var/adm/pacct -C 0 -N -a '/usr/lib/acct/accton pacct' -g adm -m 664 -o adm -p never
 [...]

Qual’è il senso di una riga di configurazione che mai verrà usata
automaticamente in uno script di rotazione dei log . Bene, il fatto che tu non la userai autoaticamente,
non significa che che non puoi usarla manualmente dalla linea di comando o che altri scripts non possano
eseguire le funzionalità di logadm per la rotazione dei log al posto di implementarli per loro conto. La configurazione mostrata in
precedenza è tale da abilitarne l’uso di logadm per la rotazione dei log in
altri scripts. Quando tu osservi nello script /usr/lib/acct/turnacct,
tu vedrai una linea che esegue logadm con -p now:

[...]
switch)
 pfexec /usr/sbin/logadm -p now /var/adm/pacct
 if test ! -r pacct
 [...]

Lo script turnacct esegue la rotazione dei log. A seguito del -p never nel logadm è il solo modo per eseguire la rotazione.
Io spiegherò succesivamente cosa accade a seguito di questo comando.

Wildcards

Le pagina di man di logadm danno un ottimo esempio dell'uso di wildcard e delle "espressioni regolari":
 logadm -w apache -p 1m -C 24\
 -t '/var/apache/old-logs/$basename.%Y-%m'\
 -a '/usr/apache/bin/apachectl graceful'\
 '/var/apache/logs/*{access,error}_log'

Con queste impostazioni tu ruoterai tutti i file di log che terminano con access_log o error_log nella tua directory di log di apache.
All’inizio delle linea tu puoi aver riconosciuto il nome apache. Questo è una
abbreviazione per questa configuarzione. Così tu puoi sempiceente ruotare tutti i logfiles con logadm -p now apache al posto del lungo nome della directory.
In aggiunta è importante che il comando specificato mediante -a è eseguito una volta dopo tutte le occorrenze del loglifes e non per ciascuna
di queste.

Più opzioni

Ci sono molte altre opzioni per controllare il comportamento di una rotazione. I descriverò queste opzioni con con dei brevi esempi:

* -A 1y:
Con -A è un un modo aggiuntivo per controllare la scadenza dei file ruotati. Per esempio, questo esempio forza logadm
a far scadere i file di log ruotati quando questi sono più vecchi di un anno.
* -S 100m :
Forse non vorrai specificare un limite di scadenza per età, ma mediante la dimensione presa da tutti i file ruotati. Tu lo puoi fare usando
l’ozione -S. In questo esmpio i logfiles ruotati scadranno quando occuperanno più che 100 Megabyte.
* -E ‘mv $nfile /longtermstorage’:
Questa opzione controlla cosa accade quando un logfiles scade. Il comportamento standard è la semplice cancellazione.
In questo esempio si muove il file scaduto in uno storage a lunga scadenza, per esempio un filesystem SamFS montato via NFS su un diverso server
* -b ‘svcadm disable nonbehavingapp’ -a ‘svcadm enable nonbehavingapp’:
Non c’è non solo una opzione per eseguire un comando dopo la rotazione dei file con -a, c’è ne una per l’esecuzione di comandi prima della
rotazione. Tu puoi usare -b per specificare questo compito. Questo è molto
utile per fermare e avviare una applicazione che si comporta male nella rotazione dei file
* -R ‘loganalyser.pl $file’:
il comando specificato con questa opzione (-R) è eseguito dopo ciascuna
rotazione. A prima vista questo sembra ridondante ad -a ma c’è una importante
differenza. -a è eseguita una volta, perfino quando nella riga di logadm.conf coincide con più logfiles. Il comando -R è eseguito per ogni
logfiles. Cosi -a è più per l’invio di un segnale al processo, che deve far partire un nuovo log, -R è più utile per l’elaboazione dei log.
Quando usi -R per la segnalazione, il processo otterrà un segnale per ciascun logfile ruotato.
-M ‘mv $file $nfile:
Con -M tu puoi specificare il tuo personale comando per la rotazione. In questo esempio è la condizione normale per una esecuzione di logadm.

Opzioni di controllo

Sino ad ora abbiamo citato le opzioni necessarie per la configurazione. Ma ci sono più opzioni aggiuntive per cosa comtrollare

Cambiare logadm.conf con logadm

Okay, come mettere i comandi nel file logadm.conf. Tu puoi editare direttamnete il file, questo funziona. Ma logadm può essere usato per aggiungere
o cancellare istruzioni al file di configurazione. Quando tu aggiungi una linea al file logadm.conf esegui logadm seguito da -w

jmoekamp@hivemind:/var/squid/logs# logadm -w /var/squid/logs/cache.log -C 8 -c -p 1d -t '/var/squid/logs/cache.log.$n' -z 1

Tu puoi controllare l’aggiunta con il comando logadm -V. -V esegue la validazione del file. Così è opportuno(sensible) eseguire
questo comando dopo una aggiunta diretta al file.

jmoekamp@hivemind:/var/squid/logs# logadm -V
 [...]
 /var/squid/logs/cache.log -C 8 -c -p 1d -t '/var/squid/logs/cache.log.$n' -z 1
 [...]

Okay, noi abbiamo lavorato per un po con questo file di configurazioe della
rotazione. Avrai notato che le linee di configurazione sono cambiate

jmoekamp@hivemind:/var/squid/logs# logadm -V
 /var/log/syslog -C 8 -P 'Sat Feb 20 02:10:00 2010' -a 'kill -HUP `cat /var/run/syslog.pid`'
 [...]
 /var/squid/logs/access.log -P 'Tue Feb 23 19:19:27 2010' -C 8 -c -p 1d -t '/var/squid/logs/access.log.$n' -z 1
 /var/squid/logs/cache.log -C 8 -P 'Tue Feb 23 19:59:20 2010' -c -p 1d -t '/var/squid/logs/cache.log.$n' -z 1

Ora tu vui eliminare questa configurazione. Queta è fatto con -r in congiunzione con il nome del logfile.

 jmoekamp@hivemind:/var/squid/logs# logadm -r /var/squid/logs/cache.log
 jmoekamp@hivemind:/var/squid/logs# logadm -V
 /var/log/syslog -C 8 -P 'Sat Feb 20 02:10:00 2010' -a 'kill -HUP `cat /var/run/syslog.pid`'
 [...]
 /var/squid/logs/access.log -P 'Tue Feb 23 19:19:27 2010' -C 8 -c -p 1d -t '/var/squid/logs/access.log.$n' -z 1
 jmoekamp@hivemind:/var/squid/logs#

é andato…. il /var/squid/logs/cache.log non verrà ruotato nel prossimo logadm eseguito mediante crontab o at a riga
di comando.

Forzare una rotazione immediata.

Qualche volta vuoi eseguire una rotazione immediata. Per esempio perchè vuoi riavviare un servizio con un nuovo log
da esaminare facilmente. -p now esegue la rotazione proprio nel momento in cui esegui logadm

jmoekamp@hivemind:/var/squid/logs# date
 Dienstag, 23. Februar 2010, 20:48:25 Uhr CET
 jmoekamp@hivemind:/var/squid/logs# logadm -p now squid_cachelog
 jmoekamp@hivemind:/var/squid/logs# ls -l cache.log*
 -rw-r----- 1 webservd webservd 0 2010-02-23 20:48 cache.log
 -rw-r----- 1 webservd webservd 636799 2010-02-23 20:41 cache.log.0
 jmoekamp@hivemind:/var/squid/logs#
 
Con -p now puoi perfino eseguire una rotazione dei log che mai sarà eseguita automaticamente.

Cosa accade sotto il tappeto?

Come scritto all’inizio, logadm lavora inviando una serie di comandi ad una c-shell. Il logadm ha un modo
interessante di operare. Quando tu usi l’opzione -v lo strumento mostra i comandi che logadm usa per ruotare i logfiles.

 

jmoekamp@hivemind:/var/squid/logs# logadm -p now -v squid_access
 # loading /etc/logadm.conf
 # processing logname: squid_access
 mkdir -p /var/squid/logs # verify directory exists
 cp -fp /var/squid/logs/access.log.2.gz /var/squid/logs/access.log.3.gz # rotate log file via copy (-c flag)
 cp -f /dev/null /var/squid/logs/access.log.2.gz # truncate log file (-c flag)
 mkdir -p /var/squid/logs # verify directory exists
 cp -fp /var/squid/logs/access.log.1.gz /var/squid/logs/access.log.2.gz # rotate log file via copy (-c flag)
 cp -f /dev/null /var/squid/logs/access.log.1.gz # truncate log file (-c flag)
 mkdir -p /var/squid/logs # verify directory exists
 cp -fp /var/squid/logs/access.log.0 /var/squid/logs/access.log.1 # rotate log file via copy (-c flag)
 cp -f /dev/null /var/squid/logs/access.log.0 # truncate log file (-c flag)
 mkdir -p /var/squid/logs # verify directory exists
 cp -fp /var/squid/logs/access.log /var/squid/logs/access.log.0 # rotate log file via copy (-c flag)
 cp -f /dev/null /var/squid/logs/access.log # truncate log file (-c flag)
 touch /var/squid/logs/access.log
 chown 80:80 /var/squid/logs/access.log
 chmod 640 /var/squid/logs/access.log
 # recording rotation date Tue Feb 23 18:15:44 2010 for /var/squid/logs/access.log
 gzip -f /var/squid/logs/access.log.1 # compress old log (-z flag)
 # writing changes to /etc/logadm.conf
  

Come puoi aver riconosciuto molto simile a come tu faresti manualmente.

Suggerimenti e Trucchi

Istanze multiple di logadm

E’ perfettamente possibile avere più che un file di configurazione. Tu puoi scegliere il file di configurazione con -f.
Aggiungendo una riga nel tabella del cron che specifica una differente logadm.conf. Un mio collega usa questa “possibilità”
per avere un file di configurazione indipendente per la rotazione di SamFS, così non deve editare un file differente fornita dalla distribuzione.

Conclusioni.

Sebbene è solamente un piccolo strumento, le possiblità di logadm di aiutarti con i tuoi logfile sono vasti ed infiniti.
Io sono veramente meravigliato del perchè molti non lo conoscono. Io spero di aver cambiato almeno un po’ mediante la scrittura di questo post

Dome imparare di più?
la pagine del man
illumos.org: logadm(1M)
illumos.org: logadm.conf(4)

logadm (parte 0)

Hi folks.

Mi sono imbattuto nella necessità di migrare un fantastico rsyslogd da un server Linux ad una SmartOS

Tutto è andato per il meglio compatibilità 100% poi ho agginto un pizzico di compressione

zfs set compression=lz4  zones/0ddfc1fe-3f33-4439-ac4e-d1547cd85340/data

Poi ruotiamo i log…. bene logrotate …ma su SmartOS ??

Dopo aver chiesto a Google … ecco quello che ho scelto

Joerg Moellenkamp

http://www.c0t0d0s0.org/archives/6394-Less-known-Solaris-features-logadm.html

E poi ecco l’idea

  1. tradurre il fantastico post di   Joerg
  2. tradurre il man di logadm
  3. il man tradotto scriverlo  con groff

 

Sensu mysql check

Hi,

I’m working to setup some check on Percona mysql with Sensuapp – I worked with Nagios XI, to setup check on F.A.O  in Rome, I’m proud about that experience but that is another story  –

My recipe:

  1. yum install Development Tools
  2. yum install Percona-Server-devel-XXXX.el6.x86_64
  3. /opt/sensu/embedded/gem install cli
  4. /opt/sensu/embedded/gem install inifile
  5. /opt/sensu/embedded/gem install mysql

Then on GitHub

https://github.com/sensu-plugins/sensu-plugins-mysql

  • check-mysql-alive.rb
  • check-mysql-connections.rb
  • check-mysql-disk.rb
  • check-mysql-replication-status.rb

That’s all …..just a moment

can I use some kind of variable …. yes

variable definition on JSON of the client . These are mine:

/etc/sensu/conf.d/client.json
{
  "client": {
    "name": "servername.sensu.org",
    "address": "192.168.0.1@CT10074",
    "subscriptions": ["all","mysql"],
    "database": {
     "DiskSize": "200G",
     "SizeWarningThreshold": "85",
     "SizeCriticalThreshold": "95",
     "ReplicationLagWarningThreshold": "900",
     "ReplicationLagCriticalThreshold": "1800",
     "name": "mysqldb"
    },
    "connection": {
     "warnnum": "10",
     "critnum": "22"
    }
  }
}

 

I can use them in this way in JSON definition check :

:::database.name:::

:::database.DiskSize:::

:::connection.warnnum:::

an so on ..

One example

{
   "checks": {
    "mysql-alive": {
    "command": "check-mysql-alive.rb -h localhost --database :::database.name::: --ini '/etc/sensu/my.cnf'",
    "subscribers": [ "mysql-perf"],
    "interval": 300,
    "handlers": ["email_perl"]
   }
  }
}


I proud about this, too !!!

OpenSource and OpenMind

Hi,

spesso mi domando ma perchè mi affascina il “libero pensiero” del free software ?

La risposta è semplice :

C’è un progetto Z-Push-contrib

============

Original Z-Push

URL: http://www.zpush.org

Z-Push is an implementation of the ActiveSync protocol, which is used ‘over-the-air’ for multi platform ActiveSync devices, including Windows Mobile, Ericsson and Nokia phones. With Z-Push any groupware can be connected and synced with these devices.

License: GNU Affero Genaral Public License v3.0 (AGPLv3)

================

poi un ci si imbatte in qualche nuova esigenza #108 , #131 che il software non prevede e allora si chiede a Francisco Miguel Biete  che “scrive”  il codice se questa esigenza può essere  aggiunta.

Il “lavoro” viene  commissionato – Drenalina (www.drenalina.com) has kindly sponsored the implementation of those missing features. So it’s testing time for “meetings”- e regolato ed infine ecco comparire nuovamente il free software alla comunità.

fmbiente_drenalina

fmbiente_drenalina

Oltre al codice ci sono due persone che ci credono si  rispettano e cosa più importante rispettano  il lavoro di entrambi.

 

Che dire,  grazie Richard  Stallman  e tutte le persone che  hanno creato, alimentato e alimentano il free software

OpenVpn – load balancing e fault tolerance

Di recente ci siamo trovati a cercare una soluzione per una struttura reti VPN basate su OpenVPN. I client sono circa 200 in modalità mista (host-to-lan e lan-to-lan). Lo scenario di partenza è costituito da client e server basati su Zeroshell (diverse versioni).

 

La necessità del cliente è quella di aumentare la resistenza della propria infrastruttura e garantire agli utilizzatori finali delle vpn continua connettività verso il canale cifrato. Per raggiungere l’obiettivo abbiamo sfruttato alcune caratteristiche di openvpn e la capacità di utilizzare la macchina linux come router.

 

Il load balancing di OpenVpn

Openvpn implementa un sistema basilare di balancing basato sulla caratteristica del client di provare la connessione verso diversi endpoint fino a trovarne uno disponibile.

Ciò è possibile in due modi:

 

  1. inserendo più direttive remote nel client.conf
  2. indicando come endpoint della direttiva remote nel file client.conf un nome host (e non un indirizzo ip) la cui risoluzione offre diversi record A.

 

Nel primo caso, banalmente, il client tenta la connessione con la stessa configurazione a tutti i server conosciuti. Nel secondo caso invece risolve il nome host e tenta ciclicamente la connessione a tutti i record A ottenuti dal DNS.

 

Nel primo scenario l’ampliamento di macchine server necessità la modifica (e riavvio) di tutti i singoli client. Abbiamo preferito la seconda soluzione perchè si presta a minori interventi di manutenzione in caso di ampliamento del numero di macchine server a disposizione.

 

Faccio presente che comunque il sistema di load balancing basato su DNS è debole poichè il DNS non conosce lo stato dell’endpoint (di fatto non sa se il server openvpn ha un malfunzionamento). Tuttavia per una connessione VPN lo riteniamo accettabile in quanto le operazioni di connessione e disconnessione non sono frequenti. Inoltre un invio da parte del DNS di un ip indisponibile innescherebbe solo un ritardo nell’apertura del canale (comunque già in stato di disservizio).

 

Traffico originato lato server e diretto alla rete del client

A questo punto il grosso è fatto ed è affidato principalmente ad OpenVPN Client (o Zeroshell). Nello scenario affrontato tuttavia si è presentato la peculiarità di avere del traffico generato lato server diretto verso la rete dietro i client. Ciò ha innescato due problemi correlati tra loro:

 

  1. per come funziona il load balancing di openvpn, le macchine destinazione dei client vpn non avevano una rotta definita per le reti dei client;
  2. OpenVPN per sua natura definisce le rotte statiche per le net dei client allo startup del demone e non alla connessione del client.

 

Il primo problema è stato risolto installando un demone di routing dinamico (RipV2) sulla macchina OpenVpn Server in grado di propagare le rotte “dietro i client”. Il secondo problema invece ha richiesto una modifica della configurazione di openvpn e l’utilizzo di scripting.

 

In sostanza avviene che il demone Rip aggiorna le rotte statiche appena esse vengono aggiunte alla macchina. OpenVpn aggiunge le rotte statiche verso le reti dei clienti nel momento in cui parte e legge le direttive route e iroute necessarie ad eseguire il routing. Se openvpn aggiungesse le rotte al momento della connessione ed autenticazione del client il problema si sarebbe risolto solamente con il Rip.

 

Soluzione

Openvpn nelle sue pagine di Man indica la modalità di configurazione del routing verso le reti dei client utilizzando una sintassi di questo tipo:

 

nel file server.conf:

route 192.168.88.0 255.255.255.0

mentre nel ccd\common-name

iroute 192.168.88.0 255.255.255.0

 

La prima di queste due istruzioni implica che allo start del processo server viene eseguita la “route add” della rotta verso il tunnel vpn per raggiungere il client. Ma in uno scenario multi server si avrebbe una ridondanza delle rotte (e senza metrica). Di fatto un client RIP non sarebbe in grado di conoscere la rotta corretta.

 

La soluzione studiata verificata e testata è stata quella di omettere l’istruzione route del file server.conf ed eseguire la route add tramite script alla connessione del client (evento di client-connect). Analogamente eseguendo la “route del” della rotta all’evento di client-disconnect.

 

Questa soluzione permette la propagazione delle rotte via RIP in maniera automatica, quindi (a prescindere dal “server di ingresso” del client nella vpn) un client rip riuscirà ad instradare correttamente il traffico.

 

 

 

Autore: Michele Terlizzi – michele@terlizzi.eu

Data: 7 Maggio 2015

Versione di riferimento: OpenVpn 2.3, Zeroshell 3.3