Installiere phpmyadmin niemals aus den debian-Quellen

So sehr ich mich auch in der letzten Zeit mit debian angefreundet habe, einige Dinge gehen einfach gar nicht. Jedenfalls in meinen Augen. nach einigen vergeblichen Versuchen, phpmyadmin in meine Server und Seitenstruktur so einzugliedern, wie ich es wollte und nicht mehr durch die verschiedensten Sicherheitsmechanismen meines Servers ausgebremst zu werden, habe ich aufgegeben. Pakete für beliebige Webanwendungen, meine Anforderungen und das was die Jungens bei Debian packen hat als Schnittmenge undgefähr eine leere Menge.

Aber man ist ja nicht sklavisch an die Pakete von debian gebunden. Oftmals funktonieren die von den Projekten zur Verfügung gestellten Quellen besser, sind mit Hirn vorkonfiguriert und passen genau damit nicht in das debian-Konzept, was (aus wohlgemerkt nachvollziehbaren Gründen) Projekte verstümmelt und verkrüppelt. Da wir aber hier über Linux reden, muss man sich dem ja nicht anschließen und laut bravo rufen. Im folgenden die Lösung meines speziellen Problems:

apt-get purge phpmyadmin

Dann legen wir einen Pfad an, in dem wir unseren Code wirklich haben wollen:

su -l 
mkdir 
cd 
git clone git://phpmyadmin.git.sourceforge.net/gitroot/phpmyadmin/phpmyadmin .

Installiere niemals MySQL aus den debian-Paketquellen…

… es sei denn, Du hast zuviel Zeit zu verschenken. Ich habe es in diesem Blog noch nicht gesondert bemerkt, ich bin auf keinen Fall ein großer Fan von Oracle, nach dem HickHack um Apache und Java noch viel weniger. Die einzigen Sachen, die mich an Oracle binden, sind Java und MySQL.

Seit heute ist dann eine Abhängikeit weniger da. Der Percona-Server hat das Parket betreten.
Continue reading “Installiere niemals MySQL aus den debian-Paketquellen…”

Dinge, die man niemals tut: iMSCP deinstallieren ohne Datensicherung

Der Titel sagt eigentlich alles – man soll es nicht tun. Musste aber sein, da ich zur Zeit der Installation nicht absehen konnte, dass ein kompletter Rewrite anstehet. Und mit Pre-Alpha wollte ich nun wirklich nicht bis zum nächten Jahr hosten. So groß ist die Liebe zu iMSCP beim besten Willen nicht.
Continue reading “Dinge, die man niemals tut: iMSCP deinstallieren ohne Datensicherung”

Installiere nie MoinMoin aus dem debian-Repository

… ausser Du willst nur minimale Grundfunktionalitäten von MoinMoin nutzen. In diesem Fall kannst Du aber eine nachvollziehbare Installation voll vergessen.
Der in meinen Augen richtige Weg: Man ziehe sich die aktuelle stable als Tarball, packe den aus und schiebe die Einzelteile an die Stelle, wo man sie wirklich haben möchte.

Der Grund für diese Handlungsweise: Manchmal möchte ich ein wenig spielen, ohne mir gleich fürchterlich ins Knie zu schießen. Dabei helfen mir die debian-Maintainer mit ihren leicht verschrobenen Ideen eines python-Paketes nicht wirklich. Es ist natürlich schick, wenn man eine Installation mit apt-get update und apt-get upgrade einfach mal auf den neuesten stand ziehen kann. Genau das will ich aber nicht. Ich möchte auch garantiert keine gemeinsame Codebasis für mehrere Wikis, wohlmöglich noch für mehrere Kunden auf einem Webserver haben: Der Grund – schrotte ich eine Basis, schrotte ich alle. Das kann so nicht sein.

Abhängig vom Aufwand, den installierten Modulen und eventueller Individualprogrammierung möchte ich ein automatisches Update noch viel weniger. Da hilft dann nur noch Handarbeit. Diese habe ich soeben erfolgreich eingesetzt. Irgendwann am morgigen Tag wird da auch eine Installationsanleitung draus, die man sich in eben jenem Wiki anschauen kann. Zwar nicht vollständig, aber doch funktionierend eingesetzt.

Ein zweiter Grund für die Ablehnung von debian-Paketen im Zusammenhang mit Webprojekten ist die debiantypische Handhabung von Komponenten – Es kann nicht sein, dass der debian-eigene FCKEditor total veraltet ist. Damit kann und will ich nicht arbeiten. Als schlechten Witz empfinde ich auch die Tatsache, dass Standard-Moin-Plugins einfach nicht mitgeliefert werden, da nicht gepackt. (TWikiDraw und AnyWikiDraw) Netterweise findet man in den jeweiligen Pluginverzeichnissen jede Menge ungenutzten Platz und den lapidaren Hinweis, das die Dinger nicht gepackt wären. Danke, das war schon aufgefallen!

Auf die absolut kranke, aber debian-typische Packweise, dass ein Paket wichtige Teile nur über verkettete Verlinkungen errreicht, rege ich mich schon gar nicht mehr auf. Auf jeden Fall habe ich heute wieder einmal gelernt, wie man Pakete nicht packt, wenn das dahinterliegende Programm noch wartbar sein soll. – Ein im Webbereich vielleicht nicht ganz unwichtiges Argument.

“Archlinux funzt”, “Update-war-möglich”, “Alles-!funzt!-noch”

In Zeiten, in denen die allgemeine Unmut über Entwicklungen im IT-Sektor immer lauter wird, gibt es ab und zu auch positive Neuigkeiten ohne wenn und aber. Eine dieser Neuigkeiten, auf die in jedem Fall eingegangen werden muss, ist die Tatsache, dass Archlinux funzt. Und ja, ein Update war möglich.

Diesem Alleinstellungsmerkmal von Archlinux ist es zu schulden, dass jetzt sogar ein eigener Thread zu diesem Thema eingerichtet wurde: Der “Archlinux-funzt“, “Updatete-war-möglich“, “Alles-!funzt!-noch” Thread wurde geboren. Ziel dieses Threads ist definitiv nicht die Weltherrschaft, Platz eins in Google würde schon reichen fürs erste. Den “Archlinux funzt” “Update-war-Möglich” “Alles-!funzt!-noch” Tread erreicht man durch das Klicken auf den untergelegten Link.

Natürlich ist die ganze Sache ein wenig sinnfrei, aber Archlinux funzt halt wirklich, diese Erkenntnis muss der Welt einfach mal so direkt mitgeteilt werden. Aus SEO-Gesichtspunkten ist das auch mal ganz interessant, sich diese Geschichte längerfristig anzuschauen. Wenn ich meine Seo-Bibel richtig gelesen habe, dann sollte die öftere Erwähnung der zu puschenden Begriffe und deren semantische Auszeichnung ein übriges tun. Leider kann man mit CK-Editor nur schreien, aber was sollst: “Archlinux funzt” , ein “Update-war-möglich“, “Alles-!funzt!-noch” kann man also nicht oft genug auch betont verwenden.

Ein oder zwei Crosslinks zu “Archlinux funzt” und “Update-war-möglich”:

 

Partition umziehen ohne Sicherung

Ein weiterer Eintrag zu “Dinge, die man niemals tut”:
Wir ziehen eine Partition um, ohne vorher zu sichern.

mkdir /source /target
mount /dev/vg0/teststand /source
mount/dev/vg0/echtstand /target

Natürlich wurde keine Datensicherung angelegt, man wird abgelenkt und das Unheil nimmt seinen Lauf:

cd /source
rm -rf *

Danach kann man dann direkt weitermachen mit

cd /target
rm -rf *

und in der freien Echtinstallation von Grund auf neu beginnen. Platz ist jetzt genug da und man hatte die Installation schon einmal erfolgreich beendet. Bei dieser Gelegenheit dokumentiert man die neue Installation auch gleich und ist beim nächsten Mal auf der etwas sicheren Seite. So was übt ungeheuer.

Da man aber die Nutzdaten klassisch in einer eigenen Partition verewigt hat, ist dieser Vorgang dann als eine willkommene Form der Systembereinigung zu sehen. Die paar nicht gesicherten und dokumentierten Scripte fallen dann auch nicht mehr wirklich ins Gewicht.

 

Eine neue Kategorie – Dinge die man niemals tut

Man liest immer wieder einmal über Dinge, die man einfach nicht tuen sollte. So was gibt es auch für Linux. Wenn mir wieder mal was auffällt, kommt es hier rein.

Einen ersten Kandidaten habe ich auch schon für diese Kategorie:

Bennenne eine Datei niemals ‘-rf’.

Man soll es kaum glauben, ohne Schutzmassnahmen wird das tatsächlich so aufgelöst, wie geschrieben. Das kann zu mehr oder weniger lustigen Verwicklungen führen, z. B. viel freiem Speicherplatz einer eigentlich vollen Festplatte.