Administration – Linux und Ich

Dateien/Ordner in Nautilus aka Files mit Root-Rechten bearbeiten

Christoph Langner — Mon, 20 Feb 2017 21:34:16 +0000

Eine der Stärken von Linux liegt in allgemeinem daran, dass das System seit Urzeiten als Mehrbenutzersystem konzipiert ist. User starten Anwendungen im Rahmen ihrer Benutzerrechte, sodass diese in der Regel nichts am System ändern können. Malware beeinträchtigt somit höchstens den Datenbestand des Users, der diese ausführt. Dennoch machen wir Linuxer immer wieder gerne ein Türchen auf: Sobald wir beispielsweise einen Editor mit Root-Rechten starten, etwa um eine Konfigurationsdatei zu bearbeiten, führen wir diesen mitsamt dem kompletten Toolkit (also GTK oder Qt) mit administrativen Rechten aus. Dadurch läuft mehr Code mit administrativen Rechten, als eigentlich nötig, daran ändert auch der Aufruf des Programms mit gksu oder gksudo nichts.

Sudoedit, das bessere sudo $editor

Das gilt nicht nur in einer grafischen Desktopumgebung, sondern auch für Editoren im Terminal. Wir rufen üblicherweise nano, vi, emacs und Co. mittels sudo nano /was/auch/immer komplett mit Root-Rechten auf. Dadurch müssen wir darauf vertrauen, dass sich der Editor nicht auf irgendeine Art und Weise missbrauchen lässt. Wenn man bedenkt, welche Funktionsfülle Vi oder Emacs mitbringen, birgt das Vorgehen durchaus ein Gefahrenpotential. Daher gibt es bereits seit 2004 mit sudoedit bzw. sudo -e ein Kommando, das dieses Problem umschifft.

$ sudo -e /etc/hosts
$ sudoedit /etc/hosts

Dabei kopiert Sudo die zu bearbeitende Datei erst einmal in ein temporäres Verzeichnis (unter Arch Linux nach /var/tmp), öffnet die Kopie dann im Kontext des Benutzers in den Editor und schiebt die temporäre Datei dann nach dem Schließen des Editors wieder an die ursprüngliche Stelle. Auf diesem Weg muss man den Editor selbst und damit alle mit angezogenen Bibliotheken nicht mehr mit Root-Rechten ausführen. Nur für das Kopieren der Dateien braucht es die administrativen Rechten.

$ VISUAL=gedit sudoedit /etc/hosts
$ EDITOR=nano sudoedit /etc/hosts

Mit den Umgebungsvariablen $VISUAL und $EDITOR lässt sich dem Kommando der gewünschte Editor mit auf den Weg geben, wobei $EDITOR für einen einfachen Editor wie etwa Nano oder Joe steht und $VISUAL mit einem Brocken wie Emacs oder Vi (oder grafischen Editoren wie Gedit oder Kate) belegt werden sollte — Sind beide Variablen definiert, zieht Sudo $VISUAL dem einfachen $EDITOR vor. Ich definiere „meine“ Editoren daher in der ~/.bashrc (den einfachen Editor) sowie in der ~/.xprofile (mit Gedit einen Editor in der GUI). Somit muss ich dann zum Bearbeiten einer Systemdatei nur noch sudoedit /foo/bar eingeben und öffne die Datei dann automatisch im „passenden“ Editor.

### Die Umgebungsvariablen $EDITOR und $Visual kann man beispielsweise
### über die ~/.bashrc oder 
$ grep EDITOR ~/.bashrc
export EDITOR=/usr/bin/joe
$ grep VISUAL ~/.xprofile
export VISUAL=/usr/bin/gedit
### Je nachdem ob man sich in einer grafischen Umgebung befindet, oder
### in einem virtuellen Terminal, startet sudoedit den Terminal-Editor
### Joe oder Gedit.
$ sudoedit /etc/hosts

Sudoedit gibt es nun schon seit 2004, aber kaum jemand nutzt diese Methode: Das Wiki der Ubuntuusers erwähnt das Kommando zum Beispiel mit keinem einzigen Wort und auch im Arch Wiki findet sich Sudoedit nur auf einer einzigen Unterseite — Damit ignorieren die in meinen Augen zwei besten Dokumentationen rund um Linux Sudoedit bisher fast komplett. In Sachen Root-Rechte in der grafischen Desktopumgebung hat mich allerdings ein aktueller Blogbeitrag von KDE-Entwickler Martin Grässlin auf etwas neues gebracht: Der Files-Dateimanager (aka Nautilus) beherrscht seit der Version 3.22 dank einer Neuerung in Gvfs (dem Gnome virtual file system) einen Administrator-Modus, der ähnlich wie Sudoeditor funktioniert.

Der mit sudoedit gestartete Gedit-Editor arbeitet ohne Root-Rechte.

Root-Rechte für Files aka Nautilus

Im Gnome-Dateimanager kann man ja mit [Strg]+[L] eine Adresszeile öffnen, über die sich Pfade eintippen lassen oder über die man durch Eingabe von smb://server/freigabe oder ssh://username@example.com Daten von entfernten Rechner direkt in den Dateimanger einbinden kann. Mithilfe von aktuellen Entwicklungen in Gvfs-admin und Polit gibt es nun aber auch eine Art Admin-Modus, diesen erreicht ihr über die Eingabe von admin:///pfad/zu/verzeichnis oder einfach nur admin:// ohne eine Pfadangabe. Über eine Maske fordert der Dateimanager danach eure Root-Rechte an und leitet euch entweder in das Wurzelverzeichnis des Systems oder den angegebenen Ordner weiter.

Durch Eingabe von admin:// kommt man in den Administrations-Modus.

Für die Root-Rechte benötigt man natürlich auch administrative Rechte

In diesem Modus könnt ihr beispielsweise nach /etc navigieren und dann die Hosts-Datei /etc/hosts in Gedit öffnen, bearbeiten und wieder abspeichern (mit abermaligen Eingabe eures Passworts). Dasselbe funktioniert mit allen anderen Konfigurationsdateien, die man mal schnell an die eigenen Wünsche anpassen möchte. Ihr könnt auch Verzeichnisse oder Dateien in geschützten Ordnern wie /, /etc oder /usr/local/bin anlegen, diese dann verschieben, wieder löschen oder die Benutzerrechte ändern. Sinnlos walten und schalten lässt euch Files jedoch in der Regel nicht: Dateien und Ordner, die dem Root-User gehören, die User der Root-Gruppe aber nur lesen und/oder ausführen dürfen (also Dateien und Ordner mit der Zuordnung root:root und den Rechten 644 oder 755) erscheinen mit einem Schloss-Symbol. Diese lassen sich dann beispielsweise nicht löschen oder ausschneiden.

Das Schloss-Symbol kennzeichnet besonders geschützte Ordner und Dateien.

Aus dem Dateimanager lassen sich dann geschützte Dateien bearbeiten.

Und natürlich auch in einem Texteditor mit Root-Rechten bearbeiten.

In Sachen Root-Rechte in KDE wird sich demnächst einiges ändern: Martin hat in seinem Posting angekündigt, dass die KDE-Editoren Kate und Kwrite sich in Zukunft nicht mehr direkt mit Root-Rechten öffnen lassen. Stattdessen informieren die Programme, wie der User die gewünschte Datei mittels sudoedit in den ohne Root-Rechte gestarteten Browser bekommt. Dies wird mit Sicherheit den Workflow zahlreicher User beeinträchtigen (und wie die Kommentare schon zeigen, für Unmut in der KDE-Community sorgen), allerdings ist dieser Schritt zum Beispiel in Bezug auf Wayland sowieso überfällig.

Today I pushed a change for Kate and KWrite which does no longer allow to be run as root. Instead it educates the user about how to do the same with sudoedit.

Now I understand that this will break the workflow for some users. But with a minor adjustment to your workflow you get the same. In fact it will be better, because the Kate you start is able to pick up your configured styling. And it will also work on Wayland. And most importantly it will be secure.

Langfristig wäre dann das Ziel, dass KIO und PolicyKit die eigentliche Arbeit übernehmen. So könnte man die gewünschten Dateien in den Editor öffnen, dann über Polkit „beweisen“, dass man Root-Rechte auf dem System hat, und dann die gewünschten Aktionen direkt über den Dateimanager oder den Editor durchführen. Das Ganze würde transparent im Hintergrund funktionieren, ohne dass man sich verrenken müsste. Wie das Ganze am Ende aussieht, gibt der Blog-Artikel von Martin noch nicht her. Im KDE-Bugtracker gibt es jedoch bereits schon einen entsprechenden Eintrag. Dieser stammt allerdings bereits von 2009 und bekommt hoffentlich durch die aktuelle Entwicklung ein wenig Leben eingehaucht.

Das Web-Cockpit aus Fedora 21 in der Workstation-Version installieren

Christoph Langner — Fri, 19 Dec 2014 08:40:51 +0000

Die Linux-Welt dreht sich ja bei vielen nur um Ubuntu, Ubuntu, Linux Mint und nochmal Ubuntu. Andere Distributionen wie etwa OpenSuse oder Fedora finden dagegen in der Öffentlichkeit deutlich weniger Aufmerksamkeit — auch wenn diese Distroibutionen im kommerziellen Umfeld durchaus große Erfolg aufweisen können. Das neue Fedora 21 bringt in meinen Augen allerdings nun ein Feature mit, das nicht ganz außer acht gelassen werden sollte. Es könnte für all die interessant sein, die einen kleinen Server in ihren vier Wänden betreiben und diese bequem managen möchten. Mit dem Cockpit lässt sich Fedora komplett über ein Web-Frontend administrieren, das Terminal und SSH könnten von daher eventuell erst einmal in der Garage bleiben.

Mit Cockpit lässt sich der aktuelle Status des Systems erfassen: Sich fortwährend aktualisierende Graphen zeigen Auslastung, Speicherbelegung oder die Load an. Wie bei ähnlich gelagerten Projekten wie etwa Webmin bieten sich aber über das reine Monitoring hinaus zahlreiche andere Funktionen. Ihr könnt die Systemlogs einsehen, über Systemd verwaltete Dienste kontrollieren und einrichten oder auch die Benutzeraccounts des Systems verwalten. Wer mehr als nur einen Fedora-Rechner im Einsatz hat, kann diese Installation in ein zentrales Cockpit integrieren und seine Rechner von diese Zentrale aus administrieren.

Cockpit unter Fedora 21 Workstation aktivieren

$ sudo yum install cockpit
$ sudo systemctl enable cockpit.socket
$ sudo systemctl start cockpit
$ sudo firewall-cmd --add-service=cockpit
$ sudo setenforce 0 # being fixed

Dabei kommt Cockpit nicht den über das Terminal gewohnten Funktionen in die Quere. Cockpit dreht nicht sein eigenes Ding, sondern setzt auf die üblichen Kommandos auf, die man auch im Terminal verwenden möchte. Da Cockpit perfekt auf Fedora abgestimmt ist, kommt es nicht zu Konflikten, wie man sie bei Webmin immer fürchten muss. Cockpit ist nur bei Fedora 21 Server von Haus aus aktiv, wer die Workstation-Version von nutzen möchte, der kann sich Cockpit allerdings auch nachträglich aus den Paketquellen installieren und selber mal einen Blick auf das Webfrontend werfen. Nach der Installation des Dienstes könnt ihr diesen dann über den Localhost unter localhost:9090 aufrufen.

Linktipp: Der Crontab-Generator hilft beim Erstellen von Cronjobs

Christoph Langner — Fri, 16 May 2014 13:45:33 +0000

Egal ob man mit crontab -e eine Crontabelle für den eigenen User anlegt, mit sudo crontab -e eine systemweite Crontabelle generiert, gleich die /etc/crontab bearbeitet oder in /etc/cron.d einen programmspetifischen Cronjob ablegt. Es gilt immer dem Cronjob zu sagen was er wann ausführen soll, dazu gibt es die ominösen ersten fünf Angaben in der Cronjob-Zeile.

17  *   * * *   root      run-parts --report /etc/cron.hourly
59 23   * * *   username  /pfad/zu/skript.sh
*/5 *   * * *   username  ping -c 1 www.google.de > /dev/null 2>&1

Die Syntax für einfache Aufgaben zu lernen ist nicht sonderlich schwer, meist reicht ein Blick ins Wiki. Doch was muss man denn jetzt als Cronjob angeben, wenn jede ungerade Minute, zu jeder geraden Stunde, zweimal im Monat, aber bitte nur an ungerade Monaten, aber dann auch nur an Wochentagen das Kommando foobar ausgeführt werden soll? Dafür müssen wohl auch erfahrene Sysadmins ein paar Minuten grübeln.

1-59/2 */2 */15 1-11/2 0,6 foobar >/dev/null 2>&1

Ganz so einfach lässt sich die Logik nicht zusammenstellen, aber per Mausklick ist das schnell gemacht, man muss nur wissen wo! Mit dem Crontab-Generator lassen sich Cronjobs Schritt für Schritt mit der Maus zusammenbauen, so dass man am Ende nur noch die Cronjob-Zeile in die Crontab des betroffenen Systems übernehmen muss. Der Generator beachtet dabei auch die Ausgaben, man kann sie verwerfen, in eine Datei schreiben oder per Mail verschicken. Damit dürften die meisten Anwendungsfälle wohl abgedeckt sein.

Mosh als SSH-Ergänzung für wacklige UMTS- oder LTE-Datenverbindungen

Christoph Langner — Sat, 19 Apr 2014 07:03:16 +0000

Wer mal „schnell“ während einer Zugfahrt versucht hat etwas mittels einer mobilen UMTS- oder LTE-Datenverbindung und SSH auf einem Server zu managen, der wird meist nach zahlreichen Versuchen gefrustet aufgegeben haben. Erst wenn der Zug vor einem Bahnhof langsam durch die Stadt rollt, bekommt man eine stabile Internetverbindung und damit auch endlich die Möglichkeit endlich störungsfrei zu arbeiten. Während der Fahrt bricht einfach zu oft die Verbindung weg. Abhilfe schafft das für wechselnde und instabile Verbindungen geschaffene Mosh.

Mosh wurde als SSH-Ersatz für instabile (die Verbindung darf komplett abbrechen, man kann sogar den Rechner in den Standby schicken) , wechselnde (man kann eine Mosh-Verbindung mit UMTS starten und über ein WLAN wieder aufnehmen) und langsame Internetverbindungen (Tastatureingaben werden bevorzugt durchgeleitet) geschaffen. Also etwa für die User, die sich mit einer wackligen UMTS-Leitung per SSH auf einen Server verbinden möchten. Es gibt Mosh für Linuxe, Windows und Macs und natürlich auch für mobile Betriebssysteme. So kann man Mosh vom PC und vom Handy aus benutzen.

Mosh neben SSH auf dem Server installieren

Um Mosh zum Laufen zu bekommen, muss das Programm auf beiden Rechnern installiert werden. Auf dem Server muss natürlich noch zusätzlich SSH installiert sein, da SSH weiterhin zur Authentifizierung des Users und zum Verbindungsaufbau benötigt wird. Mosh krallt sich erst nach dem Aufbau der verschlüsselten Leitung die Kontrolle über die Kommunikation.

# Mosh unter Debian/Ubuntu installieren...
$ sudo apt-get install mosh
# Mosh unter Arch Linux installieren...
$ sudo pacman -S mosh

Unter Ubuntu gibt es Mosh seit Precise ganz regulär in den Paketquellen, daher erspare ich mir Ausführungen über das Mosh-PPA. Dort gibt es allerdings aktuellere Versionen von Mosh, von daher könnte das PPA auch bei aktuelleren Ubuntus interessant sein. Arch-User finden Mosh ganz normal im Community-Repo. Und auch unter zahlreichen anderen Linuxen lässt sich Mosh ganz normal über die Paketquellen installieren, die Mosh-Homepage listet die Installationswege recht umfassend auf.

Mosh ohne Root-Rechte? Geht… vielleicht!

Problematisch wird es allerdings wenn man Mosh mit einem Server nutzen möchte, auf dem man zwar über ein SSH-Login verfügt, aber keine Root-Rechte hat. Mosh lässt sich in der Theorie ohne Root-Rechte — auch auf der Seite des Servers — betreiben, daher kann man sich Mosh auch selber kompilieren und beim Login ausführen. Mit install-user-mosh.sh findet ihr auch ein Skript, mit dem sich Mosh ohne große Aktion bauen lässt.

Allerdings braucht es zum erfolgreichen Bauen von Mosh eine lange Latte von Bibliotheken und Build-Tools, die wahrscheinlich nur auf wenigen Servern installiert sein dürften. Von daher solltet ihr lieber gleich beim Administrator des Servers anklopfen und lieb drum bitten doch schnell Mosh zu installieren. So wird das Programm sauber installiert, Sicherheitslücken geflickt und ihr müsst nicht groß basteln.

# Mosh auch ohne Root-Rechte installieren...
$ wget https://gist.githubusercontent.com/ViViDboarder/11000123/raw/1b71e37006db1d7dfdf8c59e4ba111d73645bec1/install-user-mosh.sh
$ chmod +x install-user-mosh.sh
$ ./install-user-mosh.sh

# Allerdings nur mit diesen Abhängigkeiten...
$ sudo apt-get install g++ protobuf-compiler libprotobuf-dev libboost-dev libutempter-dev libncurses5-dev zlib1g-dev expect-dev libexpect-perl liblocales-us-perl liblocales locales-all liblocale-us-perl liblocales-perl git libssl-dev

Mit Mosh auf den Server verbinden

Wurde Mosh auf Server und Client installiert, kann man wie gewohnt seine SSH-Verbindung aufrufen. Im Normalfall ersetzt ihr einfach das „ssh“ vor dem Befehl mit einem „mosh“, die Angabe des Users und des Servers bleiben gleich. Ein bisschen aufwändiger wird es allerdings, wenn man seinen SSH-Server nicht wie üblich auf Port 22 laufen hat, in diesem Fall muss man den von SSH benutzten Port ein wenig umständlicher angeben.

# Mit Mosh zu einem SSH-Server verbinden...
$ mosh du@dein.server.de
# Mit Mosh zu einem SSH-Server auf Port 222 verbinden...
$ mosh --ssh="ssh -p 222" du@dein.server.de

Ansonsten kann man nun genauso auf dem Server arbeiten, wie man es von SSH gewohnt ist — fast! Um Daten zu sparen überträgt Mosh immer nur die letzten Änderungen in der Shell. Was schon einmal übertragen wurde, wird noch nochmal auf den Server geschickt. Unter anderem deshalb funktioniert der Scrollback-Speicher nicht. Man kann also nicht mit Shift-PageUp/PageDown oder mit dem Mausrad die letzten Ausgaben der Shell hervorholen.

Im Handling unterscheidet sich Mosh nicht von anderen Shells.

Mosh für Android und Chrome/Chrome OS

Wie schon mehrfach angesprochen ist Mosh natürlich ideal für mobile Geräte. Daher ist es auch nicht verwunderlich, dass es Mosh-Clients für Handys gibt — allerdings wohl nur für Android. Android-User können auf JuiceSSH zurückgreifen, ein SSH-Client für Android den ich schon mehrfach hier im Blog hatte. Die App kostet eine Kleinigkeit, sie ist aber definitiv ihr Geld wert. Mosh lässt sich dort in den Settings der Verbindung einstellen. Und auch für Chrome-, Chromium oder Chrome-OS-User gibt es eine Mosh-Browser-App, die sich direkt im Webbrowser ausführen lässt.

JuiceSSH kann unter Android mit Mosh arbeiten.

Mosh gibt es inzwischen auch als Browser-App für Chrome.

Mit apt-clone die Installation eines Rechners auf andere übertragen

Christoph Langner — Sat, 07 May 2011 12:41:48 +0000

Wer länger mit einem Ubuntu- oder Debian-System gearbeitet hat, der weiß natürlich die Paketverwaltung zu schätzen. Sie ist eines DER Argumente pro Linux, wenn nicht sogar DAS Argument. Wer nicht nur einen Rechner besitzt, sondern neben dem Desktop noch ein Notebook, ein Netbook usw. der möchte oft die selben Pakete auf all seinen Rechnern installiert haben. So kann man nahtlos auf allen Rechner sämtliche Aufgaben erledigen. Dafür gibt es schon seit längerem Tricks und Kniffe, wie man eine Paketliste auf einem System erstellt, und diese dann auf einem anderen Rechner einspielt. Allerdings kommt diese Methode mit manuell installierten Paketen und zusätzlichen Quellen nicht mehr wirklich gut klar, so dass es seit Ubuntu Natty mit apt-clone ein Werkzeug gibt, das das Clonen von Systemen vereinfacht.

Wie angesprochen kann man über den Befehl dpkg die installierten Pakete ausgeben lassen. Mit ein bisschen Shell-Magie kann man aus dieser Liste eine Datei erzeugen, die sich dann auf einem anderen Rechner dazu verwenden lässt, die selben Pakete zu installieren. Im Endeffekt läuft das das Ganze so ab…

# Paketliste auf Rechner A erstellen...
$ dpkg --get-selections | awk '!/deinstall|purge|hold/ {print $1}' > packages.list
# Pakete aus der Liste auf Rechner B installieren
$ xargs -a "packages.list" sudo apt-get install

Nun funktioniert dieses Vorgehen leider nur solange, wie die Liste der verfügbaren Pakete in den Paketquellen identisch ist. Referenziert die Liste auf ein Paket, das manuell installiert wurde oder auf ein Paket aus einer zusätzlichen Paketquelle, so muss diese erst über die /etc/apt/sources.list bzw. über add-apt-repository hinzugefügt werden. Manuell installierte Pakete müsste man sogar von Hand aus der Liste löschen.

Hier kommt nun das Programm apt-clone ins Spiel. Dieses sichert nicht nur eine Paketliste, sondern speichert auch auch die sources.list inkl. weiterer in /etc/apt/sources.list.d/ abgelegten Quellen und erzeugt sogar aus manuell installierten Programmen wieder installierbare Pakete. So kann man in der Tat das komplette System klonen, ohne dass man groß Aufwand treiben muss. Einzig Konfigurationsdateien aus /etc werden bislang nicht mitgesichert, so dass man Dienste erneut konfigurieren muss, doch daran arbeitet man aktuell auch noch.

Wenn Ihr das Ganze ausprobieren wollt, dann müsst Ihr erst einmal apt-clone auf beiden Rechnern installieren. Das Paket gibt es jedoch nur seit Ubuntu Natty 11.04, ältere Ubuntu-Versionen lassen sich daher auf diesen bequemen Weg nicht clonen…

$ sudo apt-get install apt-clone

Danach müsst ihr auf dem fertig eingerichteten System apt-clone ausführen. Die Option clone --width-dpkg-repack sorgt dafür, dass von Hand installierte Pakete wieder erneut verpackt werden, so dass Ihr sie auf dem zweiten System wieder erneut installieren könnt. Bei mir schmeißt das Ganze ein paar Fehlermeldungen aus, die jedoch keine Auswirkungen hatten.

$ sudo apt-clone clone --with-dpkg-repack /
dpkg-deb: warning: './dpkg-repack-7727/DEBIAN/control' contains user-defined field 'Original-Maintainer'
dpkg-deb: warning: ignoring 1 warning about the control file(s)

dpkg-deb: building package `libxapian15' in `./libxapian15_1.0.20-2_amd64.deb'.
dpkg-deb: building package `teamviewer6' in `./teamviewer6_6.0.9224_amd64.deb'.
dpkg-deb: building package `openshot-doc' in `./openshot-doc_1.3.0-maverick1_all.deb'.
dpkg-deb: warning: './dpkg-repack-8460/DEBIAN/control' contains user-defined field 'Python-Version'
dpkg-deb: warning: ignoring 1 warning about the control file(s)

dpkg-deb: building package `arte+7recorder-5' in `./arte+7recorder-5_5.0.beta3~ppa3~maverick_all.deb'.
dpkg-deb: warning: './dpkg-repack-8498/DEBIAN/control' contains user-defined field 'Original-Maintainer'
dpkg-deb: warning: ignoring 1 warning about the control file(s)
...

Danach findet ihr im Wurzelverzeichnis / eine Datei mit dem Namen apt-clone-state-rechnername.tar.gz, in dieser stecken nun die gesammelten Informationen. Habt ihr keine Pakete manuell installiert, so ist sie nur ein paar KB groß. Sollten jedoch Programme wie Skype, Teamviewer und Co. manuell über .deb Dateien installiert worden sein, so wird diese Sicherung natürlich recht schnell aufgeblasen.

Packt die Datei nun auf einen USB-Stick oder schiebt sie über das Netzwerk auf eurer zweiten Rechner und startet auf dem zweiten Rechner ebenfalls apt-clone. Diesmal übergebt ihr mit restore die Option, dass die Paketinformationen aus dem Archiv wiederhergestellt werden sollen.

$ sudo apt-clone restore apt-clone-state-rechnername.tar.gz

Je nachdem wie viele Pakete gefehlt haben, wird nun die Paketverwaltung eine Weile lang beschäftigt sein, da ich auf meinem Testsystem bspw. eine komplette Latex-Umgebung installiert hatte, wird diese nun auch auf dem geclonten System installiert usw…

Damit Ihr nicht völlig unnötige Pakete installieren lässt, würde ich vorher auf dem zu klonenden System etwas aufräumen. Schmeißt dazu am besten Synaptic oder das Software-Center an und schaut was ihr nicht wirklich braucht. Räumt dann noch mit…

$ sudo apt-get autoremove

…nicht mehr benötigte Pakete runter und entfernt am besten noch bei den nicht mehr benötigte Kernel, die sammeln sich recht gerne an und brauchen viel Platz. Schau euch dazu am besten mal den Beitrag alte Kernel inkl. Header mit nur einem Befehl entfernen an. Mit einem Kommando räumt ihr alle alten Kernels vom System.

Getestet habe ich das alles mit meiner „normalen“ Natty-Installation unter einem 64-Bit Ubuntu und einer 32-Bit Installation in einer VirtualBox. Selbst bei diesem Sprung von 32- auf 64-Bit ging alles klar. Alles in allem ist apt-clone für alle ein tolles Werkzeug, die ihr System neu einrichten wollen.

Fehler in Lucid kann/konnte ganz Root löschen

Christoph Langner — Thu, 08 Apr 2010 17:07:20 +0000

Ich lese immer wieder von Anwendern, die auf ihren „produktiv“ genutzten Rechnern Entwicklungsversionen von Ubuntu oder anderen Linux-Distributionen verwenden. Trotz aller Warnungen wird darauf gesetzt, dass nichts schief geht, zur Not installiert man halt das System neu. Dass jedoch das komplette Dateisystem gelöscht werden KANN, das hat selten jemand auf dem Radar.

Nur als kleine zusätzliche Warnung möchte ich euch auf Bug #557177 aufmerksam machen. Durch das unglückliche Zusammenspiel von „neugierigem“ Benutzer, unvollständiger Dokumentation und problematischen Script war es möglich das komplette Dateisystem zu löschen. Ich möchte damit jetzt auf keinen Fall Panik vor Lucid schüren, doch Entwicklungsversionen sind Entwicklungsversionen! Auch wenn es verlockend ist allerneuste Programmversionen zu verwenden und die Entwicklung zu beobachten. Niemand kann euch garantieren, dass keine gravierenden Fehler gemacht werden.

Bild „backup“ von Sean MacEntee, CC-BY 2.0

Entwicklungsversionen sollten auf Testrechnern oder in virtuellen Maschinen benutzt werden, doch auf keinen Fall solltet Ihr eine Entwicklungsversion – eventuell sogar ohne zuvor erstellten Backups – auf eure wertvollen Daten loslassen! Schaut daher dass Ihr Mr. Backup glücklich macht, nicht dass es euch so geht wie Mr. NoBackup (via Fefe).

Dateien einfach über Nautilus mit Root-Rechten ausführen

Christoph Langner — Tue, 20 Feb 2007 22:00:28 +0000

Gerade Einsteiger haben unter Linux Probleme mit dem Verständnis von Dateirechten und Dateizugehörigkeiten. So gehört das Editieren von Systemdateien oftmals schon zu einer Aufgabe, wo hohe Hürden zu überwinden sind. Ein Terminal muss geöffnet werden und zum Beispiel sudo gedit /etc/fstab ausgeführt werden. Dabei kommt es zu Tippfehlern, weil Befehle falsch abgetippt oder Pfade falsch eingegeben werden, weil die Pfadvervollständigung via Tabulatortaste nicht bekannt ist. Warum also, kann man eine Datei nicht aus dem Dateimanager Nautilus selber mit Root-Rechten öffnen? Einsteigern wäre dabei viel geholfen.

Nichts leichter als das. Ab Ubuntu Edgy Eft 6.10 gibt es das Paket nautilus-gksu. Ist das Paket installiert und Nautilus einmal mittels dem Befehl nautilus -q neu gestartet worden, so kann eine Datei über Rechtsklick | Als Administrator öffnen mit Root-Rechten aus dem Kontextmenü des Dateimanagers geöffnet werden. Ein Terminal oder die Eingabe von Befehlen ist nun nicht mehr nötig. Das Programm scheint es leider nur für Debian/Ubuntu zu geben, für Fedora steht es wohl nicht zur Verfügung.