From 78b1b83be0cf04b4cba707751b7ad4d97787fe37 Mon Sep 17 00:00:00 2001 From: Ralph Amissah Date: Sat, 27 Nov 2021 21:54:49 -0500 Subject: track document samples used --- .../text/pt_BR/user_customization-runtime.ssi | 441 +++++++++++++++++++++ 1 file changed, 441 insertions(+) create mode 100644 markup/pod/live-manual/media/text/pt_BR/user_customization-runtime.ssi (limited to 'markup/pod/live-manual/media/text/pt_BR/user_customization-runtime.ssi') diff --git a/markup/pod/live-manual/media/text/pt_BR/user_customization-runtime.ssi b/markup/pod/live-manual/media/text/pt_BR/user_customization-runtime.ssi new file mode 100644 index 0000000..3e44cb3 --- /dev/null +++ b/markup/pod/live-manual/media/text/pt_BR/user_customization-runtime.ssi @@ -0,0 +1,441 @@ +: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. -- cgit v1.2.3