Zum Inhalt springen

MOS Masterplan: Unterschied zwischen den Versionen

Enki (Diskussion | Beiträge)
Keine Bearbeitungszusammenfassung
DanyX (Diskussion | Beiträge)
 
(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 ==