boban
/
CluPilotCloud
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
422 Commits
10 Branches
109 Tags
12 MiB
Commit Graph

16 Commits (b3651a14be91cddb8e9352c223d0079880d475a5)

Author SHA1 Message Date
nexxo 012d0f5092 Say EU, and stop promising to fix somebody else's deleted folder
tests / pest (push) Failing after 8m13s Details
tests / assets (push) Successful in 23s Details
tests / release (push) Has been skipped Details 
Two corrections from a read of the live pages.

The location. Three public places named countries or a city — "aus deutschen
und finnischen Rechenzentren" on the placeholder, "in Österreich und
Deutschland" in the FAQ, "EU · Wien" in the product panel — and they did not
even agree with each other. They all say EU now, which is the thing that is
promised, the thing the AV-Vertrag pins down, and the thing that stays true
when a host moves.

The same string in the customer dashboard was worse: 'EU · Rechenzentrum
Falkenstein' was hard-coded and shown to every customer whatever host their
instance actually runs on. A specific claim nobody derived from the record.

The closing headline asked who you call when a folder is missing on a Monday
morning. It promised the wrong thing: what happens inside a customer's own
Nextcloud is their own house — the recycle bin and the version history are
right there — and presenting ourselves as the first call for somebody else's
user error offers a service we do not run. It now asks who looks after
updates, backups and outages, which is what the comparison section already
says in the operator's own words and what the product is actually for.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-07-29 14:17:30 +02:00
nexxo b843c10ec3 Give the update screen the product's colours, and only one window
tests / pest (push) Failing after 8m16s Details
tests / assets (push) Successful in 20s Details
tests / release (push) Has been skipped Details 
Two complaints, both correct, both mine.

Dark blue. The panel carried a `prefers-color-scheme: dark` block — the only
one in a product that has no dark mode. On a phone set to dark the update
screen, and nothing else, turned dark blue. A dark mode for one page is not a
dark mode; it is one page that does not match. It is gone.

And even in daylight the panel was not this product's colours: it used
Tailwind's slate ramp (#0f172a, #64748b, #e2e8f0), which is blue-tinted,
against neutrals that are warm. Every value is now a copy of a token from
portal-tokens.css, with the comment saying so, because this file cannot
import them — it renders when the asset build may not exist.

The small window then the big one. The settings card grew its own little
"läuft gerade" block the instant a run started; up to three seconds later the
full-page overlay covered it and said the same thing in a different size. The
card no longer says it at all, and the overlay now opens on the button's own
click — requestUpdate dispatches an event, but only once a run is actually
pending, so a refused second press does not black out the console.

Two more things found while looking:

The panel had `min-height: 100%`, which resolves against the parent's height.
On the 503 page the parent is <body>, whose height is auto — so it computed
to zero, the panel was only as tall as its text, and the bottom two thirds of
the screen stayed the browser's default white. Viewport units now, dvh so a
phone's collapsing address bar leaves no strip either.

And the mark was a plain orange tile again, the same empty-square that was
just fixed on the placeholder. The real logo is inlined.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-07-29 14:11:01 +02:00
nexxo 4755a4f362 Redesign the pre-launch placeholder, and fix its wordmark and mark
tests / pest (push) Failing after 8m7s Details
tests / assets (push) Successful in 20s Details
tests / release (push) Has been skipped Details 
Reported from a phone on status.clupilot.com, which serves this page because
the site is still switched to private.

Two real defects behind the complaint:

The wordmark read "Clu Pilot Cloud". `gap` on a flex container applies
between EVERY child and a bare text node is a child — so an inline-flex row
wrapped around "Clu", <i>Pilot</i> and " Cloud" put nine pixels between each
of them. The wordmark is one element now and the gap only ever separates it
from the mark.

The logo was a plain gradient tile with nothing in it, which reads as an
image that failed to load. That is a poor thing to leave somebody with on a
page whose whole message is "we are building this properly". The real mark —
cloud plus autopilot ascent — is inlined; it has to be in the file because
this page renders when the asset build may not exist at all.

The redesign itself: the card is gone. The page is now a centred composition
on the open ground — the state as a pill above everything, the mark, the
headline at the size the rest of the site uses, and the three promises the
paragraph was already making set as their own line so there is something to
look at besides one block of text. One warm bloom behind it, drawn as a
gradient rather than a blurred disc, which banded into visible rings.

Still self-contained, and still the only page exempt from the shared
stylesheet: it is served mid-deploy and on a fresh install, where @vite would
throw instead of rendering the reassurance somebody came for.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-07-29 13:43:56 +02:00
nexxo b85df4c141 Rebuild the status page as a status page 
Asked for after looking at how real ones are built. The shape they all share
is a convention, and a convention is what lets somebody find the answer
without being taught the page: banner, components each with ninety days of
uptime, then the written record underneath. This page had only the banner —
the version that is of no use the morning after, because "Alle Dienste in
Betrieb" is true and says nothing to somebody who was locked out the evening
before.

Three things are new.

The ninety-day bar. It cannot be reconstructed after the fact: the monitoring
table holds the last verdict per instance, not a history. So a sampler
(clupilot:sample-status, every five minutes beside the monitoring sync)
writes counts into one row per component per day, and the page divides them.
A day with no row is drawn as a gap and says "nicht aufgezeichnet" — never
green. Degraded samples count as reachable in the percentage but still colour
the day: folding them into downtime reports a slow morning as an outage,
ignoring them loses the only trace of it.

The incident record. An operator reports a disruption in the console, posts
updates as it develops, and the entry that says "behoben" is the same action
that closes it — two separate steps is how a page ends up with a resolved
note under an incident that still reports as ongoing. There is deliberately
no way to edit an update: it is a statement made at a time, corrections are a
further entry. An open incident may make a component look worse than the
probes found it, never better.

Scheduled maintenance, from the windows the console already keeps rather than
a second list somebody has to remember to fill in.

The measurement moved out of the controller into ServiceHealth, shared with
the sampler, so the banner and the bars cannot disagree about what "healthy"
means.

The page now uses the shared design system and the site's header and footer.
Its self-contained stylesheet was there to survive a broken asset build; it
does not survive one — if the stylesheet cannot be served the application
serving this page is already failing, and mid-deployment every route answers
with the maintenance page. What the exemption bought was a third design
nobody maintained.

Found while building: durationMinutes had its operands the wrong way round,
and diffInMinutes is signed, so the public page printed "Dauer -86 Minuten".

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-07-29 12:45:18 +02:00
nexxo 696c8834b8 Redesign the public website instead of recolouring it
tests / pest (push) Failing after 8m15s Details
tests / assets (push) Successful in 22s Details
tests / release (push) Has been skipped Details 
Correctly rejected: the last pass was the old page in new paint. It kept the
skeleton — eight numbered sections, a split hero, a twelve-row comparison
matrix — and changed only the palette. A palette is not a design.

What is actually different now:

- The § numbering is gone. Numbered sections with a drawn rule are a document
  convention, and the document voice is exactly what the product's design
  system dropped.
- The hero shows the product instead of describing it: centred type, then a
  wide panel built from the real console's own tokens, cropped by the section
  below. The old hero put a table of facts beside the headline, so a visitor
  read two columns before seeing anything.
- Six identical cards, then six more, then six more became one asymmetric
  grid — a large panel, a dark tile, an accent tile, a wide module row — so
  the important thing is allowed to be bigger than the rest.
- The industries are one dense two-column list instead of six cards repeating
  each other's shape.
- The page has one dark hinge in the middle (the deployment) rather than a
  dark section among seven light ones.
- The evidence table became rows that pair the measure with the piece of
  paper you can hand somebody, which is what it is for.
- Prices are cards, with the full matrix folded away underneath. The matrix
  used to be the first thing a visitor met: twelve rows of ticks before a
  single price was legible.
- The FAQ heading sits still while the questions scroll past it.
- The footer is a real footer.

The header is a floating bar rather than a full-width band, and opaque in
both states — translucency plus backdrop-blur reads as a rendering fault over
the dark panels that scroll under it.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-07-29 11:43:25 +02:00
nexxo 43d58de7f8 Rebuild the public website in the shared design system 
Reported plainly: the site is still in the old style. It was — it was the
last of the three surfaces the token file describes that had never been
converted. landing.blade.php carried its own complete design system inside a
<style> block: warm paper, IBM Plex Serif headlines, 3px corners, its own
scale of greys, written before the tokens existed. Somebody who clicked
"Anmelden" left one company and arrived at another.

The page now draws from resources/css/portal-tokens.css like the portal and
the console: same surfaces, same radii, same button hierarchy, same
small-caps label, one family at weight 700 instead of a serif. What still
differs is rhythm, which is what a marketing page is allowed to differ in.

Content is unchanged. New: components/layouts/site.blade.php holds the header
and footer for every public page, and legal.blade.php uses it too — the
imprint used to be a stranded card in a third style again.

Two things found on the way:
- .lbl set `color: var(--muted)`, which is not a token. An undefined var() in
  `color` computes to `unset`, so every small-caps label on every surface was
  whatever colour its container happened to be.
- The big figures were set in mono. Mono gives the decimal comma a full glyph
  cell, so "99,95" read as three separate numbers.

coming-soon and the status page stay self-contained on purpose — both are
served when the application may not have a built stylesheet at all.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-07-29 11:26:35 +02:00
nexxo f8f0de4892 Let an update install host packages, without handing out root 
Asked for directly: "später wenn ich etwas lokal erweitere will ich mich
nicht auf alle adminseiten einloggen müssen und extra rsync installieren".

An update runs as the service account, so anything root-owned on the host is
out of its reach and turns into "log into every server once and paste this".
The obvious fix — sudo on deploy/install-agent.sh — is not a grant at all:
the service account owns the checkout and can rewrite the very script it
would be allowed to run as root.

So the privileged part is written OUT of the checkout by install-agent.sh, to
/usr/local/sbin/clupilot-host-step, root:root 0755, from a quoted
here-document. The service account cannot influence a byte of it. sudoers
names one exact command line including its argument, so a step added to the
helper later is not covered by a grant written before it existed, and the
helper refuses anything not on its own list as well.

update.sh uses it only when rsync is actually missing, after the restart and
never fatally: the archive is collected hours later, and an update that died
over a package would be the bigger problem. A helper older than the steps the
updater wants is reported through the existing one-time-setup hint — silently
doing nothing is worse than an error.

Existing servers still need `sudo bash deploy/install-agent.sh` once, because
that is the run that puts the helper there. After it, they do not.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-07-29 10:27:56 +02:00
nexxo 77bd30ca56 Answer on every name for the website, and send them all to one
tests / pest (push) Failing after 7m23s Details
tests / assets (push) Successful in 22s Details
tests / release (push) Has been skipped Details 
SITE_HOST takes a comma-separated list now, the first name canonical. It serves
the site; every other name in the list redirects there permanently, path and
query intact. An apex domain and its www are two names for one thing, and
answering on both without picking one splits search rankings and cookies
between them.

The redirect is a host-bound catch-all rather than middleware. Middleware that
only some routes carry is the same half-measure this file already made once,
and a catch-all registered without a host would swallow every path in the
application — which is what the third test is there to stop.

The test harness needed fixing too, and the fix is the finding. Router::dispatch
on a standalone router does not rebind the container's request, so a route
reading one — through the helper OR through an injected parameter, both of which
resolve from the container — gets the test's request rather than the one being
answered. The redirect silently lost its query string in the test while working
in production. dispatchOn() binds it where the framework would.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-07-29 01:29:33 +02:00
nexxo 21762284a7 Bind the portal to its own hostname too, so the website cannot serve it
tests / pest (push) Failing after 7m48s Details
tests / assets (push) Successful in 23s Details
tests / release (push) Has been skipped Details 
The previous release bound the landing page and stopped there. The website duly
vanished from the portal — and the portal stayed reachable from the website:
www.clupilot.com/dashboard, /login, /settings all kept working. Half a
separation is no separation, and it was reported back within the hour.

APP_HOST binds every portal route, Fortify's own POST actions included through
fortify.domain — a sign-in form on the website's hostname would otherwise post
to a route that answers there. SITE_HOST now takes the legal pages and
robots.txt with the landing page rather than leaving them everywhere; binding
them is also what makes route('legal.impressum') produce a www URL from inside
a queued mail, where there is no request to take a hostname from.

There is no clever middleware here and there should not be. Route::domain() is
the mechanism: a route registered for one host does not exist on another, and a
request for it gets the 404 it deserves. The only deliberate exception is "/" on
the portal host, which redirects to the dashboard or the sign-in page — that is
what people type from memory, and turning it into an error page to make a point
about hostnames helps nobody. The Stripe webhook and /up stay host-agnostic:
Stripe posts to whichever URL it was given, and a mismatch there loses payments.

Both are opt-in and empty by default, which every development machine reached
by a bare IP depends on.

The tests now check BOTH directions for every path rather than only the one
that was reported. That is the mistake this commit exists to correct.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-07-29 01:06:50 +02:00
nexxo 5f7b8ff81b Cut 1.3.0
tests / pest (push) Failing after 7m41s Details
tests / assets (push) Successful in 21s Details
tests / release (push) Has been skipped Details 
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-07-29 00:42:06 +02:00
nexxo 4d4d1dd5d5 Stop the update agent dying on its own tag arithmetic
tests / pest (push) Failing after 8m4s Details
tests / assets (push) Successful in 22s Details
tests / release (push) Has been skipped Details 
Since 1.2.0 the agent has ended with a non-zero status on every tick, before
writing anything. The console showed a check that never finished and a
last-checked time frozen at the moment of the deployment, and the update button
could not be reached at all — the one mechanism that would have delivered the
fix.

Two instances of the same trap, both mine, both under `set -Eeuo pipefail`:

The tag count was `release_version_gt … && echo`. The LAST iteration is almost
always a tag that is not newer, so the loop ended non-zero, pipefail carried it
out of the pipeline, the command substitution inherited it, and set -e ended
the agent. `if` rather than `&&` is the whole fix: an if whose condition is
false still returns 0.

The newest tag came from `git tag … | head -1`. head exits after one line, git
takes SIGPIPE, pipefail does the rest. install-agent.sh has carried a written
warning about exactly this since it was written; I read it and wrote it anyway.

Both now live in deploy/lib/release.sh, because the reason neither was caught
is that no PHP test can reach a bash pipeline.
tests/Feature/ReleaseComparisonTest.php runs the real functions in a real
throwaway repository under the agent's own set -Eeuo pipefail, and asserts the
EXIT CODE as well as the answer — an answer nobody lives to read is not an
answer. The SIGPIPE case needs four hundred tags to reproduce, because a short
list finishes writing before head leaves.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-07-29 00:00:17 +02:00
nexxo 6998a22527 Repair ownership by looking inside, not at the door
tests / pest (push) Failing after 8m2s Details
tests / assets (push) Successful in 21s Details
tests / release (push) Has been skipped Details 
The ownership repair added in 1.1.1 sampled the owner of each top-level
directory and skipped the recursion when it already matched. node_modules was
owned by www-data; node_modules/.vite-temp, left behind by an earlier root
build, was not. So the repair walked past it, `npm run build` failed with
EACCES, and the deployment stopped in maintenance mode — on the release whose
whole point was that this could not happen.

A directory's owner says nothing about its contents. It now walks each tree
once with find and changes only the entries that are wrong, which is also
cheaper than the detect-then-chown-everything it replaces.

Verified against the shape that actually failed: a root-owned file inside a
www-data-owned node_modules, repaired.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-07-28 23:53:25 +02:00
nexxo c7a3224466 Cut 1.2.0
tests / pest (push) Failing after 7m51s Details
tests / assets (push) Successful in 23s Details
tests / release (push) Has been skipped Details 
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-07-28 23:44:18 +02:00
nexxo 00b9107ee3 Deploy as the application's user, and take back what root already took
tests / pest (push) Failing after 7m19s Details
tests / assets (push) Successful in 19s Details
tests / release (push) Has been skipped Details 
The 500 on the VPN config download was never in the VPN code. storage/logs/
laravel.log was owned by root, mode 644, since 27.07 04:16 — the moment a
failed `artisan optimize` wrote its error there during a deployment. From then
on the application could not append to its own log: Monolog threw on every
attempt, and a throw while logging is a 500 on any page that logs, with nothing
written down to say why. The error page said "Er wurde protokolliert". It was
not.

It surfaced on the config download because that is one of the few pages writing
a log line on its way through — on success and on a wrong password alike. Pages
that log nothing were unaffected, which is exactly why it looked like a VPN
fault for days.

`docker compose exec` is root unless told otherwise, and every deployment
script relied on that default — including the agent's allowlist sync, which
runs every minute. docker/entrypoint.sh had it right all along and drops to
www-data for precisely these commands. Now so does everything else, help text
included: telling an operator to run artisan as root is how the file ends up
owned by root in the first place.

update.sh also repairs what an earlier run left behind, before its first
unprivileged step rather than after — a root-owned log file is not
self-healing, the page that trips over it is nowhere near the deployment that
caused it, and with in_app unprivileged a root-owned vendor/ would break the
next composer step outright.

tests/Feature/DeploymentRunsAsTheAppUserTest.php holds the line. It was checked
against the previous commit and finds all nine places that were wrong.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-07-28 22:52:09 +02:00
nexxo 21b7aaca42 Update only to a released version, never to whatever landed on main
tests / pest (push) Failing after 7m21s Details
tests / assets (push) Successful in 20s Details
tests / release (push) Has been skipped Details 
Asked for directly: a commit on main must change nothing on a server, and only
a tag whose version is higher than the installed one may be installed.

The agent asked two different questions before this. A pinned server compared
tags; everything else counted commits on its branch — so a console following
main offered an update for every push, verified or not, and "Jetzt
aktualisieren" meant "take whatever is on the branch right now". Landing on main
and being released are different events, and only the second is a decision
somebody made.

It is one question now, regardless of what the checkout is attached to: is there
a tag whose version is higher than the deployed one? Compared with sort -V
against the version in the deployment manifest — not the VERSION file, which an
update moves before it migrates, so a run that failed in between would leave the
checkout claiming a version it never finished installing. A run always targets
that tag; the branch path is gone. A request that arrives with nothing to
install is answered rather than obeyed, before anything announces a run.

The console follows: the button is disabled with nothing released, says so in a
line rather than leaving a grey button to be guessed at, names the version it
would install rather than a count, and refuses the action server-side as well —
a Livewire action is a public endpoint, and one place a rule may not live is
only in the disabled attribute of a button.

VERSION becomes 1.1.0, to be tagged as the first release this mechanism can see.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-07-28 22:32:44 +02:00
nexxo e9240c1324 feat(deploy): releases you can pin to, and a version that tells the truth 
VERSION at the repository root is the release number and the only place it is
written down — a file rather than `git describe`, because a source archive, a
shallow CI checkout and a container built without .git have no tags to
describe. Cutting a release is editing that file and merging it; CI creates the
annotated v<VERSION> tag once green, only on the commit that raised the number,
and never moves it. Servers are pinned to these.

Two modes, and the difference is the point. RELEASE=v1.0.0 pins a server to an
immutable tag, checked out detached: it moves when someone decides it moves.
BRANCH=main follows the edge, where CI tags a commit only after it is pushed.
The mode is remembered, so re-running the updater on a pinned box does not
quietly walk it back onto main.

Going backwards is refused, by commit ancestry rather than by comparing version
strings — a tag can be cut from anywhere, and only ancestry says whether history
is going back. The schema has already moved forward by then, and the migrations
needed to reverse it are not in the older checkout at all.

What the console reports comes from a manifest written atomically after every
step succeeded, never from live git: git says what the files are, not whether
the deployment came up. So a failed update keeps reporting the version that is
actually serving — including its version number, not the newer one the checkout
has already moved to. A deployment pinned to the tag reads "1.0.0 (abc1234)";
anything else reads "1.0.0-dev (abc1234) · main", because every commit after the
tag still carries VERSION=1.0.0 and is not that release. Reporting it as one is
how a bug gets filed against the wrong code.

Codex reviewed the design before it was written and the result six times after.
Its findings, all real: the version had to come from the manifest too, not just
the commit; branch names need JSON escaping or the manifest silently vanishes; a
`case` glob does not anchor and accepted 1x.2y.3garbage; pinning to the commit a
server already sits on skipped recording the mode, and then skipped detaching;
a manifest that failed to write would never be repaired; an unparseable
timestamp would 500 every admin page; and an empty tag list read as a
connectivity failure.

466 tests green.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-07-26 15:21:38 +02:00