diff --git a/backend/db/migrations/0073_scanner_document_inbox.sql b/backend/db/migrations/0073_scanner_document_inbox.sql new file mode 100644 index 00000000..b1311e70 --- /dev/null +++ b/backend/db/migrations/0073_scanner_document_inbox.sql @@ -0,0 +1,20 @@ +CREATE TABLE "scanner_inbox_connections" ( + "tenant_id" bigint PRIMARY KEY REFERENCES "tenants"("id") ON DELETE CASCADE, + "username" text NOT NULL UNIQUE, + "password_hash" text NOT NULL, + "active" boolean NOT NULL DEFAULT true, + "created_at" timestamp with time zone NOT NULL DEFAULT now(), + "updated_at" timestamp with time zone +); +--> statement-breakpoint +CREATE TABLE "scanner_inbox_documents" ( + "file_id" uuid PRIMARY KEY REFERENCES "files"("id") ON DELETE CASCADE, + "tenant_id" bigint NOT NULL REFERENCES "tenants"("id") ON DELETE CASCADE, + "remote_filename" text NOT NULL, + "checksum" text NOT NULL, + "received_at" timestamp with time zone NOT NULL DEFAULT now() +); +--> statement-breakpoint +CREATE UNIQUE INDEX "scanner_inbox_documents_filename_key" ON "scanner_inbox_documents" ("tenant_id", "remote_filename"); +--> statement-breakpoint +CREATE INDEX "scanner_inbox_documents_received_idx" ON "scanner_inbox_documents" ("tenant_id", "received_at"); diff --git a/backend/db/migrations/0074_scanner_inbox_filing.sql b/backend/db/migrations/0074_scanner_inbox_filing.sql new file mode 100644 index 00000000..ec0c9147 --- /dev/null +++ b/backend/db/migrations/0074_scanner_inbox_filing.sql @@ -0,0 +1 @@ +ALTER TABLE "scanner_inbox_documents" ADD COLUMN "filed_at" timestamp with time zone; diff --git a/backend/db/migrations/meta/_journal.json b/backend/db/migrations/meta/_journal.json index 3e3ce195..d479c6cd 100644 --- a/backend/db/migrations/meta/_journal.json +++ b/backend/db/migrations/meta/_journal.json @@ -491,6 +491,20 @@ "when": 1790121600001, "tag": "0072_restore_instance_scan_agents", "breakpoints": true + }, + { + "idx": 70, + "version": "7", + "when": 1790640000000, + "tag": "0073_scanner_document_inbox", + "breakpoints": true + }, + { + "idx": 71, + "version": "7", + "when": 1790640000001, + "tag": "0074_scanner_inbox_filing", + "breakpoints": true } ] } diff --git a/backend/db/schema/index.ts b/backend/db/schema/index.ts index b37bb941..e7acf454 100644 --- a/backend/db/schema/index.ts +++ b/backend/db/schema/index.ts @@ -100,3 +100,4 @@ export * from "./serialtypes" export * from "./serialexecutions" export * from "./public_links" export * from "./wikipages" +export * from "./scanner_inbox" diff --git a/backend/db/schema/scanner_inbox.ts b/backend/db/schema/scanner_inbox.ts new file mode 100644 index 00000000..b048e4a2 --- /dev/null +++ b/backend/db/schema/scanner_inbox.ts @@ -0,0 +1,24 @@ +import { bigint, boolean, index, pgTable, text, timestamp, uniqueIndex, uuid } from "drizzle-orm/pg-core" +import { tenants } from "./tenants" +import { files } from "./files" + +export const scannerInboxConnections = pgTable("scanner_inbox_connections", { + tenantId: bigint("tenant_id", { mode: "number" }).primaryKey().references(() => tenants.id, { onDelete: "cascade" }), + username: text("username").notNull().unique(), + passwordHash: text("password_hash").notNull(), + active: boolean("active").notNull().default(true), + createdAt: timestamp("created_at", { withTimezone: true }).notNull().defaultNow(), + updatedAt: timestamp("updated_at", { withTimezone: true }), +}) + +export const scannerInboxDocuments = pgTable("scanner_inbox_documents", { + fileId: uuid("file_id").primaryKey().references(() => files.id, { onDelete: "cascade" }), + tenantId: bigint("tenant_id", { mode: "number" }).notNull().references(() => tenants.id, { onDelete: "cascade" }), + remoteFilename: text("remote_filename").notNull(), + checksum: text("checksum").notNull(), + receivedAt: timestamp("received_at", { withTimezone: true }).notNull().defaultNow(), + filedAt: timestamp("filed_at", { withTimezone: true }), +}, table => ({ + filenameKey: uniqueIndex("scanner_inbox_documents_filename_key").on(table.tenantId, table.remoteFilename), + receivedIdx: index("scanner_inbox_documents_received_idx").on(table.tenantId, table.receivedAt), +})) diff --git a/backend/src/index.ts b/backend/src/index.ts index b1828a9d..342feebe 100644 --- a/backend/src/index.ts +++ b/backend/src/index.ts @@ -37,6 +37,8 @@ import telephonyRoutes from "./routes/telephony"; import instanceAgentRoutes from "./routes/instanceAgents"; import instanceAgentGatewayRoutes from "./routes/instanceAgentGateway"; import documentImportRoutes from "./routes/documentImports"; +import scannerInboxGateway from "./routes/scannerInboxGateway"; +import documentInboxRoutes from "./routes/documentInbox"; //Public Links import publiclinksNonAuthenticatedRoutes from "./routes/publiclinks/publiclinks-non-authenticated"; @@ -134,6 +136,8 @@ async function main() { await agentApp.register(instanceAgentGatewayRoutes) },{prefix: "/instance-agent"}) + await app.register(scannerInboxGateway, { prefix: "/scanner-inbox" }); + await app.register(corsPlugin); //Geschützte Routes @@ -167,6 +171,7 @@ async function main() { await subApp.register(telephonyRoutes); await subApp.register(instanceAgentRoutes); await subApp.register(documentImportRoutes); + await subApp.register(documentInboxRoutes); },{prefix: "/api"}) diff --git a/backend/src/modules/scanner-inbox.service.ts b/backend/src/modules/scanner-inbox.service.ts new file mode 100644 index 00000000..9daf85d1 --- /dev/null +++ b/backend/src/modules/scanner-inbox.service.ts @@ -0,0 +1,184 @@ +import { createHash, randomBytes, randomUUID, timingSafeEqual } from "node:crypto" +import { and, asc, count, desc, eq, ilike, isNull, sql } from "drizzle-orm" +import type { FastifyInstance } from "fastify" +import { DeleteObjectCommand, PutObjectCommand } from "@aws-sdk/client-s3" +import { files, filetags, folders, scannerInboxConnections, scannerInboxDocuments, tenants } from "../../db/schema" +import { sanitizeFilename } from "../utils/filename" +import { s3 } from "../utils/s3" +import { secrets } from "../utils/secrets" + +export const SCANNER_UPLOAD_LIMIT = 100 * 1024 * 1024 +export const SCANNER_DAV_PATH = "/scanner-inbox/" +export const scannerError = (statusCode: number, message: string) => Object.assign(new Error(message), { statusCode }) +const digest = (value: string | Buffer) => createHash("sha256").update(value).digest("hex") + +export type ScannerIdentity = { tenantId: number; username: string; passwordHash: string } +export interface ScannerStorage { + put(key: string, body: Buffer, contentType: string): Promise + remove(key: string): Promise +} + +const objectStorage: ScannerStorage = { + async put(key, body, contentType) { + await s3.send(new PutObjectCommand({ Bucket: secrets.S3_BUCKET, Key: key, Body: body, ContentType: contentType, ContentLength: body.length })) + }, + async remove(key) { + await s3.send(new DeleteObjectCommand({ Bucket: secrets.S3_BUCKET, Key: key })) + }, +} + +export function validateScannerFile(filename: string, body: Buffer) { + if (!filename || filename.length > 200 || /[\\/\u0000-\u001f\u007f]/.test(filename) || filename.startsWith(".")) { + throw scannerError(400, "Bitte einen einzelnen Dateinamen ohne Unterordner verwenden.") + } + if (!body.length) throw scannerError(400, "Die Datei ist leer.") + if (body.length > SCANNER_UPLOAD_LIMIT) throw scannerError(413, "Die Datei überschreitet 100 MB.") + const extension = filename.split(".").pop()?.toLowerCase() + if (extension === "pdf" && body.subarray(0, 5).toString() === "%PDF-" && body.subarray(-1024).includes(Buffer.from("%%EOF"))) return "application/pdf" + if (["jpg", "jpeg"].includes(extension) && body[0] === 0xff && body[1] === 0xd8 && body[2] === 0xff) return "image/jpeg" + if (extension === "png" && body.subarray(0, 8).equals(Buffer.from([137, 80, 78, 71, 13, 10, 26, 10]))) return "image/png" + if (["tif", "tiff"].includes(extension) && ["49492a00", "4d4d002a"].includes(body.subarray(0, 4).toString("hex"))) return "image/tiff" + throw scannerError(415, "Bitte eine vollständige PDF-, JPEG-, PNG- oder TIFF-Datei übertragen.") +} + +export function createScannerInboxService(db: FastifyInstance["db"], storage: ScannerStorage = objectStorage) { + const publicConnection = { + username: scannerInboxConnections.username, + active: scannerInboxConnections.active, + createdAt: scannerInboxConnections.createdAt, + } + const connection = async (tenantId: number) => { + const [row] = await db.select(publicConnection).from(scannerInboxConnections) + .where(eq(scannerInboxConnections.tenantId, tenantId)).limit(1) + return row || null + } + const credentials = async (tenantId: number) => { + // Epson ES-580W destination passwords are limited to 20 characters (120 random bits). + const password = randomBytes(15).toString("base64url") + const [row] = await db.insert(scannerInboxConnections).values({ + tenantId, username: `scan_${randomBytes(8).toString("hex")}`, passwordHash: digest(password), + }).onConflictDoUpdate({ + target: scannerInboxConnections.tenantId, + set: { passwordHash: digest(password), active: true, updatedAt: new Date() }, + }).returning(publicConnection) + return { ...row, password } + } + const disable = async (tenantId: number) => { + await db.update(scannerInboxConnections).set({ active: false, updatedAt: new Date() }) + .where(eq(scannerInboxConnections.tenantId, tenantId)) + } + const authenticate = async (username: string, password: string): Promise => { + const [row] = await db.select().from(scannerInboxConnections).where(and( + eq(scannerInboxConnections.username, username), eq(scannerInboxConnections.active, true), + )).limit(1) + const expected = row?.passwordHash || "0".repeat(64) + const valid = timingSafeEqual(Buffer.from(digest(password)), Buffer.from(expected)) + return row && valid ? { tenantId: row.tenantId, username: row.username, passwordHash: row.passwordHash } : null + } + const find = async (tenantId: number, filename: string) => { + const [row] = await db.select({ size: files.size, mimeType: files.mimeType, checksum: scannerInboxDocuments.checksum, + receivedAt: scannerInboxDocuments.receivedAt }).from(scannerInboxDocuments) + .innerJoin(files, and(eq(files.id, scannerInboxDocuments.fileId), eq(files.tenant, scannerInboxDocuments.tenantId))) + .where(and(eq(scannerInboxDocuments.tenantId, tenantId), eq(scannerInboxDocuments.remoteFilename, filename))).limit(1) + return row || null + } + const list = async (tenantId: number, limit: number, offset: number, search: string) => { + const condition = and(eq(scannerInboxDocuments.tenantId, tenantId), eq(files.tenant, tenantId), + isNull(scannerInboxDocuments.filedAt), eq(files.archived, false), + search ? ilike(scannerInboxDocuments.remoteFilename, `%${search.replace(/[\\%_]/g, "\\$&")}%`) : undefined) + const documents = await db.select({ id: files.id, name: scannerInboxDocuments.remoteFilename, + mimeType: files.mimeType, size: files.size, receivedAt: scannerInboxDocuments.receivedAt }) + .from(scannerInboxDocuments).innerJoin(files, eq(files.id, scannerInboxDocuments.fileId)) + .where(condition).orderBy(desc(scannerInboxDocuments.receivedAt), desc(files.id)).limit(limit).offset(offset) + const [total] = await db.select({ value: count() }).from(scannerInboxDocuments) + .innerJoin(files, eq(files.id, scannerInboxDocuments.fileId)).where(condition) + return { documents, total: total.value } + } + const filingOptions = async (tenantId: number) => { + const [availableFolders, types] = await Promise.all([ + db.select({ id: folders.id, name: folders.name, parent: folders.parent, + standardFiletype: folders.standardFiletype, standardFiletypeIsOptional: folders.standardFiletypeIsOptional }) + .from(folders).where(and(eq(folders.tenant, tenantId), eq(folders.archived, false))).orderBy(asc(folders.name)), + db.select({ id: filetags.id, name: filetags.name }).from(filetags) + .where(and(eq(filetags.tenant, tenantId), eq(filetags.archived, false))).orderBy(asc(filetags.name)), + ]) + return { folders: availableFolders, types } + } + const fileDocument = async (tenantId: number, userId: string, fileId: string, folderId: string | null, typeId: string) => db.transaction(async tx => { + const [tenant] = await tx.select({ locked: tenants.locked }).from(tenants) + .where(eq(tenants.id, tenantId)).for("share") + if (!tenant) throw scannerError(404, "Mandant nicht gefunden.") + if (tenant.locked === "maintenance_tenant") throw scannerError(423, "Der Mandant wird gerade gewartet.") + const [entry] = await tx.select({ filedAt: scannerInboxDocuments.filedAt }).from(scannerInboxDocuments) + .where(and(eq(scannerInboxDocuments.tenantId, tenantId), eq(scannerInboxDocuments.fileId, fileId))).for("update") + if (!entry) throw scannerError(404, "Dokument nicht in der Ablage gefunden.") + if (entry.filedAt) throw scannerError(409, "Dieses Dokument wurde bereits abgelegt. Bitte den Eingang aktualisieren.") + const [file] = await tx.select({ id: files.id }).from(files) + .where(and(eq(files.id, fileId), eq(files.tenant, tenantId), eq(files.archived, false))).for("update") + if (!file) throw scannerError(404, "Dokument nicht gefunden oder archiviert.") + if (folderId) { + const [folder] = await tx.select({ standardFiletype: folders.standardFiletype, optional: folders.standardFiletypeIsOptional }) + .from(folders).where(and(eq(folders.id, folderId), eq(folders.tenant, tenantId), eq(folders.archived, false))).for("share") + if (!folder) throw scannerError(400, "Der gewählte Ordner ist nicht verfügbar.") + if (folder.standardFiletype && !folder.optional && folder.standardFiletype !== typeId) { + throw scannerError(400, "Dieser Ordner gibt einen festen Dokumenttyp vor.") + } + } + const [type] = await tx.select({ id: filetags.id }).from(filetags) + .where(and(eq(filetags.id, typeId), eq(filetags.tenant, tenantId), eq(filetags.archived, false))).for("share") + if (!type) throw scannerError(400, "Der gewählte Dokumenttyp ist nicht verfügbar.") + const now = new Date() + await tx.update(files).set({ folder: folderId, type: typeId, updatedAt: now, updatedBy: userId }) + .where(and(eq(files.id, fileId), eq(files.tenant, tenantId))) + // Keep the receipt so a scanner retry cannot recreate a document after filing. + await tx.update(scannerInboxDocuments).set({ filedAt: now }) + .where(and(eq(scannerInboxDocuments.fileId, fileId), eq(scannerInboxDocuments.tenantId, tenantId))) + return { id: fileId, folder: folderId, type: typeId } + }) + const accept = async (identity: ScannerIdentity, filename: string, body: Buffer, onlyIfNew = false) => { + const contentType = validateScannerFile(filename, body) + const checksum = digest(body) + let uploadedKey: string | undefined + try { + return await db.transaction(async tx => { + // Coordinate with tenant maintenance and credential revocation during the upload. + const [tenant] = await tx.select({ locked: tenants.locked }).from(tenants) + .where(eq(tenants.id, identity.tenantId)).for("share") + if (!tenant) throw scannerError(401, "Scanner-Zugang ungültig.") + if (tenant.locked === "maintenance_tenant") throw scannerError(423, "Der Mandant wird gerade gewartet.") + const [active] = await tx.select({ tenantId: scannerInboxConnections.tenantId }).from(scannerInboxConnections) + .where(and(eq(scannerInboxConnections.tenantId, identity.tenantId), eq(scannerInboxConnections.username, identity.username), + eq(scannerInboxConnections.passwordHash, identity.passwordHash), eq(scannerInboxConnections.active, true))).for("share") + if (!active) throw scannerError(401, "Scanner-Zugang ungültig.") + + // Serialise retries across processes; a lost HTTP response must not duplicate a document. + await tx.execute(sql`SELECT pg_advisory_xact_lock(hashtextextended(${`${identity.tenantId}:${filename}`}, 0))`) + const [existing] = await tx.select().from(scannerInboxDocuments).where(and( + eq(scannerInboxDocuments.tenantId, identity.tenantId), eq(scannerInboxDocuments.remoteFilename, filename), + )).limit(1) + if (existing) { + if (onlyIfNew) throw scannerError(412, "Der Dateiname ist bereits vorhanden.") + if (existing.checksum !== checksum) throw scannerError(409, "Der Dateiname ist bereits vergeben. Bitte einen eindeutigen Dateinamen verwenden.") + return { created: false, checksum } + } + const id = randomUUID() + const key = `${identity.tenantId}/filesbyid/${id}/${sanitizeFilename(filename)}` + uploadedKey = key + await storage.put(key, body, contentType) + // Bypass saveFile's text extraction: the inbox only stores the original document. + await tx.insert(files).values({ id, tenant: identity.tenantId, name: filename, path: key, mimeType: contentType, size: body.length }) + await tx.insert(scannerInboxDocuments).values({ fileId: id, tenantId: identity.tenantId, remoteFilename: filename, checksum }) + return { created: true, checksum } + }) + } catch (error) { + if (uploadedKey) { + try { await storage.remove(uploadedKey) } + catch (cleanupError) { console.error("Scanner-Upload konnte nicht bereinigt werden", { key: uploadedKey, cleanupError }) } + } + throw error + } + } + return { connection, credentials, disable, authenticate, find, list, filingOptions, fileDocument, accept } +} + +export type ScannerInboxService = ReturnType diff --git a/backend/src/modules/selfhost-updater.ts b/backend/src/modules/selfhost-updater.ts index 6518eeae..5bf3c7b1 100644 --- a/backend/src/modules/selfhost-updater.ts +++ b/backend/src/modules/selfhost-updater.ts @@ -36,6 +36,7 @@ const state = z.object({ const plan = state.omit({ status: true }).extend({ updateAvailable: z.boolean(), requiresComposeAdoption: z.boolean(), estimatedBackupBytes: z.number().nonnegative().finite().optional(), + storageProvider: z.enum(["minio", "seaweedfs"]).optional(), storageImageRetained: z.boolean().optional(), retiredServices: z.array(z.enum(["matrix-db", "matrix-synapse", "matrix-redis", "matrix-element", "matrix-livekit", "matrix-rtc-jwt", "matrix-turn", "matrix-well-known"])), }); @@ -48,6 +49,7 @@ const job = state.extend({ plan: plan.optional(), progress: state.optional(), const status = z.object({ apiVersion: z.literal(1), acceptingRequests: z.boolean(), engine: state, installed: state.pick({ version: true, revision: true }), request: job.optional(), capabilities: z.object({ requestLogs: z.boolean() }).optional(), + storage: z.object({ provider: z.literal("seaweedfs"), migrationPending: z.boolean() }).optional(), }); const logs = z.object({ requestId, logs: z.array(z.object({ source: z.enum(["service", "events", "commands"]), content: z.string().max(6000), truncated: z.boolean(), diff --git a/backend/src/modules/system-status.service.ts b/backend/src/modules/system-status.service.ts index c1f41a7d..094d6aa4 100644 --- a/backend/src/modules/system-status.service.ts +++ b/backend/src/modules/system-status.service.ts @@ -1,4 +1,7 @@ import { FastifyInstance } from "fastify" +import { HeadBucketCommand } from "@aws-sdk/client-s3" +import { s3 } from "../utils/s3" +import { secrets } from "../utils/secrets" type MetricSample = { labels: Record @@ -10,9 +13,6 @@ const metricLinePattern = /^([a-zA-Z_:][a-zA-Z0-9_:]*)(?:\{([^}]*)\})?\s+(-?(?:\ const nodeExporterUrl = () => (process.env.NODE_EXPORTER_URL || "http://node-exporter:9100").replace(/\/+$/, "") -const s3EndpointUrl = () => - (process.env.S3_ENDPOINT || "").replace(/\/+$/, "") - const parseLabels = (value = "") => { const labels: Record = {} const labelPattern = /(\w+)="((?:\\"|[^"])*)"/g @@ -63,20 +63,17 @@ const serviceState = (ok: boolean, detail?: Record) => ({ ...detail, }) -const checkHttp = async (url: string, timeoutMs = 3000) => { +export const checkFileStorage = async (client = s3, bucket = secrets.S3_BUCKET, timeoutMs = 3000) => { const controller = new AbortController() const timeout = setTimeout(() => controller.abort(), timeoutMs) try { - const response = await fetch(url, { signal: controller.signal }) - return serviceState(response.ok, { - httpStatus: response.status, - url, - }) - } catch (err: any) { + if (!client || !bucket) return serviceState(false, { error: "S3-Dateispeicher ist nicht eingerichtet" }) + await client.send(new HeadBucketCommand({ Bucket: bucket }), { abortSignal: controller.signal }) + return serviceState(true, { provider: process.env.FEDEO_STORAGE_PROVIDER === "seaweedfs" ? "seaweedfs" : "s3" }) + } catch { return serviceState(false, { - url, - error: err?.message || "HTTP-Abfrage fehlgeschlagen", + error: controller.signal.aborted ? "S3-Prüfung hat das Zeitlimit überschritten" : "S3-Bucket nicht erreichbar oder Zugriff verweigert", }) } finally { clearTimeout(timeout) @@ -116,7 +113,6 @@ export const buildSystemStatus = async (server: FastifyInstance) => { const uname = nodeMetrics?.get("node_uname_info")?.[0]?.labels || null const databaseCheck = await server.db.execute("SELECT NOW() as now") - const minioUrl = s3EndpointUrl() return { checkedAt: checkedAt.toISOString(), @@ -160,9 +156,8 @@ export const buildSystemStatus = async (server: FastifyInstance) => { url: nodeExporterMetricsUrl, error: nodeExporterError, }), - minio: minioUrl ? await checkHttp(`${minioUrl}/minio/health/live`) : serviceState(false, { - error: "S3_ENDPOINT ist nicht gesetzt", - }), + // Preserve the response key for older clients; check the authenticated S3 API for every provider. + minio: await checkFileStorage(), }, } } diff --git a/backend/src/routes/documentInbox.ts b/backend/src/routes/documentInbox.ts new file mode 100644 index 00000000..265cebb2 --- /dev/null +++ b/backend/src/routes/documentInbox.ts @@ -0,0 +1,47 @@ +import { and, eq } from "drizzle-orm" +import type { FastifyInstance } from "fastify" +import { authProfiles } from "../../db/schema" +import { createScannerInboxService, SCANNER_DAV_PATH, SCANNER_UPLOAD_LIMIT, type ScannerInboxService } from "../modules/scanner-inbox.service" + +export default async function documentInboxRoutes(server: FastifyInstance, options: { service?: ScannerInboxService }) { + const service = options.service || createScannerInboxService(server.db) + server.addHook("preHandler", async (req, reply) => { + if (!req.user?.tenant_id) return reply.code(400).send({ error: "Bitte einen Mandanten auswählen." }) + const [profile] = await server.db.select({ portal: authProfiles.customer_for_portal }).from(authProfiles) + .where(and(eq(authProfiles.tenant_id, req.user.tenant_id), eq(authProfiles.user_id, req.user.user_id))).limit(1) + if (profile?.portal) return reply.code(403).send({ error: "Die Dokumentenablage ist nur intern verfügbar." }) + if (req.routeOptions.url?.includes("/scanner") && !req.user.is_admin) { + return reply.code(403).send({ error: "Scanner-Zugänge können nur Administratoren verwalten." }) + } + reply.header("Cache-Control", "no-store") + }) + server.get("/document-inbox", async (req, reply) => { + const query = req.query as { limit?: string; offset?: string; search?: string } + const limit = Number(query.limit ?? 50) + const offset = Number(query.offset ?? 0) + if (!Number.isSafeInteger(limit) || limit < 1 || limit > 100 || !Number.isSafeInteger(offset) || offset < 0 || (query.search?.length || 0) > 200) { + return reply.code(400).send({ error: "Ungültige Such- oder Seiteneinstellungen." }) + } + return service.list(req.user.tenant_id!, limit, offset, query.search?.trim() || "") + }) + server.get("/document-inbox/filing-options", async req => service.filingOptions(req.user.tenant_id!)) + server.post<{ Params: { id: string }; Body: { folder: string | null; type: string } }>("/document-inbox/:id/file", { + schema: { + params: { type: "object", required: ["id"], properties: { id: { type: "string", format: "uuid" } } }, + body: { type: "object", required: ["folder", "type"], additionalProperties: false, properties: { + folder: { anyOf: [{ type: "string", format: "uuid" }, { type: "null" }] }, + type: { type: "string", format: "uuid" }, + } }, + }, + }, async req => service.fileDocument(req.user.tenant_id!, req.user.user_id, req.params.id, req.body.folder, req.body.type)) + server.get("/document-inbox/scanner", async req => ({ + connection: await service.connection(req.user.tenant_id!), path: SCANNER_DAV_PATH, maxFileSize: SCANNER_UPLOAD_LIMIT, + })) + server.post("/document-inbox/scanner/credentials", async req => ({ + connection: await service.credentials(req.user.tenant_id!), path: SCANNER_DAV_PATH, + })) + server.delete("/document-inbox/scanner", async (_req, reply) => { + await service.disable(_req.user.tenant_id!) + return reply.code(204).send() + }) +} diff --git a/backend/src/routes/scannerInboxGateway.ts b/backend/src/routes/scannerInboxGateway.ts new file mode 100644 index 00000000..00bd4da0 --- /dev/null +++ b/backend/src/routes/scannerInboxGateway.ts @@ -0,0 +1,74 @@ +import type { FastifyInstance, FastifyRequest } from "fastify" +import { createScannerInboxService, SCANNER_UPLOAD_LIMIT, scannerError, type ScannerIdentity, type ScannerInboxService } from "../modules/scanner-inbox.service" + +const escapeXml = (text: string) => text.replace(/[<>&"']/g, char => ({ "<": "<", ">": ">", "&": "&", '"': """, "'": "'" }[char]!)) +const methods = "OPTIONS, PROPFIND, HEAD, PUT" + +export default async function scannerInboxGateway(server: FastifyInstance, options: { service?: ScannerInboxService }) { + const service = options.service || createScannerInboxService(server.db) + const identities = new WeakMap() + server.addHttpMethod("PROPFIND", { hasBody: true }) + server.addHttpMethod("MKCOL", { hasBody: true }) + // Keep raw scanner bytes, even when firmware supplies application/octet-stream or no MIME type. + server.removeAllContentTypeParsers() + server.addContentTypeParser("*", { parseAs: "buffer", bodyLimit: SCANNER_UPLOAD_LIMIT }, (_req, body, done) => done(null, body)) + + server.addHook("onRequest", async (req, reply) => { + reply.header("Cache-Control", "no-store") + const encoded = /^Basic ([A-Za-z0-9+/]+={0,2})$/i.exec(req.headers.authorization || "")?.[1] + const value = encoded && encoded.length < 1024 ? Buffer.from(encoded, "base64").toString("utf8") : "" + const separator = value.indexOf(":") + const identity = separator > 0 ? await service.authenticate(value.slice(0, separator), value.slice(separator + 1)) : null + if (!identity) return reply.header("WWW-Authenticate", 'Basic realm="FEDEO Scanner", charset="UTF-8"') + .code(401).send({ error: "Scanner-Zugangsdaten erforderlich." }) + identities.set(req, identity) + }) + + const handle = async (req: FastifyRequest, reply: any) => { + const identity = identities.get(req)! + const filename = (req.params as { "*"?: string })["*"] || "" + if (filename && (filename.length > 200 || filename.startsWith(".") || /[\\/\u0000-\u001f\u007f]/.test(filename))) { + throw scannerError(400, "Unterordner und ungültige Dateinamen werden nicht unterstützt.") + } + if (req.method === "OPTIONS") return reply.header("DAV", "1").header("Allow", methods).code(200).send() + if (req.method === "MKCOL") return reply.header("Allow", methods).code(filename ? 403 : 405).send() + if (req.method === "PUT") { + if (!filename) throw scannerError(400, "Ein Dateiname ist erforderlich.") + if (req.headers["content-range"]) throw scannerError(400, "Bitte die vollständige Datei übertragen.") + if (req.headers["if-match"] || req.headers["if-unmodified-since"] || req.headers.if) { + throw scannerError(412, "Änderungen an vorhandenen Dokumenten werden nicht unterstützt.") + } + const body = Buffer.isBuffer(req.body) ? req.body : Buffer.alloc(0) + const result = await service.accept(identity, filename, body, req.headers["if-none-match"] === "*") + return reply.header("ETag", `"${result.checksum}"`).code(result.created ? 201 : 204).send() + } + const entry = filename ? await service.find(identity.tenantId, filename) : null + if (filename && !entry) return reply.code(404).send() + if (req.method === "HEAD") { + if (entry) reply.header("Content-Length", entry.size).header("Content-Type", entry.mimeType).header("ETag", `"${entry.checksum}"`) + return reply.code(200).send() + } + if (req.method === "PROPFIND") { + // This is an upload inbox, not a browsable archive. Depth 1 deliberately exposes no other files. + if (req.headers.depth && !["0", "1"].includes(String(req.headers.depth))) { + return reply.type("application/xml").code(403).send('') + } + const prefixHeader = req.headers["x-forwarded-prefix"] + const prefix = typeof prefixHeader === "string" && /^(\/[A-Za-z0-9._~-]+)*\/?$/.test(prefixHeader) ? prefixHeader.replace(/\/$/, "") : "" + const href = prefix + req.url.split("?")[0] + (!filename && !req.url.split("?")[0].endsWith("/") ? "/" : "") + const props = entry + ? `${entry.size}${entry.mimeType}"${entry.checksum}"${entry.receivedAt.toUTCString()}` + : '' + return reply.header("DAV", "1").type("application/xml; charset=utf-8").code(207).send( + `${escapeXml(href)}${escapeXml(filename || "FEDEO Dokumentenablage")}${props}HTTP/1.1 200 OK`) + } + return reply.header("Allow", methods).code(405).send() + } + + // Both slash forms work without redirects (some scanners discard authentication on redirects). + for (const url of ["/", "/*"]) { + server.route<{}, { cors: false }>({ method: ["OPTIONS", "PROPFIND", "HEAD", "PUT", "MKCOL", "GET", "DELETE", "POST", "PATCH"], + // Scanner OPTIONS requests are WebDAV discovery, not browser CORS preflights. + url, config: { cors: false }, bodyLimit: SCANNER_UPLOAD_LIMIT, handler: handle }) + } +} diff --git a/backend/src/utils/resource.config.ts b/backend/src/utils/resource.config.ts index dd857d17..11e441d5 100644 --- a/backend/src/utils/resource.config.ts +++ b/backend/src/utils/resource.config.ts @@ -49,7 +49,7 @@ export const resourceConfig = { projects: { searchColumns: ["name","customerRef","projectNumber","notes"], mtoLoad: ["customer","plant","contract","projecttype"], - mtmLoad: ["tasks", "files","createddocuments"], + mtmLoad: ["tasks", "files","createddocuments", "events"], table: projects, numberRangeHolder: "projectNumber" }, diff --git a/backend/tests/scannerInbox.test.ts b/backend/tests/scannerInbox.test.ts new file mode 100644 index 00000000..4a6254b8 --- /dev/null +++ b/backend/tests/scannerInbox.test.ts @@ -0,0 +1,330 @@ +import assert from "node:assert/strict" +import test from "node:test" +import { randomUUID } from "node:crypto" +import { execFile } from "node:child_process" +import { promisify } from "node:util" +import { readFile, mkdtemp, mkdir, writeFile, rm } from "node:fs/promises" +import path from "node:path" +import os from "node:os" +import Fastify from "fastify" +import { Pool } from "pg" +import { drizzle } from "drizzle-orm/node-postgres" +import { migrate } from "drizzle-orm/node-postgres/migrator" +import { getTableColumns } from "drizzle-orm" +import { PDFDocument } from "pdf-lib" +import { files } from "../db/schema" +import gateway from "../src/routes/scannerInboxGateway" +import inboxRoutes from "../src/routes/documentInbox" +import corsPlugin from "../src/plugins/cors" +import { createScannerInboxService, SCANNER_UPLOAD_LIMIT, validateScannerFile, type ScannerInboxService } from "../src/modules/scanner-inbox.service" + +const execute = promisify(execFile) +const basic = (username = "scanner", password = "secret") => ({ authorization: `Basic ${Buffer.from(`${username}:${password}`).toString("base64")}` }) +const samplePdf = Buffer.from("%PDF-1.7\nscanner fixture\n%%EOF") + +test("scanner formats are verified independently of the supplied content type", () => { + assert.equal(validateScannerFile("scan.PDF", samplePdf), "application/pdf") + assert.equal(validateScannerFile("scan.jpg", Buffer.from([255, 216, 255, 0])), "image/jpeg") + assert.equal(validateScannerFile("scan.png", Buffer.from([137, 80, 78, 71, 13, 10, 26, 10])), "image/png") + assert.equal(validateScannerFile("scan.tiff", Buffer.from("49492a00", "hex")), "image/tiff") + for (const [filename, body, status] of [ + ["scan.pdf", Buffer.alloc(0), 400], ["scan.pdf", Buffer.from("error"), 415], + ["scan.pdf", Buffer.from("%PDF-truncated"), 415], ["scan.zip", samplePdf, 415], + ["../scan.pdf", samplePdf, 400], ["a/b.pdf", samplePdf, 400], ["a\\b.pdf", samplePdf, 400], + [".hidden.pdf", samplePdf, 400], ["a\u0000.pdf", samplePdf, 400], + ] as const) assert.throws(() => validateScannerFile(filename, body), { statusCode: status }) + assert.throws(() => validateScannerFile("large.pdf", Buffer.alloc(SCANNER_UPLOAD_LIMIT + 1)), { statusCode: 413 }) +}) + +const protocolFixture = async () => { + const calls: any[] = [] + const service = { + authenticate: async (username: string, password: string) => username === "scanner" && password === "secret" ? { tenantId: 7 } : null, + accept: async (...args: any[]) => { calls.push(args); validateScannerFile(args[1], args[2]); return { created: true, checksum: "abc" } }, + find: async () => null, + } as unknown as ScannerInboxService + const app = Fastify() + await app.register(gateway, { prefix: "/scanner-inbox", service }) + // Match production: the global CORS plugin is registered after the scanner gateway. + await app.register(corsPlugin) + return { app, calls } +} + +test("WebDAV authentication happens before body parsing, including discovery requests", async t => { + const { app } = await protocolFixture() + t.after(() => app.close()) + for (const method of ["OPTIONS", "PROPFIND", "PUT", "HEAD"] as const) { + const res = await app.inject({ method, url: "/scanner-inbox/scan.pdf" }) + assert.equal(res.statusCode, 401) + assert.match(res.headers["www-authenticate"] as string, /^Basic /) + } + const res = await app.inject({ method: "PUT", url: "/scanner-inbox/scan.pdf", headers: { ...basic("scanner", "wrong"), "content-type": "application/json" }, payload: "not json" }) + assert.equal(res.statusCode, 401) +}) + +test("Epson discovery works with both slash forms, XML bodies and a backend proxy prefix", async t => { + const { app } = await protocolFixture() + t.after(() => app.close()) + for (const url of ["/scanner-inbox", "/scanner-inbox/"]) { + const options = await app.inject({ method: "OPTIONS", url, headers: basic() }) + assert.equal(options.statusCode, 200) + assert.match(options.headers.allow as string, /PUT/) + const head = await app.inject({ method: "HEAD", url, headers: basic() }) + assert.equal(head.statusCode, 200) + const res = await app.inject({ method: "PROPFIND", url, headers: { ...basic(), depth: "1", "content-type": "text/xml", "x-forwarded-prefix": "/backend" }, payload: '' }) + assert.equal(res.statusCode, 207, res.body) + assert.match(res.body, /\/backend\/scanner-inbox\/<\/d:href>/) + assert.match(res.body, //) + assert.equal((res.body.match(//g) || []).length, 1) + } + assert.equal((await app.inject({ method: "PROPFIND", url: "/scanner-inbox/", headers: { ...basic(), depth: "infinity" } })).statusCode, 403) +}) + +test("raw PDFs reach storage unchanged and scanner credentials cannot download or delete", async t => { + const { app, calls } = await protocolFixture() + t.after(() => app.close()) + for (const contentType of ["application/pdf", "application/octet-stream", undefined]) { + const res = await app.inject({ method: "PUT", url: "/scanner-inbox/Rechnung%20%26%20Beleg.pdf", headers: { ...basic(), ...(contentType ? { "content-type": contentType } : {}) }, payload: samplePdf }) + assert.equal(res.statusCode, 201, res.body) + assert.equal(calls.at(-1)[0].tenantId, 7) + assert.equal(calls.at(-1)[1], "Rechnung & Beleg.pdf") + assert.deepEqual(calls.at(-1)[2], samplePdf) + } + for (const method of ["GET", "DELETE", "POST", "PATCH"] as const) { + assert.equal((await app.inject({ method, url: "/scanner-inbox/", headers: basic() })).statusCode, 405) + } + for (const name of ["sub/scan.pdf", "sub%2Fscan.pdf", "..%5Cscan.pdf"]) { + assert.equal((await app.inject({ method: "PUT", url: "/scanner-inbox/" + name, headers: basic(), payload: samplePdf })).statusCode, 400) + } + assert.equal((await app.inject({ method: "PUT", url: "/scanner-inbox/scan.pdf", headers: { ...basic(), "content-range": "bytes 0-10/20" }, payload: samplePdf })).statusCode, 400) + assert.equal((await app.inject({ method: "PUT", url: "/scanner-inbox/scan.pdf", headers: { ...basic(), "if-match": '"old"' }, payload: samplePdf })).statusCode, 412) + assert.equal((await app.inject({ method: "PUT", url: "/scanner-inbox/scan.pdf", headers: { ...basic(), "content-type": "application/pdf", "content-length": String(SCANNER_UPLOAD_LIMIT + 1) }, payload: samplePdf })).statusCode, 413) +}) + +// Uses only a disposable database and fake object storage, never DATABASE_URL or production secrets. +test("scanner inbox integration: migration, persistence, isolation, retries and management", { + skip: !process.env.FEDEO_TEST_POSTGRES_IMAGE, +}, async t => { + const container = "fedeo-scanner-inbox-test-" + randomUUID() + const dbPassword = randomUUID() + await execute("docker", ["run", "--rm", "-d", "--name", container, "-e", `POSTGRES_PASSWORD=${dbPassword}`, "-p", "127.0.0.1::5432", process.env.FEDEO_TEST_POSTGRES_IMAGE!]) + let pool: Pool | undefined + const app = Fastify() + const tempMigrations = await mkdtemp(path.join(os.tmpdir(), "fedeo-scanner-inbox-")) + t.after(async () => { + await app.close() + await pool?.end() + await execute("docker", ["rm", "-f", container]) + await rm(tempMigrations, { recursive: true, force: true }) + }) + const { stdout } = await execute("docker", ["port", container, "5432/tcp"]) + pool = new Pool({ host: "127.0.0.1", port: Number(stdout.trim().split(":").at(-1)), user: "postgres", password: dbPassword, database: "postgres", connectionTimeoutMillis: 1000 }) + for (let attempt = 0; ; attempt++) { + try { await pool.query("SELECT 1"); break } catch (error) { + if (attempt >= 80) throw error + await new Promise(resolve => setTimeout(resolve, 100)) + } + } + const columns = Object.values(getTableColumns(files)).map(column => { + const suffix = column.name === "id" ? " PRIMARY KEY" : column.name === "created_at" ? " DEFAULT now()" : column.name === "archived" ? " DEFAULT false" : "" + return `"${column.name}" ${column.getSQLType()}${suffix}` + }).join(", ") + await pool.query(`CREATE TABLE tenants (id bigint PRIMARY KEY, locked text); + INSERT INTO tenants VALUES (1, null), (2, null); + CREATE TABLE files (${columns}, CHECK (name <> 'reject.pdf')); + CREATE TABLE filetags (id uuid PRIMARY KEY, tenant bigint, name text, archived boolean DEFAULT false); + CREATE TABLE folders (id uuid PRIMARY KEY, tenant bigint, name text, parent uuid, "standardFiletype" uuid, + "standardFiletypeIsOptional" boolean DEFAULT true, archived boolean DEFAULT false); + CREATE TABLE auth_profiles (tenant_id bigint, user_id uuid, customer_for_portal bigint);`) + const migrationRoot = path.resolve(__dirname, "../db/migrations") + const journal = JSON.parse(await readFile(path.join(migrationRoot, "meta/_journal.json"), "utf8")) + const entries = ["0073_scanner_document_inbox", "0074_scanner_inbox_filing"].map(tag => journal.entries.find((item: any) => item.tag === tag)) + await mkdir(path.join(tempMigrations, "meta")) + for (const entry of entries) { + assert.ok(entry) + assert.ok(journal.entries.filter((item: any) => item.idx < entry.idx).every((item: any) => item.when < entry.when)) + await writeFile(path.join(tempMigrations, entry.tag + ".sql"), await readFile(path.join(migrationRoot, entry.tag + ".sql"))) + } + await writeFile(path.join(tempMigrations, "meta/_journal.json"), JSON.stringify({ ...journal, entries })) + const db = drizzle(pool) as any + await migrate(db, { migrationsFolder: tempMigrations }) + await migrate(db, { migrationsFolder: tempMigrations }) + const stored = new Map() + let storageFailure = false + const service = createScannerInboxService(db, { + async put(key, body) { stored.set(key, Buffer.from(body)); if (storageFailure) throw new Error("Simulated object store failure") }, + async remove(key) { stored.delete(key) }, + }) + const first = await service.credentials(1) + const second = await service.credentials(2) + assert.equal(first.password.length, 20, "Epson destination password limit") + assert.ok(first.username.length <= 30) + assert.equal((await service.connection(1) as any).passwordHash, undefined) + assert.equal((await pool.query("SELECT password_hash FROM scanner_inbox_connections WHERE tenant_id=1")).rows[0].password_hash.length, 64) + const userId = randomUUID() + app.decorate("db", db) + await app.register(gateway, { prefix: "/scanner-inbox", service }) + await app.register(corsPlugin) + await app.register(async api => { + api.addHook("onRequest", async req => { + req.user = { tenant_id: Number(req.headers["x-test-tenant"] || 1) || null, user_id: userId, email: "test@example.invalid", is_admin: req.headers["x-test-admin"] !== "false" } + }) + await api.register(inboxRoutes, { service }) + }, { prefix: "/api" }) + const doc = await PDFDocument.create() + doc.addPage() + doc.addPage() + const pdf = Buffer.from(await doc.save()) + const send = (name: string, payload = pdf, headers: Record = basic(first.username, first.password)) => app.inject({ method: "PUT", url: `/scanner-inbox/${encodeURIComponent(name)}`, headers: { "content-type": "application/pdf", ...headers }, payload }) + + await t.test("stores one unchanged two-page PDF as one document without extraction", async () => { + const res = await send("scan.pdf") + assert.equal(res.statusCode, 201, res.body) + const row = (await pool.query("SELECT * FROM files")).rows[0] + assert.equal(row.tenant, "1") + assert.equal(row.mimeType, "application/pdf") + assert.equal(row.extracted_text, null) + assert.deepEqual(stored.get(row.path), pdf) + assert.equal((await PDFDocument.load(stored.get(row.path)!)).getPageCount(), 2) + const listing = await app.inject({ method: "GET", url: "/api/document-inbox" }) + assert.equal(listing.json().total, 1) + assert.equal(listing.json().documents[0].name, "scan.pdf") + assert.equal((await app.inject({ method: "HEAD", url: "/scanner-inbox/scan.pdf", headers: basic(first.username, first.password) })).statusCode, 200) + }) + await t.test("serialises simultaneous retries and preserves existing content on filename conflicts", async () => { + const retry = await Promise.all([send("scan.pdf"), send("scan.pdf")]) + assert.deepEqual(retry.map(res => res.statusCode), [204, 204]) + const concurrent = await Promise.all([send("parallel.pdf"), send("parallel.pdf")]) + assert.deepEqual(concurrent.map(res => res.statusCode).sort(), [201, 204]) + assert.equal((await send("scan.pdf", samplePdf)).statusCode, 409) + assert.equal((await send("scan.pdf", pdf, { ...basic(first.username, first.password), "if-none-match": "*" })).statusCode, 412) + assert.equal(stored.size, 2) + }) + await t.test("credentials bind writes, metadata and lists to a tenant", async () => { + const otherHeaders = basic(second.username, second.password) + assert.equal((await app.inject({ method: "HEAD", url: "/scanner-inbox/scan.pdf", headers: otherHeaders })).statusCode, 404) + assert.equal((await send("scan.pdf", pdf, otherHeaders)).statusCode, 201) + const otherList = await app.inject({ method: "GET", url: "/api/document-inbox", headers: { "x-test-tenant": "2" } }) + assert.equal(otherList.json().total, 1) + const own = await app.inject({ method: "GET", url: "/api/document-inbox?limit=1&offset=1" }) + assert.equal(own.json().total, 2) + assert.equal(own.json().documents.length, 1) + const filtered = await app.inject({ method: "GET", url: "/api/document-inbox?search=parallel" }) + assert.equal(filtered.json().total, 1) + assert.equal((await app.inject({ method: "GET", url: "/api/document-inbox?limit=-1" })).statusCode, 400) + }) + await t.test("storage and database failures leave no incomplete file or inbox entry", async () => { + const before = stored.size + storageFailure = true + assert.equal((await send("failed.pdf")).statusCode, 500) + storageFailure = false + assert.equal(stored.size, before) + assert.equal((await send("reject.pdf")).statusCode, 500) + assert.equal(stored.size, before) + assert.equal((await pool.query("SELECT count(*) FROM files WHERE name IN ('failed.pdf', 'reject.pdf')")).rows[0].count, "0") + assert.equal((await send("failed.pdf")).statusCode, 201) + }) + const targetFolder = randomUUID() + const targetType = randomUUID() + const alternativeType = randomUUID() + const foreignFolder = randomUUID() + const foreignType = randomUUID() + const archivedFolder = randomUUID() + const archivedType = randomUUID() + await pool.query(`INSERT INTO filetags (id, tenant, name, archived) VALUES + ($1, 1, 'Rechnung', false), ($2, 1, 'Sonstiges', false), ($3, 2, 'Fremder Typ', false), ($4, 1, 'Archiviert', true)`, + [targetType, alternativeType, foreignType, archivedType]) + await pool.query(`INSERT INTO folders (id, tenant, name, "standardFiletype", "standardFiletypeIsOptional", archived) VALUES + ($1, 1, 'Rechnungen', $2, false, false), ($3, 2, 'Fremder Ordner', null, true, false), ($4, 1, 'Archiviert', null, true, true)`, + [targetFolder, targetType, foreignFolder, archivedFolder]) + const fileInto = (id: string, folder: string | null = targetFolder, type: string = targetType, headers = {}) => + app.inject({ method: "POST", url: `/api/document-inbox/${id}/file`, payload: { folder, type }, headers }) + await t.test("filing options and destinations exclude other tenants and archived entries", async () => { + const options = await app.inject({ method: "GET", url: "/api/document-inbox/filing-options" }) + assert.equal(options.statusCode, 200) + assert.deepEqual(options.json().folders.map((item: any) => item.id), [targetFolder]) + assert.equal(options.json().folders[0].standardFiletypeIsOptional, false) + assert.deepEqual(options.json().types.map((item: any) => item.id).sort(), [targetType, alternativeType].sort()) + const id = (await service.list(1, 50, 0, "scan.pdf")).documents[0].id + for (const [folder, type] of [[foreignFolder, targetType], [archivedFolder, targetType], [targetFolder, foreignType], + [null, archivedType], [targetFolder, alternativeType], [randomUUID(), targetType], [null, randomUUID()]]) { + assert.equal((await fileInto(id, folder, type!)).statusCode, 400) + } + assert.equal((await fileInto(id, null, targetType, { "x-test-tenant": "2" })).statusCode, 404) + assert.equal((await fileInto(randomUUID())).statusCode, 404) + for (const payload of [{ folder: null }, { type: targetType }, { folder: "invalid", type: targetType }, { folder: null, type: null }]) { + assert.equal((await app.inject({ method: "POST", url: `/api/document-inbox/${id}/file`, payload })).statusCode, 400) + } + await pool.query("UPDATE tenants SET locked='maintenance_tenant' WHERE id=1") + assert.equal((await fileInto(id)).statusCode, 423) + await pool.query("UPDATE tenants SET locked=null WHERE id=1") + await pool.query("INSERT INTO auth_profiles VALUES (1, $1, 123)", [userId]) + assert.equal((await fileInto(id)).statusCode, 403) + assert.equal((await app.inject({ method: "GET", url: "/api/document-inbox/filing-options" })).statusCode, 403) + await pool.query("DELETE FROM auth_profiles") + assert.equal((await service.list(1, 50, 0, "scan.pdf")).total, 1) + const row = (await pool.query("SELECT folder, type FROM files WHERE id=$1", [id])).rows[0] + assert.deepEqual(row, { folder: null, type: null }) + }) + await t.test("filing updates the original file once, keeps its content and cannot be undone by scanner retries", async () => { + const id = (await service.list(1, 50, 0, "scan.pdf")).documents[0].id + const before = (await pool.query("SELECT * FROM files WHERE id=$1", [id])).rows[0] + const countBefore = stored.size + const responses = await Promise.all([fileInto(id, targetFolder, targetType, { "x-test-admin": "false" }), fileInto(id)]) + assert.deepEqual(responses.map(response => response.statusCode).sort(), [200, 409]) + const row = (await pool.query("SELECT * FROM files WHERE id=$1", [id])).rows[0] + assert.equal(row.folder, targetFolder) + assert.equal(row.type, targetType) + assert.equal(row.updated_by, userId) + assert.ok(row.updated_at) + assert.equal(row.path, before.path) + assert.equal(row.name, before.name) + assert.deepEqual(stored.get(row.path), pdf) + assert.equal((await service.list(1, 50, 0, "scan.pdf")).total, 0) + assert.equal((await send("scan.pdf")).statusCode, 204) + assert.equal((await service.list(1, 50, 0, "scan.pdf")).total, 0) + assert.equal((await service.list(2, 50, 0, "scan.pdf")).total, 1) + assert.equal(stored.size, countBefore) + assert.equal((await app.inject({ method: "HEAD", url: "/scanner-inbox/scan.pdf", headers: basic(first.username, first.password) })).statusCode, 200) + const rootId = (await service.list(1, 50, 0, "parallel.pdf")).documents[0].id + assert.equal((await fileInto(rootId, null, alternativeType)).statusCode, 200) + assert.deepEqual((await pool.query("SELECT folder, type FROM files WHERE id=$1", [rootId])).rows[0], { folder: null, type: alternativeType }) + }) + await t.test("a failure marking the receipt rolls back file classification", async () => { + const id = (await service.list(1, 50, 0, "failed.pdf")).documents[0].id + await pool.query("ALTER TABLE scanner_inbox_documents ADD CONSTRAINT simulate_filing_failure CHECK (remote_filename <> 'failed.pdf' OR filed_at IS NULL)") + assert.equal((await fileInto(id)).statusCode, 500) + assert.deepEqual((await pool.query("SELECT folder, type FROM files WHERE id=$1", [id])).rows[0], { folder: null, type: null }) + assert.equal((await service.list(1, 50, 0, "failed.pdf")).total, 1) + await pool.query("ALTER TABLE scanner_inbox_documents DROP CONSTRAINT simulate_filing_failure") + await pool.query("UPDATE files SET archived=true WHERE id=$1", [id]) + assert.equal((await fileInto(id)).statusCode, 404) + await pool.query("UPDATE files SET archived=false WHERE id=$1", [id]) + }) + await t.test("maintenance, portal access and administrator-only settings are enforced", async () => { + await pool.query("UPDATE tenants SET locked='maintenance_tenant' WHERE id=1") + assert.equal((await send("maintenance.pdf")).statusCode, 423) + await pool.query("UPDATE tenants SET locked=null WHERE id=1") + assert.equal((await app.inject({ method: "GET", url: "/api/document-inbox", headers: { "x-test-tenant": "0" } })).statusCode, 400) + for (const [method, url] of [["GET", "/api/document-inbox/scanner"], ["POST", "/api/document-inbox/scanner/credentials"], ["DELETE", "/api/document-inbox/scanner"]] as const) { + assert.equal((await app.inject({ method, url, headers: { "x-test-admin": "false" } })).statusCode, 403) + } + assert.equal((await app.inject({ method: "GET", url: "/api/document-inbox", headers: { "x-test-admin": "false" } })).statusCode, 200) + await pool.query("INSERT INTO auth_profiles VALUES (1, $1, 123)", [userId]) + assert.equal((await app.inject({ method: "GET", url: "/api/document-inbox" })).statusCode, 403) + await pool.query("DELETE FROM auth_profiles") + }) + await t.test("revocation and rotation reject old credentials without removing documents", async () => { + const oldIdentity = await service.authenticate(first.username, first.password) + assert.equal((await app.inject({ method: "DELETE", url: "/api/document-inbox/scanner" })).statusCode, 204) + assert.equal((await send("disabled.pdf")).statusCode, 401) + const rotated = await app.inject({ method: "POST", url: "/api/document-inbox/scanner/credentials" }) + assert.equal(rotated.statusCode, 200) + assert.equal(rotated.headers["cache-control"], "no-store") + assert.equal(rotated.json().connection.username, first.username) + assert.equal((await send("old.pdf")).statusCode, 401) + await assert.rejects(service.accept(oldIdentity!, "late.pdf", pdf), { statusCode: 401 }) + assert.equal((await send("new.pdf", pdf, basic(first.username, rotated.json().connection.password))).statusCode, 201) + assert.equal((await service.list(1, 50, 0, "")).total, 2) + }) +}) diff --git a/backend/tests/selfhostUpdates.test.ts b/backend/tests/selfhostUpdates.test.ts index e21e4a6a..1f217f76 100644 --- a/backend/tests/selfhostUpdates.test.ts +++ b/backend/tests/selfhostUpdates.test.ts @@ -128,6 +128,20 @@ test("Unix client bounds response size, deadline, and protocol shape", async t = }); } }); +test("provider status and plan cross the socket boundary without private storage configuration", async t => { + const client = await socketFixture(t, (_req, res) => res.end(JSON.stringify({ + apiVersion: 1, acceptingRequests: true, engine: { status: "recovered", phase: "resolved" }, installed: {}, + storage: { provider: "seaweedfs", migrationPending: false, service: { secret: "hidden" } }, + request: { status: "checked", plan: { updateAvailable: true, requiresComposeAdoption: false, retiredServices: [], + storageProvider: "seaweedfs", storageImageRetained: true, storageBackupPaths: ["/private/path"] } }, + }))); + const { body } = await client("GET", "/v1/status") as { body: any }; + assert.deepEqual(body.storage, { provider: "seaweedfs", migrationPending: false }); + assert.equal(body.request.plan.storageProvider, "seaweedfs"); + assert.equal(body.request.plan.storageImageRetained, true); + assert.ok(!JSON.stringify(body).includes("hidden")); + assert.ok(!JSON.stringify(body).includes("private/path")); +}); test("Unix client validates bounded log responses and their request association", async t => { let payload: any = { requestId: id, logs: [{ source: "commands", content: "pull access denied", truncated: true, path: "/private/commands.log" }], private: "omitted" }; diff --git a/backend/tests/systemStatusStorage.test.ts b/backend/tests/systemStatusStorage.test.ts new file mode 100644 index 00000000..e2e5b443 --- /dev/null +++ b/backend/tests/systemStatusStorage.test.ts @@ -0,0 +1,29 @@ +import assert from "node:assert/strict"; +import test from "node:test"; +import { HeadBucketCommand } from "@aws-sdk/client-s3"; +import { checkFileStorage } from "../src/modules/system-status.service"; + +test("file storage health uses an authenticated S3 bucket request for every provider", async () => { + const client = { send: async (command: any, options: any) => { + assert.ok(command instanceof HeadBucketCommand); + assert.deepEqual(command.input, { Bucket: "fedeo" }); + assert.ok(options.abortSignal instanceof AbortSignal); + } }; + assert.equal((await checkFileStorage(client, "fedeo")).ok, true); +}); + +test("unconfigured or denied S3 access is unhealthy and does not disclose SDK details", async () => { + assert.equal((await checkFileStorage(null, "fedeo")).ok, false); + const result = await checkFileStorage({ send: async () => { throw new Error("secret@private-host"); } }, "fedeo"); + assert.equal(result.ok, false); + assert.ok(!JSON.stringify(result).includes("private-host")); +}); + +test("S3 health aborts a hung request at its deadline", async () => { + const client = { send: (_command: any, options: any) => new Promise((_resolve, reject) => { + options.abortSignal.addEventListener("abort", () => reject(new Error("aborted")), { once: true }); + }) }; + const result = await checkFileStorage(client, "fedeo", 10); + assert.equal(result.ok, false); + assert.match(result.error, /Zeitlimit/); +}); diff --git a/docs/README.md b/docs/README.md index 273c8b03..7b410691 100644 --- a/docs/README.md +++ b/docs/README.md @@ -7,3 +7,6 @@ Diese Dokumentation unterstützt dich bei der täglichen Nutzung von FEDEO. - [Bedienung](./bedienung/README.md) - [Fach- und Technikkonzept für das Lagersystem](./lagersystem-konzept.md) - [Zentraler Push-Server für Selfhost-Instanzen](./zentraler-push-server.md) +- [Konzept zum Austausch von MinIO](./minio-austausch-konzept.md) +- [MinIO-Umstellung: ausführbarer Pilot](./minio-umstellung-pilot.md) +- [Konzept für föderierte Chats und externe Projektteilnehmer](./chat-foederation-konzept.md) diff --git a/docs/chat-foederation-konzept.md b/docs/chat-foederation-konzept.md new file mode 100644 index 00000000..df1d1734 --- /dev/null +++ b/docs/chat-foederation-konzept.md @@ -0,0 +1,279 @@ +# Konzept: Föderierte Chats und externe Projektteilnehmer + +Stand: 26. September 2026. Status: Architekturvorschlag auf Basis des FEDEO-Codes bei Commit `df48c976`. Dieses Dokument beschreibt ein Zielbild; Föderation, Gastzugang und die genannten APIs sind noch nicht implementiert. Es wurden keine Einladungen verschickt und keine laufenden Instanzen verändert. + +## 1. Empfehlung + +FEDEO erhält eine gemeinsame Berechtigungsschicht für die Zusammenarbeit über Mandantengrenzen hinweg und einen darauf aufbauenden Transport zwischen FEDEO-Instanzen. Benutzer bleiben bei ihrer eigenen Instanz angemeldet. Ein Chat beziehungsweise Projekt hat genau einen verantwortlichen Mandanten und eine führende Instanz, die Mitgliedschaften, Freigaben und Änderungen verbindlich entscheidet. + +Die gleiche Funktion soll drei Fälle abdecken: + +| Fall | Verhalten | +| --- | --- | +| Zwei Mandanten derselben Instanz | Explizite Einladung und dieselben objektbezogenen Rechte; Aufruf intern ohne Netzwerktransport | +| Mandanten verschiedener FEDEO-Instanzen | Gleiche Oberfläche; signierter Austausch zwischen den Backends | +| Person ohne FEDEO-Konto | Eingeplanter Gastzugang beim Projekteigentümer, beschränkt auf ausdrücklich eingeladene Projekt-Unterräume | + +Eine Einladung macht einen externen Benutzer **nicht zum regulären Benutzer des einladenden Mandanten**. Chatteilnahme und Zugriff auf Projektdaten sind getrennte Freigaben. Eine freigegebene Partnerinstanz erhält ebenfalls keine pauschalen Rechte auf einen Mandanten. + +Gäste ohne eigenes FEDEO-Konto sind Teil des Zielumfangs. Ihre Zusammenarbeit findet in abgegrenzten Unterräumen eines Projekts statt. Dieselben Unterräume können auch Personen anderer FEDEO-Mandanten oder -Instanzen aufnehmen; die Art der Anmeldung verändert die Sichtbarkeitsgrenze nicht. + +Der Vorschlag ist eine Föderation zwischen FEDEO-Instanzen mit zentraler Zuständigkeit je Ressource. Er bietet keine automatische Interoperabilität mit Matrix, Teams oder anderen Messengern und keine gleichberechtigten Schreibkopien auf allen Instanzen. + +## 2. Nutzerabläufe + +### Gemeinsamen Chat eröffnen + +1. Benutzer wählt `Kommunikation → Neuer Chat → Externe Teilnehmer`. +2. Er wählt einen bekannten Partnerkontakt oder fügt eine FEDEO-Kontaktadresse hinzu. Vor dem Absenden werden Person, Mandant und Instanz angezeigt. +3. Er bestimmt ausdrücklich die internen und externen Teilnehmer. Die Auswahl einer Firma fügt nicht automatisch deren gesamte Belegschaft hinzu. +4. Empfänger sieht eine Anfrage in seiner eigenen FEDEO-Instanz und nimmt sie im eingeladenen Mandantenkontext an. +5. Nach Bestätigung durch die führende Instanz erscheint derselbe gemeinsame Chat auf beiden Seiten, mit Kennzeichnung des verantwortlichen Mandanten und der externen Teilnehmer. + +Ein Partnerkontakt ist lediglich eine wiederverwendbare Adresse. Er berechtigt weder zum Zugriff auf andere Chats noch zur Suche im vollständigen Benutzerverzeichnis der Partnerfirma. Unbekannte Absender landen in einer begrenzten Anfrageansicht; Benutzer und Mandanten können Kontakte blockieren. + +### Externe Person zu einem Projekt einladen + +1. Projektverantwortlicher öffnet `Projekt → Zusammenarbeit → Unterraum erstellen` oder wählt einen bestehenden Unterraum. +2. Er benennt den Unterraum, beispielsweise „Abstimmung Gerüstbau“, und wählt ausdrücklich die internen Teilnehmer. +3. Über `Person einladen` wählt er einen FEDEO-Kontakt oder einen Gast ohne FEDEO-Konto, Rolle, gegebenenfalls Ablaufdatum und die konkret freigegebenen Inhalte. +4. Jeder Unterraum hat einen eigenen Partnerchat. Optional werden eine begrenzte Projektübersicht und später einzelne Dokumente innerhalb dieses Unterraums freigegeben. Die Vorschau zeigt exakt, was der Empfänger sehen wird. +5. FEDEO-Benutzer finden den Unterraum unter `Projekte → Mit mir geteilt`; Gäste öffnen eine reduzierte Gastoberfläche beim Eigentümer. Beide sehen nur den jeweiligen Unterraum und dessen freigegebene Inhalte. +6. Verantwortliche können Teilnahme und Freigaben später einschränken, befristen oder entziehen. Unterraum und freigegebene Projektübersicht zeigen deren aktuellen Status. + +Beispiel: Ein Elektrofachbetrieb lädt einen Mitarbeiter des Gerüstbauers in das Projekt „Schulgebäude“ ein. Dieser erhält den Partnerchat, den freigegebenen Ausführungstermin und einen Lageplan. Angebote, Einkaufspreise, interne Notizen und andere Projekte bleiben verborgen. + +### Unterräume als eigenständige Zugriffsgrenze + +```text +Projekt Schulgebäude +├── Interner Projektchat +├── Unterraum: Gerüstbau → ausgewählte Mitarbeiter + Gerüstbauer +├── Unterraum: Bauherr → ausgewählte Mitarbeiter + Bauherr +└── Unterraum: Abnahme → ausdrücklich eingeladene Beteiligte +``` + +Jeder Unterraum besitzt eine eigene ID, Teilnehmerliste, Historie und Freigaben. Ein Gast im Raum „Gerüstbau“ sieht weder den internen Projektchat noch Namen, Teilnehmer, Nachrichten oder Zähler der anderen Unterräume. Auch das übergeordnete Projekt ist nicht automatisch lesbar. Die Gastansicht zeigt einen ausdrücklich freigegebenen Anzeigenamen ohne verlinkten internen Projektpfad. + +Die Zuordnung zum Projekt dient der internen Organisation und vererbt keine Leserechte nach oben, unten oder zu benachbarten Räumen. Interne Mitarbeiter werden ebenfalls ausdrücklich als Teilnehmer aufgenommen; die Berechtigung zur Verwaltung eines Unterraums ersetzt keine Chatmitgliedschaft. Für die erste Ausbaustufe reicht eine Ebene unter dem Projekt; beliebige Verschachtelung ist nicht vorgesehen. + +Nachrichten werden nicht automatisch zwischen internem Chat und Unterräumen gespiegelt. Eine spätere Funktion zum Teilen einzelner Inhalte muss Zielraum und freigegebenen Inhalt ausdrücklich bestätigen lassen. Mehrere Firmen dürfen denselben Unterraum nutzen, wenn sie bewusst gemeinsam eingeladen wurden; dann ist dessen Teilnehmerliste für alle dort Berechtigten sichtbar. + +## 3. Ausgangslage im Code + +| Bestand | Bedeutung für den Entwurf | +| --- | --- | +| [`communication_rooms`](../backend/db/schema/communication_rooms.ts) | Räume gehören bisher genau einem lokalen Mandanten; `key` ist nur innerhalb dieses Mandanten eindeutig. | +| [`communication_room_members`](../backend/db/schema/communication_room_members.ts) | Mitglieder referenzieren lokale `auth_users`; es fehlen Herkunftsmandant, externe Identität, Rolle und Widerrufszustand. | +| [`communication_messages`](../backend/db/schema/communication_messages.ts), [`communication_room_reads`](../backend/db/schema/communication_room_reads.ts) | Autoren und Lesestatus sind lokale Benutzer; numerische Nachrichten-IDs taugen nicht als instanzübergreifende Identität. | +| [`projects`](../backend/db/schema/projects.ts) | `profiles` enthält lokale Mitarbeiterprofile; externe Zusammenarbeit braucht eigene Freigaben statt fremder Mitarbeiterprofile. | +| [`auth.ts`](../backend/src/plugins/auth.ts), [`resources/main.ts`](../backend/src/routes/resources/main.ts) | Anmeldung und Ressourcenabfragen arbeiten mit dem aktiven lokalen Mandanten. Externe Rechte dürfen diese allgemeine Mandantengrenze nicht aufweichen. | +| [`communication.ts`](../backend/src/routes/communication.ts) | Raumzugriff ist an den aktiven Mandanten gebunden; Benachrichtigungsempfänger stammen aus dessen Benutzerverzeichnis. Beides benötigt eine explizite Zusammenarbeitsschicht. | + +Vor einer Freigabe sind zwei vorhandene Verhaltensweisen zu korrigieren: Das Anlegen eines Raums mit bestehendem Schlüssel darf keine zusätzlichen Mitglieder in einen fremden Raum aufnehmen. Außerdem darf das Bereitstellen eines Projektchats nicht allein durch Kenntnis einer Projekt-ID zur Selbstaufnahme führen. Einladungen, Beitritt und das Lesen von Projektdaten benötigen jeweils eine objektbezogene Prüfung. + +## 4. Zuständigkeit und Datenfluss + +```mermaid +flowchart LR + UA[Benutzer A] --> A[FEDEO A: Anmeldung und Berechtigungen] + UB[Benutzer B] --> B[FEDEO B: Anmeldung und Berechtigungen] + A --> O[(Projekt und Chat bei Eigentümer A)] + B --> P[(Freigegebene Chatkopie für Mandant B)] + B -->|Signierte Befehle und Projektabfragen| A + A -->|Bestätigte Ereignisse und freigegebene Ansichten| B +``` + +- Ein gemeinsam genutzter Chat hat einen Eigentümer und eine feste führende Instanz. Projektchats werden beim Projekteigentümer geführt. Ein freier Partnerchat wird beim Ersteller geführt; das wird vor Annahme angezeigt. +- Die führende Instanz prüft jeden Schreibbefehl und vergibt dessen verbindliche Reihenfolge. Partnerinstanzen dürfen bestätigte Chatereignisse für ihre ausdrücklich berechtigten lokalen Teilnehmer speichern. +- Projektdaten bleiben beim Eigentümer. Die Partnerinstanz fragt eine eingeschränkte Ansicht an; es gibt keine Replikation der vollständigen `projects`-, Kunden- oder Belegtabellen. +- Jede Partnerinstanz übernimmt Anmeldung, lokale Benutzeroberfläche, Lesestatus und Benachrichtigungen ihrer eigenen Benutzer. Zugangstoken der Benutzer verlassen die eigene Instanz nicht. +- Mehrere Mandanten auf derselben Instanz durchlaufen denselben Berechtigungsdienst. Die Optimierung zum internen Aufruf darf keine zusätzlichen Rechte schaffen. + +Die Entscheidung für eine führende Instanz vereinfacht Reihenfolge, Rollenwechsel und Widerruf. Sie hat einen bewussten Nachteil: Ist diese Instanz ausgefallen, können neue Nachrichten nur als ausstehend vorgemerkt werden; neue Projektabfragen und Freigaben sind nicht möglich. Bereits rechtmäßig empfangene Chatnachrichten können entsprechend der Aufbewahrungsregel weiter angezeigt werden. Es gibt in Version 1 keine automatische Übernahme durch eine andere Instanz. + +## 5. Identitäten und Vertrauen + +Eine Person handelt immer in einem konkreten Organisationskontext. Der gleiche lokale Benutzer in zwei Mandanten hat deshalb zwei getrennte Teilnehmeridentitäten. + +| Identität | Vorgabe | +| --- | --- | +| Instanz | Dauerhafte öffentliche UUID, kanonische HTTPS-Adresse und eigene Signaturschlüssel | +| Mandant | Dauerhafte öffentliche UUID plus Instanzidentität; lokale numerische ID bleibt intern | +| Teilnehmer / Principal | FEDEO-Benutzer: Kombination aus Instanz-, Mandanten- und öffentlicher Benutzer-ID; Gast: ausstellende Eigentümerinstanz, Eigentümermandant und eigene stabile Gast-ID, mit Typ `guest` | +| Ressource | Dauerhafte öffentliche UUID plus führende Instanz; z. B. Chat oder freigegebene Projektansicht | +| Nachricht / Ereignis | Globale UUID; zusätzlich fortlaufende Sequenz innerhalb des führenden Chats | + +Als Kontaktadresse kann eine kanonische HTTPS-Adresse dienen, beispielsweise `https://partner.example/federation/actors/`. Anzeigenamen und E-Mail-Adressen sind veränderbare Attribute, keine Identitätsschlüssel. Gleichlautende E-Mail-Adressen auf zwei Instanzen führen nicht zu einer automatischen Zusammenführung. Öffentlich abrufbare Adressen dürfen keine offenen Mitarbeiterlisten ergeben. + +Eine eigene Discovery-Datei `/.well-known/fedeo-federation` veröffentlicht Protokollversion, Instanz-ID, HTTPS-Endpunkt und öffentliche Schlüssel. Dieser Pfad ist ein FEDEO-eigener Vorschlag. Beim Erstkontakt werden HTTPS-Herkunft, Kontrolle des Endpunkts durch eine signierte Challenge und die Freigabe des Partners geprüft. Discovery allein verleiht kein Vertrauen. + +Für Version 1 gilt eine Partner-Allowlist je Mandant innerhalb der vom Betreiber erlaubten Instanzen. Empfänger nehmen Anfragen zusätzlich selbst an. Eine bestätigte Transportverbindung ersetzt keine Raum- oder Projektfreigabe. Eine Partnerinstanz darf ausschließlich Identitäten ihrer eigenen Herkunft bestätigen; jeder Zugriff wird auf eine konkret eingeladene Kombination aus Instanz, Mandant und Benutzer begrenzt. + +Das Vertrauensmodell setzt voraus, dass die Heimatinstanz ihre Benutzer korrekt authentifiziert. Ein kompromittierter Partneradministrator könnte im Namen dieser Benutzer handeln. Instanzsignaturen belegen den Absender-Server, nicht die persönliche Unterschrift des Menschen. Deshalb können Betreiber und Mandanten Partner sofort sperren; für höhere Anforderungen wäre später eine zusätzliche benutzergebundene Signatur nötig. + +Schlüssel werden getrennt von JWT-, Push- und sonstigen API-Secrets verwaltet. Rotation erfolgt mit überlappend veröffentlichten Schlüsseln und Nachweis durch den bereits vertrauten Schlüssel; Verlust oder Kompromittierung verlangt eine explizite erneute Vertrauensprüfung. Domainwechsel benötigen einen dokumentierten Identitätsumzug. Ein Datenbankklon für Test oder Restore darf nicht parallel als dieselbe Instanz senden; vor Freischaltung sind Instanzidentität, Worker und Schlüssel zu prüfen. + +## 6. Berechtigungen und Sichtbarkeit + +Alle externen Rechte entstehen aus einer vom Eigentümer gespeicherten Freigabe: `resource + principal + role/scopes + status + revision + expires_at`. Bei FEDEO-Benutzern prüfen wir zusätzlich die lokale Mitgliedschaft im Heimatmandanten, dessen Partnerregeln und die Sperrzustände beider Seiten. Bei Gästen werden stattdessen Gastidentität und Gastsitzung beim Eigentümer geprüft; eine reguläre Mandantenmitgliedschaft ist keine Voraussetzung. Rollen der fremden Instanz werden niemals zu lokalen Administratorrechten übersetzt. + +Unterraumzugriff verlangt eine aktive Freigabe auf genau diesen Unterraum. Chat, Projektansicht und Dateien bleiben getrennte Ressourcen; ein angebotenes Rollenpaket kann die benötigten Freigaben explizit bündeln. Für eine freigegebene Datei oder Ansicht müssen sowohl die Unterraumteilnahme als auch die konkrete Inhaltsfreigabe gültig sein. Das gilt auch bei direkten URLs, Suche, Benachrichtigungen und offenen Echtzeitverbindungen. + +| Rolle | Erlaubte Fähigkeiten | Ausdrücklich nicht enthalten | +| --- | --- | --- | +| Chatteilnehmer | Den freigegebenen Chat ab Beitritt lesen, Nachrichten senden, eigene Lesemarke setzen | Projektdaten, andere Räume, Teilnehmer einladen | +| Projektleser | Freigegebene Projektübersicht und einzeln freigegebene Dateien lesen | Vollständiges Projektobjekt, interne Notizen, Kundenakte, Belege | +| Projektmitarbeiter | Projektleser; später zusätzlich ausdrücklich zugewiesene Aufgaben oder freigegebene Rückmeldungen bearbeiten | Allgemeines Projekt-Schreibrecht, Kalkulation, Rollenverwaltung | +| Projektverantwortlicher | Auf Eigentümerseite Teilnehmer und Freigaben verwalten, soweit intern autorisiert | Automatische Rechte in Partnerorganisationen | + +Die Rollen sind Vorlagen für konkrete Rechte. Projektlesen erzeugt keine Chatmitgliedschaft und Chatmitgliedschaft keine Projektfreigabe; der Einladungsdialog kann beide bewusst bündeln. Version 1 umfasst Textchat und eine lesbare Projektübersicht. Datei- und Aufgabenrechte werden erst angeboten, wenn die jeweiligen Prüfungen umgesetzt sind. + +Die externe Projektübersicht verwendet eine Positivliste freigegebener Felder, etwa Anzeigename, vereinbarter Status und freigegebene Termine. Weder das komplette Projektobjekt noch eingebettete Beschreibungen, `notes`, `material`, `forms`, Kundenverknüpfungen oder Änderungsprotokolle werden ungeprüft ausgegeben. Eine neue interne Spalte wird dadurch nicht automatisch extern sichtbar. Auch Suche, Vorschaubilder, Zähler, Exporte und Benachrichtigungen müssen denselben Umfang einhalten. + +Standard für externe Teilnehmer ist `history_from_seq = Beitrittssequenz`. Frühere interne Nachrichten werden nicht nachträglich freigegeben. Neue Mitglieder sehen nur die für sie zulässige Historie; erneute Einladung ist eine neue Freigabe mit neuem Beginn. Bei Einführung von Antworten, Reaktionen oder Bearbeitungen dürfen Referenzen keine zuvor unsichtbaren Nachrichten offenlegen. Die Teilnehmerliste eines Partnerchats zeigt die beteiligten Identitäten und Organisationen; darüber werden Einladende und Empfänger informiert. + +Archivierte Unterräume erlauben bestehenden berechtigten Teilnehmern nur noch das Lesen. Gesperrte Unterräume erlauben keinen weiteren Zugriff. Projektarchivierung setzt zugehörige Unterräume auf nur lesbar; eine Projektsperre sperrt deren Zugriffe. Der Entzug einer Unterraumteilnahme blockiert alle darüber freigegebenen Inhalte und beendet betroffene Abonnements, auch wenn ein einzelner Datei-Grant noch gespeichert ist. Einladungen zu anderen Unterräumen bleiben davon unabhängig. Die vollständige Sperre einer Gastidentität beendet dagegen deren sämtliche Zugriffe beim betreffenden Eigentümermandanten. + +## 7. Einladung und Entzug + +Zustände: `pending → accepted | declined | expired | revoked`. `accepted` entsteht ausschließlich durch eine atomare Entscheidung beim Eigentümer; danach können die daraus entstandenen Freigaben unabhängig widerrufen oder eingeschränkt werden. Der Verlauf bleibt im Audit nachvollziehbar. + +1. Eigentümer prüft die Einladungsberechtigung und legt Empfängeridentität, Ressourcen, bei Projektzusammenarbeit den konkreten Unterraum, Rechte, Historienbeginn, Ablauf und eine unveränderliche Angebotsrevision fest. +2. Heimatinstanz des FEDEO-Empfängers zeigt die Anfrage nach Anmeldung im betreffenden Mandanten. Beim Annehmen bestätigt sie signiert Identität, Einladung und Angebotsrevision. Ein Gast wird über die eigene Gastanmeldung beim Eigentümer authentifiziert und bestätigt dort denselben Angebotsumfang. Die Zustimmung bezieht sich auf genau diesen Umfang. +3. Eigentümer prüft Ablauf, Sperren, fortbestehende Rechte des Einladenden und die Identität erneut. Freigaben und Bestätigungsereignis werden in einer Transaktion erstellt. Wiederholte Annahme liefert dasselbe Ergebnis, keine zweite Mitgliedschaft. +4. Beide Oberflächen zeigen erst nach Bestätigung `Aktiv`. Eine Änderung des Angebots vor Annahme erfordert erneute Zustimmung. +5. Widerruf setzt den Zustand beim Eigentümer und erhöht die Berechtigungsrevision. Neue Befehle, Downloads und noch nicht versandte Inhaltszustellungen prüfen diesen Zustand erneut. Alte Annahmeereignisse oder Befehle dürfen eine entzogene Freigabe nicht reaktivieren. + +Für Einladungen per Link gilt: einmaliges zufälliges Geheimnis, nur gehasht gespeichert, befristet und beim Einlösen atomar verbraucht. Ein Link allein ist kein Projektschlüssel. Die Annahme benötigt eine authentifizierte Empfängeridentität. Ist diese bei Erstellung noch unbekannt, wird sie nach Anmeldung dem Einladenden zur Bestätigung angezeigt; bis dahin werden keine Projektinhalte freigegeben. Tokens dürfen nicht in Zugriffslogs oder Referrer gelangen; Einlöseseite ohne Drittinhalte und Übergabe des Geheimnisses per POST. + +Das Entfernen eines Mitarbeiters aus seinem Heimatmandanten sperrt dessen lokale Zusammenarbeit sofort; die Heimatinstanz meldet die Deaktivierung an die Eigentümer. Beim nächsten Befehl wird die lokale Mitgliedschaft ohnehin erneut geprüft. Es erfolgt keine stillschweigende Übertragung auf einen Nachfolger oder einen anderen Mandanten derselben Person. + +Ein Entzug stoppt die weitere autorisierte Nutzung beim Eigentümer. Bereits ausgelieferte beziehungsweise bereits unterwegs befindliche Daten lassen sich nicht sicher zurückholen. Eine Partnerinstanz kann vor Eingang des Widerrufs noch ihre bisherige Chatkopie anzeigen; ein fremder Betreiber kann Kopien behalten. Die Software übernimmt Widerrufe, beendet Synchronisation und entfernt lokale Zugriffe nach Richtlinie, verspricht aber kein nachträgliches Löschen sämtlicher Kopien. Neue Projektabfragen und Dateiabrufe müssen den Eigentümer erreichen und bei Ausfall geschlossen scheitern. + +## 8. Transport und Synchronisation + +Browser und Mobile-App von FEDEO-Benutzern sprechen nur mit ihrer eigenen FEDEO-Instanz. Deren Backend übersetzt lokale Aktionen in geprüfte Föderationsbefehle. Gäste verwenden die Gastoberfläche der Eigentümerinstanz. Föderationsrouten erhalten eine eigene Authentifizierung; sie dürfen fremde Signaturen nicht in reguläre lokale Benutzer-JWTs oder einen frei wählbaren `tenant_id` umwandeln. + +Für Transportauthentifizierung wird ein festes FEDEO-Profil auf Basis von [HTTP Message Signatures, RFC 9421](https://www.rfc-editor.org/rfc/rfc9421.html) und [Content-Digest, RFC 9530](https://www.rfc-editor.org/rfc/rfc9530.html) vorgeschlagen, mit Ed25519 als festgelegtem Signaturalgorithmus. Es signiert Methode, Ziel-URI, Inhaltstyp und Inhaltsdigest sowie Schlüssel-ID, Erstellungszeit, Ablauf und Nonce. Die konkrete Implementierung muss Referenztestvektoren bestehen; Zeitfenster und abgedeckte Komponenten sind verpflichtend. Der Digest wird gegen die tatsächlichen Body-Bytes geprüft. TLS bleibt obligatorisch. Signaturen sind keine Ende-zu-Ende-Verschlüsselung. + +FEDEO-spezifisch wird jede Nachricht an Zielinstanz, handelnden Principal, Eigentümerressource, Freigabe-ID und Revision gebunden. Der Empfänger prüft diese Bindungen zusätzlich zur Signatur. Ein gültig signierter Auftrag für Mandant B darf weder für Mandant C noch für eine andere Ressource wiederverwendet werden. Unbekannte Ereignistypen oder nicht unterstützte Pflichtmerkmale werden abgelehnt; es gibt keine stille Herabstufung von Sicherheitsregeln. + +### Verarbeitung einer Nachricht + +1. Benutzer sendet mit einer stabilen Client-Auftrags-ID an seine Heimatinstanz. Diese prüft Sitzung, aktiven Mandanten und Freigabe und speichert den Auftrag dauerhaft als `pending`. +2. Eigentümer erhält den signierten Befehl. Unter derselben Transaktionssperre wie Mitgliedschaftsänderungen prüft er die aktuell wirksame Freigabe, vergibt Nachrichten-UUID und nächste Raumsequenz und speichert Nachricht, Befehlsresultat und Outbox-Einträge atomar. +3. Ein Worker stellt die bestätigten Ereignisse den berechtigten Heimatinstanzen zu. Vor jedem Versand prüft er die aktuellen Empfängerrechte; er verschickt keine ungefilterte Raumhistorie oder vollständigen internen Raumzustände. +4. Empfangsinstanz speichert Ereignis und Empfangsbestätigung dauerhaft und dedupliziert anhand der Ereignis-ID. Erst die Eigentümerbestätigung ändert die UI-Anzeige von `Ausstehend` zu `Gesendet`; die serverseitige Annahme beim Empfänger bedeutet noch nicht, dass ein Mensch gelesen hat. +5. Die Empfangsinstanz aktualisiert ihre Chatansicht und erzeugt höchstens eine lokale Benachrichtigung pro berechtigtem Empfänger und Ereignis. + +Zustellung erfolgt mindestens einmal; Eindeutigkeit entsteht durch persistente Deduplizierung. Ein wiederholter Befehl mit derselben ID und demselben Inhalt liefert das gespeicherte Ergebnis. Dieselbe ID mit anderem Inhalt wird abgelehnt. Retries erhalten eine neue HTTP-Nonce und Signatur, behalten aber Befehls-/Ereignis-ID. So werden Transport-Replays abgewehrt, ohne legitime Wiederholung nach Timeout zu blockieren. + +Raumsequenzen bestimmen die Reihenfolge, nicht Uhren verschiedener Server. Empfangsbestätigungen und Nachladen verwenden Cursor für den **empfängerbezogenen** Ereignisstrom; ausgelassene, nicht berechtigte Raumereignisse erzeugen keine fälschlich endlosen Lücken. Mitgliedschaftsrevisionen werden monoton verarbeitet. Eine verspätete alte Einladung überschreibt keinen neueren Widerruf. Inhalte werden nur an die im Zustellumschlag ausdrücklich berechtigten Principals des Zielmandanten gebunden; lokale Kopien werden nicht für andere Benutzer desselben Servers freigegeben. + +Outbox und Inbox werden in PostgreSQL gespeichert. Ein Worker mit begrenzter Parallelität, exponentiellem Backoff und Jitter übernimmt Retries; dauerhafte Fehler werden sichtbar abgelegt. Empfangsbestätigung erfolgt erst nach dauerhafter Speicherung. Nach Ausfall werden berechtigte Änderungen per Cursor nachgeholt; bei abgelaufenem Cursor liefert der Eigentümer einen erneut gefilterten Snapshot mit aktueller Freigaberevision. Ein Restore erfordert vor Wiederaufnahme eine Reconciliation, damit alte Backups keine widerrufenen Mitgliedschaften wieder aktivieren. + +Beim Restore startet der Föderationsbetrieb gesperrt. Kann der zuvor bestätigte Ereignis- und Widerrufsstand nicht lückenlos wiederhergestellt werden, bleiben alte externe Freigaben suspendiert und werden durch neue Einladungen ersetzt. Eine mit den Partnern bestätigte neue Wiederherstellungsgeneration entwertet alte ausstehende Befehle; Sequenzen dürfen nicht stillschweigend zurückgesetzt werden. Die Fortsetzung aus einem veralteten Backup ist damit keine automatische Wiederfreigabe. + +## 9. Vorgeschlagenes Datenmodell und API-Grenzen + +Die Namen sind Entwurfsvorgaben für additive Migrationen, keine fertigen Tabellen oder Endpunkte. + +| Baustein | Wesentliche Daten und Regeln | +| --- | --- | +| `federation_instances`, Schlüssel und Partnerregeln | Globale Instanz-ID, verifizierte Herkunft, öffentliche Schlüssel, Vertrauenszustand; Freigaben/Sperren separat je lokalem Mandanten | +| `collaboration_principals` | Typ `user` oder `guest`, Herkunftsinstanz, Mandantenkontext und öffentliche Benutzer-/Gast-ID, optional lokale Benutzerzuordnung; eindeutige Herkunft plus Typ; fremde Profile nur minimal speichern | +| `collaboration_resources` | Globale Ressourcen-ID, Art, Eigentümerinstanz/-mandant, optional Verweis auf lokalen Chat oder lokales Projekt; Projekt-Unterraum als eigene Ressourcenart mit lokaler Projektzuordnung | +| Unterraum-Inhaltszuordnung | Explizite Zuordnung von Chat, eingeschränkter Projektansicht und später Dateifreigaben zu genau einem Unterraum; dieselbe Datei kann über getrennte Freigaben in mehreren Räumen angeboten werden | +| Gastidentitäten und Gastsitzungen | Stabile Gast-ID im Eigentümermandanten, verifizierter Anmeldekanal, Kontostatus und getrennte Sitzungen; keine allgemeinen Tenant-Rollen | +| `collaboration_bindings` | Ressource plus empfangender lokaler Mandant; trennt lokale Spiegel desselben Raums und enthält den Synchronisationscursor | +| `collaboration_grants` | Ressource, Principal, Rolle/Scopes, Status, Revision, Historienbeginn, Ablauf, Ersteller; einzelne Freigaben bleiben widerrufbar | +| `collaboration_invitations` | Empfängerbindung, Angebotsrevision, angefragte Freigaben, Tokenhash soweit nötig, Zustand und Ablauf | +| Föderationsereignisse, Inbox, Outbox, Befehlsresultate | Globale IDs, Raumsequenz, Empfänger-/Mandantenbindung, Idempotenz, Zustellzustand und nächste Wiederholung | +| Nachrichtenergänzungen und Lesestatus | Nachrichten-UUID, Principal als Autor, Sequenz; Lesemarken je Principal/Binding; lokale Autor-IDs während Migration kompatibel halten | +| Audit | Einladung, Annahme, Rechteänderung, Widerruf, Partner-/Schlüsseländerung mit verantwortlichem Principal und Zeit; keine Tokens oder vollständigen Chattexte | + +Fremde Benutzer bekommen keinen künstlichen Eintrag mit Passwort in `auth_users` und keine Mitgliedschaft in `auth_tenant_users`. Beim Eigentümer darf eine externe Autoridentität deshalb nicht weiterhin einen obligatorischen lokalen `author_user_id` voraussetzen. Bestehende lokale Nachrichten behalten ihre Autorenverknüpfung; ein neuer Principal-Verweis ergänzt sie. Für lokale Teilnehmer wird der Principal mandantenspezifisch aufgebaut. + +`communication_rooms.tenantId` bleibt der lokale Eigentümermandant. Fremd geführte Räume erhalten einen getrennten lokalen Binding-/Projektionsdatensatz statt eines vorgetäuschten lokalen Eigentümers. Datenbankconstraints sichern lokale Ressourcenverweise gegen einen anderen Mandanten ab. Globale Identitäten und Autorenschaft werden nicht aus frei eingereichten numerischen IDs abgeleitet. + +Die Unterraum-Projektzuordnung muss auf denselben Eigentümermandanten verweisen. Sie wird nicht als Berechtigungsvererbung ausgewertet. Eine Inhaltsfreigabe bindet Quellressource, Unterraum und erlaubte Ansicht beziehungsweise Dateiversion; die Kenntnis der Quell-ID erlaubt keinen Zugriff über die internen APIs. Ein bestehender Unterraum wird in Version 1 nicht durch Änderung seiner Projekt-ID in ein anderes Projekt verschoben. + +| API-Bereich | Zweck und Grenze | +| --- | --- | +| `/.well-known/fedeo-federation` | Öffentliche technische Discovery ohne Benutzer-, Raum- oder Projektverzeichnis | +| `/federation/v1/commands` | Signierte Befehle an die führende Instanz; Fachberechtigungen bleiben zwingend | +| `/federation/v1/inbox` | Bestätigte Ereignisse nur vom zuständigen Eigentümer; feste Empfängerbindung | +| `/federation/v1/sync` | Berechtigtes Nachholen; kein frei lesbares globales Ereignisprotokoll | +| `/federation/v1/shared-projects/...` | Signierte, principalgebundene Abfrage explizit freigegebener Projektfelder | +| `/api/collaboration/...` | Lokale Benutzeroberfläche für Partner, Einladungen, Chats und geteilte Projekte; lokale Anmeldung plus objektbezogene Prüfung | +| `/guest/api/...` | Eigene Gastauthentifizierung und ausschließlich aktiv freigegebene Unterräume/Inhalte; Gastsitzungen werden von regulären `/api`- und Föderationsrouten nicht als Benutzeranmeldung akzeptiert | + +Ein zentraler `CollaborationPolicy`-Dienst prüft Aktion, handelnden Principal, Ressource, Heimatmandant und aktuelle Freigaben. Lokaler Transport und Netzwerktransport rufen denselben Fachdienst auf. Allgemeine Ressourcen-, Datei-, Export- und MCP-APIs bleiben für fremde Mandanten geschlossen; neue externe Funktionen müssen bewusst über die eingeschränkte Ansicht eingeführt werden. + +Benachrichtigungen werden auf der Heimatinstanz an lokal berechtigte Nutzer erzeugt. Der Eigentümer adressiert externe Principals und greift nicht direkt auf deren Push-Tokens zu. Die vorhandene Push-Infrastruktur kann die Zustellung übernehmen; ihre Instanzregistrierung ersetzt keine Föderationsidentität oder fachliche Autorisierung. Standard für externe Push-Nachrichten ist ein neutraler Hinweis ohne Projekt- oder Nachrichtentext. + +Für Gäste erzeugt die Eigentümerinstanz die Benachrichtigung nach derselben Unterraumprüfung. Links öffnen nur den freigegebenen Unterraum und benötigen eine gültige Gastsitzung. Gäste werden dafür nicht in reguläre Mitarbeiter-Empfängerlisten aufgenommen. + +## 10. Betrieb, Dateien und Grenzen + +- Öffentlich erreichbare HTTPS-Endpunkte sind Voraussetzung für den direkten Transport in Version 1. Für rein interne Installationen wäre später ein ausdrücklicher Relay-/Tunnelmodus nötig; ein zentraler Chatserver oder ein zentrales Adressbuch ist kein Pflichtbestandteil. +- Ausgehende Ziele stammen ausschließlich aus geprüften Partnerkonfigurationen. URL-Schemas, Ports und sämtliche aufgelösten IPv4-/IPv6-Adressen werden geprüft; keine Weiterleitungen zu beliebigen Hosts und kein Zugriff auf Loopback, private Netze oder Cloud-Metadaten. Prüfungen müssen auch DNS-Wechsel zwischen Validierung und Verbindung abdecken. Geschlossene Firmennetze brauchen eine separat konfigurierte Netzfreigabe. Grundlage: [OWASP SSRF Prevention](https://cheatsheetseries.owasp.org/cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet.html). +- Größenlimits, feste Schemas, Zeitlimits und Quotas gelten pro Instanz, Mandant und Benutzer. Ein gestörter Partner darf keine globale Warteschlange blockieren. Metriken zeigen Zustellverzug, letzte Bestätigung, Retry-Status und Sperren, ohne Chattexte zu protokollieren. +- Beim späteren Dateiaustausch bleibt der Speicher privat. Downloads laufen über einen freigabeprüfenden Dienst; keine dauerhaften öffentlichen S3-Links. Uploads sind begrenzt und vor Freigabe zu prüfen. Temporäre Downloadrechte werden an Principal, Ressource, Version und kurze Laufzeit gebunden. Sie ersetzen nicht die aktuelle Zugriffsprüfung beim Eigentümer. +- Version 1 vertraut den beteiligten Servern und verwendet Transportverschlüsselung. Betreiber der führenden und empfangenden Instanzen können Chattexte verarbeiten. Ende-zu-Ende-Verschlüsselung ist eine separate Architekturentscheidung mit Folgen für Suche, Wiederherstellung, Moderation und Benachrichtigungen; sie darf nicht nachträglich als bereits vorhandene Eigenschaft dargestellt werden. +- Aufbewahrung und Löschereignisse werden je Ressource dokumentiert. Löschanforderungen werden verteilt und protokolliert; Kopien bei fremden Betreibern oder bereits heruntergeladene Dateien sind technisch nicht sicher rückrufbar. + +## 11. Gastzugang ohne FEDEO-Konto in Unterräumen + +Der Projekteigentümer stellt eine reduzierte Gastoberfläche mit eigener Authentifizierung bereit. Gäste werden direkt in einen konkreten Projekt-Unterraum eingeladen. Nach überprüfter E-Mail-Adresse und Annahme entsteht ein Gast-Principal mit ausschließlich den angebotenen Unterraum- und Inhaltsfreigaben. Ein Gast erhält weder einen allgemeinen Mandantenzugang noch ein durchgereichtes internes Benutzer-Token. + +Die Startansicht zeigt den Namen des Unterraums, dessen ausdrücklich freigegebenen Projektkontext, Chat und Teilnehmer sowie später freigegebene Dokumente oder Aufgaben. Hat dieselbe Gastidentität mehrere angenommene Einladungen beim Eigentümermandanten, kann sie ausschließlich zwischen diesen Unterräumen wechseln. Interne Projektbäume, andere Räume und Verzeichnisse werden nicht ausgegeben. Die Erstversion soll im Browser ohne Installation einer FEDEO-App nutzbar sein. + +Ein Einladungslink ist einmalig; wiederholte Anmeldung braucht ein separates Verfahren, beispielsweise Passkey oder kurzlebigen einmaligen Anmeldecode. Verliert der Gast seinen Zugang, führt Wiederherstellung erneut über Identitätsprüfung; eine spätere gleichlautende Adresse darf keine alten Rechte automatisch übernehmen. Ein Wechsel vom Gast zur eigenen FEDEO-Instanz erfordert Zustimmung und eine explizite Neubindung der Freigaben. + +Dieser Zugang ist Teil des geplanten Funktionsumfangs und verwendet denselben Berechtigungsdienst wie die Föderation. Die eingeschränkte Gastanmeldung wird als eigener Schritt auf dem lokalen Unterraummodell aufgebaut; sie benötigt keinen bereits fertiggestellten Server-Server-Transport. Die externe Projektzusammenarbeit gilt erst dann als vollständig, wenn sowohl FEDEO-Teilnehmer als auch Gäste ihre Unterräume nutzen können. + +## 12. Architekturentscheidung gegenüber Alternativen + +| Variante | Bewertung für FEDEO | +| --- | --- | +| Native FEDEO-Föderation mit führender Instanz je Ressource | Empfehlung bei Fokus auf FEDEO-Partner und Projektfreigaben. Nutzt die vorhandene Oberfläche; ein eigenes versioniertes Protokoll, Schlüsselverwaltung und Zustellbetrieb müssen dauerhaft gepflegt werden. | +| Matrix erneut als Chatunterbau | Bietet standardisierte Serverföderation und replizierte Räume. FEDEO benötigt trotzdem eigene Projektfreigaben und ein Mapping zwischen Mandanten und Identitäten. Sinnvoll erneut zu prüfen, wenn Messenger-Interoperabilität, umfangreiche Chatfunktionen oder Verschlüsselung höchste Priorität haben. | +| Zentraler FEDEO-Kommunikationsdienst | Vereinheitlicht den Betrieb, macht Kommunikation aber von einem gemeinsamen Dienst abhängig und verlagert Datenhaltung. Erfüllt das hier gewählte dezentrale Betriebsmodell nur eingeschränkt. | + +Matrix definiert bereits einen umfangreichen Server-Server-Vertrag einschließlich Ereignissen, Zustandsabgleich und Autorisierung; die frühere Entfernung ist allein kein fachlicher Grund gegen eine Neubewertung. Unsere Empfehlung für die native Variante folgt dem engeren Ziel „FEDEO-übergreifende Projektzusammenarbeit“, nicht der Annahme, vollständige Messenger-Föderation sei trivial. [Matrix Server-Server API](https://spec.matrix.org/v1.19/server-server-api/) + +## 13. Umsetzung in abgeschlossenen Schritten + +| Schritt | Lieferumfang | Abnahme | +| --- | --- | --- | +| 0: Bestehende Grenzen absichern | Raumschlüsselkollisionen beheben, Projektchat-Beitritt autorisieren, internen und externen Chat trennen | Kein fremder Raumbeitritt durch Schlüssel oder Projekt-ID; bestehende lokale Chats funktionieren weiter | +| 1a: Unterräume und Zusammenarbeit lokal | Principals, Freigaben, Einladungen, Unterräume mit eigenem Chat und externe Projektansicht zwischen zwei Mandanten derselben Instanz | Einladung und Widerruf funktionieren ohne allgemeine Mandantenmitgliedschaft; keine Rechtevererbung zum Projekt oder Nachbarraum | +| 1b: Gäste im Unterraum | Gastidentität, getrennte Gastanmeldung und reduzierte Browseroberfläche für Personen ohne FEDEO-Konto | Gast kann eingeladenen Unterraum nutzen; direkte URLs und APIs öffnen weder Hauptprojekt noch andere Unterräume | +| 2: Föderierter Pilot | Discovery, Partnerfreigabe, Signaturen, Worker, Idempotenz und Synchronisation zwischen zwei Instanzen | Gleicher fachlicher Ablauf über Netzwerk einschließlich Ausfall und erneuter Zustellung | +| 3: Alltagstauglicher Betrieb | Web-/Mobile-Parität, Benachrichtigungen, Moderation, Quotas, Diagnose, Schlüsselrotation und Wiederherstellung | Ende-zu-Ende-Abnahme mit mehreren Mandanten und dokumentierter Wiederaufnahme | +| 4: Erweiterungen | Freigegebene Dateien und gezielte Aufgabenbearbeitung in Unterräumen, gegebenenfalls erweiterte Chatfunktionen | Jede neue Fähigkeit erhält eigene Scope-, Widerrufs- und Datenabflusstests | + +Migrationen erfolgen additiv mit Backfill für öffentliche IDs und lokale Principals. Bestehende Chat-APIs werden während des Übergangs adaptiert. Kein vorhandener Raum wird automatisch föderiert; externe Zusammenarbeit wird je Mandant aktiviert und startet bei Projekten mit explizit angelegten Unterräumen samt Partnerchat. Bei Abschaltung stoppen neue Einladungen und ausgehende Aktionen; Eigentümer entziehen aktive externe Freigaben und stellen Widerrufe nach Möglichkeit zu. Vorhandene fremde Kopien verschwinden dadurch nicht automatisch. Alte Spalten werden erst nach Clientumstellung und geprüftem Rückfallpfad entfernt. + +## 14. Konkrete Abnahmeszenarien + +1. A1 und B1 auf derselben Instanz sowie A1 und B2 auf verschiedenen Instanzen durchlaufen identische Einladung, Annahme, Nachricht und Entzug. +2. Derselbe Benutzer in zwei Heimatmandanten erhält nur im eingeladenen Kontext Zugriff. Gleichlautende numerische IDs oder E-Mail-Adressen verbinden keine fremden Datensätze. +3. Ein Chatgast kann weder Projektübersicht noch interne Ressourcen-, Datei-, Export- oder MCP-Endpunkte verwenden. Ein Projektleser erhält ausschließlich freigegebene Felder und Dokumente. +4. Externe sehen keine alten internen Nachrichten, unsichtbaren Zitate, fremden Partnerchats oder unfreigegebenen Teilnehmerlisten. Eine erneute Einladung erweitert die Historie nicht unbeabsichtigt. +5. Abgelaufene, weitergeleitete, doppelt eingelöste und während Annahme widerrufene Einladungen erzeugen keine unberechtigten Freigaben. Rechteverlust des Einladenden vor Annahme wird erkannt. +6. Manipulierter Body, falscher Signaturschlüssel, falsche Zielinstanz, Nonce-Replay und fremder Principal werden abgelehnt. Ein gültiger Server darf keine andere Organisation impersonieren. +7. Doppelte oder vertauschte Ereignisse, verlorene Bestätigungen und Neustarts erzeugen keine doppelten Nachrichten oder Benachrichtigungen. Ein alter Grant-Zustand überschreibt keinen Widerruf. +8. Entzug während ausstehender Nachricht beziehungsweise Zustellung sperrt noch nicht autorisierte Nutzung. Die Oberfläche unterscheidet ausstehend, bestätigt, fehlgeschlagen und archiviert nachvollziehbar. +9. Ein offline befindlicher Eigentümer führt zu sichtbarer Wartesituation; Wiederverbindung holt nur weiterhin berechtigte Inhalte nach. Lokale interne Chats bleiben unabhängig nutzbar. +10. Discovery und Callback-Ziele können weder interne Dienste noch Metadaten-Endpunkte erreichen, auch bei IPv6, Redirects und DNS-Wechsel. +11. Partnerblockade, Mitarbeiterdeaktivierung, Schlüsselrotation und Restore werden mit mehreren Mandanten getestet. Alte Backups oder verspätete Befehle stellen keine entzogenen Rechte wieder her. +12. Ein Gastzugang wird erst aktiviert, wenn Gastanmeldung, Linkbindung und Trennung von normalen Mandantensitzungen separat geprüft sind. +13. Ein Gast im Unterraum „Gerüstbau“ sieht weder Hauptprojekt noch Unterraum „Bauherr“, einschließlich deren Namen, Teilnehmer, Suchtreffern und Ungelesen-Zählern. Das gilt auch beim Erraten von IDs oder direkten API-Aufrufen. +14. Interne Projektmitgliedschaft, Unterraumverwaltung und Chatmitgliedschaft werden getrennt geprüft. Eine Projektzuordnung oder manipulierte Inhaltszuordnung überträgt keine Leserechte. +15. Entzug eines Unterraums beendet dessen Chat-, Datei- und Echtzeitzugriffe, lässt andere explizit freigegebene Unterräume aber unberührt. Globale Gastsperre sperrt alle zugehörigen Unterräume. +16. Archivierung erlaubt nur weiterhin berechtigtes Lesen; Sperrung verweigert auch direkte Inhaltsabrufe. Ein Wechsel der Projektzuordnung kann keine vorhandene Unterraumhistorie offenlegen. + +Als erster nutzbarer Meilenstein wird **ein abgegrenzter Projekt-Unterraum mit eigenem Chat und expliziten Einladungen** empfohlen. Zuerst wird die Mandantentrennung lokal geprüft, anschließend der Gastzugang ergänzt. Auf diesem gemeinsamen Modell baut der instanzübergreifende Transport auf. diff --git a/docs/minio-austausch-konzept.md b/docs/minio-austausch-konzept.md new file mode 100644 index 00000000..e126acce --- /dev/null +++ b/docs/minio-austausch-konzept.md @@ -0,0 +1,222 @@ +# Konzept: MinIO durch SeaweedFS ersetzen + +Stand: 25. September 2026. Status: Entscheidungsvorschlag auf Basis des FEDEO-Codes bei Commit `29155f91` und der unten verlinkten Herstellerquellen. Eine Migration, ein Kompatibilitätstest mit einem Ersatzserver oder eine Änderung an einer laufenden Instanz wurde für dieses Konzept nicht durchgeführt. + +**Fortschreibung vom 27. September 2026:** Ein ausführbarer, isoliert getesteter +Migrationspilot ist hinzugekommen. Durchführung, Testnachweise und noch offene +Freigaben stehen in [MinIO-Umstellung: Pilot](minio-umstellung-pilot.md). +Die folgenden Abschnitte bleiben das Zielbild für den vollständigen Standardbetrieb. + +## 1. Empfehlung und Umfang + +**SeaweedFS Open Source wird der bevorzugte Kandidat für den FEDEO-Dateispeicher.** Ziel ist ein einzelner Container auf dem bisherigen Docker-Host mit S3-Schnittstelle, privaten Buckets und persistentem lokalen Speicher. Die Freigabe erfolgt erst nach den unter Abschnitt 10 beschriebenen Tests mit einem festgelegten Release und Image-Digest. + +„Eins zu eins“ bedeutet für FEDEO: gleiche Dateien, gleiche Objektschlüssel, gleiche Datenbankverweise, gleiche Mandantentrennung und gleiche Benutzerabläufe. Das interne Speicherformat wird durch eine kontrollierte Kopie über S3 umgestellt. Das Verzeichnis `minio/` wird weder umbenannt und wiederverwendet noch vom Ersatzserver geöffnet. + +Zur Lösung gehören drei zusammenhängende Änderungen: + +1. MinIO-Server und MinIO-Client `mc` aus dem künftigen Standardbetrieb entfernen. +2. Installer, Update-Dienst, Datenübernahme und Wiederherstellung auf den neuen Speicher abstimmen. +3. Freigegebene Speicher-Images und Hilfswerkzeuge unter FEDEO-Kontrolle verfügbar halten, damit Kundenupdates nicht direkt von einer fremden Registry abhängen. + +Nicht Teil dieses Austauschs sind Hochverfügbarkeit, ein Kubernetes-Cluster, neue fachliche Dateifunktionen oder die Ablösung von S3 durch ein eigenes Dateisystem-Backend. Ein Container auf einem Host bleibt ein einzelner Ausfallpunkt; eine zweite Kopie auf demselben Datenträger ersetzt kein externes Backup. + +## 2. Konkreter Anlass und heutiger Zustand + +Der gemeldete Auftrag von 3.3.0 nach 3.4.1 scheiterte beim Abruf von `quay.io/minio/mc` mit `401 Unauthorized`. `phase: pulling`, `mutationStarted: false` und `recoveryRequired: false` zeigen einen Abbruch vor der Wartungsphase. Das Protokoll belegt ein Bezugsproblem des Client-Images, keinen Datenfehler im laufenden MinIO. Es belegt auch nicht, ob das benötigte Image bereits lokal vorhanden ist. + +Der inzwischen im Repository vorhandene Cache-Fix kann passende lokale Digest-Images weiterverwenden. Er ist eine Überbrückung und garantiert weder Neuinstallationen noch künftige Sicherheitsupdates. + +Die Anwendung hat bereits eine weitgehend herstellerneutrale Schnittstelle: + +| Bereich | Befund im Repository | Konsequenz | +| --- | --- | --- | +| S3-Client | `backend/src/utils/s3.ts`: AWS SDK, `forcePathStyle: true`, Endpunkt/Region/Schlüssel/Bucket aus `S3_*` | Kein Austausch des SDK erforderlich | +| Dateioperationen | `PutObject`, `GetObject`, `HeadObject`, `DeleteObject` | Überschaubarer verbindlicher API-Vertrag | +| Dateiablage | `backend/src/utils/files.ts`: Schlüssel wie `/filesbyid//`, Content-Type und Länge | Schlüssel und Objektinhalt müssen unverändert bleiben | +| WebDAV | `backend/src/webdav/server.ts`: GET und HEAD | Lesen und Dateigrößen gezielt prüfen | +| Normale Dateilinks | `backend/src/routes/files.ts`: `/api/files/content/...` mit FEDEO-Token | Interne Speicheradresse bleibt vor dem Browser verborgen | +| DATEV/SEPA | `backend/src/routes/exports.ts`: echte S3-Presigned-URLs, 24 Stunden gültig, zusätzlich gespeicherter Objektschlüssel | Signaturen und bereits gespeicherte Links gesondert behandeln | +| Mandantenexport/-import | `backend/src/utils/tenantFullExport.ts` und `backend/src/routes/admin.ts` | Auch Archive, Vorlagen und temporäre Objekte übernehmen | +| Systemstatus | `backend/src/modules/system-status.service.ts`: `/minio/health/live` | Herstellerneutralen Funktionscheck einführen | +| Installation | Compose, `.env.example`, `scripts/selfhost-setup.sh`: MinIO und `mc` fest verdrahtet | Speicherbereitstellung und Initialisierung ersetzen | +| Host-Updater | `scripts/selfhost-update.py`: feste Dienste, Mounts, Hostname `minio`, Zugangsdaten, Start-/Backup-/Restore-Logik | Expliziten Übergangsadapter entwickeln | + +Im durchsuchten Anwendungscode gibt es keine Aufrufe für Bucket-Versionierung, Object Lock, Objekt-Tags oder S3-Multipart-Uploads. Das beweist nicht, dass diese Funktionen auf einer bestehenden Instanz nie extern aktiviert wurden. Die Migration muss den tatsächlichen Bucket prüfen. HTTP-Multipart beim Datei-Upload ist außerdem nicht S3-Multipart. + +## 3. Auswahl des Ersatzes + +| Kandidat | Eignung und Grenzen | Entscheidung für FEDEO | +| --- | --- | --- | +| **SeaweedFS Open Source** | S3, Betrieb aus einem Binary/Container, konfigurierbare Schlüssel; Apache-2.0 laut Projekt. Intern mehrere Speicherkomponenten. S3-Schlüssel werden auf eine Verzeichnisstruktur abgebildet. | Bevorzugter Kandidat; Schlüsselkompatibilität, Authentifizierung und vollständiges Backup sind Freigabebedingungen. [Projekt](https://github.com/seaweedfs/seaweedfs), [S3-Vertrag](https://github.com/seaweedfs/seaweedfs/wiki/Amazon-S3-API) | +| **Garage** | Unterstützt den FEDEO-Kern aus S3, SigV4 und Presigned-URLs. Eigene Bucket-/Schlüsselrechte; keine vollständige AWS-Policy-, Versionierungs- oder Object-Lock-Schnittstelle. Das Einzelknoten-Tutorial rät wegen fehlender Redundanz vom Produktionseinsatz ab. | Alternative für bewusst kleinen Funktionsumfang; für den gewünschten Austausch weniger Spielraum bei bestehenden Sonderkonfigurationen. [Kompatibilität](https://garagehq.deuxfleurs.fr/documentation/reference-manual/s3-compatibility/), [Betriebsgrenzen](https://garagehq.deuxfleurs.fr/documentation/quick-start/) | +| **RustFS** | S3-orientiert, ähnliche Containerkonfiguration. Version 1.0.0 wurde am 16. September veröffentlicht; die direkte MinIO-Datenformat-Kompatibilität ist im aktuellen Projekt als Preview gekennzeichnet und nicht im Standardbuild aktiv. | Weiter beobachten. Die sehr junge stabile Version begründet hier eine längere Erprobung, nicht die Behauptung einer grundsätzlichen Untauglichkeit. Kein direkter Zugriff auf bestehende MinIO-Daten. [Release](https://github.com/rustfs/rustfs/releases/tag/1.0.0), [Datenformat](https://github.com/rustfs/rustfs/blob/main/docs/architecture/minio-file-format-compat.md) | + +Die Entscheidung beruht auf dem FEDEO-Betriebsmodell und dem benötigten API-Umfang, nicht auf Hersteller-Benchmarks. Es gibt noch keine gemessene Aussage zu Geschwindigkeit oder Speicherverbrauch auf dieser Instanz. SeaweedFS-Enterprise-Funktionen sind keine Voraussetzung des Konzepts. + +Zwei SeaweedFS-Eigenschaften verlangen konkrete Gegenmaßnahmen: + +- Laut S3-Dokumentation können ein Objekt `a` und ein Objekt `a/b` nicht wie in einem flachen S3-Namensraum nebeneinander existieren; auch Löschoperationen auf Verzeichnissen haben besondere Semantik. Vorab sämtliche Schlüssel auf Präfixkonflikte, leere Verzeichnismarker, wiederholte Schrägstriche und problematische Pfadsegmente prüfen. Bei Verlust oder Normalisierung eines Schlüssels wird der Austausch blockiert, nicht stillschweigend umbenannt. [S3-Unterschiede](https://github.com/seaweedfs/seaweedfs/wiki/Amazon-S3-API) +- Ohne konfigurierte Identität startet das S3-Gateway standardmäßig mit anonym erlaubten Operationen. Unser Startprogramm muss bei fehlenden oder leeren Zugangsdaten abbrechen, bevor der Server startet. Zusätzlich sind anonyme und falsch signierte Zugriffe Negativtests jeder Freigabe. [Authentifizierung](https://github.com/seaweedfs/seaweedfs/wiki/S3-Credentials) + +## 4. Zielarchitektur + +```mermaid +flowchart LR + U[Browser / Mobile / Geräte] --> B[FEDEO-Backend und WebDAV] + B --> D[(PostgreSQL: unveränderte Dateiverweise)] + B --> S[S3-Endpunkt: Dateispeicher] + S --> W[SeaweedFS: ein Container] + W --> V[(Objekte und Metadaten)] + M[Host-Updater / Migrationswerkzeug] --> S + M --> O[Altes MinIO während der Übernahme] + M --> A[(Geprüfte Backups und Übernahmeprotokoll)] +``` + +Vorgeschlagene Betriebsnamen und Verzeichnisse: + +| Bestandteil | Vorgabe | +| --- | --- | +| Compose-Dienst | `objectstore`, Container `fedeo-objectstore` | +| S3 | Intern Port 9000; keine Veröffentlichung eines neuen Host-Ports | +| Neuinstallation | `S3_ENDPOINT=http://objectstore:9000` | +| Bestehende Installation | Endpunkt zunächst unverändert; nach dem Umschalten exklusiver Netzwerkalias `minio` auf dem neuen Dienst | +| Zugangsdaten | Bestehende `S3_ACCESS_KEY`, `S3_SECRET_KEY`, `S3_REGION` und `S3_BUCKET` übernehmen; exakte Werte im Kompatibilitätstest prüfen | +| Neue Ablage | `./storage/seaweedfs/` für sämtliche persistenten Daten und Metadaten | +| Konfiguration | `./storage/config/`, root-geschützte Konfiguration und getrennte Administratorzugänge | +| Legacy-Ablage | `./minio/` bleibt bis nach erfolgreicher Abnahme erhalten | +| Initialisierung | `storage-init` als Einmalprozess aus einem FEDEO-eigenen, gepinnten Hilfsimage; keine Abhängigkeit von `mc` | + +SeaweedFS stellt einen Einzelprozess-/Container-Einstieg bereit. Die konkrete Startkonfiguration muss für den ausgewählten Release ausdrücklich Daten-, Metadaten- und Verwaltungszustand in die gesicherten Pfade legen. Keine Speicherung wichtiger Zustände in der beschreibbaren Container-Schicht. Unbenötigte APIs werden deaktiviert; Verwaltungs-, Filer- und Volume-Endpunkte sind für Anwendungscontainer nicht erreichbar. Dafür wird ein getrenntes Speichernetz beziehungsweise eine gezielte Bindung an Loopback innerhalb des Containers verwendet. [Betriebsoptionen](https://github.com/seaweedfs/seaweedfs/blob/master/README.md) + +`storage-init` prüft Zugang, Bucket und private Zugriffe idempotent. Es erzeugt einen fehlenden Bucket, überschreibt aber keine fremden Policies oder bestehenden Inhalte. Die FEDEO-Anwendungsidentität erhält nur benötigte Rechte auf den konfigurierten Bucket. Verwaltung und Migration verwenden getrennte, geschützte Zugänge. + +Bei Bestandsinstanzen dürfen `MINIO_ROOT_*` und `S3_*` nicht ohne Vergleich gleichgesetzt werden. Maßgeblich sind die tatsächlich vom Backend verwendeten Werte, einschließlich möglicher externer Secret-Verwaltung. Andere Anwendungen, weitere Buckets oder zusätzliche S3-Schlüssel führen zu einer erweiterten Bestandsaufnahme; deren Zugriff darf nicht durch die Stilllegung verloren gehen. + +Der DNS-Alias wird nie gleichzeitig von Quelle und Ziel bedient. Während des Kopierens bleibt das Ziel unter einem anderen Namen erreichbar. Vor dem Umschalten wird das alte MinIO aus dem Anwendungsnetz genommen; danach werden Backend und sonstige S3-Clients neu gestartet, um bestehende Verbindungen zu schließen. + +## 5. Verbindlicher Kompatibilitätsvertrag + +Die Referenz ist der FEDEO-SDK-Stand aus dem Lockfile zusammen mit dem aktuellen MinIO-Verhalten. Der Test verwendet dieselben Dateipfade wie die Anwendung und zusätzlich Grenzfälle: + +- PUT/GET/HEAD/DELETE; sofortiges Lesen nach Schreiben und Verhalten nach Löschen. +- Unveränderte Bytes und Schlüssel, MIME-Typ, Länge sowie vorhandene benutzerdefinierte Metadaten und relevante HTTP-Metadaten wie `Content-Disposition`, `Cache-Control` und `Content-Encoding`. +- SigV4, Path-Style, Region `eu-central-1` beziehungsweise der tatsächliche Bestandswert; SDK-Prüfsummen, Streaming und Sonderzeichen im Schlüssel. +- Leere Objekte, Umlaute, Leerzeichen, große Dateien und die größten vorhandenen Exportarchive. Für Objekte außerhalb des getesteten Größenbereichs gibt es einen ausdrücklichen Abbruch vor der Migration. +- Fehlercodes bei nicht vorhandenen Objekten, falschen Schlüsseln, anonymen Anfragen und fremden Buckets; ein HTTP-200 auf der Startseite ist kein ausreichender Healthcheck. +- Bestehende Datenbank-IDs und Pfade bleiben gleich. Mandantenrechte werden weiterhin durch FEDEO geprüft. + +Objekt-ETag, S3-Version-ID und serverseitiges `LastModified` sind keine portablen Identitäten und müssen nach der Kopie nicht gleich sein. Fachliche Zeitstempel in PostgreSQL bleiben erhalten. Inhalte werden über einen unabhängig berechneten SHA-256-Hash verglichen; ETags werden nicht pauschal als MD5 interpretiert. [AWS-Prüfsummen](https://docs.aws.amazon.com/AmazonS3/latest/userguide/checking-object-integrity-upload.html) + +Für den ersten Migrationspfad gilt: keine aktivierte Versionierung, keine aufzubewahrenden früheren Versionen/Delete-Marker, kein Object Lock und keine nicht unterstützte Verschlüsselungs-, Tagging- oder Policy-Konfiguration. Falls die Bestandsprüfung solche Merkmale findet, wird ein eigener getesteter Adapter erforderlich. SeaweedFS-Unterstützung auf dem Papier ist keine Garantie, dass unser Kopierwerkzeug diese Merkmale verlustfrei überträgt. + +DATEV-/SEPA-Exporte brauchen einen zusätzlichen Test: Bereits ausgegebene Signaturen bleiben nur bei passender Adresse, Region, Identität und unterstützten Signaturparametern gültig. Die ohnehin vorhandene Backend-Downloadstrecke soll im vorbereitenden Release auch für Exporte verwendet werden; alte gespeicherte URLs werden bei der Ausgabe aus `filePath` neu erzeugt. Für bereits an Nutzer ausgegebene Links werden Kompatibilität oder ein dokumentierter Übergang für ihre maximal 24-stündige Laufzeit nachgewiesen. Ein interner Alias allein macht interne URLs nicht browsererreichbar. + +## 6. Images zuverlässig bereitstellen + +Eine andere öffentliche Registry würde die jetzige Fehlerklasse nur verlagern. Für freigegebene Speicherstände gilt deshalb: + +1. Einen konkreten nicht vorveröffentlichten Upstream-Release auswählen, Herkunft und Digest erfassen und sämtliche Abnahmetests ausführen. Die recherchierte aktuelle SeaweedFS-Version ist 4.47; das ist noch keine FEDEO-Freigabe. [Release](https://github.com/seaweedfs/seaweedfs/releases/tag/4.47) +2. Das geprüfte OCI-Image unter einem unveränderlichen Tag in der FEDEO-Registry bereitstellen. Upstream- und Zieldigest getrennt dokumentieren; ein Registry-Transfer muss nicht dieselbe Manifestdarstellung erhalten. +3. Speicher-, Initialisierungs- und Migrationsimage samt Digests in das Release-Manifest aufnehmen. Diese Infrastruktur-Einträge von den bestehenden Anwendungsimages unterscheiden. +4. Release erst veröffentlichen, wenn jedes Zielimage aus Sicht einer Selfhost-Installation abrufbar ist. Korrekte Leserechte bei privaten Images prüfen. +5. Vor jeder Wartung alle benötigten Images laden und verifizieren. Danach ausschließlich lokal starten. Keine neuen Registry-Abhängigkeiten während Backup, Kopie oder Wiederherstellung. +6. Zusätzlich einen geprüften Offline-Export der notwendigen Images bereitstellen und Wiederherstellung ohne Upstream-Zugriff testen. Eine einzelne eigene Registry bleibt ansonsten ebenfalls ein Ausfallpunkt. + +Spiegelung friert den Stand nur für einen Release ein. Sie braucht weiterhin einen gepflegten Sicherheitsupdate-Prozess und die zugehörigen Lizenz-/Herkunftsinformationen. `latest` ist keine Produktionsreferenz. + +## 7. Datenübernahme bestehender Instanzen + +Der erste unterstützte Weg ist eine Migration mit Wartungsfenster. Live-Vorkopieren wäre eine spätere Optimierung mit zusätzlichem Umgang mit Überschreibungen und Löschungen; für den ersten Wechsel wird keine unterbrechungsfreie Migration versprochen. + +| Phase | Aktion | Bedingung zum Weitergehen | +| --- | --- | --- | +| Bestandsprüfung | Effektive Compose-Konfiguration, Images, Datenpfade, S3-Zugänge, alle Buckets, Objektanzahl/-größen und Sonderfunktionen erfassen | Standardfall bestätigt; unbekannte Schreiber oder Speichereigenschaften blockieren | +| Vorbereitung | Zielimages und Offline-Rückfall bereitstellen; Ziel in separatem Netz und leerem Datenpfad starten | Quelle/Ziel eindeutig identifiziert; Authentifizierung und Testbucket funktionieren | +| Schreibpause | Proxy, Backend, WebDAV und alle Hintergrundschreiber anhalten; externe Schreiber ausschließen | Keine fachlichen Schreibzugriffe mehr; PostgreSQL kann für den Dump laufen | +| Sicherung | PostgreSQL-Dump und kalte MinIO-Sicherung samt Konfiguration erstellen und prüfen | Ein zusammengehöriger Wiederherstellungspunkt ist vorhanden | +| Kopie | Altes MinIO ohne Anwendungszugriff wieder starten; gesamten betroffenen Bucket über S3 kopieren | Jedes Objekt im persistenten Migrationsjournal erfasst | +| Prüfung | Quell- und Zielobjekte vollständig lesen, SHA-256 und Metadaten vergleichen; Schlüsselmenge, Anzahl und Bytes abgleichen | Keine Abweichung und keine unerklärten Zielobjekte | +| Umschaltung | Altes MinIO stoppen und Neustart verhindern; Netzwerkalias/Compose wechseln | Ziel ist der einzige aktive Speicher für die Anwendung | +| Abnahme | Funktionstests im Wartungsmodus mit deaktivierten Hintergrundschreibern | Download, PDF, WebDAV, Upload und Export sowie Berechtigungen stimmen | +| Freigabe | Migration dauerhaft als abgeschlossen markieren; dann fachliche Schreiber und öffentlichen Zugriff freigeben | Journal und Backups referenzieren den aktiven Provider eindeutig | + +Der neue, noch zu entwickelnde Migrationsprozess läuft als Host-Auftrag unter derselben exklusiven Sperre wie Updates. Er nutzt S3 über das bereits verwendete SDK in einem gepinnten FEDEO-Hilfsimage. Er kopiert mit begrenzter Parallelität und begrenztem RAM; große Objekte werden gestreamt oder in begrenztem lokalen Spool verarbeitet. S3-Multipart für große Objekte ist eine ausdrückliche Werkzeugfunktion und wird separat getestet. + +Das root-lesbare Journal enthält Provider, Quell-/Zielidentität, Bucket, Image-Digests, Konfigurationsfingerprint, Phase, je Objekt Schlüssel/Größe/Hash/Metadatenvergleich sowie abgeschlossene Prüfungen. Es enthält keine Zugangsdaten. Abbruch und Wiederaufnahme sind idempotent; die Wiederaufnahme kontrolliert zuerst die Identitäten und den Schreibstopp. Sie vertraut einem alten „kopiert“-Eintrag erst nach erneuter Zielprüfung. Fehler, geänderte Quelle oder falsches Ziel führen zu einem Abbruch ohne Umschaltung. + +Es wird der ganze zu migrierende Bucket inventarisiert, nicht nur `files.path` aus der Datenbank. Dadurch bleiben auch Exporte, Vorlagen und bislang nicht zugeordnete Objekte erhalten. Unbekannte weitere Buckets werden weder ignoriert noch gelöscht. Das Ziel ist zu Beginn leer und ausschließlich für diesen Auftrag vorgesehen. + +## 8. Platzbedarf, Dauer und Rückkehr + +Die Platzprüfung unterscheidet logische Objektbytes und physisch belegte Verzeichnisse. Kompression, Metadaten, Dateisystemreserve und Backup-Ziel werden berücksichtigt; eine Angabe wie „zweimal die Bucket-Größe reicht immer“ wäre falsch. + +Für dieselbe Platte wird mindestens gerechnet mit: + +`zusätzlich frei = neuer Speicher + altes kaltes Backup + Datenbankdump + Image-/Spoolbedarf + Reserve` + +Die bereits vorhandenen MinIO-Daten bleiben zusätzlich belegt. Bei externem Backup entfällt dessen lokaler Platz nur, wenn wirklich direkt dorthin geschrieben und die Rücklesbarkeit geprüft wird. Verbindliche Zahlen gibt es nach Objektinventar, freiem Speicher und einem repräsentativen Probelauf. + +Die Unterbrechung umfasst Backup, Kopie, vollständige Gegenprüfung und Neustart. Kopie und Hashprüfung erzeugen mehrere Lese-/Schreibdurchläufe; eine Laufzeit nur aus Dateigröße geteilt durch Netzwerkbandbreite wäre zu optimistisch. + +**Bis zur Freigabe fachlicher Schreibzugriffe:** Quelle, ursprüngliche Compose-Datei, Zugangsdaten und Anwendung bleiben verfügbar. Ein Fehler erlaubt, das Ziel zu stoppen, den alten Netzwerkzustand wiederherzustellen und MinIO mit der unveränderten Anwendung zu starten. Testschreibvorgänge müssen in isolierten Testdaten stattfinden. Der Speichertausch wird nicht gleichzeitig mit fachlichen Datenbankschemamigrationen durchgeführt. + +**Nach Freigabe fachlicher Schreibzugriffe:** Das alte MinIO ist veraltet. Ein bloßer Endpunktwechsel würde neue Dateien und Änderungen verlieren. Rückkehr erfordert erneut Wartung und eine vollständige, geprüfte Rückübernahme einschließlich Löschungen oder die bewusste Wiederherstellung eines zusammengehörigen DB-/Speicherbackups mit benanntem Datenverlustzeitraum. Kein automatischer Rückfall nach Aufnahme des normalen Betriebs. + +Alte Daten und Container bleiben bis zur geprüften ersten vollständigen Sicherung und erfolgreichen Wiederherstellung des neuen Speichers erhalten. Aufräumen ist ein eigener administrativer Vorgang. Aufbewahrungsdauer wird anhand des verfügbaren Platzes festgelegt, nicht durch den Updater stillschweigend erzwungen. + +SeaweedFS speichert Inhalt und Filer-Metadaten getrennt; beide müssen zusammenpassen. Für FEDEO wird zunächst ein kaltes Backup aller persistenten Bestandteile bei gestopptem Speicher implementiert. Der Restore-Test umfasst neue leere Verzeichnisse, vollständige Konfiguration, Schlüssel und genau das zugehörige Image. [Herstellerhinweise zu Backups](https://github.com/seaweedfs/seaweedfs/wiki/Data-Backup) + +## 9. Änderungen im Projekt und Einführungsreihenfolge + +| Arbeitspaket | Betroffene Stellen | Fertig, wenn … | +| --- | --- | --- | +| S3-Vertrag und Erprobung | neue Integrationstests, bestehender S3-Client | MinIO und ausgewählter Ersatz denselben FEDEO-Vertrag bestehen | +| Speicherinitialisierung | neues FEDEO-Hilfsprogramm/-image, Compose | Bucket ohne `mc` privat und wiederholbar bereitsteht | +| Installer | `scripts/selfhost-setup.sh`, `.env.example`, Compose | Neuinstallation und erneuter Start Daten/Zugänge erhalten | +| Providerprüfung | `scripts/selfhost-update.py` | Explizite Adapter für Legacy-MinIO und SeaweedFS statt allgemeiner Lockerung der Mount-/Dienstprüfungen | +| Datenübernahme | neuer Host-Ablauf plus Kopier-/Prüfwerkzeug | Journal, Sperre, Wiederaufnahme, Integritätsprüfung und Rückkehr funktionieren | +| Backup/Restore | Host-Updater und Betriebsdokumentation | Kalte Sicherung und vollständiger Restore für beide Provider geprüft sind | +| Oberfläche und API | `selfhost-update-service.py`, Backend-Updater-Modul/-Routen, `useSelfhostUpdates`, `SelfhostUpdateCard.vue` | Plan, Fortschritt, Sperren und bereinigte Fehlerdetails der Migration sichtbar sind | +| Systemstatus | `system-status.service.ts`, Frontend-Systemstatus | „Dateispeicher“ über einen signierten S3-Funktionscheck bewertet wird | +| Exportlinks | `backend/src/routes/exports.ts` und zugehörige Auslieferung | Neue und bestehende Exportlinks den Speicherwechsel überstehen | +| Veröffentlichung | `scripts/release/publish.mjs`, Manifest, CI und Betriebsassets | Speicher-/Hilfsimages und Hostdateien vollständig geprüft ausgeliefert werden | + +Vorgeschlagene Reihenfolge: + +1. **Erprobung:** Datensatz und Restore in einer isolierten Umgebung testen. Keine produktive Quelle als Schreibziel verwenden. +2. **Vorbereitender Release:** Herstellerneutrale Checks, Exportlinks, Initialisierung ohne `mc`, beide Provider-Adapter und Migrationsprotokolle liefern. Bestehende Instanzen behalten zunächst MinIO. Für deren Übernahme wird das tatsächlich vorhandene geprüfte MinIO-Image erhalten; der Übergang darf keinen erneuten Bezug des gesperrten `mc` verlangen. +3. **Host-Dienst nachrüsten:** Die zusammengehörigen Host-Dateien aus diesem geprüften Stand installieren. Der aktuelle Host-Dienst ersetzt sich bei einem Anwendungsupdate nicht selbst. Ein Update der Weboberfläche allein reicht daher nicht. +4. **Separater Migrationsauftrag:** Auf unverändertem Anwendung-/Datenbankschema den Speicherwechsel mit Vorschau, Platzbedarf und Wartungsfreigabe durchführen. Nach erfolgreicher Migration normale Anwendungsupdates wieder erlauben. +5. **Neuer Standard:** Neue Installationen erhalten SeaweedFS direkt. Der Legacy-Adapter bleibt während der Übergangszeit zum Migrieren und Wiederherstellen verfügbar. + +Die bisherigen Prüfschranken werden nicht pauschal entfernt: Nur ausdrücklich unterstützte Providerübergänge dürfen Dienste, Datenmounts und Bootstrap-Konfiguration ändern. PostgreSQL-, Mandanten- und sonstige Mount-Regeln bleiben streng. Ein ausgefallener Migrationsauftrag blockiert parallele Releases, bis sein Zustand geklärt ist. + +API-Felder und Phasen wie `storage_copying` und `storage_verifying` müssen in Host-Dienst, Backend-Allowlist und Frontend gemeinsam eingeführt werden. Ein eigener Migrationsauftrag benötigt dieselben aktuellen globalen Adminrechte, bestätigten Bearer-Zugang und idempotenten Auftrags-IDs wie Updates. Er ist nicht über frei angegebene Shell-Befehle oder URLs konfigurierbar. + +Providerwechsel, Journal und Schreibfreigabe benötigen einen dauerhaften Zustand vor dem tatsächlichen Start der Schreiber, damit auch ein Hostabsturz den Rückkehrpunkt nicht verschleiert. Bestehende `mutationStarted`-/`recoveryRequired`-Flags allein beschreiben diese Grenze nicht ausreichend. + +Alte Updater können eine neue Compose-Struktur weiterhin ablehnen. Die Mindestversion des Host-Dienstes wird deshalb Bestandteil der Release-Vorschau. Die konkrete FEDEO-Versionsnummer folgt den Commit-Regeln; es wird keine Versionsnummer vorab versprochen und kein bestehender Release überschrieben. Inkompatible Änderungen an Betriebsverträgen müssen gegebenenfalls als Breaking Change mit Migrationshinweis gekennzeichnet werden. + +## 10. Abnahmekriterien + +Der Austausch ist erst freigegeben, wenn alle folgenden Punkte nachgewiesen sind: + +1. Der vollständige S3-Vertrag aus Abschnitt 5 funktioniert mit dem exakten Backend-Lockfile und dem gepinnten Zielimage. +2. Alle inventarisierten Objekte sind vorhanden; Schlüsselmenge, Größen, SHA-256 und zu erhaltende Metadaten stimmen. Kein stiller Ausschluss unbekannter Objekte. +3. Upload, Download, PDF-Vorschau, ZIP, WebDAV, DATEV/SEPA, Mandantenexport und -import sowie Hintergrundverarbeitung funktionieren. Zwei Mandanten können weiterhin nicht gegenseitig auf ihre Dateien zugreifen. +4. Anonymer Zugriff, falsche Schlüssel und Zugriff auf nicht freigegebene Buckets werden abgewiesen. Fehlende Start-Zugangsdaten führen zum Startabbruch. +5. Datei-/Präfixkonflikte, unterstützte maximale Objektgröße und ungewöhnliche Schlüssel sind vorab erkannt beziehungsweise erfolgreich getestet. +6. Abbrüche bei Kopie, Vollprüfung, DNS-Umschaltung und Neustart lassen sich ohne falschen Erfolg oder Verlust vorhandener Daten behandeln. Auch ein harter Host-Neustart wird geprüft. +7. Rückkehr vor Schreibfreigabe und Wiederherstellung nach Schreibfreigabe sind praktisch getestet. Ein Restore nur anhand von Tar-Inhaltsverzeichnissen reicht nicht. +8. Ein reguläres Anwendungsupdate auf dem neuen Speicher erstellt ein vollständiges Backup und kann bei Ausfall der fremden Registry mit bereitgestellten Images weiterarbeiten. +9. Ein Neuaufbau aus externem Backup und Offline-Images funktioniert ohne Quay und ohne öffentlichen Upstream-Download. +10. Gemessene Übernahmedauer und Platzreserve passen zur konkreten Instanz; der Probelauf nennt CPU/RAM, Objektanzahl, Größenverteilung und Datenträger. Unzureichende Werte blockieren die Freigabe. + +Offen vor der Implementierung sind insbesondere Objektanzahl/-volumen dieser Instanz, größtes Objekt, freie Plattenkapazität, zusätzliche S3-Nutzer, aktivierte Bucket-Sonderfunktionen, Standort des externen Backups und das akzeptable Wartungsfenster. Diese Werte beeinflussen die Durchführung, nicht die Notwendigkeit der Integritätsprüfung. + +## 11. Ergebnis für die betroffene Instanz + +Die Instanz steht laut vorgelegtem Protokoll noch vor einer mutierenden Updatephase. Sie kann daher zunächst auf dem vorhandenen Speicher bleiben, während der Ersatz erprobt wird. Das Austauschkonzept benötigt keinen erfolgreichen Download des fehlgeschlagenen `mc`-Images. Voraussetzung der späteren Übernahme ist ein erreichbares, lesbares Quell-MinIO oder dessen geprüfte Wiederherstellung. + +Der nächste Umsetzungsschritt ist ein reproduzierbarer S3-Kompatibilitäts- und Restore-Test mit SeaweedFS. Erst dessen Ergebnis rechtfertigt die Implementierung und Freigabe des produktiven Migrationspfads. diff --git a/docs/minio-umstellung-pilot.md b/docs/minio-umstellung-pilot.md new file mode 100644 index 00000000..430fb36e --- /dev/null +++ b/docs/minio-umstellung-pilot.md @@ -0,0 +1,307 @@ +# MinIO → SeaweedFS: betreuter Pilot auf einer Installer-Instanz + +Stand: 28. September 2026. Dieser Ablauf ergänzt das +[Austauschkonzept](minio-austausch-konzept.md) um ausführbare Werkzeuge. +Er übernimmt den Speicher einer vorhandenen Installation, beispielsweise 3.3.0, +mit unveränderten Anwendungsimages und ohne Datenbankschemamigration. + +**Vor dem ersten Wartungsfenster nur `load-images` und `plan` ausführen.** +Die Vorprüfung ermittelt die bislang unbekannten Größen und liefert eine +kompakte Ausgabe zum gemeinsamen Prüfen. Sie stoppt keine Anwendungscontainer. +Die fachliche Abnahme erfolgt zusätzlich auf der konkreten Instanz. + +## Was der Pilot leistet und wo seine Grenze liegt + +- Vorhandenes MinIO verwenden; kein Abruf von `minio/minio` oder `mc` erforderlich. +- SeaweedFS 4.47 mit dokumentierter FEDEO-Metadatenkorrektur; Offline-Images, + SHA-256-geprüftes Paket. +- Alle Objekte des einzigen FEDEO-Buckets übernehmen, inklusive Exporte und + Objekte ohne aktuellen Datenbankverweis. Schlüssel und Metadaten bleiben erhalten. +- Alle bekannten Schreiber anhalten, ihre automatischen Neustarts sperren, + PostgreSQL dumpen und MinIO kalt sichern. Die alten Daten bleiben erhalten. +- Kopie, vollständigen Inhaltsvergleich und tatsächlichen SeaweedFS-Restore in + ein frisches Verzeichnis prüfen. Unbekannte Zielobjekte werden nicht gelöscht. +- Den S3-Vertrag zusätzlich mit dem **tatsächlich installierten Backendimage** + ausführen. Dabei startet nur das Prüfprogramm, kein FEDEO-Backend. +- Erst nach diesen Prüfungen den Alias `minio` exklusiv an SeaweedFS vergeben + und die unveränderte Anwendung wieder starten. + +**Der Pilot ist noch kein neuer Standardinstaller und kein reguläres +FEDEO-Release.** Ältere Anwendungs-Updater kennen nur MinIO. Ihre Aufträge +bleiben nach der Umstellung bewusst über `recoveryRequired` gesperrt. Dieser +Entwicklungsstand enthält den SeaweedFS-Adapter und eine ausdrücklich geprüfte +Übergabe über `adopt-updater` (unten). Diesen Zustand nicht mit dem alten +`resolve` oder durch Löschen der Statusdatei aufheben. Ein alter Installer oder +ein altes Release-Compose darf die umgestellte Installation nicht überschreiben. + +FEDEO 3.3.0 kann im Systemstatus weiterhin den MinIO-spezifischen Health-Endpunkt +abfragen und dadurch den Dateispeicher als gestört anzeigen. Die tatsächliche +Funktionsprüfung erfolgt im Pilot über signierte S3-Operationen. Dieser +Entwicklungsstand prüft den angemeldeten S3-Bucket auch im Systemstatus; dafür +ist anschließend ein Anwendungsrelease mit dieser Änderung erforderlich. +Der Speicherwechsel selbst bleibt eine eigene betreute Hostaktion. Der bisherige +Standardinstaller wird durch die Migration nicht ersetzt. + +### Warum das Pilotimage eine gezielte Korrektur enthält + +Das unveränderte SeaweedFS 4.47 entfernt beim Speichern den expliziten MIME-Typ +`application/octet-stream`. Bei einem `.pdf`-Schlüssel liefern HEAD und GET +dadurch später `application/pdf`. Diese Abweichung wurde beim ersten betreuten +Versuch durch den strengen Metadatenvergleich erkannt; die Instanz wurde vor +Schreibfreigabe erfolgreich auf MinIO zurückgeführt. + +`scripts/storage/Dockerfile.seaweedfs` baut deshalb die feste Herstellerrevision +`c5073360007d28385a33426a42ac3e4ec504c5a3` mit +`preserve-s3-content-type.patch` als `4.47-fedeo.1`. Die Korrektur bewahrt den +expliziten Typ für S3-Einträge; die Normalisierung gewöhnlicher Dateisystemeinträge +bleibt erhalten. Quellarchiv, Go-Buildimage und Hersteller-Basisimage sind per +SHA-256 festgelegt. Gezielte Go-Tests laufen beim Build; das Paket enthält den +Buildplan und Patch mit Prüfsummen. Der S3-Vertrag prüft den generischen MIME-Typ +zusätzlich mit HEAD, GET und dem Original-Backend-SDK. + +Dies ist eine eigene Buildvariante. Bei einem späteren SeaweedFS-Update muss die +Korrektur weitergeführt oder durch einen nachgewiesenen Herstellerfix ersetzt +werden; das ungeänderte Herstellerimage ist für diese 1:1-Übernahme nicht freigegeben. + +## Voraussetzungen, die der Plan prüft + +Linux amd64, Python ab 3.10, lokaler Docker-Daemon, Docker Compose und `tar`/`du`. +Die Installation muss laufen und aus dem Installer stammen: lokale Verzeichnisse +`postgres/` und `minio/`, interner Endpunkt `http://minio:9000`, S3-Zugang wie beim +Installer aus `MINIO_ROOT_*`, keine externen Secret-Provider, keine zusätzlichen +MinIO-Ports, Datenmounts oder unbekannten Container im internen Netz. +Bekannte lokale Matrix-Dienste werden erhalten, während der Kopie angehalten und +mit ihren Daten kalt gesichert. Andere Zusatzdienste/Compose-Overrides blockieren +den Pilot und benötigen einen angepassten Plan. + +Der Plan hält auch vorhandene Container-Healthzustände fest. Bereits vor der +Migration als `unhealthy` bekannte Matrix-Nebendienste müssen beim Wiederanlauf +wieder laufen, blockieren aber nicht allein durch denselben Healthfehler die +FEDEO-Freigabe. FEDEO-Kerndienste und zuvor gesunde Matrix-Dienste müssen weiterhin +ihre Healthchecks bestehen; erforderliche Dienstabhängigkeiten bleiben erhalten. +Der Abschlusszustand nennt diese Altfehler unter `preexistingUnhealthyServices`. + +Bereits durch ein früheres Update stillgelegte Matrix-Container dürfen weiterhin +zum Compose-Projekt gehören, obwohl sie nicht mehr in dessen Konfiguration stehen. +Der Pilot akzeptiert sie nur gestoppt und mit Neustartrichtlinie `no`, erhält ihre +Container und Images und nimmt sie nicht wieder in Compose auf. Ihre lokalen +Matrix-Bind-Verzeichnisse werden ebenfalls kalt gesichert. Die alten anonymen +Redis-/Coturn-Volumes bleiben unverändert an ihren stillgelegten Containern; +sie gehören nicht zum neuen Speicherdienst oder dessen Restore-Test. + +Der S3-Prüfer blockiert zusätzliche Buckets, Versionierung einschließlich alter +Versionen/Delete-Marker, Object Lock, konfigurierte Serververschlüsselung, +Objekt-/Bucket-Tags, eigene Policies/ACLs, Lifecycle, Replikation, Benachrichtigungen, +CORS und offene Multipart-Uploads. Unklare S3-Fehler werden nicht als „nicht vorhanden“ +gewertet. Datei-/Verzeichniskonflikte und normalisierungsgefährdete Schlüssel wie +`a//b`, `a/../b` und Verzeichnismarker blockieren ebenfalls. + +Die bekannten lokalen MinIO-Metadaten werden zusätzlich geprüft (`xl-single`, +Metadatenformat 3). MinIO kann bei gleichzeitigem `a` und `a/b` einen Schlüssel +aus der S3-Liste verbergen, obwohl er per GET erreichbar bleibt. Bei gestopptem +MinIO muss deshalb die Menge lokaler `xl.meta`-Objektpfade exakt mit dem S3-Inventar +übereinstimmen. Andere Speicherformate oder Abweichungen blockieren die Umschaltung. + +Getestete Pilotgrenzen: **200.000 Objekte, höchstens 1 GiB je Objekt**. +Die Kapazitätsabschätzung berücksichtigt Quellsicherung, neues und wiederhergestelltes +Ziel, Metadatenreserve pro Objekt, DB-Dump, Offline-Images, Spool und 5 GiB Reserve. +Nach dem Schreibstopp wird das Inventar erneut ermittelt. Es gibt keine Annahme, +dass eine unbekannte freie Kapazität ausreichend ist. + +Externe Schreiber lassen sich nicht allein anhand von Docker erkennen. Vor +`migrate --writers-exclusive` muss feststehen, dass keine anderen Anwendungen, +direkten DB-/S3-Clients oder manuellen Compose-Aufträge parallel schreiben. + +## Paket erstellen und auf den Host übertragen + +Im Entwicklungscheckout mit Docker: + +```sh +bash scripts/storage/build-pilot.sh +``` + +Ergebnis: `.release/storage-pilot.tar.gz` samt `.sha256` und entpacktem Paket. +Das Archiv enthält Hostprogramme, Dokumentation und beide benötigten Zielimages. +Es enthält keine Instanz-Zugangsdaten, keine Kundendateien und kein neues MinIO. +Die Build-Phase darf Images herunterladen; alle Schritte auf dem Zielhost starten +Container mit `--pull never`. + +Archiv und Prüfsumme über den üblichen Administrationsweg auf den Docker-Host +kopieren. Dort die tatsächliche Prüfsumme mit der mitgelieferten vergleichen, +beispielsweise bei Ablage unter `/root`: + +```sh +cd /root +sha256sum storage-pilot.tar.gz +tar -xzf storage-pilot.tar.gz +cd storage-pilot +sudo python3 pilot.py load-images +sudo python3 pilot.py plan --directory /opt/fedeo +``` + +Die Ausgabe von `plan` kann in den Supportdialog kopiert werden. Sie enthält +Phase, Anwendungsversion, Objektanzahl, Objektbytes und benötigten/verfügbaren +Platz; keine Passwörter oder Dateinamen. Falls der Installer in ein anderes +Verzeichnis installiert wurde, bei jedem Befehl denselben Pfad angeben. + +Ein Plan verändert keine Quelldateien oder fachlichen Daten. Er legt geschützte +Migrationsdateien unter `.updates/storage-migration/` und einen lokalen Image-Tag +zur Aufbewahrung des Hilfsimages an. Die `storage/`-Datenablage entsteht erst beim +Migrationslauf. Das Paket bleibt bis zum Abschluss verfügbar; nicht mitten im +Auftrag neu bauen oder austauschen. + +## Wartungsfenster: kopieren, prüfen, dann freigeben + +Erst nach Prüfung der Planausgabe und Abstimmung des Wartungsfensters: + +```sh +sudo python3 pilot.py migrate --directory /opt/fedeo --writers-exclusive +sudo python3 pilot.py status --directory /opt/fedeo +``` + +`migrate` endet bei `phase: verified`. Die Anwendung ist dann **weiter angehalten**. +Es hat noch keine fachlichen Schreibzugriffe auf SeaweedFS gegeben. +Der Lauf besitzt dieselbe exklusive Sperre wie der Host-Updater. + +Die Umschaltung ist ein eigener Befehl: + +```sh +sudo python3 pilot.py activate --directory /opt/fedeo +``` + +`activate` liest Quelle und Ziel nochmals vollständig, stoppt MinIO, entfernt +dessen internen Netzwerkanschluss, sichert SeaweedFS kalt und startet einen +separaten Restore-Container mit frisch entpackten Daten. Alle Objekt-Hashes und +Metadaten müssen dort stimmen. Danach erhält das aktive Ziel allein den Alias +`minio`, und die S3-Vertragstests laufen erneut, auch mit dem Original-Backend-SDK. + +**Vor dem Start irgendeines fachlichen Schreibers** persistiert das Programm +`writesReleased: true`. Erst danach werden Backend/Hintergrunddienste und zuletzt +der öffentliche Proxy gestartet. Ein Fehler beim Neustart führt nicht zu einem +automatischen Rückfall auf den nun möglicherweise veralteten Quellspeicher. + +Anschließend auf der Instanz prüfen: Anmeldung, bestehender Download, PDF-Vorschau, +neuer Upload mit erneutem Download, WebDAV, DATEV/SEPA und Mandantenexport/-import. +Bei zwei Testmandanten auch die unveränderten Zugriffsgrenzen kontrollieren. +Bereits ausgegebene S3-Links sind zusätzlich über ihren tatsächlichen Zugriffsweg +zu prüfen; ein interner Docker-Alias macht interne URLs nicht öffentlich erreichbar. + +## Fehler und Wiederaufnahme + +| Zustand | Vorgehen | +| --- | --- | +| `planned` | Instanz läuft noch; Wartungsfenster vorbereiten. | +| `freezing`, `backing_up`, `backed_up`, `copying`, `verifying`, `verified` | `migrate --writers-exclusive` setzt fort. Quelle, Schreibstopp, Backups und Inhalte werden erneut geprüft. | +| `cutover`, `restore_testing` | `activate` setzt die noch nicht freigegebene Umschaltung fort; alternativ Rückkehr. | +| `released` nach fehlgeschlagenem Start | `resume-start` versucht denselben Zielstand erneut. Keine einfache Rückkehr mehr. | +| `complete` | SeaweedFS aktiv; alte Daten und Backups weiter aufbewahren. | +| `rolled_back` | MinIO wieder aktiv. Vor einem neuen Versuch einen neuen betreuten Plan anlegen; bestehende Beweise nicht löschen. | + +Vor der Schreibfreigabe ist die Rückkehr ausführbar: + +```sh +sudo python3 pilot.py rollback --directory /opt/fedeo +``` + +Sie stoppt das Ziel, stellt Compose, den alten exklusiven Netzwerkanschluss und +die ursprünglichen Neustartrichtlinien wieder her und startet die vorher laufenden +Container. Quelldaten und DB bleiben unverändert. Nach `writesReleased: true` +verweigert das Programm diesen Befehl. Dann braucht eine Rückkehr eine gesonderte +Rückmigration einschließlich Löschungen oder die bewusste Wiederherstellung eines +zusammengehörigen Backups. + +## Protokolle, Sicherungen und Betriebsdaten + +`status` ist die kompakte Ausgabe ohne Geheimnisse. Geschützte Einzelheiten liegen +unter `/opt/fedeo/.updates/storage-migration/`: + +- `state.json`: Phase, Container-/Image-Identitäten und dauerhafte Schreibgrenze. +- `commands.log`, `progress.jsonl`: Hostfehler und letzter Werkzeugfortschritt. +- `copy/inventory.json`, `copy/objects.jsonl`, `copy/verified.json`: vollständiges + Inventar und überprüfte Objekt-Hashes. Diese Dateien enthalten Dateinamen/Metadaten. +- `backup/database.dump`, `globals.sql`, `files.tar`, `images.tar`, `complete.json`: + zusammengehörige Quellsicherung mit Prüfsummen. Der DB-Dump wird mit `pg_restore --list` + geprüft; ein vollständiger fachlicher DB-Restore bleibt eine gesonderte DR-Prüfung. +- `backup/seaweedfs.tar`: kalt gesicherter neuer Speicher samt Konfiguration; + sein SHA-256 und erfolgreicher echter Restore werden im Zustand festgehalten. + +Die neue persistente Ablage ist `storage/seaweedfs/`, die geschützte Konfiguration +`storage/config/`. SeaweedFS bindet Verwaltung, Filer und Volume-APIs an Loopback +im Container; im internen Docker-Netz liegt ausschließlich S3 auf Port 9000. +Ein Startwrapper verweigert fehlende oder veränderte Zugangskonfiguration. +Die Anwendungsidentität erhält nur Lese-, Schreib- und Listenrechte für ihren Bucket. + +Für spätere Sicherungen **SeaweedFS anhalten und `storage/` vollständig sichern**, +einschließlich Filer-Metadaten, Masterzustand, Objektdaten, Konfiguration und passendem +Image. Die DB-Sicherung muss zum selben Schreibstopp gehören. Die Sicherungen auf +demselben Host anschließend auf das vorgesehene externe Backupziel übernehmen. +MinIO-Daten, alte Container, Test-Restores und Offline-Images werden vom Pilot +nicht automatisch gelöscht. + +## An den regulären Updater übergeben + +Erst nach `phase: complete`, erfolgreicher Anmeldung und fachlicher Prüfung eines +bestehenden Dokuments ausführen. Die Übergabe stoppt keine FEDEO-Container: + +```sh +sudo python3 pilot.py adopt-updater --directory /opt/fedeo +sudo python3 /usr/local/lib/fedeo-updater/selfhost-update.py check --directory /opt/fedeo +``` + +Das neu erstellte Paket enthält die vier zusammengehörigen Updater-Dienstdateien +mit Prüfsummen. `adopt-updater` installiert zuerst diesen Host-Dienst und ruft +danach `adopt-storage` auf. Damit wird die alte Sperre erst nach Installation des +passenden Updaters freigegeben. Bereits ausgegebene Pilotarchive bleiben unverändert; +für eine schon umgestellte Instanz ein neues geprüftes Paket bereitstellen. +**Dort nur `adopt-updater` ausführen, nicht erneut planen, kopieren oder aktivieren.** +Für diese reine Übergabe ist kein erneutes Laden der Images erforderlich. + +Die Übernahme verlangt den abgeschlossenen Migrationszustand einschließlich +Schreibfreigabe, vollständigem Kopiernachweis, erfolgreicher S3-Abnahmen und +prüfsummengleicher Restore-Sicherung. Compose und `.env` müssen dem Pilotstand +entsprechen. Sie prüft außerdem die tatsächlich laufenden Anwendungsimages, +SeaweedFS-Image, lokale Mounts, Konfigurationsdateien und internen S3-Alias sowie +das gestoppte und getrennte ursprüngliche MinIO. Ein aktueller Lesezugriff erfolgt +mit dem installierten Backend-SDK. Fehler lassen die Updatesperre bestehen. + +Danach sind `check` und `apply` über den Host-Dienst und die bestehende Oberfläche +möglich. Der erste Prüfplan benötigt keine pauschale Compose-Übernahmefreigabe. +Der Adapter erhält SeaweedFS samt Konfiguration, Datenpfaden, Zugangsdaten und +dem während der Migration festgehaltenen PostgreSQL-Image. Er entfernt die alten +MinIO-Dienste aus dem heruntergeladenen Release-Compose, bevor Images geladen +werden. Ein Anwendungsupdate lädt oder startet daher weder MinIO noch `mc`. +Ein Wechsel der SeaweedFS- oder PostgreSQL-Version ist ein separater Vorgang. + +Vor jeder Datenbankschemamigration prüft das **Zielbackend-SDK** Schreiben, +Lesen, MIME-Erhalt, Streaming, signierte Links, anonymen Zugriffsschutz und +Löschen am aktiven Speicher. Ein Fehler hält die Anwendung angehalten und +bewahrt den Wiederherstellungszustand. Die normale Anwendungsupdatesicherung +enthält `storage/`, die Speicherbeschreibung und das exakte SeaweedFS-Image. +Wiederherstellung und Grenzen stehen in [Selfhost-Updates](selfhost-updates.md). + +## Nachgewiesene Tests und ausstehende Freigaben + +Der lokale S3-Test verwendet das offizielle MinIO-Release-Binary vom 7. September +2025 und SeaweedFS 4.47 mit der dokumentierten MIME-Korrektur. 1.005 Objekte / 1.073.752.750 Bytes, +einschließlich 1-GiB-Grenzdatei, Pagination, Sonderzeichen, Metadaten, leeren +Dateien, Streaming, 24-Stunden-Signaturen, fremdem Bucket und ungültigen Zugängen +werden geprüft. Beschädigte Zielobjekte werden erkannt und beim Fortsetzen +erneut kopiert; der kalte Restore wird vollständig gelesen und verglichen. +Testhost: Linux, 16 logische CPUs, rund 29 GiB RAM für Docker, lokaler NVMe-Speicher. +Die Laufzeit hängt von Objektanzahl, Datenmenge und Host ab. + +Das Hilfs-Lockfile enthält den übernommenen vollständigen SDK-Abhängigkeitsbaum +des Backends, nicht nur dieselbe oberste Versionsnummer. Beim Pilot wird außerdem +das konkrete installierte Backendimage gegen das Ziel geprüft. + +Die Host-Integrationstests verwenden echte Speicher- und PostgreSQL-Container, +aber künstliche Anwendungsprozesse. Rückkehr vor Schreibfreigabe sowie vollständige +Umschaltung mit Restore und gesperrter Rückkehr nach Schreibfreigabe wurden erfolgreich +durchlaufen. Die fachliche Abnahme von FEDEO auf der +konkreten Instanz, ein physischer Hostneustart während jeder Phase und die +vollständige Wiederherstellung auf einem anderen Host sind damit noch nicht +nachgewiesen. Der zusätzliche Test `scripts/update/tests/host_storage_integration.py` +prüft Migration, Updater-Übernahme, zwei Anwendungsupdates und Wiederherstellung +aus einer regulären Updatesicherung mit echten Speicher-/Datenbankcontainern +und künstlichen Anwendungsimages. Deshalb bleibt der Speicherwechsel ein +betreuter Pilot; die allgemeinen Freigabekriterien des Konzepts gelten weiter. diff --git a/docs/scanner-dokumentenablage.md b/docs/scanner-dokumentenablage.md new file mode 100644 index 00000000..8916bb63 --- /dev/null +++ b/docs/scanner-dokumentenablage.md @@ -0,0 +1,51 @@ +# Epson-Scanner und Dokumentenablage + +Unter **Organisation → Dokumentenablage** erscheinen noch nicht abgelegte Scanner-Dateien des aktiven Mandanten, neueste zuerst. Die Seite aktualisiert sich alle zehn Sekunden; Suche, Öffnen und Herunterladen sind verfügbar. Jede übertragene Datei wird unverändert als ein Dokument gespeichert. Ein mehrseitiges PDF bleibt ein Dokument. Es gibt keine automatische Seitentrennung, OCR, Klassifizierung oder Rechnungsverarbeitung. + +## In Dateien ablegen + +1. Beim Dokument **Ablegen** wählen und bei Bedarf das Original öffnen. +2. Einen vorhandenen FEDEO-Dateiordner oder **Dateien (Hauptebene)** auswählen. Unterordner erscheinen mit ihrem vollständigen Pfad. +3. Einen **Dokumenttyp** aus den vorhandenen Dateitypen wählen. Neue Typen lassen sich unter **Stammdaten → Dateitypen** anlegen. Der Standardtyp eines Ordners wird vorausgewählt; ein vorgeschriebener Typ ist nicht änderbar. +4. **In Dateien ablegen** speichert Ordner und Typ am bestehenden Original. Danach verschwindet das Dokument aus dem Eingang und ist unter **Dateien** im gewählten Ordner verfügbar. Es wird keine Kopie erzeugt und keine weitere Verarbeitung ausgelöst. + +Nur aktive Ordner und Typen desselben Mandanten sind zulässig. Bei einem Fehler bleibt das Dokument im Eingang. Ein erneuter Scanner-Upload mit demselben Namen und Inhalt bestätigt weiterhin den ursprünglichen Empfang, ohne einen neuen Eingangseintrag anzulegen. + +## Einrichtung + +1. Als Administrator den gewünschten Mandanten auswählen und auf der Seite **Scanner einrichten → Scanner-Zugang erstellen** wählen. +2. Zieladresse, Benutzername und das einmalig angezeigte Passwort übernehmen. Der Zugang gehört ausschließlich zu diesem Mandanten und kann nur Scanner-Dateien einliefern. Er verwendet kein persönliches FEDEO-Passwort. Ein neues Passwort ersetzt das alte; **Zugang deaktivieren** sperrt weitere Übertragungen. +3. Am Epson ES-580W oder ES-C380W **Netzwerkordner/FTP → WebDAV (HTTPS)** wählen. In Web Config kann der Zieltyp **SharePoint (WebDAV)** heißen; dort bei separater Auswahl von HTTPS im Feld **Speichern unter** den Adressanteil ohne `https://` eintragen. Zieladresse und Zugangsdaten eintragen, Port 443 bzw. den Port der eigenen HTTPS-Adresse verwenden. Das Serverzertifikat muss vom Scanner akzeptiert werden. +4. PDF, Duplex und beispielsweise 300 dpi einstellen. Das Ziel als **FEDEO** speichern. Dateinamen mit Datum/Uhrzeit und laufender Nummer verwenden. Für getrennte Dokumente jeweils eine eigene Datei übertragen; Vorder- und Rückseite können in einer PDF bleiben. + +Die vollständige Adresse wird aus der konfigurierten Backend-Adresse gebildet, z. B. `https://fedeo.example/backend/scanner-inbox/`. Ein vorhandener `/backend`-Präfix muss erhalten bleiben. Es ist kein lokaler Rechner oder Geräte-Agent erforderlich. + +Grundlage sind die Epson-Handbücher für [ES-580W](https://download.epson.de/pub/download/6371/epson637123eu.pdf) und [ES-C380W](https://download4.epson.biz/sec_pubs/es-c380w/useg/en/GUID-55C5993A-63B2-45C9-B3C9-9C6D6801CDF0.htm). Der tatsächliche Verbindungsablauf muss bei der Inbetriebnahme am Gerät geprüft werden; es wurde kein physischer Epson-Scanner getestet. + +## Schnittstelle und Betrieb + +- Datenbankmigrationen `0073_scanner_document_inbox` und `0074_scanner_inbox_filing` werden über die reguläre Drizzle-Migration eingespielt. Keine neuen Umgebungsvariablen oder zusätzlichen Dienste sind erforderlich; der vorhandene S3-kompatible Dateispeicher wird genutzt. +- Der Scanner-Endpunkt liegt außerhalb der Browser-JWT-Anmeldung unter `/scanner-inbox/` und verwendet HTTP Basic mit eigenen zufälligen Zugangsdaten. Ausschließlich über HTTPS veröffentlichen. Passwörter werden nur als SHA-256-Hash gespeichert. +- Unterstützt werden `OPTIONS`, `PROPFIND` (Depth 0/1), `HEAD` und `PUT /scanner-inbox/`. Der Empfangsordner existiert bereits; Unterordner, Lesen, Löschen, Umbenennen und Überschreiben über den Scanner-Zugang sind nicht vorgesehen. Dies ist ein begrenzter WebDAV-Upload-Eingang, kein allgemeines Netzlaufwerk. Ein PROPFIND des Ordners gibt keine Dokumentenliste preis. +- `PUT` enthält genau eine vollständige Datei als Rohdaten, ohne Multipart-Formular. PDF, JPEG, PNG und TIFF werden anhand von Dateiendung und Signatur geprüft, maximal 100 MiB. Keine Prüfung der gesamten Dokumentstruktur auf Beschädigungen. +- Erfolgreiches Speichern: `201`. Identische Wiederholung unter demselben Dateinamen: `204`, ohne zweiten Ablageeintrag. Anderer Inhalt unter demselben Namen: `409`; mit `If-None-Match: *` bei vorhandenem Namen: `412`. Gleicher Inhalt unter einem neuen Namen wird als weiteres Dokument akzeptiert. +- Fehlende/ungültige/deaktivierte Zugangsdaten: `401`; leerer Upload/ungültiger Pfad: `400`; zu groß: `413`; falsches Format: `415`; Mandantenwartung: `423`. Bei Speicherfehlern gibt es keine Erfolgsbestätigung und keinen unvollständigen Ablageeintrag. Der Scanner kann erneut senden. +- Der Reverse Proxy muss die genannten HTTP-Methoden, den Authorization-Header und Uploads bis 100 MiB zulassen. Bei einem abgeschnittenen Pfadpräfix sollte er `X-Forwarded-Prefix` setzen (Traefik StripPrefix erledigt dies). HTTPS endet üblicherweise am bestehenden Proxy. +- Die Browser-API unter `/api/document-inbox` erfordert die normale FEDEO-Anmeldung und einen aktiven Mandanten. Portalbenutzer sind ausgeschlossen. Scanner-Zugänge verwalten nur Administratoren. Die Originale sind außerdem über die bestehende Dateiverwaltung zugänglich. +- `GET /api/document-inbox/filing-options` liefert verfügbare Ordner und Typen. `POST /api/document-inbox/:id/file` mit JSON `{ "folder": "", "type": "" }` klassifiziert das Original und markiert den Eingang atomar als abgelegt. Für die Hauptebene ist `folder` als JSON-`null` zu senden. Ein bereits abgelegtes Dokument ergibt `409`; zwischenzeitlich archivierte oder fremde Ziele werden abgewiesen. Dateiänderungen enthalten Zeitpunkt und Benutzer. + +## Lokaler Funktionstest + +Mit Testzugangsdaten und einer Test-PDF gegen eine eigene Instanz: + +```bash +curl --user "$SCANNER_USER:$SCANNER_PASSWORD" -X PROPFIND -H 'Depth: 0' "$SCANNER_URL" +curl --user "$SCANNER_USER:$SCANNER_PASSWORD" -H 'Content-Type: application/pdf' --upload-file test.pdf "${SCANNER_URL}test.pdf" +``` + +Die Antwort ist zunächst `201`; eine identische Wiederholung ergibt `204`. Anschließend steht genau ein Dokument in der Ablage. Die automatisierten Integrationsprüfungen verwenden eine isolierte PostgreSQL-Datenbank und einen ersetzten Objektspeicher, niemals produktive Zugangsdaten: + +```bash +cd backend +FEDEO_TEST_POSTGRES_IMAGE=postgres:16-alpine node --import tsx --test tests/scannerInbox.test.ts +``` diff --git a/docs/selfhost-updates.md b/docs/selfhost-updates.md index d8e1fd30..ae13add7 100644 --- a/docs/selfhost-updates.md +++ b/docs/selfhost-updates.md @@ -6,20 +6,75 @@ - Linux/amd64, Python ab 3.10, Docker Compose ab 2.24, `tar` und `du`. - Bestehendes Betriebsverzeichnis, standardmäßig `/opt/fedeo`, mit `.env` und `docker-compose.yml`; kein Git-Checkout. -- Standard-Stack mit `traefik`, `db`, `minio`, `createbuckets`, `backend`, `frontend` und `node-exporter`. PostgreSQL und MinIO verwenden die lokalen Verzeichnisse `postgres/` und `minio/`. +- Standard-Stack mit `traefik`, `db`, `minio`, `createbuckets`, `backend`, `frontend` und `node-exporter`. PostgreSQL und MinIO verwenden die lokalen Verzeichnisse `postgres/` und `minio/`. Nach geprüfter Pilotübernahme ersetzt `objectstore` (SeaweedFS) die beiden MinIO-Dienste; dessen Daten liegen unter `storage/`. - Als root auf dem Server ausführen: Docker-Zugriff und Leserechte für die Daten- und Zertifikatsverzeichnisse werden benötigt. Ein entfernter Docker-Daemon wird abgewiesen. - Die öffentliche HTTPS-Adresse muss vom Host erreichbar sein und ein gültiges Zertifikat haben. - Eine Wartungsunterbrechung für alle Mandanten einplanen. Vor dem Backup werden alle laufenden Dienste außer PostgreSQL angehalten, auch der öffentliche Proxy und alle im Backend laufenden Hintergrundaufgaben. Eine separate Wartungsseite folgt mit der späteren Oberflächenintegration. Der Updater verweigert externe Datenbanken, externen S3-/Seafile-Speicher, zusätzliche Dienste, Compose-Profile, geänderte Datenpfade und PostgreSQL-Imagewechsel. Dafür braucht es zunächst passende Backup-/Migrationsadapter. Eigene Einstellungen innerhalb der unterstützten Dienste können in `docker-compose.override.yml` **oder** `docker-compose.override.yaml` bleiben; der Updater verwendet diese Datei bei jedem Compose-Aufruf. Änderungen an dieser Override-Datei werden nicht überschrieben. -Eine gezielte Ausnahme ist die Stilllegung des **entfernten alten Matrix-Stacks**: `matrix-db`, `matrix-synapse`, `matrix-redis`, `matrix-element`, `matrix-livekit`, `matrix-rtc-jwt`, `matrix-turn` und `matrix-well-known` dürfen in der bestehenden Konfiguration vorkommen. Die Zielkonfiguration muss ausschließlich die sieben FEDEO-Dienste enthalten, auch nach Zusammenführung mit einer Override-Datei. Matrix wird nicht in den neuen Stack übernommen. Andere Zusatzdienste bleiben gesperrt; die Fehlermeldung nennt die konkreten Abweichungen. Ein Abbruch mit `mutationStarted: false` und `recoveryRequired: false` benötigt keine Wiederherstellung und keinen `resolve`-Aufruf. +Eine gezielte Ausnahme ist die Stilllegung des **entfernten alten Matrix-Stacks**: `matrix-db`, `matrix-synapse`, `matrix-redis`, `matrix-element`, `matrix-livekit`, `matrix-rtc-jwt`, `matrix-turn` und `matrix-well-known` dürfen in der bestehenden Konfiguration vorkommen. Die Zielkonfiguration muss ausschließlich die FEDEO-Dienste des jeweiligen Speicherproviders enthalten, auch nach Zusammenführung mit einer Override-Datei. Matrix wird nicht in den neuen Stack übernommen. Bereits stillgelegte Matrix-Container bleiben erhalten und ihre lokalen Bind-Verzeichnisse werden weiter gesichert. Andere Zusatzdienste bleiben gesperrt; die Fehlermeldung nennt die konkreten Abweichungen. Ein Abbruch mit `mutationStarted: false` und `recoveryRequired: false` benötigt keine Wiederherstellung und keinen `resolve`-Aufruf. Für diesen Übergang müssen die Matrix-Daten lokal unter `matrix/` liegen, insbesondere `matrix/postgres` und `matrix/synapse`; symbolische Links, andere konfigurierte Datenpfade, benannte Volumes und spezielle Compose-Konfigurationen benötigen eine manuelle Stilllegung. Die tatsächlichen Bind-Mounts der alten Container müssen zur Compose-Datei passen. Der Plan nennt `retiredServices` und `retainedDataPaths` und berücksichtigt den zusätzlichen Backup-Platz. Alle Matrix-Container werden vor dem Backup gestoppt. Das komplette lokale `matrix/`-Verzeichnis wird bei gestoppter Matrix-Datenbank in `files.tar` gesichert. Erst nach erfolgreichem Backup setzt der Updater die Neustartrichtlinie der alten Matrix-Container auf `no`, damit sie auch nach einem Host-Neustart stillgelegt bleiben. Er löscht weder diese Container noch ihre Daten oder Volumes. Image-seitig angelegte anonyme Volumes und schreibbare Container-Schichten bleiben an den alten Containern erhalten; sie sind nicht Bestandteil von `files.tar`. Die alten Container daher für die Wiederherstellung behalten und nicht mit `--remove-orphans` oder einem Docker-Prune entfernen. Die Stilllegung vor der Dateisicherung entspricht den Anforderungen an ein [PostgreSQL-Dateisystem-Backup](https://www.postgresql.org/docs/16/backup-file.html); die Container-Richtlinie wird mit [Docker `update --restart`](https://docs.docker.com/reference/cli/docker/container/update/) geändert. -Die Zielversion muss bereits die festen MinIO-Digests und die neuen Backend-/Frontend-Healthchecks enthalten. Ältere Releases bleiben über den in `docs/releases.md` beschriebenen manuellen Ablauf installierbar. Ein Versionswechsel des Betriebssystems oder der Docker Engine gehört nicht zu diesem Ablauf. +Die Zielversion muss die Backend-/Frontend-Healthchecks enthalten; bei weiterhin aktivem MinIO zusätzlich feste MinIO-/mc-Digests. Ältere Releases bleiben über den in `docs/releases.md` beschriebenen manuellen Ablauf installierbar. Ein Versionswechsel des Betriebssystems oder der Docker Engine gehört nicht zu diesem Ablauf. + +## Bereits auf SeaweedFS umgestellte Instanzen + +Speicherumstellung und Anwendungsupdate bleiben getrennte Wartungsschritte. +Für weitere Installer-Instanzen zuerst den [Migrationsablauf](minio-umstellung-pilot.md) +mit Kopie, vollständiger Prüfung und echtem Restore durchführen. Er verwendet +die vorhandenen MinIO-Images und benötigt keinen funktionierenden MinIO-Download. +Der normale `apply`-Befehl startet keine verdeckte Speichermigration. +Der neue Standardinstaller und Setup-Assistent erkennen vorbereitete bzw. +durchgeführte Speicherumstellungen und verweigern dort das Überschreiben der +Konfiguration oder ein pauschales Entfernen des Stacks. Alte Skriptstände besitzen +diesen Schutz nicht und dürfen auf umgestellten Instanzen nicht mehr ausgeführt werden. + +Nach Installation der **vier zusammengehörigen neuen Host-Dienstdateien** übernimmt +der neue Updater einen vollständig abgeschlossenen Pilot: + +```sh +sudo python3 /usr/local/lib/fedeo-updater/selfhost-update.py adopt-storage --directory /opt/fedeo +sudo python3 /usr/local/lib/fedeo-updater/selfhost-update.py check --directory /opt/fedeo +``` + +Das neue Pilotpaket verbindet Dienstinstallation und Übernahme als `pilot.py +adopt-updater`. Die Übernahme verändert keine Anwendungsimages und stoppt keine +FEDEO-Dienste. Sie prüft Migrations-/Restore-Nachweise, Originalzustand der +Anwendung, aktiven Speicher und S3-Lesezugriff und schreibt erst dann +`.updates/storage-provider.json`. Die alte Sperre wird als letzter Schritt +freigegeben. Bei Abbruch kann derselbe Befehl wiederholt werden. `resolve` +verweigert ausdrücklich die Freigabe einer Speichermigration. +Bei Installation aus dem Pilotpaket die CLI unter `/usr/local/lib/fedeo-updater/` +verwenden. Eventuell noch vorhandene ältere Kopien unter `/opt/fedeo/scripts/` +werden durch die Dienstinstallation nicht ersetzt. + +Weitere Anwendungsupdates erzeugen das Release-Compose mit dem übernommenen +SeaweedFS-Dienst. Image, Mounts, Startkonfiguration, interner Alias und Zugangsdaten +bleiben erhalten; MinIO und `mc` werden weder geladen noch gestartet. Das bei der +Pilotmigration festgehaltene PostgreSQL-Image bleibt ebenfalls erhalten. Eine +geänderte PostgreSQL-Referenz im Release blockiert die Anwendung bis zur separaten +Datenbankmigration. Ein Anwendungsupdate aktualisiert **nicht** die SeaweedFS-Version. + +Das Backup enthält den Datenbankdump und die bei gestopptem SeaweedFS gesicherte +vollständige Ablage `storage/` in `files.tar`, zusätzlich `storage-image.tar` und +`config/.updates/storage-provider.json`. Der Platzbedarf berücksichtigt das Image. +Vor den SQL-Migrationen wird das neue Backendimage mit seinem tatsächlichen SDK +gegen S3 geprüft (PUT/HEAD/GET/DELETE, Streaming, MIME, 24-Stunden-Signatur und +anonymer Zugriffsschutz). Ein unterbrochener Test protokolliert seinen eindeutigen +Prüfschlüssel; `resolve` bereinigt ausschließlich diesen mit passender Prüfmetadatenmarkierung, +nachdem zurückgebliebene Prüfcontainer entfernt wurden und die Anwendung wieder +erreichbar ist. Unbekannte Dateien werden nicht gelöscht. + +Die Oberfläche neuer FEDEO-Releases zeigt den erkannten Speicher im Updateplan +und unterscheidet die ausstehende Speicherübergabe von einem fehlgeschlagenen +Anwendungsupdate. Ältere Backends können den neuen Host-Dienst weiterhin nutzen; +zusätzliche Planinformationen werden dort ausgeblendet. Nach einem Apprelease +mit dem neuen Systemstatus ersetzt ein authentifizierter S3-Bucket-Check den +MinIO-spezifischen Health-Endpunkt. ## Bereitstellung @@ -162,7 +217,7 @@ Aufträge liegen dauerhaft und root-lesbar unter `.updates/service/`. Nach einem 3. Aktuelle und neue Compose-Konfiguration mit Docker Compose validieren. Projektname, Container-Identitäten, Mounts, Netzwerke und Zugangsdaten erhalten. Die Shell-Umgebung überschreibt dabei keine Werte aus der Instanz-`.env`. 4. Speicherplatz prüfen: mindestens 5 GiB frei am Docker-Datenverzeichnis vor dem Pull sowie geschätzte Backup-Größe plus Reserve im Betriebsverzeichnis. Images mit exakt gepinntem SHA-256-Digest nur laden, wenn sie lokal fehlen (`pull --policy missing`); vorhandene Tags ohne passenden Digest reichen dafür nicht aus. Bewegliche Infrastruktur-Tags weiterhin aktualisieren (`pull --policy always`). Ein fehlendes, nicht herunterladbares Image beendet den Auftrag vor der Wartung. Backup-Platz erneut prüfen. Während der anschließenden Infrastrukturstarts und Migrationen erfolgt kein weiterer Pull (`up`/`run --pull never`), auch nicht bei einer abweichenden Pull-Policy in einer Override-Datei. 5. Schreibende Dienste und Proxy anhalten. PostgreSQL bleibt für `pg_dump` aktiv. -6. Konfiguration, Container-Metadaten, PostgreSQL-Dump im Custom-Format, globale PostgreSQL-Rollen, gestoppten MinIO-Dateispeicher und Zertifikate sichern. Dump und TAR auf Lesbarkeit prüfen und SHA-256-Prüfsummen schreiben. `backup/complete.json` markiert ein vollständig geschriebenes Backup; ein Restore-Probelauf auf einer getrennten Instanz wird dadurch nicht ersetzt. +6. Konfiguration, Container-Metadaten, PostgreSQL-Dump im Custom-Format, globale PostgreSQL-Rollen, den gestoppten Dateispeicher und Zertifikate sichern. Bei SeaweedFS gehören dessen vollständige Ablage, Konfiguration und Image dazu. Dump und TAR auf Lesbarkeit prüfen und SHA-256-Prüfsummen schreiben. `backup/complete.json` markiert ein vollständig geschriebenes Backup; ein Restore-Probelauf auf einer getrennten Instanz wird dadurch nicht ersetzt. Beim Übergang vom alten Matrix-Stack enthält das TAR zusätzlich `matrix/`. Container-Metadaten enthalten die ursprünglichen Image-IDs, Mounts und Neustartrichtlinien; `complete.json` nennt die stillgelegten Dienste und erhaltenen Container. Vor dem Dateiaustausch wird deren automatischer Neustart deaktiviert. Das Zielrelease enthält keine Matrix-Dienste und keine Backend-Abhängigkeit auf Synapse mehr. 7. Compose-Datei und `.env` einzeln atomar ersetzen. In `.env` wird ausschließlich `FEDEO_VERSION` verändert; `.env.example` und Setup-Skript werden erneuert. Den laufenden Updater ersetzt dieser Vorgang nicht. 8. Infrastruktur starten, Bucket-Einrichtung ausführen und Migrationen explizit in einem benannten Einmalcontainer starten. Beim anschließenden regulären Backend-Start läuft dessen bestehende Migrationsprüfung nochmals; bereits angewendete Migrationen werden dabei übersprungen. @@ -185,7 +240,7 @@ Für die Rückkehr zum alten Stand in einem geplanten Wartungsfenster: 1. Alle schreibenden Dienste und den Proxy angehalten lassen; keinen neuen Update-Auftrag starten. 2. Prüfsummen aus `backup/complete.json` prüfen. Ursprüngliche Compose-Datei, `.env` und gegebenenfalls Override aus `backup/config/` wiederherstellen. `backup/containers.json` dokumentiert die ursprünglichen Image-IDs; insbesondere bewegliche Infrastruktur-Tags vor dem Start auf die gesicherten Image-Stände festlegen. -3. Falls Migrationen/Infrastrukturänderungen bereits begonnen haben: PostgreSQL und Dateispeicher aus dem **zusammengehörigen** Backup wiederherstellen. Der PostgreSQL-Dump ist für `pg_restore` geeignet; `globals.sql` enthält Rollen und Kennwörter und muss beim Wiederaufbau der Datenbank berücksichtigt werden. MinIO und Zertifikate bei gestoppten Diensten aus `files.tar` wiederherstellen. Die konkrete Rücksicherung bestehender Daten erfolgt bewusst manuell und ersetzt Daten. +3. Falls Migrationen/Infrastrukturänderungen bereits begonnen haben: PostgreSQL und Dateispeicher aus dem **zusammengehörigen** Backup wiederherstellen. Der PostgreSQL-Dump ist für `pg_restore` geeignet; `globals.sql` enthält Rollen und Kennwörter und muss beim Wiederaufbau der Datenbank berücksichtigt werden. MinIO bzw. die vollständige SeaweedFS-Ablage `storage/` und Zertifikate bei gestoppten Diensten aus `files.tar` wiederherstellen. Bei SeaweedFS auch die Speicherbeschreibung aus `backup/config/.updates/storage-provider.json` zurückspielen und das gesicherte Image mit `docker image load -i backup/storage-image.tar` laden. Die konkrete Rücksicherung bestehender Daten erfolgt bewusst manuell und ersetzt Daten. Der vor der Speicherumstellung erhaltene MinIO-Bestand gehört nicht zu einem aktuellen Anwendungsbackup; ihn keinesfalls als Abkürzung reaktivieren. 4. Wiederhergestellten Stack mit dessen Compose-Dateien starten und Funktionen prüfen. Alternativ den Fehler der Zielversion beheben und diese erfolgreich starten. 5. Erst nach erfolgreicher Wiederherstellung die Sperre aufheben: @@ -202,8 +257,15 @@ Bei Rückkehr zum alten Matrix-Stack dessen ursprüngliche Compose-Datei aus dem ```bash npm test npm run commits:check -cd backend && node --import tsx --test tests/selfhostUpdates.test.ts +cd backend && node --import tsx --test tests/selfhostUpdates.test.ts tests/systemStatusStorage.test.ts cd ../frontend && node --test tests/selfhost-updates.test.cjs ``` Die Update-Tests verwenden den echten Compose-Parser und einen simulierten Docker-Daemon. Sie prüfen u. a. Erfolg, Prüfsummen, Release-Auswahl, unveränderte Konfiguration, Speicherplatz, parallele Aufträge, Backupfehler, Migrationsfehler, falsche laufende Versionen und unterbrochene Aufträge. Die Matrix-Tests prüfen Stilllegung, Daten-/Container-Erhalt, Backup vor Änderung der Neustartrichtlinien, Fehler und Unterbrechungen sowie die weitere Ablehnung unbekannter Dienste. Ein vollständiger Test mit realem PostgreSQL-/MinIO-/Matrix-Restore auf einer separaten Selfhost-Testinstanz ist vor dem Produktionseinsatz zusätzlich erforderlich. + +`python3 -B scripts/update/tests/host_storage_integration.py` prüft zusätzlich +MinIO-Migration, Speicherübernahme, zwei Anwendungsupdates und Restore der +regulären SeaweedFS-Updatesicherung mit echten Docker-Containern. Anwendung und +Release-/HTTP-Antworten sind isolierte Testdaten. Benötigte Images und Aufbau +stehen in `scripts/storage/README.md`. Die fachliche Abnahme des veröffentlichten +FEDEO-Releases auf einer Testinstanz bleibt zusätzlich erforderlich. diff --git a/frontend/components/MainNav.vue b/frontend/components/MainNav.vue index cab9fdc9..743c26b7 100644 --- a/frontend/components/MainNav.vue +++ b/frontend/components/MainNav.vue @@ -52,6 +52,11 @@ const links = computed(() => { to: "/wiki", icon: "i-heroicons-book-open" } : null, + featureEnabled("files") ? { + label: "Dokumentenablage", + to: "/organisation/dokumentenablage", + icon: "i-heroicons-inbox-arrow-down" + } : null, featureEnabled("files") ? { label: "Dateien", to: "/files", diff --git a/frontend/components/SelfhostUpdateCard.vue b/frontend/components/SelfhostUpdateCard.vue index 594830a4..3d1dd504 100644 --- a/frontend/components/SelfhostUpdateCard.vue +++ b/frontend/components/SelfhostUpdateCard.vue @@ -47,7 +47,8 @@ const reload = () => window.location.reload()

Aktualisiert die gesamte Selfhost-Instanz einschließlich Docker Compose und Datenbank. Vor Änderungen wird ein Backup erstellt.

- + +

{{ statusLabel }}

@@ -58,6 +59,8 @@ const reload = () => window.location.reload()
Commit
{{ job.plan.revision?.slice(0, 8) }}
Geschätztes Backup
{{ backupSize }}
+

Dateispeicher: SeaweedFS. Die geprüfte Speicherversion bleibt erhalten und wird zusammen mit der Datenbank gesichert.

+

Dateispeicher: MinIO. Eine Umstellung auf SeaweedFS erfolgt als eigener, geprüfter Wartungsschritt auf dem Host.

Alte Matrix-Dienste werden stillgelegt; Daten und Container bleiben erhalten: {{ job.plan.retiredServices.join(', ') }}.

Auftrag: {{ job.requestId }}

diff --git a/frontend/composables/useSelfhostUpdates.ts b/frontend/composables/useSelfhostUpdates.ts index cb776bd8..6e668e81 100644 --- a/frontend/composables/useSelfhostUpdates.ts +++ b/frontend/composables/useSelfhostUpdates.ts @@ -5,13 +5,15 @@ export type UpdateState = { export type UpdateJob = UpdateState & { progress?: UpdateState; error?: { code: string; message: string }; plan?: { version: string; revision: string; previousVersion?: string; updateAvailable: boolean; - requiresComposeAdoption: boolean; estimatedBackupBytes?: number; retiredServices: string[] }; + requiresComposeAdoption: boolean; estimatedBackupBytes?: number; retiredServices: string[]; + storageProvider?: 'minio' | 'seaweedfs'; storageImageRetained?: boolean }; } export type UpdateLogs = { requestId: string; logs: { source: 'service' | 'events' | 'commands'; content: string; truncated: boolean }[] } type Overview = { acceptingRequests: boolean; engine: UpdateState; request?: UpdateJob; installed: { version?: string }; backend: { version: string; revision: string }; capabilities?: { requestLogs: boolean }; + storage?: { provider: 'seaweedfs'; migrationPending: boolean }; } type Submission = { command: 'check' | 'apply'; body: { requestId: string; version?: string; checkRequestId?: string } } diff --git a/frontend/pages/banking/statements/[mode]/[[id]].vue b/frontend/pages/banking/statements/[mode]/[[id]].vue index a2466f95..69d49b9e 100644 --- a/frontend/pages/banking/statements/[mode]/[[id]].vue +++ b/frontend/pages/banking/statements/[mode]/[[id]].vue @@ -169,7 +169,7 @@ const selectAccount = (id) => { const manualAllocationSum = ref(itemInfo.value.amount || 0) const allocationDescription = ref("") const allocationCostcentre = ref(null) -const allocationTaxKey = ref(null) +const allocationTaxKey = ref("40") const allocationAmounts = computed(() => getBankAllocationAmounts({ bankstatement: itemInfo.value.id, account: accountToSave.value, @@ -256,7 +256,7 @@ const saveAllocation = async (allocation) => { customerAccountToSave.value = null ownAccountToSave.value = null allocationCostcentre.value = null - allocationTaxKey.value = null + allocationTaxKey.value = "40" allocationBookingMode.value = "expense" allocationDepreciationMonths.value = 36 allocationDepreciationStartDate.value = dayjs(itemInfo.value?.date || new Date()).format("YYYY-MM-DD") diff --git a/frontend/pages/organisation/dokumentenablage.vue b/frontend/pages/organisation/dokumentenablage.vue new file mode 100644 index 00000000..a6e7c0fd --- /dev/null +++ b/frontend/pages/organisation/dokumentenablage.vue @@ -0,0 +1,380 @@ + + + diff --git a/frontend/tests/document-inbox.test.cjs b/frontend/tests/document-inbox.test.cjs new file mode 100644 index 00000000..59ceb6ae --- /dev/null +++ b/frontend/tests/document-inbox.test.cjs @@ -0,0 +1,192 @@ +const { test } = require('node:test') +const assert = require('node:assert/strict') +const fs = require('node:fs') +const vm = require('node:vm') +const vue = require('vue') +const ts = require('../../backend/node_modules/typescript') + +const deferred = () => { + let resolve + const promise = new Promise(done => { resolve = done }) + return { promise, resolve } +} +const settle = () => new Promise(setImmediate) + +function setup(api, apiBase = 'https://fedeo.example/backend') { + const auth = vue.reactive({ activeTenant: '1', user: { is_admin: true } }) + const timers = new Map() + let timerId = 0 + let mount + let unmount + const context = vm.createContext({ + require, exports: {}, URL, + ref: vue.ref, computed: vue.computed, watch: vue.watch, + useAuthStore: () => auth, + useRuntimeConfig: () => ({ public: { apiBase } }), + useFiles: () => ({}), useToast: () => ({ add() {} }), + useNuxtApp: () => ({ $api: api }), + window: { location: { origin: 'https://fedeo.example' } }, + onMounted: handler => { mount = handler }, + onBeforeUnmount: handler => { unmount = handler }, + setTimeout: handler => { timers.set(++timerId, handler); return timerId }, + clearTimeout: id => timers.delete(id), + }) + const source = fs.readFileSync(`${__dirname}/../pages/organisation/dokumentenablage.vue`, 'utf8').match(/