Kürzlich hatte ich mal wieder meine Freude mit Windows Vista: Ein auf dem Rechner angemeldeter Hauptbenutzer wollte einen im Netzwerk freigegebenen Drucker hinzufügen. Zuerst lief dabei auch alles normal. Nachdem die Abfrage, ob der Treiber installiert werden soll, bestätigt worden war, kam jedoch die Meldung "Druckerverbindung kann nicht hergestellt werden. Zugriff verweigert". Es gab aber auch keine Möglichkeit, diesen Vorgang mit Administratorrechten zu durchzuführen.
Daher habe ich mich als Administrator angemeldet und es nochmals versucht. Dies hat dann problemlos funktioniert. Als ich den Drucker dann anschließend nochmals als Hauptbenutzer hinzuzufügen versuchte, hat es ebenfalls geklappt.
Dass man als Hauptbenutzer keine Treiber installieren darf, erscheint natürlich logisch und durchaus sinnvoll. Doch warum fragt Vista dann nicht - wie sonst i. d. R. auch - nach den Anmeldedaten eines Administrators? Dies würde das Problem jedenfalls beheben.
Artikel mit Tag Betriebssystem
Browser Bug CheatSheet CSS Design Extension | Plugin Firefox Google GoogleMail HTML Internet Internet Explorer JavaScript Links Nagios Online-Dienst OpenBook openSource Programmierung Software SysAdmin Tool Tutorial Webdesign Buch Linux Mail MySQL Test CMS Debian Feed GoogleReader Hardware Kaspersky Office Outlook PHP RSS Ruhezustand TYPO3 Ubuntu VPN Windows Apache Editor Freeware Fun Netzwerk RegEx SSL Webhosting XML Blog s9y Serendipity Postfix Cisco Gnome KDE Konverter Security Spiel Video XAMPP Registry Installation Remote SATA IPv6 Aktion Internes BGP Exchange internet Juniper mod_rewrite DNS SSH SVN IMAP CSV Trackback Smarty Excel GoogleEarth htaccess Verlosung RewriteRule
Mittwoch, 30. September 2009
Windows Vista: Druckerverbindung kann nicht hergestellt werden
Montag, 20. Juli 2009
Crontab-Dateien sichern und wiederherstellen
Sicher ist es dem einen oder anderen schon einmal passiert: Man hat über crontab -e Cronjobs definiert und möchte an diesen etwas ändern. Nach der Änderung stellt man fest, dass es nicht so funktioniert, und möchte die Änderungen rückgängig machen. Unglücklicherweise hat man aber so viel geändert, dass man nicht mehr genau weiß, wie es davor war.
Aber zum Glück macht man ja regelmäßige Backups des Systems, weshalb die alte Version ja noch nicht ganz verloren sein dürfte. Doch dann stellt sich die Frage, wo die so definierten Cronjobs im Dateisystem abgelegt werden.
Die Antwort hierzu ist jedoch ganz einfach: Im Verzeichnis /var/spool/cron/crontabs/ gibt es für jeden User eine Datei, in der dessen Cronjobs hinterlegt sind. Stellt man die betreffende Datei dann aus dem Backup wieder her, so sind die Cronjobs wieder auf dem Stand vor den Änderungen.
Aber zum Glück macht man ja regelmäßige Backups des Systems, weshalb die alte Version ja noch nicht ganz verloren sein dürfte. Doch dann stellt sich die Frage, wo die so definierten Cronjobs im Dateisystem abgelegt werden.
Die Antwort hierzu ist jedoch ganz einfach: Im Verzeichnis /var/spool/cron/crontabs/ gibt es für jeden User eine Datei, in der dessen Cronjobs hinterlegt sind. Stellt man die betreffende Datei dann aus dem Backup wieder her, so sind die Cronjobs wieder auf dem Stand vor den Änderungen.
Donnerstag, 4. Juni 2009
Standardmäßigen Num-Lock-Status festlegen
Eigentlich bin ich ein Fan des Ziffernblocks auf der Tastatur. Daher ist dieser bei mir standardmäßig immer an (Num-Lock). Doch es gibt auch Fälle, in denen dies nicht gewünscht ist. Ein Beispiel hierfür sind Notebook-Tastaturen. Hier gibt es keinen separaten Ziffernblock, die Ziffern sind stattdessen auf den Buchstabentasten hinterlegt. Ist Num-Lock nun in diesem Fall standardmäßig aktiv, ist dies meist von großem Nachteil, da die Tasten bei Weitem häufiger mit den entsprechenden Buchstaben benötigt werden, als mit den Ziffern.
Artikel vollständig lesen »
Artikel vollständig lesen »
Samstag, 9. Mai 2009
Mehrfach vergebene Partitions-UUID
Unter Ubuntu und anderen Linux-Distributionen werden für die Identifizierung von Festplatten-Partitionen mittlerweile meist so genannte UUIDs verwendet. Da dabei jeder Partition eine (zumindest theoretisch) eindeutige ID zugewiesen wird, vereinfacht dies oft die Arbeit. Dies macht sich insbesondere dann bemerkbar, wenn man Änderungen an der Hardware vornimmt, da UUIDs im Gegensatz zum herkömlichen Bezeichnung (z.B. /dev/sda3) stets gleich bleiben.
Doch so groß der Vorteil von UUIDs ist, so leicht kann es damit auch zu Problemen kommen. Vor einem Upgrade von Ubuntu 8.10 auf 9.04 wollte ich zur Sicherheit meine System-Partition duplizieren. Mittels dd war dies einfach und ohne Probleme möglich. Nach dem Upgrade wurde jedoch plötzlich wieder das alte System gestartet, obwohl diese Partition im Dateisystem nirgendwo gemountet oder im GRUB hinterlegt war. Nach langer Fehlersuche bin ich schließlich darauf gekommen, dass beim Kopieren der Partition auch deren UUID mitkopiert wurde, so dass ich zwei Partitionen mit der gleichen UUID hatte. Das musste natürlich unweigerlich zu Problemen führen.
Lösen lässt sich dies, indem man für eine der beiden Partitionen eine neue UUID vergibt. Dies kann mittels tune2fs folgendermaßen gemacht werden:
Dadurch gibt es die bisher doppelt vergebene UUID nur noch einmal, so dass das bisherige Fehlverhalten nicht mehr auftritt.
Doch so groß der Vorteil von UUIDs ist, so leicht kann es damit auch zu Problemen kommen. Vor einem Upgrade von Ubuntu 8.10 auf 9.04 wollte ich zur Sicherheit meine System-Partition duplizieren. Mittels dd war dies einfach und ohne Probleme möglich. Nach dem Upgrade wurde jedoch plötzlich wieder das alte System gestartet, obwohl diese Partition im Dateisystem nirgendwo gemountet oder im GRUB hinterlegt war. Nach langer Fehlersuche bin ich schließlich darauf gekommen, dass beim Kopieren der Partition auch deren UUID mitkopiert wurde, so dass ich zwei Partitionen mit der gleichen UUID hatte. Das musste natürlich unweigerlich zu Problemen führen.
Lösen lässt sich dies, indem man für eine der beiden Partitionen eine neue UUID vergibt. Dies kann mittels tune2fs folgendermaßen gemacht werden:
tune2fs -U random [Partition]
# Beispiel:
tune2fs -U random /dev/sda3
Dadurch gibt es die bisher doppelt vergebene UUID nur noch einmal, so dass das bisherige Fehlverhalten nicht mehr auftritt.
Samstag, 18. April 2009
Startskripte bequem zu den einzelnen Runlevels hinzufügen
Wenn man auf einem Linux-System beispielsweise ein eigenes Startscript erstellt hat, das beim Systemstart automatisch ausgeführt werden soll, legt man dieses typischerweise unter /etc/init.d/ ab. Allein dadurch wird es natürlich noch nicht automatisch ausgeführt. Dazu muss noch in den entsprechenden Verzeichnissen der verschiedenen Runlevels ein symbolischer Link angelegt werden.
Artikel vollständig lesen »