Howtos

How to Create Local Debian Repository

Why to create a private Debian repository ?

So that to gain more control while updating and upgrading your .deb files, to be able to install exactly the files you used in your test environment, and, what is also important – to avoid so called “dependency hell”.

Follow the steps below to create a local Debian repository, that is recognized by Apt. Apt will use .deb files from the private repository and resolve the associated dependencies when you run the command to install the packages.

1. Install the dpkg-scanpackages tool

To do so, run the following command as root:

apt-get install dpkg-dev

2. Then, create repository directory and place packages there:

mkdir /path/to/repository
cp /path/to/packages /path/to/repository

3. Run “dpkg-scanpackages”

Switch to the repository directory and invoke the dpkg-scanpackages there:

cd /path/to/repository
dpkg-scanpackages -m . > Packages

This creates the Packages file holding the metadata for all packages in the newly created repository.

It is also possible to create a gzipped version of the Packages file - Packages.gz:

cd /path/to/repository
dpkg-scanpackages -m . | gzip > Packages.gz

4. Create a Debian configuration file for the repository

The configuration file (for example myrepo.list) should be placed under the /etc/apt/sources.list.d/ directory and may look like:

deb [trusted=yes] file:/path/to/repository /

In the case when you’d like to share your repository over the network, e.g. to put it under http://your-site.com, the configuration file may look like:

deb [trusted=yes] http://your-site.com/your/repository/ /

or just use RpmDeb capabilities to create, host and distribute your packages worldwide without the neccessity to set up and maintain infrastructure.

OpenMediaVault - Komplettanleitung zur Installation und Konfiguration

Anleitung

Anmeldung nach Upgrade 7->8 : 502 - Bad Gateway

=> omv-salt deploy list-dirty

=> omv-salt deploy run $

Alpine IGEL-HW

  
   6 setup-xorg-base
  13 adduser -g "willi book" willi
  14 adduser willi wheel
  15 apk add doas
   17 apk add nano
  18 nano /etc/doas.d/doas.conf
  19 adduser willi video
  20 adduser willi input
  24 apk add linux-firmware-radeon
  25 echo >> radeon /etc/modules
  26 echo >> fbcon /etc/modules
  27 apk add mkinitfs
  28 nano /etc/mkinitfs/mkinitfs.conf 
  29 mkinitfs 
  30 reboot
  31 apk add xf86-video-ati
  34 apk add kbd
  37 apk add xf86-input-evdev
  39 apk add xf86-input-libinput
  40 setup-desktop 
  41 reboot
  46 apk add gedit
  47 history 
  49 history >history.txt
  
  https://wiki.alpinelinux.org/wiki/Main_Page

Linux audio recording guide (PulseAudio or PipeWire)

This article explains how to record an audio stream on a Linux system running either PulseAudio or PipeWire. (The commands below are all PulseAudio commands, but they should work on a PipeWire system thanks to its PulseAudio compatibility.)

You can record both input streams (microphones) and output streams (whatever you are hearing in your headphones). However, each stream goes to a separate file. If you want to record a conversation, record both streams and mix them afterwards in an audio editor/DAW.

First, find out the PulseAudio name of the stream you want to record.

If you want to record a microphone, run

pactl --format=json list sources | jq '.[] | select(.monitor_source == "") | {name: .name, desc: .description}'

Here is an example output:

{
  "name": "alsa_input.pci-0000_06_00.6.analog-stereo",
  "desc": "Family 17h/19h HD Audio Controller Analog Stereo"
}
{
  "name": "alsa_input.usb-Audient_EVO4-00.analog-surround-40",
  "desc": "EVO4 Analog Surround 4.0"
}

The "name" component is what you need; the description is just there to help you figure out which stream is the right one.

If you want to record an output (e.g. a person you’re talking to), similarly run

pactl --format=json list sources | jq '.[] | select(.monitor_source != "") | {name: .name, desc: .description}'

Once you know the name of the stream you want to record, run

parecord --channels=1 --file-format=flac --device $STREAM_NAME filename.flac

When you are done recording, terminate the process by pressing Ctrl-C.

--channels=1 forces your recording to mono, which is usually what you want.

To see the list of supported file formats, run

parecord --list-file-formats

If you try to record a generic output, such as alsa_output.pci-0000_06_00.6.analog-stereo.monitor, you might also capture some unwanted output from other applications or notification sounds. To make sure only a specific application is recorded, here’s what you can do:

  1. Create a fresh sink that will send its input to headphones, but to which no application is connected by default.
  2. Direct the sound from the specific applications you want to record into this new sink.
  3. Record the output of the new sink.

Find out the name of your output device by running

pactl --format=json list sinks | jq '.[] | {name: .name, desc: .description}'

In my case, it says

{
  "name": "alsa_output.pci-0000_06_00.6.analog-stereo",
  "desc": "Family 17h/19h HD Audio Controller Analog Stereo"
}
{
  "name": "alsa_output.usb-Audient_EVO4-00.analog-surround-40",
  "desc": "EVO4 Analog Surround 4.0"
}

Let’s say my headphones are connected to EVO 4. Then I would run:

OUTPUT_NAME=alsa_output.usb-Audient_EVO4-00.analog-surround-40
pactl load-module module-combine-sink sink_name=recording sink_properties=device.description=Recording slaves=$OUTPUT_NAME
parecord --channels=1 --file-format=flac --device recording.monitor filename.flac

Now, redirect the sound to the Recording sink:

  1. Run the pavucontrol command (a graphical window will appear) and go to the “Playback” tab.
  2. Start the application you’d like to record.
  3. The application should appear in pavucontrol. If it doesn’t, make sure the application produces some sound. Unfortunately, until the application tries to play something, PulseAudio/PipeWire cannot “see” it.
  4. Choose the Recording sink for the application as shown on the screenshot:
pavucontrol.png
A screenshot of a pavucontrol window

How to Install NVIDIA Drivers on Debian

Introduction
NVIDIA GPUs (Graphics Processing Units) have various uses, including gaming, 3D rendering, cryptocurrency mining, deep learning, and machine learning. Keeping the drivers for these GPUs up to date ensures your system performs at peak efficiency.

In this tutorial, we will guide you through the NVIDIA driver installation process on Debian.

grafik.png

Prerequisites



Note: If you are working on an older machine, use the nvidia-detect tool to determine the appropriate driver version. Install it with sudo apt nvidia-detect and run nvidia-detect as a command to determine the appropriate driver version.

Install NVIDIA Drivers Via Debian Repository

The first method focuses on installing NVIDIA drivers from the Debian repositories. NVIDIA recommends using this method for Linux systems due to improved interactions.

Follow the steps below to install the drivers via the Debian repository.

Step 1: Enable Non-Free Repositories

Adjust the APT sources list to include non-free repositories before installing. To enable them, do the following in the terminal:

1. Open the APT sources list file using a text editor:

sudo nano /etc/apt/sources.list

2. Add the contrib and non-free repositories to the sources list links. For example:

deb http://deb.debian.org/debian/ bullseye main contrib non-free

grafik.png

Enabling the repositories gives access to proprietary drivers that are not open source, including NVIDIA drivers.

3. Press Ctrl+X, Y, and Enter to save changes and exit the configuration file.

4. Update the system repository index:

sudo apt update

The update ensures the newest data from the added repositories is available.

Step 2: Install NVIDIA Drivers

To install the driver, see the steps below:

1. Run the following apt command to install the driver:

sudo apt install nvidia-driver

grafik.png

The command also installs necessary dependencies. Press y and Enter to confirm the installation.

2. If the system prompts that there is a conflicting driver, a restart after the installation resolves the issue.

grafik.png

Press Enter to confirm and continue the installation.

3. Once the installation completes, reboot your system with:

sudo reboot

The driver loads immediately after reboot.

Install NVIDIA Drivers Via Official nvidia.com Package

This method lets you manually download and install an NVIDIA driver package from the official website.

Step 1: Download Drivers

To download the NVIDIA driver installer, do the following:

1. Navigate to the Unix driver archive in a web browser and find the appropriate driver version download link. The latest production version is compatible with all modern NVIDIA GPUs.

grafik.png

Click the version number to access the downloads page.

2. Click the Download button and save the file.

grafik.png

The file is in the ~/[username]/Downloads directory of the currently logged-in user.

Step 2: Install Driver Prerequisites

Install the driver prerequisites. Run the following in the terminal:

sudo apt -y install linux-headers-$(uname -r) build-essential libglvnd-dev pkg-config

grafik.png

The packages ensure that NVIDIA drivers compile successfully.

Step 3: Disable Default Drivers

Disable the default nouveau GPU driver:

1. Create and open a new configuration file using nano:

sudo nano /etc/modprobe.d/blacklist-nouveau.conf

The configuration file is in the kernel module loading directory.

2. Add the following lines to the file:

blacklist nouveau
options nouveau modeset=0

grafik.png

The file instructs the system to prevent the Nouveau kernel module from loading and disables the open-source driver.

3. Save the changes and exit. Press Ctrl+X, Y, and Enter.

4. Update the kernel initramfs with:

sudo update-initramfs -u

grafik.png

The rebuild takes several moments to complete. It ensures that essential drivers load and the root filesystem mounts early in the boot process. It ensures the changes apply after rebooting.

Step 4: Reboot to Multi-User Login

Since the default GPU drivers are now disabled, switching to a text-based interface lets you install NVIDIA drivers without using the GUI.

1. Enable the text-based multi-user login prompt:

sudo systemctl set-default multi-user.target

grafik.png

The command creates a symlink and outputs the result.

2. Reboot the system with:

systemctl reboot

The system restarts into the terminal without a GUI.

Step 5: Install Nvidia Drivers

Once the system restarts, do the following:

1. Log in as root.

grafik.png

2. Navigate to the directory where the driver file is downloaded:

cd /home/[username]/Downloads

3. Install the Nvidia drivers using the package you downloaded:

bash ./[driver file name]

For example:

bash ./NVIDIA-Linux-x86_64-550.127.05.run

grafik.png

3. If prompted, choose the following options during the install process:

4. Wait for the process to complete until it shows the installation was successful.

grafik.png

Press Enter to confirm and exit the installer. The prompt returns to the terminal.

Step 6: Enable GUI

Re-enable the GUI to complete the process and start up the new drivers:

1. Enable the GUI login prompt with:

systemctl set-default graphical.target

grafik.png

2. Reboot your system to finish the installation:

reboot

The system starts up using the new driver.

Conclusion

This guide showed how to install the newest NVIDIA GPU drivers on Debian 12 using two different methods.

 

20 häufige Linux IPTables Firewall Regeln

Lernen Sie die wichtigsten IPTables Regeln kennen welche oft verwendet werden um ihren Server abzusichern, Ports weiterzuleiten oder den Traffic an mehrere Server aufzuteilen wie einem Load Balancer.

In diesem Beispielen verwenden wir ETH0 als Netzwerk Interface, eine abwandlung der Befehle ist ganz einfach durch austauschen des Interfaces möglich, wenn Sie z.B. virtuelle Interface haben wir VENET0:0 oder dergleichen.
Um herauszufinden welchen Netzwerk Interface namen Sie haben verwenden Sie einfach:

ifconfig

1. Auflistung der Firewall Regeln

Um die derzeitigen Filterregeln auflisten zu können benötigen wir die List Option. Dann sehen Sie ob Regeln aktiv sind oder ob keine Regeln vorhanden sind.

iptables -L

2. Löschen einer existierenden Regel

Bevor wir neue Regel erstellen, bereinigen wir zuerst einmal alle vorherigen Regeln damit wir von vorne Beginnen. Um die derzeit gültigen Regeln alle zu löschen benötigen wir einen "flush". Dies geschieht entwedert mit -F oder --flush

iptables -F
(oder)
iptables --flush

3. Setzen einer Standart Regeln

Standartmäßig wenn keine Einstellungen und Regeln gesetzt sind, wird jede Verbindung zum System auf "Accept" (Erlaubt) gestellt. Um die Verbindungen zu schließen können wir anstellen von ACCEPT die Regeln auf DROP (Überspringen) für den Input, Output und Forward.

iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT DROP

Wenn wir die Input und Output Regel standardmäßig auf Drop setzen, müssen Sie für jede weitere Regel sowohl Input als auch Output per Accept wieder freigeben, je nach ihren Anforderungen.
In den Beispielen unterhalb haben wir Regeln sowohl für den Input als auch den Output welchen wir freigeben können. Es hängt von ihren Individuellen Einstellungen ab was für Sie sinnvoll ist.

4. Blockieren einer Spezifischen IP Adresse

Um eine einzelne IP Adresse z.B. für den Input Traffic zu sperren können Sie auch speziell eine Regel setzen. Je nachdem ob Sie eine Allgemeine Drop Regel nutzen oder nicht. Ersetzen Sie hierfür einfach x.x.x.x durch die IP Adresse welche gesperrt werden soll.

iptables -A INPUT -s "x.x.x.x" -j DROP

Diese Regel macht sinn wenn Sie Auffälligkeiten im System bemerken welche von der gesperrten IP Adresse kommen und Sie diese Temporär blockieren wollen.
Sie können die IP Adresse auch spezifisch auf einem Interface blockieren oder rein auf den Traffic via TCP.

iptables -A INPUT -i eth0 -s "x.x.x.x" -j DROP
iptables -A INPUT -i eth0 -p tcp -s "x.x.x.x" -j DROP

5. Erlauben sie SSH Zugriff auf ihrem System

Um SSH freizuschalten können wird den Port 22 für Input und Output freigeben. Natürlich können Sie auch SSH auf einen anderen Port laufen lassen. Hierfür dann entsprechen die 22 editieren.
iptables -A INPUT -i eth0 -p tcp --dport 22 -m state --state NEW,ESTABLISHED -j ACCEPT

iptables -A OUTPUT -o eth0 -p tcp --sport 22 -m state --state ESTABLISHED -j ACCEPT

5. Erlauben von SSH nur auf einem spezifischen Netzwerk

Die folgende Regel erlaubt den SSH Zugriff nur von dem einem internen Netzwerk mit den IP Adresse beginnen mit 192.168.100.x.

iptables -A INPUT -i eth0 -p tcp -s 192.168.100.0/24 --dport 22 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -o eth0 -p tcp --sport 22 -m state --state ESTABLISHED -j ACCEPT

In diesem Beispiel nutzen wir ein 24er Subnetz. Sie können natürlich auch die volle Subnet mask nutzen.

6. Erlauben von HTTP und HTTPS verbindungen

Webserver nutzen HTTP (Port 80) und HTTPS (Port 443) für das anzeigen von Webseiten, die folgende Regel erlaubt den Zugriff auf ihren Webserver via HTTP von Extern.

iptables -A INPUT -i eth0 -p tcp --dport 80 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -o eth0 -p tcp --sport 80 -m state --state ESTABLISHED -j ACCEPT

Nun die selbe Regel für den HTTPS Port 443 um auch sicheren Webseiten anzeigen zu können.

iptables -A INPUT -i eth0 -p tcp --dport 443 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -o eth0 -p tcp --sport 443 -m state --state ESTABLISHED -j ACCEPT

7. Mehrere Regeln zusammenführen in eine Regel

Wenn Sie Traffic von ausserhalb auf mehrere Ports erlauben wollen, macht es oft sinn dies in eine einzelne Regel zu verpacken, anstatt für jeden Port eine eigene Regel zu schreiben. Hier ersparen wir uns eine unzählige Anzahl an widerholungen.
Im folgenden Beispiel erlauben wir den Traffic von SSH (22), HTTP (80) and HTTPS (443).

iptables -A INPUT -i eth0 -p tcp -m multiport --dports 22,80,443 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -o eth0 -p tcp -m multiport --sports 22,80,443 -m state --state ESTABLISHED -j ACCEPT

8. Load Balance eingehenden Web Traffic

Es ist möglich den eingehenden Traffic aufzuteilen auf mehrere IP Adressen. Umgangssprachlich auch ein sogenannter Load Balancer ermöglicht solche aufgaben.
Um den Traffic aufzuteilen benötigen wir in IPTables die nth Erweiterung. Das folgende Beispiel zeit wie HTTPS traffic auf drei unterschiedliche IP Adressen aufgeteilt wird. Für  jedes 3te Paket das ankommt wird die nächste IP herangezogen welche den counter bei 0 halt.

iptables -A PREROUTING -i eth0 -p tcp --dport 443 -m state --state NEW -m nth --counter 0 --every 3 --packet 0 -j DNAT --to-destination 192.168.1.101:443
iptables -A PREROUTING -i eth0 -p tcp --dport 443 -m state --state NEW -m nth --counter 0 --every 3 --packet 1 -j DNAT --to-destination 192.168.1.102:443
iptables -A PREROUTING -i eth0 -p tcp --dport 443 -m state --state NEW -m nth --counter 0 --every 3 --packet 2 -j DNAT --to-destination 192.168.1.103:443

9. Erlaube Pingen von Aussen nach Innen

Die folgende Regel erlaubt Benutzern von ausserhalb die Seerver zu Pingen und erhalten im Output auf die Antwort.

iptables -A INPUT -p icmp --icmp-type echo-request -j ACCEPT
iptables -A OUTPUT -p icmp --icmp-type echo-reply -j ACCEPT

10. Erlaube Loopback zugriff

Die eigene 127.0.0.1 Loopback Adresse können wir ebenfalls freischalten. Das ist dann sinnvoll wenn z.B. ein SQL Server auf dem Localhost läuft und mit 127.0.0.1 angesprochen werden soll.

iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

11. Internes Netzwerk zu Externes Netzwerk

Auf einem Server mit zwei Netzwerk Karten ist es möglich wenn eine Netzwerkkarte auf dem Internet Netzwerk hängt und die andere auf dem externen Netzwerk diese Weiterzuleiten (Forwarden).
In diesem Beispiel ist eth1 an das externe Netzwerk (internet) angebungen, und eth0 an das interne Netzwerk (192.168.0.x).

iptables -A FORWARD -i eth0 -o eth1 -j ACCEPT

12. Erlauben von outbound DNS

Die folgende Regel erlaubt ausgehende DNS verbindungen.

iptables -A OUTPUT -p udp -o eth0 --dport 53 -j ACCEPT
iptables -A INPUT -p udp -i eth0 --sport 53 -j ACCEPT

13. Rsync von einem spezifischen Netzwerk erlauben

Die folgende Regel erlaubt rsync Verbindungen von deinem fix definierten Netzwerk.

iptables -A INPUT -i eth0 -p tcp -s 192.168.10.0/24 --dport 873 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -o eth0 -p tcp --sport 873 -m state --state ESTABLISHED -j ACCEPT

14. MySQL Verbindungen nur von einem spezifischen Netzwerk erlauben.

Wenn Sie einen MySQL Server laufen haben, wollen Sie üblicherweise keine direkte Verbindung von ausserhalb erlauben. Den die Verbindungen direkt zum Server erfolgen in der Regel unverschlüsselt und Hacker könnten so einfach an wichtigen Informationen gelangen.
Es ist daher anzuraten das Sie nur direkte verbindungen zu lassen von dem Internen Netzwerk. DBA und Entwickler können den Umweg eines Jumpservers nutzen. Im folgenden Beispiel öffnen wir den Port für MySQL 3306 nur für interne Verbindungen aus dem eignen LAN.

iptables -A INPUT -i eth0 -p tcp -s 192.168.100.0/24 --dport 3306 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -o eth0 -p tcp --sport 3306 -m state --state ESTABLISHED -j ACCEPT

15. Erlauben von Sendmail oder Postfix Traffic

Die folgende Regel erlaubt den Datenverkehr auf Port 25 für Mailserver wie z.B. Sendmail oder Postfix.

iptables -A INPUT -i eth0 -p tcp --dport 25 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -o eth0 -p tcp --sport 25 -m state --state ESTABLISHED -j ACCEPT

16. Erlauben von IMAP und IMAPS Verbindungen

Die folgende Regel erlaubt den Datenverkehr auf Port 143 und 993 für IMAP (143) und IMAPS (993) Verbindungen.

iptables -A INPUT -i eth0 -p tcp --dport 143 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -o eth0 -p tcp --sport 143 -m state --state ESTABLISHED -j ACCEPT
iptables -A INPUT -i eth0 -p tcp --dport 993 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -o eth0 -p tcp --sport 993 -m state --state ESTABLISHED -j ACCEPT

17. Erlauben von POP3 und POP3S Verbindungen

Die folgende Regel erlaubt den Datenverkehr auf Port 110 und 995 für POP3 (110) und POP3S (995) Verbindungen.
iptables -A INPUT -i eth0 -p tcp --dport 110 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -o eth0 -p tcp --sport 110 -m state --state ESTABLISHED -j ACCEPT

iptables -A INPUT -i eth0 -p tcp --dport 995 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -o eth0 -p tcp --sport 995 -m state --state ESTABLISHED -j ACCEPT

18. Vorbeugen einer DoS Attacke

Die folgende Regel hilft ihnen einen Denial of Service (DoS) auf ihren Webserver abzufangen.

iptables -A INPUT -p tcp --dport 80 -m limit --limit 25/minute --limit-burst 100 -j ACCEPT

In dem Beispiel darüber geschieht folgendes:

  • -m limit: Benutzt die limit iptables erweiterung
  • –limit 25/minute: Stellt die limits auf ein maximum von 25 Verbindungen pro Minute. Ändern Sie den Wert je nach ihren Bedürfnissen.
  • –limit-burst 100: Dieser Wert gibt an wie viele Verbindungen gleichzeitig geöffnet werden dürfen innerhalb des Zeitraumes

19. Port Forwarding / Port Weiterleitung

Das folgende Beispiel zeigt wie man den Traffic auf einen anderen Port am selben Server umleiten kann. So ist z.B. dann eine SSH Verbindung über den Port 422 erreichbar obwohl er in Wirklichkeit auf Port 22 lauscht.

iptables -t nat -A PREROUTING -p tcp -d 192.168.10.2 --dport 422 -j DNAT --to 192.168.10.2:22

Natürlich müssen Sie nun auch den Port 422 freigeben um auf diesen Port zugreifen zu können. Eine Freigabe des Ports 22 ist dann nicht mehr Notwendig von extern.
iptables -A INPUT -i eth0 -p tcp --dport 422 -m state --state NEW,ESTABLISHED -j ACCEPT

iptables -A OUTPUT -o eth0 -p tcp --sport 422 -m state --state ESTABLISHED -j ACCEPT

20. Protokollieren / Loggen von Paketen welche übersprungen wurden. (Dropped Packets)

Diese Regel sollte ganz zum Schluss kommen um die übersprungenen Pakete zu Loggen / Protokollieren.
Zuerst erstellen wir eine neue Regel die "LOGGING" heißt.

iptables -N LOGGING

Als nächstes stellen wir sicher das alle Verbindungen die LOGGING Regeln durchlaufen um Sie später nach übersprungenen Paketen zu durchsuchen.

iptables -A INPUT -j LOGGING

Nun spezifizieren wir die Pakete mit einem log-prefix auf dem log-level 7 und filtern diese.

iptables -A LOGGING -m limit --limit 2/min -j LOG --log-prefix "IPTables Packet Dropped: " --log-level 7

Zu guter letzt werden die IPs dieser Pakete nun gesperrt.
iptables -A LOGGING -j DROP

Paperless - Readme


Features

Paperless, a history

Paperless-ngx is the official successor to the original Paperless & Paperless-ng projects and is designed to distribute the responsibility of advancing and supporting the project among a team of people. Consider joining us!

Further discussion of the transition between these projects can be found at ng#1599 and ng#1632.

Screenshots

Paperless-ngx aims to be as nice to use as it is useful. Check out some screenshots below.

![image](assets/screenshots/dashboard.png)
The dashboard shows saved views which can be sorted. Documents can be uploaded with the button or dropped anywhere in the application.

The document list provides three different styles to browse your documents.

grafik.png


grafik.png


grafik.png

Use the 'slim' sidebar to focus on your docs and minimize the UI.
![image](assets/screenshots/documents-smallcards-slimsidebar.png)

Of course, Paperless-ngx also supports dark mode:

grafik.png


Quickly find documents with extensive filtering mechanisms.
![image](assets/screenshots/documents-filter.png)

And perform bulk edit operations to set tags, correspondents, etc. as well as permissions.
![image](assets/screenshots/bulk-edit.png)

Side-by-side editing of documents.

grafik.png

Support for custom fields.

grafik.png

A robust permissions system with support for 'global' and document / object permissions.

grafik.png

Searching provides auto complete and highlights the results.

grafik.png

Tag, correspondent, document type and storage path editing.

grafik.png


grafik.png

{: style="width:21%; margin-left: 4%; float: left"}

grafik.png


grafik.png



Mail rules support various filters and actions for incoming e-mails.

grafik.png

Workflows provide finer control over the document pipeline and trigger actions.

grafik.png



Mobile devices are supported.

grafik.png


grafik.png


grafik.png


Support

Community support is available via GitHub Discussions and the Matrix chat room.

Feature Requests

Feature requests can be submitted via GitHub Discussions where you can search for existing ideas, add your own and vote for the ones you care about.

Bugs

For bugs please open an issue or start a discussion if you have questions.

Contributing

People interested in continuing the work on paperless-ngx are encouraged to reach out on GitHub or the Matrix chat room. If you would like to contribute to the project on an ongoing basis there are multiple teams (frontend, ci/cd, etc) that could use your help so please reach out!

Translation

Paperless-ngx is available in many languages that are coordinated on Crowdin. If you want to help out by translating paperless-ngx into your language, please head over to the Paperless-ngx project at Crowdin, and thank you!

Scanners & Software

Paperless-ngx is compatible with many different scanners and scanning tools. A user-maintained list of scanners and other software is available on the wiki.

Footnotes

  1. Office document and email consumption support is optional and provided by Apache Tika (see configuration) 2

Debian Multimedia Repo

Programme wie avidemux, kodi, vlc oder obs sind nicht immer (oder nicht in aktueller Version) im Standard-Repository von Debian. Hier eine kleine Anleitung um das Repo von deb-multimedia.org einzubinden.

Als erstes laden fügen wir uns den benötigten GPG-Key hinzu:

wget http://www.deb-multimedia.org/pool/main/d/deb-multimedia-keyring/deb-multimedia-keyring_2016.8.1_all.deb
sudo dpkg -i deb-multimedia-keyring_2016.8.1_all.deb

Jetzt noch das Repository (in diesem Fall für Debian bullseye):

echo "deb https://www.deb-multimedia.org bullseye main non-free" | sudo tee /etc/apt/sources.list.d/deb-multimedia.list

Linux Page Cache


Der Page Cache unter Linux beschleunigt zahlreiche Lese-Zugriffe von Dateien. Dies geschieht, indem Linux Daten beim erstmaligen Lesen von oder Schreiben auf Datenträgern wie Festplatten zusätzlich in ungenutzten Bereichen des Arbeitsspeichers cacht. Werden diese Daten später erneut gelesen, können diese schnell aus dem Arbeitsspeicher gelesen werden. Dieser Artikel liefert wertvolle Hintergrundinformationen zum Page Cache.

Page Cache oder Buffer Cache

Oft wird für den Page Cache noch der Begriff Buffer Cache verwendet. Bei Linux Kerneln bis Version 2.2 gab es sowohl einen Page Cache, als auch einen Buffer Cache. Mit Kernel 2.4 wurden diese beiden Caches vereint. Heute gibt es nur noch einen Cache, den Page Cache.[1]

Funktionsweise

Auslastung

Unter Linux gibt das Kommando free -m in der Spalte cached an, wieviel MB des Arbeitsspeichers momentan für den Page Cache verwendet werden:

[root@testserver ~]# free -m
             total       used       free     shared    buffers     cached
Mem:         15976      15195        781          0        167       9153
-/+ buffers/cache:       5874      10102
Swap:         2000          0       1999
[root@testserver ~]# 

Schreiben

Wenn Daten geschrieben werden, kommen diese zuerst in den Page Cache und werden dort als Dirty Pages verwaltet. Dirty deshalb, weil diese Daten zwar im Page Cache liegen, aber erst auf das darunterliegende Speichergerät geschrieben werden müssen. Der Inhalt dieser Dirty Pages wird regelmäßig (bzw. auch beim Aufruf von Systemcalls wie sync oder fsync) auf das darunterliegende Speichergerät weitergegeben. Dies kann in letzter Instanz etwa ein RAID-Controller oder direkt eine Festplatte sein.

Das folgende Beispiel zeigt die Erstellung einer 10 MByte großen Datei, die zuerst in den Page Cache geschrieben wird. Der Umfang der Dirty Pages steigt dadurch, bis diese in diesem Fall manuell per sync Kommando auf die darunterliegende SSD geschrieben werden:

wfischer@pc:~$ dd if=/dev/zero of=testfile.txt bs=1M count=10
10+0 records in
10+0 records out
10485760 bytes (10 MB) copied, 0,0121043 s, 866 MB/s
wfischer@pc:~$ cat /proc/meminfo | grep Dirty
Dirty:             10260 kB
wfischer@pc:~$ sync
wfischer@pc:~$ cat /proc/meminfo | grep Dirty
Dirty:                 0 kB

bis Kernel 2.6.31: pdflush

Bis inklusive Linux Kernel 2.6.31 sorgten die pdflush Threads dafür, dass Dirty Pages regelmäßig auf die darunterliegenden Speichergeräte geschrieben wurden.

ab Kernel 2.6.32: Per-backing-device based writeback

Da pdflush einige Performance-Nachteile hatte, entwickelte Jens Axboe für den Linux Kernel 2.6.32 einen neuen effektiveren writeback Mechanismus.[2]

Dabei gibt es nun Threads für jedes Gerät, wie folgendes Beispiel eines Rechners mit einer SSD (/dev/sda) und einer Festplatte (/dev/sdb) zeigt:

root@pc:~# ls -l /dev/sda
brw-rw---- 1 root disk 8, 0 2011-09-01 10:36 /dev/sda
root@pc:~# ls -l /dev/sdb
brw-rw---- 1 root disk 8, 16 2011-09-01 10:36 /dev/sdb
root@pc:~# ps -eaf | grep -i flush
root       935     2  0 10:36 ?        00:00:00 [flush-8:0]
root       936     2  0 10:36 ?        00:00:00 [flush-8:16]

Lesen

Nicht nur beim Schreiben, auch beim Lesen von Dateien kommen Dateiblöcke in den Page Cache. Wenn Sie z.B. eine 100 MB Datei zweimal hintereinander lesen, so wird der zweite Zugriff schneller sein, da die Dateiblöcke direkt aus dem Page Cache im Arbeitsspeicher kommen und nicht mehr erneut von der Festplatte gelesen werden müssen. Das folgende Beispiel zeigt, dass nach der Wiedergabe eines gut 200 MB großen Videos die Größe des Page Caches angestiegen ist:

user@adminpc:~$ free -m
             total       used       free     shared    buffers     cached
Mem:          3884       1812       2071          0         60       1328
-/+ buffers/cache:        424       3459
Swap:         1956          0       1956
user@adminpc:~$ vlc video.avi
[...]
user@adminpc:~$ free -m
             total       used       free     shared    buffers     cached
Mem:          3884       2056       1827          0         60       1566
-/+ buffers/cache:        429       3454
Swap:         1956          0       1956
user@adminpc:~$

Benötigt Linux mehr Arbeitsspeicher für normale Applikationen als aktuell frei ist, werden bereits länger nicht mehr genutzte Bereiche des Page Caches automatisch gelöscht.

Page Cache optimieren

Das automatische Caching von Dateiblöcken im Page Cache ist meistens sehr vorteilhaft. Manche Daten (etwa Logfiles oder MySQL-Dumps) werden aber oft nach dem Schreiben nicht mehr benötigt. Solche Dateiblöcke belegen also oft unnötig Platz im Page Cache. Andere Dateiblöcke, deren Caching mehr Vorteile bringen würde, fliegen durch die neuen Logfiles oder MySQL aus dem Page Cache hinaus.[3]

Bei Logdateien hilft Ihnen hier etwa ein regelmäßiges Logrotate mit gzip Kompromierung. Wenn eine Logdatei mit beispielsweise 500 MB durch logrotate und gzip auf 10 MB komprimiert wird, wird die ursprüngliche Logdatei und somit auch deren Cache ungültig. 490 MB im Page Cache werden dadurch frei. Die Gefahr, dass eine kontinuierlich wachsenende Logdatei dadurch sinnvollere Dateiblöcke aus dem Page Cache "hinausschiebt" sinkt somit.

Es macht also durchaus Sinn, wenn manche Anwendungen bestimmte Dateien/Dateiblöcke gar nicht cachen würden. Für rsync gibt es dazu auch bereits einen Patch.[4]

Rechte im Dateisystem mehr als nur r,w,x

Erfahren Sie, wie Sie einfacher Verzeichnisstrukturen für Mitarbeiter bereitstellen und diese mit den benötigten Rechten und ACLs versehen können.

Stefan Kania 08. September 2015

image.png


© depositphotos.com / olly18

Jeder der schon mal mit Linux auf der Kommandozeile gearbeitet hat und dort administrativ tätig war, kennt diese drei Buchstaben: "rwx" und das pro Eintrag im Dateisystem dreimal. Die Dateisystemberechtigungen! Aber was verbirgt sich noch hinter dem Begriff "Dateisystemberechtigungen"? Weit mehr als nur die drei Berechtigungen "read", "write" und "execute". Mit diesem Artikel werde ich weitere Facetten der Dateisystemberechtigungen wie "special Bits", "Access Control Lists" und "erweiterte Attribute" ansprechen.

Immer wieder höre ich in den Grundlagenseminaren zu Linux von Teilnehmern, dass man mit den drei einfachen Rechten "read", "write" und "execute" nicht viel anfangen kann. Dass komplexe Abbildungen von Zugriffsrechten unter Windows viel besser seien. Wo reicht es denn heute noch aus, dass man nur einem Benutzer und einer Gruppe Rechte an einem Verzeichnis oder einer Datei geben kann? Aber nicht nur Einsteiger, auch so mancher Admin stößt immer wieder an seine Grenzen.

Ich will in diesem Artikel nicht nur erklären, wie die Rechte funktionieren, was man mit den Rechten alles machen kann, sondern ich will auch praktische Tipps geben, die vielleicht das Leben mit den Dateisystemrechten etwas angenehmer machen können. Neben den bekannten Dateisystemrechten gehören auch noch die "special Bits", die "Access Contol Lists (ACL)" und die erweiterten Attribute in ein gut geplantes Berechtigungskonzept. Auch diese Themen werde ich in diesem Artikel ansprechen.

Die altbekannten Buchstaben "r","w","x"

Im Schnelldurchlauf will ich hier noch mal die Rechte "read", "write" und "execute" erklären, wobei ich dabei auch die unterschiedlichen Bedeutungen der Rechte an Dateien und Verzeichnissen erläutern werde:

  • read
    Das "read"-Recht an einer Datei bedeutet, die Datei kann zum Lesen geöffnet werden. Der Anwender der dieses Recht hat, kann den Inhalt lesen, aber nicht verändern. Das "read"-Recht an einem Verzeichnis erlaubt es, dass ein Anwender sich den Inhalt des Verzeichnisses mit "ls" anzeigen lassen kann.
  • write
    Das "write"-Recht an einer Datei erlaubt es dem Anwender, den Inhalt einer Datei zu verändern. Er hat dadurch nicht das Recht, den Dateinamen zu ändern oder gar eine Datei zu löschen. Erst wenn ein Anwender das "write"-Recht an einem Verzeichnis hat, kann er die Einträge im Verzeichnis löschen, umbenennen und neue Einträge erstellen. Die Vergabe des "write"-Rechts an einem Verzeichnis sollte daher immer gut überlegt sein. Das Recht erlaubt es einem Anwender, alle Einträge in dem Verzeichnis zu löschen, auch wenn er an den Einträgen selbst keine Rechte hat. In allen heutigen Unix/Linux-Systemen muss der Anwender aber alle drei Rechte besitzen, um Einträge löschen, umbenennen oder erstellen zu können.
  • execute
    Das "execute"-Recht erlaubt es einem Anwender, eine Datei auszuführen. Auf Binärdateien und Shell-Skripte muss immer das "execute"-Recht gesetzt sein, damit ein Anwender das Programm oder Shell-Skript ausführen kann. Hat ein Anwender das "execute"-Recht an einem Verzeichnis, kann er mit dem Kommando "cd" in das Verzeichnis wechseln.

user, group, other

Neben den Rechten selbst gibt es dann noch die Zuordnung der Rechte. Es gibt drei Berechtigungszuordnungen: Da wäre als erstes der Besitzer einer Datei (user), dann die besitzende Gruppe (group) und abschließend noch der Rest der Welt (other). Jeder dieser Berechtigungszuordnungen können die Rechte "read", "write" und "execute" zugeordnet werden. Ein Anwender kann aber immer nur die Rechte über eine der Berechtigungszuordnungen erhalten. Er ist also entweder der Besitzer einer Datei, dann erhält er die Rechte von "user", oder er ist Mitglied der besitzenden Gruppe, dann erhält er die Rechte von "group". Wenn er weder Besitzer noch Mitglied der besitzenden Gruppe ist, erhält er immer die Rechte von "other". Sie sehen schon, Rechte über "other" zu vergeben ist keine gute Lösung, da Sie den Zugriff auf Dateisystemeinträge nicht wirklich steuern können.

Immer alles Oktal

Systeme können nichts mit Buchstaben wie "r", "w" oder "x" anfangen, Systeme benötigen Zahlen und die am besten im Binärformat. Deshalb werden die Berechtigungen intern in Binärwerten mit drei Stellen abgebildet. Daraus entstehen dann die Oktalwerte für die Rechte wie Sie sie in der Tabelle sehen können. Egal ob für "user", "group" oder "other" – die Rechte haben dabei die folgenden Wertigkeiten:

Recht    Binärwert    Oktalwert
-------- ------------ ----------------
read      2^2          4    
write     2^1          2
execute   2^0          1

Werden also alle Rechte an eine Berechtigungszuordnung vergeben, ergibt das einen Oktalwert von "7". Maximal also "777".

Woher kommen die Rechte im Dateisystem?

Wenn Sie eine Datei oder ein Verzeichnis anlegen, haben diese Einträge bereits Berechtigungen, aber wo kommen diese Berechtigungen her? Eine Vererbung wie Sie sie von Windows her kennen gibt es unter Linux nicht. Hier ist die "umask" für die Vergabe der Berechtigungen eines neuen Eintrags im Dateisystem verantwortlich. Sie können sich die Umask mit dem gleichnamigen Kommando anzeigen lassen. Hier ein Beispiel:

stefan@stefan:~% umask
022

Die drei Stellen der Umask stehen hier für eine Berechtigungszuordnungen. Die erste Stelle für "user", die zweite für "group" und die dritte für "other". Die Umask zeigt an, welche Rechte beim Anlegen eines neuen Eintrags im Dateisystem NICHT vergeben werden. Der Besitzer erhält immer alle Rechte, die besitzenden Gruppe alles außer dem Schreibrecht, genau wie der Rest der Welt. Das bedeutet in der Standardeinstellung kann der Rest der Welt immer in alle Verzeichnisse wechseln und sich den Inhalt aller Dateien anzeigen lassen. Jeder Anwender kann über die Kommandozeile die Einstellung der Umask mit dem Kommando "umask <wert>" selbst anpassen. Später in diesem Artikel werde ich noch auf die Planung eines Berechtigungskonzeptes eingehen, dabei werde ich zeigen, wie man die Umask auch systemweit setzen können. Doch sehen wir uns einmal je einen neuen Eintrag für eine Datei und ein Verzeichnis an und vergleichen dieses mit der gesetzten Umask:

stefan@stefan:~% ls -l
insgesamt 4
-rw-r--r-- 1 stefan users    0 Aug  4 11:34 datei1
drwxr-xr-x 2 stefan users 4096 Aug  4 11:34 verzeichnis1

Hier sieht man, dass die Berechtigungen am Verzeichnis mit der Umask übereinstimmen. Der Gruppe und dem Rest der Welt wurde das Schreibrecht nicht vergeben. Der Besitzer hat alle Rechte. Aber was ist mit der Datei? Da fehlt bei allen drei Berechtigungszuordnungen das Execute-Recht. Das ist auch korrekt so! Denn das Betriebssystem überprüft beim Anlegen einer neuen Datei, ob es überhaupt Sinn macht, das Execute-Rechte an der Datei zu setzen. Bei allen nicht-binär-Dateien macht das Setzen des Execute-Rechts auch keinen Sinn, also setzt das System das Recht auch nicht. Nur wenn Sie einen Quellcode kompilieren und dabei eine ausführbare Datei entsteht, dann wird auch das Execute-Recht entsprechend der Umask gesetzt.

Wie werden Rechte gesetzt?

Nach dem Sie jetzt eine Einführung zu den Rechten erhalten haben, will ich jetzt erklären, wie die Rechte gesetzt werden und wer alles Rechte setzen kann. Auch das Ändern der besitzenden Gruppe und des Besitzer will ich in diesem Abschnitt erklären.

Die Rechte an einem Eintrag können immer vom "root" und dem Besitzer einer Datei geändert werden. Zum Ändern der Rechte wird das Kommando "chmod" verwendet. Das Kommando "chmod" kann dabei auf zwei verschiedene Arten angewendet werden: Einmal gibt es die relative Vergabe der Berechtigungen, bei der immer die derzeitige Berechtigung geändert wird. Dann gibt es noch die absolute Vergabe der Berechtigungen, bei der der komplette Satz an Berechtigungen für alle Berechtigungszuordnungen neu erstellt wird.

Relative Vergabe der Rechte im Dateisystem

Bei der relativen Vergabe der Berechtigungen können Sie jedes einzelne Recht für sich vergeben. Hier sehen Sie einige Beispiele:

  stefan@stefan:~% chmod u+x datei1 
  stefan@stefan:~% ls -l datei1  
  -rwxr--r-- 1 stefan users 0 Aug  4 11:34 datei1

  stefan@stefan:~% chmod g-r,o-r datei1 
  stefan@stefan:~% ls -l datei1
  -rwx------ 1 stefan users 0 Aug  4 11:34 datei1

  stefan@stefan:~% chmod a+r datei1
  stefan@stefan:~% ls -l datei1    
  -rwxr--r-- 1 stefan users 0 Aug  4 11:34 datei1
  
  stefan@stefan:~% chmod a+rx datei1
  stefan@stefan:~% ls -l datei1 
  -rwxr-xr-x 1 stefan users 0 Aug  4 11:34 datei1

Wie Sie an den Beispielen sehen, können Sie jedes Recht einzeln setzen. Wenn Sie ein Recht zum Beispiel mit "chmod u+x datei1" ändern wollen, aber der Besitzer bereits das Execute-Recht an der Datei hat, ändert sich nichts. Auch sehen Sie in den Beispielen, dass Sie mit der Option "a+r" oder "a-r" ein oder mehrere Rechte für alle Berechtigungszuordnungen gleichzeitig ändern können.

Absolute Vergabe der Rechte im Dateisystem

Dabei gehen Sie ganz anders vor. Sie überlegen sich, welche Rechte Sie für alle drei Berechtigungszuordnungen vergeben wollen, diese rechnen Sie dann in den entsprechenden dreistelligen Oktalwert um und vergeben dann die Rechte für den Eintrag komplett neu. Als Beispiel:

  stefan@stefan:~% ls -l datei1
  -rwxr-xr-x 1 stefan users 0 Aug  4 11:34 datei1
  
  stefan@stefan:~% chmod 600 datei1
  stefan@stefan:~% ls -l datei1
  -rw------- 1 stefan users 0 Aug  4 11:34 datei

Hier spielt es keine Rolle, welche Rechte vorher auf dem Eintrag gesetzt waren, alle Rechte werden überschrieben.

Ändern der besitzenden Gruppe

Die besitzende Gruppe kann sowohl vom "root" als auch vom Besitzer eines Eintrags geändert werden. Wobei es für den Besitzer eine Einschränkung gibt: Er kann einen Eintrag des Dateisystems nur an Gruppen übergeben, in denen er auch Mitglied ist. Für die Änderung der besitzenden Gruppe verwenden Sie das Kommando "chgrp". Das Beispiel zeigt, wie der Gruppenbesitz geändert wird:

stefan@stefan:~% chgrp cdrom datei1 
stefan@stefan:~% ls -l datei1 
-rw------- 1 stefan cdrom 0 Aug  4 11:34 datei1

Ändern des Besitzers

Den Besitzer eines Eintrages im Dateisystem - gleich ob Datei oder Verzeichnis - kann nur der "root" ändern. Mit dem Kommando "chown" kann der "root" nicht nur den Besitzer ändern, sondern auch gleichzeitig die besitzenden Gruppe. Auch hierfür einige Beispiele:

root@stefan:~# chown stka datei1
root@stefan:~# ls -l datei1 
-rw------- 1 stka cdrom 0 Aug  4 11:34 datei1

root@stefan:~# chown stefan:users datei1
root@stefan:~# ls -l datei1             
-rw------- 1 stefan users 0 Aug  4 11:34 datei1

Wie Sie sehen, wurde dieser Vorgang als Benutzer "root" durchgeführt.

Special Bits

Bis zu diesem Punkt ist das Thema für viele von Ihnen mehr oder weniger bekannt. Jetzt kommt die erste Erweiterung der Berechtigungen. In den letzten Abschnitten habe ich immer von drei Oktalgruppen für die Berechtigungen gesprochen. Aber es gibt vier dieser Gruppen. Vor den eigentlichen Dateisystemberechtigungen steht eine vierte Gruppe bestehend aus drei Bits, die zusätzliche Rechte geben oder auch Rechte nehmen kann. Die folgende Tabelle zeigt eine Übersicht der Bits:

Rechte      Binärwerte  Oktalwert
------------------------------------------
SUID         2^2        4
SGID         2^1        2
Sticky Bit    2^0        1 

Das SUID-Bit

Werfen wir doch einmal einen Blick auf die Rechte die an der Datei "/etc/shadow" vergeben sind:

stefan@stefan:~% ls -l /etc/shadow
-rw-r----- 1 root shadow 1360 Mai 27 08:52 /etc/shadow

Da sehen Sie, dass der "root" Lese- und Schreibrecht hat und die Gruppe "shadow" nur das Leserecht. In dieser Datei befinden sich die Passwortinformationen aller Benutzer des lokalen Systems. Nur aufgrund der Rechte an der Datei sieht es so aus, als hätte ein "normaler" Benutzer keine Rechte an dieser Datei. In dieser Datei befindet sich aber das Passwort eines jeden Benutzers. Ein Benutzer kann aber sein Passwort mit dem Kommando "passwd" ändern und greift damit schreibend auf die Datei zu. Wie kann das sein? Schauen wir deshalb mal auf die Berechtigungen des Programms "/usr/bin/passwd":

stefan@stefan:~% ls -l /usr/bin/passwd 
-rwsr-xr-x 1 root root 47032 Jul 15 21:29 /usr/bin/passwd

Da fällt auf, dass an der Stelle, wo sonst beim Besitzer ein "x" steht, jetzt ein "s" steht. Dieses kleine "s" zeigt an, dass das SUID-Bit gesetzt ist. Was passiert jetzt, wenn ein "normaler" Benutzer das Programm "passwd" aufruft um sein Passwort zu ändern? Das System prüft, ob der Benutzer das Recht hat, das Programm zu starten. Da der Benutzer über "other" die Rechte "r-x" besitzt, kann der Benutzer das Programm aufrufen. Jetzt prüft das System zusätzlich, ob das SUID-Bit gesetzt ist. Ist das der Fall, wie bei dem Programm "passwd", erhält der Benutzer ein ZUSÄTZLICHE UID, nämlich die UID des Besitzers des Programms. Damit hat der Benutzer für die Laufzeit des Programms zwei UIDs, seine
eigene und die des "root". Da der "root" Schreibrechte an der Datei "/etc/passwd" hat, kann der Benutzer jetzt sein Passwort ändern. Programme, bei denen das SUID-Bit gesetzt ist, lassen sich nicht im Hintergrund starten. Das wäre auch fatal, da dann der Benutzer im Vordergrund "root"-Rechte hätte.

Das Setzen des SUID-Bits ist nur sinnvoll auf Binärdateien. Das Recht können Sie mit dem Kommando "chmod u+s <Programm>" setzen und entfernen mit "chmod u-s <Programm>". Damit das SUID-Bit genutzt werden kann, muss auch immer für den
Besitzer das "x"-Bit gesetzt sein. Da nach dem Setzen des SUID-Bits an der Stelle des "x" jetzt immer ein "s" steht, können Sie das gesetzte "x"-Bit daran erkennen, dass es sich bei dem "s" um ein kleines "s" handelt. Würde an der Stelle ein großes "S" stehen, wäre das "x"-Bit nicht gesetzt.

Das SGID-Bit

Mit dem SGID-Bit können Sie die Verwaltung der Rechtestruktur in Ihrem Dateisystem beeinflussen. Normalerweise gibt es bei Linux keine Vererbung der Berechtigungen im Dateisystem, aber durch den Einsatz des SGID-Bits können Sie das in einem bestimmten Rahmen ändern. Wenn Sie an einem Verzeichnis das SGID-Bit setzen, wird ab diesem Zeitpunkt jeder neue Eintrag unterhalb des Verzeichnisses immer der Gruppe gehören, die in diesem Verzeichnis als besitzende Gruppe eingetragen ist. Das SGID-Bit vererbt sich auch auf alle neu erstellten Unterverzeichnisse, die nach dem Setzen des SGID-Bits erzeugt werden. Wenn Sie auf Ihrer Verzeichnisstruktur das SGID-Bit an den einzelnen Abteilungsverzeichnissen setzen, gehören anschließend alle Einträge der entsprechenden Gruppe, ohne dass ein Benutzer seine Standardgruppe ändern müsste. Zusammen mit einer angepassten Umask können Sie dann bestimmte Verzeichnisse gezielt einer Gruppe zuordnen und die Rechte bestimmen. Mehr dazu folgt später im praktischen Teil dieses Artikels.

Der Einsatz des SGID-Bits ist nur sinnvoll, wenn es auf Verzeichnisse gesetzt wird. Es wird mit dem Kommando "chmod g+s <Verzeichnis>" gesetzt. Hier ein Beispiel:

stefan@stefan:~% chmod g+s verzeichnis1 
stefan@stefan:~% ls -ld verzeichnis1
drwxr-sr-x 2 stefan users 4096 Aug  4 11:34 verzeichnis1
stefan@stefan:~% chgrp cdrom verzeichnis1 
stefan@stefan:ueb~% cd verzeichnis1 
stefan@stefan:~/verzeichnis1% mkdir verzeichnis1a
stefan@stefan:~/verzeichnis1% ls -ld verzeichnis1a 
drwxr-sr-x 2 stefan cdrom 4096 Aug  4 17:31 verzeichnis1a

Hier sehen Sie, dass das neue Verzeichnis der neu zugeordneten Gruppe "cdrom" gehört und das SGID-Bit am Verzeichnis "verzeichnis1" gesetzt wurde. Auch das neue Unterverzeichnis "verzeichnis1/verzeichnis1a" hat das SGID-Bit gesetzt.

Das Sticky-Bit

Der Name dieses Bits stammt von seiner ursprünglichen Bedeutung. Wurde dieses Bit auf ein ausführbares Programm vom "root" gesetzt, dann blieb das Programm nach Beendigung im Arbeitsspeicher "kleben". Beim nächsten Aufruf wurde das Programm dann direkt aus dem Arbeitsspeicher gestartet. Dadurch wurde der Startvorgang des Programms beschleunigt. Linux nutzt das Sticky-Bit aber anders. Wenn Sie das Sticky-Bit an einem Verzeichnis setzen, kann nur noch der Besitzer einer Datei in dem Verzeichnis diese auch löschen. Auch wenn ein anderer Benutzer am Verzeichnis die Rechte "r,w,x" besitzt, ist er nicht berechtigt eine Datei zu löschen. Das Sticky-Bit macht nur Sinn, wenn es auf Verzeichnissen gesetzt wird. Das Sticky-Bit setzen Sie mit dem Kommando "chmod o+t <Verzeichnis>". Ein Beispiel:

stefan@stefan:~% mkdir verzeichnis2
stefan@stefan:~% chmod g+w,o+t verzeichnis2
stefan@stefan:~% ls -ld verzeichnis2
drwxrwxr-t 2 stefan users 4096 Aug  4 18:02 verzeichnis2

stefan@stefan:~% cd verzeichnis2
stefan@stefan:~/verzeichnis2% touch datei2
stefan@stefan:~/verzeichnis2% ls -l datei2 
-rw-r--r-- 1 stefan users 0 Aug  4 18:04 datei2

stefan@stefan:berechtigungen-ia/verzeichnis2% su stka  
Passwort: 
stka@stefan:/home/stefan/verzeichnis2% rm datei2 
rm: Normale leere Datei (schreibgeschützt) »datei2“ entfernen? y
rm: das Entfernen von »datei2“ ist nicht möglich: Vorgang nicht zulässig

Sie sehen hier, obwohl der Benutzer "stka" alle Rechte am Verzeichnis "verzeichnis2" über die Gruppe "users" (in der er Mitglied ist) erhält, kann er die Datei in dem Verzeichnis nicht löschen. Auch die Meldung ist eine ganz andere, als wenn ihm das Recht fehlen würde. Hier wird jetzt auf Grund des Sticky-Bits der Vorgang untersagt. Das Sticky-Bit ist ein sehr gutes Mittel, um in Verzeichnissen auf die mehrere Benutzer Zugriff haben, ein versehentliches Löschen von Dateien durch Nichtbesitzer zu verhindern. Das Bit schützt aber nicht vor der Veränderung des Inhalts von Dateien.

Die erweiterten POSIX-ACLs

Aber was tun Sie, wenn Sie an einem Verzeichnis unterschiedliche Rechte für unterschiedliche Gruppen vergeben wollen? Diese Aufgabe können Sie nicht mehr mit den einfachen Dateisystemrechten lösen. Dafür benötigen Sie die Access Control Lists (ACL). Hier geht es darum, die Dateisystemrechte zu erweitern. Mithilfe der ACL ist es möglich, dass mehrere Gruppen oder Benutzer an einer Datei oder einem Verzeichnis unterschiedliche Rechte erhalten. Damit Sie die ACLs nutzen können, müssen Sie als Erstes das Dateisystem für die ACL-Unterstützung anpassen. Alle gängigen Dateisysteme wie ext2, ext3, ext4, reiserfs und xfs unterstützen ACLs. Aber die ACLs müssen eventuell beim Mounten des Dateisystems als Option mit angegeben werden. Sie können die entsprechende Option natürlich auch direkt in dem Eintrag der "/etc/fstab" mit angeben, so werden die ACLs auch bei einem Systemstart sofort wieder aktiviert.

Warum nur "eventuell"? Weil bei vielen aktuellen Distributionen die Dateisysteme schon so kompiliert wurden, dass sie ACLs unterstützen. Wenn Sie die in diesem Abschnitt besprochenen Beispiele auf Ihrem System nachvollziehen können, ohne die Datei "/etc/fstab" anpassen zu müssen, dann unterstützt Ihr Dateisystem die ACLs ohne dass Sie weitere Optionen angeben müssen. Sollte das nicht der Fall sein, müssen Sie die Einträge in Ihrer "/etc/fstab" wie folgt anpassen:

/dev/hdb1       /daten               ext4    errors=remount-ro,acl 0       0

Hier wurde für eine Datenpartition die Option "acl" hinzugefügt. Nach einem "remount" mit dem Kommando "mount -o remount,rw /daten" stehen dann auf dieser Partition die ACLs zur Verfügung. Bei den ACLs wird zwischen den einfache ACLs und den default ACLs unterschieden. Zur Verwaltung der ACLs gibt es die Kommandos "setfacl" zum Setzen der ACLs und "getfacl" zum Auslesen der ACLs. Wenn diese Programme auf Ihrem System nicht vorhanden sind, müssen Sie das Paket "acl" nachinstallieren.

Die einfachen ACLs

Einfache ACLs gelten nur für das Verzeichnis oder die Datei, auf die sie angewendet wurden. Die einfachen ACLs werden nicht vererbt. Das folgende Listing zeigt, wie eine ACL auf ein Verzeichnis gesetzt wird:

stefan@stefan:~% mkdir verzeichnis3
stefan@stefan:~% ls -ld verzeichnis3
drwxr-xr-x 2 stefan users 4096 Aug  4 18:51 verzeichnis3

stefan@stefan:~% setfacl -m g:cdrom:rx verzeichnis3
stefan@stefan:~% ls -ld verzeichnis3
drwxr-xr-x+ 2 stefan users 4096 Aug  4 18:51 verzeichnis3

stefan@stefan:~% getfacl verzeichnis3
# file: verzeichnis3
# owner: stefan
# group: users
user::rwx
group::r-x
group:cdrom:r-x
mask::r-x
other::r-x

Im ersten Teil des Beispiels wird ein neues Verzeichnis angelegt und die Rechte aufgelistet. Im zweiten Teil wird dann mit dem Kommando "setfacl -m g:cdrom:rx verzeichnis3" ein ACL gesetzt. Die einzelnen Parameter haben dabei die folgende Bedeutung:

  • -m
    Mit dieser Option "-m" wird das Kommando "setfacl" angewiesen, die ACL eines Eintrages zu modifizieren.
  • - g:cdrom:rx verzeichnis3
    Eine Gruppe (bestimmt durch den Parameter "g") "cdrom" erhält die Rechte "rx" am "verzeichnis3"

Die Reihenfolge der Parameter muss dabei eingehalten werden.

Im dritten Teil werden die Rechte des Verzeichnisses "verzeichnis3" nochmal aufgelistet. Hier sehen Sie, dass nach den Rechten jetzt ein "+" zu sehen ist. Dieses "+" weist darauf hin, dass an dem Eintrag im Dateisystem ACLs gesetzt sind. Dann wird die ACL des Verzeichnisses "verzeichnis3" aufgelistet. Hier sehen Sie jetzt, dass neben der Gruppe "users" die Gruppe "cdrom" Rechte erhalten hat.

ACHTUNG: Wenn Sie auf einem Eintrag im Dateisystem – egal ob bei einem Verzeichnis oder einer Datei – eine ACL gesetzt haben, dürfen Sie von dem Moment an keine Berechtigungen mehr mit dem Kommando "chmod" ändern. Denn dann ändern Sie nicht mehr die Rechte sondern nur eine ACL-Maske. Diese Maske kann nur Rechte ausfiltern. Sprich: ein Recht, das dort nicht gesetzt ist, kann auch keine Gruppe oder Benutzer erhalten.

Um das Verhalten zu verdeutlichen, folgt hier ein Beispiel:

stefan@stefan:~% chmod g-r verzeichnis3
stefan@stefan:~% getfacl verzeichnis3  
# file: verzeichnis3
# owner: stefan
# group: users
user::rwx
group::r-x                      #effective:--x
group:cdrom:r-x                 #effective:--x
mask::--x
other::r-x

Hier sehen Sie, dass die Gruppen nur noch das effektive Recht "x" besitzen, durch die Maske wird das "r"-Recht ausgefiltert. Wenn das Recht mit "chmod" wieder zurückgesetzt wird, wird auch die Maske wieder zurückgesetzt. Was passiert aber, wenn die besitzende Gruppe (so wie im Beispiel) nur die Rechte "r-x" besitzt und Sie für eine andere Gruppe die Rechte "rwx" setzen wollen? Denn in der Standardberechtigung fehlt ja das "w"-Recht. Da es sich bei den Berechtigungen aber um einen Filter handelt, müsste das "w"-Recht auch für eine andere Gruppe nicht wirksam sein. Aber das ist nicht so, wie das folgende Listing zeigt:

stefan@stefan:~% setfacl -m g:cdrom:rwx verzeichnis3
stefan@stefan:~% getfacl verzeichnis3           
# file: verzeichnis3
# owner: stefan
# group: users
user::rwx
group::r-x
group:cdrom:rwx
mask::rwx
other::r-x

Obwohl die besitzende Gruppe nur die Rechte "r-x" besitzt, hat die Gruppe "cdrom" alle Rechte am Verzeichnis. Erst eine nachträgliche Veränderung der Berechtigungsliste verändert die Maske. Selbstverständlich können Sie auch einem einzelnen Benutzer Rechte über ACLs vergeben. Das Listing zeigt diesen Vorgang:

stefan@stefan:~% setfacl -m u:stka:rwx verzeichnis3
stefan@stefan:~% getfacl verzeichnis3
# file: verzeichnis3
# owner: stefan
# group: users
user::rwx
user:stka:rwx
group::r-x
group:cdrom:rwx
mask::rwx
other::r-x

Wenn Sie jetzt in dem Verzeichnis eine neue Datei oder Verzeichnis erstellen, werden Sie feststellen, dass die ACLs nicht auf die neuen Einträge übernommen wurden. Damit die ACLs auf neue Einträge vererbt werden, müssen Sie die "defaults ACLs" an Verzeichnissen setzen.

Die default ACLs

Bis jetzt waren alle ACLs immer nur für den Eintrag gültig, auf dem Sie die ACL gesetzt hatten. Mit den default ACLs können Sie jetzt Berechtigungen auf ein Verzeichnis setzen, die sich dann an alle darunter neu erstellten Einträge vererben. Das Listing zeigt wie Sie default ACLs setzen können:

stefan@stefan:~% mkdir verz-def-acl

stefan@stefan:~% setfacl -d -m  g:cdrom:rwx verz-def-acl

stefan@stefan:~% ls -ld verz-def-acl
drwxr-xr-x+ 2 stefan users 4096 Aug  6 10:57 verz-def-acl

stefan@stefan:~% getfacl verz-def-acl
# file: verz-def-acl
# owner: stefan
# group: users
user::rwx
group::r-x
other::r-x
default:user::rwx
default:group::r-x
default:group:cdrom:rwx
default:mask::rwx
default:other::r-x

Mit der setfacl-Option "-d" erstellen Sie ein default ACL. Wenn Sie sich das Verzeichnis mit "ls" anzeigen lassen, sehen Sie auch hier wieder das Pluszeichen am Ende der Rechteliste, welches auf das Vorhandensein von ACL hinweist. Lassen Sie sich jetzt die ACLs mittels "getfacl" anzeigen, sehen Sie, dass alle ACLs als "default ACLs" eingetragen wurden. Wenn Sie jetzt in dem Verzeichnis ein neues Verzeichnis oder eine neue Datei anlegen, werden diese Einträge die ACLs übernehmen. In nächsten Listing möchte ich Sie noch einmal auf das Verhalten beim Anlegen einer Datei hinsichtlich des x-Rechts aufmerksam machen. In den "default ACLs" ist ja das x-Recht immer mit gesetzt und wird somit auf alle neuen Einträge übernommen. Auch auf Dateien werden diese "default ACLs" gesetzt. Wenn Sie jetzt aber eine leere Datei oder eine Datei einer Anwendung erstellen, vergibt das Betriebssystem das x-Recht nicht an diese Datei. In den ACLs ist es aber gesetzt, deshalb sehen Sie bei dem Aufruf von "getfacl" den Hinweis "effective". Das ist kein Fehler, das ist das richtige Verhalten.

stefan@stefan:~% touch dat-acl

stefan@stefan:~% getfacl dat-acl 
# file: dat-acl
# owner: stefan
# group: users
user::rw-
group::r-x                      #effective:r--
group:cdrom:rwx                 #effective:rw-
mask::rw-
other::r--

Löschen von ACLs

Sowohl die einfachen, als auch die default ACLs löschen Sie mit dem Kommando "setfacl". Beim Entfernen der ACLs wird zwischen den unterschiedlichen ACLs unterschieden. Sie müssen vor dem Löschen wissen, ob Sie ein einfache oder eine default ACL entfernen wollen. Das folgende Listing zeigt den Vorgang des Löschens einer default ACL:

stefan@stefan:~/verz-def-acl% setfacl -k verz-acl 

stefan@stefan:~/verz-def-acl% getfacl verz-acl 
# file: verz-acl
# owner: stefan
# group: users
user::rwx
group::r-x
group:cdrom:rwx
mask::rwx
other::r-x

stefan@stefan:berechtigungen-ia/verz-def-acl% ls -ld verz-acl 
drwxrwxr-x+ 2 stefan users 4096 Aug  6 11:05 verz-acl

Durch die Option "-k" werden alle default ACLs des Eintrags gelöscht, die einfachen ACLs bleiben erhalten. Mit der Option "-b" löschen Sie die einfachen ACLs:

stefan@stefan:~/verz-def-acl% setfacl -b verz-acl 

stefan@stefan:~/verz-def-acl% ls -ld verz-acl 
drwxr-xr-x 2 stefan users 4096 Aug  6 11:05 verz-acl

Und dann ist da noch das Folgende

Bis zu diesem Zeitpunkt haben wir immer nur ACLs auf einzelne Einträge gesetzt oder entfernt. Selbstverständlich können Sie die ACLs auch rekursiv über einen ganzen Teilbaum setzen oder löschen. Auch ein Sichern der ACLs mittels "getfacl" können Sie rekursiv durchführen und diese Sicherung später mittels "setfacl" wieder einspielen. Das ist besonders dann wichtig, wenn Sie eine Backup-Software einsetzen, die keine ACLs sichern kann. Dann können Sie die ACLs getrennt in eine Datei sichern und anschließend – bei einem eventuellen Recovery des Dateisystems – aus der Datei wieder einspielen. Sowohl das Kommando "setfacl" als auch das Kommando "getfacl" kennen die Option "-R" für das rekursive Löschen oder Anzeigen. Im folgenden Listing sehen Sie ein paar Beispiele für die Verwendung von "setfacl" und "getfacl":

stefan@stefan:~% getfacl -R verz-def-acl

stefan@stefan:~% getfacl -R verz-def-acl > sicherung.acl

stefan@stefan:~% setfacl -R -m g:cdrom:rwx verz-def-acl

stefan@stefan:~% setfacl --restore=sicherung.acl

Im ersten Beispiel werden alle ACLs aller Einträge angezeigt. Im zweiten Beispiel werden die Einträge in eine Datei gesichert. Beim dritten Beispiel werden alle Einträge ab dem angegeben Verzeichnis mit einer ACL belegt. Das vierte Beispiel zeigt dann, wie Sie die ACLs aus einer Datei wieder einspielen können. Wenn Sie jetzt die ACLs in Ihrem Dateisystem anwenden wollen, dann stellen Sie schnell fest, dass Dateien und Verzeichnisse unterschiedliche ACLs benötigen. Zum Beispiel braucht ein Textdokument kein x-Recht, aber ein Verzeichnis benötigt dieses Recht auf jeden Fall, denn sonst kann nicht in das Verzeichnis gewechselt werden. Deshalb können Sie das Kommando "setfacl" sehr gut zusammen mit dem Kommando "find" einsetzen. Im nächsten Listing zeige ich Ihnen, wie Sie für alle Dateien und Verzeichnisse ab einem bestimmten Punkt ACLs setzen können:

stefan@stefan:~% find . -type d -exec setfacl -d -m g:cdrom:rwx {} \;

stefan@stefan:~% find . -type f -exec setfacl -m g:cdrom:r {} \;

Im ersten Beispiel werden alle Verzeichnisse ab dem aktuellen Verzeichnis gesucht und anschließend wird für jedes Verzeichnis die entsprechende default ACL gesetzt. Im zweiten Beispiel wird nach allen Dateien gesucht und die einfache ACL gesetzt. Die Option "-d" darf hier nicht verwendet werden, da sich default ACLs nur auf Verzeichnisse setzen lassen. Verwenden Sie trotzdem die Option "-d", werden für die Dateien Fehlermeldungen ausgeworfen.

Zusammen mit den Berechtigungen, den "special-Bits" und den ACLs stehen Ihnen jetzt eine Vielzahl von Möglichkeiten zur Verfügung, die Rechte in Ihrem Dateisystem gezielt zu setzen.

Die erweiterten Attribute

Auch Linux kennt im Dateisystem erweiterte Attribute mit denen Sie bestimmte Einschränkungen beim Zugriff auf Dateien einrichten können. Diese erweiterten Attribute möchte ich an dieser Stelle vorstellen. Um die Attribute verwenden zu können muss das Dateisystem vorbereitet werden. Denn auch für die Attribute gibt es eine Mountoption, die Sie wieder bei einigen älteren Distributionen in der Datei "/etc/fstab" setzen müssen. Das Listing zeigt Ihnen den angepassten Eintrag in der Datei:

/dev/hdb1       /daten               ext4    errors=remount-ro,acl,user_xattr 0       0

Nach einem "remount" des Dateisystems stehen Ihnen dann die erweiterten Attribute zur Verfügung. Die Attribute setzen Sie mit dem Kommando "chattr". Auflisten können Sie die Attribute mit dem Kommando "lsattr", sollten diese Kommandos auf Ihrem System nicht vorhanden sein, müssen Sie das Paket "attr" nachinstallieren.

Bei den Attributen gibt es zwei Gruppen: Die Attribute der einen Gruppe können von "normalen" Benutzern gesetzt werden, die Attribute der anderen Gruppe können nur vom "root" gesetzt werden. Unter den Attributen gibt es einige, die sowieso selten benötigt werden, diese sollen hier nicht betrachtet werden. Aber einige der Attribute können im täglichen Umgang mit Dateisystemrechten nützlich sein. Diese werden ich Ihnen hier erklären.

Attribute, die jeder setzen kann

  • Das Attribut "d"
    Durch Setzen dieses Attributs verhindern Sie, dass die entsprechende Datei bei einer Datensicherung mit dem Kommando "dump" mitgesichert wird.
  • Das Attribut "s"
    Wenn ein Benutzer dieses Attribut setzt, wird die Datei beim Löschen mit Nullen überschrieben.
  • Das Attribut "A"
    Wenn Sie das Attribut "A" setzen, wird die "atime" der Datei nicht verändert. Das kann die Performance beim Schreiben erhöhen. Besser ist es aber, hier die Option "noatime" für das gesamte Dateisystem in der Datei "/etc/fstab" zu setzen.

Attribute die nur der "root" setzen kann

  • Das Attribut "a"
    Wenn Sie als "root" dieses Attribut auf eine Datei setzen, kann der Inhalt der Datei nicht mehr geändertwerden, es können nur noch Daten an die Datei angehängt werden. Hier sehen Sie dazu ein Beispiel:
      root@stefan:~#  touch datei1.txt root@stefan:~#  chattr +a datei1.txt  root@stefan:~#  lsattr datei1.txt  -----a------------- datei1.txt root@stefan:~#  echo "Eine neue Zeile" > datei1.txt  -bash: datei1.txt: Die Operation ist nicht erlaubt root@stefan:~#  echo "Eine neue Zeile anhängen " >> datei1.txt  

    Mit dem ersten Kommando wird einfach eine leere Datei erzeugt, bei der im zweiten Schritt das Attribut "a" gesetzt wird. Im Anschluss wird versucht, eine Zeile in die Datei mit einer einfachen Umleitung zu schreiben. Diese Operation wird aufgrund des Attributs verboten. Selbst der "root" kann den Inhalt der Datei nicht verändern, solange das Attribute "a" gesetzt ist. Erst im nächsten Schritt wird eine Zeile an die Datei angehängt, und jetzt ist das
    Schreiben in die Datei möglich.

  • Das Attribut "i"

    Durch das Attribut "i" wird die Datei immun gegen das Ändern, Umbenennen und Löschen. Auch der "root" kann eine Datei mit diesem Attribut nicht löschen, ohne vorher das Attribut zurückzusetzen. Auch dazu sehen Sie ein Beispiel: root@stefan:~# chattr +i datei1.txt

      root@stefan:~# lsattr datei1.txt  ----i-------------- datei1.txt root@stefan:~# echo "Eine zweite Zeile anhängen " >> datei1.txt  -bash: datei1.txt: Keine Berechtigung root@stefan:~# ls -l datei1.txt  -rw-r--r-- 1 root stefan 27 27. Jul 18:02 datei1.txt root@stefan:~# rm datei1.txt rm: Entfernen von "datei1.txt" nicht möglich: Die Operation ist nicht erlaubt root@stefan:~# mv datei1.txt datei1a.txt  mv: Verschieben von "datei1.txt" nach "datei1a.txt" nicht möglich: Die Operation ist nicht erlaubt root@stefan:~# chattr -i datei1.txt  root@stefan:~# rm datei1.txt

Alle Aktionen wurden hier als Benutzer "root" durchgeführt. Wie Sie sehen, ist danach keine Aktion mit der Datei mehr möglich. Erst wenn das Attribut von der Datei entfernt wird, kann die Datei wieder gelöscht werden.

Weitere Attribute

Neben diesen Attributen gibt es noch weitere Attribute, die zum Teil experimentell oder nicht von so großer Bedeutung für den täglichen Gebrauch sind. Alle Attribute werden ausführlich in der Manpage zu "chattr" beschrieben. Wenn Sie die Attribute verwenden wollen, sollten Sie immer einen Blick auf diese Manpage werfen, um mögliche Komplikationen zu vermeiden, denn nicht alle Attribute funktionieren in allen Dateisystemen.

Ein praktisches Beispiel

Nach dem im ersten Teil die Grundlagen besprochen wurden, will ich Ihnen jetzt anhand eines Beispiels zeigen, wie Sie die Dateisystemrechte planen können. Natürlich ist es in so einem Artikel nicht möglich, alle Eventualitäten abzudecken, aber eine gewisse Planungsgrundlage kann ich Ihnen hier an die Hand geben. In dem Beispiel werde ich eine Verzeichnisstruktur erstellen, die sich auf ein Unternehmen mit mehreren Abteilungen bezieht, in dem jede Abteilung unterschiedliche Zugriffsrechte auf verschiedene Ordner benötigt. Desweiteren soll ein Verzeichnis für alle Mitarbeiter existieren, das als Austauschverzeichnis für Daten dient und in das alle Mitarbeiter schreiben dürfen, aber nur der Besitzer einer Datei soll diese auch löschen können. Um die Verzeichnisse hier abbilden zu können, werde ich das Kommando "tree" verwenden. Sollte das Kommando bei Ihnen nicht installiert sein, müssen Sie das Paket "tree" nachinstallieren.

Im Beispiel wird alles auf einer lokalen Maschine eingerichtet. In der Praxis werden Sie die Daten auf einem Server verwalten und die Benutzerverwaltung zentral durchführen. Da sich die ACLs und die Dateisystemrechte via NFS auf Clients exportieren lassen, können Sie das Beispiel auch auf einem Fileserver mit einer zentralen Benutzerverwaltung und angebundenen Clients einrichten und testen.

Beschreibung der Umgebung

Die Firma besteht aus drei Abteilungen: Der Verwaltung, der Produktion und der Geschäftsleitung. Jede Abteilung soll ein eigenes Verzeichnis erhalten, in der nur diese Abteilung Schreibrechte haben soll. Die Geschäftsleitung möchte auf allen Abteilungsverzeichnissen das Leserecht haben. Alle Dateien in den Abteilungsverzeichnissen sollen immer der Abteilungsgruppe gehören. Die Rechte aller neuen Einträge sollen immer mit der Umask 007 angelegt werden. Es soll ein Gruppe "mitarbeiter" geben, in der alle Mitarbeiter Mitglied sind. Über die Gruppe sollen die Rechte am Austauschverzeichnis gesteuert werden.

Setzen der Umask

Damit alle Mitarbeiter auf allen Clients die gewünschte Umask von 007 erhalten, müssen Sie, je nach Distribution, entweder direkt die Datei "/etc/profile" oder die Datei "/etc/login.defs" anpassen. Diese Anpassung müssen Sie an jedem Client durchführen.

Einrichten der Verzeichnisstruktur

Um die Berechtigungen gut staffeln zu können, wird ein übergeordnetes Verzeichnis für die Abteilungen eingerichtet. An diesem Verzeichnis erhalten alle Mitarbeiter über die Gruppe "mitarbeiter" die Rechte "rx", damit sie durch das Verzeichnis in das eigentliche Abteilungsverzeichnis wechseln können. Das wäre auf einem Server auch das Verzeichnis, das über NFS an alle Clients freigegeben würde. Das folgende Listing zeigt das Anlegen der Verzeichnisstruktur:

root@stefan:~# mkdir  /abteilungen

root@stefan:~# cd /abteilungen 

root@stefan:/abteilungen# mkdir verwaltung produktion geschaeftsleitung

root@stefan:/abteilungen# mkdir /alle 

Nach dem alle benötigten Verzeichnisse angelegt wurden, zeigt das nächste Listing, wie Sie die entsprechenden Rechte setzen müssen:

root@stefan:/# chmod 750 /abteilungen 

root@stefan:/# chmod 2770 /abteilungen/*

root@stefan:/# chgrp mitarbeiter /abteilungen

root@stefan:/# chgrp verwaltung /abteilungen/verwaltung

root@stefan:/# chgrp produktion /abteilungen/produktion

root@stefan:/# chgrp geschaeftsleitung /abteilungen/geschaeftsleitung

root@stefan:/# tree -p abteilungen
abteilungen
--- [drwxrws---]  geschaeftsleitung
--- [drwxrws---]  produktion
--- [drwxrws---]  verwaltung

root@stefan:/# chgrp mitarbeiter /alle

root@stefan:/# chmod 3770 /alle 

root@stefan:/# ls -ld /alle 
drwxrws--T 2 root mitarbeiter 4096 Aug 10 13:04 /alle

Jetzt kann jede Abteilung in ihrem Verzeichnis Daten speichern. Durch das gesetzte SGID-Bit gehören alle Dateien immer der Abteilungsgruppe. Über "other" werden keine Rechte vergeben. Am Verzeichnis "/alle" haben alle Mitarbeiter die Rechte "rwx". Dadurch können sie Einträge erzeugen und Inhalte ändern. Aber nur die Einträge, die ihnen gehören können sie löschen oder umbenennen. Jetzt fehlt nur noch, dass die Geschäftsleitung an allen anderen Abteilungsverzeichnissen das Leserecht an allen Einträge erhält. Das steuern Sie über die default ACLs an den Verzeichnissen. Das Listing zeigt die entsprechenden
Kommandos:

root@stefan:/# setfacl -d -m g:geschaeftsleitung:rx /abteilungen/verwaltung

root@stefan:/# setfacl -d -m g:geschaeftsleitung:rx /abteilungen/produktion

Jetzt können alle Mitglieder der Gruppe "geschaeftsleitung" in allen Verzeichnissen mindestens lesen. Dadurch, dass die ACLs als default ACLs gesetzt wurden, vererben sich die ACLs immer weiter und auch in neu angelegten Unterverzeichnissen hat die Geschäftsleitung die gewünschten Rechte.

Fazit

Ich hoffe, ich konnte Ihnen mit diesem kleinen Artikel zum Thema Dateisystemberechtigungen etwas helfen, in Zukunft einfacher Verzeichnisstrukturen für Mitarbeiter bereitzustellen und diese mit den benötigten Rechten und ACLs zu versehen.

Upgrade Debian Bookworm zu Trixie

1. Vorbereitungen

Bevor wir ein Upgrade durchführen, sollte das aktuelle System auf den letzten Stand aktualisiert werden. Zusätzlich entfernen wir nicht mehr benötigte Pakete und schaffen somit etwas mehr Platz auf der Festplatte. Alle hier gezeigten Befehle gebe ich als root-User ein. Solltet ihr nicht als root arbeiten, müsst ihr euch mittels vorangestelltem sudo entsprechende Rechte zuweisen. Sollte bei der Update ein neuer Kernel installiert werden, ist ein anschließender Reboot ratsam.

Für ein Upgrade solltet ihr über mindestens 5GB freien Speicher verfügen und ihr solltet auf Debian 12 Bookworm sein. Ein Upgrade von Debian 11 aus geht nicht.

Nun wäre es auch ratsam sich über ein Backup Gedanken zu machen. Ich nutze nur VMs auf einem Proxmox System und erstelle somit vorher ein Backup des Systems unter Proxmox.

apt update && apt dist-upgrade
apt clean
apt autoremove

2. Repositories aktualisieren

Nun ändern wir die Debian Repositories und alles 3rd Party Repositories zu Trixie. Mit folgenden zwei Befehlen lässt sich das einfach bewerkstelligen. Anschließend für ihre in Update der Paketinformationen durch. Sollte es hier zu Fehlern kommen, solltet ihr nochmals eure Source Files kontrollieren. Gerade 3rd Party Repositories können hier Probleme machen. Stellt diese wieder auf Bookworm um, oder deaktiviert sie temporär durch ein vorangestelltes # im entsprechenden Source File .

sed -i 's/bookworm/trixie/g' /etc/apt/sources.list
find /etc/apt/sources.list.d -name "*.list" -exec sed -i 's/bookworm/trixie/g' {} \;
apt update

3. Debian Upgrade auf Trixie

Nun kommen wir zu eigentlichen Upgrade-Prozess. Wir gehen hier den konservativen Weg und machen erst ein Upgrade ohne neue Pakete und eventuellen Abhängigkeitsproblemen aus dem Weg zu gehen. Anschließend führen wir das volle Upgrade durch. Während des Upgrades werdet ihr über Service Neustarts und Konfig-Files Updates informiert. Generell solltet ihr dem Neustart zustimmen und eure bestehende Konfiguration beibehalten, außer ihr habt dafür spezielle Gründe.

apt upgrade --without-new-pkgs
apt full-upgrade

4. Nacharbeit

Wir bereinigen noch die Pakete und führen den abschließenden Reboot durch. Danach solltet ihr erfolgreich auf Debain Trixie upgegraded haben.

apt autoremove
apt autoclean
reboot

Nach dem Neustart kontrollieren wir die installierte Debian Version und überprüfen ob wirklich alle Pakete aktualisiert wurden.

cat /etc/os-release
apt update
apt list --upgradable

Nebenstehend seht ihr das euer System nun auf Debian 13 Trixie läuft.

6. Neue Debian Sources aktivieren in Trixie

Aktuell nicht notwendig aber bereits jetzt empfehlenswert ist die Umstellung der Quellenliste auf das neue deb822 Format. Dafür gibt es ein Tool, welche eure Quellenlisten umstellt, bzw. euch dabei hilft. Das Tool bietet sogar eine Simulation an.

apt modernize-sources

The following files need modernizing:
  - /etc/apt/sources.list
  - /etc/apt/sources.list.d/docker.list

Modernizing will replace .list files with the new .sources format,
add Signed-By values where they can be determined automatically,
and save the old files into .list.bak files.

This command supports the 'signed-by' and 'trusted' options. If you
have specified other options inside [] brackets, please transfer them
manually to the output files; see sources.list(5) for a mapping.

For a simulation, respond N in the following prompt.
Rewrite 2 sources? [Y/n] y
Modernizing /etc/apt/sources.list...
- Writing /etc/apt/sources.list.d/debian.sources

Modernizing /etc/apt/sources.list.d/docker.list...
- Writing /etc/apt/sources.list.d/docker.sources

Ich hoffe diese Beitrag konnte euch bei der Umstellung helfen. Ich habe damit bereits drei Systeme erfolgreich umgestellt und bisher keine Probleme gehabt. Jedoch hier nochmals der Hinweis, immer vorher ein Backup erstellen!

7. Ding die bei mir Probleme machten

Danke für den Tipp die systcl.conf in die /etc/sysctl.d/ zu verschieben, nun klappt auch das Wireguard wieder 🙂 .

Antworten
Björn
18. August 2025 um 14:50 Uhr

Hab ich zwar so nicht geschrieben, aber deine Methode ist natürlich besser. 😉
Danke.


Hallo,

danke für die Anleitung hat super funktioniert.
Aber ich bekomme immer folgenden Hinweis:

All packages are up to date.
Notice: Missing Signed-By in the sources.list(5) entry for ‚http://archive.raspberrypi.com/debian‘

Braucht man überhaupt noch das „http://archive.raspberrypi.com/debian“ ?

Gruß
Tobi

Jens
13. Februar 2026 um 12:15 Uhr

Moin Björn!

Dane für die klare Anleitung. Hat bei mir soweit gut funktioniert. Leider habe ich mit dem letzten Schritt (apt modernize-sources) Schwierigkeiten. Er sagt, dass er für die Docker Quellen kein „Signed-By“ finden kann:

Modernizing /etc/apt/sources.list.d/download_docker_com_linux_debian.list…
– Writing /etc/apt/sources.list.d/download_docker_com_linux_debian.sources
Warning: Could not determine Signed-By for URIs: https://download.docker.com/linux/debian/, Suites: trixie

Du kannst dir dazu die Docker Dokumentation anschauen. Unter 1. Set up Docker’s apt repository. findest du die nötigen Infos, wie du den Key herunterlädst und das nötige Source File erzeugst, bzw. wie es aussehen sollte.