bilibop-rules ------------- 1. OVERVIEW =========== This package mainly provides a udev rules file to be applied on operating systems running from external media (USB stick, USB HDD, FireWire, Flash Memory stick, eSATA HDD). Its goal is to adapt some system behaviours to its particular situation, like an organ outside of the body. Bilibop-rules is based on the bilibop-common functions and may need Linux kernel 2.6.37 or higher to work properly (this requirement is related to loop devices). The running system being hosted on a removable device, the common udev rules (91-permissions.rules) will set it as owned by the 'floppy' group, allowing any member of this group to damage it, even by mistake, with a simple 'shred DEVICE' or 'cat /dev/zero >DEVICE' command. So the bilibop rules fix the disk hosting the operating system and all its partitions as owned by the 'disk' group, as it was an internal disk. This is the main, and this is not optional. 2. OTHER UDEV RULES =================== Another feature of the bilibop udev rules is to tag all devices hosted by the same disk than the root filesystem as 'BILIBOP'. This applies to all physical devices (disk and partitions) and virtual devices (device-mapper and loop), and can be used later by the lsbilibop(8) command (see below). Internal physical block devices (i.e. disks and partitions of the drives inside the computer) are also tagged as 'INSIDEV'. This can be used later by the physical_volumes_filter helper script, and provides an easy way to customize the settings and behaviour of these internal devices (see 90-insidev.rules in the documentation of the package for examples). Additionally, if one of the 'BILIBOP' tagged devices uses the device-mapper, some of the udev symlinks to this device are updated. This is done because when a device has already been added from the initrd, the dm rules file (55-dm.rules) makes that the spurious 'add' uevent triggered by udev from the system environment don't update symlinks to the added device, leading to this situation, that a dm device can have a lot of symlinks created by udev in the initrd environment, but none is managed by udev in the system environment. So, bilibop rules restore at least /dev/mapper/dm_name as a part of the udev database, and also /dev/vg_name/lv_name if the device is a Logical Volume. 2.1. Udisks facilities ---------------------- Bilibop rules include rules to set udisks2 environment variables for the devices hosted on the same disk than the root filesystem. If one of the Gnome, KDE, Xfce or LXDE desktop environment is installed, and then Udisks is used to mount/unmount removable devices from the file manager or the desktop (which is an instance of the file manager), it is possible to hide some devices, or show them with a different name or icon than the default, or prompt the user for su/sudo password when she attempts to manage them. The udisks variables bilibop rules can set are: * For udisks2 (see udisks(8) manpage): UDISKS_SYSTEM UDISKS_IGNORE UDISKS_ICON_NAME UDISKS_NAME By default, 'BILIBOP' tagged devices are hidden and set 'system internal'. The rules: ENV{ID_DRIVE_DETACHABLE}:=0 (udisks) and ENV{UDISKS_CAN_POWER_OFF}:=0 (udisks2) are also applied to the disk, to avoid udisks detach it from its bus when a partition is unmounted, but it seems that the first one is not working as expected. Bad thing! Here the Udisks ability to detach a drive can lead to crash the system :( 2.2. lsbilibop -------------- This command can be used to list 'BILIBOP' tagged devices, and display or update some of their udev properties. It should be used each time the BILIBOP_RULES_* variables are modified in /etc/bilibop/bilibop.conf. For the case the devices have not been tagged (a simple case: override /usr/lib/udev/rules.d/66-bilibop.rules by an empty rules file in /etc), you may use the -l option: it allows lsbilibop to not rely on the 'BILIBOP' udev tag, and makes it lists bilibop devices by using the shell library provided by bilibop-common. If BILIBOP_COMMON_BASENAME has been modified in /etc/bilibop/bilibop.conf, then running 'lsbilibop -a' or 'lsbilibop -c' is mandatory. See the bilibop.conf(5) and lsbilibop(8) manual pages and /usr/share/doc/bilibop-rules/examples/bilibop.conf for detailed information about default or custom settings. 3. DEBCONF ========== bilibop-rules is now debconf-configurable (since 0.4.12). That means it is also preconfigurable or 'preseedable'. To preconfigure bilibop-rules from a preseed file, you can include something like: bilibop-rules bilibop-rules/on-live-system boolean false bilibop-rules bilibop-rules/bilibop_rules_generator/customize boolean false bilibop-rules bilibop-rules/physical_volumes_filter/system-only boolean true Except the first one, all is based on calls of helper scripts (see the next section). If you intend to install bilibop-rules on a LiveUSB, be sure to answer 'true' to the first question (on-live-system); then other questions will not be asked and the helper scripts will not be executed at all. To reconfigure bilibop-rules, just run (as root): dpkg-reconfigure -p low bilibop-rules 4. HELPER SCRIPTS ================= bilibop-rules provides helper scripts (in /usr/share/bilibop). They are called from the maintainer scripts (postinst and prerm) but all can be run manually by the admin: each of them accepts the '--help' option, to know how to use it. If BILIBOP_COMMON_BASENAME is modified in bilibop.conf(5) (i.e. set to something else than 'bilibop' or ''), then it may be necessary to run 'bilibop_rules_generator' (if /etc/udev/rules.d/66-bilibop.rules exists) to reflect the new setting. Unless you know what you are doing, you should not run these scripts manually, but by running 'dpkg-reconfigure bilibop-rules' instead. 4.1. bilibop_rules_generator ---------------------------- This program generates a udev rules file /etc/udev/rules.d/66-bilibop.rules doing the same things than the file with the same name in /usr/lib/udev/rules.d. The main difference is that rules in /lib are generic and can take more time if a lot of removable devices are plugged onto the computer. Rules in /etc use the sysfs attributes of the device hosting the system and run faster. Take care that if your device is able to be plugged on several port types (i.e. can be used both as USB and FireWire, or USB and eSATA, or MMC and USB - by using an adapter) the generated rules will work only for the interface type on which it was plugged when the rules have been generated. As example, for a 'LaCie Rugged FW/USB' external HDD: ### 4.1.a. When booted as USB device The sysfs attributes possibly managed by the script are: ATTRS{vendor}=="LaCie " ATTRS{model}=="Rugged FW/USB " ... ATTRS{manufacturer}=="LaCie" ATTRS{product}=="LaCie Rugged FW/USB" ATTRS{serial}=="00D04B9A0506232D" ### 4.1.b. When booted as FireWire device The sysfs attributes possibly managed by the script are: ATTRS{vendor}=="LaCie " ATTRS{model}=="Rugged FW/USB " ### 4.1.c. Generate the proper rules file: To generate a rules file matching sysfs attributes both for USB and FireWire usage, you have to force 'vendor' and 'model' sysfs attributes, because the default being to use 'manufacturer', 'product' and 'serial' if they exist, as they don't exist when the disk is plugged on FireWire, the rules working fine for USB will not work for FireWire. So, in that case, if the disk is plugged on the FireWire port, the result of the command without option will work for both USB and FireWire; but if the disk is connected on the USB port when you want to build the rules file, use this command: /usr/share/bilibop/bilibop_rules_generator --attribute vendor,model 4.2. physical_volumes_filter ---------------------------- This script can be used to display the LVM 'filter' settings actually in use, or to modify these settings. It uses the 'BILIBOP' and 'INSIDEV' tags to find devices and their symlinks and build patterns on which the 'accept' or 'reject' behaviours will be applied. For example, if you don't want to activate Logical Volumes other than those used by your system, you can easily make that all Physical Volumes that are not used by your system are ignored and never scanned by lvm tools: /usr/share/bilibop/physical_volumes_filter --overwrite --udev --accept bilibop --reject all Or, shorter: /usr/share/bilibop/physical_volumes_filter -oua bilibop -r all This can be very useful, especially when the VG and LV names used on your system are as generic as 'vg0' and 'lv0', 'lv1', etc. One time you are satisfied of your settings, you should not modify them. Run 'update-initramfs -u' to put your lvm.conf in the initramdisk (so the other Physical Volumes will be hidden even from the initramfs, and never activated). Then, to use other LVM filters without modifying your owns, you can do (as root): mkdir /tmp/lvm2 cp /etc/lvm/lvm.conf /tmp/lvm2 export LVM_SYSTEM_DIR=/tmp/lvm2 alias pvfilter='/usr/share/bilibop/physical_volumes_filter' And then you can use 'pvfilter' and all LVM tools from the same shell: changes from pvfilter will apply to /tmp/lvm2/lvm.conf, and LVM tools will use the settings from this temporary file. If, for a reason or another, the initramdisk of your system is updated during this time, lvm.conf will be copied in it from /etc/lvm, not from /tmp/lvm2, and so your next boot will not be compromised. In this context, you can safely run: pvfilter --overwrite --blank --udev --show --reject bilibop And then you can perform operations on Physical or Logical Volumes by using LVM commands without take the risk to modify your owns by mistake. This can be automated by copying /usr/share/doc/bilibop-rules/examples/rlvm somewhere in your PATH (probably in /usr/local/sbin) and enabling its executable bit; then run 'rlvm' (restricted lvm) and work. If the 'global_filter' variable is supported (lvm2 >= 2.02.98) and if it is enabled, then the command automatically applies to this variable (instead of 'filter'), unless the --noglobal option is invoked. See also lvm.conf(5) manual page for details. 5. MORE INFO ============ See /usr/share/doc/bilibop-common/misc/* -- bilibop project Tue, 17 Apr 2012 03:03:52 +0200 -- bilibop project Sun, 24 Nov 2013 03:19:27 +0000 -- bilibop project Sat, 08 Feb 2020 19:48:41 +0000