A shell can be invoked as an:

Depending on the type of shell you use, different configuration files will be read. The following tables show the login and non-login shell configuration files.

Note that the login shell also sources the configuration files listed under Table 1.2, “Bash Configuration Files for Non-Login Shells”.

Additionally, Bash uses some more files:

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 minimally-privileged user 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:

tux > 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

The following table provides a short overview of the most important higher-level directories that you find on a Linux system. Find more detailed information about the directories and important subdirectories in the following list.

The following list provides more detailed information and gives some examples of which files and subdirectories can be found in the directories:

For example, if you have the script foo.sh you can execute it like this:

tux > foo.sh "Tux Penguin" 2000

To access all the arguments which are passed to your script, you need positional parameters. These are $1 for the first argument, $2 for the second, and so on. You can have up to nine parameters. To get the script name, use $0.

The following script foo.sh prints all arguments from 1 to 4:

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

If you execute this script with the above arguments, you get:

"Tux Penguin" "2000" "" ""

Variable substitutions apply a pattern to the content of a variable either from the left or right side. The following list contains the possible syntax forms:

The if command is used to check expressions. For example, the following code tests whether the current user is Tux:

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

The test expression can be as complex or simple as possible. The following expression checks if the file foo.txt exists:

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

The test expression can also be abbreviated in square brackets:

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

Find more useful expressions at https://bash.cyberciti.biz/guide/If..else..fi.

The for loop allows you to execute commands to a list of entries. For example, the following code prints some information about PNG files in the current directory:

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

Logged in as normal user, you can run any command as root by adding sudo before it. It will prompt for the root password and, if authenticated successfully, run the command as root:

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

Tip: I/O Redirection

I/O redirection does not work as you would probably expect:

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

Only the echo/cat binary is run with elevated privileges, while the redirection is performed by the user's shell with user privileges. You can either start a shell like in Section 2.1.2, “Starting a Shell” or use the dd utility instead:

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

Having to add sudo before every command can be cumbersome. While you could specify a shell as a command sudo bash, it is recommended to rather use one of the built-in mechanisms to start a shell:

By default, sudo does not propagate environment variables:

tux > ENVVAR=test env | grep ENVVAR
ENVVAR=test
tux > ENVVAR=test sudo env | grep ENVVAR
root's password:
1
tux > 

This behavior can be changed by the env_reset option, see Table 2.1, “Useful Flags and Options”.

The main policy configuration file for sudo is /etc/sudoers. As it is possible to lock yourself out of the system because of errors in this file, it is strongly recommended to use visudo for editing. It will prevent simultaneous changes to the opened file and check for syntax errors before saving the modifications.

Despite its name, you can also use editors other than vi by setting the EDITOR environment variable, for example:

sudo EDITOR=/usr/bin/nano visudo

However, the /etc/sudoers file itself is supplied by the system packages and modifications may break on updates. Therefore, it is recommended to put custom configuration into files in the /etc/sudoers.d/ directory. Any file in there is automatically included. To create or edit a file in that subdirectory, run:

sudo visudo -f /etc/sudoers.d/NAME

Alternatively with a different editor (for example nano):

sudo EDITOR=/usr/bin/nano visudo -f /etc/sudoers.d/NAME

Note: Ignored Files in /etc/sudoers.d

The #includedir command in /etc/sudoers, used for /etc/sudoers.d, ignores files that end in ~ (tilde) or contain a . (dot).

For more information on the visudo command, run man 8 visudo.

In the sudoers configuration files, there are two types of options: strings and flags. While strings can contain any value, flags can be turned either ON or OFF. The most important syntax constructs for sudoers configuration files are:

# Everything on a line after a # gets 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

Defaults targetpw # Turn targetpw flag ON

Defaults !rootpw # Turn rootpw flag OFF

Defaults env_reset # Turn env_reset flag ON

# Set env_keep to contain EDITOR and PROMPT
Defaults env_keep = "EDITOR PROMPT"
Defaults env_keep += "JRE_HOME" # Add JRE_HOME
Defaults env_keep -= "JRE_HOME" # Remove JRE_HOME

# Set env_delete to contain EDITOR and PROMPT
Defaults env_delete = "EDITOR PROMPT"
Defaults env_delete += "JRE_HOME" # Add JRE_HOME
Defaults env_delete -= "JRE_HOME" # Remove JRE_HOME

The Defaults token can also be used to create aliases for a collection of users, hosts, and commands. Furthermore, it is possible to apply an option only to a specific set of users.

For detailed information about the /etc/sudoers configuration file, consult man 5 sudoers.

Rules in the sudoers configuration can be very complex, so this section will only cover the basics. Each rule follows the basic scheme ([] marks optional parts):

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

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: Dangerous constructs

Constructs of the kind

ALL ALL = ALL

must not be used 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 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 sudoers file must be DOMAIN+GROUP_NAME.

In cases with special restrictions (“user X can only run command Y as root”) it is not possible. In other cases, it is still favorable to have some kind of separation. By convention, members of the group wheel can run all commands with sudo as root.

When starting graphical applications with sudo, you will encounter the following error:

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

YaST will pick the ncurses interface instead of the graphical one.

To use X.Org in applications started with sudo, the environment variables DISPLAY and XAUTHORITY need to be propagated. To configure this, create the file /etc/sudoers.d/xorg, (see Section 2.2.1, “Editing the Configuration Files”) and add the following line:

Defaults env_keep += "DISPLAY XAUTHORITY"

If not set already, set the XAUTHORITY variable as follows:

export XAUTHORITY=~/.Xauthority

Now X.Org applications can be run as usual:

sudo yast2

If you know the package name and the package is provided by any of your active installation repositories, you can use the command line option -i to install the package:

tux > sudo yast -i package_name

or

tux > sudo yast --install -i package_name

package_name can be a single short package name (for example gvim) installed with dependency checking, or the full path to an RPM package which is installed without dependency checking.

If you need a command line based software management utility with functionality beyond what YaST provides, consider using Zypper. This utility uses the same software management library that is also the foundation for the YaST package manager. The basic usage of Zypper is covered in Section 6.1, “Using Zypper”.

To save time, you can start individual YaST modules directly. To start a module, enter:

tux > sudo yast module_name

View a list of all module names available on your system with yast -l or yast --list. Start the network module, for example, with yast lan.

To use YaST functionality in scripts, YaST provides command line support for individual modules. Not all modules have command line support. To display the available options of a module, enter:

tux > sudo yast module_name help

If a module does not provide command line support, it is started in a text mode and the following message appears:

This YaST module does not support the command line interface.

The following sections describe all YaST modules with command line support, together with a brief explanation of all their commands and available options.

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

tux > sudo yast mail summary

The general syntax of Zypper is:

zypper [--global-options] COMMAND  [--command-options] [arguments]

The components enclosed in brackets are not required. See zypper help for a list of general options and all commands. To get help for a specific command, type zypper help COMMAND.

You can combine all of the above. For example, the following command will install the mc and vim packages from the factory repository while being verbose:

tux > sudo zypper -v install --from factory mc vim

The --from option keeps all repositories enabled (for solving any dependencies) while requesting the package from the specified repository. --repo is an alias for --from, and you may use either one.

Most Zypper commands have a dry-run option that does a simulation of the given command. It can be used for test purposes.

tux > sudo zypper remove --dry-run MozillaFirefox

Zypper supports the global --userdata STRING option. You can specify a string with this option, which gets written to Zypper's log files and plug-ins (such as the Btrfs plug-in). It can be used to mark and identify transactions in log files.

tux > sudo zypper --userdata STRING patch

Zypper subcommands are executables that are stored in the zypper_execdir, /usr/lib/zypper/commands. If a subcommand is not found in the zypper_execdir, Zypper automatically searches the rest of your $PATH for it. This enables writing your own local extensions and storing them in userspace.

Executing subcommands in the Zypper shell, and using global Zypper options are not supported.

List your available subcommands:

tux > zypper help subcommand
[...]
Available zypper subcommands in '/usr/lib/zypper/commands'

  appstream-cache
  lifecycle
  migration
  search-packages

Zypper subcommands available from elsewhere on your $PATH

  <none>

View the help screen for a subcommand:

tux > zypper help appstream-cache

To install or remove packages, use the following commands:

tux > sudo zypper install PACKAGE_NAME
tux > sudo zypper remove PACKAGE_NAME

Warning: Do Not Remove Mandatory System Packages

Do not remove mandatory system packages like glibc , zypper , kernel . If they are removed, the system can become unstable or stop working altogether.

tux > sudo zypper install emacs -vim

tux > sudo zypper remove emacs +vim

tux > sudo zypper install -emacs +vim       # Wrong
tux > sudo zypper install vim -emacs        # Correct
tux > sudo zypper install -- -emacs +vim    # Correct
tux > sudo zypper remove emacs +vim         # Correct

tux > sudo zypper rm --clean-deps PACKAGE_NAME

tux > sudo zypper --non-interactive install PACKAGE_NAME

tux > zypper source-install PACKAGE_NAME

tux > sudo zypper source-install -D PACKAGE_NAME

tux > sudo zypper source-install -d PACKAGE_NAME

tux > zypper search -t srcpackage

tux > zypper source-download

6.1.3.6 Installing Packages from Disabled Repositories #Edit source

Normally you can only install or refresh packages from enabled repositories. The --plus-content TAG option helps you specify repositories to be refreshed, temporarily enabled during the current Zypper session, and disabled after it completes.

For example, to enable repositories that may provide additional -debuginfo or -debugsource packages, use --plus-content debug. You can specify this option multiple times.

To temporarily enable such 'debug' repositories to install a specific -debuginfo package, use the option as follows:

tux > sudo zypper --plus-content debug \
   install "debuginfo(build-id)=eb844a5c20c70a59fc693cd1061f851fb7d046f4"

The build-id string is reported by gdb for missing debuginfo packages.

Note: Disabled Installation Media

Repositories from the SUSE Linux Enterprise Desktop installation media are still configured but disabled after successful installation. You can use the --plus-content option to install packages from the installation media instead of the online repositories. Before calling zypper, ensure the media is available, for example by inserting the DVD into the computer's drive.

tux > zypper verify

tux > sudo zypper install-new-recommends

There are three different ways to update software using Zypper: by installing patches, by installing a new version of a package or by updating the entire distribution. The latter is achieved with zypper dist-upgrade. Upgrading SUSE Linux Enterprise Desktop is discussed in Book “Upgrade Guide”, Chapter 1 “Upgrade Paths and Methods”.

tux > sudo zypper patch

tux > sudo zypper patch --with-update

tux > sudo zypper patch --with-optional

tux > sudo zypper patch --bugzilla=NUMBER

tux > sudo zypper patch --cve=NUMBER

tux > sudo zypper patch --cve=CVE-2010-2713

tux > sudo zypper patch --updatestack-only

tux > zypper list-patches --all --cve
Issue | No.           | Patch             | Category    | Severity  | Status
------+---------------+-------------------+-------------+-----------+----------
cve   | CVE-2015-0287 | SUSE-SLE-Module.. | recommended | moderate  | needed
cve   | CVE-2014-3566 | SUSE-SLE-SERVER.. | recommended | moderate  | not needed
[...]

6.1.4.3 Installing New Package Versions #Edit source

If a repository contains only new packages, but does not provide patches, zypper patch does not show any effect. To update all installed packages with newer available versions, use the following command:

tux > sudo zypper update

Important

zypper update ignores problematic packages. For example, if a package is locked, zypper update omits the package, even if a higher version of it is available. Conversely, zypper patch reports a conflict if the package is considered vulnerable.

To update individual packages, specify the package with either the update or install command:

tux > sudo zypper update PACKAGE_NAME
tux > sudo zypper install PACKAGE_NAME

A list of all new installable packages can be obtained with the command:

tux > zypper list-updates

Note that this command only lists packages that match the following criteria:

• has the same vendor like the already installed package,

• is provided by repositories with at least the same priority than the already installed package,

• is installable (all dependencies are satisfied).

A list of all new available packages (regardless whether installable or not) can be obtained with:

tux > sudo zypper list-updates --all

To find out why a new package cannot be installed, use the zypper install or zypper update command as described above.

tux > sudo zypper packages --orphaned

When patching, updating or removing packages, there may be running processes on the system which continue to use files having been deleted by the update or removal. Use zypper ps to list processes using deleted files. In case the process belongs to a known service, the service name is listed, making it easy to restart the service. By default zypper ps shows a table:

tux > zypper ps
PID   | PPID | UID | User  | Command      | Service      | Files
------+------+-----+-------+--------------+--------------+-------------------
814   | 1    | 481 | avahi | avahi-daemon | avahi-daemon | /lib64/ld-2.19.s->
      |      |     |       |              |              | /lib64/libdl-2.1->
      |      |     |       |              |              | /lib64/libpthrea->
      |      |     |       |              |              | /lib64/libc-2.19->
[...]

The output format of zypper ps can be controlled as follows:

For more information about service handling refer to Chapter 15, The systemd Daemon.

All installation or patch commands of Zypper rely on a list of known repositories. To list all repositories known to the system, use the command:

tux > zypper repos

The result will look similar to the following output:

tux > zypper repos
# | Alias        | Name          | Enabled | Refresh
--+--------------+---------------+---------+--------
1 | SLEHA-12-GEO | SLEHA-12-GEO  | Yes     | No
2 | SLEHA-12     | SLEHA-12      | Yes     | No
3 | SLES12       | SLES12        | Yes     | No

When specifying repositories in various commands, an alias, URI or repository number from the zypper repos command output can be used. A repository alias is a short version of the repository name for use in repository handling commands. Note that the repository numbers can change after modifying the list of repositories. The alias will never change by itself.

By default, details such as the URI or the priority of the repository are not displayed. Use the following command to list all details:

tux > zypper repos -d

tux > sudo zypper addrepo URI ALIAS

6.1.6.2 Refreshing Repositories #Edit source

zypper enables you to fetch changes in packages from configured repositories. To fetch the changes, run:

tux > sudo zypper refresh

Note: Default Behavior of zypper

By default, some commands perform refresh automatically, so you do not need to run the command explicitly.

The refresh command enables you to view changes also in disabled repositories, by using the --plus-content option:

tux > sudo zypper --plus-content refresh

This option fetches changes in repositories, but keeps the disabled repositories in the same state—disabled.

tux > sudo zypper removerepo 1
tux > sudo zypper removerepo "SLEHA-12-GEO"

tux > sudo zypper modifyrepo -er -p 20 'updates'

tux > sudo zypper renamerepo 'Mozilla Firefox' firefox

Zypper offers various methods to query repositories or packages. To get lists of all products, patterns, packages or patches available, use the following commands:

tux > zypper products
tux > zypper patterns
tux > zypper packages
tux > zypper patches

To query all repositories for certain packages, use search. To get information regarding particular packages, use the info command.

tux > zypper search-packages package1 package2

tux > zypper what-provides 'perl(SVN::Core)'

tux > zypper info --requires MozillaFirefox

SUSE products are generally supported for 10 years. Often, you can extend that standard lifecycle by using the extended support offerings of SUSE which add three years of support. Depending on your product, find the exact support lifecycle at https://www.suse.com/lifecycle.

To check the lifecycle of your product and the supported package, use the zypper lifecycle command as shown below:

root # zypper lifecycle

Product end of support
Codestream: SUSE Linux Enterprise Server 15             2028-07-31
    SUSE Linux Enterprise Server 15                     n/a*

Module end of support
Basesystem Module                                       n/a*
Server Applications Module                              n/a*

Package end of support if different from product:
SUSEConnect                              Now, installed 0.3.11-1.4, update available 0.3.11-3.3.1
ca-certificates-mozilla                  Now, installed 2.22-2.12, update available 2.24-4.3.1
curl                                     Now, installed 7.60.0-1.1, update available 7.60.0-3.3.1
e2fsprogs                                Now, installed 1.43.8-2.44, update available 1.43.8-4.3.1
glibc                                    Now, installed 2.26-11.8, update available 2.26-13.3.1

Zypper now comes with a configuration file, allowing you to permanently change Zypper's behavior (either system-wide or user-specific). For system-wide changes, edit /etc/zypp/zypper.conf. For user-specific changes, edit ~/.zypper.conf. If ~/.zypper.conf does not yet exist, you can use /etc/zypp/zypper.conf as a template: copy it to ~/.zypper.conf and adjust it to your liking. Refer to the comments in the file for help about the available options.

If you have trouble accessing packages from configured repositories (for example, Zypper cannot find a certain package even though you know it exists in one of the repositories), refreshing the repositories may help:

tux > sudo zypper refresh

If that does not help, try

tux > sudo zypper refresh -fdb

This forces a complete refresh and rebuild of the database, including a forced download of raw metadata.

If the Btrfs file system is used on the root partition and snapper is installed, Zypper automatically calls snapper when committing changes to the file system to create appropriate file system snapshots. These snapshots can be used to revert any changes made by Zypper. See Chapter 7, System Recovery and Snapshot Management with Snapper for more information.

For more information on managing software from the command line, enter zypper help, zypper help  COMMAND or refer to the zypper(8) man page. For a complete and detailed command reference, cheat sheets with the most important commands, and information on how to use Zypper in scripts and applications, refer to https://en.opensuse.org/SDB:Zypper_usage. A list of software changes for the latest SUSE Linux Enterprise Desktop version can be found at https://en.opensuse.org/openSUSE:Zypper_versions.

RPM packages have a GPG signature. To verify the signature of an RPM package, use the command rpm --checksig  PACKAGE-1.2.3.rpm to determine whether the package originates from SUSE or from another trustworthy facility. This is especially recommended for update packages from the Internet.

While fixing issues in the operating system, you might need to install a Problem Temporary Fix (PTF) into a production system. The packages provided by SUSE are signed against a special PTF key. However, in contrast to SUSE Linux Enterprise 11, this key is not imported by default on SUSE Linux Enterprise 12 systems. To manually import the key, use the following command:

tux > sudo rpm --import \
/usr/share/doc/packages/suse-build-key/suse_ptf_key.asc

After importing the key, you can install PTF packages on your system.

Normally, the installation of an RPM archive is quite simple: rpm -i PACKAGE.rpm. With this command the package is installed, but only if its dependencies are fulfilled and if there are no conflicts with other packages. With an error message, rpm requests those packages that need to be installed to meet dependency requirements. In the background, the RPM database ensures that no conflicts arise—a specific file can only belong to one package. By choosing different options, you can force rpm to ignore these defaults, but this is only for experts. Otherwise, you risk compromising the integrity of the system and possibly jeopardize the ability to update the system.

The options -U or --upgrade and -F or --freshen can be used to update a package (for example, rpm -F PACKAGE.rpm). This command removes the files of the old version and immediately installs the new files. The difference between the two versions is that -U installs packages that previously did not exist in the system, while -F merely updates previously installed packages. When updating, rpm updates configuration files carefully using the following strategy:

Following an update, .rpmsave and .rpmnew files should be removed after comparing them, so they do not obstruct future updates. The .rpmorig extension is assigned if the file has not previously been recognized by the RPM database.

Otherwise, .rpmsave is used. In other words, .rpmorig results from updating from a foreign format to RPM. .rpmsave results from updating from an older RPM to a newer RPM. .rpmnew does not disclose any information to whether the system administrator has made any changes to the configuration file. A list of these files is available in /var/adm/rpmconfigcheck. Some configuration files (like /etc/httpd/httpd.conf) are not overwritten to allow continued operation.

The -U switch is not only an equivalent to uninstalling with the -e option and installing with the -i option. Use -U whenever possible.

To remove a package, enter rpm -e PACKAGE. This command only deletes the package if there are no unresolved dependencies. It is theoretically impossible to delete Tcl/Tk, for example, as long as another application requires it. Even in this case, RPM calls for assistance from the database. If such a deletion is, for whatever reason, impossible (even if no additional dependencies exist), it may be helpful to rebuild the RPM database using the option --rebuilddb.

Delta RPM packages contain the difference between an old and a new version of an RPM package. Applying a delta RPM onto an old RPM results in a completely new RPM. It is not necessary to have a copy of the old RPM because a delta RPM can also work with an installed RPM. The delta RPM packages are even smaller in size than patch RPMs, which is an advantage when transferring update packages over the Internet. The drawback is that update operations with delta RPMs involved consume considerably more CPU cycles than plain or patch RPMs.

The makedeltarpm and applydelta binaries are part of the delta RPM suite (package deltarpm) and help you create and apply delta RPM packages. With the following commands, you can create a delta RPM called new.delta.rpm. The following command assumes that old.rpm and new.rpm are present:

tux > sudo makedeltarpm old.rpm new.rpm new.delta.rpm

Using applydeltarpm, you can reconstruct the new RPM from the file system if the old package is already installed:

tux > sudo applydeltarpm new.delta.rpm new.rpm

To derive it from the old RPM without accessing the file system, use the -r option:

tux > sudo applydeltarpm -r old.rpm new.delta.rpm new.rpm

See /usr/share/doc/packages/deltarpm/README for technical details.

With the -q option rpm initiates queries, making it possible to inspect an RPM archive (by adding the option -p) and to query the RPM database of installed packages. Several switches are available to specify the type of information required. See Table 6.1, “The Most Important RPM Query Options”.

For example, the command rpm -q -i wget displays the information shown in Example 6.2, “rpm -q -i wget”.

Name        : wget
Version     : 1.14
Release     : 17.1
Architecture: x86_64
Install Date: Mon 30 Jan 2017 14:01:29 CET
Group       : Productivity/Networking/Web/Utilities
Size        : 2046483
License     : GPL-3.0+
Signature   : RSA/SHA256, Thu 08 Dec 2016 07:48:44 CET, Key ID 70af9e8139db7c82
Source RPM  : wget-1.14-17.1.src.rpm
Build Date  : Thu 08 Dec 2016 07:48:34 CET
Build Host  : sheep09
Relocations : (not relocatable)
Packager    : https://www.suse.com/
Vendor      : SUSE LLC <https://www.suse.com/>
URL         : http://www.gnu.org/software/wget/
Summary     : A Tool for Mirroring FTP and HTTP Servers
Description :
Wget enables you to retrieve WWW documents or FTP files from a server.
This can be done in script files or via the command line.
Distribution: SUSE Linux Enterprise 12

The option -f only works if you specify the complete file name with its full path. Provide as many file names as desired. For example:

tux > rpm -q -f /bin/rpm /usr/bin/wget
rpm-4.11.2-15.1.x86_64
wget-1.14-17.1.x86_64

If only part of the file name is known, use a shell script as shown in Example 6.3, “Script to Search for Packages”. Pass the partial file name to the script shown as a parameter when running it.

#! /bin/sh
for i in $(rpm -q -a -l | grep $1); do
    echo "\"$i\" is in package:"
    rpm -q -f $i
    echo ""
done

The command rpm -q --changelog PACKAGE displays a detailed list of change information about a specific package, sorted by date.

With the installed RPM database, verification checks can be made. Initiate these with -V, or --verify. With this option, rpm shows all files in a package that have been changed since installation. rpm uses eight character symbols to give some hints about the following changes: