Auch wenn ich dem "Projekt" damit eigentlich vorgreife, möchte ich gern dazu Stellung nehmen bzw. ein paar Sachen erläutern. Grundsätzlich - und das ist auch auch explizites Ziel des Projektes - sind wir bereit, das Layout (Softwareauswahl, Konfiguration in jedem einzelnen Detail zu diskutieren). Zusätzlich sei noch vorausgeschickt, das alle Admins ehrenamtlich arbeiten, also neben ihren Job oder Studium, das Projekt betreuen. In gewisser Beziehung haben wir das "Erbe" von warcraft3.de angetreten. (btw, ich habe es genossen, die ursprüngliche vB-DB um 800K Threads erleichtert zu haben - nach ein paar Tagen ungläubigen Entsetzens und dem Anflug eines Aufstandes hat man mir das sogar relativ kommentarlos verziehen
- nur ich hätte die DB damals nie von den gamigo-Systemen in der vollen Größe herunter und konvertiert bekommen in vernünftiger Zeit).
Zum Szenario:
Ich bin, wie gesagt, für den technischen Betrieb einer der ältesten deutschen Warcraft3 Clanligen zuständig. Damit einher geht die Tatsache, dass meine "Kunden" in erster Linie Gamer (aka Spieler) sind, die mit ernsthafter IT-Sicherheit und Technik vergleichweise wenig am Hut haben. Das betrifft sowohl die Teilnehmer als auch die "Admins" und Redakteure (redaktionelle Begleitung von Spieltagen), welche den Liga-Betrieb organisatorisch durchziehen.
Rechtlich wird das Projekt durch einen eingetragenen Verein (e.V.) vertreten, der rechtlich und finanziell dafür im Hintergrund gerade steht. Die Einnahmen kommen aus Mitgliedsgebühren und ein bisschen Werbung.
Bisher bestand das Technik-Team aus 2 erfahrenen Leuten - in Zukunft aus 3. Problem war, dass was den eigentlichen Serverbetrieb anging nur einer wirklich einen Plan hatte, weil er es selbst eingerichtet und gewartet hat
Am Ligascript hingegen haben beide Techniker geschraubt.
ich bin also einerseits in der komfortablen Lage, gewisse Dinge diktatorisch festzulegen (Spruch: "Iss' halt so.") andererseits muss ich auf bestimmte Gewohnheiten Rücksicht nehmen, um entsprechende Akzeptanz zu erreichen. Auf Grund des häufigen Wechsels von Leuten im "normalen" Admins-Stab, müssen Standard-Tätigkeiten wie eMail-Postfächer einrichten etc. pp. möglichst einfach und wenig aufwendig zu erledigen sein (quasi halbtrunken im Schlaf).
Daneben laufen auf dem Server noch ein paar private Projekte, wie z.B. mein privates Blog auf Java-Basis (Pebble) sowie Joomla-Seiten (ebenfalls private Sachen/Blogs).
So zu den angesprochenen Punkten ClamAV und SA:
Ich benutze derzeit in Postfix eine vergleichsweise sehr agressive Strategie zur Abwehr von Verbindungen auf den SMTP. Das wäre so mit "normalen" Kunden" nicht möglich, aber wie gesagt, siehe oben ich kann das. Fazit: Ich erledige damit ca. 90% der Spam-Fälle. Das Problem ist, dass wir bestimmte eMail-Adressen exponieren müssen.
Resultat kann sich jeder vorstellen, diese Adressen stehen in fast jeder Spammer-DB. Und aus meiner bisherigen Erfahrung heraus - ich checke ab und zu die Inhalte der Postfächer - sehe ich das ClamAV und insbesondere SA (mit einer ebenfalls recht agressiven Konfig) durchaus ihren Dienst tun.
Fakt ist: im Support-Postfach kommen praktisch seit Monaten und Jahren exakt 0 Spams an und wir haben exakt 0 false positives. Aber die Durchleitung sowie das Ablegen solcher Mails in seperaten Ordnern geben den Admins das Gefühl, dass alles durchkommt und damit nix verloren geht. Auf der anderen Seite sind sie dafür dankbar, dass das Postfach sauber bleibt.
zum Thema FTP:
Atm, setzen wir vsFTP ein und erzwingen sFTP. Den Zugang via WinSCP (SSH) haben wir verworfen aus Sicherheitsgründen, weil wir, das Technik-Team, sehr genau definieren möchten, was User X Y oder Z tut und sieht. Das erschien uns mit vsFTP hinreichend gewährleistet. Außerdem ist halt die Preferenz der Admins und insbesondere der Redakteure, Bilder o.ä., mit Filezilla etc. pp. hochzuladen. Das ist wiederum eine der Anforderungen, die ich erfüllen muss.
zu Postfixadmin und phpMyAdmin:
Ja natürlich geht alles per Shell. Nur unser Datenbank-Konzept für das Ligascript ist schon etwas komplexer. Und es ist für Support-Fälle und sonstige Ungereimtheiten oftmals einfacher, bequem per komfortabler UI nachschauen zu können, ob wir (Script) versagt haben oder ob der Teilnehmer einfach nur was nicht gerafft hat. Selten treten auch Fälle auf, wo wir durchaus händisch reagieren müssen, weil sich der Aufwand, dies via PHP-Script zu realisieren einfach nicht lohnt oder wir dies definitiv nicht wollen (welche der Teilnehmer aus Datenschutzgründen aber maybe durchaus fordern, kann - siehe Ausgangssituation - bevor wir uns auf eine Auseinandersetzung einlassen, erfüllen wir die Wünsche).
Last but not least - sorry für die langatmige Antwort, aber ich denke, das ist notwendig um zu verstehen, warum wir bestimmte Optionen wählen, die professionelle Hoster nie in Betracht ziehen würden. Ich muss den Usern (Admins und Redakteure) eine einfache Möglichkeit zur Verfügung stellen, dass PW zu ändern. Bisher hatten wir dafür Usermin. Nur das Konglomerat aus Webmin + Virtualmin + Usermin möchte ich in Zukunft gern einsparen.
