Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
Vorhergehende Überarbeitung Nächste Überarbeitung | |||
— | content:serverbasics [2023/07/24 12:30] – [Raided LVM- Volumes] Daniel | ||
---|---|---|---|
Zeile 1: | Zeile 1: | ||
+ | ====== Linux: Basic Server Configuration ====== | ||
+ | |||
+ | These setting here are an advice to think about when setting up a new linux- machine (here on an opensuse distrubution, | ||
+ | |||
+ | ===== Mountpoints ===== | ||
+ | |||
+ | By default openSuSE will set some conservative mountoptions, | ||
+ | |||
+ | ==== Raided EFIBOOT ==== | ||
+ | |||
+ | There are some problems when raiding the efi-boot. I would suggest to use: | ||
+ | |||
+ | < | ||
+ | ~ # mdadm --create --verbose / | ||
+ | |||
+ | </ | ||
+ | |||
+ | The important part is metadata=1.0 - this format has especially designed to fit the needs of raid1 of fat/efi- systems. | ||
+ | |||
+ | |||
+ | ==== LVM ==== | ||
+ | |||
+ | LVM is a powerful partition-management-layer and should always be used, when there is some none low-end hardware present. If you can use the **KDE Partitioning- Tool** (which means having Plasma=KDE Desktop compatible support), the support is very inuitive and opens a lot of flexibility whne handling partitions, like adding more disk space or moving partitions, but also on console this offers good functionality. OpenSuSE offer to create LVM- Styled system setup in installation optionally (not by default). If you can: use it. | ||
+ | === Raided LVM- Volumes === | ||
+ | |||
+ | Noadays, raid1 or raid5 for system without LVM is outdated. Those things are integrated in LVM - so use it! | ||
+ | |||
+ | First, creat a volume group with two same size partitions on two discs, than create a raid1 on it (for example): | ||
+ | |||
+ | < | ||
+ | vgcreate vgsystem /dev/sdX1 /dev/sdY1 | ||
+ | lvcreate -m1 --type raid1 -l 100%FREE -n lvroot vgsystem | ||
+ | |||
+ | </ | ||
+ | |||
+ | where 100%FREE means 100% of Free Space used… | ||
+ | |||
+ | To check if raid1 works, use: | ||
+ | |||
+ | < | ||
+ | lvs -a -o name, | ||
+ | |||
+ | </ | ||
+ | |||
+ | If this has not worked, use: | ||
+ | |||
+ | < | ||
+ | lvconvert --type raid1 -m1 vg_xxx/ | ||
+ | |||
+ | </ | ||
+ | |||
+ | Or - you can do raid5 with: | ||
+ | |||
+ | < | ||
+ | lvcreate -n lvdata --type raid5 -l 100%FREE -i 2 vgdata | ||
+ | |||
+ | </ | ||
+ | |||
+ | where i equals the number of devices with Data (not including parity- storage) | ||
+ | |||
+ | |||
+ | === Useful Commands === | ||
+ | |||
+ | The KDE- Partitionmanager is still not perfect. LVM is mor powerful in these things: | ||
+ | |||
+ | == Moving logical Volumes to physical Devices == | ||
+ | |||
+ | Usually Partitions or Devices are only assigned to Volume-Groups (VG) and Logical Volumes (LV) are using them dynamically as needed. This makes it sometimes hard to understand, where the Data really is located right now. Especially when you are having different physical Devices, you may want one LV to use one Device. | ||
+ | |||
+ | For an overview how the Data is split, you can use: | ||
+ | |||
+ | < | ||
+ | # lvs -o+devices | ||
+ | LV | ||
+ | home | ||
+ | root | ||
+ | shared system -wi-ao---- 786.64g | ||
+ | |||
+ | </ | ||
+ | |||
+ | You can also move them to single Devices if needed. Here i wanted my home to also be on the faster Device sda. As sda4 had enough free space, i could do: | ||
+ | |||
+ | < | ||
+ | # pvmove -n system/home /dev/sdb2 /dev/sda4 | ||
+ | |||
+ | </ | ||
+ | |||
+ | |||
+ | ==== Filesystem ==== | ||
+ | |||
+ | Brtfs is the way to go everywhere. There are some disadvanteges while it is still in developement and sometime a bit oversized for homeoffice, but no other filesystem is that good in general usage. Only use other Filesystems, | ||
+ | |||
+ | ==== Mountoptions ==== | ||
+ | |||
+ | BTRFs has a lot of Mountoptions and some here are really odd ones for every linux. I would suggest at least those: | ||
+ | |||
+ | For **Desktopusage**: | ||
+ | |||
+ | While autodefrag should not be necessary on ssd- harddiscs. | ||
+ | |||
+ | For **Databases** or files that need speed and __**are well backed up otherwise**__ | ||
+ | |||
+ | |||
+ | === Sources: === | ||
+ | |||
+ | * [[https:// | ||
+ | * [[https:// | ||
+ | |||
+ | ===== Quotas ===== | ||
+ | |||
+ | Brief: Quotas should be disabled | ||
+ | |||
+ | ==== What is it for? ==== | ||
+ | |||
+ | BTRFS comes with included support of disk quotas. It is enabled by default if a btrfs-volume is created. Disk quotas are useful to mangage diskspace, as they store informations of directory sizes in the filesystem. There may be programs, that calculate disk usage of directories only that way. One example is snapper: It will automatically delete old snapshots, if the space is running low on a device using snapshots. This is done, by checking the qoutas. Running snapper without qoutas will make this not working anymore. Instead other functions will be used - e.g. the maximum number of old snapshots to keep. | ||
+ | |||
+ | To find out, if quoutas are enabled, do: | ||
+ | < | ||
+ | |||
+ | btrfs qgroup show / | ||
+ | |||
+ | </ | ||
+ | |||
+ | ==== What is the problem? ==== | ||
+ | |||
+ | Quotas are complicated to manage by btrfs. As there are many situations, where the qoutas may get incorrect, they will often be invalidated and will need to be recalculated from scratch. Furthermore checking if they are correct is often needed - e.g. at startup or after some time. This process consumes a lot of cpu and disc utilisation and makes the hardware slow, sometimes rendering a computer useless for some time. | ||
+ | |||
+ | ==== Solution ==== | ||
+ | |||
+ | Because of this, the kernel.org- team recommends to turn disk quotas off if not needed. | ||
+ | |||
+ | This can be done by: | ||
+ | |||
+ | < | ||
+ | btrfs quota disable / | ||
+ | |||
+ | </ | ||
+ | |||
+ | === Snapper === | ||
+ | |||
+ | After that, / | ||
+ | |||
+ | < | ||
+ | # limit for number cleanup | ||
+ | NUMBER_MIN_AGE=" | ||
+ | NUMBER_LIMIT=" | ||
+ | NUMBER_LIMIT_IMPORTANT=" | ||
+ | |||
+ | </ | ||
+ | |||
+ | ===== Swappiness ===== | ||
+ | |||
+ | If you have a lot of Ram, you may adjust the swappiness to better fit your needs - or turn off swap completely. | ||
+ | |||
+ | e.g. / | ||
+ | |||
+ | < | ||
+ | vm.swappiness = 60 | ||
+ | |||
+ | </ | ||
+ | |||
+ | ===== Filesystem and User rights in Linux ===== | ||
+ | |||
+ | While linux itself is a very secure system (when set up the right way), the rights given to files by default are not secure at all. Setting good rights is not an intuive process and is mostly not well done. So it needs some attention. | ||
+ | |||
+ | ==== Why care about rights ==== | ||
+ | |||
+ | If you are the only user on your pc, or your linux pc is a machine for the net, then you maybe fine. But if your pc is shared between some users e.g. in your family and used by some other persons, then you may wish, that personal informations of the one user is not accessible to the other one. | ||
+ | |||
+ | Even if your pc is not used by others, there maybe other users on your pc by services running in different accounts, so maybe you want Data not to be visible to any user. | ||
+ | |||
+ | ==== Test the rights ==== | ||
+ | |||
+ | Lets start with a simple new file, let's say " | ||
+ | |||
+ | New File ~\securedata.txt : | ||
+ | |||
+ | < | ||
+ | testuser@xubuntu-stick: | ||
+ | |||
+ | </ | ||
+ | |||
+ | Then become someone else, maybe user testuser2 and read that file: | ||
+ | |||
+ | < | ||
+ | testuser@xubuntu-stick: | ||
+ | Passwort: | ||
+ | testuser2@xubuntu-stick: | ||
+ | |||
+ | </ | ||
+ | |||
+ | Now lets see what the other user has written in its secure file: | ||
+ | |||
+ | < | ||
+ | testuser2@xubuntu-stick: | ||
+ | cat: ../ | ||
+ | |||
+ | </ | ||
+ | |||
+ | So everything right? No - not quite. Lets say horst decides to store is secure data in another location and do it again: | ||
+ | |||
+ | < | ||
+ | testuser@xubuntu-stick: | ||
+ | testuser@xubuntu-stick: | ||
+ | Passwort: | ||
+ | testuser2@xubuntu-stick: | ||
+ | secure data | ||
+ | |||
+ | </ | ||
+ | |||
+ | So now the data the one user created is not secure any more. Well ok this sounds fine, because the data was moved to an insecure directory. | ||
+ | |||
+ | But: Can you make sure that everybody knows which directories are secure and which aren' | ||
+ | |||
+ | So it may be a better approach to not make the files created by someone readable by other user by default. | ||
+ | |||
+ | ==== UMask- Approach ==== | ||
+ | |||
+ | There ist a tool for this called umask. This tool defines the permission for new created files. | ||
+ | |||
+ | By default the umask is 0002 or 0022. Those values are substracted from 0777, which would mean full access for everyone. You can check out the docs in the net how they work. I won't explain here, cause there is a big problem with umask: The value can only be changed on process level or user or systemwide. This means you cannot set them per directory - which would be intentional to the user. | ||
+ | |||
+ | So forget about umask. | ||
+ | |||
+ | ==== FACLs ==== | ||
+ | |||
+ | F… what??? Yes: facl is the tool to do so. with that tool you can very much expand the rights per directory an on every file in detail. It ist also possible to have multiple group- access definitions, | ||
+ | |||
+ | So lets do some facl- work: | ||
+ | |||
+ | < | ||
+ | testuser@xubuntu-stick: | ||
+ | testuser@xubuntu-stick: | ||
+ | # file: temp | ||
+ | # owner: testuser | ||
+ | # group: testuser | ||
+ | user::rwx | ||
+ | group::rwx | ||
+ | other::r-x | ||
+ | |||
+ | </ | ||
+ | |||
+ | As you can see, that directory has been created quite insecure. There is only the above permission preventing everyone to read the informations in it. Creating a new file in it, would make it the same way insecure, as it would have been before. | ||
+ | |||
+ | But now lets set the mode to better fit our needs: | ||
+ | |||
+ | < | ||
+ | testuser@xubuntu-stick: | ||
+ | testuser@xubuntu-stick: | ||
+ | # file: temp | ||
+ | # owner: testuser | ||
+ | # group: testuser | ||
+ | user::rwx | ||
+ | group::rwx | ||
+ | other::r-x | ||
+ | default: | ||
+ | default: | ||
+ | default: | ||
+ | |||
+ | </ | ||
+ | |||
+ | Note, that we only changed the DEFAULT permissions to be more secure (d:). | ||
+ | |||
+ | Now lets again create a file there as we did before just in that - safe - directory. Also we can use getfacl on that file to check if it works: | ||
+ | |||
+ | < | ||
+ | testuser@xubuntu-stick: | ||
+ | testuser@xubuntu-stick: | ||
+ | # file: temp/ | ||
+ | # owner: testuser | ||
+ | # group: testuser | ||
+ | user::rw- | ||
+ | group::rw- | ||
+ | other::--- | ||
+ | |||
+ | </ | ||
+ | |||
+ | As you can see, that file is more secure than before. So lets check, what happens now if we move that file as before. | ||
+ | |||
+ | < | ||
+ | testuser@xubuntu-stick: | ||
+ | testuser@xubuntu-stick: | ||
+ | |||
+ | </ | ||
+ | |||
+ | And check if it is accessible by another one: | ||
+ | |||
+ | < | ||
+ | testuser@xubuntu-stick: | ||
+ | Passwort: | ||
+ | testuser2@xubuntu-stick: | ||
+ | cat: / | ||
+ | |||
+ | </ | ||
+ | |||
+ | You can also check the rights now: | ||
+ | |||
+ | < | ||
+ | testuser2@xubuntu-stick: | ||
+ | getfacl: Entferne führende '/' | ||
+ | # file: tmp/ | ||
+ | # owner: testuser | ||
+ | # group: testuser | ||
+ | user::rw- | ||
+ | group::rw- | ||
+ | other::--- | ||
+ | |||
+ | </ | ||
+ | |||
+ | Now " | ||
+ | |||
+ | That way you can also have one or more default group(s) assigned and to give only those groups access to the file(s), which is very powerful. As for the user perspective i would rate that approach more secure, than the default one. | ||
+ | |||
+ | Its up to you to decide if this is more usable or not. | ||
+ | |||
+ | ==== Last words ==== | ||
+ | |||
+ | Some other intersting aspects: | ||
+ | |||
+ | * There are some interesting usages of the sticky bits for a. the user and group- bit and b. to files and directories in seperate | ||
+ | * Mind, that only the user of the file can change its ownership. Per default all files created by the user are owned by the user. | ||
+ | * That means: If you don't want a user be able to change the ownership of a file into insecure permissions, | ||
+ | |||
+ | All in all thinking about permissions is a basic one whenever there is personal data that needs to be secured somehow. One cannot rely on the defaults and hope its all fine. | ||
+ | |||
+ | And with FACLs there are powerful tools that should cover everything an administrator needs. | ||
+ | |||