ServiceBSD: Unterschied zwischen den Versionen

Aus C3D2
Zur Navigation springen Zur Suche springen
KKeine Bearbeitungszusammenfassung
Keine Bearbeitungszusammenfassung
Zeile 7: Zeile 7:
* könnte eine Ergänzung zu bestehenden Konzepten sein
* könnte eine Ergänzung zu bestehenden Konzepten sein
** [[FreeNAS]] oder das Framework für das WUI das dort verwenden wird ([https://freenas.github.io/gui/ FreeNAS GUI])
** [[FreeNAS]] oder das Framework für das WUI das dort verwenden wird ([https://freenas.github.io/gui/ FreeNAS GUI])
** [[PC-BSD]] oder das Framework für die GUI das dort verwenden wird ([https://sysadm.us/ sysadm])
** [[TrueOS]] oder das Framework für die GUI das dort verwenden wird ([https://sysadm.us/ sysadm])
* "best practice" (an Konfiguration) soll Standard sein (Über das WUI soll ein Ändern der Konfiguration der einzelnen Dienste möglich sein.)
* "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 so) angestoßen wird.
* Die Dienste sollen einfach nur aktiviert werden müssen, womit dann das Deployment (mit Ansible oder so) angestoßen wird.

Version vom 28. Mai 2017, 11:01 Uhr

ein auf FreeBSD basierendes System, 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 (, um den Server erreichbar zu machen, wie etwa Netzwerkeinstellungen) beziehungsweise üblicher Weise so eingestellt werden kann).
  • 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.
  • könnte eine Ergänzung zu bestehenden Konzepten sein
  • "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 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.)
  • Erweiterungen (für WUI und Deployment) sollen einfach und standardisiert möglich sein.
  • In Anlehnung an das Konzept von FreeNAS 10 könnte das auch mit Instanzen von Docker realisiert werden.

In Anlehnung an bestehende Konzepte:

Marketing

Namensfindung

Eigentlich ist der Name von einem solchen Produkt

Kriterien:

  • nicht unbedingt mit BSD im Namen
    BSD ist - mangels Bekanntheit - irritierend.
    PC-BSD firmte das Betriebssystem (2016) zu TrueOS um. Es hieß, dass die Abkürzung BSD im Namen vermieden werden sollte.
  • 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 ...
  • community operating system
    abgekürzt
    • ComOS
    anders interpretiert
    • communistic(ally) ...
  • service oriented service
    abgekürzt
    • servOS
  • service operating system
    abgekürzt
    • ServiceOS
  • 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

Siehe auch