diff options
Diffstat (limited to 'markup/pod/live-manual/media/text/ro/user_customization-runtime.ssi')
| -rw-r--r-- | markup/pod/live-manual/media/text/ro/user_customization-runtime.ssi | 441 |
1 files changed, 0 insertions, 441 deletions
diff --git a/markup/pod/live-manual/media/text/ro/user_customization-runtime.ssi b/markup/pod/live-manual/media/text/ro/user_customization-runtime.ssi deleted file mode 100644 index 3e44cb3..0000000 --- a/markup/pod/live-manual/media/text/ro/user_customization-runtime.ssi +++ /dev/null @@ -1,441 +0,0 @@ -:B~ Customizing run time behaviours - -1~customizing-run-time-behaviours Customizing run time behaviours - -All configuration that is done during run time is done by live-config. Here -are some of the most common options of live-config that users are interested -in. A full list of all possibilities can be found in the man page of -live-config. - -2~ Customizing the live user - -One important consideration is that the live user is created by live-boot at -boot time, not by live-build at build time. This not only influences where -materials relating to the live user are introduced in your build, as -discussed in {Live/chroot local includes}#live-chroot-local-includes, but -also any groups and permissions associated with the live user. - -You can specify additional groups that the live user will belong to by using -any of the possibilities to configure live-config. For example, to add the -live user to the #{fuse}# group, you can either add the following file in -#{config/includes.chroot/etc/live/config/user-setup.conf}#: - -code{ - - LIVE_USER_DEFAULT_GROUPS="audio cdrom dip floppy video plugdev netdev powerdev scanner bluetooth fuse" - -}code - -or use -#{live-config.user-default-groups=audio,cdrom,dip,floppy,video,plugdev,netdev,powerdev,scanner,bluetooth,fuse}# -as a boot parameter. - -It is also possible to change the default username "user" and the default -password "live". If you want to do that for any reason, you can easily -achieve it as follows: - -To change the default username you can simply specify it in your config: - -code{ - - $ lb config --bootappend-live "boot=live components username=live-user" - -}code - -One possible way of changing the default password is by means of a hook as -described in {Boot-time hooks}#boot-time-hooks. In order to do that you can -use the "passwd" hook from #{/usr/share/doc/live-config/examples/hooks}#, -prefix it accordingly (e.g. 2000-passwd) and add it to -#{config/includes.chroot/lib/live/config/}# - -2~customizing-locale-and-language Customizing locale and language - -When the live system boots, language is involved in two steps: - -_* the locale generation - -_* setting the keyboard configuration - -The default locale when building a Live system is -#{locales=en_US.UTF-8}#. To define the locale that should be generated, use -the #{locales}# parameter in the #{--bootappend-live}# option of #{lb -config}#, e.g. - -code{ - - $ lb config --bootappend-live "boot=live components locales=de_CH.UTF-8" - -}code - -Multiple locales may be specified as a comma-delimited list. - -This parameter, as well as the keyboard configuration parameters indicated -below, can also be used at the kernel command line. You can specify a locale -by #{language_country}# (in which case the default encoding is used) or the -full #{language_country.encoding}# word. A list of supported locales and the -encoding for each can be found in #{/usr/share/i18n/SUPPORTED}#. - -Both the console and X keyboard configuration are performed by -#{live-config}# using the #{console-setup}# package. To configure them, use -the #{keyboard-layouts}#, #{keyboard-variants}#, #{keyboard-options}# and -#{keyboard-model}# boot parameters via the #{--bootappend-live}# -option. Valid options for these can be found in -#{/usr/share/X11/xkb/rules/base.lst}#. To find layouts and variants for a -given language, try searching for the English name of the language and/or -the country where the language is spoken, e.g: - -code{ - -$ egrep -i '(^!|german.*switzerland)' /usr/share/X11/xkb/rules/base.lst - ! model - ! layout - ch German (Switzerland) - ! variant - legacy ch: German (Switzerland, legacy) - de_nodeadkeys ch: German (Switzerland, eliminate dead keys) - de_sundeadkeys ch: German (Switzerland, Sun dead keys) - de_mac ch: German (Switzerland, Macintosh) - ! option - -}code - -Note that each variant lists the layout to which it applies in the -description. - -Often, only the layout needs to be configured. For example, to get the -locale files for German and Swiss German keyboard layout in X use: - -code{ - - $ lb config --bootappend-live "boot=live components locales=de_CH.UTF-8 keyboard-layouts=ch" - -}code - -However, for very specific use cases, you may wish to include other -parameters. For example, to set up a French system with a French-Dvorak -layout (called Bepo) on a TypeMatrix EZ-Reach 2030 USB keyboard, use: - -code{ - - $ lb config --bootappend-live \ - "boot=live components locales=fr_FR.UTF-8 keyboard-layouts=fr keyboard-variants=bepo keyboard-model=tm2030usb" - -}code - -Multiple values may be specified as comma-delimited lists for each of the -#{keyboard-*}# options, with the exception of #{keyboard-model}#, which -accepts only one value. Please see the #{keyboard(5)}# man page for details -and examples of #{XKBMODEL}#, #{XKBLAYOUT}#, #{XKBVARIANT}# and -#{XKBOPTIONS}# variables. If multiple #{keyboard-variants}# values are -given, they will be matched one-to-one with #{keyboard-layouts}# values (see -#{setxkbmap(1)}# #{-variant}# option). Empty values are allowed; e.g. to -define two layouts, the default being US QWERTY and the other being US -Dvorak, use: - -code{ - - $ lb config --bootappend-live \ - "boot=live components keyboard-layouts=us,us keyboard-variants=,dvorak" - -}code - -2~persistence Persistence - -A live cd paradigm is a pre-installed system which runs from read-only -media, like a cdrom, where writes and modifications do not survive reboots -of the host hardware which runs it. - -A live system is a generalization of this paradigm and thus supports other -media in addition to CDs; but still, in its default behaviour, it should be -considered read-only and all the run-time evolutions of the system are lost -at shutdown. - -'Persistence' is a common name for different kinds of solutions for saving -across reboots some, or all, of this run-time evolution of the system. To -understand how it works it would be handy to know that even if the system is -booted and run from read-only media, modifications to the files and -directories are written on writable media, typically a ram disk (tmpfs) and -ram disks' data do not survive reboots. - -The data stored on this ramdisk should be saved on a writable persistent -medium like local storage media, a network share or even a session of a -multisession (re)writable CD/DVD. All these media are supported in live -systems in different ways, and all but the last one require a special boot -parameter to be specified at boot time: #{persistence}#. - -If the boot parameter #{persistence}# is set (and #{nopersistence}# is not -set), local storage media (e.g. hard disks, USB drives) will be probed for -persistence volumes during boot. It is possible to restrict which types of -persistence volumes to use by specifying certain boot parameters described -in the live-boot(7) man page. A persistence volume is any of the following: - -_* a partition, identified by its GPT name. - -_* a filesystem, identified by its filesystem label. - -_* an image file located on the root of any readable filesystem (even an -NTFS partition of a foreign OS), identified by its filename. - -The volume label for overlays must be #{persistence}# but it will be ignored -unless it contains in its root a file named #{persistence.conf}# which is -used to fully customize the volume's persistence, this is to say, specifying -the directories that you want to save in your persistence volume after a -reboot. See {The persistence.conf file}#persistence-conf for more details. - -Here are some examples of how to prepare a volume to be used for -persistence. It can be, for instance, an ext4 partition on a hard disk or on -a usb key created with, e.g.: - -code{ - - # mkfs.ext4 -L persistence /dev/sdb1 - -}code - -See also {Using the space left on a USB stick}#using-usb-extra-space. - -If you already have a partition on your device, you could just change the -label with one of the following: - -code{ - - # tune2fs -L persistence /dev/sdb1 # for ext2,3,4 filesystems - -}code - -Here's an example of how to create an ext4-based image file to be used for -persistence: - -code{ - - $ dd if=/dev/null of=persistence bs=1 count=0 seek=1G # for a 1GB sized image file - $ /sbin/mkfs.ext4 -F persistence - -}code - -Once the image file is created, as an example, to make #{/usr}# persistent -but only saving the changes you make to that directory and not all the -contents of #{/usr}#, you can use the "union" option. If the image file is -located in your home directory, copy it to the root of your hard drive's -filesystem and mount it in #{/mnt}# as follows: - -code{ - - # cp persistence / - # mount -t ext4 /persistence /mnt - -}code - -Then, create the #{persistence.conf}# file adding content and unmount the -image file. - -code{ - - # echo "/usr union" >> /mnt/persistence.conf - # umount /mnt - -}code - -Now, reboot into your live medium with the boot parameter "persistence". - -3~persistence-conf The persistence.conf file - -A volume with the label #{persistence}# must be configured by means of the -#{persistence.conf}# file to make arbitrary directories persistent. That -file, located on the volume's filesystem root, controls which directories it -makes persistent, and in which way. - -How custom overlay mounts are configured is described in full detail in the -persistence.conf(5) man page, but a simple example should be sufficient for -most uses. Let's say we want to make our home directory and APT cache -persistent in an ext4 filesystem on the /dev/sdb1 partition: - -code{ - - # mkfs.ext4 -L persistence /dev/sdb1 - # mount -t ext4 /dev/sdb1 /mnt - # echo "/home" >> /mnt/persistence.conf - # echo "/var/cache/apt" >> /mnt/persistence.conf - # umount /mnt - -}code - -Then we reboot. During the first boot the contents of #{/home}# and -#{/var/cache/apt}# will be copied into the persistence volume, and from then -on all changes to these directories will live in the persistence -volume. Please note that any paths listed in the #{persistence.conf}# file -cannot contain white spaces or the special #{.}# and #{..}# path -components. Also, neither #{/lib}#, #{/lib/live}# (or any of their -sub-directories) nor #{/}# can be made persistent using custom mounts. As a -workaround for this limitation you can add #{/ union}# to your -#{persistence.conf}# file to achieve full persistence. - -3~ Using more than one persistence store - -There are different methods of using multiple persistence store for -different use cases. For instance, using several volumes at the same time or -selecting only one, among various, for very specific purposes. - -Several different custom overlay volumes (with their own -#{persistence.conf}# files) can be used at the same time, but if several -volumes make the same directory persistent, only one of them will be -used. If any two mounts are "nested" (i.e. one is a sub-directory of the -other) the parent will be mounted before the child so no mount will be -hidden by the other. Nested custom mounts are problematic if they are listed -in the same #{persistence.conf}# file. See the persistence.conf(5) man page -for how to handle that case if you really need it (hint: you usually don't). - -One possible use case: If you wish to store the user data i.e. #{/home}# and -the superuser data i.e. #{/root}# in different partitions, create two -partitions with the #{persistence}# label and add a #{persistence.conf}# -file in each one like this, #{# echo "/home" > persistence.conf}# for the -first partition that will save the user's files and #{# echo "/root" > -persistence.conf}# for the second partition which will store the superuser's -files. Finally, use the #{persistence}# boot parameter. - -If a user would need multiple persistence store of the same type for -different locations or testing, such as #{private}# and #{work}#, the boot -parameter #{persistence-label}# used in conjunction with the boot parameter -#{persistence}# will allow for multiple but unique persistence media. An -example would be if a user wanted to use a persistence partition labeled -#{private}# for personal data like browser bookmarks or other types, they -would use the boot parameters: #{persistence}# -#{persistence-label=private}#. And to store work related data, like -documents, research projects or other types, they would use the boot -parameters: #{persistence}# #{persistence-label=work}#. - -It is important to remember that each of these volumes, #{private}# and -#{work}#, also needs a #{persistence.conf}# file in its root. The live-boot -man page contains more information about how to use these labels with legacy -names. - -3~ Using persistence with encryption - -Using the persistence feature means that some sensible data might get -exposed to risk. Especially if the persistent data is stored on a portable -device such as a usb stick or an external hard drive. That is when -encryption comes in handy. Even if the entire procedure might seem -complicated because of the number of steps to be taken, it is really easy to -handle encrypted partitions with live-boot. In order to use *{luks}*, which -is the supported encryption type, you need to install /{cryptsetup}/ both on -the machine you are creating the encrypted partition with and also in the -live system you are going to use the encrypted persistent partition with. - -To install /{cryptsetup}/ on your machine: - -code{ - - # apt-get install cryptsetup - -}code - -To install /{cryptsetup}/ in your live system, add it to your package-lists: - -code{ - - $ lb config - $ echo "cryptsetup" > config/package-lists/encryption.list.chroot - -}code - -Once you have your live system with /{cryptsetup}/, you basically only need -to create a new partition, encrypt it and boot with the #{persistence}# and -#{persistence-encryption=luks}# parameters. We could have already -anticipated this step and added the boot parameters following the usual -procedure: - -code{ - - $ lb config --bootappend-live "boot=live components persistence persistence-encryption=luks" - -}code - -Let's go into the details for all of those who are not familiar with -encryption. In the following example we are going to use a partition on a -usb stick which corresponds to #{/dev/sdc2}#. Please be warned that you need -to determine which partition is the one you are going to use in your -specific case. - -The first step is plugging in your usb stick and determine which device it -is. The recommended method of listing devices in live-manual is using #{ls --l /dev/disk/by-id}#. After that, create a new partition and then, encrypt -it with a passphrase as follows: - -code{ - - # cryptsetup --verify-passphrase luksFormat /dev/sdc2 - -}code - -Then open the luks partition in the virtual device mapper. Use any name you -like. We use *{live}* here as an example: - -code{ - - # cryptsetup luksOpen /dev/sdc2 live - -}code - -The next step is filling the device with zeros before creating the -filesystem: - -code{ - - # dd if=/dev/zero of=/dev/mapper/live - -}code - -Now, we are ready to create the filesystem. Notice that we are adding the -label #{persistence}# so that the device is mounted as persistence store at -boot time. - -code{ - - # mkfs.ext4 -L persistence /dev/mapper/live - -}code - -To continue with our setup, we need to mount the device, for example in -#{/mnt}#. - -code{ - - # mount /dev/mapper/live /mnt - -}code - -And create the #{persistence.conf}# file in the root of the partition. This -is, as explained before, strictly necessary. See {The persistence.conf -file}#persistence-conf. - -code{ - - # echo "/ union" > /mnt/persistence.conf - -}code - -Then unmount the mount point: - -code{ - - # umount /mnt - -}code - -And optionally, although it might be a good way of securing the data we have -just added to the partition, we can close the device: - -code{ - - # cryptsetup luksClose live - -}code - -Let's summarize the process. So far, we have created an encryption capable -live system, which can be copied to a usb stick as explained in {Copying an -ISO hybrid image to a USB stick}#copying-iso-hybrid-to-usb. We have also -created an encrypted partition, which can be located in the same usb stick -to carry it around and we have configured the encrypted partition to be used -as persistence store. So now, we only need to boot the live system. At boot -time, live-boot will prompt us for the passphrase and will mount the -encrypted partition to be used for persistence. |