3 Commits (a64d41639b509ea60cc5ff3db711fe211ea2a24c)

Author	SHA1	Message	Date
nexxo	200df30b9d	Hetzner-Cloud-DNS, Bereitschaftsseite aus sich heraus behebbar ... Die alte Hetzner-DNS-API ist abgeschaltet (301 auf die Weboberflaeche). Jede Bereitstellung starb in ConfigureDnsAndTls, nachdem der Kunde bezahlt hatte. HttpHetznerDnsClient und DnsTokenCheck sprechen jetzt die Cloud-API: Bearer statt Auth-API-Token, RRSets ueber {name}/{typ} statt Record-IDs, der Zonen-Lookup entfaellt. Gegen das Live-Konto gemessen, nicht geraten. Drei Fallen, die am Konto gemessen wurden: TXT-Werte muessen in Anfuehrungszeichen (sonst 422, was als read_only gemeldet worden waere), ein Name mit Zonensuffix wird STILL angenommen (201), und der Fake gab andere IDs aus als der echte Client -- zwoelf Tests waren gruen ueber einem Abbau, der im Betrieb geworfen haette. Bereitschaftspunkte, die nur eine Shell beheben konnte, sind jetzt bedienbar: SSH-Schluesselpaar erzeugen (Ed25519 ueber phpseclib, privater Teil direkt in den Tresor), Stripe-Katalog abgleichen (Warteschlange, Trockenlauf, Ausgabe wortgleich), Mailzustellung als Schalter statt MAIL_MAILER, Neustart der Arbeiterprozesse. Stripe hat jetzt alle drei Werte in der Konsole: Secret Key, Signatur-Secret (Tresor, je Modus getrennt) und Publishable Key (Klartext). Codex-Review (R15), zwei P1 behoben: der Signaturschluessel faellt nicht mehr vom Live- in den Testplatz, und eine Record-ID aus der alten API macht einen Host nicht mehr unloeschbar -- was adressierbar ist, wandelt eine Migration um, der Rest wird beim Loeschen laut uebergangen statt geworfen. 2109 Tests gruen. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-31 19:50:01 +02:00
nexxo	b3081a544b	Let the export have as many destinations as somebody wants ... One path and one exported_at could not say "on the office NAS, not yet on the off-site box" — which is the only interesting question once there is more than one destination, and the reason for a second is precisely that any single one can fail. A row per destination now, and a row per (invoice, destination) pair. Two kinds, and the difference is where the protocol lives. 'local' is a directory this machine can already write to: a NAS mounted over NFS 4.1, a bind mount, a disk. The application knows nothing about the protocol, the target changes without code changing with it, and the whole thing stays testable against a temporary directory. 'sftp' is for something reachable with credentials — a Hetzner Storage Box being the obvious one — and the password goes into the secret vault with only its key on the row, because a credential in a settings table is a credential in every database dump. An empty password field on an existing target means unchanged, not cleared: the field cannot show what is stored, so blank-means-delete would wipe it on every unrelated edit. One job per pair rather than one per invoice. A job writing to both would retry the one that worked every time the other did not, and report one outcome for two different things. The ordering fix the tests found: Laravel's local adapter creates its root when it is CONSTRUCTED, so the "never create the root" guard was checking a directory the disk had just made for it. It runs before the disk is built now. That guard is the difference between an archive and a hole in the ground — mkdir on an absent mountpoint succeeds, writes onto the container's own disk and reports success, and an archive that silently is not the archive is worse than none. The single path from the previous commit is migrated into a destination called "Archiv" rather than dropped. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-29 02:43:15 +02:00
nexxo	ab4b0311d4	Copy every invoice to the archive when it is issued, and notice when that fails ... The application knows nothing about NFS and should not. It writes to a directory; whether that is a local disk, a bind mount or a NAS over NFS 4.1 belongs to the mount. No protocol library, the target changes without code changing with it, and the whole thing is testable against a temp directory. The finding that shaped it: mkdir -p on a path whose mount is NOT there succeeds. It creates the empty directory beneath the mountpoint, writes the invoice onto the container's own disk and reports success — so an unmounted NAS would quietly collect invoices locally while every check said it worked. An archive that silently is not the archive is worse than none. The root is therefore never created, only used: a missing root means a missing mount, and that is a failure. Only the year subdirectory is created, inside a root already proven to exist. Written to a .part and renamed. A rename within one filesystem is atomic, so whatever watches that folder never sees a truncated PDF and takes it for a finished invoice. The size is read back afterwards rather than the write being trusted: over a network mount a short write can report success, and an archive of truncated files looks exactly like one that worked. Queued, not done during the request. A network mount can block for its whole timeout, and an invoice must not fail to be issued because a NAS is rebooting. Dispatched after the commit, or a worker could look for an invoice that has not landed yet. And copy-on-issue is not enough on its own: an invoice issued while the office connection was down never arrives, the queue eventually gives up, and nobody opens an archive to check whether last Tuesday is in it. An hourly sweep re-queues whatever is still missing, the failure is recorded on the invoice rather than only in a log, and the Finance page says how many are outstanding. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-29 02:32:08 +02:00