[gelöst] E-Porto Plugin Deutsche Post Libre Office Problem

Hallo zusammen,

hat irgend jemand Erfahrung mit dem E-Porto Plugin von der Deutschen Post ( http://www.deutschepost.de/dpag?xmlFile=link1022607_1022369 ) Damit kann man die "Internetbriefmarke" direkt ins Adressfenster placieren. Theoretisch jedenfalls.

Wenn ich das Porto "anfordere" kommt die Fehlermeldung "Bitte stellen Sie Ihre Systemzeit richtig ein. Sie darf nicht mehr als drei Minuten abweichen (03030060)"

Meine Systemzeit ist aber korrekt: UTC über NTP Server.

Fragt mich bitte nicht warum die Post für eine Briefmarke die Systemzeit mit ihrem Server abgleichen will...

Im Netz bin ich auch nicht wirklich weiter gekommen - hab nur gefunden, dass auch Ubuntu-User zwar dieses Problem, aber auch keine Lösung haben (siehe: http://forum.ubuntuusers.de/to…office-open/#post-4966272 )

Bin für jeden Tipp/Rat dankbar.

Ach ja - gutes neues Jahr noch!!!
Moritz

Hi Boser,

erst mal danke für die rasche Antwort. Das hab ich schon versucht und die Systemzeit via Yast manuell eingestellt und UTC sowie NTP-Server deaktiviert. Die Meldung kommt (leider) trotzdem.

Und den Zeitabgleich versteh ich trotz der wasserdichten Sicherheit nicht. Denn wenn ich eine Internetmarke ohne Writer abrufe bekomme ich sie auch ohne den Zeitabgleich.

Innerhalb von drei Minuten. Definitiv. Unabhängig davon kommt die Fehlermeldung auch, wenn man sich über das Plugin in seinen Account bzw. die Portokasse einloggen will. Also muss ich es irgendwie schaffen, meine Systemzeit auf die MET einzustellen, ich glaub nämlich nicht, dass die Post auf UTC umstellt

Und hier liegt der Hase im Pfeffer. Meine Systemzeit ist eben UTC+1 Stunde. Wie kann ich das ändern? Und so wie ich gegoogelt hab, spielt Java auch noch ne Rolle.

Ganz schön viel Schwachsinn zu lesen, für so einen kurzen Thread.

Dein Problem mit den Briefmarken kann ich nicht beurteilen. (Ich mache sowas nicht).
Aber ein wenig zur Zeit:

Das schlichte NTP Protocol ist gar nicht schlicht.
Es geht darum, jedem Rechner die ganz exakte Uhrzeit mitzuteilen.
Das ist schwierig. Sehr viel schwieriger, als man es sich gemeinhin vorstellt.
Der Rechner frägt dazu über das Netz einen "Zeitserver". Die Netzwerkpakete müssen gesendet, dann auf der anderen Seite empfangen und verarbeitet werden. Und das Ergebniss muss zurückgesendet werden.
Es liegt in der Natur der Protocolsuite TCP/IP, dass Verbindungen eben __GENAU NICHT__ zu festgelegten Zeiten mit festgelegten Laufzeiten im typisch deutschen Gleichschritt marschiert werden.
Für unser Problem tun sie das anarchisch und nicht vorhersehbar und vor allem: mit völlig unterschiedlichen Laufzeiten.
Reden wir von NTP, so reden wir von einer Genauigkeit, die in der Größenordnung von 0,2 Nanosekunden (in Worten: Nullkommazwei Nanosekunden) liegt.
Die Laufzeit von UDP Paketen ist da also sehr, sehr einflussreich. (Beachte bei einem Ping die Laufzeiten!)

Wie NTP ganz grob funktioniert:
Um ein Zeitsignal zu erhalten, muss irgendwo ein Server eine Vorrichtung haben, um die korrekte Uhrzeit zu empfangen.
Meist ein Server mit einem DCF77 Empfänger. (Segler verwenden gerne Loran, und jeder hat irgendein GPS, das auch Zeitstempel liefern kann. DCF77 selbst ist ein spezialisierter Zeitsignalempfänger. Also ein Stück Hardware mit Antenne)

An einem solchen Server, der eine verlässliche Zeitquelle angeschlossen hat, können sich andere REchner ihre Uhrzeit holen. Man nennt ihn im NTP Jargon "Stratum 0". Alle Server, die sich von diesem Server die Zeit holen, sind sekundär, und wir wir sagen, sie liegen im "Stratum 1". Und so weiter....
Jeder Rechner, der Zeitsignale weitergibt, ist ein NTP-Server UND gleichzeitig Client eines Servers, der eine Stratumebene höher liegt.

Im NTP Protocol ist nun festgelegt, dass jeder Zeitserver beständig sich mit dem "höherem" Zeitserver synchronisiert UND mit allen anderen Servern, die im gleichen Stratum liegen.
Ratzfatz ist unser einfaches Zeitsynchronisieren eine hochkomplexe Angelegenheit.
Sensibel reagieren sie schon auf Laufzeitunterschiede.

Weil das alles ziemlich komplex ist, sind auch einige Grenzen definiert.
Eine davon ist: Weicht die lokale Uhr eines Rechners, der durch NTP kontrolliert wird, mehr als drei Sekunden ab, wird gar nicht mehr synchronisiert.
(Wenn wir von 0,2 Nanosekunden reden, sind 3 Sekunden ganz schön lang)
Woher soll das Protocol wissen, ob nicht ein NASA Fuzzi seinen Rechner absichtlich auf Marszeit getrimmt hat, weil er pünktlich Curiosity ärgern will?)

Und die von der Lost (kein Rechtschreibfehler) angegebene Zeit, ist genau diese Grenze in NTP Protocol.

Wenn man sich nun klar macht, dass in vielen kryptischen Kryptographieverfahren die lokale Zeit miteingeht, wird es leicht vorstellbar, dass die Lostler einen ähnlichen Algortihmus einsetzen, der dann halt nicht mehr die gewünschten Übereinstimmungen liefern kann, die sie vorsehen.
Kodiere ich bei der Portoübermitllung einen Zeitstempel, der auf 0,2 Sekunden genau ist, kann ich leicht viele "gleichzeitig" ablaufende Verkäufe von Porto sauber tracken, Weichen die Zeiten zu weit ab, wird die Zordnung nicht mehr eindeutig möglich sein.
Ohne es zu wissen, schiebe ich die geforderte Minimalabweichung der Zeit auf diese Tatsache.

Es ist also völlig egal, ob der Rechner mit UTC oder irgendeinem GMT+/-x läuft. (Es gibt kein modernes OS, das nicht mit beiden Zeiteinstellungen zurechtkäme.)

Hallo Uhelp,

vielen Dank für die ausführliche Erklärung. Ich glaub, ich habs auch einigermaßen verstanden. Was ich nicht verstehe ist aber, dass das Problem verschwindet, sobald eine andere Java-Version zum Einsatz kommt. Sag jetzt bitte nicht "dann nimm halt diese" - die Version 1.7.0 sorgt dann für andere Probs. Aber das ist (wohl) ein anderes Thema. - siehe

CPU Auslastung openjdk 1.7.0 LibreOffice

Gruß
Moritz

Also, das Problem wurde wie folgt gelöst

openjdk6jre (1.6.0) löschen

und durch SUN Java 7 von

http://download.opensuse.org/repositories/Java:/sun:/Factory/openSUSE_12.1/

ersetzen.

Danke an Trekki00, Sauerland und Co!