Ab und an gibt es in der c't wirklich gute Artikel, die komprimiert und technisch fundiert Wissen vermitteln. Damit ich diese Artikel auch noch später in meiner CD-Sammlung auffinden kann, vermerke ich sie hier.
Prinzipiell ist die Anleitung von Linux-StepByStep sehr brauchbar.
Allerdings musste ich nur mod_ssl nachinstallieren.
Die Punkte 8.2-8.5 ("8.2 Edit or create an OpenSSL template", "8.3. Create a new CA certificate", "8.4. Create a Certificate Signing Request (CSR)", "8.5. Sign the CSR") fielen natürlich weg, weil ich ein CAcert-Zertifikat besitze und den Key schon vorher generiert habe.
Unter Fedora gibt es schon vorgegebene Verzeichnisse für die SSL-Keys (/etc/httpd/conf/ssl.*). Zunächst habe ich die vorgenerierten Keys und Zertifikate (server.key, server.crt) gelöscht und meine eigenen als ssl.key/cacert.key bzw. ssl.crt/cacert.crt gespeichert. Wichtig ist auch, dass die privaten Schlüssel root gehören müssen und auch nur von root gelesen werden dürfen!
Die eigentliche Apache-SSL-Konfiguration geschieht über /etc/httpd/conf.d/ssl.conf. Da ich aber lieber SSL direkt bei meinen virtual hosts konfiguriere, habe ich alle Anweisungen innerhalb von <VirtualHost> ... </VirtualHost> auskommentiert.
Statt dessen habe ich der /etc/httpd/conf/sites-enabled/default folgende Einträge hinzugefügt:
<VirtualHost *:443>
SSLEngine on
LogLevel warn
ErrorLog logs/ssl_error_log
TransferLog logs/ssl_access_log
SSLCertificateFile /etc/httpd/conf/ssl.crt/cacert.crt
SSLCertificateKeyFile /etc/httpd/conf/ssl.key/cacert.key
SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP
SetEnvIf User-Agent ".*MSIE.*" \
SetEnvIf User-Agent ".*MSIE.*" \
nokeepalive ssl-unclean-shutdown \
downgrade-1.0 force-response-1.0
</VirtualHost>
Anschließend noch Apache neu starten und anschließend sollte die Verbindung gesichert sein.
Ab und an hat man ein Zertifikat (z.B. ein Class-3-Zertifikat von CAcert), das nur von einer Zwischenzertifizierungsstelle (Intermediate CA) zertifiziert wurde. Das Zertifikat dieser intermediate CA ist nicht im Browser integriert, jedoch von einer CA signiert, die im Browser enthalten sein sollte. Auf Grund der asymmetrischen Verschlüsselung kann der Browser jedoch trotzdem das Zertifikat verifizieren, wenn er Zugriff auf das Zwischenzertifikat hat.
Daher muss man das Zertifikat der intermediate CA ebenfalls im Apache eintragen. Die folgende virtual host-Definition muss ergänzt werden um den Eintrag:
SSLCACertificateFile /etc/httpd/conf/ssl.crt/intermediate_ca.crt
Anschließend muss natürlich auch der Apache neu gestartet werden und alles sollte im Lot sein.
Sowohl MailScanner als auch Amavis sind Frameworks, um Mails auf einem Mailserver nach Viren und Spam zu durchsuchen. Neben vielen Gemeinsamkeiten (beide in Perl geschrieben, beide sind unter GPL lizensiert), gibt es wie bei allen größeren Programmen auch Unterschiede.
Da ich mir beide Programme inzwischen etwas genauer angesehen und beide auch produktiv einsetze (MailScanner ab 2003, amavisd-new ab Anfang 2006), will ich einen Vergleich wagen, vielleicht hilft es ja dem einen oder anderen.
Vorweg möchte ich aber noch sagen, dass ich mich inzwischen nicht mehr als neutral betrachten kann: Anfang 2006 habe ich begonnen, amavisd-new selbst zu erweitern (größeres Refactoring der Spamscanner-API, ein DSPAM-Plugin, einige Patches sind auch bereits in amavisd-new 2.4 eingeflossen. Ich hätte mir die Zeit für die Patches wohl nicht genommen, wenn ich nicht davon überzeugt gewesen wäre, dass amavisd-new für mich die bessere Lösung darstellt. Einen Lobgesang auf MailScanner sollte also keiner erwarten ;-)
Sowohl MailScanner als auch amavisd-new sind komplett in Perl geschrieben und laufen nur unter Unix-Systemen. Beide kooperieren mit allen gängigen SMTP-Servern und Virenscannern. Für die Spamprüfung wird SpamAssassin als Library eingesetzt (quasi alternative Implementierungen von spamd). Abhängig von bestimmten Regeln (z.B. Empfängeradresse) ist es möglich, mit einer Mail bestimmte Dinge zu tun oder eben nicht (z.B. keine Virenprüfung).
Bezüglich der Code-Qualität unterscheiden sie sich auch nicht viel: Beide Projekte haben viel Spaghetti-Code und häufig schlechte Bezeichner. Amavisd-new hat die längeren Methoden (z.T. über 950 Zeilen, s. Amavis::check_mail()), MailScanner dafür die verworreneren Abhängigkeiten und schlechteren Variablenbezeichnungen.
Zunächst zu MailScanner: Da XAMS eine Anleitung zur Einbindung von MailScanner beinhaltete, habe ich im Jahr 2003 begonnen, MailScanner zu benutzen.
MailScanner basiert darauf, dass eine Instanz des SMTP-Servers die Mail annimmt und erst mal auf der Platte abspeichert, wo MailScanner sie dann holt, bearbeitet und einer anderen Instanz des SMTP-Servers zur weiteren Verarbeitung übergibt.
amavisd-new ist der aktivste und meistgenutzte Fork von AMaViS. amavisd-new ist ein eigenständiger Daemon, der die Mails über SMTP entgegen nimmt (auf Wunsch mit Authentifizierung und TLS-Verschlüsselung) und sie auch wieder über SMTP ausliefert.
!$r ? $var : $r eq 'SCALAR' ? $$var
: $r eq 'ARRAY' ? @$var : $r eq 'HASH' ? %$var : $var;
Vor einigen Jahren war ich gegenüber amavisd-new etwas skeptisch, weil amavisd-new einen SMTP-Mailserver simuliert. Damals nahm ich an, dass Clients sich direkt zu amavisd-new verbinden bzw. dass amavisd-new vor Exim vorgeschaltet wird. Dies ist natürlich problematisch, da weil es immer wieder kaputte Clients gibt und Erfahrungen mit den ganzen Feinheiten und Bugs in den herkömmlichen Mailservern schon existieren. Außerdem müsste in so einem Fall eine möglicherweise komplexe Mailkonfiguration des Mailservers in amavisd-new dupliziert werden. Diese Bedenken sind aber unbegründet, weil eben amavisd-new nur mit dem eigentlichen MTA kommunziert und gegenüber den Clients gar nicht in Erscheinung tritt.
Ab und an ist bin ich gezwungen, CGI-Scripts unter Windows zu schreiben bzw. zu testen, die anschließend auf einem Unix-Server laufen sollen. Einziges Problem dabei: Die Shebang-Zeile am Anfang jedes Scripts.
Unter Unix verwendet man z.B. für Perl-Scripts standardmäßig #!/usr/bin/perl, für
Windows bräuchte ich aber etwas wie #!c:/programme/perl/bin/perl.exe.
Um diese Zeile nicht in jedem Script ändern zu müssen (fehleranfällig und zeitraubend), gibt es in der Apache-Konfiguration jedoch die Direktive ScriptInterpreterSource registry-strict, wodurch der Apache unter Windows die Shebang-Direktive nicht mehr beachtet, sondern die Registry zu Rate zieht, um herauszufinden, welches Kommando mit dem Dateityp verknüpft ist.
Um aber nicht die entsprechenden Dateitypen auch bei Ausführung des CGI-Scripts mit den Standard-Anwendungen zu öffnen (bei mir z.B. mein bevorzugter Perl-Editor), pfuscht man kurz vorher noch in der Registry herum (Achtung, nicht ganz ungefährlich!):
HKEY_CLASSES\ROOT den Inhalt des Standard-Schlüssels (bei mir z.B. "pl_auto_file". Unterhalb dieses neuen Schlüssels geht es jetzt weiter.
Shell\ExecCGI\Command.
Das funktioniert natürlich auch mit Python-Scripts und beliebigen Datei-Endungen.
Bei allen Webseiten, die automatisch von Scripts generiert werden, sollten Templates verwendet werden. Zu "kleine" Projekte gibt es dabei meiner Erfahrung nach eigentlich nicht. Meist empfiehlt sich auch der Einsatz von erprobten Template-Engines, die einfach bugfrei sind und mehr Features haben, auch wenn es meist sehr einfach ist, sich etwas Eigenes zu schreiben.
Generell kann man zwei Klassen von Template-Engines unterscheiden. Eine interessante Diskussion darüber fand im Juni 2004 in comp.lang.python statt (archiviert durch Google).
Viele weit verbreitete Template-Toolkits ersetzen im Wesentlichen nur Variablen mit speziellen Werten. Die besseren Template-Systeme treffen keine Annahmen über die Struktur der Dokumente und können beliebige Textformate wie z.B. XML, LaTeX u.ä. ausgeben.
Die Template-Systeme definieren eine eigene Meta-Syntax, um Werte an den entsprechenden Stellen einzusetzen. Außerdem gibt es häufig mehr oder weniger ausgefeilte Features, um z.B. über Listen zu iterieren. Zum Teil gibt es Plugin-Mechanismen, um Daten aus verschiedenen Quellen wie Datenbanken darzustellen. Dadurch wird immer mehr Logik wieder zurück in die Templates verlagert.
Insgesamt sind Ersetzungssysteme einfach zu verstehen und sehr beliebt, haben manchmal aber auch die Eigenschaft, die gewünschte Trennung von Markup, Präsentations- und Applikationslogik wieder aufzuweichen.
Beispiele für Ersetzungssysteme:
Sollen nur XML-Dokumente mit DOM-Struktur generiert werden (XHTML etc), bieten sich auch DOM-basierte Systeme an, die meist noch komfortabler zu benutzen sind und das Markup noch klarer vom Rest (Applikations- und Präsentationslogik) trennen.
Soweit ich weiß, sind diese Art von Systemen nicht für beliebige Textdateien geeignet (wie z.B. Konfigurationsdateien). Andererseits sind die Templates völlig frei von jeder Art Präsentationslogik (z.B. Schleifen) und können damit von allen Designern mit ihren Webeditoren bearbeitet werden. Der Ansatz gegenüber den Ersetzungssystemen ist jedoch ein anderer, so dass viele Programmierer umdenken müssen.
Subversion ist ein Versionsverwaltungsprogramm und wird als "Nachfolger" von CVS bezeichnet. Im Unterschied zu CVS legt man aber nicht lokal ein Repository an und greift dann per SSH darauf zu. Es gibt statt dessen mehrere Methoden, wie man remote auf ein Repository zugreifen kann, inbesondere geht das über ein spezielles Apache-Modul, dass WebDAV modifiziert (mod_dav_svn).
Einrichtung eines Subversion Repositories auf einem Server, so dass man sicher mit Eclipse darauf zugreifen kann. Gleichzeitig soll es unterschiedliche User mit unterschiedlichen Rechten geben, die auch eigene Repositories besitzen.
<Location /svn/repos> DAV svn SVNParentPath /var/version-management/subversion # our access control policy AuthzSVNAccessFile /var/version-management/subversion/access_control # try anonymous access first, resort to real # authentication if necessary. Satisfy Any Require valid-user # how to authenticate a user AuthType Basic AuthName "Subversion repository" AuthUserFile /var/version-management/subversion/.htpasswd </Location>
[felix:/] felix = rw
Alle anderen Benutzer haben keinerlei Rechte .
Wenn SElinux auf dem System aktiviert ist, wird Apache nicht auf die Repositories zugreifen können. Dies äußert sich in Fehlermeldungen in error.log und in /var/log/messages bzw. in fehlgeschlagenen Anmeldungen trotz richtigen Passworts. Zunächst muss nämlich der SElinux-Kontext des Repositories korrekt gesetzt werden. Den Kontext kann man mit "ls -lZ <datei>" ansehen. Mit folgendem Befehl wird der Kontext der Dateien auf httpd_sys_content_t gesetzt, so dass Apache auch auf sie zugreifen kann.
chcon --verbose --recursive -t httpd_sys_content_t /var/version-management/subversion/
Damit man nicht Passwörter und möglicherweise geheime Quelltexte unverschlüsselt durch die Gegend schickt, ist Verschlüsselung mit SSL unverzichtbar. In meiner Konfiguration soll jeder unverschlüsselte Zugriff abgelehnt werden. Das geschieht mittels der Option "SSLRequireSSL", so dass die subversion.conf anschließend so aussieht:
<Location /svn/repos> DAV svn SVNParentPath /var/version-management/subversion SSLRequireSSL SSLOptions +StrictRequire # our access control policy AuthzSVNAccessFile /var/version-management/subversion/access_control (...)
Wenn man Webseiten-Inhalte mit copy&paste in ein OpenOffice-Dokument kopiert, wird zwar die Formatierung übernommen, jedoch werden Bilder nur als Referenz gespeichert und nicht direkt eingebettet. Das folgende Python-Script durchsucht eine OpenOffice-Datei und bettet die referenzierten Bilder ein.
Derzeit ist das Script (convert.py) eher ein proof of concept, funktionierte jedoch für meine Zwecke. Das ganze steht unter der GPL-Lizenz.
getmail ist ein Python-Programm, um Mail von externen Servern abzuholen und in eine Mailbox (mbox, Maildir, etc.) zu transportieren. Allerdings möchte ich meine Konfiguration nicht duplizieren müssen, damit zwei verschiedene Tools wissen, wo die entsprechenden Mailboxen liegen. Daher bietet es sich an, die abgeholten Mails durch den ohnehin vorhandenen Mailserver zustellen zu lassen. Bisher ist in getmail nur vorgesehen, ein externes Programm für diesen Zweck zu verwenden. Mit meinem Patch gibt es auch eine "SMTP" destination, so dass die abgeholten Mails direkt per SMTP ausgeliefert werden.
Damit kann man z.B. Mails per POP3 abholen lassen und an einen blöden MS Exchange-Server weiterleiten.
Immer wieder fallen mir Dinge ein, die "man noch mal machen müsste" oder Verbesserungen an existierenden Programmen, gerade im Bereich Linux und Open Source Software. Damit ich das ganze nicht vergesse, dokumentiere ich es hier. Sollte es etwas schon geben, wäre eine entsprechende Nachricht nett. Und vielleicht hat ja jemand mal zu viel Zeit... ;-)
Nachholen der Backups, die ausgefallen sind, weil der director Dienst nicht lief. (Hintergrund: Mein Backuprechner wird nur für Backups angeschaltet, ansonsten würde nur ständig Krach machen, Strom verpulvern und obendrein noch schneller kaputt gehen. Manchmal schalte ich ihn aber 1/2 Stunde zu spät ein o.ä. Dann sollte das Backup schnellstmöglich nachgeholt werden.
Hamster ist ein freier Mail- und Newsserver für Windows. Um einen weiteren Windows-Rechner abzuschießen, würde ich das ganze gerne auf Linux verwenden. Anforderungen:
Papercut (früher www.papercut.org) scheint einer netter Python-Ansatz zu sein, nur leider versteht der sich noch nicht mit upstream-Servern. Und ich würde ungerne auf Google vertrauen, dass sie ihr Newsarchiv immer öffentlich und kostenlos halten werden.
Ich setze Mozilla/Firebird auf verschiedenen Rechnern ein. Ich hätte gern, dass alle Bookmarks automatisch synchron gehalten werden. Optimalerweise würden auch die gespeicherten Passwörter synchronisiert.
Ich hätte gerne ein Bildverwaltungsprogramm, v.a. für Bilder meiner Digitalkamera. Wichtiger als die Möglichkeit, einfach Nachbearbeitungen vorzunehmen, wäre mir, dass ich meine Bilder wiederfinden kann. D.h. Verschlagwortung der Bilder, zusätzliche Kommentare zu Bildern oder Bildgruppen, Organisation in Kategorien und chronologisch ev. auch Integration mit Beagle und das ganze am besten netzwerkfähig (Bilder auf einem Rechner, Abruf auf einem beliebigen anderen).
Am Schönsten wäre es, wenn auch eine Webgalerie schon mit verknüpft wäre, so dass man bestimmte Sammlungen auf Knopfdruck hochladen könnte. Und die Krönung des ganzen: Besucher der Webgalerie sollten dann auch gleich bei einem oder mehreren Fotodiensten die ausgewählten Bilder bestellen können.
Erste Ansätze gibt es mit digikam (nur leider ein KDE-Programm ;-), sehr schön ist auch das Gnome-Projekt F-Spot (hoffen wir, dass Microsoft das Mono-Projekt nicht mit Patentklagen stoppt). Insgesamt hoffnungsvolle Ansätze, aber noch nicht die gewünschte Integration inkl. Verschlagwortung.
Mittels Enigmail können Thunderbird und Mozilla Mail PGP-verschlüsselte Mails speichern. Leider werden diese Mails nicht dauerhaft (im Mailprogramm) entschlüsselt gespeichert (Motto: Mein Rechner ist sicher und wenn jemand reinkommt, habe ich ganz andere Probleme. Das Problem hatten natürlich auch schon andere Leute, aber die Implementation würde wohl einige Eingriffe in Thunderbird selbst erfodern. Immerhin wurde dieses Feature inzwischen in die 1.1 Roadmap aufgenommen.
Anmerkung: Wenn jemand zugriff auf den Rechner hat, könnte er sich vermutlich auch den Schlüssel krallen, wenn der Benutzer unvorsichtig war und diesem kein Passwort zugewiesen hat. Wenn die Daten es den Aufwand Wert währen, könnte man evtl. auch über Bruteforce an das Passwort kommen. -- Benutzer:Ruehrer 23:43, 6. Jun 2007 (CEST)
SubEthaEdit erlaubt es auf vorzügliche Weise, mit mehreren Personen gleichzeitig eine Datei zu bearbeiten - leider nur für den Mac und derzeit nur mit anderen SubEthaEdits. Eigentlich sollte jeder Texteditor in Eclipse diese Funktionalität bieten. Mit dem eclipse communication framework gibt es Ansätze in diese Richtung.
Das Python FTP-Modul ist grauenhaft. Es sollte viel komfortabler sein, directory listings usw. zu bekommen.
Thunderbird und Sunbird sind zwar schöne Programme, noch besser wäre es aber, sie würden eine freie Groupware-Suite einfach unterstützen, so dass die ganzen interessanten Funktionalitäten wie gemeinsame Mailboxen und Kalender sowie eine gemeinsame, ausbaufähige, firmentaugliche Kontaktdatenbank wirklich nutzbar wären. Im Rahmen des Lightning-Projekts wird derzeit daran gearbeitet, aber ohne weitere Entwickler dauert das sicherlich noch einige Jahre.
Thunderbird sollte es einfach erlauben, dass bestimmte Mails und Ordner als msg-/mbox-Dateien oder als Maildir exportiert werden können. Ebenso sollte der Import solcher Mails einfach machbar sein. Auch das Importieren von vcard sollte möglich sein.
Ich hätte gerne einen vernünftigen eBay-Sniper, der es vor allem einfach macht, nach hunderten gleichartiger Produkte (wie z.B. Film-DVDs) zu suchen und auf ausgewählte Produkte dieser Kategorie dann im letzten Moment zu bieten. Insbesondere müssten auch die Versandkosten berücksichtigt werden (automatisches Auslesen und wo das nicht klappt auch manuelle Eingabe). Außerdem wäre mir wichtig, dass der eigentliche Sniper auch auf einem anderen Rechner arbeiten können sollte als die GUI: Wenn z.B. Auktionen irgendwann nachts zu Ende gehen, würde ich ungerne meinen Rechner die ganze Nacht laufen lassen (Lautstärke, Strom). Andererseits habe ich Zugriff auf diverse Linux-Server, die ohnehin ständig laufen müssen. Schön wäre es, wenn der Sniper dort installiert wäre und mein Arbeitsplatzrechner nur zur Konfiguration laufen müsste.
Flash-Werbung wird immer mehr zur Plage. Ebenso nerven Seiten mit unnötigen Java-Applets, deren Start sehr lange dauert. Ich hätte gerne ein Filter-System ähnlich dem für Bilder, mit dem Mozilla Medientypen je nach Domain blockiert und ggf. mit einem Klick anzeigt.
Eigentlich gibt es im X-Server von X.org schon ewig eine sehr, sehr praktische Funktion, nämlich den Session-Support. Grundidee ist, dass man seine X-Session beendet und alle Programme speichern ihren aktuellen Zustand ab, so dass man beim Einloggen exakt an der gleichen Stelle mit den gleichen offenen Fenstern weiterarbeiten kann. Es wäre klasse, wenn alle Programme diese Sessions wirklich unterstützen würden.
Eine Sache, die bei Mozilla noch fehlt, ist ein richtiger Download-Manager, der es erlaubt, Downloads zu unterbrechen und zu einem späteren Zeitpunkt (z.B. nach einem Neustart des Systems) wiederaufzunehmen. Nice to have wäre z.B. auch die Möglichkeit, von mehreren Quellen gleichzeitig herunterzuladen.
Das gibts mehr oder weniger schon. ;-) FileZilla und andere können mit der entsprechenden Extension bei einem Download gestartet werden. Hth, Clemens ;-)
: Wenn es aber nicht richtig integriert ist (auf jeder Plattform wieder ein anderes Programm, immer ein anderes Aussehen, muss immer noch mal extra installiert werden), wäre das für mich noch keine echte Lösung. Andererseits habe ich bisher auch kaum "gute" (UI, Bedienbarkeit) Download-Manager gesehen. Immerhin gibt es unter Linux freeloader bzw. gwget. -- Benutzer:Felix 09:38, 31. Jan 2006 (CET), Änderung vom 19:51, 19. Jun 2007 (CEST)
Gerade C-Programme haben das Problem, dass man einige Dinge nur vor dem Kompilieren festlegen kann, wie z.B. die verwendete Datenbank. Das Problem ergibt sich v.a. für Distributoren, die sich dann für eine Datenbank entscheiden müssen. Ich habe häufiger das Problem, dass ich ein Paket brauche, dass aber z.B. bei Fedora nicht mit den gewünschten Optionen verfügbar ist (inbesondere bei Bacula, Exim und Dovecot). Gerade Sachen wie Datenbanken kann man aber selbst in C hervorragend modularisieren und als Plugin implementieren.
Damit kann der Distributor einfach alle Plugins kompilieren und der User kann dann zur Laufzeit konfigurieren, welche Datenbank genutzt werden soll. Verallgemeinert bin ich stark für möglichst viel Konfiguration zur Laufzeit.
Wenn Apache nicht in einer single user Umgebung eingesetzt wird, sondern für virtual hosting (mehrere Webseiten unterschiedlicher Benutzer) und diese Benutzer eigene (CGI-)Scripte ausführen dürfen, gibt es automatisch Sicherheitsprobleme, da die Scripte eigentlich unter der Benutzer-ID des jeweiligen Benutzers laufen müssen (alles andere ist aus sicherheitstechnischer Sicht nicht akzeptabel). Dafür gibt es spezialisierte Tools wie suexec und suPHP, doch die Möglichkeit, Scripte mittels mod_perl oder mod_php zu beschleunigen ist dahin. Außerdem ist die Installation zusätzlicher Software nötig.
Die technische richtige Lösung wäre es, wenn jeder virtual host unter einer konfigurierbaren User-ID ausgeführt werden würde, so dass die suexec/suPHP-Krücken (so gut sie auch programmiert sein mögen) einfach konzeptionell überflüssig werden. Außerdem erhoffe ich mir von dieser Lösung, dass z.B. mod_php auch für einen einzelnen virtual host eingesetzt werden kann.
Der Mangel wurde natürlich auch von anderen erkannt und so gibt es mehrere Projekte, die das Problem angehen:
Alle Lösungen haben gemeinsam, dass sie noch nicht standardmäßig von Apache oder Fedora unterstützt werden...
VNC ist sehr hilfreich, aber die GUI ist steinzeitlich. Vino als Gnome VNC-Server ist da schon ein Meilenstein. Was mir trotzdem fehlt sind: Transparentes Drag'n'Drop und Copy&Paste (bei verschiedenen Betriebssystemen), integrierte Verschlüsselung, Bonjour-Support sowie ein GTK VNC-Client mit den Features Adresshistory/-management, übersichtliche Optionen, Integration in den Gnome-Schlüsselbund.
Mit Bongosurfer gibt es einen funktionierenden Least Cost Router (nicht nur) für ISDN unter Linux. Schön wäre es, wenn die allgemeine Interaktivität (z.B. Anzeige der Wählversuche) erhöht würde und in der Anzeige mehr Usability-Aspekte berücksichtigt wären.
Ich suche einen in Python implementierten Webshop, der mit den Mängeln von osCommerce, xtCommerce etc. einmal gründlich aufräumt. Besonders wichtig wären dabei sehr gute Codequalität, komplette Unit-Test-Abdeckung und die Möglichkeit, Businesslogik zum Shop hinzuzufügen (Rechnung erst ab 3. Bestellung, Versandkosten auf Grund eigener Berechnungsregeln wie z.B. eigenes Produktattribut, ...), so dass diese Logik auch nach einem Update erhalten bleibt (Plugin-Schnittstelle). Eine konsequente Umsetzung würde auch verschiedene Produkttypen mit jeweils anderen Attributen berücksichtigen (z.B. Bücher mit ISBN und Autor und Stahlrohre mit Durchmesser und Material). Eine vielversprechende Umsetzung könnte z.B. mit Django oder TurboGears erfolgen.
WebDAV wurde ursprünglich auch mit der Intention entworfen, dass man Dateien für Webseiten darüber (ohne FTP) hochladen kann. In der Theorie funktioniert das auch alles sehr schön. Die bekannteste Implementierung ist sicherlich mod_dav im Apache-Webserver. mod_dav hat allerdings das Problem, dass alle Operationen mit dem Benutzer-Account des Webservers ausgeführt werden. Entsprechend kann man auch keine CGI-Skripte mit WebDAV hochladen, weil suexec die Ausführung auf Grund des falschen Datei-Eigentümers verweigert.
Ich bräuchte einen DAV-Server, der die Benutzerauthentifikation durchführt und die hochgeladenen Dateien auch mit den richtigen Dateieigentümern (abhängig von der Anmeldung/dem Pfad) versieht.
osCommerce ist ein PHP-basierter Online-Shop, der als Open Source-Software (GPL-Lizenz) entwickelt wird. Bemerkenswert sind die vielen sog. contributions (Erweiterungen), mit denen der Shop an viele Anwendungsgebiete angepasst werden kann. Ein weiterer positiver Aspekt ist die Übersetzung der Software in diverse Sprachen.
Insgesamt kann osCommerce vielen kommerziellen Produkten das Wasser reichen bzw. ist ihnen überlegen, doch lässt insgesamt die Code-Qualität sehr zu wünschen übrig. Nahezu überall wird PHP-Code direkt in das Layout gestreut, ein Template-System wird standardmäßig nicht mitgeliefert (Version 2.2 Milestone 2). Auch wenn Templates für Milestone 3 vorgesehen sind, wollen die Entwickler nach eigener Aussage kein etabliertes System (wie z.B. Smarty) verwenden.
Es gibt (mit Ausnahmen weniger kleiner Teilbereiche) keine Plugin-Schnittstelle, so dass jede Änderung gut getestet werden muss. Sicherheitsaktualisierungen und größere Layout-Anpassungen nur unter großem Auswand durchzuführen und müssen bei jeder neuen Version wiederholt werden.
Problem: Nur bei den kleinsten Shops (<20 Produkte) ist es machbar, Artikel für neue Sonderangebote (specials) über ein einfaches Dropdown-Menü auszuwählen.
Ich habe daher eine minimal-invasive Erweiterung geschrieben, bei der man die Sonderangebote über eine Textsuche auswählt (ähnlich der normalen Suche im Shop). Die Erweiterung steht natürlich unter der GPL-Lizenz. Änderungen/Erweiterungen oder auch Übersetzungen sind jederzeit herzlich willkommen.
Download: select_specials_1.0.6.zip
Hilfe & Diskussion: Bitte eröffnet einen neuen Thread im Benutzerbeiträge-Forum von oscommerce.de und sendet den Link an felix.schwarz@web.de. Bitte keine Fragen per Mail, im Forum haben alle was davon.
osCommerce contribution page: http://www.oscommerce.com/community/contributions,2044
Support-Threads in Foren: Bevor ihr fragt, bitte zuerst diese Threads durchschauen, um Probleme ev. auch schon selbst lösen zu können:
Problem: In osCommerce ist die Möglichkeit vorgesehen, Sonderangebote an einem vorher festgelegten Tag auslaufen zu lassen. Jedoch war es nicht möglich, Sonderangebote schon vorher einzugeben und dann sie dann automatisch an einem bestimmten Tag durch osCommerce freischalten zu lassen.
Mit dieser Erweiterung (GPL-Lizenz) ist es z.B. möglich, alle Sonderangebote des kommenden Monats in Ruhe einzugeben und dann automatisch freischalten zu lassen. Allerdings sind dafür kleine Datenbank-Änderungen nötig. Änderungen/Erweiterungen oder auch Übersetzungen sind jederzeit herzlich willkommen.
Download: specials_valid_from_1.0.3.zip
Hilfe & Diskussion: Bitte eröffnet einen neuen Thread im Benutzerbeiträge-Forum von oscommerce.de und sendet den Link an felix.schwarz@web.de. Bitte keine Fragen per Mail, im Forum haben alle was davon.
osCommerce contribution page: http://www.oscommerce.com/community/contributions,2520
Support-Threads in Foren: Bevor ihr fragt, bitte zuerst diese Threads durchschauen, um Probleme ev. auch schon selbst lösen zu können:
Das MediaWiki ist eine sehr leistungsfähige Wiki-Software, die insbesondere von der Wikipedia eingesetzt wird und sehr leistungsfähig ist. Ich finde, es ist eines der wenigen Wikis, wo der Text wirklich lesbar ist und man sich darauf freut, etwas zu lesen.
Leider hat der standardmäßige Monobook-Skin (sieht wirklich gut aus, finde ich :-) ein paar Macken, die ich ausgebessert habe:
Standardmäßig werden oben in der Benutzerleiste ('Anmelden', 'Einstellungen', ...) und der Optionsleiste ('Artikel', 'Diskussion', ...) alle Einträge klein geschrieben. Grund dafür sind zwei css-Anweisungen in der main.css (Verzeichnis skins/monobook). Ein Patch behebt das Problem (einzuspielen im Verzeichnis, wo die main.css liegt, also z.B. /skins/monobook) mit <code>patch -p0 < kleinschreibung-1.5.patch</code>.
Das Navigationsmenü links oben enthält viele Einträge, die zwar für die Wikipedia interessant sind, doch ansonsten eigentlich nur stören.
Das Menü kann direkt mit Wiki-eigenen Mitteln geändert werden: Als Wiki-Operator kann man die Seite /MediaWiki:Sidebar nach den eigenen Wünschen anpassen. Mehr Informationen zu diesem Thema gibt es im Wikimedia Meta-Wiki.
In den älteren MediaWiki-Versionen kann die Navigationsleiste nur über die LocalSettings.php geändert werden. Im Beispiel unten gibt es dann nur noch die Einträge 'Hauptseite' und 'Letzte Änderungen':
$wgNavigationLinks = array (
array( 'text'=>'mainpage', 'href'=>'mainpage' ),
array( 'text'=>'recentchanges', 'href'=>'recentchanges-url' ),
);
Zunächst müssen Backups gemacht werden. Neben der eigentlichen Datenbank sollten auch die Dateien des Mediawikis gesichert werden, da dort z.B. auch die ins Wiki importierten Bilder liegen!
Von Version 1.4 zu 1.5 haben sich die Datenbankstrukturen geändert, daher ist diesmal etwas mehr Arbeit erforderlich. Für deutsche Wikis sollte auch beachtet werden, dass die Kodierung von Text in der Datenbank von Latin-1 (ISO-8859-1) zu UTF-8 ("Unicode") geändert wurde, was zu zusätzlichen Fehlern führen kann.
Nach dem Entpacken der neuen Mediawiki-Dateien sollte dort noch eine AdminSettings.php angelegt werden, die etwa so aussehen muss:
<?php
$wgDBname = "mediawikidb";
$wgDBadminuser = "mysqluser";
$wgDBadminpassword = "password";
?>
Im Verzeichnis 'maintenance' werden dann die beiden Scripts ausgeführt:
php upgrade1_5.php php update.php
Jetzt ist die Datenbank im neuen Format und das Mediawiki auf Version 1.5.
Ohne besondere Vorkehrungen sehen Mediawiki-URLs etwa so aus: "/index.php?title=Hauptseite". Das ist natürlich unschön, eigentlich will ich eher etwas wie "/Hauptseite" haben. Dazu gibt es einige rewrite-Rules, die genau das machen. Leider müssen diese Regeln in der VirtualHost-Sektion stehen, nur mit .htaccess-Dateien habe ich es nicht hinbekommen.
# rules for well-behaving bots and normal browser:
RewriteCond %{REQUEST_URI} !^/files/
# Don't rewrite requests for files in MediaWiki subdirectories,
# MediaWiki PHP files, HTTP error documents, favicon.ico, or robots.txt
RewriteCond %{REQUEST_URI} !^/(images|skins)/
RewriteCond %{REQUEST_URI} !^/(redirect|texvc|index).php
RewriteCond %{REQUEST_URI} !^/error/(40(1|3|4)|500).html
RewriteCond %{REQUEST_URI} !^/favicon.ico
RewriteCond %{REQUEST_URI} !^/robots.txt
RewriteRule ^/(.*)$ /index.php?title=$1 [L,QSA]
Zur Erklärung: Es gibt bei mir ein zusätzliches Verzeichnis /files, in dem ich statische Dateien aufbewahre. Für dieses Verzeichnis soll sich Mediawiki nicht zuständig fühlen, weswegen auch URLs, die mit /files beginnen, nicht umgeschrieben werden.
In meinem Mediawiki gibt es "Seiten", die eigentlich nicht in einer Suchmaschine auftauchen sollten, z.B. verschiedene Vorlagen wie '/Mediawiki:Uploadtext' oder alte Versionen von Artikeln. Leider werden auch solche Seiten von Google und Co. durchsucht und gespeichert.
Um das zu verhindern, gibt es eigentlich die Datei robots.txt, in der folgendes stehen könnte:
User-agent: * Disallow: /Spezial: Disallow: /Mediawiki: Disallow: /MediaWiki: Disallow: /index.php
Leider ignorieren Google und Co. die robots.txt oder genauer gesagt: Sie halten sich sehr buchstabengetreu an den entspr. Standard. Das bedeutet, dass sie URLs, die in der robots.txt genannt werden, zwar besuchen, deren Inhalte aber nicht zwischenspeichern. Im Suchresultat taucht dann nur die URL (ohne weiteren Inhalt) auf.
Da die Suchmaschinen aber eigentlich kooperativ sind, geben sie sich zuverlässig im UserAgent-String zu erkennen. Entsprechend setze ich einige zusätzliche Rewrite-Rules ein, um Suchmaschinen außen vor zu halten. Diese Regeln müssen vor den Regeln für schöne URLs platziert werden!
# forbid bots to spider pages with certain urls that are forbidden in
# robots.txt anyway.
RewriteCond %{HTTP_USER_AGENT} .*Yahoo\!\sSlurp.*|.*Googlebot.*|.*msnbot.*
RewriteRule ^/index.php?.*$ /Hauptseite [L,QSA,gone]
RewriteCond %{HTTP_USER_AGENT} .*Yahoo\!\sSlurp.*|.*Googlebot.*|.*msnbot.*
RewriteRule ^/(MediaWiki|Mediawiki|Spezial):.*?.*$ /Hauptseite [L,QSA,gone]
RewriteCond %{HTTP_USER_AGENT} .*Yahoo\!\sSlurp.*|.*Googlebot.*|.*msnbot.*
RewriteCond %{QUERY_STRING} !^$
RewriteRule ^/?$ /Hauptseite [L,QSA,gone]
Alle "Besucher", deren UserAgent "Yahoo! Slurp", "Googlebot" oder "msnbot" enthält, bekommen bei bestimmten Seiten ('index.php?...', '/Spezial...', '/MediaWiki...' oder überhaupt ein nicht-leerer Query-String die Fehlermeldung "409 gone", so dass die entspr. Seiten nicht mehr in der Suchmaschine auftauchen. Allerdings wird es einige Zeit dauern, damit einmal aufgenommene Einträge aus dem Index gelöscht werden (mehrere Monate).
Wenn man nachträglich die Lizenz seines Wikis ändern will, geht das technisch gesehen verhältnismäßig einfach: In der LocalSettings.php die folgenden Einträge ändern:
$wgRightsUrl = "http://creativecommons.org/licenses/by-sa/2.0/de/";
$wgRightsText = "Creative Commons Attribution-ShareAlike 2.0 Germany License";
$wgRightsIcon = "${wgStylePath}/common/images/somerights20.png";
# $wgRightsCode = "by-sa"; # Not yet used
Allerdings sollte beachtet werden, ob die alte Lizenz rechtlich zur neuen kompatibel ist. Wenn nicht, müssen theoretisch alle Autoren ihr Einverständnis zur Lizenzänderung geben!
Mit der Cite.php-Extension kann man Fußnoten in Texten verwenden. Der Name kommt wohl vom Chicago-Zitierstil, der mit Fußnoten arbeitet.
Im MediaWiki gibt es eine Seite, die sich mit kleineren Layout-Anpassungen beschäftigt.