Environnement utilisateur

La plupart de ces lignes sont extraites de Linux From Scratch en version 10; ainsi, on parle ici d'un utilisateur appelé lfs. http://www.linuxfromscratch.org/lfs/downloads/stable/LFS-BOOK-10.0.pdf

Créer un utilisateur qui aura son propre environnement

...et par environnement, on parle des variables d'environnement.

Création de l'utilisateur

On créé l'utilisateur, avec un répertoire home (-m) qui ne contient pas de "squelette", soit pas de dossiers dans son home, et bash comme shell (-s):

<source> groupadd lfsuseradd -s /bin/bash -g lfs -m -k /dev/null lfs </source>

puis on en prend le contrôle :

su - lfs

login shell, non login shell

Le - dit à su de nous donner un *login shell*, en opposition à un *non-login shell*. En gros, on veut un shell en lançant la session; pour l'explication, je cite stackexchange (https://unix.stackexchange.com/questions/38175/difference-between-login-shell-and-non-login-shell)

A login shell is the first process that executes under your user ID when you log in for an interactive session. The login process tells the shell to behave as a login shell with a convention: passing argument 0, which is normally the name of the shell executable, with a - character prepended (e.g. -bash whereas it would normally be bash. Login shells typically read a file that does things like setting environment variables: /etc/profile and ~/.profile for the traditional Bourne shell, ~/.bash_profile additionally for bash†, /etc/zprofile and ~/.zprofile for zsh†, /etc/csh.login and ~/.login for csh, etc.

When you log in on a text console, or through SSH, or with su -, you get an interactive login shell. When you log in in graphical mode (on an X display manager), you don't get a login shell, instead you get a session manager or a window manager.

It's rare to run a non-interactive login shell, but some X settings do that when you log in with a display manager, so as to arrange to read the profile files. Other settings (this depends on the distribution and on the display manager) read /etc/profile and ~/.profile explicitly, or don't read them. Another way to get a non-interactive login shell is to log in remotely with a command passed through standard input which is not a terminal, e.g. ssh example.com <my-script-which-is-stored-locally (as opposed to ssh example.com my-script-which-is-on-the-remote-machine, which runs a non-interactive, non-login shell).

When you start a shell in a terminal in an existing session (screen, X terminal, Emacs terminal buffer, a shell inside another, etc.), you get an interactive, non-login shell. That shell might read a shell configuration file (~/.bashrc for bash invoked as bash, /etc/zshrc and ~/.zshrc for zsh, /etc/csh.cshrc and ~/.cshrc for csh, the file indicated by the ENV variable for POSIX/XSI-compliant shells such as dash, ksh, and bash when invoked as sh, $ENV if set and ~/.mkshrc for mksh, etc.).

When a shell runs a script or a command passed on its command line, it's a non-interactive, non-login shell. Such shells run all the time: it's very common that when a program calls another program, it really runs a tiny script in a shell to invoke that other program. Some shells read a startup file in this case (bash runs the file indicated by the BASH_ENV variable, zsh runs /etc/zshenv and ~/.zshenv), but this is risky: the shell can be invoked in all sorts of contexts, and there's hardly anything you can do that might not break something.

bash_profile

On va ensuite donner à cet utilisateur un environnement:

echo "exec env -i HOME=$HOME TERM=$TERM PS1='\u:\w\$ ' /bin/bash" >> ~/.bash_profile

Cette ligne précise que cet utilisateur ne doit pas recevoir le shell habituel de l'OS qui lit le fichier /etc/profile pour gérer tous ses nouveaux shells : il a vraiment un environnement à lui avec les trois variables d'nevironnement données dans la ligne, le tout avec bash. Il a un interactive, non login shell sui ne lit dont pas /etc/profile mais ~/.bashrc

bashrc

Dans le .bashrc, je vais ici mettre: <source> set +h umask 022 LFS=/mnt/lfs LC_ALL=POSIX LFS_TGT=$(uname -m)-lfs-linux-gnu PATH=/usr/binif [ ! -L /bin ]; then PATH=/bin:$PATH; fi PATH=$LFS/tools/bin:$PATH export LFS LC_ALL LFS_TGT PATH </source>

Je reprend les explications de lfs:

set +h

The set +h command turns off bash's hash function. Hashing is ordinarily a useful feature—bash uses a hash table to remember the full path of executable files to avoid searching the PATH time and again to find the same executable. However, the new tools should be used as soon as they are installed. By switching off the hash function, the shell will always search the PATH when a program is to be run. As such, the shell will find the newly compiled tools in $LFS/tools as soon as they are available without remembering a previous version of the same program in a different location.

umask 022

Setting the user file-creation mask (umask) to 022 ensures that newly created files and directories are only writable by their owner, but are readable and executable by anyone (assuming default modes are used by the open(2) system call, new files will end up with permission mode 644 and directories with mode 755).

LFS=/mnt/lfs

The LFS variable should be set to the chosen mount point.

LC_ALL=POSIX

The LC_ALL variable controls the localization of certain programs, making their messages follow the conventions of a specified country. Setting LC_ALL to “POSIX” or “C” (the two are equivalent) ensures that everything will work as expected in the chroot environment.

LFS_TGT=(uname -m)-lfs-linux-gnu

The LFS_TGT variable sets a non-default, but compatible machine description for use when building our cross compiler and linker and when cross compiling our temporary toolchain. More information is contained in Toolchain Technical Notes.

PATH=/usr/bin

Many modern linux distributions have merged /bin and /usr/bin. When this is the case, the standard PATH variable needs just to be set to /usr/bin/ for the Chapter 6 environment. When this is not the case, the following line adds /bin to the path.

if [ ! -L /bin ]; then PATH=/bin:$PATH; fi

If /bin is not a symbolic link, then it has to be added to the PATH variable.

PATH=$LFS/tools/bin:$PATH

By putting $LFS/tools/bin ahead of the standard PATH, the cross-compiler installed at the beginning of Chapter 5 is picked up by the shell immediately after its installation. This, combined with turning off hashing, limits the risk that the compiler from the host be used instead of the cross-compiler.

export LFS LC_ALL LFS_TGT PATH

While the above commands have set some variables, in order to make them visible within any sub-shells, we export them.

La plupart des distros ont un /etc/bash.bashrc qui va modifier notre travail : on peut le donner aux *autres* users du système comme bashrc:

$cp /etc/bash.bashrc {/home/untel/.bashrc,/root/bashrc}

...puis le renommer

*$mv /etc/bash.bashrc /etc/bash.bashrc.NOUSE