Beiträge von nordtech

Moin zusammen,

ich hatte bisher nur in diesem Zusammenhang mit dem Verzeichnis "temp" im Archive von Usern (\\server\David\Archive\USER\xxxxxxxx\temp) zu tun. Das Verzeichnis scheint ulkigerweise nicht bei allen Usern zu existieren, und es taucht nicht als Archive im David-Client auf (die Aussage hier ist wohl fehlerhaft). Offenbar also ein Systemverzeichnis, in dem David Dinge tut.

Hintergrund der Anfrage ist, dass bei einem Kunden auffiel, dass sich in diesen temp-Verzeichnissen mitunter größere Datenmengen anhäufen: Da liegen PDFs, Grafiken, teilweise auch ganze Ordner. Viele relativ aktuell, manche schon Jahre alt.

Bei unserer hauseigenen Installation sind alle temp-Ordner leer. Daher tun wir uns gerade etwas schwer, das zuzuordnen. Auf den ersten Blick würde ich aber sagen, es handelt sich um Anhänge, die entweder versendet oder empfangen wurden. Die Frage ist natürlich, ob man die einfach weglöschen kann, denn im Einzelfall ist der Platzbedarf schon erheblich.

Habt ihr diesbezüglich Ideen? Eine Foren-Suche brachte leider nichts zutage.

Bei ca. 20% unserer Kunden war heute morgen ebenfalls der SL inaktiv. Ließ sich aber manuell anstoßen.

Über Nacht war bei vielen ein "hotfix 358701" installiert worden. Ich hab' leider keine Ahnung, was es damit auf sich hat, auf unserem eigenen Server ist dieser Hotfix bislang nicht eingetroffen.

Die Meldungen liegen auch noch einmal im Archiv "System -> David -> Ereignisse". Da kann man direkt erkennen, welches Konto den Fehler wirft.

OK, also irgend eine Art von Schluckauf gab es - das Problem war bei Tobit bekannt ("wir sind an dem Thema dran"), gestern Abend kam dann aber via Chat die Nachricht, dass es nun nicht mehr auftreten sollte.

Wir hängen immer noch mit obiger Fehlermeldung fest und bekommen wegen des "RateLimit reached" kein neues Zertifikat ausgestellt. Werden mal ein paar Tage abwarten. Bei den Kunden gibt es zum Glück keine derartigen Auffälligkeiten.

Zitat von riawie

übernimmt man gewisse Einstellungen ja gern auf alle von einem betreuten und hinreichend ähnlichen Systeme

Könnte aber natürlich auch ein Problem mit einem gemeinsamen Upstream gelegenen Provider sein...

"Leider" nicht, ich habe zum Testen extra den Kunden ausgewählt, der von uns geographisch am weitesten entfernt sitzt. Anderer Provider, anderer Router (beim Kunden nur eine simple Fritz!Box ohne besondere Firewall-Beschränkungen), anderer Subdomain-Host (einmal dyndns, einmal A-Record auf feste IP). Außer einer weitgehend identischen David-Installation kann ich derzeit keine potenziell Problem-verursachende Übereinstimmungen erkennen.

Aber du hast natürlich Recht, bei Let's Encrypt selbst gibt es keine Störungsmeldungen und auch keine passenden neuen Einträge im Forum. Wäre schon seltsam, wenn eine Störung bei so einem großen Dienst nicht auch anderen Benutzern auffällt.

Für heute ist eh erstmal Pause angesagt:

Error: Error order certificate

StatusCode: 500

Description: Failed to create challenge

Reason: RateLimit reached

Ich schaue mir das morgen noch einmal an. Unser Zertifikat gilt ja noch bis 13.12. ...

OK, ich denke nicht, dass es an unserer Konfiguration liegt, bei einem Kunden ist das Problem soeben identisch aufgetreten. Die letzte automatische Aktualisierung funktionierte noch reibungslos.

Also: Fehler bei Let's Encrpyt? Oder Bug in Rollout 414?

Moin,

bei uns wäre heute die Erneuerung des Webbox-Zertifikats via Let's Encrypt dran. Es kommt aber nur:

(AC) Certificate Order Error

Code: 1008

Error: Order certificate request failed

StatusCode: 500

Description: Failed to complete challenge

Reason: Request failed

An der Konfiguration hat sich nichts geändert, Port 80 ist offen, Webbox läuft. Porttest OK. Ich kann unsere öffentliche Adresse problemlos ansprechen, sowohl über den Hostnamen als auch über die IP.

Problem bei LE? Oder was kann das sonst sein? Hat jemand von euch schon ein neues Zertifikat angefordert bzw. erhalten, seit Rollout 414 draußen ist?

Moin,

zu a) hat mir Tobit vor Kurzem geantwortet, dass das nicht möglich sei. Ich würde mir ebenfalls eine entsprechende Option oder einen Reg-Key wünschen, mit dem die Meldung unterdrückt wird. Aber der neue Client soll wohl "gepusht" werden.

Für den Einsatz des (durchaus sehr guten) in David eingebauten SPAM-Schutzes, bei Tobit MIS genannt, wird afaik eine aktuelle Version benötigt, also david.3 - mit der alten fx.12 kommt man an der Stelle nicht weit.

Es gibt allerdings einige Drittanbieter-Lösungen, die an die Plattform keine so strengen Anforderungen stellen. Spontan fällt mir DvSPAM von SyntaX ein. Oder ihr arbeitet mit einem SPAM-verdauenden Proxy, einer Firewall, oder, oder... Möglichkeiten gibt es da viele.

Zitat von riawie

sicher das es keine signierten Nachrichten sind?
Da wäre das ändern nämlich verboten und sollte auch unmöglich sein...

Leuchtet ein, aber das kann ich ausschließen. Es sind bei mir alle Nachrichten betroffen, sogar die Script-generierten plain-text-Meldungen der Datensicherung...

Zitat von PeterPan

Mail markieren, rechte Maustaste, Eigenschaften, Betreff ändern

Ulkig: Das funktioniert in der Tat einwandfrei. Danke, ist ein guter Workaround.

Zitat von riawie

ich mach das zwar meist in der Eintragsliste mittels F2

Das klappt ebenfalls. Komplett öffnen + ändern + speichern hingegen nicht.

Ulkig 2: Stelle gerade fest, im Modern Client tritt das Problem nicht auf... Da der Classic Client nicht mehr weiter entwickelt wird, bringt eine Nachfrage bei Tobit vermutlich nix.

Naja. Mit der Lösung/den Lösungen kann ich leben, es geht in 99% der Fälle eh nur um den Betreff.

Danke euch!

Moin zusammen,

ich sehe vermutlich gerade mal wieder den Wald vor lauter Bäumen nicht. Bis vor einiger Zeit habe ich gerne Einträge in meinem persönlichen Eingangsarchiv angepasst. Da kommt zum Beispiel eine Mail von der Fritzbox mit dem Betreff "Nachricht von 12345 98765" - wenn das etwas ist, auf das ich später antworten wollte, habe ich die Nachricht geöffnet, den Betreff geändert (z. B. hinten dran gehängt: "Herr Müller Rückruf am Donnerstag") und die Sache mit Strg+S gespeichert.

Seit neustem funktioniert das nicht mehr. Statt dass der Eintrag direkt gespeichert wird, erscheint eine Abfrage, wo ich speichern will, und dort legt David dann eine Kopie des Eintrags ab. Was blöd ist, da damit auch die zeitliche Sortierung nicht mehr stimmt.

Mache ich irgendwas falsch? So ganz zeitlich einordnen kann ich es leider nicht, denke aber, dass es so vor ungefähr 6 Monaten noch problemlos funktioniert hat. Ich benutze nach wie vor den Classic Client (aktuelles Rollout). Hat jemand ne Idee?

Der SQL-Server ist bei David eher "Beiwerk", da sind bzgl. Usern, Konfiguration etc. keine relevanten Sachen gespeichert. Wenn du noch keine Chats hast, die erhalten bleiben müssen, kannst du die Datenbanken im SSMS einfach weglöschen und dann den Service Layer neu starten - auf diesem Wege werden die DBs automatisch neu erzeugt (Disclaimer: AFAIR. Wenn du unsicher bist, mach vorher eine Sicherheitskopie der Datenbanken).

Dazu muss natürlich trotzdem die prinzipielle Kommunikation mit dem SQL vom Service Layer her möglich sein. Was mir spontan dazu einfällt:

• Im SQL-Konfigurationsmanager prüfen, ob unter "Protokolle" sowohl TCP/IP als auch Named Pipes für David aktiv sind
• Evtl. Rechteproblem: Ändere testweise die Anmeldung des Dienstes "David Service Layer" mal auf einen Domänen-Admin - klappt der Zugriff dann? Falls ja, ggf. Rechte überarbeiten, vgl. auch RE: SQL Migration vom 2008R2 auf 2017 Express

14.0.x ist SQL-Server 2017, ja. Das aktuelle kumul. Update müsste dieses sein: https://www.catalog.update.mic…m/Search.aspx?q=KB5016884 (über Windows Updates sollte ebenfalls klappen, ggf. die Option "weitere MS-Software über Windows Updates aktualisieren" aktiv schalten).

So sollte das ungefähr aussehen:

Wurde der SQL-Server im Rahmen des David-Setups automatisch eingerichtet, oder hast du das manuell gemacht? Verpass dem mal die aktuellen Patches (wenn Standard Tobit-Installation: Auf Sprache "Englisch" achten), lade dir das MS SQL Server Management Studio herunter und schau, ob eine Verbindung möglich ist und in der Instanz DAVID bereits Datenbanken existieren.

Generell kannst du dort auch die DB zurücksetzen, allerdings sieht mir das oben eher so aus, als ob gar keine Kommunikation mit dem SQL möglich wäre. Grätscht evtl. die Firewall dazwischen? Klappt die Anmeldung via SSMS?

Schau mal in den Diensten, ob der SQL-Server (Instanz DAVID) korrekt installiert ist und läuft. Falls ja: Sagen im David-Client die Einträge unter System -> David -> Ereignisse irgendwas?

Die allermeisten Einstellungen (zumindest serverseitig) bleiben erhalten, wenn man entweder den Servernamen beibehält und stumpf das gesamte David-Verzeichnis überkopiert ODER den offiziellen Weg mit den Tobit Migration Servicves wählt. Letzteres kann bei sehr umfangreichen Archiven ein bisschen an der Geduld nagen.

Wenn du manuell alles mit Strongbox-Archiven umziehst, gehen die Einstellungen verloren, und bei einer Neuinstallation erhalten die Benutzer neue User-IDs. Woher soll das System auch wissen, wie es vorher war?

Zitat von juvilado

Das Zertifikat von globessl.com ist da, aber beim importieren verlangt er auch ein Passwort

Nee, das Zertifikat importierst du nicht auf die Smartphones, daraus baust du dir eines für die Webbox. Die weist sich damit dann "offiziell" als korrekte Gegenstelle aus, und der Weg mit dem manuellen Import entfällt.

Bastle dir eine neue Textdatei. In die kopierst du einfach untereinander die Inhalte der folgenden Dateien rein, die du von GlobeSSL erhalten hast:

1) Eigenes Zertifikat (kundenname.crt) (online bei globessl.com: CRT code)

2) Intermediate 1 (GlobeSSLDVCA.crt) (online bei globessl.com: CA code, erste Hälfte)

3) Intermediate 2 (USERTrustRSAAAACA.crt) (online bei globessl.com: CA code, zweite Hälfte)

4) Private Key (den du bei der Erstellung des Cert-Requests gespeichert hast).

Die Intermediates sind nicht zwingend nötig, sorgen aber für ein besseres Grading.

Diese Textdatei speichern als "WBCERT.PEM" (nicht "WEBBOX.PEM" !) im Verzeichnis \DAVID\APPS\WEBBOX\CODE, in der Konfiguration der Webbox Haken setzen bei "Zertifizierungspfad übertragen", in der Zuweisung der Zertifikate im David Admin ggf. die Pfade anpassen, dann Webbox neu starten.

Läuft die Webbox wieder, kannst du z. B. unter https://www.ssllabs.com/ssltest/ mal eure Domain eingeben und schauen, ob da alles schön grün ist. Mit obigen Einstellungen (Intermediates + Zert.-Pfad) sollte mindestens ein "A" herauskommen.

Zitat von juvilado

Nach dem Bestätigen kommt trotzdem wieder der Fehler:

Hast du das Zertifikat zusätzlich, wie von riawie in Beitrag 25 beschrieben, in den Zertifikatsspeicher des Smartphones importiert?

Zitat von juvilado

Welches muss ich denn wohl da bestellen?

In der Auswahl wäre das einfache Sectigo PositiveSSL vermutlich ausreichend. Du brauchst ja nur ein ganz einfaches für "Domain Validation".

Zitat von juvilado

Wie kann ich das denn bearbeiten

Bau dir einfach schnell ein neues.

Mach eine Sicherheitskopie eures jetzigen Zertifikats, vermutlich \David\Apps\Webbox\Code\wbcert.pem

Dann \David\Util\Windows\TLSCERT\tlscert.exe aufrufen und im Tool folgende Werte hinterlegen:

Certificate Type = Self Signed

Key Length = 2048

Country Name = DE

State or Province = Bundesland

Locality Name = Stadt

Organization Name = Firmenname

Organizational Unit = n/a

Common Name = EXAKTE (Sub)Domain David

Contact e-Mail = Mailadresse

Optionale Attribute: Leer lassen, Valid Days kannst du dir aussuchen (z.B. 366)

Wichtig ist dort halt, dass "Common Name" exakt der Adresse entspricht, über die du per Smartphone drauf zugreifst. Also z. B. eure dyndns-Adresse, ohne http(s)-Präfix. meindavidserver.dyndns.org etwa.

Die über das Tool erstellte Datei speicherst du als WBCERT.PEM in \David\Apps\Webbox\Code ab und startest dann die Webbox neu.

Schön finde ich das trotzdem nicht, auch wenn's funktioniert. Der Kostenaufwand für ein offiziell beglaubigtes Zertifikat ist ja nun wirklich minimal. Aber gut.

Zitat von juvilado

Ich will ja eigentlich kein Zertifikat für eine Webseite

Doch doch, in diesem Fall schon. Du willst ja damit keine E-Mails signieren/verschlüsseln, sondern ankommenden Clients nur bestätigen, dass sie den korrekten Host zu fassen haben. Gut, ist in diesem Fall nicht wirklich eine "Webseite", aber eben ein Dienst-Host.

Du brauchst: 1) Einen Hostnamen, der auf eure Adresse zeigt, da Zertifikate nicht für IP-Adressen ausgestellt werden können (nützt dir bei dynamischen Adressen eh nix). Wie gesagt, ich meine im Hinterkopf zu haben, dass Let's Encrypt keine Zertifikate für dyndns.org-Adressen ausstellt, bin da aber nicht ganz sicher. Falls doch, kommt der Tipp von ComputerManni ins Spiel, evtl. ist es schlau, sich bei Strato ein Billigpaket mit dyn. Host nur für diesen Zweck anzuschaffen.

2. musst du dann für diesen Host ein Zertifikat anfordern. Für LE geht das nur "zu Fuß" über die oben verlinkten Methoden. Ich hab' das seinerzeit offen gestanden als zu kompliziert empfunden und mir statt dessen ein einfaches Zertifikat bei GlobeSSL geholt ("Globe Standard SSL"). Einfache Domain Validation (DV), mehr brauchst du an der Stelle nicht. Andrere Anbieter gehen natürlich ebenso, GlobeSSL ist relativ billig. Für den Bezug erstellst du auf dem David-Server ein certificate request, z. B. mit der TLSCERT.EXE im Util-Verzeichnis. Mit dem ausgestellten Zertifikat musst du dir anschließend eine .pem-Datei bauen und diese der Webbox "unterjubeln".

Anschließend sieht es im Browser dann im Idealfall so aus, wenn du die Webbox-Adresse von extern aufrufst: