Professional Documents
Culture Documents
Introduction
In recent years, Linux distributions have increasingly transitioned from other init
systems to systemd. Thesystemd suite of tools provides a fast and flexible init model
for managing an entire machine from boot onwards.
In this guide, we'll give you a quick run through of the most important commands
you'll want to know for managing a systemd enabled server. These should work on
any server that implements systemd (any OS version at or above Ubuntu 15.04,
Debian 8, CentOS 7, Fedora 15). Let's get started.
All of the normal init system commands have equivalent actions with
the systemctl command. We will use the nginx.service unit to demonstrate (you'll have
to install Nginx with your package manager to get this service file).
DEBIAN Page 1
sudo systemctl restart nginx.service
To attempt to reload the service without interrupting normal functionality, we can
type:
For instance, to get all of the unit files that systemd has listed as "active", type (you
can actually leave off the list-units as this is the default systemctl behavior):
systemctl list-units
To list all of the units that systemd has loaded or attempted to load into memory,
including those that are not currently active, add the --all switch:
systemctl list-unit-files
DEBIAN Page 2
A systemd component called journald collects and manages journal entries from all
parts of the system. This is basically log information from applications and the kernel.
journalctl
By default, this will show you entries from the current and previous boots if journald is
configured to save previous boot records. Some distributions enable this by default,
while others do not (to enable this, either edit the /etc/systemd/journald.conf file and
set the Storage= option to "persistent", or create the persistent directory by
typing sudo mkdir -p /var/log/journal).
If you only wish to see the journal entries from the current boot, add the -b flag:
journalctl -b
To see only kernel messages, such as those that are typically represented by dmesg,
you can use the -kflag:
journalctl -k
Again, you can limit this only to the current boot by appending the -b flag:
journalctl -k -b
To see an overview of the current state of a unit, you can use the status option with
the systemctlcommand. This will show you whether the unit is active, information
about the process, and the latest journal entries:
journalctl -u nginx.service
As always, you can limit the entries to the current boot by adding the -b flag:
DEBIAN Page 3
journalctl -b -u nginx.service
A unit file contains the parameters that systemd uses to manage and run a unit. To
see the full contents of a unit file, type:
To add a unit file snippet, which can be used to append or override settings in the
default unit file, simply call the edit option on the unit:
DEBIAN Page 4
If you prefer to modify the entire content of the unit file instead of creating a snippet,
pass the --full flag:
In systemd, "targets" are used instead. Targets are basically synchronization points
that the server can used to bring the server into a specific state. Service and other
unit files can be tied to a target and multiple targets can be active at the same time.
systemctl get-default
You can change the default target that will be used at boot by using the set-
default option:
DEBIAN Page 5
sudo systemctl isolate multi-user.target
Next Steps
By now, you should know the basics of how to manage a server that uses systemd.
However, there is much more to learn as your needs expand. Below are links to
guides with more in-depth information about some of the components we discussed
in this guide:
By learning how to leverage your init system's strengths, you can control the state of
your machines and more easily manage your services and processes.
Introduction
Systemd is an init system and system manager that is widely becoming the new
DEBIAN Page 6
Systemd is an init system and system manager that is widely becoming the new
standard for Linux machines. While there are considerable opinions about
whether systemd is an improvement over the traditional SysV init systems it is
replacing, the majority of distributions plan to adopt it or have already done so.
Due to its heavy adoption, familiarizing yourself with systemd is well worth the
trouble, as it will make administrating these servers considerably easier. Learning
about and utilizing the tools and daemons that comprise systemd will help you better
appreciate the power, flexibility, and capabilities it provides, or at least help you to do
your job with minimal hassle.
In this guide, we will be discussing the systemctl command, which is the central
management tool for controlling the init system. We will cover how to manage
services, check statuses, change system states, and work with the configuration
files.
Service Management
The fundamental purpose of an init system is to initialize the components that must
be started after the Linux kernel is booted (traditionally known as "userland"
components). The init system is also used to manage services and daemons for the
server at any point while the system is running. With that in mind, we will start with
some simple service management operations.
In systemd, the target of most actions are "units", which are resources
that systemd knows how to manage. Units are categorized by the type of resource
they represent and they are defined with files known as unit files. The type of each
unit can be inferred from the suffix on the end of the file.
For service management tasks, the target unit will be service units, which have unit
files with a suffix of.service. However, for most service management commands, you
can actually leave off the .servicesuffix, as systemd is smart enough to know that you
probably want to operate on a service when using service management commands.
DEBIAN Page 7
sudo systemctl start application.service
As we mentioned above, systemd knows to look for *.service files for service
management commands, so the command could just as easily be typed like this:
To stop a currently running service, you can use the stop command instead:
DEBIAN Page 8
To disable the service from starting automatically, you can type:
Keep in mind that enabling a service does not start it in the current session. If you
wish to start the service and enable it at boot, you will have to issue both
the start and enable commands.
For instance, when checking the status of an Nginx server, you may see output like
this:
Jan 27 19:41:23 desktop systemd[1]: Starting A high performance web server and a reverse
proxy server...
Jan 27 19:41:23 desktop systemd[1]: Started A high performance web server and a reverse
proxy server.
This gives you a nice overview of the current status of the application, notifying you
of any problems and any actions that may be required.
There are also methods for checking for specific states. For instance, to check to see
if a unit is currently active (running), you can use the is-active command:
To see if the unit is enabled, you can use the is-enabled command:
DEBIAN Page 9
systemctl is-enabled application.service
This will output whether the service is enabled or disabled and will again set the exit
code to "0" or "1" depending on the answer to the command question.
A third check is whether the unit is in a failed state. This indicates that there was a
problem starting the unit in question:
systemctl list-units
This will show you a list of all of the units that systemd currently has active on the
system. The output will look something like this:
DEBIAN Page 10
Since the list-units command shows only active units by default, all of the entries
above will show "loaded" in the LOAD column and "active" in the ACTIVE column.
This display is actually the default behavior of systemctl when called without
additional commands, so you will see the same thing if you call systemctl with no
arguments:
systemctl
We can tell systemctl to output different information by adding additional flags. For
instance, to see all of the units that systemd has loaded (or attempted to load),
regardless of whether they are currently active, you can use the --all flag, like this:
You can use other flags to filter these results. For example, we can use the --
state= flag to indicate the LOAD, ACTIVE, or SUB states that we wish to see. You
will have to keep the --all flag so that systemctlallows non-active units to be displayed:
systemctl list-unit-files
Units are representations of resources that systemd knows about. Since systemd has
not necessarily read all of the unit definitions in this view, it only presents information
about the files themselves. The output has two columns: the unit file and the state.
DEBIAN Page 11
UNIT FILE STATE
proc-sys-fs-binfmt_misc.automount static
dev-hugepages.mount static
dev-mqueue.mount static
proc-fs-nfsd.mount static
proc-sys-fs-binfmt_misc.mount static
sys-fs-fuse-connections.mount static
sys-kernel-config.mount static
sys-kernel-debug.mount static
tmp.mount static
var-lib-nfs-rpc_pipefs.mount static
org.cups.cupsd.path enabled
...
The state will usually be "enabled", "disabled", "static", or "masked". In this context,
static means that the unit file does not contain an "install" section, which is used to
enable a unit. As such, these units cannot be enabled. Usually, this means that the
unit performs a one-off action or is used only as a dependency of another unit and
should not be run by itself.
Unit Management
So far, we have been working with services and displaying information about the unit
and unit files thatsystemd knows about. However, we can find out more specific
information about units using some additional commands.
Displaying Dependencies
To see a unit's dependency tree, you can use the list-dependencies command:
DEBIAN Page 12
systemctl list-dependencies sshd.service
This will display a hierarchy mapping the dependencies that must be dealt with in
order to start the unit in question. Dependencies, in this context, include those units
that are either required by or wanted by the units above it.
sshd.service
system.slice
basic.target
microcode.service
rhel-autorelabel-mark.service
rhel-autorelabel.service
rhel-configure.service
rhel-dmesg.service
rhel-loadmodules.service
paths.target
slices.target
...
The recursive dependencies are only displayed for .target units, which indicate
system states. To recursively list all dependencies, include the --all flag.
To show reverse dependencies (units that depend on the specified unit), you can
add the --reverse flag to the command. Other flags that are useful are the --
before and --after flags, which can be used to show units that depend on the specified
unit starting before and after themselves, respectively.
DEBIAN Page 13
We saw in the service management section how to stop or disable a service,
but systemd also has the ability to mark a unit as completely unstartable,
automatically or manually, by linking it to /dev/null. This is called masking the unit,
and is possible with the mask command:
If you check the list-unit-files, you will see the service is now listed as masked:
systemctl list-unit-files
...
kmod-static-nodes.service static
ldconfig.service static
mandb.service static
messagebus.service static
nginx.service masked
quotaon.service static
rc-local.service static
rdisc.service disabled
rescue.service static
...
If you attempt to start the service, you will see a message like this:
The edit command, by default, will open a unit file snippet for the unit in question:
DEBIAN Page 14
Within this directory, a snippet will be created called override.conf. When the unit is
loaded, systemdwill, in memory, merge the override snippet with the full unit file. The
snippet's directives will take precedence over those found in the original unit file.
If you wish to edit the full unit file instead of creating a snippet, you can pass the --
full flag:
To remove any additions you have made, either delete the unit's .d configuration
directory or the modified service file from /etc/systemd/system. For instance, to
remove a snippet, we could type:
sudo rm -r /etc/systemd/system/nginx.service.d
To remove a full modified unit file, we would type:
sudo rm /etc/systemd/system/nginx.service
After deleting the file or directory, you should reload the systemd process so that it no
longer attempts to reference these files and reverts back to using the system copies.
You can do this by typing:
This can be used in order to bring the system to certain states, much like other init
systems use runlevels. They are used as a reference for when certain functions are
available, allowing you to specify the desired state instead of the individual units
needed to produce that state.
For instance, there is a swap.target that is used to indicate that swap is ready for use.
DEBIAN Page 15
For instance, there is a swap.target that is used to indicate that swap is ready for use.
Units that are part of this process can sync with this target by indicating in their
configuration that they are WantedBy= orRequiredBy= the swap.target. Units that
require swap to be available can specify this condition using the Wants=, Requires=,
and After= specifications to indicate the nature of their relationship.
systemctl get-default
multi-user.target
If you wish to set a different default target, you can use the set-default. For instance,
if you have a graphical desktop installed and you wish for the system to boot into that
by default, you can change your default target accordingly:
Isolating Targets
It is possible to start all of the units associated with a target and stop all units that are
not part of the dependency tree. The command that we need to do this is called,
appropriately, isolate. This is similar to changing the runlevel in other init systems.
You may wish to take a look at the dependencies of the target you are isolating
DEBIAN Page 16
You may wish to take a look at the dependencies of the target you are isolating
before performing this procedure to ensure that you are not stopping vital services:
For instance, to put the system into rescue (single-user) mode, you can just use
the rescue command instead of isolate rescue.target:
sudo reboot
Conclusion
By now, you should be familiar with some of the basic capabilities of
the systemctl command that allow you to interact with and control
your systemd instance. The systemctl utility will be your main point of interaction for
service and system state management.
DEBIAN Page 17
service and system state management.
While systemctl operates mainly with the core systemd process, there are other
components to thesystemd ecosystem that are controlled by other utilities. Other
capabilities, like log management and user sessions are handled by separate
daemons and management utilities (journald/journalctl andlogind/loginctl respectively).
Taking time to become familiar with these other tools and daemons will make
management an easier task.
From <https://www.digitalocean.com/community/tutorials/how-to-use-systemctl-to-manage-systemd-services-and-units>
DEBIAN Page 18
Journalctl
ponedeljak, 12. septembar 2016. 11.20
Introduction
Some of the most compelling advantages of systemd are those involved with process
and system logging. When using other tools, logs are usually dispersed throughout
the system, handled by different daemons and processes, and can be fairly difficult
to interpret when they span multiple applications.Systemd attempts to address these
issues by providing a centralized management solution for logging all kernel and
userland processes. The system that collects and manages these logs is known as
the journal.
The journal is implemented with the journald daemon, which handles all of the
messages produced by the kernel, initrd, services, etc. In this guide, we will discuss
how to use the journalctl utility, which can be used to access and manipulate the data
held within the journal.
General Idea
One of the impetuses behind the systemd journal is to centralize the management of
logs regardless of where the messages are originating. Since much of the boot
process and service management is handled by the systemd process, it makes
sense to standardize the way that logs are collected and accessed.
Thejournald daemon collects data from all available sources and stores them in a
binary format for easy and dynamic manipulation.
This gives us a number of significant advantages. By interacting with the data using
a single utility, administrators are able to dynamically display log data according to
their needs. This can be as simple as viewing the boot data from three boots ago, or
combining the log entries sequentially from two related services to debug a
communication issue.
Storing the log data in a binary format also means that the data can be displayed in
DEBIAN Page 19
Storing the log data in a binary format also means that the data can be displayed in
arbitrary output formats depending on what you need at the moment. For instance,
for daily log management you may be used to viewing the logs in the
standard syslog format, but if you decide to graph service interruptions later on, you
can output each entry as a JSON object to make it consumable to your graphing
service. Since the data is not written to disk in plain text, no conversion is needed
when you need a different on-demand format.
The systemd journal can either be used with an existing syslog implementation, or it
can replace thesyslog functionality, depending on your needs. While
the systemd journal will cover most administrator's logging needs, it can also
complement existing logging mechanisms. For instance, you may have a
centralized syslog server that you use to compile data from multiple servers, but you
also may wish to interleave the logs from multiple services on a single system with
the systemd journal. You can do both of these by combining these technologies.
Because of this, before we get started with the journal, we will make sure the
timezone is set up correctly. The systemd suite actually comes with a tool
called timedatectl that can help with this.
First, see what timezones are available with the list-timezones option:
timedatectl list-timezones
This will list the timezones available on your system. When you find the one that
matches the location of your server, you can set it by using the set-timezone option:
timedatectl status
Local time: Thu 2015-02-05 14:08:06 EST
Universal time: Thu 2015-02-05 19:08:06 UTC
RTC time: Thu 2015-02-05 19:08:06
Time zone: America/New_York (EST, -0500)
DEBIAN Page 20
Time zone: America/New_York (EST, -0500)
NTP enabled: no
NTP synchronized: no
RTC in local TZ: no
DST active: n/a
The first line should display the correct time.
When used alone, every journal entry that is in the system will be displayed within a
pager (usually less) for you to browse. The oldest entries will be up top:
journalctl
-- Logs begin at Tue 2015-02-03 21:48:52 UTC, end at Tue 2015-02-03 22:29:38 UTC. --
Feb 03 21:48:52 localhost.localdomain systemd-journal[243]: Runtime journal is using 6.2M (max
allowed 49.
Feb 03 21:48:52 localhost.localdomain systemd-journal[243]: Runtime journal is using 6.2M (max
allowed 49.
Feb 03 21:48:52 localhost.localdomain systemd-journald[139]: Received SIGTERM from PID 1
(systemd).
Feb 03 21:48:52 localhost.localdomain kernel: audit: type=1404 audit(1423000132.274:2):
enforcing=1 old_en
Feb 03 21:48:52 localhost.localdomain kernel: SELinux: 2048 avtab hash slots, 104131 rules.
Feb 03 21:48:52 localhost.localdomain kernel: SELinux: 2048 avtab hash slots, 104131 rules.
Feb 03 21:48:52 localhost.localdomain kernel: input: ImExPS/2 Generic Explorer Mouse as
/devices/platform/
Feb 03 21:48:52 localhost.localdomain kernel: SELinux: 8 users, 102 roles, 4976 types, 294
bools, 1 sens,
Feb 03 21:48:52 localhost.localdomain kernel: SELinux: 83 classes, 104131 rules
...
You will likely have pages and pages of data to scroll through, which can be tens or
hundreds of thousands of lines long if systemd has been on your system for a long
while. This demonstrates how much data is available in the journal database.
The format will be familiar to those who are used to standard syslog logging.
However, this actually collects data from more sources than
traditional syslog implementations are capable of. It includes logs from the early boot
process, the kernel, the initrd, and application standard error and out. These are all
available in the journal.
You may notice that all of the timestamps being displayed are local time. This is
available for every log entry now that we have our local time set correctly on our
system. All of the logs are displayed using this new information.
If you want to display the timestamps in UTC, you can use the --utc flag:
journalctl --utc
DEBIAN Page 21
Journal Filtering by Time
While having access to such a large collection of data is definitely useful, such a
large amount of information can be difficult or impossible to inspect and process
mentally. Because of this, one of the most important features of journalctl is its
filtering options.
journalctl -b
This will help you identify and manage information that is pertinent to your current
environment.
In cases where you aren't using this feature and are displaying more than one day of
boots, you will see that journalctl has inserted a line that looks like this whenever the
system went down:
...
-- Reboot --
...
This can be used to help you logically separate the information into boot sessions.
Past Boots
While you will commonly want to display the information from the current boot, there
are certainly times when past boots would be helpful as well. The journal can save
information from many previous boots, sojournalctl can be made to display
information easily.
Some distributions enable saving previous boot information by default, while others
disable this feature. To enable persistent boot information, you can either create the
directory to store the journal by typing:
DEBIAN Page 22
persistent logging:
/etc/systemd/journald.conf
...
[Journal]
Storage=persistent
When saving previous boots is enabled on your server, journalctl provides some
commands to help you work with boots as a unit of division. To see the boots
that journald knows about, use the --list-boots option with journalctl:
journalctl --list-boots
-2 caf0524a1d394ce0bdbcff75b94444fe Tue 2015-02-03 21:48:52 UTCTue 2015-02-03 22:17:00
UTC
-1 13883d180dc0420db0abcb5fa26d6198 Tue 2015-02-03 22:17:03 UTCTue 2015-02-03 22:19:08 UTC
0 bed718b17a73415fade0e4e7f4bea609 Tue 2015-02-03 22:19:12 UTCTue 2015-02-03 23:01:01 UTC
This will display a line for each boot. The first column is the offset for the boot that
can be used to easily reference the boot with journalctl. If you need an absolute
reference, the boot ID is in the second column. You can tell the time that the boot
session refers to with the two time specifications listed towards the end.
To display information from these boots, you can use information from either the first
or second column.
For instance, to see the journal from the previous boot, use the -1 relative pointer
with the -b flag:
journalctl -b -1
You can also use the boot ID to call back the data from a boot:
journalctl -b caf0524a1d394ce0bdbcff75b94444fe
Time Windows
While seeing log entries by boot is incredibly useful, often you may wish to request
windows of time that do not align well with system boots. This may be especially true
when dealing with long-running servers with significant uptime.
You can filter by arbitrary time limits using the --since and --until options, which
restrict the entries displayed to those after or before the given time, respectively.
The time values can come in a variety of formats. For absolute time values, you
should use the following format:
YYYY-MM-DD HH:MM:SS
For instance, we can see all of the entries since January 10th, 2015 at 5:15 PM by
DEBIAN Page 23
For instance, we can see all of the entries since January 10th, 2015 at 5:15 PM by
typing:
By Unit
Perhaps the most useful way of filtering is by the unit you are interested in. We can
use the -u option to filter in this way.
For instance, to see all of the logs from an Nginx unit on our system, we can type:
journalctl -u nginx.service
Typically, you would probably want to filter by time as well in order to display the
lines you are interested in. For instance, to check on how the service is running
today, you can type:
DEBIAN Page 24
today, you can type:
To do this we can filter by specifying the _PID field. For instance if the PID we're
interested in is 8088, we could type:
journalctl _PID=8088
At other times, you may wish to show all of the entries logged from a specific user or
group. This can be done with the _UID or _GID filters. For instance, if your web
server runs under the www-data user, you can find the user ID by typing:
id -u www-data
33
Afterwards, you can use the ID that was returned to filter the journal results:
The leading underscore indicates that the _PID field is of the latter type. The journal
automatically records and indexes the PID of the process that is logging for later
filtering. You can find out about all of the available journal fields by typing:
man systemd.journal-fields
We will be discussing some of these in this guide. For now though, we will go over
one more useful option having to do with filtering by these fields. The -F option can
be used to show all of the available values for a given journal field.
DEBIAN Page 25
For instance, to see which group IDs the systemd journal has entries for, you can
type:
journalctl -F _GID
32
99
102
133
81
84
100
0
124
87
This will show you all of the values that the journal has stored for the group ID field.
This can help you construct your filters.
By Component Path
We can also filter by providing a path location.
If the path leads to an executable, journalctl will display all of the entries that involve
the executable in question. For instance, to find those entries that involve
the bash executable, you can type:
journalctl /usr/bin/bash
Usually, if a unit is available for the executable, that method is cleaner and provides
better info (entries from associated child processes, etc). Sometimes, however, this
is not possible.
To display only these messages, we can add the -k or --dmesg flags to our
command:
journalctl -k
By default, this will display the kernel messages from the current boot. You can
specify an alternative boot using the normal boot selection flags discussed
previously. For instance, to get the messages from five boots ago, you could type:
journalctl -k -b -5
By Priority
DEBIAN Page 26
One filter that system administrators often are interested in is the message priority.
While it is often useful to log information at a very verbose level, when actually
digesting the available information, low priority logs can be distracting and confusing.
You can use journalctl to display only messages of a specified priority or above by
using the -p option. This allows you to filter out lower priority messages.
For instance, to show only entries logged at the error level or above, you can type:
journalctl -p err -b
This will show you all messages marked as error, critical, alert, or emergency. The
journal implements the standard syslog message levels. You can use either the
priority name or its corresponding numeric value. In order of highest to lowest
priority, these are:
0: emerg
1: alert
2: crit
3: err
4: warning
5: notice
6: info
7: debug
The above numbers or names can be used interchangeably with the -p option.
Selecting a priority will display messages marked at the specified level and those
above it.
By default, journalctl will show the entire entry in the pager, allowing the entries to
trail off to the right of the screen. This info can be accessed by pressing the right
arrow key.
DEBIAN Page 27
arrow key.
If you'd rather have the output truncated, inserting an ellipsis where information has
been removed, you can use the --no-full option:
journalctl --no-full
...
Feb 04 20:54:13 journalme sshd[937]: Failed password for root from 83.234.207.60...h2
Feb 04 20:54:13 journalme sshd[937]: Connection closed by 83.234.207.60 [preauth]
Feb 04 20:54:13 journalme sshd[937]: PAM 2 more authentication failures; logname...ot
You can also go in the opposite direction with this and tell journalctl to display all of
its information, regardless of whether it includes unprintable characters. We can do
this with the -a flag:
journalctl -a
journalclt --no-pager
This can be piped immediately into a processing utility or redirected into a file on
disk, depending on your needs.
Output Formats
If you are processing journal entries, as mentioned above, you most likely will have
an easier time parsing the data if it is in a more consumable format. Luckily, the
journal can be displayed in a variety of formats as needed. You can do this using
the -o option with a format specifier.
For instance, you can output the journal entries in JSON by typing:
DEBIAN Page 28
"/usr/lib/systemd/systemd", "_SYSTEMD_CGROUP" : "/", "UNIT" : "nginx.service", "MESSAGE" :
"Starting A high performance web server and a reverse proxy server...",
"_SOURCE_REALTIME_TIMESTAMP" : "1422990364737973" }
...
This is useful for parsing with utilities. You could use the json-pretty format to get a
better handle on the data structure before passing it off to the JSON consumer:
These options allow you to display the journal entries in the whatever format best
suits your current needs.
DEBIAN Page 29
suits your current needs.
journalctl -n
You can specify the number of entries you'd like to see with a number after the -n:
journalctl -n 20
Following Logs
To actively follow the logs as they are being written, you can use the -f flag. Again,
this works as you might expect if you have experience using tail -f:
journalctl -f
Journal Maintenance
You may be wondering about the cost is of storing all of the data we've seen so far.
Furthermore, you may be interesting in cleaning up some older logs and freeing up
space.
journalctl --disk-usage
Journals take up 8.0M on disk.
If you use the --vacuum-size option, you can shrink your journal by indicating a size.
DEBIAN Page 30
If you use the --vacuum-size option, you can shrink your journal by indicating a size.
This will remove old entries until the total journal space taken up on disk is at the
requested size:
For instance, to keep entries from the last year, you can type:
SystemMaxUse=: Specifies the maximum disk space that can be used by the journal
in persistent storage.
SystemKeepFree=: Specifies the amount of space that the journal should leave free
when adding journal entries to persistent storage.
SystemMaxFileSize=: Controls how large individual journal files can grow to in
persistent storage before being rotated.
RuntimeMaxUse=: Specifies the maximum disk space that can be used in volatile
storage (within the/run filesystem).
RuntimeKeepFree=: Specifies the amount of space to be set aside for other uses
when writing data to volatile storage (within the /run filesystem).
RuntimeMaxFileSize=: Specifies the amount of space that an individual journal file
can take up in volatile storage (within the /run filesystem) before being rotated.
By setting these values, you can control how journald consumes and preserves
space on your server.
Conclusion
As you can see, the systemd journal is incredibly useful for collecting and managing
your system and application data. Most of the flexibility comes from the extensive
metadata automatically recorded and the centralized nature of the log.
The journalctl command makes it easy to take advantage of the advanced features of
the journal and to do extensive analysis and relational debugging of different
application components.
DEBIAN Page 31
application components.
From <https://www.digitalocean.com/community/tutorials/how-to-use-journalctl-to-view-and-manipulate-systemd-logs>
DEBIAN Page 32
fstab
utorak, 13. septembar 2016. 11.13
fstab
Translation(s): English - Franais - Italiano - - Espaol
The fstab (/etc/fstab) (or file systems table) file is a system configuration file on
Debian systems. The fstab file typically lists all available disks and disk
partitions, and indicates how they are to be initialized or otherwise integrated
into the overall system's file system.
Contents
1. Example
2. Field definitions
3. Defining filesystems
1. Kernel naming
2. UUIDs
3. Labels
4. See also
Example
# <file system> <dir> <type> <options> <dump> <pass>
/dev/sda1 / ext4 defaults 1 1
/dev/hdxx /usr ext4 defaults 1 1
/dev/sda5 swap swap defaults 0 0
It is not necessary to list /proc and /sys in the fstab unless some special options
are needed. The boot system will always mount them.
Field definitions
/etc/fstab contains the following fields separated by a space or tab:
<file system> <dir> <type> <options> <dump> <pass>
<file systems> - defines the storage device (i.e. /dev/sda1).
<dir> - tells the mount command where it should mount the <file system> to.
<type> - defines the file system type of the device or partition to be mounted.
Many different file systems are supported. Some examples are: ext2, ext3,
reiserfs, xfs, jfs, smbfs, iso9660, vfat, ntfs, swap, and auto. The 'auto' type lets
the mount command to attempt to guess what type of file system is used, this is
useful for removable devices such as CDs and DVDs.
<options> - define particular options for filesystems. Some options relate only
to the filesystem itself. Some of the more common options are:
auto - file system will mount automatically at boot, or when the command
'mount -a' is issued.
noauto - the filesystem is mounted only when you tell it to.
exec - allow the execution binaries that are on that partition (default).
noexec - do not allow binaries to be executed on the filesystem.
ro - mount the filesystem read only.
rw - mount the filesystem read-write.
sync - I/O should be done synchronously.
async - I/O should be done asynchronously.
flush - specific option for FAT to flush data more often, thus making copy
dialogs or progress bars to stays up until things are on the disk.
user - permit any user to mount the filesystem (implies noexec,nosuid,nodev
unless overridden).
nouser - only allow root to mount the filesystem (default).
defaults - default mount settings (equivalent to
rw,suid,dev,exec,auto,nouser,async).
suid - allow the operation of suid, and sgid bits. They are mostly used to allow
users on a computer system to execute binary executables with temporarily
elevated privileges in order to perform a specific task.
nosuid - block the operation of suid, and sgid bits.
DEBIAN Page 33
nosuid - block the operation of suid, and sgid bits.
noatime - do not update inode access times on the filesystem. Can help
performance.
nodiratime - do not update directory inode access times on the filesystem. Can
help performance.
relatime - update inode access times relative to modify or change time. Access
time is only updated if the previous access time was earlier than the current
modify or change time (similar to noatime, but doesn't break mutt or other
applications that need to know if a file has been read since the last time it was
modified). Can help performance.
<dump> - is used by the dump utility to decide when to make a backup. When
installed, dump checks the entry and uses the number to decide if a file system
should be backed up. Possible entries are 0 and 1. If 0, dump will ignore the file
system, if 1, dump will make a backup. Most users will not have dump installed,
so they should put 0 for the <dump> entry.
<pass> fsck reads the <pass> number and determines in which order the file
systems should be checked. Possible entries are 0, 1, and 2. The root file
system should have the highest priority, 1, all other file systems you want to
have checked should get a 2. File systems with a <pass> value 0 will not be
checked by the fsck utility.
Defining filesystems
You can define the filesystems in the /etc/fstab configuration in three different
ways: by kernel naming descriptors, by UUID, or by labels. The advantage of
using UUIDs or labels is that they are not dependent on disk order. This is
useful if you change your storage device order in the BIOS, you switch storage
device cabling, or because some BIOS's may occasionally change the order of
storage devices.
LVM snapshots can result in duplicate UUIDs and labels, so LVM logical
volumes should always be identified by logical volume name (/dev/mapper/name).
Kernel naming
You can get kernel naming descriptors using fdisk:
# fdisk -l
...
Device Boot Start End Blocks Id System
/dev/sda1 * 1 19458 156290016+ 83 Linux
An example /etc/fstab using the kernel naming:
# <file system> <dir> <type> <options> <dump> <pass>
/dev/sda1 / ext4 defaults 1 1
UUIDs
UUIDs are generated by the make-filesystem utilities (mkfs.*) when you create
a filesystem. blkid will show you the UUIDs of mounted devices and partitions:
# blkid
/dev/sda1: UUID="6a60524d-061d-454a-bfd1-38989910eccd" TYPE="ext4"
An example /etc/fstab using the UUID identifiers:
# <file system> <dir> <type> <options> <dump> <pass>
UUID=6a60524d-061d-454a-bfd1-38989910eccd / ext4 defaults 1 1
Labels
The device or partition is required to be labeled first. To do this, you can use
common applications like gparted to label partitions or you can use e2label to
label ext2, ext3, and ext4 partitions. Keep in mind that not all file system have
labeling support (e.g. FAT file systems). Labels can be up to 16 characters
long. Labels should be unambiguous, meaning that each label should be
original to prevent any possible conflicts.
A device or partition must not be mounted before attempting to label them.
Initially you will need to boot from a Live(CD/DVD/USB) before you can label
with a gparted-like application or for ext partitions you can use e2label:
# e2label /dev/<disk-or-partition> Debian
An example /etc/fstab using the labels:
# <file system> <dir> <type> <options> <dump> <pass>
LABEL=Debian / ext4 defaults 1 1
DEBIAN Page 34
From <https://wiki.debian.org/fstab>
Add nodev, nosuid, and noexec options to /tmp:
1. Edit the file /etc/fstab, enter:
vi /etc/fstab
2. Locate the /tmp line:
UUID=0aef28b9-3d11-4ab4-a0d4-d53d7b4d3aa4 /tmp ext4 defaults 12
3. Append the text ,nodev,nosuid,noexec to the list of mount options in column
4. The entry should look like this:
UUID=0aef28b9-3d11-4ab4-a0d4-d53d7b4d3aa4 /tmp ext4 defaults,nodev,nosuid,noexec 12
5. Save and close the file.
About /var/tmp
Make sure you bind /var/tmp to /tmp:
1. Edit the file /etc/fstab, enter:
vi /etc/fstab
2. Append the following line:
/tmp /var/tmp none rw,noexec,nosuid,nodev,bind 0 0
3. Save and close the file.
Set nodev, nosuid, and noexec options without rebooting the Linux server
1. Type the following command as root user:
# Bind /var/tmp to /tmp
mount -o rw,noexec,nosuid,nodev,bind /tmp/ /var/tmp/
# Remount /tmp
mount -o remount,noexec,nosuid,nodev /tmp
# Remount /dev/shm
mount -o remount,noexec,nosuid,nodev /dev/shm
2. Verify new settings:
From <https://kb.iweb.com/entries/23913751--Increasing-Linux-server-security-with-nodev-nosuid-and-no-exec-options>
DEBIAN Page 35
utorak, 13. septembar 2016. 12.15
DEBIAN Page 36
debsign will add a GPG signature to .dsc and .changes files themselves. You can
use debsign like this:
$ debsign -k E732A79A test_1.0-7.dsc
This command specifies the GPG key ID to use when signing the Debian source file test_
1.0-7.dsc. The signature is embedded in the filetest_1.0-7.dsc and can be verified by running:
$ gpg --verify test_1.0-7.dsc
The Debian source package file and changes file both contain SHA1, SHA256, and MD5
checksums of all source files that comprise the source package. Since this data is signed,
any modifications to the source file checksums, file size, or other data in the dsc or changes
files would cause signature verification to fail.
As long as a recipient who wishes to build the deb package from a dsc file verifies the
checksums of each file in the source package and verifies the signature of the source
package itself, the recipient knows their build uses precisely the same files that the packager
used when building.
apt-get source packagename will automatically check the GPG signature of the source
package file and the checksums of the source files listed in the source package.
GPG signing Debian package files (.deb files)
A Debian package file itself is actually an AR archive that contains at least three entries:
debian-binary: a file describing the deb format version
control: an archive containing package metadata such as pre-install or post-install scripts
data: an archive containing the actual installable files
The control and data archives are typically tar, tar.gz, tar.bz2, tar.xz, tar.lzma, or another archive
format.
When a Debian package is signed with a GPG key, the signature is also included in the
archive and is named based on its type.
Debian package signatures are typically associated with a role. Some commonly used roles
include:
origin: the signature of the organization which distributes the .deb file
maint: the signature of the package maintainer
archive: the signature of the archive providing the package to reassure users that the package is the
actually provided by the archive
In order to sign a Debian package, you can use the program debsigs:
$ debsigs --sign=origin -k E732A79A test_1.0-7_amd64.deb
In the above example, the Debian file is signed using the GPG key on my system with the ID
E732A79A. The signature type is origin and thus the deb package will be modified to include
a file called _gpgorigin that contains the GPG signature of the debian-
binary file, control archive, anddata archive from the deb package concatenated together.
I used the type origin because I am person distributing the deb package test_1.0-7
_amd64.deb.
Verifying signatures on Debian .deb package files is a bit more involved than the other
verification methods.
Verifying GPG signatures of .deb package files
In order to verify .deb package files, you must have the program debsig-verify installed, import
the public GPG keys you will use to verify packages to the debsig-verify keyrings, and you
must also create an XML policy document for signature verification.
First, create a keyring directory for the public key and import the public key to the debsig-
verify GPG keyring:
$ mkdir /usr/share/debsig/keyrings/DDDF2F4CE732A79A/
$ gpg --no-default-keyring \
--keyring /usr/share/debsig/keyrings/DDDF2F4CE732A79A/debsig.gpg \
--import my-public-key
In the above example, the keyring subdirectory, DDDF2F4CE732A79A, is the fingerprint of
the GPG key which will be imported. Note that the name of the keyring debsig.gpg will be
used in the XML policy document created next. You can use any filename you like.
Now that the public key is imported, the XML policy document can be constructed.
First, create a directory for the policy document. It must have the GPG key fingerprint in the
path:
$ mkdir /etc/debsig/policies/DDDF2F4CE732A79A/
Next create the XML document. The debsig-verify man page indicates that the filename is
irrelevant so long as the filename ends with .pol and resides in a directory named after the
GPG key fingerpint.
You can find more information regarding how the build the policy document
DEBIAN Page 37
You can find more information regarding how the build the policy document
in /usr/share/doc/debsig-verify/policy-syntax.txt and some examples in/usr/share/doc/debsig-
verify/examples.
Heres an example XML policy document:
<?xml version="1.0"?>
<!DOCTYPE Policy SYSTEM "http://www.debian.org/debsig/1.0/policy.dtd">
<Policy xmlns="http://www.debian.org/debsig/1.0/">
<Origin Name="test" id="DDDF2F4CE732A79A" Description="Test package"/>
<Selection>
<Required Type="origin" File="debsig.gpg" id="DDDF2F4CE732A79A"/>
</Selection>
<Verification MinOptional="0">
<Required Type="origin" File="debsig.gpg" id="DDDF2F4CE732A79A"/>
</Verification>
</Policy>
Once this document is constructed, you can verify the GPG signature of the Debian .deb
package:
$ debsig-verify test_1.0-7_amd64.deb
debsig: Verified package from `Test package' (test)
dpkg support for debsig-verify
dpkg has support for verifying GPG signatures of Debian package files, but this verification
is disabled by default. This means that when a package is installed on a Debian-based
system, the signature checking for individual packages is disabled.
In order to enable it, the file /etc/dpkg/dpkg.cfg will need to be modified to remove the no-
debsig option from the config file.
CAUTION: Doing this may cause dpkg to reject installation of unsigned Debian files. If you
plan to enable this, it is strongly recommended you try this first in a testing environment.
Youll also need to ensure you have the correct XML policy files created, as explained
above.
Another Debian package signing tool: dpkg-sig
There is a another tool available for signing and verifying Debian package files called dpkg-
sig. Signatures created by this tool are not compatiblewith debsigs and the tools cannot
understand or verify each other signatures.
dpkg-sig generates a Debian control file with several userful fields:
Version of dpkg-sig which generated the signature
Gpg key signer information
Role
Files section with checksums, file sizes, and filenames of the control, data, and debian-binary files in
the Debian package
This file is named based on the role selected, which is defaulted to builder if none is
specified. So, signing a Debian package file with no role would result in a file
named _gpgbuilder being created and added to the package file. This file is signed with GPG
and the signature is embedded as plain text (a clearsign GPG signature).
The result of this scheme is that the GPG signature can be verified using commonly
available software. The Debian package can be extracted withar and the signature of the
control file can be checked with just gpg --verify.
Signing a Debian file with dpkg-sig is straight forward:
$ dpkg-sig -k E732A79A --sign builder test_1.0-7_amd64.deb
The signature can also be checked by using dpkg-sig directly, if desired:
$ dpkg-sig --verify test_1.0-7_amd64.deb
Processing test_1.0-7_amd64.deb...
GOODSIG _gpgbuilder 284E8BE753AE45DFF8D82748DDDF2F4CE732A79A 1414371553
Additionally, no XML policy document is required for signature verification, which makes
signature verification much simpler to integrate into a workflow.
dpkg support for dpkg-sig
Unfortunately, dpkg does not have built-in support for dpkg-sig, but the discussion appears to
have been moved to a bug ticket with Debian (last updated in
2012): https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=340306.
GPG signatures for APT repository metadata
It is also possible to generate GPG signatures for APT repositories in addition to generating
signatures for Debian packages themselves.
Generating signatures of the repository metadata allows you to verify that the repository
metadata has not been tampered with since it was generated by the repository host.
This is critical to preventing a Man-in-the-Middle attack attack where a malicious actor plants
DEBIAN Page 38
This is critical to preventing a Man-in-the-Middle attack attack where a malicious actor plants
repository metadata causing a users package manager to install potentially malicious
packages.
Luckily, generating GPG sigantures for APT repositories is straightforward with reprepro.
Assuming you have a GPG key youd like to use to sign the repository metadata, you can
simply modify your reprepro repository config to add your GPG key.
Using the same GPG key ID used in the earlier examples, the conf/distributions config file can
be modified to add the field:
SignWith: E732A79A
This will cause reprepro to generate GPG signatures of the repository metadata. reprepro will
generate a signature of the apt Release file and store the signature in the file Release.gpg.
This is called a detached GPG signature.
Newer version of reprepro will generate an embedded text GPG signature (a clearsign GPG
signature) in a file named InRelease.
The apt client will download the GPG Release file(s) it understands and will automatically
attempt to verify the GPG signature of the repository.
Users of the repository will need to have the GPG key installed on the system. This can be
done by end users running the command: apt-key:
$ sudo bash -c 'wget -O - https://packagecloud.io/gpg.key | apt-key add -'
The above command downloads a GPG key and adds the GPG key to the system using apt-
key.
Conclusion
GPG signing of Debian package files, source packages, and repository metadata is critical
to establishing the authenticity of the package objects and repository metadata.
Knowing that a package being installed on your system is the same package that was
generated by a vendor, and that you were able to retrieve that package from the repository
generated by the vendor is the only way to ensure that you are safely installing software in
your infrastructure.
Unfortunately, signing and checking the signatures of Debian packages is not as streamlined
and integrated as it could be, so vendors currently signing their Debian package files may be
surprised to learn that the majority of their customers are not automatically checking the
GPG signature of their packages. At the very least, vendors should be signing their
repository metadata. Also signing their Debian package files and providing instructions for
how users can verify those signatures would be a great way to help improve their end users
security.
packagecloud.io signs repository metadata it generates using a GPG key so that users of
our repositories know, without a doubt, that the repository metadata their package manager
downloaded was generated by packagecloud.io.
From <http://blog.packagecloud.io/eng/2014/10/28/howto-gpg-sign-verify-deb-packages-apt-repositories/>
DEBIAN Page 39
Rad sa paketima
petak, 07. oktobar 2016. 18.57
From <https://wiki.debian.org/ListInstalledPackages>
DEBIAN Page 40
Skripta za povezanost sa grupom
sreda, 30. novembar 2016 23:24
cat /etc/group | awk -F: '{print $1, $3, $4}' | while read group gid members; do
members=$members,$(awk -F: "\$4 == $gid {print \",\" \$1}" /etc/passwd);
echo "$group: $members" | sed 's/,,*/ /g';
done
DEBIAN Page 41