Thema: Users4Users: Kleine Tricks zur Verfeinerung des Systems

Hallo Gemeinde,

hier sollen mal kleine Tipps & Tricks gepostet werden wie man sein System verfeinern kann. Also z.B. in welcher Konfigurationsdatei ein bisschen geschraubt werden kann und was für einen Effekt das dann hat.

So, ich fang' dann auch gleich mal an.

Hin und wieder muss man bei dem ein oder anderen Programm den ganzen Pfad eingeben wenn man es aus der Konsole/Bash/Xterm/... starten will, bzw. vorher mit cd ... zu dem jeweiligen Ordner gehen.
Um einen kleineren Befehl mit dem ganzen Pfad zu versehen, so dass man nur noch diesen einen Befehl eingeben muss, gibt es die Funktion/den Befehl alias. Einfach mal nur alias in die Konsole eingeben, dann sieht man welche alias alles gesetzt sind.
Man kann temporär einen alias setzen, indem man folgenden Befehl eingibt:

Code:

alias gewünschterBefehl='ganzer/Pfad/und/Programm'

Die ' ' nicht vergessen!
Das gilt allerdings nur für eine Sitzung. Startet man seine Konsole neu, oder gar den PC so ist der temporäre alias nicht mehr gesetzt.

Um einen alias dauerhaft für sein Benutzerprofil zu setzen, das also jedes mal wenn man sich anmeldet gilt, muss man nur die ~/.bashrc ein wenig modifizieren.
Am Ende der Datei gibt man einfach den Befehl wie o.g. ein:

Code:

alias gewünschterBefehl='ganzer/Pfad/und/Programm'

und schon gilt der alias für immer auf dem Benutzerprofil.
Auch hier die ' ' nicht vergessen und keine Leerzeichen bei dem Gleichheitszeichen!

Will man zwei Befehle in einem alias zusammenfügen, kann man das mit einem Semikolon machen.

Code:

alias gewünschterBefehl='Befehl1 ; Befehl2'

Bsp.: Bei der libxcb-Sache, die hier im Unterforum beschrieben ist, recht praktisch. Mit einem Befehl zunächst die libxcb exportieren und dann das Programm aufrufen.

Praktische Sache meiner Meinung nach.

Schönen Gruß,
benne

Hallo,

mit der Datei

Code:

/etc/sysconfig/cron

kann man so einiges einstellen. Wenn man zum Beispiel möchte, dass der /tmp-Ordner beim Booten geleert wird muss nur folgendes in der Datei stehen:

Code:

TMP_DIRS_TO_CLEAR="/tmp"
CLEAR_TMP_DIRS_AT_BOOTUP="yes"

Wobei die Einträge dafür evtl. schon vorhanden sind und nur ein "no" in ein "yes" geändert werden muss. Die Liste mit Ordnern, die geleert werden soll kann natürlich auch erweitert werden.

Schönen Gruß,
benne

Hallo,

mithilfe von udev kann man einiges in Sachen Geräte- und Hardwaresteuerung machen.
udev – Wikipedia

Als Beispiel:
mich hat es genervt, dass wenn ich bei KDE 4.1 über die Geräteüberwachung in der Taskleiste meine externe Festplatte mounten wollte, immer Dolphin mit dem Inhalt der Festplatte geöffnet wurde. Außerdem wollte ich etwas dazu lernen, also hab' ich mal geschaut, wie man diese Geräteüberwachung von KDE umgehen kann.

Wenn man nicht möchte, dass automatisch gemountet wird, man aber als User die Möglichkeit haben möchte zu mounten, bietet sich pmount an: http://www.pc-forum24.de/linux-howto...-x-11-0-a.html

Möchte man, dass automatisch gemountet wird kann man das mithilfe einer udev-Regel lösen. Eine udev-Regel (bzw. udev-rule) besteht eigentlich nur aus einer Zeile. Das Prinzip ist recht einfach:
Wenn x passiert, dann tue y
In meinem Fall also: Wird die Festplatt angehängt, dann mounte sie mit User-Rechten.

Die erste Schwierigkeit dabei ist herauszufinden, wie man die Festplatte eindeutig identifizieren kann. Nach dem Anstöpseln der Festplatte kann man die wichtigen Parameter per

Code:

dmesg | tail -n 25
bzw.
sudo cat /var/log/messages | tail -n 25

herausfinden.

Bzw. wenn man genau weiß nach was man sucht bietet es sich an von Textkommandobefehlen gebrauch zu machen, wie zum Beispiel grep:

Code:

benne@linux-rsm7:~> sudo cat /var/log/messages | tail -n 25 | grep idVendor
Mar  4 16:09:19 linux-rsm7 kernel: usb 2-3: New USB device found, idVendor=04cf, idProduct=8818

Wenn also ein USB-Device mit idVendor 04cf auf einmal gefunden wird, dann soll gemountet werden. Na dann los! In /etc/udev/rules.d wird als root z.B. die Datei

Code:

00-myharddrive.rules

angelegt. Wie die Regel heißt ist im Prinzip egal, wichtig ist, dass sie mit einer zweistelligen Zahl beginnt. Dabei wird bei der Regel mit der niedrigsten Zahl immer zuerst geschaut, ob etwas für ein bestimmtes Ereignis zu tun ist.
Wie sieht jetzt also die Regel aus?
Bei mir funktioniert folgendes:

Code:

SUBSYSTEMS=="usb", KERNEL=="sd?1", ATTRS{idVendor}=="04cf", RUN+="/bin/mount -t vfat -o uid=benne,gid=users /dev/sdb1 /media/Festplatte"

Zwei Gleichheitszeichen ( == ) beschreiben einen Vergleich, ein Gleichheitszeichen ( = ) eine Zuweisung und += ein auszuführenden Befehl.
Wenn also ein USB-Device mit idVendor=="04cf" gefunden wird, dann soll der o.g. mount-Befehl ausgeführt werden. (Username und Gruppenzugehörigkeit sind ggf. anzupassen ;> )

Zum Schluss muss udev einmal neugestartet werden

Code:

/etc/init.d/boot.udev restart

Wer mehr über udev erfahren möchte:
- udev – Wikipedia
- man udev
- oder einfach Google (o.a. Suchmaschinen) befragen ;>

Schönen Gruß,
benne

Hallo,

häufig muss man Befehle als root ausführen, und manchmal macht es auch Sinn, wenn die User diese bestimmten Befehle selber ausführen könnten.

Zum Beispiel für das Aushängen einer Festplatte. Bei dem Beitrag oben wird die Festplatte zwar automatisch gemountet, aber unmounten muss man jedes Mal als root, dabei wird die Festplatte schon mit Userrechten gemountet. Der User kann also quasi alles machen, nur nicht aushängen. Was tun?

Für solche Fälle gibt es sudo und die Datei /etc/sudoers, in welcher man festlegen kann, welche User/Groups welche Befehle mit welchen Rechten ausführen dürfen.

Editieren muss man natürlich als root indem man einfach

Code:

visudo

ausführt.

Ans Ende der Datei fügt man dann folgende Zeile ein:

Code:

benne ALL = (root) NOPASSWD: /bin/umount

Damit legt man fest, dass der Benutzer "benne" auf allen Systemen mit root-Rechten den Befehl /bin/umount ausführen darf, ohne sich per Passwort authentifizieren zu müssen. Die allgemeine Syntax ist

Code:

USER HOST = (RUNAS) [OPTIONS] COMMAND

Unmounten kann man nun auch als User.

Um dennoch nicht den ganzen Pfad jedes Mal angeben zu müssen hab' ich mir einen alias wie oben beschrieben gesetzt. (Alternativ ginge auch ein Bash-Script, aber da es quasi nur um die Verkürzung eines Befehls geht...)

Wer mehr über sudoers wissen will:
Wie immer "man sudoers" oder google o.ä. fragen!

Schöne Grüße,
benne

Dann "schieße" ich mal direkt in die "andere Richtung".

Wer einem bestimmten Nutzer die Verwendung von sudo komplett verbieten will, der fügt eine Zeile wie diese hinzu.

Code:

NAME_DES_USERS ALL = (ALL) !/*

Das "in die andere Richtung" hat hier noch eine weitere Bedeutung, die /etc/sudoers wird AFAIK von oben nach unten gelesen, also sollten solche Zeilen als erste Definition über die ganzen anderen Definitionen mit der Form

Code:

USER HOST = (RUNAS) [OPTIONS] COMMAND

eingefügt werden, damit sie auch zuerst greifen.

Greetz,

RM

Dazu noch meine 2 Cents.

Per sudo konfig etwas zu erlauben ist Ok. Es sollte nur keiner versuchen das komplement zu bewirken: Also zu definieren was per sudo NICHT erlaubt ist. Das ist von vorne herein zum Scheitern verurteilt - es gibt immer Dinge die man bei der Exlusion vergisst bzw sich durch irgendweclhe zukünftigen SW updates ändern.

Also deshalb: Nur positive Erlaubnis bei sudoers. Alles andere ist ein Flickenteppich.

Zitat von framp

Also deshalb: Nur positive Erlaubnis bei sudoers. Alles andere ist ein Flickenteppich.

Ja, gerade bei mehreren Usern und/oder Definitionen von Aliasen für Gruppen, wird gerne mal etwas übersehen, allgemein sollte sudo auch _nicht_ als "Sicherheitsfeature per se" angesehen werden, egal was eine bestimmte Distribution behaupten mag.

Mit sudo erlaubt man "normalen" Nutzern Dinge auszuführen, für die sich eigentlich nicht vorgesehen sind (root existiert nicht umsonst auf _allen_ unixoiden Systemen, auch andere Systeme setzen ja auf privilegierte und nicht-privilegierte Nutzer als Konzept), das kann also nicht "sicherer" sein.

Ein Trick, wie man mit einer "Erlaube"-Regel Ähnliches erreichen kann, wäre z.B. so etwas:

Code:

username ALL = (ALL) /bin/false

Damit darf der entsprechende User dann gerne "false" mit erhöhten Rechten aufrufen, die Chancen, daß dieses Programm Schaden anrichtet, sind relativ gering.

Greetz,

RM