Wuerzelchens blog » Server

Probleme beim installieren von Paketen unter Debian

wuerzelchen — Sun, 11 Dec 2011 01:54:03 +0000

Da nach einem Update mal wieder Probleme aufgetreten sind, musste ich den die Probleme erstmal beheben, die durch das Halb-Konfigurierte Paket entstanden sind. Leider wollte der sich nicht so einfach entfernen lassen:

Setting up courier-authdaemon (0.61.0-1+lenny1) ...
Starting Courier authentication services: authdaemond/usr/sbin/authdaemond: line 16: /etc/courier/authdaemonrc: No such file or directory
invoke-rc.d: initscript courier-authdaemon, action "start" failed.
dpkg: error processing courier-authdaemon (--configure):
subprocess post-installation script returned error exit status 1
Errors were encountered while processing:
courier-authdaemon
E: Sub-process /usr/bin/dpkg returned an error code (1)

Da ich das Paket weder entfernen noch installieren konnte, musste ich dann zur härteren Mitteln greifen und konnte den Fehler mit einem

dpkg --force-remove-reinstreq -P courier-authdaemon

beheben.

Nun konnte ich dann endlich das php5-curl Paket installieren das mir entfernt wurde, aber für Magento benötigt wird.

Aptitude package list flags

wuerzelchen — Sat, 10 Dec 2011 23:27:01 +0000

Wer schon mal nach Paketen mit Aptitude gearbeitet hat, weiss dass dort am Anfang Buchstaben stehen die einem sagen sollen wie der aktuelle Status des Pakets ist, oder was mit dem Paket gemacht wird.

Hier ist eine Liste, die die einzelnen Bedeutungen dieser Buchstaben auflistet:

Erster Buchstabe (common state)
i	Das Paket ist installiert und alle zugehoerigen Pakete sind in Ordnung.
c	Das Paket wurde entfernt, aber die Konfigurationsdateien sind immer noch vorhanden.
p	Das Paket und alle Konfigurationsdateien sind entfernt worden, oder das Paket wurde niemals installiert.
v	Das Paket ist Virtuell.
B	Das Paket hat kaputte Abhängigkeiten.
u	Das Paket wurde entpackt aber noch nicht Konfiguriert.
C	Halb-Konfiguriert: Die Konfiguration des Paketes wurde unterbrochen.
H	Halb-Installiert: Die Installation des Paketes wurde unterbrochen.

Zweiter Buchstabe (action)
i	Das Paket wird installiert.
u	Das Paket wird geupgraded.
d	Das Paket wird Gelöscht: Es wird entfernt, aber die Konfigurationsdateien werden auf dem System bleiben.
p	Das Paket wird Eleminiert: Das Paket und seine Konfigurationsdateien werden entfernt.
h	Das Paket wird zurück gehalten: Es wird auf der aktuellen Version gehalten, selbst wenn eine neuere Version verfügbar wird, solange bis der Halt abgebrochen wird.
F	Ein Upgrade des Pakets wurde verboten.
r	Das Paket wird neu installiert.
B	Das Paket ist “kaputt“: Einige der Abhängigkeiten sind nicht in Ordnung. aptitude wird es nicht erlauben zu installieren, entfernen, oder upgraden solange kaputte Pakete vorhanden sind.

Dritter Buchstaben
A	Das Paket wurde automatisch installiert

Quelle

Mehrere FTP Services auf einem IIS 7

wuerzelchen — Tue, 08 Nov 2011 08:08:28 +0000

Es ist sehr verwirrend wenn man aus der Linux Welt kommt und es nicht kennt wie es auf dem IIS ablaeuft.
Wenn man versucht Subdomains, oder generell mehrere FTP Server am laufen zu haben, neben seinen Apps, dann hat man, bzw. ich hatte, gewisse Probleme auf den Service zu zugreifen. Das lag einzig und alleine daran dass wenn ich unterschiedliche Domains habe meine Usernamen dementsprechend auch unterschiedlich sind. Die sind dann naemlich nicht nur der Username sondern noch die Domain, gefolgt von dem Usernamen.
In dem Format:

domain|username

In einem Beispiel mit der Domain www.example.com und dem User ftpuser waere das dann dementsprechend so:

www.example.com|ftpuser

Dienst startet nach Neustart des Servers nicht mehr

wuerzelchen — Sat, 06 Jun 2009 03:41:41 +0000

Wie kann man herausfinden warum ein Dienst nach einem Neustart des Servers nicht mehr funktioniert?

Eigentlich ganz simpel, wenn man weiss wie es geht.

Um zu analysieren warum der Dienst nicht gestartet hat, ganz stumpf erst einmal den Dienst so versuchen zu starten.

/etc/init.d/<dienst> start

Falls der Dienst sich starten lässt weiss man dass es nicht an dem Dienst selber liegt.

Wenn er fehlermeldungen ausgeben sollte dann erst einmal den Fehlern der Fehlermeldungen auf den Grund gehen. Die meisten Logdateien findet ihr in:

/var/log/

Nun geht man noch eine stufe niedriger und schaut sich die Logfiles vom boot an. Keine bootlogs vorhanden? Unter Debian müsst ihr einfach in

/etc/default/bootlogd

BOOTLOGD_ENABLE=NO

auf YES setzen.

Nun könt ihr rebooten und schaut euch danach die Logdatei an.

cat /var/log/boot | grep -B 5 error

Dort solltet ihr nun ein paar Einträge eures fehlerhaften Dienstes sehen welches den Bootvorgang abbrechen lässt.

Da ihr jetzt eventuell wisst welcher Dienst fehler bereitet schmeissen wir den Dienst aus dem Runlevel raus indem wir folgendes in die Console eingeben:

update-rc.d -f remove

Jetzt startet ihr noch einmal euern Server neu und schaut euch an ob euer gewüschter Dienst gestartet ist. Falls nicht dann könnt ihr wieder in die boot log schauen und euch die nächste Fehlermeldung vorknöpfen.

Um die einzelnen Dienste dem Runlevel wieder hinzuzufügen gebt ihr folgendes ein:

sudo update-rc.d <dienst> defaults

Wenn ihr dann den Dienst gefunden habt welcher euren ganzen Bootvorgang durcheinander bringt könnt ihr euch bei diesem selbst auf Fehlersuche begeben. Wenn er dann einwandfrei läft könnt ihr diesen wieder dem Runlevel hinzufügen.