Zimbra Güncelleme ve Sürüm Yükseltme Rehberi

Zimbra’yı güncellemek, özellikle major sürüm atlamalarında, herkesi biraz tedirgin eden o klasik “acaba ne patlar?” anının yaşandığı süreçlerden biridir. Yıllar içinde onlarca Zimbra kurulumunda güncelleme yaptım ve her seferinde aynı dersi öğrendim: hazırlık, güncellemenin kendisinden daha önemlidir. Bu yazıda hem minor hem de major sürüm yükseltmelerini, gerçek dünyada yaşanan sorunlarla birlikte ele alacağım.

Neden Bu Kadar Dikkatli Olmak Gerekiyor?

Zimbra, monolitik bir yapıya sahip. Yani LDAP, MTA, web sunucu, antivirüs, veritabanı gibi bileşenler tek bir çatı altında çalışıyor. Bu entegrasyon bir yanda kolaylık sağlarken, öte yanda bir şeyin yanlış gitmesi halinde tüm mail akışını durma noktasına getirebilir. 500 kullanıcılı bir kurumda mail’in bir saatliğine durması bile ciddi iş kayıplarına yol açabiliyor.

Dolayısıyla güncelleme sürecini “indirip çalıştırırım, ne olacak ki” şeklinde ele almak, ilerleyen dönemde bedelini ağır ödeyeceğiniz bir yaklaşımdır.

Güncelleme Öncesi Hazırlık

Ortam Bilgilerini Kayıt Altına Alın

Güncellemeye başlamadan önce mevcut durumu belgelemek şarttır. Bu hem geri dönüş senaryolarında hem de sorun giderme aşamasında hayat kurtarır.

# Zimbra versiyon bilgisi
su - zimbra -c "zmcontrol version"

# Tüm servislerin durumu
su - zimbra -c "zmcontrol status"

# Zimbra hostname ve domain bilgileri
su - zimbra -c "zmprov gacf | grep -i 'zimbramail|zimbraldap|zimbradefault'"

# Disk kullanımı - güncelleme öncesi mutlaka kontrol
df -hT
du -sh /opt/zimbra/

Özellikle disk durumunu kontrol etmeyi atlamamanızı öneririm. Güncelleme paketi açılırken ve kurulum sırasında /opt/zimbra altında ciddi miktarda geçici alan kullanılabiliyor. Yeterli alan yoksa kurulum yarıda kesilebiliyor ve sistemi tutarsız bir durumda bırakabiliyor.

Yedek Almak: Gerçek Yedek

“Yedek aldım” diyip sadece /opt/zimbra dizinini tarlayanları görüyorum sık sık. Oysa Zimbra için kapsamlı yedek birden fazla katmanı kapsamalıdır.

# Zimbra servislerini durdurun
su - zimbra -c "zmcontrol stop"

# Tam dizin yedeği (sistem dışı bir diske alın)
tar -czpf /mnt/backup/zimbra_pre_upgrade_$(date +%Y%m%d).tar.gz /opt/zimbra/

# LDAP yedeği - ayrıca alın, kritik
su - zimbra -c "zmlocalconfig -s zimbra_ldap_password"
su - zimbra -c "ldap start"
su - zimbra -c "/opt/zimbra/libexec/zmslapcat /tmp/ldap_backup_$(date +%Y%m%d).ldif"

# Konfigürasyon yedeği
su - zimbra -c "zmprov getAllConfig > /tmp/zimbra_config_$(date +%Y%m%d).txt"

# Servisler yeniden başlatın
su - zimbra -c "zmcontrol start"

Eğer sanallaştırma ortamında çalışıyorsanız (VMware, KVM vb.), güncelleme öncesinde VM snapshot’ı almak en pratik geri dönüş yöntemidir. Snapshot aldıktan sonra bile yukarıdaki Zimbra özelinde yedekleri almayı ihmal etmeyin zira snapshot her zaman tutarlı bir uygulama durumunu garantilemez.

Sürüm Yükseltme Yolunu Belirleyin

Zimbra’da sürüm atlaması doğrudan yapılamıyor. Örneğin 8.6’dan direkt 8.8.15’e geçemiyorsunuz, ya da 8.x’den 9.x’e. Desteklenen yükseltme yollarını Zimbra Wiki’den kontrol etmek zorundasınız.

Genel kural şudur:

• Minor güncellemeler (8.8.10 -> 8.8.15 gibi): Genellikle doğrudan yapılabilir
• Major sürüm atlamaları (8.x -> 9.x ya da 9.x -> 10.x): Ara sürümlerden geçmek gerekebilir
• İşletim sistemi değişiklikleri: CentOS 7 üzerindeki Zimbra’yı Ubuntu’ya taşıyorsanız bu ayrı bir migrasyon sürecidir, güncelleme değil

Minor Güncelleme (Patch) Uygulaması

Patch güncellemeleri görece az risklidir ama yine de dikkatli olmak gerekir.

# İndirilen paketi doğrulayın - hash kontrolü yapın
sha256sum zcs-8.8.15_GA_4179.RHEL7_64.20211118033954.tgz

# Paketi uygun dizine çıkarın
mkdir -p /tmp/zimbra_upgrade
tar -xzf zcs-8.8.15_GA_4179.RHEL7_64.20211118033954.tgz -C /tmp/zimbra_upgrade/
cd /tmp/zimbra_upgrade/zcs-8.8.15_GA_4179.RHEL7_64.20211118033954/

# Kurulum betiğini çalıştırın
./install.sh

Kurulum sırasında birkaç kritik soru sorulacak. “Do you wish to upgrade?” sorusuna evet derken hangi bileşenlerin güncelleneceğini dikkatle okuyun. Bazı durumlarda kurulum betiği yeni bileşenler kurmak isteyebilir, bunları kurumunuzun ihtiyacına göre değerlendirin.

Güncelleme tamamlandıktan sonra doğrulama adımlarını atlamayın:

# Versiyon kontrolü
su - zimbra -c "zmcontrol version"

# Servis durumu
su - zimbra -c "zmcontrol status"

# Mail akışı testi - bir test maili gönderin ve alın
su - zimbra -c "echo 'Test maili' | sendmail [email protected]"

# Log takibi
tail -f /opt/zimbra/log/mailbox.log

Major Sürüm Yükseltmesi: 8.x’den 9.x’e

Bu, asıl dikkat gerektiren kısım. Zimbra 8.8.15’den Zimbra 9.x’e yükseltme yapacaksanız, süreç biraz daha uzun ve karmaşıktır.

Ön Koşulları Kontrol Edin

# İşletim sistemi versiyonu
cat /etc/os-release

# Java versiyonu (Zimbra 9 için Java 11 gerekebilir)
su - zimbra -c "java -version"

# Sistem kaynaklarını kontrol edin
free -h
nproc
ulimit -n

# Açık dosya limitlerini kontrol edin
su - zimbra -c "ulimit -n"

Zimbra 9 ve 10, daha yüksek ulimit değerleri gerektiriyor. Eğer open files limiti 10000’in altındaysa kurulum sonrası servis sorunları yaşarsınız.

# /etc/security/limits.conf dosyasına ekleyin
cat >> /etc/security/limits.conf << 'EOF'
zimbra soft nofile 524288
zimbra hard nofile 524288
zimbra soft nproc 65535
zimbra hard nproc 65535
EOF

Yükseltme Öncesi LDAP Kontrolü

LDAP sağlığı, major yükseltmelerde en kritik faktördür. Yükseltme sonrası LDAP sorunları yaşarsanız kullanıcılar mail kutularına erişemez.

# LDAP durumu
su - zimbra -c "ldap status"

# LDAP replikasyon durumu (multi-server kurulumda)
su - zimbra -c "zmprov gsi | grep -i ldap"

# LDAP veritabanı bütünlük kontrolü
su - zimbra -c "/opt/zimbra/common/sbin/slapcat -n 2 | wc -l"

Yükseltme İşlemi

# Paketi indirip doğruladıktan sonra
cd /tmp/zimbra_upgrade/zcs-RHEL7_64-9.0.0_GA/

# Güncelleme için -u parametresi ile çalıştırmayın, normal install.sh yeterli
# Betik mevcut kurulumu tespit edip upgrade modunda çalışır
./install.sh

# Kurulum sırasında şu soruya dikkat edin:
# "Do you want to upgrade existing installation?" -> Y
# "Do you want to install zimbra-store?" -> Mevcut bileşenlerinize göre yanıt verin

Yükseltme tamamlandıktan sonra veritabanı migration adımları otomatik başlamalıdır. Bu süreç posta kutusu sayısına bağlı olarak 30 dakikadan birkaç saate kadar sürebilir. Sabırsızlanıp işlemi kesmeyin.

# Migration durumunu takip edin
tail -f /tmp/zmsetup.log
tail -f /opt/zimbra/log/zmmailboxd.out

Çok Sunuculu (Multi-Server) Ortamlarda Güncelleme

Eğer Zimbra’yı birden fazla sunucuya dağıtık kurduysanız, güncelleme sırası kritik önem taşır.

Doğru sıralama şöyledir:

• 1. Adım: LDAP master sunucusunu güncelleyin
• 2. Adım: LDAP replica sunucularını güncelleyin
• 3. Adım: MTA sunucularını güncelleyin
• 4. Adım: Mailbox (store) sunucularını güncelleyin
• 5. Adım: Proxy sunucularını güncelleyin

Bu sırayı bozmak, özellikle LDAP schema uyumsuzluklarına yol açabilir ve tüm cluster’ı kullanılamaz hale getirebilir.

# Her sunucu güncellemesi sonrasında şu kontrolü yapın
su - zimbra -c "zmcontrol status"
su - zimbra -c "zmhostname"
su - zimbra -c "zmprov gs $(zmhostname) zimbraServiceEnabled"

Sık Karşılaşılan Sorunlar ve Çözümleri

Sorun 1: Güncelleme Sonrası Servisler Başlamıyor

Bu genellikle permissions sorunudur. Güncelleme betiği bazen dosya sahipliklerini karıştırabilir.

# Dosya sahipliği düzeltme
chown -R zimbra:zimbra /opt/zimbra/

# Gerekli izinleri yeniden uygulama
su - zimbra -c "/opt/zimbra/libexec/zmfixperms"

# Sonrasında servisleri yeniden başlatın
su - zimbra -c "zmcontrol stop"
su - zimbra -c "zmcontrol start"

Sorun 2: Postfix Konfigürasyonu Sıfırlandı

Major güncellemelerde Postfix konfigürasyonunuzun üzerine yazılabilir. Özellikle özel relay ayarları, TLS konfigürasyonları etkilenebilir.

# Mevcut postfix main.cf'i kontrol edin
postconf -n

# Zimbra'nın postfix konfigürasyonunu yeniden oluşturmasını sağlayın
su - zimbra -c "zmmtactl stop"
su - zimbra -c "postfix check"
su - zimbra -c "zmmtactl start"

# Özel relay host ayarlarını yeniden uygulayın
su - zimbra -c "zmprov ms $(zmhostname) zimbraSmtpHostname relay.example.com"

Sorun 3: Web Arayüzü Açılmıyor (Jetty/Mailboxd Sorunu)

# Mailboxd log'larını inceleyin
tail -100 /opt/zimbra/log/zmmailboxd.out
tail -100 /opt/zimbra/log/mailbox.log

# Java heap space sorunları için
su - zimbra -c "zmlocalconfig -e mailboxd_java_heap_size=1024"

# Mailboxd'yi yeniden başlatın
su - zimbra -c "zmmailboxdctl restart"

Sorun 4: SSL Sertifika Sorunları

Güncelleme sonrasında self-signed ya da özel sertifikanızın yeniden uygulanması gerekebilir.

# Mevcut sertifika bilgilerini kontrol edin
su - zimbra -c "zmcertmgr viewdeployedcrt"

# Sertifikayı yeniden deploy edin
su - zimbra -c "zmcertmgr deploycrt self"
# Ya da özel sertifika için:
su - zimbra -c "zmcertmgr deploycrt comm /tmp/commercial.crt /tmp/commercial_ca.crt"

# Nginx'i yeniden başlatın
su - zimbra -c "zmproxyctl restart"

Güncelleme Sonrası Doğrulama Kontrol Listesi

Güncelleme tamamlandıktan sonra şu adımları sırayla uygulayın:

# 1. Versiyon ve servis durumu
su - zimbra -c "zmcontrol version"
su - zimbra -c "zmcontrol status"

# 2. Mail gönderme ve alma testi
su - zimbra -c "echo 'Güncelleme sonrası test' | mail -s 'Test' [email protected]"

# 3. Mail kuyruğu durumu
su - zimbra -c "mailq | tail -5"

# 4. Antispam ve antivirüs
su - zimbra -c "zmamavisdctl status"
su - zimbra -c "zmantispamctl status"

# 5. Log hatası kontrolü
grep -i "ERROR|FATAL|Exception" /opt/zimbra/log/mailbox.log | tail -50
grep -i "error|warn" /opt/zimbra/log/zimbra.log | tail -50

# 6. LDAP sağlığı
su - zimbra -c "ldap status"
su - zimbra -c "zmprov gam | wc -l"

Geri Alma (Rollback) Planı

Her güncelleme planında rollback senaryosu önceden düşünülmüş olmalıdır. Eğer snapshot aldıysanız iş basit: VM’i snapshot’a döndürün. Ama snapshot yoksa:

# Servisleri durdurun
su - zimbra -c "zmcontrol stop"
pkill -u zimbra

# Zimbra dizinini yedekten geri yükleyin
mv /opt/zimbra /opt/zimbra_failed_upgrade
tar -xzpf /mnt/backup/zimbra_pre_upgrade_20240115.tar.gz -C /

# Servisleri başlatın
su - zimbra -c "zmcontrol start"

Bu süreç oldukça ağır bir operasyondur ve her zaman %100 başarılı olmayabilir, özellikle arada veritabanı değişiklikleri yaşandıysa. Bu yüzden en sağlıklı geri dönüş yöntemi her zaman VM snapshot’ıdır.

Bakım Penceresi Planlaması

Gerçekçi konuşmak gerekirse, Zimbra güncellemelerini mesai saatlerinde yapmak kullanıcılar üzerinde ciddi baskı oluşturur. Deneyimlerime dayanarak şu zaman planını öneriyorum:

• Cuma 23:00: Yedeklerin alınması ve son kontroller
• Cumartesi 00:00: Servislerin durdurulması ve güncelleme başlangıcı
• Cumartesi 02:00-04:00: Güncelleme ve doğrulama (minor için 1 saat, major için 3-4 saat ayırın)
• Cumartesi sabah: Pilot kullanıcılarla test
• Pazartesi: Tüm kullanıcılara duyuru ve normal operasyon

Mail servisi için kabul edilebilir maksimum kesinti süresi kurumdan kuruma değişir ama çoğu yerde bu süre 4 saatin altında tutulmalıdır. Major güncellemelerde bu süreyi sıkı tutmak için önceden test ortamında mutlaka bir prova yapın.

Test Ortamının Önemi

Üretim ortamında direkt güncelleme yapmak, paşa kumarda koz kullanmak gibidir. Eğer elinizde bir test Zimbra ortamı yoksa, güncellemeyi yapmadan önce mevcut üretim Zimbra’nın bir kopyasını sanal makineye alın ve güncellemeyi önce orada test edin.

Bu test ortamında şunları doğrulayın:

• Kurulum hatasız tamamlanıyor mu?
• Mail gönderme ve alma çalışıyor mu?
• Web arayüzü ve ActiveSync düzgün çalışıyor mu?
• Mevcut özelleştirmeleriniz (signatures, zimlets vb.) korunuyor mu?
• Tahmini güncelleme süresi ne kadar?

Sadece bu adım bile üretim ortamında yaşanabilecek pek çok sürprizin önüne geçer.

Sonuç

Zimbra güncellemeleri, doğru hazırlıkla yapıldığında oldukça sorunsuz geçebilir. Paniği yaratan çoğu durum aslında önceden öngörülebilir ve önlenebilir şeylerdir. Yedek almak, disk alanını kontrol etmek, LDAP sağlığını doğrulamak ve multi-server ortamlarda doğru sırayı takip etmek, işin %80’ini oluşturuyor.

Major sürüm atlamalarında sabırsız davranmamak önemli. Veritabanı migration’ları uzun sürebilir ve bu süreçte sisteme müdahale etmek durumu daha da kötüleştirebilir. Log’ları takip edin, sabırla bekleyin.

Son olarak, her güncelleme sonrasında öğrendiklerinizi belgeleyin. Hangi sorunla karşılaştınız, nasıl çözdünüz, ne kadar sürdü? Bu notlar hem sizin için hem de ekibinizdeki diğer sistem yöneticileri için gelecekteki güncellemelerde değerli bir referans kaynağı olacaktır.