bologna

Download Zimbra versioni e patch Download

Versioni di Zimbra, link di download dirette (direct download zimbra), patch e manuali per versioni CentOS 6.x 64 bit e CentOS 7.x 64 bit.

Zimbra documento dei requisiti: zcs_system_requirements_8-7-0

Zimbra documento per multi-server: zimbra-open-source-edition-multi-server-installation-guide-8-7

Zimbra 8.7.1

CentOS 6.x: https://files.zimbra.com/downloads/8.7.1_GA/zcs-8.7.1_GA_1670.RHEL6_64.20161025035141.tgz
CentOS 7.x: https://files.zimbra.com/downloads/8.7.1_GA/zcs-8.7.1_GA_1670.RHEL7_64.20161025045328.tgz

Zimbra 8.7.0

CentOS 6.x: https://files.zimbra.com/downloads/8.7.0_GA/zcs-8.7.0_GA_1659.RHEL6_64.20160628192545.tgz
CentOS 7.x: https://files.zimbra.com/downloads/8.7.0_GA/zcs-8.7.0_GA_1659.RHEL7_64.20160628202714.tgz

Zimbra 8.6.0

CentOS 6.x: https://files.zimbra.com/downloads/8.6.0_GA/zcs-8.6.0_GA_1153.RHEL6_64.20141215151155.tgz
CentOS 7.x: https://files.zimbra.com/downloads/8.6.0_GA/zcs-8.6.0_GA_1153.RHEL7_64.20141215151110.tgz
patch: https://files.zimbra.com/downloads/8.6.0_GA/zcs-patch-8.6.0_GA_1200.tgz
note: http://files.zimbra.com.s3.amazonaws.com/website/docs/8.6/ZCS_860_Patch7_ReleaseNotes.pdf

Zimbra 8.5.0

CentOS 6.x: https://files2.zimbra.com/downloads/8.5.0_GA/zcs-8.5.0_GA_3042.RHEL6_64.20140828192005.tgz
CentOS 7.x: https://files2.zimbra.com/downloads/8.5.0_GA/zcs-8.5.0_GA_3042.RHEL7_64.20140828204420.tgz
patch: https://files2.zimbra.com/downloads/8.5.0_GA/zcs-patch-8.5.0_GA_3050.tgz
note: https://files.zimbra.com/website/docs/8.5/ZCS_850_Patch2_ReleaseNotes.pdf

Zimbra 8.0.9

CentOS 6.x: https://files2.zimbra.com/downloads/8.0.9_GA/zcs-8.0.9_GA_6191.RHEL6_64.20141103151557.tgz
CentOS 7.x: https://files2.zimbra.com/downloads/8.0.9_GA/zcs-8.0.9_GA_6191.RHEL7_64.20141103151539.tgz

Zimbra 7.2.7

CentOS 6.x: https://files2.zimbra.com/downloads/7.2.7_GA/zcs-7.2.7_GA_2942.RHEL6_64.20140314185955.tgz

Open Source: Zimbra 8.7 – ActiveSync – Autodiscover – Z-Push 2.3.0 – Zimbra Backend 64 – CentOS 6.8 x64

L’uscita di Zimbra 8.7 e dei nuovi telefoni basati sui sistemi Android rende necessario un aggiornamento alle ultime release di ActiveSync Open Source. In questo articolo verrà trattata la completa installazione e configurazione di un server CentOS 6.8 64bit che svolgerà il compito di ActiveSync verso i mobile per la soluzione di posta elettronica e collaborazione basata su Zimbra 8.7.

Premessa

Server Zimbra
Nome HOST: zimbra.dev.andreabalboni.com
IP HOST Zimbra: 10.0.0.20/24
Iptables e SELINUX disattivati

Server ActiveSync/Autodiscover
nome host: activesync.dev.andreabalboni.com
ip host: 10.0.0.19/24
Iptables e SELINUX disattivati

Verifica iptables disattivato

# iptables -L

Chain INPUT (policy ACCEPT)
target prot opt source destination

Chain FORWARD (policy ACCEPT)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

Verifica SELINUX disattivato

# cat /etc/selinux/config

# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
# enforcing – SELinux security policy is enforced.
# permissive – SELinux prints warnings instead of enforcing.
# disabled – No SELinux policy is loaded.
SELINUX=disabled
# SELINUXTYPE= can take one of these two values:
# targeted – Targeted processes are protected,
# mls – Multi Level Security protection.
SELINUXTYPE=targeted

Installazione / Configurazione Server ActiveSync / Autodiscover

I punti che verranno svolti saranno:

1- installazione web server (httpd)
2- installazione php ver. 5.4
3- creazione del certificato autofirmato SSL (durata 10 anni)
4- configurazione del server web verso la zona z-push (2.3.0)
5- download, installazione e configurazione z-push e autodiscovery
6- installazione e configurazione backend zimbra (6.4) per z-push (2.3.0) e Zimbra (8.7)

1- installazione web server (httpd)

Accedere con utente root al sistema CentOS 6.8 x64
# yum install httpd
# yum install mod_ssl openssl

2- installazione php ver. 5.4

Per installare php ver. 5.4 è necessario abilitare un repository alla CentOS 6.8.
Vedi articolo http://vlab.abconsultinggroup.eu/centos-567-installazione-php-5-3-es-php-5-4/

Pacchetti da abilitare per activesync/autodiscovery.
# yum install php54w.x86_64 php54w-cli.x86_64 php54w-soap.x86_64 php54w-process.x86_64 php54w-mbstring.x86_64

3- creazione del certificato autofirmato SSL

Accedere con utente root al sistema WEB Server php/httpd

# openssl genrsa -out ca.key 1024
# openssl req -new -key ca.key -out ca.csr
# openssl x509 -req -days 3650 -in ca.csr -signkey ca.key -out ca.crt
# cp ca.key /etc/pki/tls/private/
# cp ca.csr /etc/pki/tls/private/
# cp ca.crt /etc/pki/tls/certs/

4- configurazione del server web verso la zona z-push
Accedere con utente root al sistema WEB Server php/httpd

# mkdir /var/www/html/zpush
# mkdir /var/log/zpush
# nano /etc/httpd/conf/httpd.conf

 

NameVirtualHost *:443

Alias /Microsoft-Server-ActiveSync /var/www/html/zpush/index.php
AliasMatch (?i)/Autodiscover/Autodiscover.xml “/var/www/html/zpush/autodiscover/autodiscover.php”

<VirtualHost *:443>
SSLEngine on
SSLCertificateFile /etc/pki/tls/certs/ca.crt
SSLCertificateKeyFile /etc/pki/tls/private/ca.key
<Directory /var/www/html/zpush>
AllowOverride All
php_flag magic_quotes_gpc off
php_flag register_globals off
php_flag magic_quotes_runtime off
php_flag short_open_tag on
</Directory>
DocumentRoot /var/www/html/zpush
ServerName activesync.dev.andreabalboni.com
</VirtualHost>

5- download, installazione e configurazione z-push

# wget http://download.z-push.org/final/2.3/z-push-2.3.0.tar.gz
# tar zxfv z-push-2.3.0.tar.gz
# cd z-push-2.3.0
# cp -R * /var/www/html/zpush/.
# mkdir /var/www/html/zpush/state
# mkdir /var/www/html/zpush/backend/zimbra

Configurazione z-push

# nano /var/www/html/zpush/config.php

conf#01

* Default settings
*/
// Defines the default time zone, change e.g. to “Europe/London” if necessary
define(‘TIMEZONE’, ‘Europe/Rome’);

conf#02

*/
define(‘USE_FULLEMAIL_FOR_LOGIN’, true);

conf#03

*/
define(‘STATE_MACHINE’, ‘FILE’);
define(‘STATE_DIR’, ‘/var/www/html/zpush/state/’);

conf#04

// Filelog settings
define(‘LOGFILEDIR’, ‘/var/log/zpush/’);
define(‘LOGFILE’, LOGFILEDIR . ‘zpush.log’);
define(‘LOGERRORFILE’, LOGFILEDIR . ‘zpush-error.log’);

conf#05

// SYNC_FILTERTYPE_1MONTH, SYNC_FILTERTYPE_3MONTHS, SYNC_FILTERTYPE_6MONTHS
define(‘SYNC_FILTERTIME_MAX’, SYNC_FILTERTYPE_6MONTHS);

conf#06

* Backend settings
*/
// the backend data provider
define(‘BACKEND_PROVIDER’, ‘BackendZimbra’);

Configurazione Autodiscovery

Il sistema Autodiscovery è legato al DNS pubblico del dominio. Nel caso di un dominio di posta elettronica @domain.ltd, dovrà essere definito il record A nel DNS pubblico come autodiscover.domain.ltd verso l’ip pubblico del webserver su cui viene configurato l’autodiscovery e lo zpush. Nel nostro caso il dominio su cui stiamo lavorando è @dev.andreabalboni.com e il record A definito per l’autodiscovery è autodiscovery.dev.andreabalboni.com .

# nano /var/www/html/zpush/autodiscover/config.php

conf#01

*/
// Defines the default time zone, change e.g. to “Europe/London” if necessary
define(‘TIMEZONE’, ‘Europe/Rome’);

conf#02

// The Z-Push server location for the autodiscover response
define(‘SERVERURL’, ‘https://activesync.dev.andreabalboni.com/Microsoft-Server-ActiveSync’);

conf#03

define(‘USE_FULLEMAIL_FOR_LOGIN’, true);

conf#04

*/

define(‘LOGBACKEND’, ‘filelog’);

define(‘LOGFILEDIR’, ‘/var/log/zpush/’);
define(‘LOGFILE’, LOGFILEDIR . ‘autodiscover.log’);
define(‘LOGERRORFILE’, LOGFILEDIR . ‘autodiscover-error.log’);

conf#05

*/
// the backend data provider
define(‘BACKEND_PROVIDER’, ‘BackendZimbra’);

 

6- installazione e configurazione backend zimbra per z-push

# wget http://downloads.sourceforge.net/project/zimbrabackend/Release64/zimbra64.tgz?r=https%3A%2F%2Fsourceforge.net%2Fprojects%2Fzimbrabackend%2F&ts=1472108441&use_mirror=kent
# tar zxfv zimbra64.tgz
# cd zimbra64
# cd z-push-2
# cp -R * /var/www/html/zpush/backend/zimbra/.
# chown -R apache:apache /var/www/html/zpush /var/log/zpush
# chmod -R 775 /var/www/html/zpush /var/log/zpush
# nano /var/www/html/zpush/backend/zimbra/config.php

conf#01

// define(‘ZIMBRA_URL’, ‘https://127.0.0.1’);

define(‘ZIMBRA_URL’, ‘https://zimbra.dev.andreabalboni.com:8443’);

 

VPN site-to-site dietro router, NAT e firewall: quando non vi sono i requisiti standard

La realizzazione delle VPN site to site richiedono requisiti strutturali ben precisi per realizzare connessioni fra uffici stabili e prestanti. Ci si trova in situazioni dove non è possibile avere:

  • pool di IP pubblici statici
  • configurazione dell’ip pubblico sulla interfaccia WAN del proprio device di rete (normalmente firewall)
  • router in gestione autonoma

Questo articolo propone una soluzione di VPN site-to-site basata sul protocollo PPTP di Microsoft.

Rete A – 192.168.0.0 / 24 (sede centrale)

Rete B – 192.168.10.0/24 (sede remota, ad es: magazzino)

Diagramma di rete.

vpn-pptp

Composizione della rete A.

Server Windows: 192.168.0.100 / 255.255.255.0, gateway 192.168.0.254
Firewall: LAN 192.168.0.254 / 255.255.255.255.0 – WAN 192.168.1.254 /255.255.255.0 – GW 192.168.1.1
Router operatore: LAN 192.168.1.1 – WAN: IP-Pubblico-Rete-A (assegnato dall’operatore)

vpn-pptp-A

Composizione della rete B.

Linux PPTP-client-gateway: 192.168.10.254 / 255.255.255.0, gateway 192.168.10.1
Router operatore: LAN 192.168.10.1 – WAN: IP-Pubblico-Rete-B (assegnato dall’operatore)

vpn-pptp-B

Configurazione apparati della rete A.

Le parti che necessitano configurazioni sono il Server Windows e il firewall. L’installazione da svolgere sul server windows riguarda l’attivazione del ruolo di “Servizio di accesso e criteri di rete” e la relativa configurazione VPN (è necessario avere un servizio DHCP attivo e limitare il numero di connessioni lato VPN per non saturare il range DHCP).

ruolo

Nella definizione dell’utente per la connession VPN (in esempio “magazzinovpn”) va definita correttamente la proprietà “chiamate in ingresso”

account

e va inoltre definita la parte “Assegna inidirizzi IP statici”

indirizzo-ip-statico

definendo così (ad es: 192.168.0.20) l’ip che avrà la connessione con utente “magazzinovpn” e che rappresenterà il gateway della rete-A verso la rete-B.

Lato firewall vanno definite le regole di port-forwarding verso il server windows (192.168.0.100) delle porte TCP/1723 e GRE/47 (è probabile che il la porta GRE/47, quella responsabile del tunnel VPN non si definibile perché implicitamente già aperta). Lato firewall va definita una route statica dove si indica che tutte le sorgenti LAN (rete-A: 192.168.0.0/24) che hanno come destinazione la rete magazzino (rete-B: 192.168.10.0/24) il next-hop è il 192.168.0.20. Il router dell’operatore deve “girare” tutte le richieste da “Internet” sull’ip del firewall 192.168.1.254.

IMPORTANTE. Ora serve un’ultima definizione di routing: le destinazioni che devono raggiungere la rete-B (192.168.10.0/24) devono attraversare il tunnel VPN. Questa definizione deve essere scritta all’interno del server windows (è il sistema operativo che ha in gestione il tunnel VPN). Inoltre questa definizione deve essere attivata tutte le volte che viene accessa la VPN. In caso di caduta di linea la VPN cade, la route viene eliminata dal sistema operativo e quando la connettività riprende la VPN si ristabilisce e con sè si deve ristabilire anche la route statica di attraversamento tunnel.

Per realizzare questo meccanismo creiamo un file di script all’interno di c:\scripts e lo chiamiamo routevpn.cmd e al suo interno le seguenti righe:

route add 192.168.10.0 mask 255.255.255.0 192.168.0.20

Per “far scattare” questo meccanismo tutte le volte che il tunnel VPN si attiva, utilizziamo la tecnica delle schedulazioni Microsoft basate su evento. L’evento di attivazione tunnel VPN è nel registro di “Sistema” con event-ID=20274.

pianificazioneavvio-script

Configurazioni apparati della rete B.

Sulle sedi remote, nell’esempio “magazzino”, viene richiesta una macchina Linux con una interfaccia di rete. La configurazione che si andrà a predisporre è molto “leggera” e non richiede nessun intervento da parte dell’operatore. Nell’architettura VPN site-to-site routing, deve comunque essere rispettata la regola di non sovrapposizione di rete: i due segmenti di rete sono disgiunti, proprio come nel nostro esempio.

Il PC Linux deve avere come ruoli il routing, client PPTP e gateway principale della rete. Indico i pacchetti di “rito” da installare da una versione Linux CentOS 6.8 minimal e il pacchetto necessario per eseguire la funzione di PPTP client:

yum install -y nano telnet wget lynx bind-utils crontabs.noarch ntpdate dnsmasq sysstat nc sudo screen system-config-network-tui.noarch setuptool system-config-firewall-tui.noarch setup.noarch
yum install nano wget lynx telnet bind-utils
yum install dnsmasq
yum install -y compat-libstdc++-33 compat-glibc glibc-common glibc glibc-headers glibc-devel glibc-static glibc-utils
yum groupinstall “Development Tools”
yum install pptp

Una volta installato il software si passa alle parti di configurazione. In elenco files e relativa configurazione.

SELINUX

[root@gw ~]# cat /etc/selinux/config

# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
# enforcing – SELinux security policy is enforced.
# permissive – SELinux prints warnings instead of enforcing.
# disabled – No SELinux policy is loaded.
SELINUX=disabled
# SELINUXTYPE= can take one of these two values:
# targeted – Targeted processes are protected,
# mls – Multi Level Security protection.
SELINUXTYPE=targeted

SYSCTL.CONF

[root@gw ~]# cat /etc/sysctl.conf
# Kernel sysctl configuration file for Red Hat Linux
#
# For binary values, 0 is disabled, 1 is enabled. See sysctl(8) and
# sysctl.conf(5) for more details.
#
# Use ‘/sbin/sysctl -a’ to list all possible parameters.

# Controls IP packet forwarding
net.ipv4.ip_forward = 1

# Controls source route verification
net.ipv4.conf.default.rp_filter = 0

# Do not accept source routing
net.ipv4.conf.default.accept_source_route = 0

# Controls the System Request debugging functionality of the kernel
kernel.sysrq = 0

# Controls whether core dumps will append the PID to the core filename.
# Useful for debugging multi-threaded applications.
kernel.core_uses_pid = 1

# Controls the use of TCP syncookies
net.ipv4.tcp_syncookies = 1

# Controls the default maxmimum size of a mesage queue
kernel.msgmnb = 65536

# Controls the maximum size of a message, in bytes
kernel.msgmax = 65536

# Controls the maximum shared segment size, in bytes
kernel.shmmax = 4294967295

# Controls the maximum number of shared memory segments, in pages
kernel.shmall = 268435456

IP-UP.LOCAL (con permessi di esecuzione, chmod 755)

[root@gw ppp]# cat /etc/ppp/ip-up.local
#!/bin/bash

ip route add 192.168.0.0/24 dev ppp0

PPTPVPN

[root@gw peers]# cat /etc/ppp/peers/pptpvpn
pty “pptp <ip-pubblico-statico-rete-A> –nolaunchpppd”
lock
noauth
nobsdcomp
nodeflate
refuse-eap
refuse-pap
name magazzinovpn
password <password-utente-magazzinovpn-definito-in-ms-windows>
persist
remotename PPTP
require-mppe-128
ipparam pptpvpn

CON.SH (con permessi di esecuzione, chmod 755)

[root@gw peers]# cat /root/con.sh
#!/bin/bash
pppd call pptpvpn
sleep 10
iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE

RC.LOCAL

[root@gw peers]# cat /etc/rc.local
#!/bin/sh
#
# This script will be executed *after* all the other init scripts.
# You can put your own initialization stuff in here if you don’t
# want to do the full Sys V style init stuff.

/root/con.sh

touch /var/lock/subsys/local

Il client Linux creerà il tunnel VPN ed essendo il gateway della rete-B smisterà le chiamate pubbliche verso il router dell’operatore, mentre le chiamate con destinazione la rete-A verranno instradate nel tunnel VPN.

Se siete interessati a approfondimenti o valutazioni di scenari diversi potete contattarmi compilando il form al link http://www.abconsultinggroup.eu/contatti/index.php .

Open Source Email Platform – Zimbra Collaboration Open Source Edition

Zimbra offers an open source email platform  for the enterprise. Easily customize, extend and integrate Zimbra with line-of-business applications and organizational workflows.

Sorgente: Open Source Email Platform – Zimbra Collaboration Open Source Edition

CentOS 7 – PPTPD Vpn, how to

Accesso al sistema SSH da root e seguire i comandi di installazione librerie attraverso l’utility yum.

Installazione librerie PPTPD

# yum install ppp pptp pptp-setup
# rpm -Uvh https://dl.fedoraproject.org/pub/epel/7/x86_64/e/epel-release-7-5.noarch.rpm
# yum install ppp pptpd

Configurazione servizio PPTPD

# nano /etc/pptpd.conf

localip 10.0.0.15
remoteip 10.0.0.200-210

# nano /etc/ppp/chap-secrets

USERNAME pptpd PASSWORD *

# nano /etc/sysctl.conf

net.core.wmem_max = 12582912
net.core.rmem_max = 12582912
net.ipv4.tcp_rmem = 10240 87380 12582912
net.ipv4.tcp_wmem = 10240 87380 12582912
net.core.wmem_max = 12582912
net.core.rmem_max = 12582912
net.ipv4.tcp_rmem = 10240 87380 12582912
net.ipv4.tcp_wmem = 10240 87380 12582912
net.core.wmem_max = 12582912
net.core.rmem_max = 12582912
net.ipv4.tcp_rmem = 10240 87380 12582912
net.ipv4.tcp_wmem = 10240 87380 12582912
net.ipv4.ip_forward = 1

# sysctl -p
# systemctl enable pptpd
# systemctl start pptpd

Virus Cryptolocker – Ransomware – TeslaCrypt

Lo Studio AB Consulting Group SRLS con questo documento, vuole informare del rischio mondiale in corso, il più elevato numero di utenti possibili che operano quotidianamente con strumenti informatici. La minaccia a cui ci si sta riferendo ha il nome di “CryptoLocker” o “Ransomware”. Di seguito alcuni link di approfondimento:

https://it.wikipedia.org/wiki/CryptoLocker ,

https://it.wikipedia.org/wiki/Ransomware .

La modalità di attacco (sino ad ora misurata) di questo virus informatico è l’e-mail: vengono generate numerose e-mail con mittenze fasulle (ad es: Telecom, Agenzia delle Entrate, Ministero degli Interni, SDA, TNT e così via) con un allegato somigliante a un normale file .zip o file .pdf accompagnato da un nome circa “fattura”, “invoice”, “order number”, “conferma ordine”, “consegna”, “ritiro”. L’utente che riceve l’e-mail attraverso il proprio programma di posta elettronica (ad es: Windows Mail, Microsoft Outlook, Mozilla Thunderbird) apre (con un doppio click) l’allegato, e questo scatena (esegue) il programma malizioso virale. Il virus da quel doppio click svolge la sua attività distruttiva: in soli 10 secondi è in grado di criptare (rendere inutilizzabili) migliaia di files. I files che vengono attaccati sono tutti quelli presenti sul PC infettato e sulle cartelle di rete raggiungibili da quel PC sul server, danneggiando quindi tutti i documenti condivisi sul server. Questo produce un blocco esteso a tutta l’azienda (anche se il PC infetto è uno solo). Anche eliminando il virus dal PC infetto, i files rimangono illeggibili e inutilizzabili.

Tutti i sistemi informatici presentano vulnerabilità a questo tipo di virus. E’ ormai certo che questo virus verrà implementato nel tempo: produce un business agli hacker che diffondono e controllano queste chiavi di criptazione. Il virus propone sullo schermo del PC infettato un tariffa di ca. 3 bitcoin (ca. € 750,00 – € 1.000,00 , https://bitcoin.org/it/ , http://it.coinmill.com/BTC_EUR.html#BTC=3 ) come compenso per la soluzione. Questo tipo di virus è in grado di mutare velocemente e questo rende difficoltoso ai sistemi antivirus il processo di riconoscimento.

Attualmente non esiste “la contromisura” a questo sistema virale. Si può pensare di abbassare il rischio di contagio implementando strutture e servizi informatici che concorrono a evitare e risolvere incidenti distruttivi, nello specifico:

  • Formazione agli utenti nel riconoscere “fake e-mail”
  • Sistemi operativi di nuova generazione e aggiornati (Windows 7/8/10 Pro)
  • Posta elettronica affidata ai servizi Microsoft Exchange OnLine (Office 365)
  • Antivirus con servizi cloud (es: Symantec.cloud)
  • Scelta puntuale dei dati informatici da proteggere
  • Backup e monitoraggio quotidiano del backup aziendale (Acronis)

Questi 6 punti per la difesa da Cryptolocker rappresentano attualmente le uniche possibilità per rendere il rischio da contagio al minimo. Purtroppo la mutabilità della famiglia dei virus “Ransomware” non permette di sviluppare strategie e atteggiamenti definitivi e risolutivi. E’ certo che questo tipo di virus continuerà a essere implementato, perfezionato e distribuito sempre di più nel tempo.

VMWare ESXi 5.x – comandi utili da shell SSH per gestione virtual machines

Lista delle macchine virtuali presenti nell’host ESXi:
vim-cmd vmsvc/getallvms

Stato di una specifica macchina virtuale nell’host ESXi:
vim-cmd vmsvc/power.getstate VMID

Spegnimento in modalità SHUTDOWN di una macchina virtuale specifica nell’host ESXi:
vim-cmd vmsvc/power.shutdown VMID

Spegnimento forzato (modalità POWEROFF):
vim-cmd vmsvc/power.off VMID

Accensione di una macchina virtuale specifica nell’host ESXi:
vim-cmd vmsvc/power.on VMID

Configurazione postfix relay on smtp.gmail.com

E’ possibile configurare il servizio postfix presente nella propria rete LAN come SMTP interno e “rilanciare (relay)” il servizio di invio a un provider qualificato, ad esempio GMAIL.

0- requisiti

1- librerie necessarie per il relay verso GMAIL

2- configurazione postfix come SMTP di LAN

3- configurazione postfix per relay verso GMAIL

4- opzionale: relay verso più indirizzi

0- REQUISITI

Sistema operativo CentOS 6.x 64 bit

Connessione alla rete internet funzionante

Postfix installato come MTA di default

1- LIBRERIE

# yum install cyrus-sasl.x86_64 cyrus-sasl-devel.x86_64 cyrus-sasl-lib.x86_64 cyrus-sasl-md5.x86_64 cyrus-sasl-ntlm.x86_64 cyrus-sasl-plain.x86_64

2- Configurazione POSTFIX SMTP

# nano /etc/postfix/main.cf

inet_interfaces = localhost, <ip di rete del server>

mynetworks = 127.0.0.0/8, <x.y.z.t/aa rete LAN>

 3- Configurazione postfix come relay verso GMAIL

Creazione dell’account di autenticazione

# nano /etc/postfix/sasl_passwd

smtp.gmail.com     user@gmail.com:password

# cd /etc/postfix

# chmod 600 sasl_passwd

# postmap sasl_passwd

Aggiungere le seguenti linee di configurazione al file main.cf

# nano /etc/postfix/main.cf

relayhost = smtp.gmail.com

smtp_use_tls = yes

smtp_sasl_auth_enable = yes

smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd

smtp_sasl_security_options =

# /etc/init.d/postfix restart

4- Relay verso più indirizzi

Creazione dell’account di alias

# nano /etc/postfix/vmaps

lista@abconsulting.local <email1>@<dominio1>, <email2>@<dominio2>

Creazione del legame account sender e alias

# nano /etc/postfix/sender_bcc

<email_mittente>@<di notifica> lista@abconsulting.local

Applicazione delle nuove regole di lista

# postmap /etc/postfix/vmaps
# postmap /etc/postfix/sender_bcc
# nano /etc/postfix/main.cf

virtual_alias_maps = hash:/etc/postfix/vmaps
sender_bcc_maps = hash:/etc/postfix/sender_bcc

# /etc/init.d/postfix restart

NOTA. E’ possibile utilizzare indirizzi di destinazione anzichè di “from” lavorando con l’attributo
recipient_bcc_maps = hash:/etc/postfix/recipient_bcc dove all’interno del file recipient_bcc si trovano
le righe:

e-mail destinatario  lista@abconsulting.local

VMWare Zimbra 8 Multi-Domain, rilascio certificati self-signed per dominio

Questa rapida guida permette di generare certificati auto-firmati per la gestione di multi-dominio basati da virtualhost.
La procedura si sviluppa in tre punti: generazione del certificato dominio (virtualhost) e chiave privata, inserimento delle chiavi generate nel sistema VMWare Zimbra, rilascio del certificato.

– Accesso SSH con utente root sul sistema VMWare Zimbra
# mkdir /opt/certs
# cd /opt/certs
# openssl genrsa -out <virtualhost>.key 2048
# openssl req -new -x509 -key <virtualhost>.key -out <virtualhost>.cert -days 3650 -subj /CN=<virtualhost>

– Accesso alla console Admin del sistema VMWare Zimbra
– dal menu di DX: configura > domini > dominio con configurato <virtualhost> > certificato
– nell’area “Certificato dominio” inserire la chiave <virtualhost>.cert
– nell’area “Chiave privata dominio” inserire la chiave <virtualhost>.key

– Accesso SSH con utente root sul sistema VMWare Zimbra e lanciare il seguente comando su ogni nodo
# /opt/zimbra/libexec/zmdomaincertmgr deploycrts