Back up your Xenserver with Xenbackup-ng, now with Tag and vApp Support!

It's time to release an update to xenbackup-ng script.

I added two new features:

• Tag Support: you can tag your vm and backup them by selecting tags.
• vApp Support: if you are used to group vm in vApps you can select vm to backup by vApp.

You can download xenbackup-ng from github: https://github.com/rbicelli/xenbackup-ng/archive/master.zip

Github project is here: https://github.com/rbicelli/xenbackup-ng

pfSense on XenServer: enable VLAN Support for xn ethernet adapter

I was migrating my PfSense boxes from vmware to xenserver and I was disappointed when trying to create a VLAN the XenServer xn interface wasn't listed as capable.

I lurked in forums in search for a solution and found that in stock BSD the xn interface is reported working fine with VLANs, even the vlanmtu is not reported as capable at driver level.

So my idea is to cheat pfsense and report xn network devices as VLAN capable.

Here's the trick:

Go to Diagnostic -> Edit File
Load file /etc/inc/interfaces.inc

Locate the function is_jumbo_capable ( in pfsense 2.2.6 starts at line 5181) end edit as is:

/****f* interfaces/is_jumbo_capable
 * NAME
 *   is_jumbo_capable - Test if interface is jumbo frame capable.  Useful for determining VLAN capability.
 * INPUTS
 *   $int             - string containing interface name
 * RESULT
 *   boolean          - true or false
 ******/
function is_jumbo_capable($iface) {
$iface = trim($iface);
$capable = pfSense_get_interface_addresses($iface);

if (isset($capable['caps']['vlanmtu']))
return true;

// hack for some lagg modes missing vlanmtu, but work fine w/VLANs
if (substr($iface, 0, 4) == "lagg")
return true;

        // hack for XenServer xn interfaces
if (substr($iface, 0, 2) == "xn")
return true;

return false;
}

Then go to Interfaces->Assign->VLAN and create your VLAN interface on your xn network!

Refers To: Pfsense issue 4103

Convert a Linux ESXi Virtual Machine to Xenserver

Since I had to migrate my hypervisor from vmware ESXi to Citrix Xenserver 6.5, I had to convert my Centos Linux 6.x Virtual Machines.
The main difference in Xenserver is that the Linux kernel is paravirtualized.

Tools for the trade:
- vmware vSphere Client
- Xencenter
- Very little Linux terminal skills :)

STEP 1

Optional: take a snapshot

Drop into vSphere Client and take a snapshot.

It is safe to take a snapshot prior to daamge your work

STEP 2

Uninstall vmware Tools

Connect to virtual machine console and type as root:

# rpm -e --nodeps $( rpm -qa | grep vmware-tools)




STEP 3

Export the Virtual Machine into an OVF Package.

Shutdown your VM then in VSphere Client Select your VM and click on File->Export->Export OVF Template

Export your VM - now you can go take some coffee

STEP 4

Import The VM in Xenserver

Now move to Xencenter, right click on the Pool then select Import...

Time to import your VM - now you can go take another coffee

Follow the instructions on wizard

STEP 5

Configure VM for PV.

Power on your VM and login to console as root.

Remove the stock kernel and install the xen-aware kernel by typing

# yum remove kernel
# yum install kernel-xen


Edit the bootloader, add to "kernel=" line

console=hvc0


Then shutdown your VM.

Now open a console to your Xenserver host and change boot policy from HVM to PV:

xe vm-list name-label=[NAME-OF-YOUR-VM]
uuid ( RO)           : [UUID-OF-YOUR_VM]
     name-label ( RW): SOGo
    power-state ( RO): halted

xe vm-param-set uuid=[UUID-OF-YOUR_VM] HVM-boot-policy="" PV-bootloader=pygrub PV-args="graphical utf-8"

xe vm-disk-list uuid=[UUID-OF-YOUR_VM]
Disk 0 VBD:
uuid ( RO)             : [UUID-OF-VBD]
    vm-name-label ( RO): SOGo
       userdevice ( RW): 0
[...]

xe vbd-param-set uuid=[UUID-OF-VBD] bootable=true

Then Power on your VM and Install XenTools.

Source: CTX121875

Get Host Power On working with Dell iDrac in Citrix XenServer 6.5

After a couple days messing around in searching how to get my XenServer 6.5 Hosts powered on by iDRAC, here's my little howto:

1. Download and install Dell OpenManage Server Administrator Managed Node for XenServer6.5 , v8.1.1:
   From XenServer host console:
   
   cd /tmp
wget http://downloads.dell.com/FOLDER02994001M/1/OM-SrvAdmin-Dell-Web-LX-8.1.1-1583.XenServer65_A00.iso
mount -o loop /tmp/OM-SrvAdmin-Dell-Web-LX-8.1.1-1583.XenServer65_A00.iso /mnt
cd /mnt
./install.sh
cd ..
umount /mnt

2. From iDrac web interface, create a user named xenserver (or whatever), with a password not containing complex chars. The user must be created with Administrator privileges.
   
3. In XenCenter go to Host->Properties->Power On, select Remote Access Controller (DRAC) , enter the ip address of the iDrac and credential of iDrac user created.
   
4. Ta-Daaah! Host Power On is enabled!

Totaleapatia.it, e leviamo un po' di ruggine

Ho da poco terminato il restyling del sito dei  miei amici Totale Apatia.

Realizzato in PHP su Framework Codeigniter 3.

Per la gestione del foglio di stile CSS mi sono imbattuto per la prima volta in SASS, un preprocessore per CSS: lo trovo molto versatile e potente e credo che lo userò presto nei miei progetti.

Non avendo a disposizione nessun database e dovendo effettuare pochi aggiornamenti ho optato per gestire tutti i dati variabili con dei file csv.

Un ringraziamento va a Themezy per il template.

SCST iSCSI OCF Update Released

I've just released an update for my iSCSI SCST OCF Resource Agents.

This release improves reliability during migration under high IO pressure and solves problem of unmanaged/failed LUN resources issuing crm node standby/online commands.

Download is available from my Github account ...

BTIER Resource Agent for Pacemaker

Since BTIER became stable for production environment I wanted it in my clustered SAN, so I wrote an OCF compliant resource agent for managing a BTIER device.

For now is very simple, In future I'm planning to add some other features.

CIB Notation looks like:

primitive BTIER_TIER1 ocf:brick:btier \
params tier_devices="/dev/sda:/dev/sdb" \
device_name="mybtierdev01"
op monitor interval="10s"


I would say thanks to Mark for giving us such a piece of software.
I'm using it in production (with LVM over tiered device) and it works fine.

Download it from my Dropbox and place in /usr/lib/ocf/resource.d/brick (or whatever) directory.

SCST ocf Resource Agent Updated: SRPT (Infiniband) support

It's time to update the SCST Pacemaker Resource Agents!

This release introduces some new features.

Infiniband support is added. Now is possible to add infiniband target and map LUNs to it. It is also possible to have, in the same resource a LUN mapped both to iSCSI and to Infiniband. ESXi is reported to behave fine with this setup.

Tests are welcome and appreciated.

Resource Agents can be downloaded from my Dropbox: https://dl.dropbox.com/u/3102209/Projects/SCST-ocf/SCST-ocf-1.2.tar.gz


Below is part of README file:


EXAMPLE OF USAGE

Assumptions:
- you are using DRBD as backing device (/dev/drbd1)
- your target iqn is iqn.2012-02.com.mysuperhasan:vdisk.lun
- your nic reserved for iscsi is eth2 and your iscsi subnet is 192.168.103.x

This is what your resource configuration in cib notation will look like:


primitive DRBD_VOLUME ocf:linbit:drbd \
    params drbd_resource="DRBDRESOURCE" \
    op monitor interval="29" role="Master" \
    op monitor interval="31" role="Slave"
primitive ISCSI_IP ocf:heartbeat:IPaddr2 \
    params ip="192.168.103.20" cidr_netmask="24" nic="eth2" \
    op monitor interval="10s"
primitive ISCSI_LUN ocf:scst:SCSTLun \
    params iscsi_enable="1" target_iqn="iqn.2012-02.com.mysuperhasan:vdisk.lun" iscsi_lun="0" \
    path="/dev/drbd1" handler="vdisk_fileio" device_name="VDISK-LUN10" \        
    additional_parameters="nv_cache=1" \
    op monitor interval="10s" timeout="120s"
primitive ISCSI_TGT ocf:scst:SCSTTarget \
    params iscsi_enable="1" iqn="iqn.2012-02.com.mysuperhasan:vdisk.lun" \
    portals="192.168.103.20" \
    op monitor interval="10s" timeout="120s"
group GR_ISCSI ISCSI_TGT ISCSI_LUN ISCSI_IP
ms MS_DRBD_VOLUME DRBD_VOLUME \
    meta master-max="1" master-node-max="1" clone-max="2" \
    clone-node-max="1" notify="true"
colocation CO_ISCSI_ON_DRBD_VOLUME inf: GR_ISCSI MS_DRBD_VOLUME:Master
order OR_DRBD_BEFORE_ISCSI inf: MS_DRBD_VOLUME:promote GR_ISCSI:start


INFINIBAND:
For now infiniband support is using one target per HCA model, with SCST auto-created target names.
Soon it will be ported in one target per per mode, with target names represented by HCA port GUID

The CIB for infiniband looks like this:

primitive ISCSI_LUN ocf:scst:SCSTLun \
    params target_iqn="iqn.2012-02.com.mysuperhasan:vdisk.lun" lun="0" \
    path="/dev/drbd1" handler="vdisk_fileio" device_name="VDISK-LUN10" \        
    srpt_enable=1 additional_parameters="nv_cache=1" \
    op monitor interval="10s" timeout="120s"
primitive ISCSI_TGT ocf:scst:SCSTTarget \
    params iqn="iqn.2012-02.com.mysuperhasan:vdisk.lun" \
    portals="192.168.103.20" \
    srpt_enable=1 \
    op monitor interval="10s" timeout="120s"

Autenticazione Multi-Tenant Active Directory con Dovecot

Nota: questo articolo è un'estensione di Mailbox Virtuali con Dovecot, Postfix e Active Directory

Se volessimo fare in modo che il nostro server di posta autentichi su diversi domini AD è necessario apportare qualche piccola modifica alla configurazione di Dovecot.
Prendiamo come esempio questa struttura:

Il dominio BRICK.LOCAL ha una relazione di Trust unidirezionale col dominio TRICK.LOCAL. Percé la relazione di trust funzioni c'è bisogno che sui due DNS di AD sia impostato un conditional forward.

Proviamo quindi a risolvere TRICK.LOCAL:

nslookup trick.local
Server:        192.168.98.101
Address:    192.168.98.101#53

Non-authoritative answer:
Name:    trick.local
Address: 192.168.99.101

Nel caso non risolvesse, c'è da controllare la configurazione DNS.

Aggiungiamo nella configurazione di kerberos i parametri relativi al secondo dominio AD, modificando il file /etc/krb5.conf:

[logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log 

[libdefaults]
default_realm = BRICK.LOCAL
dns_lookup_realm = true
dns_lookup_kdc = true

[realms]
BRICK.LOCAL = {
kdc = brick.local:88
admin_server = brick.local:749
default_domain = brick.local
}

TRICK.LOCAL = {
kdc = trick.local:88
admin_server = trick.local:749
default_domain = trick.local
}

[domain_realm]
.brick.local = BRICK.LOCAL
brick.local = BRICK.LOCAL
.trick.local = TRICK.LOCAL
trick.local = TRICK.LOCAL

[kdc]
profile = /var/kerberos/krb5kdc/kdc.conf

[appdefaults]
pam = {
debug = false
ticket_lifetime = 36000
renew_lifetime = 36000
forwardable = true
krb4_convert = false
}

Dal momento che il setup che andremo a realizzare sarà un setup multidominio, e si configurerà la possibilità di collisione fra nomi utente, è necessario variare il modo in cui Dovecot chiamerà la procedure di login e in cuiandrà a salvare i messaggi su filesystem.

Modifichiamo il file /etc/dovecot/conf.d/10-auth.conf

auth_username_format =%Ln@%Ud

In questo modo Dovecot passerà a PAM il nome utente nella forma utente@DOMINIO, in modo da rispettare la sintassi di kerberos utente@REALM.

Modifichiamo poi i file:

/etc/dovecot/conf.d/10-mail.conf

mail_location = maildir:/var/vmail/%Ld/%Ln/Maildir

/etc/dovecot/conf.d/auth-system.conf.ext

userdb {
  driver = static
  args = uid=500 gid=500 home=/var/vmail/%Ld/%Lu/Maildir allow_all_users=yes
}

In questo modo i messaggi verranno registrati nella cartella dominio/utente sotto /var/mail.

xenbackup-ng, for backing up your xenserver VMs with quiescent snapshot

Starting from Filippo Zanardo's Xenbackup, I wrote a modified version of his scripts, now tested and running on Citrix Xenserver 5.6 fp1 and Citrix Xenserver 6.0.2.

The script has the purpose to backup a Citrix Xenserver Guests Virtual Machines and it can be configured for doing it in different ways. 

Besides the Filippo's original version, I included some features:

• Split configuration files: one for strings, one for operational parameters.
• Added the Job feature: it is possible to create a job file in the job dir where general options can be overridden.
• Selective VM backup: it is possible to declare a list of VMs that will be backed up.
• Quiesce Snapshot on Windows VM: only with Xen VSS Provider installed on guest.
• Preserve VM power state: in case of normal backup (Shutdown->Backup->Start) the original vm state will be preserved. So, if a VM is initially powered off it will not powered on after backup.
• Improved email notifications: now is possible to receive a mail with a summary of operations executed or a verbose log of backup process. 

You can download the script direct from here or from my GitHub.

Dont't forget to change the mail address where you receive notification!

SCST iSCSI Resource agents for pacemaker.

Inspired by Openfiler I built my own DIY Highly Available SAN using Pacemaker, DRBD, LVM and SCST.
 
My current setup is:
- Two servers running gentoo
- a DRBD device in single primary
- a floating IP address
- an iSCSI Target with one LUN pointing straight to the DRBD device (vdisk_fileio, nv_cache).

The cib looks like:

node isan01 \
    attributes standby="off"
node isan02 \
    attributes standby="off"
primitive DRBD_VG1 ocf:linbit:drbd \
    params drbd_resource="ISCSIVG1" \
    op monitor interval="29" role="Master" \
    op monitor interval="31" role="Slave"
primitive ISCSI_IP1 ocf:heartbeat:IPaddr2 \
    params ip="192.168.100.20" \
    op monitor interval="10s"
primitive ISCSI_LUN_LUN10 ocf:scst:SCSTLun \
    params target_iqn="iqn.2012-02.com.


isan:vdisk.lun10" lun="0" path="/dev/drbd/by-res/DRBD_VG1" handler="vdisk_fileio" device_name="VDISK-LUN10" additional_parameters="nv_cache=1" \
    op monitor interval="10s"
primitive ISCSI_TGT_LUN10 ocf:scst:SCSTTarget \
    params iqn="iqn.2012-02.com.isan:vdisk.lun10" portals="192.168.100.20" \
    op monitor interval="10s" timeout="60s"
group GR_ISCSIVG1 ISCSI_TGT_LUN10 ISCSI_LUN_LUN10 ISCSI_IP1
ms MS_DRBD_VG1 DRBD_VG1 \
    meta master-max="1" master-node-max="1" clone-max="2" clone-node-max="1" notify="true"
colocation CO_ISCSI_ON_DRBD_VG1 inf: GR_ISCSIVG1 MS_DRBD_VG1:Master 
order OR_TARGET_BEFORE_VG1 inf: CL_ISCSI_TGT_LUN1:start GR_ISCSIVG1:start
order OR_DRBD_BEFORE_VG1 inf: MS_DRBD_VG1:promote GR_ISCSIVG1:start
property $id="cib-bootstrap-options" \
    dc-version="1.0.9-da7075976b5ff0bee71074385f8fd02f296ec8a3" \
    cluster-infrastructure="openais" \
    expected-quorum-votes="2" \
    stonith-enabled="false" \
    no-quorum-policy="ignore" \
    default-action-timeout="240"
rsc_defaults $id="rsc-options" \
    resource-stickiness="200"



Now I'm testing it  using vmware ESXi 5 as initiator. Seems working.

You can download them from my Github account ...

... and put them in /usr/lib/ocf/resource.d/scst.

UPDATE

SCST resource agent are now included in head revision of SCST project.
I'm just finished writing a master/slave version of SCSTLun, suitable only for iSCSI vdisk.
In the next days I'll test it and soon publish a little howto :)

Esportare le unità a nastro via iSCSI con SCST, autoloader compresi!

Nelle moderne sale server ci piace virtualizzare tutto. A volte anche il server che gestisce i backup. Quando facciamo backup su disco è facile, basta un NAS, ma quando dobbiamo farlo su nastro?
Va bene che vmware supporta il pass-through dei dispositivi SCSI, ma dato che ho un paio di storage iSCSI realizzati con Linux, perché non usarli anche per rendere disponibili nastri e autoloader, oltre che ai dischi?

Vediamo come farlo con linux, il target generico SCST e una unità Dell Powervault 124T.

( Do per scontato che abbiate già un'installazione linux con SCST funzionante, altrimenti in rete ci sono diversi howto da seguire per arrivare allo scopo. )

Per prima cosa colleghiamo e accendiamo la nostra libreria, se è esterna.
Poi controlliamo che il sistema la rilevi correttamente, con il comando lsscsi:

brick01# lsscsi 
[1:0:0:0] cd/dvd PLDS DVD+-RW DS-8W2S 1D11 /dev/sr0
[2:0:0:0] disk Generic STORAGE DEVICE 0207 /dev/sda
[3:0:32:0] enclosu DP BACKPLANE 1.05 -
[3:2:0:0] disk DELL PERC 6/i 1.21 /dev/sdb
[4:0:0:0] tape IBM ULTRIUM-TD4 97F0 -

Le librerie normalmente sono costituite da due LUN, la LUN0 che punta al nastro e la LUN1 che punta al media changer. Nel mio caso quindi (e probabilmente anche nel vostro) manca qualcosa ...

Dal momento che lo SCSI ID dell'unità a nastro è 4:0:0:0, rappresentato nella forma H:C:I:L (Host:Channel-ID-Lun), il nostro media changer dovrebbe corrispondere allo SCSI ID 4:0:0:1.
Per cui diciamo al sottosistema SCSI di linux di andare a interrogare anche l'ID del media changer.

brick01#echo "scsi add-single-device 4:0:0:1" > /proc/scsi/scsi

Ora l'unità dovrebbe fare un po' di rumori. Almeno è quello che ha fatto la mia!
Verifichiamo con lsscsi che il comando sia andato a buon fine:

brick01# lsscsi
[1:0:0:0] cd/dvd PLDS DVD+-RW DS-8W2S 1D11 /dev/sr0
[2:0:0:0] disk Generic STORAGE DEVICE 0207 /dev/sda
[3:0:32:0] enclosu DP BACKPLANE 1.05 -
[3:2:0:0] disk DELL PERC 6/i 1.21 /dev/sdb
[4:0:0:0] tape IBM ULTRIUM-TD4 97F0 -
[4:0:0:1] mediumx DELL PV-124T 0075 -


Ed ecco il apparire il changer!

Ora possiamo procedere con la configurazione di SCST.
Attiviamo prima gli handler di nastro e changer:

brick01#modprobe scst_tape
brick01#modprobe scst_changer


Per chi usa scstadmin, creiamo i due device in pass-through, creiamo un target iscsi e abilitiamolo:


brick01# scstadmin -open_dev 4:0:0:0 -handler dev_tape_perf
brick01# scstadmin -open_dev 4:0:0:1 -handler dev_changer
brick01# scstadmin -add_target iqn.2012-03.com.brick:vsan.tape -driver iscsi
brick01# scstadmin -add_lun 0 -target iqn.2012-03.com.brick:vsan.tape -device 4:0:0:0 -driver iscsi
brick01# scstadmin -add_lun 1 -target iqn.2012-03.com.brick:vsan.tape -device 4:0:0:1 -driver iscsi
brick01# scstadmin -enable_target iqn.2012-03.com.brick:vsan.tape -driver iscsi


Per chi vuole agire direttamente sul file di configurazione, invece:

#File /etc/scst.conf

HANDLER dev_changer {
        DEVICE 4:0:0:1
}

HANDLER dev_tape_perf {
        DEVICE 4:0:0:0
}

TARGET_DRIVER iscsi {
        enabled 1

        TARGET iqn.2012-03.com.brick:vsan.tape {
                enabled 1
                rel_tgt_id 1

                LUN 0 4:0:0:0
                LUN 1 4:0:0:1
        }
}

Poi andate sul vostro initiator preferito (io ho testato il tutto con Microsoft iSCSI Initiator e Symantec Backup Exec), collegate il target, e buon backup!

Utilizzare mpop come connettore POP alternativo per Exchange

Il Connettore POP di SBS (o di Exchange) mi fa spesso dannare e talvolta il troubleshooting può essere lungo, creando fastidi all'utente.
Ci sono valide alternative commerciali al connettore POP3 di Microsoft, come ad esempio MAPILab POP3 Connector, GFI MailEssentials, ma prediligo le soluzioni aperte e gratuite.
Quindi, vagando per la rete in cerca di alternative più aperte e meno costose, mi sono imbattutto in mpop, una alternativa command-line e open source al POP connector di SBS.
Ho scaricato la versione per windows (c'è anche per Linux) e l'ho provato su un server Exchange 2003... funziona!

Ma vediamo come ho fatto:

Innanzitutto, per il corretto funzionamento di mpop è necessario:
- Localizzare correttamente la directory Pickup di Exchange (Per sapere qual è vi rimando all'articolo sulla KB Microsoft KB 822933)
- Che gli indirizzi di posta associati alle cassette postali POP3 siano configurati su degli utenti esistenti sul sistema (ovvero se alla cassetta postale POP3 corrisponde l'indirizzo mailbox_1@mypop3.com lo stesso indirizzo deve esistere nella scheda "Indirizzi di Posta Elettronica" di un utente Active Directory)

Scarichiamo mpop per windows, estraiamo il file mpop.exe dall'archivio zip e mettiamolo su disco (io l'ho messo in C:\progs\mpop), creiamo poi il file di configurazione, chiamiamolo mpoprc.txt:

#File C:\progs\mpop\mpoprc.txt
defaults
# Disattivo TLS (nel mio caso utilizzo un server POP3 senza supporto per autenticazione sicura).
tls off
tls_starttls off

# Giro i messaggi nella directory Pickup di Exchange:
delivery exchange "C:\Programmi\Exchsrvr\Mailroot\vsi 1\PickUp"


# Nel mio caso ho due mailbox


account mailbox_1
# Imposto l'autenticazione
auth user
host mail.mypop3.com
user user_1
password lamiapassword

#Creo un secondo account, copia del primo, e cambio solo nome utente e password
account mailbox_2 : mailbox_1
user user_2
password lamiapassword_2

# Imposto un account di default (anche se non è necessario)
account default : mailbox_1


Per comodità creiamo un file batch, chiamiamolo mpopretrieve.cmd:

REM file c:\progs\mpop\mpopretrieve.cmd


@echo off
cd c:\progs\mpop
mpop.exe -C mpoprc.txt -a > mpopout.txt


In questo modo diciamo a mpop di leggere la configurazione dal file mpoprc.txt e di scaricare i messaggi da tutti gli account POP. Reindirizziamo poi l'output del comando sul file mpopout.txt.

Per testare il funzionamento, eseguiamo il file mpopretrieve.cmd. A esecuzione completata possiamo aprire il file mpopout.txt e visualizzare l'output:

mailbox_1 at mail.mypop3.com:
new: 1 message in 6.88 KiB, total: 1 message in 6.88 KiB
retrieving message 1 of 1 (6.88 KiB): 0%...100
mailbox_2 at mail.mypop3.com:
new: 1 message in 6.88 KiB, total: 1 message in 6.88 KiB
retrieving message 1 of 1 (6.88 KiB): 0%...100


Controlliamo poi in OWA o in Outlook se l'utente o gli utenti han ricevuto messaggi.
Se tutto è ok, possiamo pianificare l'esecuzione di mpopretrieve.cmd con le Operazioni Pianificate o il nostro scheduler preferito.

Installazione di SOGo con Integrazione Active Directory

Hai un dominio Active Directory, non hai un sistema di gestione dalla posta elettronica e ne vorresti uno che ti permetta di condividere calendari e contatti con i tuoi colleghi senza dover accendere un mutuo per acquistare Exchange?

Vedremo ora tutto il processo di installazione e configurazione di SOGo con login degli utenti da Active Directory.
SOGo per funzionare ha bisogno di:

• Un Database (io ho scelto MySQL, potete anche usare PostgreSQL o Oracle)
• Un server LDAP (nel nostro caso Microsoft Active Directory. Potete utilizzare OpenLDAP o 389 Directory Server)
• Un server IMAP (io ho scelto Dovecot, ma va bene anche Cyrus)
• Un server SMTP (Postfix, ma se volete farvi del male usate pure Sendmail)

1. Preparazione

Prima di arrivare alla configurazione vera e propria di SOGo, è necessario avere una infrastruttura di posta elettronica funzionante. Dobbiamo quindi avere un server IMAP e un server SMTP funzionanti.
Seguendo la guida linkata qui sotto arriverete ad avere una buona base di partenza.

Mailbox Virtuali con Dovecot, Postfix e Active Directory

Configurate il DNS: la risoluzione DNS deve funzionare. Aggiungete un record nel DNS, che punta all'ip del vostro server SOGo, che risponda al nome di sogoserver, o quello che vi pare: l'importante è che vi ricordiate di sostituire col vostro nome all'occorrenza.

2. Aggiunta dei Repository

Se utilizzate CENTOS 6

Aggiungiamo il repository di inverse a YUM.
Creiamo il file /etc/yum.repos.d/inverse.repo.


[SOGo]
name=Inverse SOGo repository
baseurl=http://inverse.ca/downloads/SOGo/RHEL6/$basearch
gpgcheck=0


Potete tranquillamente saltare alla sezione successiva

Se utilizzate CENTOS 5

aggiungiamo il repository di inverse a YUM.
Creiamo il file /etc/yum.repos.d/inverse.repo.


[SOGo]
name=Inverse SOGo repository
baseurl=http://inverse.ca/downloads/SOGo/CentOS5/$basearch
gpgcheck=0


In CentOS 5 la semplice aggiunta del repository non è sufficiente, bisogna effettuare alcune modifiche a yum:

Installiamo il plugin yum-protectbase:


yum install yum-protectbase


Modifichiamo il file /etc/yum.repos.d/CentOS-Base.repo:

#Aggiungere nella sezione base
#[base]
protect=1

#Aggiungere nella sezione updates
#[update]
protect=1


Abilitiamo i repository RPMForge:
Modifichiamo il file /etc/yum.repos.d/rpmforge.repo


#Aggiungere nella sezione rpmforge-base
#[rpmforge-base]
exclude=memcached*


4. Configurazione di MySQL

Installiamo MySQL server:


yum install mysql-server


Modifichiamo il file /etc/my.cnf in modo da impostare come set di caratteri predefinito UTF-8.


[mysqld]
character_set_server=utf8
character_set_client=utf8

[client]
default-character-set=utf8

[mysql]
default-character-set=utf8


Avviamo mysql:


service mysqld start


Entriamo in mysql, creiamo il database per SOGo e creiamo un utente sogo che abbia tutti i privilegi sul database:

mysql
CREATE DATABASE sogo CHARSET='UTF8';
GRANT ALL PRIVILEGES ON sogo.* @'localhost' IDENTIFIED BY 'sogopassword';
quit;


4. Configurazione di SOGo

Installiamo SOGo e il connettore per il database (nel nostro caso MySQL):

yum install sogo
yum install sope49-gdl1-mysql;


Configurazione di Base:

Creiamo una configurazione di base per il nostro SOGo, inseriamo la timezone, la lingua predefinita


su - sogo
defaults write sogod SOGoTimeZone "Europe/Rome"
defaults write sogod SOGoMailDomain "brick.local"
defaults write sogod SOGoLanguage Italian
defaults write sogod SOGoAppointmentSendEMailNotifications YES
defaults write sogod SOGoFoldersSendEMailNotifications YES
defaults write sogod SOGoACLsSendEMailNotifications YES
exit


Aggancio del Server LDAP

SOGo può utilizzare uno o più server (o meglio query) LDAP come database per l'autenticazione o elenchi di indirizzi. Aggiungiamo quindi il server LDAP come sorgente per gli utenti di SOGo.

Se non lo avete già fatto create un utente in Active Directory. L'utente deve poter effettuare delle query su LDAP. Io ho creato l'utente adquery con password password.


su - sogo
defaults write sogod SOGoUserSources '({type=ldap; CNFieldName = cn; IDFieldName = cn; UIDFieldName = sAMAccountName; baseDN = "dc=brick,dc=local"; bindDN = "adquery@brick.local"; bindFields = (sAMAccountName); bindPassword = password; canAuthenticate = YES; displayName = "Active Directory"; hostname = brick.local; id = directory; isAddressBook = YES; port = 389;});'
exit


Database MySQL


su - sogo
defaults write sogod SOGoProfileURL 'mysql://sogo:sogopassword@localhost:3306/sogo/sogo_user_profile'
defaults write sogod OCSFolderInfoURL 'mysql://sogo:sogopassword@localhost:3306/sogo/sogo_folder_info'
defaults write sogod OCSSessionsFolderURL 'mysql://sogo:sogopassword@localhost:3306/sogo/sogo_sessions_folder'
exit


Server SMTP


su - sogo
defaults write sogod SOGoMailingMechanism smtp
defaults write sogod SOGoSMTPServer localhost


Server IMAP


su - sogo
defaults write sogod SOGoDraftsFolderName Drafts
defaults write sogod SOGoSentFolderName Sent
defaults write sogod SOGoTrashFolderName Trash
defaults write sogod SOGoIMAPServer localhost
exit


Utente Amministratore

Dobbiamo dire a SOGo quale sarà l'utente amministratore che avrà il privilegio di gestire le condivisioni tramite Web UI.

su - sogo
defaults write sogod SOGoSuperUsernames "(Administrator)"


6. Configurazione di Apache

Per far funzionare la WEB UI, modifichiamo il file /etc/httpd/conf.d/SOGo.conf

RequestHeader set "x-webobject-server-port" "80"
RequestHeader set "x-webobject-server-name" "sogoserver"
RequestHeader set "x-webobject-server-url" "http://sogoserver"


7. Avvio dei servizi

Avviamo i servizi:

service sogod start
service httpd start

Poi aprite il vostro browser preferito e puntatelo su http://sogoserver/sogo. Se appare la schermata di login accedete col vostro utente di prova e fatevi un giretto nella WEB UI.

Aggiungiamo poi i servizi appena installati all'avvio automatico:

chkconfig mysqld on
chkconfig sogod on
chkconfig httpd on


Ora provate a puntare il browser all'indirizzo http://sogoserver/SOGo (attenzione che SOGo deve essere scritto proprio così) e controllate la vostra mail!

Mailbox Virtuali con Dovecot, Postfix e Active Directory

Seguendo questa piccola guida realizzeremo un sistema di posta basato su Dovecot e Postfix, su server Linux, con autenticazione e gestione delle informazioni utente tramite Active Directory.

Il prodotto finito sarà funzionante ma estremamente semplice: solo IMAP e SMTP, nessun filtraggio dei contenuti, nessuna implementazione di comunicazione sicura. Diciamo che sarà una buona base per ulteriori implementazioni.

Premesse

• Le configurazioni lato linux qui proposte sono realizzate su CentOS.
• Il mio dominio Windows è BRICK.LOCAL. Sostituitelo con il vostro nome di dominio nei file di configurazione.
• In Active Directory abbiamo un utente testuser con password testpassword.
• Il mio indirizzamento di rete è 192.168.98.0/24
• I DNS devono essere configurati correttamente.
• Gli orologi del Domain Controller Active Directory e del server Linux devono essere sincronizzati, o deve esserci una differenza massima di 5 minuti.
• Tenete d'occhio il file /var/log/maillog, è pieno di informazioni utili!
• Dotatevi di un browser LDAP (JXPlorer, ADSI Edit o Softerra LDAP Browser).

1. Installazione dei Pacchetti

Installiamo i pacchetti necessari:

yum install postfix dovecot krb5-workstation pam-krb5

2. Configurazione di Kerberos

Configuriamo kerberos per autenticarsi con Active Directory:
Modifichiamo il file  /etc/krb5.conf

[logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log 

[libdefaults]
default_realm = BRICK.LOCAL
dns_lookup_realm = true
dns_lookup_kdc = true

[realms]
BRICK.LOCAL = {
kdc = brick.local:88
admin_server = brick.local:749
default_domain = brick.local
}

[domain_realm]
.brick.local = BRICK.LOCAL
brick.local = BRICK.LOCAL

[kdc]
profile = /var/kerberos/krb5kdc/kdc.conf

[appdefaults]
pam = {
debug = false
ticket_lifetime = 36000
renew_lifetime = 36000
forwardable = true
krb4_convert = false
}

Ho messo nel campo kdc il nome di dominio perché nella configurazione standard del DNS di Active directory al nome di dominio corrisponde il primo Domain Controller disponibile. Provate con il comando "nslookup brick.local"

Testiamo poi il funzionamento di kerberos con il comando:

host -t any _kerberos._tcp.brick.local

Se produce una risposta del tipo "_kerberos._tcp.brick.local has SRV record …" è tutto a posto, altrimenti c'è bisogno di ricontrollare la configurazione DNS.

Poi proviamo ad autenticarci:

kinit testuser

Quando ci viene chiesto digitiamo la password. Se il comando non produce nessun output con kerberos abbiamo finito, altrimenti ricontrolliamo la configurazione.



3. Configurazione di Dovecot

Configuriamo l'autenticazione PAM per dovecot, sostituendo il contenuto del file /etc/pam.d/dovecot con:

auth sufficient pam_krb5.so no_user_check validate
account sufficient pam_permit.so


Creiamo un utente vmail:

useradd vmail -m -s /sbin/nologin -d /var/vmail

Annotiamoci uid e gid dell'utente vmail, ci tornerà utile dopo. Lanciamo il comando

getent passwd | grep vmail


che produrrà un output di questo tipo:

vmail:x:501:501:/var/vmail:/sbin/nologin


Per gli utenti di Dovecot 1.x , modifichiamo il file /etc/dovecot.conf

protocols = imap
auth_username_format = %Lu
auth_debug = yes
disable_plaintext_auth = no
ssl_disable = yes
mail_location = maildir:/var/vmail/%n/Maildir
first_valid_uid = 501
last_valid_uid = 501
first_valid_gid = 501
last_valid_gid = 501
valid_chroot_dirs = /var/vmail

protocol lda {
#L'indirizzo del Postmaster per il Local Delivery
        postmaster_address = administrator@brick.local
}

auth default {
        mechanisms = plain login
        passdb pam {
        }
        userdb static {
         args = uid=501 gid=501 home=/var/vmail/%Lu/Maildir/ allow_all_users=yes
        }

socket listen {
        client {
          #Parametri per dovecot-sasl, Postfix utilizza dovecot per inziare una sessione SMTP autenticata
          path = /var/spool/postfix/private/auth
          mode = 0660
          user = postfix
          group = postfix

        master {
          #Impostazioni per LDA
          path = /var/run/dovecot/auth-master
          mode = 0600
          user = vmail
          group = vmail
        }
}

}

Per gli utenti di Dovecot 2.x, dal momento che lo schema dei file di configurazione è cambiato, bisognerà procedere modificando diversi file:

File /etc/dovecot/conf.d/10-auth.conf

auth_username_format = %Lu
auth_debug = yes
ssl = no
first_valid_uid = 501
last_valid_uid = 501
first_valid_gid = 501
last_valid_gid = 501


File /etc/dovecot/conf.d/auth-system.conf.ext 

passdb {
         driver = pam
       }
userdb {
         driver = static
         args = uid=501 gid=501 home=/var/vmail/%Lu allow_all_users=yes
       }


File /etc/dovecot/conf.d/10-master.conf

service auth {
               unix_listener auth-userdb {
                                           mode = 0600
                                           user = vmail
                                           group = vmail
                                         }
               unix_listener /var/spool/postfix/private/auth {
                                           mode = 0660
                                           user = postfix
                                           group = postfix
                                         }
}

File /etc/dovecot/conf.d/15-lda.conf

postmaster_address = administrator@brick.local

Avviamo poi Dovecot con il comando

service dovecot start

Testiamo se l'autenticazione funziona (digitate solo i comandi in grassetto):

telnet localhost 143
Trying 127.0.0.1...
Connected to localhost.localdomain (127.0.0.1).
Escape character is '^]'.
* OK Dovecot ready.
a LOGIN testuser testpassword
a OK Logged in.
a EXAMINE INBOX
* FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
* OK [PERMANENTFLAGS ()] Read-only mailbox.
* 0 EXISTS
* 0 RECENT
* OK [UIDVALIDITY 1307972331] UIDs valid
* OK [UIDNEXT 1] Predicted next UID
a OK [READ-ONLY] Select completed.
a LOGOUT
* BYE Logging out
a OK Logout completed.
Connection closed by foreign host.

Se il server vi risponde come sopra è tutto ok, altrimenti ricontrollate i file di configurazione e spulciatevi i log.

Per configurare Dovecot in modalità Multi-Tenant, fate riferimento a questo articolo


4. Configurazione di Postfix

Per fare in modo che Postfix riconosca se un indirizzo mail è esistente o meno nella nostra organizzazione, impostiamo un lookup su Active Directory tramite LDAP.

Creiamo prima un utente in Active Directory la cui funzione sarà quella di effettuare le query su LDAP.
Io ho creato l'utente adquery con password password e l'ho messo nell'unità organizzativa System Users.

Il bind DN con Active Directory può essere esplicitato in 3 modi:

1. Utilizzando la sintassi LDAP, nel nostro caso CN=adquery,OU=System Users,DC=brick,DC=local
2. Utilizzando la la forma utente\DOMINIO, nel nostro caso adquery\BRICK
3. Utilizzando la forma utente@dominio, nel nostro caso adquery@brick

Creiamo il file /etc/postfix/ldap-users.cf:

server_host = brick.local
search_base = DC=brick,DC=local

bind = yes
bind_dn = adquery@brick.local
bind_pw = querypassword

query_filter = (&(objectclass=person) (mail=%s))
result_attribute = sAMAccountName
version = 3
result_format=%s/Maildir/ 


Configuriamo il delivery transport di Dovecot, aggiungendo in fondo al file /etc/postfix/master.cf

# Dovecot LDA
dovecot unix - n n - - pipe
flags=DRhu user=vmail:vmail argv=/usr/libexec/dovecot/deliver -f ${sender} -d ${recipient}

Modificate il file /etc/postfix/main.cf:

mynetworks_style = subnet
mynetworks = 127.0.0.0/8,192.168.98.0/24

myhostname = mail.brick.local
myorigin = $mydomain

#Autenticazione SASL (postfix utilizza dovecot, che a sua volta si appoggia a Kerberos di Active Directory
smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth
smtpd_sasl_auth_enable = yes

smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated,reject_unauth_destination

alias_maps = hash:/etc/aliases
command_directory = /usr/sbin
daemon_directory = /usr/libexec/postfix

# Usiamo dovecot lda per recapitare i messaggi nelle mailbox, il transport dovecot è definito nel file /etc/postfix/master.cf
virtual_transport=dovecot
dovecot_destination_recipient_limit=1

virtual_mailbox_domains = brick.local
virtual_mailbox_base = /home/vmail/
 
#Lo UID e il GID dell'utente vmail, ve lo siete annotati?
virtual_uid_maps = static:501
virtual_gid_maps = static:501

# Controlliamo che l'indirizzo del destinatario sia valido e facciamo in modo che dovecot LDA recapiti il messaggio nella posizione corretta

virtual_alias_maps = ldap:/etc/postfix/ldap-users.cf
virtual_mailbox_maps = ldap:/etc/postfix/ldap-users.cf

Riavviamo Postfix:

service postfix restart


E Proviamo a inviare un messaggio (digitiamo i comandi in grassetto):
telnet localhost 25
Trying 127.0.0.1...
Connected to localhost.localdomain (127.0.0.1).
Escape character is '^]'.
220 mail.brick.local ESMTP Postfix
HELO brick.local
250 mail.brick.local
mail from brick@brick.local
250 2.1.0 Ok
RCPT TO: testuser@brick.local
250 2.1.5 Ok
DATA
354 End data with <CR><LF>.<CR><LF>
Subject: La vispa...
...Teresa avea tra l'erbetta a volo sorpresa gentil farfalletta ...
.
250 2.0.0 Ok: queued as A6DF511804D
quit
221 2.0.0 Bye
Connection closed by foreign host.

Poi controllate sul server IMAP se c'è posta. Se non vi ha scritto nessuno ricontrollate i file di configurazione e buttate un occhio sui log.
Magari, se vi è venuta la sindrome da tunnel carpale a forza di comandi telnet, potete anche configurare il vostro client di posta preferito, così potete testare anche l'autenticazione SMTP. Io vi consiglio Mozilla Thunderbird!

Se tutto funziona, possiamo aggiungere all'avvio automatico Dovecot e Postfix:


chkconfig dovecot on
chkconfig postfix on


Ed ecco pronto il nostro server di posta.

Fonti:
Shami's Blog: FreeBSD, Postfix, Dovecot, and Active Directory
Active Directory and Dovecot PAM Authentication

Xenbackup-ng, backup di VM xenserver con snapsot quiesce, and more

Basandomi sugli script xenbackup di Filippo Zanardo, ho realizzato una versione modificata di xenbackup, che per il momento sto usando con successo su Citrix Xenserver 5.6 fp1 e Xenserver 6.02.

Lo script consente di eseguire dei backup dei guest Citrix Xenserver e può essere configurato per farlo con diverse modalità.
Rispetto alla versione originale di Filippo ho introdotto alcune varianti:

• Separato i file di configurazione: uno per le stringhe, uno per i parametri "operativi".
• Aggiunto il concetto di Job: nella directory jobs possono essere messi dei file dove specificare, oltre al nome del job, impostazioni diverse rispetto a quelle definite nel file di configurazione.
• Backup selettivo delle VM: si possono selezionare anche solo una o più VM, invece della pool completa.
• Quiesce Snapshot sulle VM Windows: deve essere installato però Xen VSS Provider.
• Preservazione dello stato della VM: nel caso di backup in modalità normale (Shutdown/Backup/Start) viene tenuto conto dello stato in cui si trova la macchina al momento; se la VM è spenta, dopo il backup non viene avviata.
• Notifiche via email: è possibile ricevere una semplice mail riepilogativa, o una mail riepilogativa con in fondo il log dettagliato delle operazioni eseguite. 

Lo script è scaricabile direttamente dal mio dropbox, cliccando qui.