MOS Masterplan: Unterschied zwischen den Versionen

aus Metalab Wiki, dem offenen Zentrum für meta-disziplinäre Magier und technisch-kreative Enthusiasten.
Zur Navigation springenZur Suche springen
 
(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. Neue User werden vom MOS in die mediawiki db gepusht.
+
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:

  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)
  2. Database Initial Population Scripts
  1. 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.