Innerhalb weniger Tage wurden zwei gravierende Sicherheitslöcher im DokuWiki entdeckt. Andreas Gohr hat sie — wie gewohnt — sofort gefixt und ein Update auf Hotfixed-Lemming (Version 2009-12-25c Release 2010-01-15) sei Euch allen dringend ans Herz gelegt. Bei mir hat es ohne Probleme geklappt, selbst mein Monobook-Template machte diesmal keine Probleme.
So weit, so gut. Nur … ich betreue mehr als 30 DokuWiki-Installationen, die meisten auf gemietetem Webspace. Eine Neu-Installation dauert etwas über zehn Minuten (ohne Backup). Und das ist die dritte Neuinstallation in wenigen Wochen. Erst das Update auf die neue Version am 3. Januar, dann letzte Woche das erste Sicherheitsupdate und jetzt das zweite. Jedesmal bin ich mehr als einen Tag mit den Updates beschäftigt. Ich mache Andreas keinen Vorwurf, aber vielleicht sollte man generell einmal die gesamte Update-Prozedur überdenken. Für mich ist es auf jeden Fall ein weiteres Indiz für die prinzipielle Überlegenheit von Tools, die statische Seiten herausrendern. Die Notwendigkeit von Sicherheits-Updates ist nicht so dringend gegeben. Ich habe (wenn auch aus anderen Gründen) schon einmal mein altes Frontier wieder hervorgekramt.
































Wenn das simple auspacken und rüberbügeln schon zu kompliziert ist… da kann man update technisch nun nix mehr vereinfachen.
Du kannst aber auch einfach mit git den stable branch auschecken. Dann ist ein update nur noch ein git pull.
wenn man shell access hat, ist das drüber bügeln schon okay, aber wenn man nur gemieteten webspace mit ftp-only hat, ist es nicht unbedingt der burner, da muss ich herrn kantel schon recht geben.
wo findet sich ein Anleitung wie das “einfach mit git den stable branch auschecken” einzurichten ist?
klingt praktisch
Rolf, hier: http://www.dokuwiki.org/devel:git#maintaining_a_stable_version_with_git
danke,
werd ich heute noch mit dem ersten Wiki testen
@Andreas: Das simple »rüberbügeln« ist nicht kompliziert, aber es kostet Zeit, wenn man nur einen FTP-Account und keinen Shell-Zugriff hat. Ich muß auf meinem Desktop auspacken und dann per FTP alles runterladen. Und alleine die Sprachdateien brauchen bei mir (mit VDSL rüber zu Strato) etwa 8 Minuten, dabei sind sie mit Sicherheit nicht von dem Sicherheitsloch betroffen. Ich denke daher an ein Delta-Update, das nur die betroffenen Dateien austauscht. Damit wäre mir schon viel geholfen.
Und um meinen Rant zu relativieren: Beim vorletzten Update habe ich tatsächlich nur die betroffene ajax.php ausgetauscht und dann die magische Ziffer hochgezählt. Das ging ruck-zuck, so etwas wünsche ich mir.
Aber vielleicht — und das ist die tieferliegende Idee meines Rants — sind tatsächlich PHP-Anwendungen auf gemietetem Webspace nicht das Gelbe vom Ei.
Und ich schimpfe ja nicht nur auf DokuWiki. Diese mehr als 30 Intallationen sind auf meine Empfehlung hin entstanden. Dazu stehe ich noch heute. Und die betroffenen Wissenschaftler sind durch die Bank auch alle sehr zufrieden damit. Nur … es sind Geisteswissenschaftler mit hohem Support-Bedarf …
30 Installationen zu betreuen hat m.E. nichts mehr mit privatem Vergnügen zu tun. Daher sollte man auf eine professionelle Vorgehensweise switchen und alle Sites auf einem (virtuellen) Server mit gemeinsamer Codebasis verlegen. Da klappts dann auch mit dem Backup
Da bsit du wohl Opfer deiner eigenen guten Leistung und eine zu gut funktioniereden Mundpropaganda geworden
Lutz
Als der Kantel damals mit dem DokuWiki statete habe ich auch einen Versuch mit dem DokuWiki gemacht. Ich habe es dann wieder eingestellt, weil es zu wenige Doku-Wiki Entwickler gab und vermutlich gibt. Das ist für mich langfristig betrachtet ein erhebliches Risiko. Ich hatte das bereits irgendwo hier im Blog in einem Kommentar etwas detaillierter geschildert. Daher bin ich bei WordPress geblieben.
Mir war auch die Layoutanpassung zu aufwendig. Was bei WordPress minimale Codierung bedeutet, war/ist (?) beim DokuWiki mit teilweise sinnlosen Arbeitsschritten zusätzlich verbunden. Da kam bei mir damals echter Ekel hoch.
Wenn ich bei WordPress update, dann mache ich ein diff und lade nur die überarbeiteten Dateien auf einen Testserver hoch. Klappt alles, dann bediene ich den echten Server. Das läuft bei mir mit einem kleinen Script ab, das auch den ftp bedient. Zeitaufwand entsteht bei nur beim diff und der Selektion der Dateien.
Ich weiss, ein git pull ist heute cooler und wer auf das nächste stable.tar.gz wartet ist uncool, aber ich bin lieber uncool. Das erspart mir – glaube ich – Ärger.
Also das mit den Sprachdateien lässt sich ja – entsprechend den Anforderungen – leicht lösen, siehe hier:
http://www.wgv-projects.de/wgv-intrawiki/doku.php?id=hilfe:eigenes
einfach weglassen …
und was ich nicht verstehe: Ich bin ja auch bei Strato und mit Sicherheit nicht so eine hohe Preisklasse wie Du und ich komme über das Terminal schön auf meine Webpräsenz via ssh. Das müsstest Du doch auch schaffen, oder?
Ich bin auf alle Fälle ganz glücklich mit dokuwiki und wenn sogar mein Vater da produktiv seine Münchner Kleinkunstszene eingeben kann, dann will das schon was heißen.
Grüß Dich Jörg,
hast Du noch Aktuelles übers DokuWiki zu berichten? Zusammengefasst ist es für kleine Projekte empfehlenswert, wenn ich das so richtig lese (mal abgesehen von Updateroutinen).
Gibt es Erfahrung mit Migration des DW? An sich sollte es ja heißen verpacken-kopieren-fertig …