Z-Push, Exchange ActiveSync (EAS) uyumlu istemcilerle posta ve groupware sistemleri arasında senkronizasyon sağlayan açık kaynak bir PHP uygulamasıdır. Veriyi kendisi posta kutusu olarak barındırmaz. Backend, Z-Push’ın veriyi tutan sunucuya bağlanmak için kullandığı bileşendir; desteklenen veri türleri bu bileşene göre değişir.
Resmi proje açıklaması birden fazla backend ile çalışmayı tanımlar. Bu, bütün cihazların veya sunucuların aynı işlevleri desteklediği anlamına gelmez. Uygunluk; Z-Push sürümü, backend, kimlik doğrulama yöntemi ve istemci bileşimiyle değerlendirilir.
ActiveSync için backend seçimi
Resmi yapılandırma dosyası, veri türleri için farklı backend’leri tanımlar:
| Backend | Kapsam |
|---|---|
BackendIMAP | IMAP sunucusundaki e-postalar |
BackendCalDAV | Sunucunun desteğine göre takvim ve görevler |
BackendCardDAV | Kişi verileri |
BackendCombined | Farklı veri türlerini uygun backend’lere yönlendirme |
Z-Push, Zimbra ile nasıl değerlendirilir?
Zimbra Collaboration ile kullanılacaksa seçilen bağlayıcı veya protokol yolu ayrıca doğrulanır. Eski bir üçüncü taraf bağlayıcının bulunması, güncel sunucuya güvenli ve desteklenen entegrasyon sağladığını göstermez.
Zimbra’nın kendi ActiveSync seçeneği ile Z-Push üzerinden bağlantı farklı işletim modelleridir. Seçilen Zimbra lisansının sunduğu erişim ile ayrı bir Z-Push/bağlayıcı katmanının bakım yükü birlikte karşılaştırılır. Pilot için aşağıdaki uyumluluk matrisi hazırlanabilir:
| Kontrol | Kabul kriteri |
|---|---|
| Sürüm bileşimi | Zimbra, Z-Push, PHP ve backend sürümleri kayıtlı; bağlayıcının bakım kaynağı belli. |
| Kimlik doğrulama | Kurumun parola/MFA politikasıyla uyum doğrulanmış; güvenlik politikası devre dışı bırakılmıyor. |
| E-posta | Alma, gönderme, klasör taşıma ve silme işlemleri iki tarafta tutarlı. |
| Takvim ve kişiler | Davet, yanıt, tekrarlayan etkinlik ve kişi değişiklikleri iki yönde test edilmiş. |
| İstemci | Kurumun kullandığı her cihaz/uygulama sürümü için sonuç ayrı kaydedilmiş. |
Bu kontroller tamamlanmadan “Zimbra ile uyumlu” ifadesi bütün cihazlar ve veri türleri için kullanılmamalıdır.
Tipik üretim mimarisi
Temel akış istemci → HTTPS → web sunucusu/PHP-FPM → Z-Push → backend → posta/groupware sunucusu şeklindedir. State deposu, hangi verinin istemciyle senkronize edildiği gibi durum bilgisini tutar; posta kutusunun kendisi değildir.
ActiveSync’in değişiklik bekleyen uzun süreli istekleri, reverse proxy ve PHP-FPM timeout’larıyla birlikte değerlendirilmelidir. Push davranışı ayrı bir dış bağlantıyla her cihaza anlık veri gönderildiği anlamına gelmez. IMAP IDLE da posta değişiklik bildirimleri sağlayabilir; ayrım yalnız “anlık veya periyodik” değildir.
Güvenlik ve kapasite
- HTTPS sertifika zincirini doğrulayın; backend bağlantısında TLS doğrulamasını hata çözmek için kapatmayın.
- Parola/kimlik doğrulama yolunun kurumun MFA ve erişim politikasıyla uyumunu pilotta inceleyin.
- Ayrıntılı logların mesaj ve kişisel veri içerebileceğini dikkate alın; debug kaydını sınırlı süre ve kullanıcıyla açın.
- Cihaz politikası uyumsuzluğunu provisioning’i kapatarak geçiştirmeyin; desteklenen istemci ve politika bileşimini seçin.
- PHP-FPM kapasitesini yalnız cihaz sayısıyla değil, etkin uzun bağlantı, bellek tüketimi ve backend gecikmesiyle ölçün.
State depolama ile IPC (Inter-Process Communication) aynı şey değildir. İncelenen yapılandırmada FILE/SQL state seçenekleri ve ayrı IPC ayarları vardır. Çok sunuculu kurulumda bu bileşenlerin tutarlılığı planlanmadan yalnız yük dengeleyici eklenmemelidir.
Yaygın sorunlar ve çözümler
| Belirti | Önce ne incelenir? |
|---|---|
| Posta geliyor, takvim gelmiyor | Backend veri türleri, endpoint ve yetkilendirme |
| 502/504 hatası | PHP-FPM hata kayıtları, timeout, worker doluluğu ve backend yanıt süresi |
| Cihaz sürekli tam senkronizasyon yapıyor | İstemci hataları, state erişimi, izinler ve sürüm uyumu |
| Yeni cihaz kayıt olamıyor | Kimlik doğrulama, sertifika ve cihaz politikası |
| Bazı öğeler eksik | İstemci filtreleri, senkronizasyon zaman aralığı ve veri dönüşüm hataları |
State verisini topluca silmek ilk çözüm değildir. Yeniden eşitleme yükü ve istemcide henüz sunucuya ulaşmamış değişiklikler değerlendirilmelidir. Gerekirse yedek ve kullanıcı onayıyla, ilgili sürümün yönetim araçları üzerinden dar kapsamlı işlem yapılır.
Pilot ve geri dönüş
Temsilî cihazlarda yeni posta, gönderim, klasör taşıma, takvim daveti, tekrarlayan etkinlik ve kişi düzenleme test edilir. Bir cihazın başarılı olması tüm istemci filosunun desteklendiğini kanıtlamaz.
Z-Push yapılandırması ve state verisi, posta/groupware sunucusundaki verinin yedeğinden ayrı korunur. Yükseltmede PHP ve bağlayıcı uyumu doğrulanır. Geri dönüşte eski state biçimine uyum ve cihazların yeniden eşitleme ihtiyacı planlanmalıdır.
