MOS Masterplan: Unterschied zwischen den Versionen
Enki (Diskussion | Beiträge) |
DanyX (Diskussion | Beiträge) (→Wiki) |
||
(9 dazwischenliegende Versionen von 2 Benutzern werden nicht angezeigt) | |||
Zeile 1: | Zeile 1: | ||
das hier ist komplett unfertig und unvollständig, während ich pizza essen geh | 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. | ||
+ | |||
+ | Hier der Entwurf der in der Sitzung vom 14.7.2006 entstanden ist: [[Media:MetalabOSMasterplanSitzung.pdf]] | ||
+ | |||
+ | Schon getan: | ||
+ | # Kern der Member Datenbank migriert. | ||
+ | # Virtual Mailhosting System installiert. | ||
+ | # Mailman installiert und mit VERP konfiguriert. | ||
+ | # Userverwaltung-Neu, History Management, Polls, und Inventarsystem implementiert. | ||
+ | |||
+ | Die nächsten Schritte sind: | ||
+ | # Virtual Mailhosting System mit MOS Datenbank integrieren. | ||
+ | # Mailman migrieren | ||
+ | # Members Mailingliste auf intern umbenennen, und autosynch zwischen neuer Datenbank und Subscriber Liste reaktivieren. | ||
+ | # Mailaccounts (IMAP, SMTP-Auth) für alle Members anlegen | ||
+ | # Jabber migrieren. | ||
+ | # LDAP installieren / Jabber an MOS Auth koppeln | ||
+ | # Wiki migrieren (vmtl. Mysql dafür installieren) | ||
+ | # Wiki Registration disablen. | ||
+ | # User/Pass Daten in die Wikidb pushen. | ||
+ | # MetaSense migrieren. | ||
+ | # Sicherstellen, dass alle Dienste mit dem gleichen Passwort nur über verschlüsselte Kanäle erreichbar sind. | ||
+ | # Weitere Apps | ||
+ | # Vor Wartungsphase: Config File Revision Control | ||
+ | |||
+ | == Todo == | ||
+ | |||
+ | # Unterschiede zwischen Deployment und Development in eigenen Files Kapseln und inkludieren (settings.py) | ||
+ | # Database Initial Population Scripts | ||
+ | |||
+ | # Member ist kein enum/flag sondern ein ForeignKey | ||
+ | |||
+ | z.B. Member | ||
+ | Banned | ||
+ | usw. | ||
+ | |||
+ | = Naming = | ||
+ | |||
+ | http://things.metalab.at/einding oder http://things.metalab.at/2342 | ||
+ | |||
+ | http://events.metalab.at/Cocktailparty | ||
+ | |||
+ | http://people.metalab.at/DjangoMueller | ||
= Komponenten = | = Komponenten = | ||
Zeile 29: | Zeile 75: | ||
Jedes Event hat eine Anfangs und Endzeit, sowie null oder mehr Räume welche für das Event benötigt werden. | 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. | 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. | Die aktuellen und baldigen Ereignisse werden regelmässig (wenn genug Daten vorhanden sind) via E-Mail announced. | ||
Zeile 40: | Zeile 88: | ||
== Wiki == | == Wiki == | ||
− | Mediawiki. Datenbank und Code wird unverändert belassen (ansonsten unwartbar). Loginfunktionalität wird deaktiviert. | + | Mediawiki. Datenbank und Code wird unverändert belassen (ansonsten unwartbar). Loginfunktionalität wird deaktiviert. Idealerweise kann ein Plugin verwendet werden, das die Userverwaltung über LDAP erlaubt. |
== Mailinglisten == | == Mailinglisten == |
Aktuelle Version vom 16. Juli 2006, 17:55 Uhr
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.
Hier der Entwurf der in der Sitzung vom 14.7.2006 entstanden ist: Media:MetalabOSMasterplanSitzung.pdf
Schon getan:
- Kern der Member Datenbank migriert.
- Virtual Mailhosting System installiert.
- Mailman installiert und mit VERP konfiguriert.
- Userverwaltung-Neu, History Management, Polls, und Inventarsystem implementiert.
Die nächsten Schritte sind:
- Virtual Mailhosting System mit MOS Datenbank integrieren.
- Mailman migrieren
- Members Mailingliste auf intern umbenennen, und autosynch zwischen neuer Datenbank und Subscriber Liste reaktivieren.
- Mailaccounts (IMAP, SMTP-Auth) für alle Members anlegen
- Jabber migrieren.
- LDAP installieren / Jabber an MOS Auth koppeln
- Wiki migrieren (vmtl. Mysql dafür installieren)
- Wiki Registration disablen.
- User/Pass Daten in die Wikidb pushen.
- MetaSense migrieren.
- Sicherstellen, dass alle Dienste mit dem gleichen Passwort nur über verschlüsselte Kanäle erreichbar sind.
- Weitere Apps
- Vor Wartungsphase: Config File Revision Control
Todo
- Unterschiede zwischen Deployment und Development in eigenen Files Kapseln und inkludieren (settings.py)
- Database Initial Population Scripts
- Member ist kein enum/flag sondern ein ForeignKey
z.B. Member Banned usw.
Naming
http://things.metalab.at/einding oder http://things.metalab.at/2342
http://events.metalab.at/Cocktailparty
http://people.metalab.at/DjangoMueller
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. Idealerweise kann ein Plugin verwendet werden, das die Userverwaltung über LDAP erlaubt.
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.