MOS Masterplan

das hier ist komplett unfertig und unvollständig, während ich pizza essen geh

Migrationsplan

Derzeit läuft viel Metalab Infrastruktur auf einem Privatserver, soll aber schrittweise auf den eigenen metalab Server migriert werden.

Schon getan:

1. Kern der Member Datenbank migriert.
2. Virtual Mailhosting System installiert.
3. Mailman installiert und mit VERP konfiguriert.
4. Userverwaltung-Neu, History Management, Polls, und Inventarsystem implementiert.

Die nächsten Schritte sind:

1. Virtual Mailhosting System mit MOS Datenbank integrieren.
2. Mailman migrieren
3. Members Mailingliste auf intern umbenennen, und autosynch zwischen neuer Datenbank und Subscriber Liste reaktivieren.
4. Mailaccounts (IMAP, SMTP-Auth) für alle Members anlegen
5. Jabber migrieren.
6. LDAP installieren / Jabber an MOS Auth koppeln
7. Wiki migrieren (vmtl. Mysql dafür installieren)
8. Wiki Registration disablen.
9. User/Pass Daten in die Wikidb pushen.
10. MetaSense migrieren.
11. Sicherstellen, dass alle Dienste mit dem gleichen Passwort nur über verschlüsselte Kanäle erreichbar sind.
12. Weitere Apps
13. Vor Wartungsphase: Config File Revision Control

Todo

1. Unterschiede zwischen Deployment und Development in eigenen Files Kapseln und inkludieren (settings.py)

Komponenten

Server

mos läuft primär auf http://os.metalab.at/ oder http://mos.metalab.at/ Der zuständige Server madame.metalab.at (ma.metalab.at) befindet sich in einem Hosting Center.

Datenbank

Kern des OS ist eine Postgresql Datenbank. Auf diese Datenbank wird mittels des Django ORM Mappers zugegriffen. Aus Konsistenzgründen befinden sich alle Applikationen die mit der Datenbank interagieren innerhalb des selben Django Projekts, und teilen sich die aktuelle Datenbank-Abstraktionen (models.py) In weiterer Folge können in Zukunft ein LDAP Aufsatz, sowie eine Web-API Zugriff zu der Datenbank ermöglichen.

Benutzerverwaltung

Als Kernablage für Benutzerdaten dient das 'User' Modell aus dem Django Auth Framework. Dort werden Username, Firstname, Lastname, Email-Adresse, sowie zusätzliche Daten wie Passwort, Berechtigungen, und Aktivierungs-Stand des Accounts abgelegt.

Zusatz-Daten werden in einem Profile abgelegt, welches mittels eines ForeignKey an einen User gekoppelt ist. Das Profil selbst enthält darüber hinaus noch Daten zum aktuellen E-Mail Aktivierungstoken, sowie einen ForeignKey Verweis auf die Aktuelle Revision der Daten. Alle Benutzerdaten werden zum aufbewahren einer History, sowie zum Freischalten gewisser Felder in Revisionen abgespeichert.

Benutzerprofile sollten zukünftig über http://people.metalab.at/username erreichbar werden. Welche der Daten öffentlich, welche für Members, und welche nur für Vorstand und Gehilfen einsichtig sein sollen, ist zu definieren.

Inventardatenbank

Das Inventar hält Überblick über Dinge die sich im Metalab befinden (sollten). Die Daten werden derzeit flach in einem 'Thing' Modell abgelegt. Jedes Thing hat einen zugestammten Platz, eine Beschreibung, eine eindeutige ID und einen Kurznamen, Daten zum Besitzstand (geborgt (bis wann?), metalab besitz, ...) sowie ein optionales Foto.

Calendaring System

Jedes Event hat eine Anfangs und Endzeit, sowie null oder mehr Räume welche für das Event benötigt werden. Eventuell kann ein Event auch Inventar benötigen. Desweiteren wird zu jedem Event eine Beschreibung, eine Verantwortliche erfasst.

Fokus auf Ressourcen statt Calendar.

Die aktuellen und baldigen Ereignisse werden regelmässig (wenn genug Daten vorhanden sind) via E-Mail announced. Der Kalendar hat zusätzlich Feeds und kann auf ical/xcal exportieren.

Startseite

Die Startseite des Metalab soll statt wie bisher Selbstbeschreibungstext, vor allem aktuelle Daten anzeigen. Die metalab Hauptseite wird dazu aus dem Wiki auf das MOS verlagert. Dort sollen in Form von Widgets, vor allem aktuelle Termine, Öffnungsstand, Jabber-Online-Listen, Photo-Scroller (Flickr?), Pressespiegel-Scroller, metalab Planet (Feedjack), usw. angezeigt werden. Die Seite soll zeigen wieviel sich im und um das metalab tut, aber Handlungen, statt eigener Worte für uns sprechen lassen. Alle Links von der Startseite gehen aber wieder in das Wiki, oder auf spezielle Seiten der jeweiligen Backend-Software. "Statische" Seiten sollten sich ausschließlich im Wiki befinden.

Jabber-System

ejabberd - datenbank momentan auf mnesia. Migration möglichst auf postgresql und/oder LDAP backend.

Wiki

Mediawiki. Datenbank und Code wird unverändert belassen (ansonsten unwartbar). Loginfunktionalität wird deaktiviert. Neue User werden vom MOS in die mediawiki db gepusht.

Mailinglisten

Mailman. Unterstützt keine Datenbanken. Wird über python code und commandlinetools konfiguriert. Mittels der Python Schnittstelle und cron ist ein in-synch halten mit einer Datenbank nicht besonders aufwändig.

Email Accounts

Datenbankgetriebenes Postgres+Postfix+Dovecot Setup.