Hallo zusammen,
ich habe zarafa und z-push über das app-center aktualisiert. Jetzt kann ich mich nicht mehr über z-push auf den Server zugreifen.
Den einzigen Hinweis das etwas nicht stimmt gibt es in der Datei /var/log/apache2/error.log. Hier steht
File does not exist: /var/www/Microsoft-Server-ActiveSync
Ich habe z-push einmal deinstalliert und danach wieder installiert. Das hat nicht geholfen.
Woran kann es liegen, und was kann ich machen?
Mit freundlichen grüßen,
Thomas
Hallo Thomas,
gibt es denn einen Eintrag “z-push” unterhalb von “/etc/apache2/sites-enabled”? Falls dies nicht der Fall ist, kann dieser mittel einem “a2ensite z-push” leicht wiederhergestellt werden.
Hallo
gibt es nicht
[quote]
Falls dies nicht der Fall ist, kann dieser mittel einem “a2ensite z-push” leicht wiederhergestellt werden.[/quote]
Funktioniert wieder.
Vielen Dank.
Mit freundlichen grüßen,
Thomas
Hallo,
Beim mir war nach den Update der Eintrag auch nicht mehr vorhanden.
a2ensite z-push brachte ebenfalls die Lösung.
mfg
Stefan
Bei mir ebenfalls. Vielleicht ist ein Fehler im Update? Liest jemand von Zarafa hier mit?
Hallo,
nachdem ich heute sowieso einen unerwarteten Basteltag einlegen musste, habe ich schnell einen Snapshot erstellt und auch dieses Update getestet.
Unter “/etc/apache2/sites-enabled” hatte ich bereits nach dem Zarafa (nicht z-push) keinen Eintrag für “z-push”, trotzdem war
https://<ActiveSyncServerURL>/Microsoft-Server-ActiveSync zunächst noch problemlos erreichbar - bis zum Neustart der Server-Komponenten (logisch). Es kann also durchaus dauern, bis man den Fehler bemerkt.
Das Installieren des z-push Updates auf 2.2.2.1981 machte dann keinen Unterschied mehr bzw. legte die Links auch nicht an.
Ich glaube mich daran zu erinnern, dass das Updater-Skript erst letztens für Probleme gesorgt hatte. Etwas mehr QA würde sicherlich nicht schaden…
MBG,
TP
Hallo in die Runde,
ich habe mir gerade mal das postinst Skript angesehen und auch in meiner Testumgebung mal ein Update und eine Neuinstallation von Z-Push durchgeführt. Hier kann ich das beschriebene Verhalten leider nicht reproduzieren (der vhost ist immer da und aktiv).
Das klingt irgendwie sehr ungewöhnlich. Bei einem Zarafa Update wird der vHost von Z-Push nicht angefasst. Auch beim einem Update von 7.1.12 auf 7.1.13 ist der Z-Push vHost bei mir erhalten geblieben.
Ich habe meine Tests hier auf UCS 4.0-2/-3 durchgeführt. Auf welchen Versionen traten die Probleme bei euch auf?
Zunächst das Vorprogramm:
z-push vs d-push (aus /var/log/apt/history.log):
[code]Start-Date: 2015-08-23 16:07:57
Install: d-push:amd64 (2.0-1.1.8.201403190140, automatic)
Upgrade: zarafa:amd64 (7.1.12-48726, 7.1.13-51032), python-mapi:amd64 (7.1.12-48726, 7.1.13-51032), zarafa-webaccess-muc:amd64 (7.1.12-48726, 7.1.13-51032), zarafa-backup:amd64 (7.1.12-48726, 7.1.13-51032), zarafa-client:amd64 (7.1.12-48726, 7.1.13-51032), zarafa-ical:amd64 (7.1.12-48726, 7.1.13-51032), zarafa-dagent:amd64 (7.1.12-48726, 7.1.13-51032), zarafa-libarchiver:amd64 (7.1.12-48726, 7.1.13-51032), zarafa-common:amd64 (7.1.12-48726, 7.1.13-51032), zarafa-spooler:amd64 (7.1.12-48726, 7.1.13-51032), zarafa-libs:amd64 (7.1.12-48726, 7.1.13-51032), zarafa-licensed:amd64 (7.1.12-48726, 7.1.13-51032), zarafa-search:amd64 (7.1.12-48726, 7.1.13-51032), php5-mapi:amd64 (7.1.12-48726, 7.1.13-51032), zarafa-webaccess:amd64 (7.1.12-48726, 7.1.13-51032), zarafa-gateway:amd64 (7.1.12-48726, 7.1.13-51032), zarafa-server:amd64 (7.1.12-48726, 7.1.13-51032), zarafa-contacts:amd64 (7.1.12-48726, 7.1.13-51032), zarafa-monitor:amd64 (7.1.12-48726, 7.1.13-51032), zarafa-utils:amd64 (7.1.12-48726, 7.1.13-51032)
Remove: z-push:amd64 (2.2.1.1939)
End-Date: 2015-08-23 16:09:01
Start-Date: 2015-08-23 16:26:05
Install: z-push:amd64 (2.2.2.1981)
Remove: d-push:amd64 (2.0-1.1.8.201403190140)
End-Date: 2015-08-23 16:26:11
[/code]
Wobei das auch ein “red herring” sein kann.
Dieses System hatte jedenfalls noch eine “richtige” /etc/apache2/sites-available/z-push (von Februar 2014), keinen Symlink, da greift das Postinst nicht wie gewünscht und man kann Z-Push installieren wie man will. Solange die Überreste nicht beseitigt sind funktionierts nur mit Nacharbeit.
Hallo,
@fbartels: ich habe den Vorgang ganz stressfrei durchgeführt, jeder Schritt war nachvollziehbar. Allerdings kommt meine Installation noch von einer frühen 3.x mit einigen Updates von Zarafa.
Noch eine Novität, jetzt erhalte ich:
/etc/cron.daily/logrotate:
error: z-push.lr:1 duplicate log entry for /var/log/z-push/z-push-error.log
Das war ähnlich dem Problem, an das ich mich erinnert hatte: dort wurden die Rechte für eine der Log-Dateien falsch gesetzt. Hier wird wohl eher in verschiedenen Ordnern dieselbe Datei vorhanden sein?
MBG,
TP
Tka,
ich hab das Problem, das ich zwar den Betreff der Emails sehen kann, und auf meiner Android Wear Watch auch den Inhalt lesen kann. Aber sowohl auf einem OnePLus mit Cyanogen, als auch mit der Software Touchdown als auch auf einem Samsung Note 8.0 und einem Nexus 7. Die Emails werden dort nicht dargestellt, Weisser Adler auf weissen Grund.
Ich habe mit dem Z-Push admin die Geräte bereits einmal gelöscht und neu wieder hinzu gefügt, leider keine Besserung.
Auch ich hatte den von fbartels aufgeführten Eintrag im “apache site aviable” vom Februar 14.
Wäre schön wenn mir jemand einen Hinweis geben könnte wie ich das wieder hin biegen kann. Emails nur auf der Watch lesen ist etwas mist…
@dirk hm… mit dem letzen Update haben wir das Recommends für d-push aus dem zarafa4ucs Paket genommen. Eigentlich hätte dies aber schon mit dem Wechsel d-push -> z-push über ein transitionalpackage von deinem System entfernt worden sein (oder zumindest entschärft).
@the preacher
hast du zufällig mal eine eigene Logrotate Definition für Z-Push hinterlegt? Sofern eine solche Datei über dpkg angelegt wurde, sollte sie eigentlich auch beim Upgrade/Deinstallation hiervon entfernt werden.
@volker.grabbe
Aber bekommen die Android Wear Devices nicht vom Android Telefon überhaupt ihre Elemente? Also wenn das Telefon eine Mail defekt anzeigt, sollte auch die Uhr das falsch anzeigen. Ich würde dir Testweise ein Downgrade (inkl. resync) auf 2.2.1 empfehlen. Sollte es dann wieder gehen würde vermutlich ein wbxml (einmal 2.2.2, einmal 2.2.1) helfen. Dies solltest du dann direkt im Zarafa Forum posten, da dort auch die Z-Push Entwickler mitlesen.
Hallo,
[quote]@the preacher
hast du zufällig mal eine eigene Logrotate Definition für Z-Push hinterlegt? Sofern eine solche Datei über dpkg angelegt wurde, sollte sie eigentlich auch beim Upgrade/Deinstallation hiervon entfernt werden.[/quote]
Wie hier: [url]Logrotatet für z-push funktioniert nicht mehr] zu lesen, waren die Berechtigungen nach dem letzten Update von z-push für “/etc/logrotate.d/z-push” von 644 auf 664 gesetzt.
Ich vermute, dass dies bei Einigen heute noch so ist, und nicht auffällt, solange die Partition nicht überläuft.
Genauso wie die Meldung von root bezüglich “/etc/cron.daily/logrotate” - diese wird wohl selten zugestellt werden.
“z-push.lr” wurde jedenfalls mit diesem Update generiert (timestamp), während “z-push.dpkg-dist” noch vom letzten Update (März 2015) stammt.
Da ist wohl eine kleine Aufräumaktion angesagt, welche Löschungen bewahren denn die Kompatibilität mit weiteren Updates? Ich vermute, die beiden alten sind zu löschen, während “z-push.lr” einfach in “z-push” umzubenennen ist.
Wobei der Inhalt ja bekanntlich derselbe ist. 
MBG,
TP
Hallo TP,
dpkg-dist Dateien werden vom Debian Paketmanager erstellt, wenn eine Datei als Konfigdatei markiert ist (welche die Logrotate Datei ist). Diese können für gewöhnlich im Dateisystem verbleiben (auch wenn man die Änderungen zu einem beliebigen Zeitpunkt generell mergen sollte). Die Logrotate Datei, die auch in Zukunft bestehen bleiben wird ist die z-push.lr (mit anderen Worten, wenn du diese umbenennst wirst du mit dem nächsten Update einen neuen Konflikt haben).
[quote=“fbartels”]Hallo TP,
… Die Logrotate Datei, die auch in Zukunft bestehen bleiben wird ist die z-push.lr (mit anderen Worten, wenn du diese umbenennst wirst du mit dem nächsten Update einen neuen Konflikt haben).[/quote]
Danke! So werde ich das durchführen!
MBG,
TP
Hallo allerseits,
bei mir ist auch Z-Push nicht mehr erreichbar gewesen, nachdem ich gestern Abend ein Upgrade von Z-Push und anschließend von Zarafa durchgeführt habe. Das ganze auf UCS 4.0-3.
upgrade z-push:all 2.2.1.1939 2.2.2.1981
upgrade zarafa:all 7.1.12-49411 7.1.13-51032
Ich habe zuerst Z-Push upgegradet und dann die Verbindung per Smartphone getestet. Alles ok. Danach Zarafa upgegradet und nur per Webapp getestet. Den Test per Smartphone hatte ich danach ausgelassen. Erst heute morgen ist aufgefallen, dass z-push nicht funktioniert.
Der Hinweis von fbartels den nicht mehr vorhanden “/etc/apache2/sites-enabled/z-psuh” durch “a2ensite z-push” wieder herzustellen, hat mir geholfen.
Entweder hat das Verschwinden bei sites-enabled mit dem Upgrade von Zarafa zu tun oder es verschwindet vorher schon und erst mit dem Upgrade von Zarafa wird der Apache neu geladen.
Gruß,
Peter
Hi,
bei mir ist das Problem auch aufgetaucht, Update vorgestern abend auf aktuelle Zarafa und Z-Push Version. Nach dem Update war das Z-Push Verzeichnis nicht mehr vorhanden. Obiges Kommando durchgeführt, Z-Push Verzeichnis wieder da aber Email Abfrage von Android/iOS per Active Sync funktioniert trotzdem nicht mehr. Bei iOS funktioniert die Verbindung zum z-push zwar wieder aber es werden keine Emails angezeigt. Die Ordnerstruktur wird erstaunlicherweise angezeigt.
Irgendeine Idee?
Gerd
scheint sich nach einem Tag abwarten erledigt zu haben.
Auf zwei Geräten musste ich den Account neu anlegen, auf anderen hat es “einfach so” wieder funktioniert…
hmm… merkwürdig. Eventuell eine Instanz dazwischen gehabt, die den alten Fehler im Cache gehalten hat?
Bei mir wurde beim Upgrade das Paket z-push durch das Paket d-push ersetzt und es kamen keine Verbindungen mehr zu zustande. Eine Installation von Z-Push über die Weboberfläche hat das d-push wieder entfernt und z-push installiert. Anscheinend liegt da ein Konflikt vor.
Mit dem nächsten Update des Zarafa4ucs Paketes wird die Abhängigkeit auf d-push entfernt. Mir ist aber nicht wirklich klar, woher das Paket kommt, das ist in den aktuellen Repos afaik nicht mehr enthalten und dürft daher nicht installiert werden. Ist unmaintained eventuell aktiv?