mit folgenen befehlen installiert man das mono plugin für apache (unter ubuntu)
sudo apt-get install libapache2-mod-mono
sudo apt-get install mono-apache-server2
und mittels
sudo a2enmod mod_mono(_ autoload)
aktiviert man den ganzen kram…
aber vorsicht: vorher noch die Datei /etc/apache2/mods-available/mod_mono.conf checken, welche mono version geladen wird, standartmäßig ist das die 1.0…
Ich hab mal wieder (wahnsinniger weise) versucht, meine Datenbanken zu backupen und auf in eine lokale Datenbank einzuspielen.
Naja ich spare die Details mal aus, wenn man aber von einer alten MySQL und phpMyAdmin Version exportiert und in eine neue importiert hilft folgendes dabei, das die umlaute erhalten bleiben.
alle Kommentare wegmachen, besonders den am Anfang, der das charset auf latin1 setzt will…
das create database um „CHARACTER SET=utf8 COLLATE=utf8_bin“ erweitern
ne weitere methode ist im backupfile einfach ein:
SET character_set_client = utf8;
SET character_set_connection = utf8;
dann klappt es auch mit Ö Ä Ü
Ab und zu ist es nützlich ein Script mundtot zu machen
somenoisyscript &>/dev/null
schade, dass das nicht in wirklichkeit geht
Ein Beitrag im Kernel-Bereich bei Linux Weekly News hat mal wieder einen interessanten Aspekt bei der Entwicklung moderner Dateisysteme beleuchtet, welcher nicht im direkten Fokus des Normalusers oder Administrators liegt.
Grundlegend geht es darum, dass der Speicherplatz wesentlich schneller wächst als alles andere. Eine „witzige“ Anekdote die durch diesen Fakt bedingt ist, ist die maximale zu verwaltende Speichergröße bei Ext4. Im aktuellen Ext4-Tree wird eine Blocknummer von 48 Bit genutzt, obwohl 64Bit locker möglich währen. Der Grund ist simpel. Selbst mit 48 Bit kann man 1 PByte verwalten und schon der Check dieser Datenmenge braucht unter aktuellen Bedingungen sehr lange (über 100 Jahre).
Es überrascht mich ein wenig wie deutlich der Autor des LWN-Artikels auf die Fehleranfälligkeit von SSDs hinweißt. Besonders da ich überlege damit meinen Server zu „upgraden“ …
Es ist jedoch interessant zu lesen, wie die Entwickler diesen Problemen versuchen zu begegnen. Ein Dateisystem das auf Wiederherstellung und Reparatur (s)eines defekten Zustandes optimiert ist. Es klingt für mich als Programmierer/(hobby)Administator ein wenig seltsam, dass ein Dateisystem davon ausgeht korrupt zu sein. Jedoch müssen wir uns wohl an diesen Umstand gewöhnen und geeignet darauf reagieren.
ChunkFS geht den Ansatzt, dass Fehler entweder global (totaler Verlust der Festplatte) oder lokal (einzelne Lesefehler) auftreten. Selten gibt es was dazwischen… Fast alle modernen Dateisysteme können mit ersterem nicht umgehen (außer über ein Fallback mittels RAID) und behandeln einen Lokalen defekt, indem sie die ganze Festplatte als „korrupt“ ansehen. Klingt irgendwie nicht sehr sinnig 😉
Chunk FS hingegen teilt „Festplatte“ in viele unabhängige Bereiche, die einzeln und online (im Background) wiederhergestellt werden können. Was freilich nur Sinn macht, wenn die Daten irgendwo redundant abgelegt sind. Noch gibt es keine wirklich praxistaugliches Implementation aber es ist wohl nur noch eine Frage der Zeit.
Wer unter Linux Thunderbird und Opera nutzt und mit letzterem Links in ersterem öffnen will sollte folgendes machen.
Im Thunderbird-Profiel findet sich die prefs.js. Dort einfach folgendes anhängen
user_pref(„network.protocol-handler.app.ftp“, „opera“);
user_pref(„network.protocol-handler.app.http“, „opera“);
user_pref(„network.protocol-handler.app.https“, „opera“);
und schon geht das wie geschmiert….
WordPress bietet seit Version 2.5 eine kleine nette Gallerie die mittels
[gallery]
imagelinks
[gallery]
erzeugt werden kann. Leider bietet diese nicht ganz den Umfang der NextGen-Gallery von Alex Rabe
Sehr zu empfehlen, einfach zu installieren und leicht zu pflegen…
Wie schon im vorherigen Eintrag erwähnt, gibt es einige Haken und Ösen wenn man mittels CIFS einen Samba Share als Homedir mountet.
Ein weiterer Haken tritt auf, wenn die GroupIDs und UserIDs zwischen Server und Clienten nicht matchen.
Wichtig bei zu verstehen bei (fast) allen Netzwerk-FileSystems ist. Der Benutzer mit dem man sich authentifiziert, ist nicht unbedingt der Benutzer mir dem man die „Dateien“ erstellt. Beispiel, der Admin mountet unter UserA einen Share und UserB ist auch angemeldet und greift auf diesen Share (auf der gleichen Maschine) zu. Alle Dateien die jetzt UserB anlegt (sofern er das denn darf) werden mit seiner UserID angelegt…
nun kann man um sowas zu unterbinden, sowohl unter SAMBA(Server) als auch beim CIFS (Client) angeben, dass die Gruppen und UserIDs überschrieben werden sollen.
Das nützt blos nicht immer etwas. Einige Programme scheinen den Weg über die Inodes zu nehmen und „umgehen“ dabei dieses force-mapping. Symptome dieses Umstandes sind Probleme mit fehlenden Schreib/Leserechte obwohl man doch mittels „ls -la“ sichtbar alle rechte hat…
In diesem Fall hilft es das clienseitige mapping abzuschalten (gid und uid Parameter beim mounten) und die GroupIDs und UserIDs dem Server anzugleichen (/etc/group und /etc/passwd anpassen)
Wenn man unter Linux auf die Idee kommt sein HomeDir mittels Samba/CIFS auf einem NAS-Laufwerk abzulegen, ist das prinzipiell gut, es kommt aber unweigerlich zu Schwierigkeiten (oder man kennt den Trick schon…)
Auffälligkeiten sind: OpenOffice und einige andere KDE programme zicken „seltsam“ rum. Starten nicht, lassen sicht nicht ordnungsgemäß beenden oder müssen zwei mal Gestartet werden …
Kandidaten dafür sind: K3B, Amarok, Open Office usw…
All diese Programme schreiben Lockfiles in das .kde/share/ verzeichniss (meist .kde/share/config). Startet man über die Konsole bekommt man nach einiger Zeit Fehlermeldungen der Art „Cannot delete stale lockfile …“
löscht man diese Dateien per Hand, kommt das Programm hoch.
Bei CIFS kann man das Problem recht elegant über den „serverino“-Parameter lösen. Einfach beim mounten diese Parameter mitgeben und schon läuft alles wie geschmiert…