Diskussion:Squab
Diskussionsseite, die Projektseite findet sich unter http://wiki.pilarkto.org/Projekte:Squab
Generell sehe ich keine Notwendigkeit Backendinfrastruktur festzulegen.
* Es wird ein SMTP-Server zum Mailversand benötigt. Postfix, Exim, nullmailer macht erst mal keinen Unterschied. * Eingehende Mail soll auf Spam/Viren überprüft werden. Mit Postfix und Amavis geht das 'Before Queue'. Amavis kann Spamassassin direkt mit ansteuern. Aber wer weiss schon welches Antispamprogramm und welcher Virenscanner in 2 Jahren gut sind? Eventuell will man auch mehrere in Reihe haben. * Postgres/Ingres oder gar doch MySQL: Das hängt auch sehr davon ab, ob es eine weitgehend passende Groupware schon gibt, die für unsere Zwecke erweiterbar ist.
Bei der Virtualisierung würde ich grundsätzlich auf eine kernelbasierende gehen. Selbst dann, wenn dort schon ein Vollvirtualisierer im Einsatz ist. Dann kommt die kernelbasierende eben drüber. Die Vorteile einer kernelbasierten Virtualisierung/Partitionierung liegen im Bereich 'Verfügbarkeit' vor allem in der Gruppierung von atomar zusammengehörigen Softwarekomponenten/Konfigurationen ohne dabei zusätzliche 'Hardware' konfigurieren zu müssen. Im Falle von Linux VServer können sogar mehrere VServer auch dieselbe IP teilen, sofern verschiedene Dienste genutzt werden. Eine IP-Knappheit lässt sich aber auch mittels iptables/DNAT für die jeweils nach draußen anzubietenden Dienste umgehen. Die verlinkte Seite http://virt.kernelnewbies.org/TechComparison ist bezüglich Linux VServer nicht korrekt. Linux VServer kann alles, was der Kernel kann zzgl. dessen was der Patch noch nachliefert. Insbesondere Ressourcenverteilung ist damit durch 'cgroups' möglich, es besteht kein Nachteil gegenüber LXC/OpenVZ. KVM/Xen können einzelne Instanzen gegenüber anderen priorisieren, allerdings ist der Overhead insbesondere beim Platten-IO so hoch, dass VServer/LXC/OpenVZ mit gut eingestellten Schedulern/cgroups die bessere Alternative sind.
Als zusammengehörig in der Virtualisierung betrachte ich
* Webserver als direktes Frontend * für das Groupwarefrontend * für einen möglichen alternativen Webmailclient * für den Synchronisationsserver, der darf auch eine separate Instanz haben * Postfix/Antispam/Antiviren und Mailstorage (DBmail) * Datenbankserver * 2 wegen Master/Master oder Master/Slave Replikation auf Datenbankebene * Master/Slave ist für Backups intressant * Master/Master wenn die Last sehr hoch wird
Existierende Groupwareprojekte, die eventuell geeignet sind
* EGroupware ** - Oberfläche angegraut ** - Datenbankstruktur gerüchteweise nicht besonders toll ** + bietet die Grundfunktionalität ** + kann SyncML ** + Erfahrungen gibt es damit schon ** + hat ein Applikationskonzept, so dass sich fehlende Teile nachimplementieren lassen, oder existierende durch schönere ersetzen lassen ** - Hauptentwickler entwickelt das System eher als gehostete Applikation weiter, TINE ist ein Fork nach einem Streit der Entwickler * SoGo ** + recht ansprechende Oberfläche ** + bietet die Grundfunktionalität ** + es gibt einen fertigen Connector zu Funambol (Synchronisationsserver) ** + aktiv weiterentwickelt, Beta zu 2.0 kam gerade raus
Lizenzen für Eigenentwicklung
* Open Source sagt noch gar nichts aus * Die Affero General Public License könnte eine gute Lizenz für das Projekt sein * Grundsätzlich ist hier zu unterscheiden ob es Open Source, oder Freie Software sein soll. Da es sich im wesentlichen um einen gehosteten Service handelt, deckt die GPL/LGPL alleine den Fall nicht ab, dass jemand den Source nimmt, Erweiterungen macht, diese als Webservice anbietet ohne dabei die neuen Quellen zu veröffentlichen. Da das Programm ja nicht weitergegeben wird, greifen hier GPL/LGPL und diverse andere Lizenzen zu kurz. Die LGPL macht genau dann Sinn, wenn derartiges Verhalten auch im nicht gehosteten Bereich gewünscht/toleriert wird, also bei tatsächlicher Programmweitergabe.
Alternativ zur Lizenz 'Creative Commons „Namensnennung, nicht kommerziell, Weitergabe unter gleichen Bedingungen“' stehen die von mir geschriebenen Abschnitte unter der GNU Free Documentation License 1.3 oder höher.
_are_ 20:02, 2. Okt. 2011 (CEST)
Zur Lizenz: Hier ein paar grundlegende Informationen zu OpenSource Lizenzen.
Zu Egroupware/SOGo:
* SOGo ** + Outlook ab der 2.0 Version als Client nativ verwendbar (für Kalender und Kontakte, aber basierend auf Samba4 (alpha)) ** + Positive und längere Erfahrungen (mit Version 1.xx) vorhanden ** + Benutzerspezifischen Daten pro Benutzer sicherbar (um nicht die ganze Datenbank zu sichern und zurückspielen zu müssen) ** - Aufgabenverwaltung ** + Domain-Isolation möglich ** + Interner Loadbalancer vorhanden
* Egroupware ** + Benutzerspezifischen Daten pro Benutzer sicherbar (um nicht die ganze Datenbank zu sichern und zurückspielen zu müssen) ** - Hohe Durchdringungen der Objekte notwendig, um Verknüpfungen vollständig zu setzten (Projekte mit Kalender und Tasks mit Ressourcen...) ** - Domain-Isolation nicht möglich
philipp.strobl 18:37, 9. Okt. 2011(CEST)
dbmail vs dovecot
Zunächst die Vorteile der jeweiligen Kandidaten
Darüber hinaus einige Stimmen:
- dbmail/SQL hat das Problem mit sogenannten "SQL injection":
=> Ja
=> Nein
- Performance
Inhalt
| Betreff | Antworten | Zuletzt geändert |
|---|---|---|
| Zusätzliche Spam-Absicherung | 0 | 01:31, 11. Mär. 2013 |
Zusätzliche Spam-Absicherung
Sinnvoll wäre eine zusätzliche individuelle Spamabwehr auf dem Mailstorage .z.B. mit DPSAM.
Konfiguration DSPAM und DBMail:
www.dbmail.org/dokuwiki/doku.php/postfix_-_dspam_-_dbmail http://wiki2.dovecot.org/HowTo/Virtual%2BPostfix%2BDspam%2BDovecot http://dspamwiki.expass.de/Installation/Postfix/RelayClamExchangeWebUiToActiveDirectory
