ServiceBSD
ServiceBSD soll ein auf FreeBSD basierendes System sein, das als Server zum Klicken durch jeden Mensch bedient werden kann, um der eigenen "Community" gängige Dienste anbieten zu können.
- Es soll (über eine Oberfläche) nur noch ergänzt werden müssen was ergänzt werden muss. (Das können beispielsweise Angaben zur Einstellung für die Erreichbarkeit im Netzwerk sein.) Alle individuellen Einstellungen sollen jederzeit eingestellt werden können.
- Die angebotenen Dienste sollen alle üblichen Fälle von Anwendungen (auf einem Server) abdecken.
- Die Anwendungen sollen "von selbst" (vorkonfiguriert) miteinander verbundenen sein.
- Gängige Aufgaben, wie das zentrale Verwalten von Accounts und jeweiligen Verwalten der Berechtigungen oder das Erstellen von Datensicherungen, sollen so einfach wie möglich sein.
- ServiceBSD könnte eine Ergänzung zu bestehenden Konzepten sein
- FreeNAS oder das Framework für das WUI das dort verwenden wird (FreeNAS GUI)
- TrueOS oder das Framework für die GUI das dort verwenden wird (sysadm)
- BSD#CBSD
- Werkzeuge zur Verwaltung von BSD#Jails, wie BSD#pot
- "best practice" (an Konfiguration) soll Standard sein! (Über das WUI soll ein Ändern der Konfiguration der einzelnen Dienste möglich sein.)
- Die Dienste sollen einfach nur aktiviert werden müssen, womit dann das Deployment (mit Ansible (oder SaltStack) oder so) angestoßen wird.
- Das Deployment (soll individuell mit dem Werkzeug (Ansible oder so) frei abänderbar sein.
- Gute Funktionalitäten von FreeBSD (wie Jails, ZFS usw.) sollen möglichst gut genutzt werden.
- Erweiterungen (für WUI und Deployment) sollen einfach und standardisiert möglich sein.
- In Anlehnung an das Konzept von FreeNAS 10 (aka BSD#FreeNAS Corral) könnte das auch mit Instanzen von Docker (oder sowas) realisiert werden.
In Anlehnung an bestehende Konzepte:
- YunoHost (self-hosting accessible to everyone)
- Univention Corporate Server (UCS) (Server software for easy-to-use IT operations)
- fractal cells (an integrated solution)
- BetterCrypto⋅org (focuses on our target group (system administrators))
- Diskussion:ServiceBSD#weitere ähnliche Ansätze
Marketing
Namensfindung
Eigentlich ist der Name von einem solchen Produkt
Kriterien:
- nicht unbedingt mit BSD im Namen
- nicht englischsprachig fokussiert
- Möglichst soll der Name in verschieden Sprachen nahezu ähnlich ausgesprochen werden (können).
Ideen für Namen
- collective operating system
- abgekürzt
- CollOS
- ColOS
- anders interpretiert
- colocation ...
- KolOS
- kollektives ...
- abgekürzt
- community operating system
- abgekürzt
- ComOS
- anders interpretiert
- communistic(ally) ...
- abgekürzt
- service oriented service
- abgekürzt
- servOS
- abgekürzt
- service operating system
- abgekürzt
- ServiceOS
- abgekürzt
- jailing operating system
- abgekürzt
- anders interpretiert
- jailed operating system
- Jos
Wenn es nicht irgendwas mit BSD heißt, so könnte folgendes angefügt werden:
- FreeBSD style
Konzept
- Das Konzept soll für Außenstehende und für Mitwirkende das Ziel verdeutlichen.
- Ferner sollen damit eine Art Anforderungen abgebildet sein.
- Abschottung der Instanzen für einzelne Dienste
Wir kommen aus der Welt von FreeBSD und Vertrauen auf das Prinzip der Abschottung durch Jails und vergleichbaren Lösungen.
- Etwa Zones von Illumos oder auch Jails von Dragonfly BSD sind charmante, aber letztlich weniger gut zum Konzept passende, Alternativen.)
Ein jeder Dienst soll eine eigenständige Instanz erhalten. Alternative eigenständige Lösungen zu einem Dienst sollen auch eine eigenständige Instanz erhalten.
- Es soll beispielsweise für eine jede Art von CMS (etwa MediaWiki vs. Plone) eine eigenständige Jail geben.
- Im Falle einer eigenständigen für Datenbanken solle es für jede Art von Datenbank (etwa mariadb vs. postgresql) eine eigenständige Jail geben.
- Verknüpfen der einzelnen Dienste zur Erfüllung ihrer Funktion
Zentral ist die gemeinsame Verwaltung von Account. (Die eigenständige Registrierung bei einzelnen Diensten ist dabei nicht ausgeschlossen.)
Zentral könnte auch eine gemeinsame Verwaltung der Verteilung an die Dienste sein, etwa durch das Weiterleiten mittels einer Firewall (pf, ipfw, ...) oder Loadbalancing (haproxy, ...)
Wohl selbstverständlich ist das notwendige Zusammenwirken der benötigten Komponenten. Klassischer Weise benötigt ein CMS eine Anbindung zu einer Datenbank und einen Webserver. Aber eben auch die Anbindung an die zentrale Verwaltung von Accounts muss selbstverständlich ermöglicht sein.
- mögliche alternative Kombination von einzelnen Diensten
- postgresql vs. mariadb vs. mysql vs. ...
- nginx vs. apache vs. ...
Es muss selbstverständlich mindestens eine Lösung für die Inbetriebnahme angeboten werden.
Im Übrigen wäre die Überführung von zu einer anderen Variante eine utopische Zielstellung.
- Vielfalt an einzelnen Diensten
Software | Dienst |
---|---|
openldap | Konten |
apache | Webserver |
Dienst | Notwendigkeit |
---|---|
Konten | ja |
Postausgang | ja |
Posteingang | vielleicht |
Postfächer | nein |
Webserver | ja |
Datenbank | ja |
- Erscheinungsbild und Funktionalität der Oberfläche