Traditionally, the Linux shell is Bash (Bourne again Shell). When this chapter speaks about “the shell” it means Bash. There are more shells available (ash, csh, ksh, zsh, …), each employing different features and characteristics.

1.1.1 Bash configuration files #

  

A shell can be invoked as an:

1. Interactive login shell.  This is used when logging in to a machine, invoking Bash with the --login option or when logging in to a remote machine with SSH.

2. Interactive non-login shell.  This is normally the case when starting xterm, konsole, gnome-terminal, or similar command line interface (CLI) tools.

3. Non-interactive non-login shell.  This is invoked when invoking a shell script at the command line.

Each shell reads different configuration files. The following tables show the login and non-login shell configuration files.

Tip

Bash looks for its configuration files in a specific order depending on the type of shell where it is run. Find more details on the Bash man page (man 1 bash). Search for the headline INVOCATION.

Table 1.1: Bash configuration files for login shells #

  

File	Description
/etc/profile	Do not modify this file, otherwise your modifications may be destroyed during your next update.
/etc/profile.local	Use this file if you extend /etc/profile
/etc/profile.d/	Contains system-wide configuration files for specific programs
~/.profile	Insert user specific configuration for login shells here

The login shell also sources the configuration files listed under Table 1.2, “Bash configuration files for non-login shells”.

Table 1.2: Bash configuration files for non-login shells #

  

/etc/bash.bashrc	Do not modify this file, otherwise your modifications may be destroyed during your next update.
/etc/bash.bashrc.local	Use this file to insert your system-wide modifications for Bash only
~/.bashrc	Insert user specific configuration here

Additionally, Bash uses multiple files:

Table 1.3: Special files for Bash #

  

File	Description
~/.bash_history	Contains a list of all commands you have typed
~/.bash_logout	Executed when logging out
~/.alias	User defined aliases of frequently used commands. See man 1 alias for more details about defining aliases.

No-Login Shells#

There are special shells that block users from logging into the system: /bin/false and /sbin/nologin. Both fail silently when the user attempts to log into the system. This was intended as a security measure for system users, though modern Linux operating systems have more effective tools for controlling system access, such as PAM and AppArmor.

The default on SUSE Linux Enterprise Desktop is to assign /bin/bash to human users, and /bin/false or /sbin/nologin to system users. The nobody user has /bin/bash for historical reasons, as it is a user with minimum privileges that used to be the default for system users. However, whatever little bit of security gained by using nobody is lost when multiple system users use it. It should be possible to change it to /sbin/nologin; the fastest way to test it is change it and see if it breaks any services or applications.

Use the following command to list which shells are assigned to all users, system and human users, in /etc/passwd. The output varies according to the services and users on your system:

> sort -t: -k 7 /etc/passwd | awk -F: '{print $1"\t" $7}' | column -t
tux               /bin/bash
nobody            /bin/bash
root              /bin/bash
avahi             /bin/false
chrony            /bin/false
dhcpd             /bin/false
dnsmasq           /bin/false
ftpsecure         /bin/false
lightdm           /bin/false
mysql             /bin/false
postfix           /bin/false
rtkit             /bin/false
sshd              /bin/false
tftp              /bin/false
unbound           /bin/false
bin               /sbin/nologin
daemon            /sbin/nologin
ftp               /sbin/nologin
lp                /sbin/nologin
mail              /sbin/nologin
man               /sbin/nologin
nscd              /sbin/nologin
polkitd           /sbin/nologin
pulse             /sbin/nologin
qemu              /sbin/nologin
radvd             /sbin/nologin
rpc               /sbin/nologin
statd             /sbin/nologin
svn               /sbin/nologin
systemd-coredump  /sbin/nologin
systemd-network   /sbin/nologin
systemd-timesync  /sbin/nologin
usbmux            /sbin/nologin
vnc               /sbin/nologin
wwwrun            /sbin/nologin
messagebus        /usr/bin/false
scard             /usr/sbin/nologin

Shell scripts provide a convenient way to perform a wide range of tasks: collecting data, searching for a word or phrase in a text and other useful things. The following example shows a small shell script that prints a text:

#!/bin/sh 1
# Output the following line: 2
echo "Hello World" 3

Before you can run this script, there are a few prerequisites:

If you have fulfilled all the above prerequisites, you can execute the script in the following ways:

Each command can use three channels, either for input or output:

To redirect these channels, there are the following possibilities:

Every channel has a file descriptor: 0 (zero) for standard input, 1 for standard output and 2 for standard error. It is allowed to insert this file descriptor before a < or > character. For example, the following line searches for a file starting with foo, but suppresses its errors by redirecting it to /dev/null:

> find / -name "foo*" 2>/dev/null

An alias is a shortcut definition of one or more commands. The syntax for an alias is:

alias NAME=DEFINITION

For example, the following line defines an alias lt that outputs a long listing (option -l), sorts it by modification time (-t), and prints it in reverse sorted order (-r):

> alias lt='ls -ltr'

To view all alias definitions, use alias. Remove your alias with unalias and the corresponding alias name.

A shell variable can be global or local. Global variables, or environment variables, can be accessed in all shells. In contrast, local variables are visible in the current shell only.

To view all environment variables, use the printenv command. If you need to know the value of a variable, insert the name of your variable as an argument:

> printenv PATH

A variable, be it global or local, can also be viewed with echo:

> echo $PATH

To set a local variable, use a variable name followed by the equal sign, followed by the value:

> PROJECT="SLED"

Do not insert spaces around the equal sign, otherwise you get an error. To set an environment variable, use export:

> export NAME="tux"

To remove a variable, use unset:

> unset NAME

The following table contains common environment variables that you can use in you shell scripts:

> foo.sh "Tux Penguin" 2000

#!/bin/sh
echo \"$1\" \"$2\" \"$3\" \"$4\"

"Tux Penguin" "2000" "" ""

Shells allow you to concatenate and group commands for conditional execution. Each command returns an exit code which determines the success or failure of its operation. If it is 0 (zero) the command was successful, everything else marks an error which is specific to the command.

The following list shows, how commands can be grouped:

To control the flow of your script, a shell has while, if, for and case constructs.

if test $USER = "tux"; then
  echo "Hello Tux."
else
  echo "You are not Tux."
fi

if test -e /tmp/foo.txt ; then
  echo "Found foo.txt"
fi

if [ -e /tmp/foo.txt ] ; then
  echo "Found foo.txt"
fi

for i in *.png; do
 ls -l $i
done

Important information about Bash is provided in the man pages man bash. More about this topic can be found in the following list:

The following chapter provides an introduction to basic usage of sudo.

2.1.1 Running a single command #

  

As a regular user, you can run any command as root by adding sudo before it. This prompts you to provide the root password. If authenticated successfully, this runs the command as root:

> id -un1
tux
> sudo id -un
root's password:2
root
> id -un
tux3
> sudo id -un
4
root

1	The id -un command prints the login name of the current user.
2	The password is not shown during input, neither as clear text nor as masking characters.
3	Only commands that start with sudo run with elevated privileges.
4	The elevated privileges persist for a certain period of time, so you do not need to provide the root password again.

Tip: I/O redirection

When using sudo, I/O redirection does not work:

> sudo echo s > /proc/sysrq-trigger
bash: /proc/sysrq-trigger: Permission denied
> sudo cat < /proc/1/maps
bash: /proc/1/maps: Permission denied

In the example above, only the echo and cat commands run with elevated privileges. The redirection is done by the user's shell with user privileges. To perform redirection with elevated privileges, either start a shell as in Section 2.1.2, “Starting a shell” or use the dd utility:

echo s | sudo dd of=/proc/sysrq-trigger
sudo dd if=/proc/1/maps | cat

2.1.2 Starting a shell #

  

Using sudo every time to run a command with elevated privileges is not always practical. While you can use the sudo bash command, it is recommended to use one of the built-in mechanisms to start a shell:

sudo -s (<command>)

Starts a shell specified by the SHELL environment variable or the target user's default shell. If a command is specified, it is passed to the shell (with the -c option). Otherwise the shell runs in interactive mode.

tux:~ > sudo -s
root's password:
root:/home/tux # exit
tux:~ > 

sudo -i (<command>)

Similar to -s, but starts the shell as a login shell. This means that the shell's start-up files (.profile etc.) are processed, and the current working directory is set to the target user's home directory.

tux:~ > sudo -i
root's password:
root:~ # exit
tux:~ > 

Tip: Environment variables

By default, sudo does not propagate environment variables. This behavior can be changed using the env_reset option (see Useful flags and options).

sudo provides a wide range on configurable options.

Note: Locked yourself out of sudo

If you accidentally locked yourself out of sudo, use su - and the root password to start a root shell. To fix the error, run visudo.

Warning: Example configurations are for demonstration purposes only

The example rules outlined below are purely for demonstration purposes. Use them to understand the general syntax of sudo configuration files. Do not use them in real-world setups, because they do not reflect the complexity of these environments.

# Everything on a line after # is ignored 1
Defaults !insults # Disable the insults flag 2
Defaults env_keep += "DISPLAY HOME" # Add DISPLAY and HOME to env_keep
tux ALL = NOPASSWD: /usr/bin/frobnicate, PASSWD: /usr/bin/journalctl 3

2.2.6 Basic sudoers rules #

  

Each rule follows the following scheme ([] marks optional parts):

#Who      Where         As whom      Tag                What
User_List Host_List = [(User_List)] [NOPASSWD:|PASSWD:] Cmnd_List

sudoers rule syntax #

  

User_List

One or several (separated by comma) identifiers: either a user name, a group in the format %GROUPNAME, or a user ID in the format #UID. Negation can be specified with the ! prefix.

Host_List

One or several (separated by comma) identifiers: either a (fully qualified) host name or an IP address. Negation can be specified with the ! prefix. ALL is a common choice for Host_List.

NOPASSWD:|PASSWD:

The user is not prompted for a password when running commands matching Cmd_List after NOPASSWD:.

PASSWD is the default. It only needs to be specified when both PASSWD and NOPASSWD are on the same line:

tux ALL = PASSWD: /usr/bin/foo, NOPASSWD: /usr/bin/bar

Cmnd_List

One or several (separated by comma) specifiers: a path to an executable, followed by an optional allowed argument.

/usr/bin/foo     # Anything allowed
/usr/bin/foo bar # Only "/usr/bin/foo bar" allowed
/usr/bin/foo ""  # No arguments allowed

ALL can be used as User_List, Host_List, and Cmnd_List.

A rule that allows tux to run all commands as root without entering a password:

tux ALL = NOPASSWD: ALL

A rule that allows tux to run systemctl restart apache2:

tux ALL = /usr/bin/systemctl restart apache2

A rule that allows tux to run wall as admin with no arguments:

tux ALL = (admin) /usr/bin/wall ""

Warning: Unsafe rules

Do not use rules like ALL ALL = ALL without Defaults targetpw. Otherwise anyone can run commands as root.

Important: Winbind and sudo

When specifying the group name in the sudoers file, make sure that you use the NetBIOS domain name instead of the realm, for example:

%DOMAIN\\GROUP_NAME ALL = (ALL) ALL

Keep in mind that when using winbindd, the format also depends on the winbind separator option in the smb.conf file. By default, it is \. If it is changed, for example, to +, then the account format in the sudoers file must be DOMAIN+GROUP_NAME.

Starting graphical applications with sudo normally results in the following error:

> sudo xterm
xterm: Xt error: Can't open display: %s
xterm: DISPLAY is not set

A simple workaround is to use xhost to temporarily allow the root user to access the local user's X session. This is done using the following command:

xhost si:localuser:root

The command below removes the granted access:

xhost -si:localuser:root

Warning: Potential security issue

Running graphical applications with root privileges has security implications. It is recommended to enable root access for a graphical application only as an exception. It is also recommended to revoke the granted root access as soon as the graphical application is closed.

The sudo --help command offers a brief overview of the available command line options, while the man sudoers command provides detailed information about sudoers and its configuration.

YaST has two graphical interfaces: one for use with graphical desktop environments like KDE and GNOME, and an ncurses-based pseudo-graphical interface for use on systems without an X server (see Chapter 4, YaST in text mode).

In the graphical version of YaST, all modules in YaST are grouped by category, and the navigation sidebar allows you to quickly access modules in the desired category. The search field at the top makes it possible to find modules by their names. To find a specific module, enter its name into the search field, and you should see the modules that match the entered string as you type.

Important: List of installed YaST modules

The list of installed modules for the ncurses-based and GUI version of YaST may differ. Before starting any YaST module, verify that it is installed for the version of YaST that you are using.

The graphical version of YaST supports keyboard shortcuts

The following description of the control elements in the YaST modules assumes that all function keys and Alt key combinations work and are not assigned to different global functions. Read Section 4.3, “Restriction of key combinations” for information about possible exceptions.

Figure 4.2: The software installation module #

  

The ncurses-based version of YaST offers several advanced key combinations.

If your window manager uses global Alt combinations, the Alt combinations in YaST may not work. Keys like Alt or Shift can also be occupied by the settings of the terminal.

Besides the text mode interface, YaST provides a command line interface. To get a list of YaST command line options, use the following command:

> sudo yast -h

> sudo yast -i package_name

> sudo yast --install -i package_name

> sudo yast module_name

> sudo yast module_name help

This YaST module does not support the command line interface.

 > sudo yast add-on http://server.name/directory/Lang-AddOn-CD1/

> sudo yast mail summary

Depending on how you use your desktop and whether you want to switch the entire system to another language or only the desktop environment, you have several options:

5.1.1 Modifying system languages with YaST #

  

YaST supports two different language categories:

Primary Language

The primary language set in YaST applies to the entire system, including YaST and the desktop environment. This language is used whenever available unless you manually specify another language.

Secondary Languages

Install secondary languages to make your system multilingual. Languages installed as secondary can be selected manually, when needed. For example, use a secondary language to start an application in a certain language to do word processing in this language.

Before installing additional languages, determine which of them should be the default system language (primary language).

To access the YaST language module, start YaST and click System › Language. Alternatively, start the Languages dialog directly by running sudo yast2 language & from a command line.

Procedure 5.1: Installing additional languages #

  

When installing additional languages, YaST allows you to set different locale settings for the user root, see Step 4. The option Locale Settings for User root determines how the locale variables (LC_*) in the file /etc/sysconfig/language are set for root. You can set them to the same locale as for regular users. Alternatively, you can keep them unaffected by any language changes, or only set the variable RC_LC_CTYPE to the same values as for the regular users. The RC_LC_CTYPE variable sets the localization for language-specific function calls.

1. To add languages in the YaST language module, select the Secondary Languages you want to install.

2. To make a language the default language, set it as Primary Language.

3. Additionally, adapt the keyboard to the new primary language and adjust the time zone, if appropriate.

   

   Tip: Advanced settings

   For advanced keyboard or time zone settings, select Hardware › System Keyboard Layout or System › Date and Time in YaST. For more information, refer to Chapter 32, Setting up your system keyboard layout and Section 5.2, “Changing the country and time settings”.

4. To change language settings specific to the user root, click Details.

   1. Set Locale Settings for User root to the desired value. For more information, click Help.

   2. Decide whether to use Use UTF-8 Encoding for root or not.

5. If your locale was not included in the list of primary languages available, try specifying it with Detailed Locale Setting. However, this may result in certain locales being incomplete.

6. Confirm the changes in the dialogs with OK. If you have selected secondary languages, YaST installs the localized software packages for the additional languages.

The system is now multilingual. However, to start an application in a language other than the primary one, you need to set the desired language explicitly as explained in Section 5.1.3, “Switching languages for standard X and GNOME applications”.

LANG=LANGUAGE application

Using the YaST date and time module, adjust your system date, clock and time zone information to the area you are working in. To access the YaST module, start YaST and click System › Date and Time. Alternatively, start the Clock and Time Zone dialog directly by running sudo yast2 timezone & from a command line.

First, select a general region, such as Europe. Choose an appropriate country that matches the one you are working in, for example, Germany.

Depending on which operating systems run on your workstation, adjust the hardware clock settings accordingly:

Important: Set the hardware clock to UTC

The switch from standard time to daylight saving time (and vice versa) can only be performed automatically when the hardware clock (CMOS clock) is set to UTC. This also applies if you use automatic time synchronization with NTP, because automatic synchronization is only performed if the time difference between the hardware and system clock is less than 15 minutes.

Since a wrong system time can cause serious problems (missed backups, dropped mail messages, mount failures on remote file systems, etc.) it is strongly recommended to always set the hardware clock to UTC.

You can change the date and time manually or opt for synchronizing your machine against an NTP server, either permanently or only for adjusting your hardware clock.

To administer users or groups, start YaST and click Security and Users › User and Group Management. Alternatively, start the User and Group Administration dialog directly by running sudo yast2 users & from a command line.

Figure 6.1: YaST user and group administration #

  

Every user is assigned a system-wide user ID (UID). Apart from the users that can log in to your machine, there are also several system users for internal use only. Each user is assigned to one or more groups. Similar to system users, there are also system groups for internal use.

The main window shows several tabs, depending on the set of users (local users, network users, system users) you choose to view and modify. The tabs allow you to perform the following tasks:

For user and group management, the dialog provides similar functionality. You can easily switch between the user and group administration view by choosing the appropriate tab at the top of the dialog.

Filter options allow you to define the set of users or groups you want to modify: on the Users or Group tab, click Set Filter to view and edit users or groups. They are listed according to certain categories, such as Local Users or LDAP Users, if applicable. With Set Filter › Customize Filter you can also set up and use a custom filter.

Depending on the filter you choose, not all the following options and functions may be available from the dialog.

YaST allows you to create, modify, delete or temporarily disable user accounts. Do not modify user accounts unless you are an experienced user or administrator.

Note: Changing user IDs of existing users

File ownership is bound to the user ID, not to the user name. After a user ID change, the files in the user's home directory are automatically adjusted to reflect this change. However, after an ID change, the user no longer owns the files they created elsewhere in the file system unless the file ownership for those files is manually modified.

The following instructions demonstrate how to set up default user accounts. For further options, refer to Section 6.3, “Additional options for user accounts”.

Warning: Do not rename the root account

While it is technically possible to rename the root account, certain applications, scripts or third-party products may rely on the existence of a user called root. While such a configuration always targets individual environments, necessary adjustments could be overwritten by vendor updates, so this becomes an ongoing task rather than a one-time setting. This is especially true in complex setups involving third-party applications, where it needs to be verified with every vendor involved whether a rename of the root account is supported.

As the implications for renaming the root account cannot be foreseen, SUSE does not support renaming the root account.

Usually, the idea behind renaming the root account is to hide it or make it unpredictable. However, /etc/passwd requires 644 permissions for regular users, so any user of the system can retrieve the login name for the user ID 0. For better ways to secure the root account, refer to Book “Security and Hardening Guide”, Chapter 14 “User management”, Section 14.5 “Restricting root logins” and Book “Security and Hardening Guide”, Chapter 14 “User management”, Section 14.5.3 “Restricting SSH logins”.

Tip: Matching user IDs

It is useful to match the (local) user ID to the ID in the network. For example, a new (local) user on a laptop should be integrated into a network environment with the same user ID. This ensures that the file ownership of the files the user creates “offline” is the same as if they had created them directly on the network.

Besides the settings for a default user account, SUSE® Linux Enterprise Desktop offers further options. For example, options to enforce password policies, use encrypted home directories or define disk quotas for users and groups.

6.3.1 Automatic login and passwordless login #

  

If you use the GNOME desktop environment you can configure Auto Login for a certain user and Passwordless Login for all users. Auto login causes a user to become automatically logged in to the desktop environment on boot. This functionality can only be activated for one user at a time. Login without password allows all users to log in to the system after they have entered their user name in the login manager.

Warning: Security risk

Enabling Auto Login or Passwordless Login on a machine that can be accessed by more than one person is a security risk. Without the need to authenticate, any user can gain access to your system and your data. If your system contains confidential data, do not use this functionality.

To activate auto login or login without password, access these functions in the YaST User and Group Administration with Expert Options › Login Settings.

When creating new local users, several default settings are used by YaST. These include, for example, the group the user belongs to, or the access permissions of the user's home directory. You can change these default settings to meet your requirements:

Local users are assigned to several groups according to the default settings, which you can access from the User and Group Administration dialog on the Defaults for New Users tab. In the following, learn how to modify an individual user's group assignment. If you need to change the default group assignments for new users, refer to Section 6.4, “Changing default settings for local users”.

With YaST you can also easily add, modify or delete groups.

To delete a group, it must not contain any group members. To delete a group, select it from the list and click Delete. Click OK to close the administration dialog and save the changes. Alternatively, to save all changes without exiting the User and Group Administration dialog, click Expert Options › Write Changes Now.

When your machine is connected to a network, you can change the authentication method. The following options are available:

To change the authentication method, proceed as follows:

By default, SUSE Linux Enterprise Desktop creates user names, which cannot be deleted. These users are typically defined in the Linux Standard Base (see https://refspecs.linuxfoundation.org/lsb.shtml). The following list provides the common user names and their purpose:

By default, SLE creates multiple user groups that are used by system services. The following list describes examples of required and common optional groups.

To open the YaST Online Update dialog, start YaST and select Software  › Online Update. Alternatively, start it from the command line with yast2 online_update.

The Online Update window consists of four sections.

Figure 7.1: YaST online update #

  

The Summary section on the left lists the available patches for SUSE Linux Enterprise Desktop. The patches are sorted by security relevance: security, recommended, and optional. You can change the view of the Summary section by selecting one of the following options from Show Patch Category:

Each list entry in the Summary section consists of a symbol and the patch name. For an overview of the possible symbols and their meaning, press Shift–F1. Actions required by Security and Recommended patches are automatically preset. These actions are Autoinstall, Autoupdate and Autodelete.

If you install an up-to-date package from a repository other than the update repository, the requirements of a patch for this package may be fulfilled with this installation. In this case, a check mark is displayed in front of the patch summary. The patch is visible in the list until you mark it for installation. This does not install the patch (because the package already is up to date), but mark the patch as having been installed.

Select an entry in the Summary section to view a short Patch Description at the bottom left corner of the dialog. The upper right section lists the packages included in the selected patch (a patch can consist of several packages). Click an entry in the upper right section to view details about the respective package that is included in the patch.

The YaST Online Update dialog allows you to either install all available patches at once or manually select the desired patches. You may also revert patches that have been applied to the system.

By default, all new patches (except optional ones) that are currently available for your system are already marked for installation. They will be applied automatically once you click Accept or Apply. If one or multiple patches require a system reboot, you will be notified about this before the patch installation starts. You can then either decide to continue with the installation of the selected patches, skip the installation of all patches that need rebooting and install the rest, or go back to the manual patch selection.

Maintenance updates are carefully tested to minimize the risk of introducing a bug. If a patch proves to contain a bug, it is automatically retracted. A new update (with a higher version number) is issued to revert the buggy patch, and is blocked from being installed again. You can see retracted patches, and their history, on the Package Classification tab.

Figure 7.2: Viewing retracted patches and history #

  

You may configure automatic updates with a daily, weekly or monthly schedule with YaST. Install the yast2-online-update-configuration package.

By default, updates are downloaded as delta RPMs. Since rebuilding RPM packages from delta RPMs is a memory- and processor-intensive task, certain setups or hardware configurations may require you to disable the use of delta RPMs for the sake of performance.

Certain patches, such as kernel updates or packages requiring license agreements, require user interaction, which would cause the automatic update procedure to stop. You can configure skipping patches that require user interaction.

Use the Patches tab in the YaST Software module to review available and installed patches, including references to bug reports and CVE bulletins.

The automatic online update does not automatically restart the system afterward. If there are package updates that require a system reboot, you need to do this manually.