Linupedia.org - Benutzerbeiträge [de]

Benutzer:Gehrke

2022-02-21T10:38:29Z

Gehrke: test

Diskussion:Sed

2019-12-14T18:15:46Z

Gehrke: /* Layout */

== Layout ==

Wie kann man es machen dass der Text in den Tabellenfeldern nicht so hart an Anfang klebt? nbsp's reinhauen wäre eher unschön für den Quelltext, geht das besser? --[[Benutzer:Itu|Itu]] ([[Benutzer Diskussion:Itu|Diskussion]]) 13:08, 14. Dez. 2019 (CET)

: Hhmm, Du könntest mit den Formatierungselementen von Mediawiki experimentieren:
: https://www.mediawiki.org/wiki/Help:Tables
: Aber eigentlich hätte ich gedacht, dass die Form an dieser Stelle nicht so wichtig ist.
: --[[Benutzer:Gehrke|Gehrke]] ([[Benutzer Diskussion:Gehrke|Diskussion]]) 19:15, 14. Dez. 2019 (CET)

Diskussion:Einrichten von public keys mit ssh

2016-11-23T16:14:45Z

Gehrke: /* Sicherheitsinfo */

=ssh-agent fehlend / key ohne passphrase?=
Das Verfahren beschreibt die Erzeugung eines Schlüsselpaares '''ohne''' Passphrase. Ich denke, man sollte hier darauf hinweisen, dass eine Passphrase nochmals deutlich mehr an Sicherheit bringt und dass man die unbequemen Abfragen nach derselben bei jeder Verwendung mittels [[ssh-agent]] auf eine einmalige Eingabe reduzieren kann. Das kann auch gerne ich übernehmen. --[[Benutzer:Gehrke|Gehrke]] ([[Benutzer Diskussion:Gehrke|Diskussion]]) 14:16, 26. Nov. 2013 (CET)

:Warnhinweis und Referenz auf ssh-agent hinzugefügt. --[[Benutzer:Gehrke|Gehrke]] ([[Benutzer Diskussion:Gehrke|Diskussion]]) 07:48, 27. Nov. 2013 (CET)

=Struktur des Artikels=
Die Kapitel-Struktur scheint mir nicht korrekt. Sollte die Kapitel nach dem Sicherheitshinweis nicht Überschriften 1. Ordnung sein? --[[Benutzer:Gehrke|Gehrke]] ([[Benutzer Diskussion:Gehrke|Diskussion]]) 14:22, 26. Nov. 2013 (CET)

:Done. --[[Benutzer:Gehrke|Gehrke]] ([[Benutzer Diskussion:Gehrke|Diskussion]]) 07:48, 27. Nov. 2013 (CET)

=Sicherheitsinfo=
Dieser Abschnitt warnt vor einem schweren Sicherheitsproblem von OpenSSH unter Debian, welches 2008 aufgedeckt wurde und auf 2006 zurückgeht. Nun ist fast 2014 und ich denke, dass das Thema mittlerweile soweit behandelt sein sollte, dass es nicht mehr auf dieser Seite an erster Stelle stehen muss. Daher schlage ich vor, das hier zu entfernen. --[[Benutzer:Gehrke|Gehrke]] ([[Benutzer Diskussion:Gehrke|Diskussion]]) 11:06, 6. Dez. 2013 (CET)
::: und Tschüß [[Benutzer:Robi|Robi]] ([[Benutzer Diskussion:Robi|Diskussion]]) 20:48, 8. Dez. 2013 (CET)

=Public Schlüssel auf dem Server installieren=
Hinweis von User 'Sauerland': alternativ oder stattdessen ''ssh-copy-id'' --[[Benutzer:Gehrke|Gehrke]] ([[Benutzer Diskussion:Gehrke|Diskussion]]) 17:56, 7. Dez. 2013 (CET)

Konfigurationsbeispiel eines Notebooks für den Einsatz in unterschiedlichen Netzen mit 'firewalld' und 'NetworkManager'

2016-10-29T13:11:41Z

Gehrke: /* NetworkManager */ CLI: ausführliche Parametrisierungsform

{{UnderConstruction}}--[[Benutzer:Gehrke|Gehrke]] ([[Benutzer Diskussion:Gehrke|Diskussion]]) 22:09, 24. Okt. 2016 (CEST)

Im Folgenden soll eine Beispielkonfiguration für ein Notebook gezeigt werden, welches auf den Einsatz in '''Netzwerken mit unterschiedlichen Sicherheitsanforderungen''' eingerichtet ist. Dieses System soll in vertrauenswürdigen Netzen (wie beispielsweise dem eigenen LAN oder WLAN) eine bestimmte Netzwerkfunktionalität wie [[SSH]] oder den File-Daemon von [[Bacula]] auf diesem Notebook erlauben. In anderen Netzen dagegen soll nur eine sehr eingeschränkte Netzwerk-Konnektivität erlaubt sein.

Dabei soll die Zuordnung anhand der Auswahl des Netzwerkes im [[NetworkManager]] erfolgen, welche bei bekannten Netzen in der Regel '''automatisch''' durchgeführt wird. Beispielsweise beim Wechsel vom (als sicher eingestuften) heimischen LANs in ein unsicheres öffentliches WLAN nach einem Ruhezustand des Notebooks.

Der Dienst [[firewalld]] kennt für die Gruppierung von Sicherheitsanforderungen das Konzept der ''Zonen''. Dabei enthält die Definition der Zone eine vollständige Beschreibung, welche Netzwerkdienste von oder zu dem jeweiligen System zulässig sind. Es werden von der Distribution eine Reihe von Zonen-Definitionen mitgeliefert, welche sich im Grad der Netzwerk-Freigibigkeit unterscheiden. Für das vorliegende Beispiel werden 2 vorgefertigte Zonen-Definitionen (''work'' und ''public'') kopiert und entsprechend der Anforderungen angepasst.

Die gewünschten Eigenschaften der Zonen sind:
*work: [[SSH]] und bacula-fd nur vom [[bacula]]-Server (172.16.21.10)
*public: Keinerlei Zugriff (auch kein SSH)

Dieses Beispiel basiert auf der Distribution [[CentOS]] 7. Um eine effektive und eindeutig dokumentierbare Vorgehensweise darzustellen, soll für alle administrativen Zugriffe auf die verwendeten Tools das jeweilige ''Command Line Interface (CLI)'' verwendet werden.

=Konfiguration=
Um dieses Ziel zu erreichen, sind zwei Subsysteme zu konfigurieren:
*[[firewalld]]: Dieser Dienst übernimmt die dynamische Konfiguration und Steuerung der lokalen Firewall. Die von der Distribution vorgegebenen Templates (XML) für die beiden Zonen werden kopiert und angepasst, so dass die Konfiguration persistent zur Verfügung steht.
*[[NetworkManager]]: Der Dienst konfiguriert und steuert die Netzwerkanbindung dynamisch. Bekannten Netzen soll anhand der UUID die Zone 'work' zugewiesen werden. Andere Netze behalten die Default-Zone 'public'.
==firewalld==
Im ersten Schritt werden die durch die Distribution vorgegebenen Zonen-Definitionen kopiert. Die folgenden Änderungen erfolgen auf den hier erzeugten Kopien:
<pre>
# mkdir /etc/firewalld/zones
# cp /usr/lib/firewalld/zones/public.xml /etc/firewalld/zones/
# cp /usr/lib/firewalld/zones/work.xml /etc/firewalld/zones/
</pre>
Die geänderten Definitionen enthalten die Umsetzung für die oben genannten Anforderungen:
<pre>
# cat /etc/firewalld/zones/work.xml
<?xml version="1.0" encoding="utf-8"?>
<zone>
<short>Work</short>
<description>For use in work areas. You mostly trust the other computers on networks to not harm your computer. Only selected incoming connections are accepted.</description>
<service name="ssh"/>
<rule family="ipv4">
<source address="172.16.21.10"/>
<service name="bacula"/>
<accept/>
</rule>
</zone>
</pre>
<pre>
# cat /etc/firewalld/zones/public.xml
<?xml version="1.0" encoding="utf-8"?>
<zone>
<short>Public</short>
<description>For use in public areas. You do not trust the other computers on networks to not harm your computer. Only selected incoming connections are accepted.</description>
</zone>
</pre>

Neustart der Firewall:
<pre>
# systemctl restart firewalld.service
</pre>

==NetworkManager==
Vorhandene Netze anzeigen:
<pre>
# nmcli connection show
NAME UUID TYP GERÄT
Freifunk fec93f72-3488-4008-abfc-ec372d6f8806 802-11-wireless --
WLAN1 82be9628-2709-495f-a389-d209b74fcd05 802-11-wireless --
VPN1 ec0aa457-d3ec-4089-8c8f-1a53a8a33374 vpn --
LAN1 ee9ee0aa-57b9-4c5d-9c76-d2722986c5d8 802-3-ethernet --
enp2s0 8c1c5b53-0c80-44df-8c49-678b6d122d42 802-3-ethernet enp2s0
WLAN2 1e906b64-4909-4dbe-8d81-705ea64767b4 802-11-wireless wlp8s0
VPN2 23c0b2c5-b5a6-4e82-95b2-9b198074391d vpn --
</pre>
Man erkennt, dass das Notebook kabelgebunden über das Interface ''enp2s0'' am Netzwerk ''enp2s0'' und per WLAN über wlp8s0 am eigenen Funk-Netzwerk ''WLAN2'' hängt.

Die Zuordnung der Zone 'work' an beide Netze erfolgt über die UUID der Netze im [[NetworkManager]]:
<pre>
# nmcli connection modify 8c1c5b53-0c80-44df-8c49-678b6d122d42 connection.zone work
# nmcli connection modify 1e906b64-4909-4dbe-8d81-705ea64767b4 connection.zone work
</pre>
Anschließend werden die Verbindungen noch aktiviert:
<pre>
# nmcli connection up uuid 8c1c5b53-0c80-44df-8c49-678b6d122d42
Verbindung wurde erfolgreich aktiviert (aktiver D-Bus-Pfad: /org/freedesktop/NetworkManager/ActiveConnection/38)
# nmcli connection up uuid 1e906b64-4909-4dbe-8d81-705ea64767b4
Verbindung wurde erfolgreich aktiviert (aktiver D-Bus-Pfad: /org/freedesktop/NetworkManager/ActiveConnection/39)
</pre>

=Überprüfung=
Abschließend ist die Konfiguration zu überprüfen.

Die Anzeige im Falle der Verbindung in den heimischen Netzen zeigt, dass die beiden Interfaces ''enp2s0'' und ''wlp8s0'' der Zone 'work' zugeordnet sind:
<pre>
# firewall-cmd --get-active-zones
work
interfaces: enp2s0 wlp8s0
</pre>
Anzeige der Konfiguration dieser Zone:
<pre>
# firewall-cmd --zone=work --list-all
work (active)
interfaces: enp2s0 wlp8s0
sources:
services: ssh
ports:
masquerade: no
forward-ports:
icmp-blocks:
rich rules:
rule family="ipv4" source address="172.16.21.10" service name="bacula" accept
</pre>

Dagegen sollte bei einer Verbindung zu einem anderen Netzwerk die Default-Zone 'public' zugeordnet sein. Im folgenden Beispiel besteht ausschließlich eine Verbindung zum WLAN 'Freifunk':
<pre>
# nmcli connection show
NAME UUID TYP GERÄT
Freifunk fec93f72-3488-4008-abfc-ec372d6f8806 802-11-wireless wlp8s0
enp2s0 8c1c5b53-0c80-44df-8c49-678b6d122d42 802-3-ethernet --
WLAN1 82be9628-2709-495f-a389-d209b74fcd05 802-11-wireless --
VPN1 ec0aa457-d3ec-4089-8c8f-1a53a8a33374 vpn --
LAN1 ee9ee0aa-57b9-4c5d-9c76-d2722986c5d8 802-3-ethernet --
enp2s0 8c1c5b53-0c80-44df-8c49-678b6d122d42 802-3-ethernet --
WLAN2 1e906b64-4909-4dbe-8d81-705ea64767b4 802-11-wireless --
VPN2 23c0b2c5-b5a6-4e82-95b2-9b198074391d vpn --
</pre>
Dementsprechend zeigt die Prüfung, dass für das WLAN-Interface ''wlp8s0'' die Zone 'public' gesetzt wurde und das derzeit nicht verbundene ''enp2s0'' ohne Zuordnung verbleibt:
<pre>
# firewall-cmd --get-active-zones
public
interfaces: wlp8s0
</pre>
Es ist zu erkennen, dass [[SSH]] im Bereich ''services'' nicht zugelassen ist:
<pre>
# firewall-cmd --zone=public --list-all
public (default, active)
interfaces: wlp8s0
sources:
services:
ports:
masquerade: no
forward-ports:
icmp-blocks:
rich rules:
</pre>
Dabei erfolgt die Zuordnung der Zonen automatisch in Reaktion auf die Auswahl des Netzwerkes im [[NetworkManger]]. Eine manuelle Auswahl der Zone ist hierfür nicht erforderlich.

=Links=
*[http://www.firewalld.org/ firewalld.org] {{englisch}}
*[https://www.digitalocean.com/community/tutorials/how-to-set-up-a-firewall-using-firewalld-on-centos-7 How To Set Up a Firewall Using FirewallD on CentOS 7] {{englisch}}
*[https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Security_Guide/sec-Using_Firewalls.html redhat Security Guide] {{englisch}}
*[https://www.certdepot.net/rhel7-get-started-firewalld/ RHEL7: How to get started with Firewalld] {{englisch}}

[[Category:Security]] [[Category:Netzwerk]] [[Category:HowTo]]

Konfigurationsbeispiel eines Notebooks für den Einsatz in unterschiedlichen Netzen mit 'firewalld' und 'NetworkManager'

2016-10-29T12:51:31Z

Gehrke: /* firewalld */ mkdir

{{UnderConstruction}}--[[Benutzer:Gehrke|Gehrke]] ([[Benutzer Diskussion:Gehrke|Diskussion]]) 22:09, 24. Okt. 2016 (CEST)

Im Folgenden soll eine Beispielkonfiguration für ein Notebook gezeigt werden, welches auf den Einsatz in '''Netzwerken mit unterschiedlichen Sicherheitsanforderungen''' eingerichtet ist. Dieses System soll in vertrauenswürdigen Netzen (wie beispielsweise dem eigenen LAN oder WLAN) eine bestimmte Netzwerkfunktionalität wie [[SSH]] oder den File-Daemon von [[Bacula]] auf diesem Notebook erlauben. In anderen Netzen dagegen soll nur eine sehr eingeschränkte Netzwerk-Konnektivität erlaubt sein.

Dabei soll die Zuordnung anhand der Auswahl des Netzwerkes im [[NetworkManager]] erfolgen, welche bei bekannten Netzen in der Regel '''automatisch''' durchgeführt wird. Beispielsweise beim Wechsel vom (als sicher eingestuften) heimischen LANs in ein unsicheres öffentliches WLAN nach einem Ruhezustand des Notebooks.

Der Dienst [[firewalld]] kennt für die Gruppierung von Sicherheitsanforderungen das Konzept der ''Zonen''. Dabei enthält die Definition der Zone eine vollständige Beschreibung, welche Netzwerkdienste von oder zu dem jeweiligen System zulässig sind. Es werden von der Distribution eine Reihe von Zonen-Definitionen mitgeliefert, welche sich im Grad der Netzwerk-Freigibigkeit unterscheiden. Für das vorliegende Beispiel werden 2 vorgefertigte Zonen-Definitionen (''work'' und ''public'') kopiert und entsprechend der Anforderungen angepasst.

Die gewünschten Eigenschaften der Zonen sind:
*work: [[SSH]] und bacula-fd nur vom [[bacula]]-Server (172.16.21.10)
*public: Keinerlei Zugriff (auch kein SSH)

Dieses Beispiel basiert auf der Distribution [[CentOS]] 7. Um eine effektive und eindeutig dokumentierbare Vorgehensweise darzustellen, soll für alle administrativen Zugriffe auf die verwendeten Tools das jeweilige ''Command Line Interface (CLI)'' verwendet werden.

=Konfiguration=
Um dieses Ziel zu erreichen, sind zwei Subsysteme zu konfigurieren:
*[[firewalld]]: Dieser Dienst übernimmt die dynamische Konfiguration und Steuerung der lokalen Firewall. Die von der Distribution vorgegebenen Templates (XML) für die beiden Zonen werden kopiert und angepasst, so dass die Konfiguration persistent zur Verfügung steht.
*[[NetworkManager]]: Der Dienst konfiguriert und steuert die Netzwerkanbindung dynamisch. Bekannten Netzen soll anhand der UUID die Zone 'work' zugewiesen werden. Andere Netze behalten die Default-Zone 'public'.
==firewalld==
Im ersten Schritt werden die durch die Distribution vorgegebenen Zonen-Definitionen kopiert. Die folgenden Änderungen erfolgen auf den hier erzeugten Kopien:
<pre>
# mkdir /etc/firewalld/zones
# cp /usr/lib/firewalld/zones/public.xml /etc/firewalld/zones/
# cp /usr/lib/firewalld/zones/work.xml /etc/firewalld/zones/
</pre>
Die geänderten Definitionen enthalten die Umsetzung für die oben genannten Anforderungen:
<pre>
# cat /etc/firewalld/zones/work.xml
<?xml version="1.0" encoding="utf-8"?>
<zone>
<short>Work</short>
<description>For use in work areas. You mostly trust the other computers on networks to not harm your computer. Only selected incoming connections are accepted.</description>
<service name="ssh"/>
<rule family="ipv4">
<source address="172.16.21.10"/>
<service name="bacula"/>
<accept/>
</rule>
</zone>
</pre>
<pre>
# cat /etc/firewalld/zones/public.xml
<?xml version="1.0" encoding="utf-8"?>
<zone>
<short>Public</short>
<description>For use in public areas. You do not trust the other computers on networks to not harm your computer. Only selected incoming connections are accepted.</description>
</zone>
</pre>

Neustart der Firewall:
<pre>
# systemctl restart firewalld.service
</pre>

==NetworkManager==
Vorhandene Netze anzeigen:
<pre>
# nmcli connection show
NAME UUID TYP GERÄT
Freifunk fec93f72-3488-4008-abfc-ec372d6f8806 802-11-wireless --
WLAN1 82be9628-2709-495f-a389-d209b74fcd05 802-11-wireless --
VPN1 ec0aa457-d3ec-4089-8c8f-1a53a8a33374 vpn --
LAN1 ee9ee0aa-57b9-4c5d-9c76-d2722986c5d8 802-3-ethernet --
enp2s0 8c1c5b53-0c80-44df-8c49-678b6d122d42 802-3-ethernet enp2s0
WLAN2 1e906b64-4909-4dbe-8d81-705ea64767b4 802-11-wireless wlp8s0
VPN2 23c0b2c5-b5a6-4e82-95b2-9b198074391d vpn --
</pre>
Man erkennt, dass das Notebook kabelgebunden über das Interface ''enp2s0'' am Netzwerk ''enp2s0'' und per WLAN über wlp8s0 am eigenen Funk-Netzwerk ''WLAN2'' hängt.

Die Zuordnung der Zone 'work' an beide Netze erfolgt über die UUID der Netze im [[NetworkManager]]:
<pre>
# nmcli con mod "8c1c5b53-0c80-44df-8c49-678b6d122d42" connection.zone work
# nmcli con mod "1e906b64-4909-4dbe-8d81-705ea64767b4" connection.zone work
</pre>
Anschließend werden die Verbindungen noch aktiviert:
<pre>
# nmcli con up uuid 8c1c5b53-0c80-44df-8c49-678b6d122d42
Verbindung wurde erfolgreich aktiviert (aktiver D-Bus-Pfad: /org/freedesktop/NetworkManager/ActiveConnection/38)
# nmcli con up uuid 1e906b64-4909-4dbe-8d81-705ea64767b4
Verbindung wurde erfolgreich aktiviert (aktiver D-Bus-Pfad: /org/freedesktop/NetworkManager/ActiveConnection/39)
</pre>

=Überprüfung=
Abschließend ist die Konfiguration zu überprüfen.

Die Anzeige im Falle der Verbindung in den heimischen Netzen zeigt, dass die beiden Interfaces ''enp2s0'' und ''wlp8s0'' der Zone 'work' zugeordnet sind:
<pre>
# firewall-cmd --get-active-zones
work
interfaces: enp2s0 wlp8s0
</pre>
Anzeige der Konfiguration dieser Zone:
<pre>
# firewall-cmd --zone=work --list-all
work (active)
interfaces: enp2s0 wlp8s0
sources:
services: ssh
ports:
masquerade: no
forward-ports:
icmp-blocks:
rich rules:
rule family="ipv4" source address="172.16.21.10" service name="bacula" accept
</pre>

Dagegen sollte bei einer Verbindung zu einem anderen Netzwerk die Default-Zone 'public' zugeordnet sein. Im folgenden Beispiel besteht ausschließlich eine Verbindung zum WLAN 'Freifunk':
<pre>
# nmcli connection show
NAME UUID TYP GERÄT
Freifunk fec93f72-3488-4008-abfc-ec372d6f8806 802-11-wireless wlp8s0
enp2s0 8c1c5b53-0c80-44df-8c49-678b6d122d42 802-3-ethernet --
WLAN1 82be9628-2709-495f-a389-d209b74fcd05 802-11-wireless --
VPN1 ec0aa457-d3ec-4089-8c8f-1a53a8a33374 vpn --
LAN1 ee9ee0aa-57b9-4c5d-9c76-d2722986c5d8 802-3-ethernet --
enp2s0 8c1c5b53-0c80-44df-8c49-678b6d122d42 802-3-ethernet --
WLAN2 1e906b64-4909-4dbe-8d81-705ea64767b4 802-11-wireless --
VPN2 23c0b2c5-b5a6-4e82-95b2-9b198074391d vpn --
</pre>
Dementsprechend zeigt die Prüfung, dass für das WLAN-Interface ''wlp8s0'' die Zone 'public' gesetzt wurde und das derzeit nicht verbundene ''enp2s0'' ohne Zuordnung verbleibt:
<pre>
# firewall-cmd --get-active-zones
public
interfaces: wlp8s0
</pre>
Es ist zu erkennen, dass [[SSH]] im Bereich ''services'' nicht zugelassen ist:
<pre>
# firewall-cmd --zone=public --list-all
public (default, active)
interfaces: wlp8s0
sources:
services:
ports:
masquerade: no
forward-ports:
icmp-blocks:
rich rules:
</pre>
Dabei erfolgt die Zuordnung der Zonen automatisch in Reaktion auf die Auswahl des Netzwerkes im [[NetworkManger]]. Eine manuelle Auswahl der Zone ist hierfür nicht erforderlich.

=Links=
*[http://www.firewalld.org/ firewalld.org] {{englisch}}
*[https://www.digitalocean.com/community/tutorials/how-to-set-up-a-firewall-using-firewalld-on-centos-7 How To Set Up a Firewall Using FirewallD on CentOS 7] {{englisch}}
*[https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Security_Guide/sec-Using_Firewalls.html redhat Security Guide] {{englisch}}
*[https://www.certdepot.net/rhel7-get-started-firewalld/ RHEL7: How to get started with Firewalld] {{englisch}}

[[Category:Security]] [[Category:Netzwerk]] [[Category:HowTo]]

Konfigurationsbeispiel eines Notebooks für den Einsatz in unterschiedlichen Netzen mit 'firewalld' und 'NetworkManager'

2016-10-25T19:59:29Z

Gehrke: /* Konfiguration */ CLI entfernt

{{UnderConstruction}}--[[Benutzer:Gehrke|Gehrke]] ([[Benutzer Diskussion:Gehrke|Diskussion]]) 22:09, 24. Okt. 2016 (CEST)

Im Folgenden soll eine Beispielkonfiguration für ein Notebook gezeigt werden, welches auf den Einsatz in '''Netzwerken mit unterschiedlichen Sicherheitsanforderungen''' eingerichtet ist. Dieses System soll in vertrauenswürdigen Netzen (wie beispielsweise dem eigenen LAN oder WLAN) eine bestimmte Netzwerkfunktionalität wie [[SSH]] oder den File-Daemon von [[Bacula]] auf diesem Notebook erlauben. In anderen Netzen dagegen soll nur eine sehr eingeschränkte Netzwerk-Konnektivität erlaubt sein.

Dabei soll die Zuordnung anhand der Auswahl des Netzwerkes im [[NetworkManager]] erfolgen, welche bei bekannten Netzen in der Regel '''automatisch''' durchgeführt wird. Beispielsweise beim Wechsel vom (als sicher eingestuften) heimischen LANs in ein unsicheres öffentliches WLAN nach einem Ruhezustand des Notebooks.

Der Dienst [[firewalld]] kennt für die Gruppierung von Sicherheitsanforderungen das Konzept der ''Zonen''. Dabei enthält die Definition der Zone eine vollständige Beschreibung, welche Netzwerkdienste von oder zu dem jeweiligen System zulässig sind. Es werden von der Distribution eine Reihe von Zonen-Definitionen mitgeliefert, welche sich im Grad der Netzwerk-Freigibigkeit unterscheiden. Für das vorliegende Beispiel werden 2 vorgefertigte Zonen-Definitionen (''work'' und ''public'') kopiert und entsprechend der Anforderungen angepasst.

Die gewünschten Eigenschaften der Zonen sind:
*work: [[SSH]] und bacula-fd nur vom [[bacula]]-Server (172.16.21.10)
*public: Keinerlei Zugriff (auch kein SSH)

Dieses Beispiel basiert auf der Distribution [[CentOS]] 7. Um eine effektive und eindeutig dokumentierbare Vorgehensweise darzustellen, soll für alle administrativen Zugriffe auf die verwendeten Tools das jeweilige ''Command Line Interface (CLI)'' verwendet werden.

=Konfiguration=
Um dieses Ziel zu erreichen, sind zwei Subsysteme zu konfigurieren:
*[[firewalld]]: Dieser Dienst übernimmt die dynamische Konfiguration und Steuerung der lokalen Firewall. Die von der Distribution vorgegebenen Templates (XML) für die beiden Zonen werden kopiert und angepasst, so dass die Konfiguration persistent zur Verfügung steht.
*[[NetworkManager]]: Der Dienst konfiguriert und steuert die Netzwerkanbindung dynamisch. Bekannten Netzen soll anhand der UUID die Zone 'work' zugewiesen werden. Andere Netze behalten die Default-Zone 'public'.
==firewalld==
Im ersten Schritt werden die durch die Distribution vorgegebenen Zonen-Definitionen kopiert. Die folgenden Änderungen erfolgen auf den hier erzeugten Kopien:
<pre>
# cp /usr/lib/firewalld/zones/public.xml /etc/firewalld/zones/
# cp /usr/lib/firewalld/zones/work.xml /etc/firewalld/zones/
</pre>
Die geänderten Definitionen enthalten die Umsetzung für die oben genannten Anforderungen:
<pre>
# cat /etc/firewalld/zones/work.xml
<?xml version="1.0" encoding="utf-8"?>
<zone>
<short>Work</short>
<description>For use in work areas. You mostly trust the other computers on networks to not harm your computer. Only selected incoming connections are accepted.</description>
<service name="ssh"/>
<rule family="ipv4">
<source address="172.16.21.10"/>
<service name="bacula"/>
<accept/>
</rule>
</zone>
</pre>
<pre>
# cat /etc/firewalld/zones/public.xml
<?xml version="1.0" encoding="utf-8"?>
<zone>
<short>Public</short>
<description>For use in public areas. You do not trust the other computers on networks to not harm your computer. Only selected incoming connections are accepted.</description>
</zone>
</pre>

Neustart der Firewall:
<pre>
# systemctl restart firewalld.service
</pre>

==NetworkManager==
Vorhandene Netze anzeigen:
<pre>
# nmcli connection show
NAME UUID TYP GERÄT
Freifunk fec93f72-3488-4008-abfc-ec372d6f8806 802-11-wireless --
WLAN1 82be9628-2709-495f-a389-d209b74fcd05 802-11-wireless --
VPN1 ec0aa457-d3ec-4089-8c8f-1a53a8a33374 vpn --
LAN1 ee9ee0aa-57b9-4c5d-9c76-d2722986c5d8 802-3-ethernet --
enp2s0 8c1c5b53-0c80-44df-8c49-678b6d122d42 802-3-ethernet enp2s0
WLAN2 1e906b64-4909-4dbe-8d81-705ea64767b4 802-11-wireless wlp8s0
VPN2 23c0b2c5-b5a6-4e82-95b2-9b198074391d vpn --
</pre>
Man erkennt, dass das Notebook kabelgebunden über das Interface ''enp2s0'' am Netzwerk ''enp2s0'' und per WLAN über wlp8s0 am eigenen Funk-Netzwerk ''WLAN2'' hängt.

Die Zuordnung der Zone 'work' an beide Netze erfolgt über die UUID der Netze im [[NetworkManager]]:
<pre>
# nmcli con mod "8c1c5b53-0c80-44df-8c49-678b6d122d42" connection.zone work
# nmcli con mod "1e906b64-4909-4dbe-8d81-705ea64767b4" connection.zone work
</pre>
Anschließend werden die Verbindungen noch aktiviert:
<pre>
# nmcli con up uuid 8c1c5b53-0c80-44df-8c49-678b6d122d42
Verbindung wurde erfolgreich aktiviert (aktiver D-Bus-Pfad: /org/freedesktop/NetworkManager/ActiveConnection/38)
# nmcli con up uuid 1e906b64-4909-4dbe-8d81-705ea64767b4
Verbindung wurde erfolgreich aktiviert (aktiver D-Bus-Pfad: /org/freedesktop/NetworkManager/ActiveConnection/39)
</pre>

=Überprüfung=
Abschließend ist die Konfiguration zu überprüfen.

Die Anzeige im Falle der Verbindung in den heimischen Netzen zeigt, dass die beiden Interfaces ''enp2s0'' und ''wlp8s0'' der Zone 'work' zugeordnet sind:
<pre>
# firewall-cmd --get-active-zones
work
interfaces: enp2s0 wlp8s0
</pre>
Anzeige der Konfiguration dieser Zone:
<pre>
# firewall-cmd --zone=work --list-all
work (active)
interfaces: enp2s0 wlp8s0
sources:
services: ssh
ports:
masquerade: no
forward-ports:
icmp-blocks:
rich rules:
rule family="ipv4" source address="172.16.21.10" service name="bacula" accept
</pre>

Dagegen sollte bei einer Verbindung zu einem anderen Netzwerk die Default-Zone 'public' zugeordnet sein. Im folgenden Beispiel besteht ausschließlich eine Verbindung zum WLAN 'Freifunk':
<pre>
# nmcli connection show
NAME UUID TYP GERÄT
Freifunk fec93f72-3488-4008-abfc-ec372d6f8806 802-11-wireless wlp8s0
enp2s0 8c1c5b53-0c80-44df-8c49-678b6d122d42 802-3-ethernet --
WLAN1 82be9628-2709-495f-a389-d209b74fcd05 802-11-wireless --
VPN1 ec0aa457-d3ec-4089-8c8f-1a53a8a33374 vpn --
LAN1 ee9ee0aa-57b9-4c5d-9c76-d2722986c5d8 802-3-ethernet --
enp2s0 8c1c5b53-0c80-44df-8c49-678b6d122d42 802-3-ethernet --
WLAN2 1e906b64-4909-4dbe-8d81-705ea64767b4 802-11-wireless --
VPN2 23c0b2c5-b5a6-4e82-95b2-9b198074391d vpn --
</pre>
Dementsprechend zeigt die Prüfung, dass für das WLAN-Interface ''wlp8s0'' die Zone 'public' gesetzt wurde und das derzeit nicht verbundene ''enp2s0'' ohne Zuordnung verbleibt:
<pre>
# firewall-cmd --get-active-zones
public
interfaces: wlp8s0
</pre>
Es ist zu erkennen, dass [[SSH]] im Bereich ''services'' nicht zugelassen ist:
<pre>
# firewall-cmd --zone=public --list-all
public (default, active)
interfaces: wlp8s0
sources:
services:
ports:
masquerade: no
forward-ports:
icmp-blocks:
rich rules:
</pre>
Dabei erfolgt die Zuordnung der Zonen automatisch in Reaktion auf die Auswahl des Netzwerkes im [[NetworkManger]]. Eine manuelle Auswahl der Zone ist hierfür nicht erforderlich.

=Links=
*[http://www.firewalld.org/ firewalld.org] {{englisch}}
*[https://www.digitalocean.com/community/tutorials/how-to-set-up-a-firewall-using-firewalld-on-centos-7 How To Set Up a Firewall Using FirewallD on CentOS 7] {{englisch}}
*[https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Security_Guide/sec-Using_Firewalls.html redhat Security Guide] {{englisch}}
*[https://www.certdepot.net/rhel7-get-started-firewalld/ RHEL7: How to get started with Firewalld] {{englisch}}

[[Category:Security]] [[Category:Netzwerk]] [[Category:HowTo]]

Konfigurationsbeispiel eines Notebooks für den Einsatz in unterschiedlichen Netzen mit 'firewalld' und 'NetworkManager'

2016-10-25T19:56:37Z

Gehrke: Definition der Zone

{{UnderConstruction}}--[[Benutzer:Gehrke|Gehrke]] ([[Benutzer Diskussion:Gehrke|Diskussion]]) 22:09, 24. Okt. 2016 (CEST)

Im Folgenden soll eine Beispielkonfiguration für ein Notebook gezeigt werden, welches auf den Einsatz in '''Netzwerken mit unterschiedlichen Sicherheitsanforderungen''' eingerichtet ist. Dieses System soll in vertrauenswürdigen Netzen (wie beispielsweise dem eigenen LAN oder WLAN) eine bestimmte Netzwerkfunktionalität wie [[SSH]] oder den File-Daemon von [[Bacula]] auf diesem Notebook erlauben. In anderen Netzen dagegen soll nur eine sehr eingeschränkte Netzwerk-Konnektivität erlaubt sein.

Dabei soll die Zuordnung anhand der Auswahl des Netzwerkes im [[NetworkManager]] erfolgen, welche bei bekannten Netzen in der Regel '''automatisch''' durchgeführt wird. Beispielsweise beim Wechsel vom (als sicher eingestuften) heimischen LANs in ein unsicheres öffentliches WLAN nach einem Ruhezustand des Notebooks.

Der Dienst [[firewalld]] kennt für die Gruppierung von Sicherheitsanforderungen das Konzept der ''Zonen''. Dabei enthält die Definition der Zone eine vollständige Beschreibung, welche Netzwerkdienste von oder zu dem jeweiligen System zulässig sind. Es werden von der Distribution eine Reihe von Zonen-Definitionen mitgeliefert, welche sich im Grad der Netzwerk-Freigibigkeit unterscheiden. Für das vorliegende Beispiel werden 2 vorgefertigte Zonen-Definitionen (''work'' und ''public'') kopiert und entsprechend der Anforderungen angepasst.

Die gewünschten Eigenschaften der Zonen sind:
*work: [[SSH]] und bacula-fd nur vom [[bacula]]-Server (172.16.21.10)
*public: Keinerlei Zugriff (auch kein SSH)

Dieses Beispiel basiert auf der Distribution [[CentOS]] 7. Um eine effektive und eindeutig dokumentierbare Vorgehensweise darzustellen, soll für alle administrativen Zugriffe auf die verwendeten Tools das jeweilige ''Command Line Interface (CLI)'' verwendet werden.

=Konfiguration=
Um dieses Ziel zu erreichen, sind zwei Subsysteme zu konfigurieren:
*[[firewalld]]: Dieser Dienst übernimmt die dynamische Konfiguration und Steuerung der lokalen Firewall. Die von der Distribution vorgegebenen Templates (XML) für die beiden Zonen werden kopiert und angepasst, so dass die Konfiguration persistent zur Verfügung steht.
*[[NetworkManager]]: Der Dienst konfiguriert und steuert die Netzwerkanbindung dynamisch. Bekannten Netzen soll anhand der UUID die Zone 'work' zugewiesen werden. Andere Netze behalten die Default-Zone 'public'. Die Konfiguration erfolgt über das CLI auf der Kommandozeile.

==firewalld==
Im ersten Schritt werden die durch die Distribution vorgegebenen Zonen-Definitionen kopiert. Die folgenden Änderungen erfolgen auf den hier erzeugten Kopien:
<pre>
# cp /usr/lib/firewalld/zones/public.xml /etc/firewalld/zones/
# cp /usr/lib/firewalld/zones/work.xml /etc/firewalld/zones/
</pre>
Die geänderten Definitionen enthalten die Umsetzung für die oben genannten Anforderungen:
<pre>
# cat /etc/firewalld/zones/work.xml
<?xml version="1.0" encoding="utf-8"?>
<zone>
<short>Work</short>
<description>For use in work areas. You mostly trust the other computers on networks to not harm your computer. Only selected incoming connections are accepted.</description>
<service name="ssh"/>
<rule family="ipv4">
<source address="172.16.21.10"/>
<service name="bacula"/>
<accept/>
</rule>
</zone>
</pre>
<pre>
# cat /etc/firewalld/zones/public.xml
<?xml version="1.0" encoding="utf-8"?>
<zone>
<short>Public</short>
<description>For use in public areas. You do not trust the other computers on networks to not harm your computer. Only selected incoming connections are accepted.</description>
</zone>
</pre>

Neustart der Firewall:
<pre>
# systemctl restart firewalld.service
</pre>

==NetworkManager==
Vorhandene Netze anzeigen:
<pre>
# nmcli connection show
NAME UUID TYP GERÄT
Freifunk fec93f72-3488-4008-abfc-ec372d6f8806 802-11-wireless --
WLAN1 82be9628-2709-495f-a389-d209b74fcd05 802-11-wireless --
VPN1 ec0aa457-d3ec-4089-8c8f-1a53a8a33374 vpn --
LAN1 ee9ee0aa-57b9-4c5d-9c76-d2722986c5d8 802-3-ethernet --
enp2s0 8c1c5b53-0c80-44df-8c49-678b6d122d42 802-3-ethernet enp2s0
WLAN2 1e906b64-4909-4dbe-8d81-705ea64767b4 802-11-wireless wlp8s0
VPN2 23c0b2c5-b5a6-4e82-95b2-9b198074391d vpn --
</pre>
Man erkennt, dass das Notebook kabelgebunden über das Interface ''enp2s0'' am Netzwerk ''enp2s0'' und per WLAN über wlp8s0 am eigenen Funk-Netzwerk ''WLAN2'' hängt.

Die Zuordnung der Zone 'work' an beide Netze erfolgt über die UUID der Netze im [[NetworkManager]]:
<pre>
# nmcli con mod "8c1c5b53-0c80-44df-8c49-678b6d122d42" connection.zone work
# nmcli con mod "1e906b64-4909-4dbe-8d81-705ea64767b4" connection.zone work
</pre>
Anschließend werden die Verbindungen noch aktiviert:
<pre>
# nmcli con up uuid 8c1c5b53-0c80-44df-8c49-678b6d122d42
Verbindung wurde erfolgreich aktiviert (aktiver D-Bus-Pfad: /org/freedesktop/NetworkManager/ActiveConnection/38)
# nmcli con up uuid 1e906b64-4909-4dbe-8d81-705ea64767b4
Verbindung wurde erfolgreich aktiviert (aktiver D-Bus-Pfad: /org/freedesktop/NetworkManager/ActiveConnection/39)
</pre>

=Überprüfung=
Abschließend ist die Konfiguration zu überprüfen.

Die Anzeige im Falle der Verbindung in den heimischen Netzen zeigt, dass die beiden Interfaces ''enp2s0'' und ''wlp8s0'' der Zone 'work' zugeordnet sind:
<pre>
# firewall-cmd --get-active-zones
work
interfaces: enp2s0 wlp8s0
</pre>
Anzeige der Konfiguration dieser Zone:
<pre>
# firewall-cmd --zone=work --list-all
work (active)
interfaces: enp2s0 wlp8s0
sources:
services: ssh
ports:
masquerade: no
forward-ports:
icmp-blocks:
rich rules:
rule family="ipv4" source address="172.16.21.10" service name="bacula" accept
</pre>

Dagegen sollte bei einer Verbindung zu einem anderen Netzwerk die Default-Zone 'public' zugeordnet sein. Im folgenden Beispiel besteht ausschließlich eine Verbindung zum WLAN 'Freifunk':
<pre>
# nmcli connection show
NAME UUID TYP GERÄT
Freifunk fec93f72-3488-4008-abfc-ec372d6f8806 802-11-wireless wlp8s0
enp2s0 8c1c5b53-0c80-44df-8c49-678b6d122d42 802-3-ethernet --
WLAN1 82be9628-2709-495f-a389-d209b74fcd05 802-11-wireless --
VPN1 ec0aa457-d3ec-4089-8c8f-1a53a8a33374 vpn --
LAN1 ee9ee0aa-57b9-4c5d-9c76-d2722986c5d8 802-3-ethernet --
enp2s0 8c1c5b53-0c80-44df-8c49-678b6d122d42 802-3-ethernet --
WLAN2 1e906b64-4909-4dbe-8d81-705ea64767b4 802-11-wireless --
VPN2 23c0b2c5-b5a6-4e82-95b2-9b198074391d vpn --
</pre>
Dementsprechend zeigt die Prüfung, dass für das WLAN-Interface ''wlp8s0'' die Zone 'public' gesetzt wurde und das derzeit nicht verbundene ''enp2s0'' ohne Zuordnung verbleibt:
<pre>
# firewall-cmd --get-active-zones
public
interfaces: wlp8s0
</pre>
Es ist zu erkennen, dass [[SSH]] im Bereich ''services'' nicht zugelassen ist:
<pre>
# firewall-cmd --zone=public --list-all
public (default, active)
interfaces: wlp8s0
sources:
services:
ports:
masquerade: no
forward-ports:
icmp-blocks:
rich rules:
</pre>
Dabei erfolgt die Zuordnung der Zonen automatisch in Reaktion auf die Auswahl des Netzwerkes im [[NetworkManger]]. Eine manuelle Auswahl der Zone ist hierfür nicht erforderlich.

=Links=
*[http://www.firewalld.org/ firewalld.org] {{englisch}}
*[https://www.digitalocean.com/community/tutorials/how-to-set-up-a-firewall-using-firewalld-on-centos-7 How To Set Up a Firewall Using FirewallD on CentOS 7] {{englisch}}
*[https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Security_Guide/sec-Using_Firewalls.html redhat Security Guide] {{englisch}}
*[https://www.certdepot.net/rhel7-get-started-firewalld/ RHEL7: How to get started with Firewalld] {{englisch}}

[[Category:Security]] [[Category:Netzwerk]] [[Category:HowTo]]

Konfigurationsbeispiel eines Notebooks für den Einsatz in unterschiedlichen Netzen mit 'firewalld' und 'NetworkManager'

2016-10-25T19:48:19Z

Gehrke: allgemeineres Intro

{{UnderConstruction}}--[[Benutzer:Gehrke|Gehrke]] ([[Benutzer Diskussion:Gehrke|Diskussion]]) 22:09, 24. Okt. 2016 (CEST)

Im Folgenden soll eine Beispielkonfiguration für ein Notebook gezeigt werden, welches auf den Einsatz in '''Netzwerken mit unterschiedlichen Sicherheitsanforderungen''' eingerichtet ist.

Dieses System soll in vertrauenswürdigen Netzen (wie beispielsweise dem eigenen LAN oder WLAN) eine bestimmte Netzwerkfunktionalität wie [[SSH]] oder den File-Daemon von [[Bacula]] auf diesem Notebook erlauben. In anderen Netzen dagegen soll nur eine sehr eingeschränkte Netzwerk-Konnektivität erlaubt sein.

Dabei soll die Zuordnung anhand der Auswahl des Netzwerkes im [[NetworkManager]] erfolgen, welche bei bekannten Netzen in der Regel '''automatisch''' durchgeführt wird. Beispielsweise beim Wechsel vom (als sicher eingestuften) heimischen LANs in ein unsicheres öffentliches WLAN nach einem Ruhezustand des Notebooks.

Der Dienst [[firewalld]] kennt für die Gruppierung von Sicherheitsanforderungen das Konzept der ''Zonen''. Es werden von der Distribution eine Reihe von Zonen-Definitionen mitgeliefert, welche sich im Grad der Netzwerk-Freigibigkeit unterscheiden. Für das vorliegende Beispiel werden 2 vorgefertigte Zonen-Definitionen (''work'' und ''public'') kopiert und entsprechend der Anforderungen angepasst.

Die gewünschten Eigenschaften der Zonen sind:
*work: [[SSH]] und bacula-fd nur vom [[bacula]]-Server (172.16.21.10)
*public: Keinerlei Zugriff (auch kein SSH)

Dieses Beispiel basiert auf der Distribution [[CentOS]] 7. Um eine effektive und eindeutig dokumentierbare Vorgehensweise darzustellen, soll für alle administrativen Zugriffe auf die verwendeten Tools das jeweilige ''Command Line Interface (CLI)'' verwendet werden.

=Konfiguration=
Um dieses Ziel zu erreichen, sind zwei Subsysteme zu konfigurieren:
*[[firewalld]]: Dieser Dienst übernimmt die dynamische Konfiguration und Steuerung der lokalen Firewall. Die von der Distribution vorgegebenen Templates (XML) für die beiden Zonen werden kopiert und angepasst, so dass die Konfiguration persistent zur Verfügung steht.
*[[NetworkManager]]: Der Dienst konfiguriert und steuert die Netzwerkanbindung dynamisch. Bekannten Netzen soll anhand der UUID die Zone 'work' zugewiesen werden. Andere Netze behalten die Default-Zone 'public'. Die Konfiguration erfolgt über das CLI auf der Kommandozeile.

==firewalld==
Im ersten Schritt werden die durch die Distribution vorgegebenen Zonen-Definitionen kopiert. Die folgenden Änderungen erfolgen auf den hier erzeugten Kopien:
<pre>
# cp /usr/lib/firewalld/zones/public.xml /etc/firewalld/zones/
# cp /usr/lib/firewalld/zones/work.xml /etc/firewalld/zones/
</pre>
Die geänderten Definitionen enthalten die Umsetzung für die oben genannten Anforderungen:
<pre>
# cat /etc/firewalld/zones/work.xml
<?xml version="1.0" encoding="utf-8"?>
<zone>
<short>Work</short>
<description>For use in work areas. You mostly trust the other computers on networks to not harm your computer. Only selected incoming connections are accepted.</description>
<service name="ssh"/>
<rule family="ipv4">
<source address="172.16.21.10"/>
<service name="bacula"/>
<accept/>
</rule>
</zone>
</pre>
<pre>
# cat /etc/firewalld/zones/public.xml
<?xml version="1.0" encoding="utf-8"?>
<zone>
<short>Public</short>
<description>For use in public areas. You do not trust the other computers on networks to not harm your computer. Only selected incoming connections are accepted.</description>
</zone>
</pre>

Neustart der Firewall:
<pre>
# systemctl restart firewalld.service
</pre>

==NetworkManager==
Vorhandene Netze anzeigen:
<pre>
# nmcli connection show
NAME UUID TYP GERÄT
Freifunk fec93f72-3488-4008-abfc-ec372d6f8806 802-11-wireless --
WLAN1 82be9628-2709-495f-a389-d209b74fcd05 802-11-wireless --
VPN1 ec0aa457-d3ec-4089-8c8f-1a53a8a33374 vpn --
LAN1 ee9ee0aa-57b9-4c5d-9c76-d2722986c5d8 802-3-ethernet --
enp2s0 8c1c5b53-0c80-44df-8c49-678b6d122d42 802-3-ethernet enp2s0
WLAN2 1e906b64-4909-4dbe-8d81-705ea64767b4 802-11-wireless wlp8s0
VPN2 23c0b2c5-b5a6-4e82-95b2-9b198074391d vpn --
</pre>
Man erkennt, dass das Notebook kabelgebunden über das Interface ''enp2s0'' am Netzwerk ''enp2s0'' und per WLAN über wlp8s0 am eigenen Funk-Netzwerk ''WLAN2'' hängt.

Die Zuordnung der Zone 'work' an beide Netze erfolgt über die UUID der Netze im [[NetworkManager]]:
<pre>
# nmcli con mod "8c1c5b53-0c80-44df-8c49-678b6d122d42" connection.zone work
# nmcli con mod "1e906b64-4909-4dbe-8d81-705ea64767b4" connection.zone work
</pre>
Anschließend werden die Verbindungen noch aktiviert:
<pre>
# nmcli con up uuid 8c1c5b53-0c80-44df-8c49-678b6d122d42
Verbindung wurde erfolgreich aktiviert (aktiver D-Bus-Pfad: /org/freedesktop/NetworkManager/ActiveConnection/38)
# nmcli con up uuid 1e906b64-4909-4dbe-8d81-705ea64767b4
Verbindung wurde erfolgreich aktiviert (aktiver D-Bus-Pfad: /org/freedesktop/NetworkManager/ActiveConnection/39)
</pre>

=Überprüfung=
Abschließend ist die Konfiguration zu überprüfen.

Die Anzeige im Falle der Verbindung in den heimischen Netzen zeigt, dass die beiden Interfaces ''enp2s0'' und ''wlp8s0'' der Zone 'work' zugeordnet sind:
<pre>
# firewall-cmd --get-active-zones
work
interfaces: enp2s0 wlp8s0
</pre>
Anzeige der Konfiguration dieser Zone:
<pre>
# firewall-cmd --zone=work --list-all
work (active)
interfaces: enp2s0 wlp8s0
sources:
services: ssh
ports:
masquerade: no
forward-ports:
icmp-blocks:
rich rules:
rule family="ipv4" source address="172.16.21.10" service name="bacula" accept
</pre>

Dagegen sollte bei einer Verbindung zu einem anderen Netzwerk die Default-Zone 'public' zugeordnet sein. Im folgenden Beispiel besteht ausschließlich eine Verbindung zum WLAN 'Freifunk':
<pre>
# nmcli connection show
NAME UUID TYP GERÄT
Freifunk fec93f72-3488-4008-abfc-ec372d6f8806 802-11-wireless wlp8s0
enp2s0 8c1c5b53-0c80-44df-8c49-678b6d122d42 802-3-ethernet --
WLAN1 82be9628-2709-495f-a389-d209b74fcd05 802-11-wireless --
VPN1 ec0aa457-d3ec-4089-8c8f-1a53a8a33374 vpn --
LAN1 ee9ee0aa-57b9-4c5d-9c76-d2722986c5d8 802-3-ethernet --
enp2s0 8c1c5b53-0c80-44df-8c49-678b6d122d42 802-3-ethernet --
WLAN2 1e906b64-4909-4dbe-8d81-705ea64767b4 802-11-wireless --
VPN2 23c0b2c5-b5a6-4e82-95b2-9b198074391d vpn --
</pre>
Dementsprechend zeigt die Prüfung, dass für das WLAN-Interface ''wlp8s0'' die Zone 'public' gesetzt wurde und das derzeit nicht verbundene ''enp2s0'' ohne Zuordnung verbleibt:
<pre>
# firewall-cmd --get-active-zones
public
interfaces: wlp8s0
</pre>
Es ist zu erkennen, dass [[SSH]] im Bereich ''services'' nicht zugelassen ist:
<pre>
# firewall-cmd --zone=public --list-all
public (default, active)
interfaces: wlp8s0
sources:
services:
ports:
masquerade: no
forward-ports:
icmp-blocks:
rich rules:
</pre>
Dabei erfolgt die Zuordnung der Zonen automatisch in Reaktion auf die Auswahl des Netzwerkes im [[NetworkManger]]. Eine manuelle Auswahl der Zone ist hierfür nicht erforderlich.

=Links=
*[http://www.firewalld.org/ firewalld.org] {{englisch}}
*[https://www.digitalocean.com/community/tutorials/how-to-set-up-a-firewall-using-firewalld-on-centos-7 How To Set Up a Firewall Using FirewallD on CentOS 7] {{englisch}}
*[https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Security_Guide/sec-Using_Firewalls.html redhat Security Guide] {{englisch}}
*[https://www.certdepot.net/rhel7-get-started-firewalld/ RHEL7: How to get started with Firewalld] {{englisch}}

[[Category:Security]] [[Category:Netzwerk]] [[Category:HowTo]]

Konfigurationsbeispiel eines Notebooks für den Einsatz in unterschiedlichen Netzen mit 'firewalld' und 'NetworkManager'

2016-10-25T19:44:47Z

Gehrke: firewalld

{{UnderConstruction}}--[[Benutzer:Gehrke|Gehrke]] ([[Benutzer Diskussion:Gehrke|Diskussion]]) 22:09, 24. Okt. 2016 (CEST)

Im Folgenden soll eine Beispielkonfiguration für ein Notebook gezeigt werden, welches auf den Einsatz in '''Netzwerken mit unterschiedlichen Sicherheitsanforderungen''' eingerichtet ist.

Dieses System soll in vertrauenswürdigen Netzen (wie beispielsweise dem eigenen LAN oder WLAN) mit der Zone 'work' laufen, welche eine bestimmte Netzwerkfunktionalität wie [[SSH]] oder den File-Daemon von [[Bacula]] auf diesem Notebook erlaubt. In anderen Netzen dagegen soll die Default-Zone 'public' verwendet werden, welche nur eine sehr eingeschränkte Netzwerk-Konnektivität erlaubt.

Dabei soll die Zuordnung anhand der Auswahl des Netzwerkes im [[NetworkManager]] erfolgen, welche bei bekannten Netzen in der Regel '''automatisch''' durchgeführt wird. Beispielsweise beim Wechsel vom (als sicher eingestuften) heimischen LANs in ein unsicheres öffentliches WLAN nach einem Ruhezustand des Notebooks.

Der Dienst [[firewalld]] kennt für die Gruppierung von Sicherheitsanforderungen das Konzept der ''Zonen''. Es werden von der Distribution eine Reihe von Zonen-Definitionen mitgeliefert, welche sich im Grad der Netzwerk-Freigibigkeit unterscheiden. Für das vorliegende Beispiel werden 2 vorgefertigte Zonen-Definitionen (''work'' und ''public'') kopiert und entsprechend der Anforderungen angepasst.

Die gewünschten Eigenschaften der Zonen sind:
*work: [[SSH]] und bacula-fd nur vom [[bacula]]-Server (172.16.21.10)
*public: Keinerlei Zugriff (auch kein SSH)

Dieses Beispiel basiert auf der Distribution [[CentOS]] 7. Um eine effektive und eindeutig dokumentierbare Vorgehensweise darzustellen, soll für alle administrativen Zugriffe auf die verwendeten Tools das jeweilige ''Command Line Interface (CLI)'' verwendet werden.

=Konfiguration=
Um dieses Ziel zu erreichen, sind zwei Subsysteme zu konfigurieren:
*[[firewalld]]: Dieser Dienst übernimmt die dynamische Konfiguration und Steuerung der lokalen Firewall. Die von der Distribution vorgegebenen Templates (XML) für die beiden Zonen werden kopiert und angepasst, so dass die Konfiguration persistent zur Verfügung steht.
*[[NetworkManager]]: Der Dienst konfiguriert und steuert die Netzwerkanbindung dynamisch. Bekannten Netzen soll anhand der UUID die Zone 'work' zugewiesen werden. Andere Netze behalten die Default-Zone 'public'. Die Konfiguration erfolgt über das CLI auf der Kommandozeile.

==firewalld==
Im ersten Schritt werden die durch die Distribution vorgegebenen Zonen-Definitionen kopiert. Die folgenden Änderungen erfolgen auf den hier erzeugten Kopien:
<pre>
# cp /usr/lib/firewalld/zones/public.xml /etc/firewalld/zones/
# cp /usr/lib/firewalld/zones/work.xml /etc/firewalld/zones/
</pre>
Die geänderten Definitionen enthalten die Umsetzung für die oben genannten Anforderungen:
<pre>
# cat /etc/firewalld/zones/work.xml
<?xml version="1.0" encoding="utf-8"?>
<zone>
<short>Work</short>
<description>For use in work areas. You mostly trust the other computers on networks to not harm your computer. Only selected incoming connections are accepted.</description>
<service name="ssh"/>
<rule family="ipv4">
<source address="172.16.21.10"/>
<service name="bacula"/>
<accept/>
</rule>
</zone>
</pre>
<pre>
# cat /etc/firewalld/zones/public.xml
<?xml version="1.0" encoding="utf-8"?>
<zone>
<short>Public</short>
<description>For use in public areas. You do not trust the other computers on networks to not harm your computer. Only selected incoming connections are accepted.</description>
</zone>
</pre>

Neustart der Firewall:
<pre>
# systemctl restart firewalld.service
</pre>

==NetworkManager==
Vorhandene Netze anzeigen:
<pre>
# nmcli connection show
NAME UUID TYP GERÄT
Freifunk fec93f72-3488-4008-abfc-ec372d6f8806 802-11-wireless --
WLAN1 82be9628-2709-495f-a389-d209b74fcd05 802-11-wireless --
VPN1 ec0aa457-d3ec-4089-8c8f-1a53a8a33374 vpn --
LAN1 ee9ee0aa-57b9-4c5d-9c76-d2722986c5d8 802-3-ethernet --
enp2s0 8c1c5b53-0c80-44df-8c49-678b6d122d42 802-3-ethernet enp2s0
WLAN2 1e906b64-4909-4dbe-8d81-705ea64767b4 802-11-wireless wlp8s0
VPN2 23c0b2c5-b5a6-4e82-95b2-9b198074391d vpn --
</pre>
Man erkennt, dass das Notebook kabelgebunden über das Interface ''enp2s0'' am Netzwerk ''enp2s0'' und per WLAN über wlp8s0 am eigenen Funk-Netzwerk ''WLAN2'' hängt.

Die Zuordnung der Zone 'work' an beide Netze erfolgt über die UUID der Netze im [[NetworkManager]]:
<pre>
# nmcli con mod "8c1c5b53-0c80-44df-8c49-678b6d122d42" connection.zone work
# nmcli con mod "1e906b64-4909-4dbe-8d81-705ea64767b4" connection.zone work
</pre>
Anschließend werden die Verbindungen noch aktiviert:
<pre>
# nmcli con up uuid 8c1c5b53-0c80-44df-8c49-678b6d122d42
Verbindung wurde erfolgreich aktiviert (aktiver D-Bus-Pfad: /org/freedesktop/NetworkManager/ActiveConnection/38)
# nmcli con up uuid 1e906b64-4909-4dbe-8d81-705ea64767b4
Verbindung wurde erfolgreich aktiviert (aktiver D-Bus-Pfad: /org/freedesktop/NetworkManager/ActiveConnection/39)
</pre>

=Überprüfung=
Abschließend ist die Konfiguration zu überprüfen.

Die Anzeige im Falle der Verbindung in den heimischen Netzen zeigt, dass die beiden Interfaces ''enp2s0'' und ''wlp8s0'' der Zone 'work' zugeordnet sind:
<pre>
# firewall-cmd --get-active-zones
work
interfaces: enp2s0 wlp8s0
</pre>
Anzeige der Konfiguration dieser Zone:
<pre>
# firewall-cmd --zone=work --list-all
work (active)
interfaces: enp2s0 wlp8s0
sources:
services: ssh
ports:
masquerade: no
forward-ports:
icmp-blocks:
rich rules:
rule family="ipv4" source address="172.16.21.10" service name="bacula" accept
</pre>

Dagegen sollte bei einer Verbindung zu einem anderen Netzwerk die Default-Zone 'public' zugeordnet sein. Im folgenden Beispiel besteht ausschließlich eine Verbindung zum WLAN 'Freifunk':
<pre>
# nmcli connection show
NAME UUID TYP GERÄT
Freifunk fec93f72-3488-4008-abfc-ec372d6f8806 802-11-wireless wlp8s0
enp2s0 8c1c5b53-0c80-44df-8c49-678b6d122d42 802-3-ethernet --
WLAN1 82be9628-2709-495f-a389-d209b74fcd05 802-11-wireless --
VPN1 ec0aa457-d3ec-4089-8c8f-1a53a8a33374 vpn --
LAN1 ee9ee0aa-57b9-4c5d-9c76-d2722986c5d8 802-3-ethernet --
enp2s0 8c1c5b53-0c80-44df-8c49-678b6d122d42 802-3-ethernet --
WLAN2 1e906b64-4909-4dbe-8d81-705ea64767b4 802-11-wireless --
VPN2 23c0b2c5-b5a6-4e82-95b2-9b198074391d vpn --
</pre>
Dementsprechend zeigt die Prüfung, dass für das WLAN-Interface ''wlp8s0'' die Zone 'public' gesetzt wurde und das derzeit nicht verbundene ''enp2s0'' ohne Zuordnung verbleibt:
<pre>
# firewall-cmd --get-active-zones
public
interfaces: wlp8s0
</pre>
Es ist zu erkennen, dass [[SSH]] im Bereich ''services'' nicht zugelassen ist:
<pre>
# firewall-cmd --zone=public --list-all
public (default, active)
interfaces: wlp8s0
sources:
services:
ports:
masquerade: no
forward-ports:
icmp-blocks:
rich rules:
</pre>
Dabei erfolgt die Zuordnung der Zonen automatisch in Reaktion auf die Auswahl des Netzwerkes im [[NetworkManger]]. Eine manuelle Auswahl der Zone ist hierfür nicht erforderlich.

=Links=
*[http://www.firewalld.org/ firewalld.org] {{englisch}}
*[https://www.digitalocean.com/community/tutorials/how-to-set-up-a-firewall-using-firewalld-on-centos-7 How To Set Up a Firewall Using FirewallD on CentOS 7] {{englisch}}
*[https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Security_Guide/sec-Using_Firewalls.html redhat Security Guide] {{englisch}}
*[https://www.certdepot.net/rhel7-get-started-firewalld/ RHEL7: How to get started with Firewalld] {{englisch}}

[[Category:Security]] [[Category:Netzwerk]] [[Category:HowTo]]

Konfigurationsbeispiel eines Notebooks für den Einsatz in unterschiedlichen Netzen mit 'firewalld' und 'NetworkManager'

2016-10-25T18:21:46Z

Gehrke: /* Links */

{{UnderConstruction}}--[[Benutzer:Gehrke|Gehrke]] ([[Benutzer Diskussion:Gehrke|Diskussion]]) 22:09, 24. Okt. 2016 (CEST)

Im Folgenden soll eine Beispielkonfiguration für ein Notebook gezeigt werden, welches auf den Einsatz in '''Netzwerken mit unterschiedlichen Sicherheitsanforderungen''' eingerichtet ist.

Dieses System soll in vertrauenswürdigen Netzen (wie beispielsweise dem eigenen LAN oder WLAN) mit der Zone 'work' laufen, welche eine bestimmte Netzwerkfunktionalität wie [[SSH]] oder den File-Daemon von [[Bacula]] auf diesem Notebook erlaubt. In anderen Netzen dagegen soll die Default-Zone 'public' verwendet werden, welche nur eine sehr eingeschränkte Netzwerk-Konnektivität erlaubt.

Dabei soll die Zuordnung anhand der Auswahl des Netzwerkes im [[NetworkManager]] erfolgen, welche bei bekannten Netzen in der Regel '''automatisch''' durchgeführt wird. Beispielsweise beim Wechsel vom (als sicher eingestuften) heimischen LANs in ein unsicheres öffentliches WLAN nach einem Ruhezustand des Notebooks.

Gewünschte Eigenschaften der Zonen:
*work: [[SSH]] und bacula-fd nur vom [[bacula]]-Server (172.16.21.10)
*public: Keinerlei Zugriff (auch kein SSH)

Dieses Beispiel basiert auf der Distribution [[CentOS]] 7. Um eine effektive und eindeutig dokumentierbare Vorgehensweise darzustellen, soll für alle administrativen Zugriffe auf die verwendeten Tools das jeweilige ''Command Line Interface (CLI)'' verwendet werden.

=Konfiguration=
Um dieses Ziel zu erreichen, sind zwei Subsysteme zu konfigurieren:
*[[firewalld]]: Dieser Dienst übernimmt die dynamische Konfiguration und Steuerung der lokalen Firewall. Die von der Distribution vorgegebenen Templates (XML) für die beiden Zonen werden kopiert und angepasst, so dass die Konfiguration persistent zur Verfügung steht.
*[[NetworkManager]]: Der Dienst konfiguriert und steuert die Netzwerkanbindung dynamisch. Bekannten Netzen soll anhand der UUID die Zone 'work' zugewiesen werden. Andere Netze behalten die Default-Zone 'public'. Die Konfiguration erfolgt über das CLI auf der Kommandozeile.

==firewalld==
Im ersten Schritt werden die durch die Distribution vorgegebenen Zonen-Definitionen kopiert. Die folgenden Änderungen erfolgen auf den hier erzeugten Kopien:
<pre>
# cp /usr/lib/firewalld/zones/public.xml /etc/firewalld/zones/
# cp /usr/lib/firewalld/zones/work.xml /etc/firewalld/zones/
</pre>
Die geänderten Definitionen enthalten die Umsetzung für die oben genannten Anforderungen:
<pre>
# cat /etc/firewalld/zones/work.xml
<?xml version="1.0" encoding="utf-8"?>
<zone>
<short>Work</short>
<description>For use in work areas. You mostly trust the other computers on networks to not harm your computer. Only selected incoming connections are accepted.</description>
<service name="ssh"/>
<rule family="ipv4">
<source address="172.16.21.10"/>
<service name="bacula"/>
<accept/>
</rule>
</zone>
</pre>
<pre>
# cat /etc/firewalld/zones/public.xml
<?xml version="1.0" encoding="utf-8"?>
<zone>
<short>Public</short>
<description>For use in public areas. You do not trust the other computers on networks to not harm your computer. Only selected incoming connections are accepted.</description>
</zone>
</pre>

Neustart der Firewall:
<pre>
# systemctl restart firewalld.service
</pre>

==NetworkManager==
Vorhandene Netze anzeigen:
<pre>
# nmcli connection show
NAME UUID TYP GERÄT
Freifunk fec93f72-3488-4008-abfc-ec372d6f8806 802-11-wireless --
WLAN1 82be9628-2709-495f-a389-d209b74fcd05 802-11-wireless --
VPN1 ec0aa457-d3ec-4089-8c8f-1a53a8a33374 vpn --
LAN1 ee9ee0aa-57b9-4c5d-9c76-d2722986c5d8 802-3-ethernet --
enp2s0 8c1c5b53-0c80-44df-8c49-678b6d122d42 802-3-ethernet enp2s0
WLAN2 1e906b64-4909-4dbe-8d81-705ea64767b4 802-11-wireless wlp8s0
VPN2 23c0b2c5-b5a6-4e82-95b2-9b198074391d vpn --
</pre>
Man erkennt, dass das Notebook kabelgebunden über das Interface ''enp2s0'' am Netzwerk ''enp2s0'' und per WLAN über wlp8s0 am eigenen Funk-Netzwerk ''WLAN2'' hängt.

Die Zuordnung der Zone 'work' an beide Netze erfolgt über die UUID der Netze im [[NetworkManager]]:
<pre>
# nmcli con mod "8c1c5b53-0c80-44df-8c49-678b6d122d42" connection.zone work
# nmcli con mod "1e906b64-4909-4dbe-8d81-705ea64767b4" connection.zone work
</pre>
Anschließend werden die Verbindungen noch aktiviert:
<pre>
# nmcli con up uuid 8c1c5b53-0c80-44df-8c49-678b6d122d42
Verbindung wurde erfolgreich aktiviert (aktiver D-Bus-Pfad: /org/freedesktop/NetworkManager/ActiveConnection/38)
# nmcli con up uuid 1e906b64-4909-4dbe-8d81-705ea64767b4
Verbindung wurde erfolgreich aktiviert (aktiver D-Bus-Pfad: /org/freedesktop/NetworkManager/ActiveConnection/39)
</pre>

=Überprüfung=
Abschließend ist die Konfiguration zu überprüfen.

Die Anzeige im Falle der Verbindung in den heimischen Netzen zeigt, dass die beiden Interfaces ''enp2s0'' und ''wlp8s0'' der Zone 'work' zugeordnet sind:
<pre>
# firewall-cmd --get-active-zones
work
interfaces: enp2s0 wlp8s0
</pre>
Anzeige der Konfiguration dieser Zone:
<pre>
# firewall-cmd --zone=work --list-all
work (active)
interfaces: enp2s0 wlp8s0
sources:
services: ssh
ports:
masquerade: no
forward-ports:
icmp-blocks:
rich rules:
rule family="ipv4" source address="172.16.21.10" service name="bacula" accept
</pre>

Dagegen sollte bei einer Verbindung zu einem anderen Netzwerk die Default-Zone 'public' zugeordnet sein. Im folgenden Beispiel besteht ausschließlich eine Verbindung zum WLAN 'Freifunk':
<pre>
# nmcli connection show
NAME UUID TYP GERÄT
Freifunk fec93f72-3488-4008-abfc-ec372d6f8806 802-11-wireless wlp8s0
enp2s0 8c1c5b53-0c80-44df-8c49-678b6d122d42 802-3-ethernet --
WLAN1 82be9628-2709-495f-a389-d209b74fcd05 802-11-wireless --
VPN1 ec0aa457-d3ec-4089-8c8f-1a53a8a33374 vpn --
LAN1 ee9ee0aa-57b9-4c5d-9c76-d2722986c5d8 802-3-ethernet --
enp2s0 8c1c5b53-0c80-44df-8c49-678b6d122d42 802-3-ethernet --
WLAN2 1e906b64-4909-4dbe-8d81-705ea64767b4 802-11-wireless --
VPN2 23c0b2c5-b5a6-4e82-95b2-9b198074391d vpn --
</pre>
Dementsprechend zeigt die Prüfung, dass für das WLAN-Interface ''wlp8s0'' die Zone 'public' gesetzt wurde und das derzeit nicht verbundene ''enp2s0'' ohne Zuordnung verbleibt:
<pre>
# firewall-cmd --get-active-zones
public
interfaces: wlp8s0
</pre>
Es ist zu erkennen, dass [[SSH]] im Bereich ''services'' nicht zugelassen ist:
<pre>
# firewall-cmd --zone=public --list-all
public (default, active)
interfaces: wlp8s0
sources:
services:
ports:
masquerade: no
forward-ports:
icmp-blocks:
rich rules:
</pre>
Dabei erfolgt die Zuordnung der Zonen automatisch in Reaktion auf die Auswahl des Netzwerkes im [[NetworkManger]]. Eine manuelle Auswahl der Zone ist hierfür nicht erforderlich.

=Links=
*[http://www.firewalld.org/ firewalld.org] {{englisch}}
*[https://www.digitalocean.com/community/tutorials/how-to-set-up-a-firewall-using-firewalld-on-centos-7 How To Set Up a Firewall Using FirewallD on CentOS 7] {{englisch}}
*[https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Security_Guide/sec-Using_Firewalls.html redhat Security Guide] {{englisch}}
*[https://www.certdepot.net/rhel7-get-started-firewalld/ RHEL7: How to get started with Firewalld] {{englisch}}

[[Category:Security]] [[Category:Netzwerk]] [[Category:HowTo]]

Konfigurationsbeispiel eines Notebooks für den Einsatz in unterschiedlichen Netzen mit 'firewalld' und 'NetworkManager'

2016-10-25T18:02:22Z

Gehrke: /* Links */

{{UnderConstruction}}--[[Benutzer:Gehrke|Gehrke]] ([[Benutzer Diskussion:Gehrke|Diskussion]]) 22:09, 24. Okt. 2016 (CEST)

Im Folgenden soll eine Beispielkonfiguration für ein Notebook gezeigt werden, welches auf den Einsatz in '''Netzwerken mit unterschiedlichen Sicherheitsanforderungen''' eingerichtet ist.

Dieses System soll in vertrauenswürdigen Netzen (wie beispielsweise dem eigenen LAN oder WLAN) mit der Zone 'work' laufen, welche eine bestimmte Netzwerkfunktionalität wie [[SSH]] oder den File-Daemon von [[Bacula]] auf diesem Notebook erlaubt. In anderen Netzen dagegen soll die Default-Zone 'public' verwendet werden, welche nur eine sehr eingeschränkte Netzwerk-Konnektivität erlaubt.

Dabei soll die Zuordnung anhand der Auswahl des Netzwerkes im [[NetworkManager]] erfolgen, welche bei bekannten Netzen in der Regel '''automatisch''' durchgeführt wird. Beispielsweise beim Wechsel vom (als sicher eingestuften) heimischen LANs in ein unsicheres öffentliches WLAN nach einem Ruhezustand des Notebooks.

Gewünschte Eigenschaften der Zonen:
*work: [[SSH]] und bacula-fd nur vom [[bacula]]-Server (172.16.21.10)
*public: Keinerlei Zugriff (auch kein SSH)

Dieses Beispiel basiert auf der Distribution [[CentOS]] 7. Um eine effektive und eindeutig dokumentierbare Vorgehensweise darzustellen, soll für alle administrativen Zugriffe auf die verwendeten Tools das jeweilige ''Command Line Interface (CLI)'' verwendet werden.

=Konfiguration=
Um dieses Ziel zu erreichen, sind zwei Subsysteme zu konfigurieren:
*[[firewalld]]: Dieser Dienst übernimmt die dynamische Konfiguration und Steuerung der lokalen Firewall. Die von der Distribution vorgegebenen Templates (XML) für die beiden Zonen werden kopiert und angepasst, so dass die Konfiguration persistent zur Verfügung steht.
*[[NetworkManager]]: Der Dienst konfiguriert und steuert die Netzwerkanbindung dynamisch. Bekannten Netzen soll anhand der UUID die Zone 'work' zugewiesen werden. Andere Netze behalten die Default-Zone 'public'. Die Konfiguration erfolgt über das CLI auf der Kommandozeile.

==firewalld==
Im ersten Schritt werden die durch die Distribution vorgegebenen Zonen-Definitionen kopiert. Die folgenden Änderungen erfolgen auf den hier erzeugten Kopien:
<pre>
# cp /usr/lib/firewalld/zones/public.xml /etc/firewalld/zones/
# cp /usr/lib/firewalld/zones/work.xml /etc/firewalld/zones/
</pre>
Die geänderten Definitionen enthalten die Umsetzung für die oben genannten Anforderungen:
<pre>
# cat /etc/firewalld/zones/work.xml
<?xml version="1.0" encoding="utf-8"?>
<zone>
<short>Work</short>
<description>For use in work areas. You mostly trust the other computers on networks to not harm your computer. Only selected incoming connections are accepted.</description>
<service name="ssh"/>
<rule family="ipv4">
<source address="172.16.21.10"/>
<service name="bacula"/>
<accept/>
</rule>
</zone>
</pre>
<pre>
# cat /etc/firewalld/zones/public.xml
<?xml version="1.0" encoding="utf-8"?>
<zone>
<short>Public</short>
<description>For use in public areas. You do not trust the other computers on networks to not harm your computer. Only selected incoming connections are accepted.</description>
</zone>
</pre>

Neustart der Firewall:
<pre>
# systemctl restart firewalld.service
</pre>

==NetworkManager==
Vorhandene Netze anzeigen:
<pre>
# nmcli connection show
NAME UUID TYP GERÄT
Freifunk fec93f72-3488-4008-abfc-ec372d6f8806 802-11-wireless --
WLAN1 82be9628-2709-495f-a389-d209b74fcd05 802-11-wireless --
VPN1 ec0aa457-d3ec-4089-8c8f-1a53a8a33374 vpn --
LAN1 ee9ee0aa-57b9-4c5d-9c76-d2722986c5d8 802-3-ethernet --
enp2s0 8c1c5b53-0c80-44df-8c49-678b6d122d42 802-3-ethernet enp2s0
WLAN2 1e906b64-4909-4dbe-8d81-705ea64767b4 802-11-wireless wlp8s0
VPN2 23c0b2c5-b5a6-4e82-95b2-9b198074391d vpn --
</pre>
Man erkennt, dass das Notebook kabelgebunden über das Interface ''enp2s0'' am Netzwerk ''enp2s0'' und per WLAN über wlp8s0 am eigenen Funk-Netzwerk ''WLAN2'' hängt.

Die Zuordnung der Zone 'work' an beide Netze erfolgt über die UUID der Netze im [[NetworkManager]]:
<pre>
# nmcli con mod "8c1c5b53-0c80-44df-8c49-678b6d122d42" connection.zone work
# nmcli con mod "1e906b64-4909-4dbe-8d81-705ea64767b4" connection.zone work
</pre>
Anschließend werden die Verbindungen noch aktiviert:
<pre>
# nmcli con up uuid 8c1c5b53-0c80-44df-8c49-678b6d122d42
Verbindung wurde erfolgreich aktiviert (aktiver D-Bus-Pfad: /org/freedesktop/NetworkManager/ActiveConnection/38)
# nmcli con up uuid 1e906b64-4909-4dbe-8d81-705ea64767b4
Verbindung wurde erfolgreich aktiviert (aktiver D-Bus-Pfad: /org/freedesktop/NetworkManager/ActiveConnection/39)
</pre>

=Überprüfung=
Abschließend ist die Konfiguration zu überprüfen.

Die Anzeige im Falle der Verbindung in den heimischen Netzen zeigt, dass die beiden Interfaces ''enp2s0'' und ''wlp8s0'' der Zone 'work' zugeordnet sind:
<pre>
# firewall-cmd --get-active-zones
work
interfaces: enp2s0 wlp8s0
</pre>
Anzeige der Konfiguration dieser Zone:
<pre>
# firewall-cmd --zone=work --list-all
work (active)
interfaces: enp2s0 wlp8s0
sources:
services: ssh
ports:
masquerade: no
forward-ports:
icmp-blocks:
rich rules:
rule family="ipv4" source address="172.16.21.10" service name="bacula" accept
</pre>

Dagegen sollte bei einer Verbindung zu einem anderen Netzwerk die Default-Zone 'public' zugeordnet sein. Im folgenden Beispiel besteht ausschließlich eine Verbindung zum WLAN 'Freifunk':
<pre>
# nmcli connection show
NAME UUID TYP GERÄT
Freifunk fec93f72-3488-4008-abfc-ec372d6f8806 802-11-wireless wlp8s0
enp2s0 8c1c5b53-0c80-44df-8c49-678b6d122d42 802-3-ethernet --
WLAN1 82be9628-2709-495f-a389-d209b74fcd05 802-11-wireless --
VPN1 ec0aa457-d3ec-4089-8c8f-1a53a8a33374 vpn --
LAN1 ee9ee0aa-57b9-4c5d-9c76-d2722986c5d8 802-3-ethernet --
enp2s0 8c1c5b53-0c80-44df-8c49-678b6d122d42 802-3-ethernet --
WLAN2 1e906b64-4909-4dbe-8d81-705ea64767b4 802-11-wireless --
VPN2 23c0b2c5-b5a6-4e82-95b2-9b198074391d vpn --
</pre>
Dementsprechend zeigt die Prüfung, dass für das WLAN-Interface ''wlp8s0'' die Zone 'public' gesetzt wurde und das derzeit nicht verbundene ''enp2s0'' ohne Zuordnung verbleibt:
<pre>
# firewall-cmd --get-active-zones
public
interfaces: wlp8s0
</pre>
Es ist zu erkennen, dass [[SSH]] im Bereich ''services'' nicht zugelassen ist:
<pre>
# firewall-cmd --zone=public --list-all
public (default, active)
interfaces: wlp8s0
sources:
services:
ports:
masquerade: no
forward-ports:
icmp-blocks:
rich rules:
</pre>
Dabei erfolgt die Zuordnung der Zonen automatisch in Reaktion auf die Auswahl des Netzwerkes im [[NetworkManger]]. Eine manuelle Auswahl der Zone ist hierfür nicht erforderlich.

=Links=
*[http://www.firewalld.org/ firewalld.org] {{englisch}}
*[https://www.digitalocean.com/community/tutorials/how-to-set-up-a-firewall-using-firewalld-on-centos-7 How To Set Up a Firewall Using FirewallD on CentOS 7] {{englisch}}
*[https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Security_Guide/sec-Using_Firewalls.html redhat Security Guide] {{englisch}}

[[Category:Security]] [[Category:Netzwerk]] [[Category:HowTo]]

Konfigurationsbeispiel eines Notebooks für den Einsatz in unterschiedlichen Netzen mit 'firewalld' und 'NetworkManager'

2016-10-25T17:49:07Z

Gehrke: /* Überprüfung */

{{UnderConstruction}}--[[Benutzer:Gehrke|Gehrke]] ([[Benutzer Diskussion:Gehrke|Diskussion]]) 22:09, 24. Okt. 2016 (CEST)

Im Folgenden soll eine Beispielkonfiguration für ein Notebook gezeigt werden, welches auf den Einsatz in '''Netzwerken mit unterschiedlichen Sicherheitsanforderungen''' eingerichtet ist.

Dieses System soll in vertrauenswürdigen Netzen (wie beispielsweise dem eigenen LAN oder WLAN) mit der Zone 'work' laufen, welche eine bestimmte Netzwerkfunktionalität wie [[SSH]] oder den File-Daemon von [[Bacula]] auf diesem Notebook erlaubt. In anderen Netzen dagegen soll die Default-Zone 'public' verwendet werden, welche nur eine sehr eingeschränkte Netzwerk-Konnektivität erlaubt.

Dabei soll die Zuordnung anhand der Auswahl des Netzwerkes im [[NetworkManager]] erfolgen, welche bei bekannten Netzen in der Regel '''automatisch''' durchgeführt wird. Beispielsweise beim Wechsel vom (als sicher eingestuften) heimischen LANs in ein unsicheres öffentliches WLAN nach einem Ruhezustand des Notebooks.

Gewünschte Eigenschaften der Zonen:
*work: [[SSH]] und bacula-fd nur vom [[bacula]]-Server (172.16.21.10)
*public: Keinerlei Zugriff (auch kein SSH)

Dieses Beispiel basiert auf der Distribution [[CentOS]] 7. Um eine effektive und eindeutig dokumentierbare Vorgehensweise darzustellen, soll für alle administrativen Zugriffe auf die verwendeten Tools das jeweilige ''Command Line Interface (CLI)'' verwendet werden.

=Konfiguration=
Um dieses Ziel zu erreichen, sind zwei Subsysteme zu konfigurieren:
*[[firewalld]]: Dieser Dienst übernimmt die dynamische Konfiguration und Steuerung der lokalen Firewall. Die von der Distribution vorgegebenen Templates (XML) für die beiden Zonen werden kopiert und angepasst, so dass die Konfiguration persistent zur Verfügung steht.
*[[NetworkManager]]: Der Dienst konfiguriert und steuert die Netzwerkanbindung dynamisch. Bekannten Netzen soll anhand der UUID die Zone 'work' zugewiesen werden. Andere Netze behalten die Default-Zone 'public'. Die Konfiguration erfolgt über das CLI auf der Kommandozeile.

==firewalld==
Im ersten Schritt werden die durch die Distribution vorgegebenen Zonen-Definitionen kopiert. Die folgenden Änderungen erfolgen auf den hier erzeugten Kopien:
<pre>
# cp /usr/lib/firewalld/zones/public.xml /etc/firewalld/zones/
# cp /usr/lib/firewalld/zones/work.xml /etc/firewalld/zones/
</pre>
Die geänderten Definitionen enthalten die Umsetzung für die oben genannten Anforderungen:
<pre>
# cat /etc/firewalld/zones/work.xml
<?xml version="1.0" encoding="utf-8"?>
<zone>
<short>Work</short>
<description>For use in work areas. You mostly trust the other computers on networks to not harm your computer. Only selected incoming connections are accepted.</description>
<service name="ssh"/>
<rule family="ipv4">
<source address="172.16.21.10"/>
<service name="bacula"/>
<accept/>
</rule>
</zone>
</pre>
<pre>
# cat /etc/firewalld/zones/public.xml
<?xml version="1.0" encoding="utf-8"?>
<zone>
<short>Public</short>
<description>For use in public areas. You do not trust the other computers on networks to not harm your computer. Only selected incoming connections are accepted.</description>
</zone>
</pre>

Neustart der Firewall:
<pre>
# systemctl restart firewalld.service
</pre>

==NetworkManager==
Vorhandene Netze anzeigen:
<pre>
# nmcli connection show
NAME UUID TYP GERÄT
Freifunk fec93f72-3488-4008-abfc-ec372d6f8806 802-11-wireless --
WLAN1 82be9628-2709-495f-a389-d209b74fcd05 802-11-wireless --
VPN1 ec0aa457-d3ec-4089-8c8f-1a53a8a33374 vpn --
LAN1 ee9ee0aa-57b9-4c5d-9c76-d2722986c5d8 802-3-ethernet --
enp2s0 8c1c5b53-0c80-44df-8c49-678b6d122d42 802-3-ethernet enp2s0
WLAN2 1e906b64-4909-4dbe-8d81-705ea64767b4 802-11-wireless wlp8s0
VPN2 23c0b2c5-b5a6-4e82-95b2-9b198074391d vpn --
</pre>
Man erkennt, dass das Notebook kabelgebunden über das Interface ''enp2s0'' am Netzwerk ''enp2s0'' und per WLAN über wlp8s0 am eigenen Funk-Netzwerk ''WLAN2'' hängt.

Die Zuordnung der Zone 'work' an beide Netze erfolgt über die UUID der Netze im [[NetworkManager]]:
<pre>
# nmcli con mod "8c1c5b53-0c80-44df-8c49-678b6d122d42" connection.zone work
# nmcli con mod "1e906b64-4909-4dbe-8d81-705ea64767b4" connection.zone work
</pre>
Anschließend werden die Verbindungen noch aktiviert:
<pre>
# nmcli con up uuid 8c1c5b53-0c80-44df-8c49-678b6d122d42
Verbindung wurde erfolgreich aktiviert (aktiver D-Bus-Pfad: /org/freedesktop/NetworkManager/ActiveConnection/38)
# nmcli con up uuid 1e906b64-4909-4dbe-8d81-705ea64767b4
Verbindung wurde erfolgreich aktiviert (aktiver D-Bus-Pfad: /org/freedesktop/NetworkManager/ActiveConnection/39)
</pre>

=Überprüfung=
Abschließend ist die Konfiguration zu überprüfen.

Die Anzeige im Falle der Verbindung in den heimischen Netzen zeigt, dass die beiden Interfaces ''enp2s0'' und ''wlp8s0'' der Zone 'work' zugeordnet sind:
<pre>
# firewall-cmd --get-active-zones
work
interfaces: enp2s0 wlp8s0
</pre>
Anzeige der Konfiguration dieser Zone:
<pre>
# firewall-cmd --zone=work --list-all
work (active)
interfaces: enp2s0 wlp8s0
sources:
services: ssh
ports:
masquerade: no
forward-ports:
icmp-blocks:
rich rules:
rule family="ipv4" source address="172.16.21.10" service name="bacula" accept
</pre>

Dagegen sollte bei einer Verbindung zu einem anderen Netzwerk die Default-Zone 'public' zugeordnet sein. Im folgenden Beispiel besteht ausschließlich eine Verbindung zum WLAN 'Freifunk':
<pre>
# nmcli connection show
NAME UUID TYP GERÄT
Freifunk fec93f72-3488-4008-abfc-ec372d6f8806 802-11-wireless wlp8s0
enp2s0 8c1c5b53-0c80-44df-8c49-678b6d122d42 802-3-ethernet --
WLAN1 82be9628-2709-495f-a389-d209b74fcd05 802-11-wireless --
VPN1 ec0aa457-d3ec-4089-8c8f-1a53a8a33374 vpn --
LAN1 ee9ee0aa-57b9-4c5d-9c76-d2722986c5d8 802-3-ethernet --
enp2s0 8c1c5b53-0c80-44df-8c49-678b6d122d42 802-3-ethernet --
WLAN2 1e906b64-4909-4dbe-8d81-705ea64767b4 802-11-wireless --
VPN2 23c0b2c5-b5a6-4e82-95b2-9b198074391d vpn --
</pre>
Dementsprechend zeigt die Prüfung, dass für das WLAN-Interface ''wlp8s0'' die Zone 'public' gesetzt wurde und das derzeit nicht verbundene ''enp2s0'' ohne Zuordnung verbleibt:
<pre>
# firewall-cmd --get-active-zones
public
interfaces: wlp8s0
</pre>
Es ist zu erkennen, dass [[SSH]] im Bereich ''services'' nicht zugelassen ist:
<pre>
# firewall-cmd --zone=public --list-all
public (default, active)
interfaces: wlp8s0
sources:
services:
ports:
masquerade: no
forward-ports:
icmp-blocks:
rich rules:
</pre>
Dabei erfolgt die Zuordnung der Zonen automatisch in Reaktion auf die Auswahl des Netzwerkes im [[NetworkManger]]. Eine manuelle Auswahl der Zone ist hierfür nicht erforderlich.

=Links=
<ToDo>

[[Category:Security]] [[Category:Netzwerk]] [[Category:HowTo]]

Konfigurationsbeispiel eines Notebooks für den Einsatz in unterschiedlichen Netzen mit 'firewalld' und 'NetworkManager'

2016-10-25T14:47:51Z

Gehrke: Links

{{UnderConstruction}}--[[Benutzer:Gehrke|Gehrke]] ([[Benutzer Diskussion:Gehrke|Diskussion]]) 22:09, 24. Okt. 2016 (CEST)

Im Folgenden soll eine Beispielkonfiguration für ein Notebook gezeigt werden, welches auf den Einsatz in '''Netzwerken mit unterschiedlichen Sicherheitsanforderungen''' eingerichtet ist.

Dieses System soll in vertrauenswürdigen Netzen (wie beispielsweise dem eigenen LAN oder WLAN) mit der Zone 'work' laufen, welche eine bestimmte Netzwerkfunktionalität wie [[SSH]] oder den File-Daemon von [[Bacula]] auf diesem Notebook erlaubt. In anderen Netzen dagegen soll die Default-Zone 'public' verwendet werden, welche nur eine sehr eingeschränkte Netzwerk-Konnektivität erlaubt.

Dabei soll die Zuordnung anhand der Auswahl des Netzwerkes im [[NetworkManager]] erfolgen, welche bei bekannten Netzen in der Regel '''automatisch''' durchgeführt wird. Beispielsweise beim Wechsel vom (als sicher eingestuften) heimischen LANs in ein unsicheres öffentliches WLAN nach einem Ruhezustand des Notebooks.

Gewünschte Eigenschaften der Zonen:
*work: [[SSH]] und bacula-fd nur vom [[bacula]]-Server (172.16.21.10)
*public: Keinerlei Zugriff (auch kein SSH)

Dieses Beispiel basiert auf der Distribution [[CentOS]] 7. Um eine effektive und eindeutig dokumentierbare Vorgehensweise darzustellen, soll für alle administrativen Zugriffe auf die verwendeten Tools das jeweilige ''Command Line Interface (CLI)'' verwendet werden.

=Konfiguration=
Um dieses Ziel zu erreichen, sind zwei Subsysteme zu konfigurieren:
*[[firewalld]]: Dieser Dienst übernimmt die dynamische Konfiguration und Steuerung der lokalen Firewall. Die von der Distribution vorgegebenen Templates (XML) für die beiden Zonen werden kopiert und angepasst, so dass die Konfiguration persistent zur Verfügung steht.
*[[NetworkManager]]: Der Dienst konfiguriert und steuert die Netzwerkanbindung dynamisch. Bekannten Netzen soll anhand der UUID die Zone 'work' zugewiesen werden. Andere Netze behalten die Default-Zone 'public'. Die Konfiguration erfolgt über das CLI auf der Kommandozeile.

==firewalld==
Im ersten Schritt werden die durch die Distribution vorgegebenen Zonen-Definitionen kopiert. Die folgenden Änderungen erfolgen auf den hier erzeugten Kopien:
<pre>
# cp /usr/lib/firewalld/zones/public.xml /etc/firewalld/zones/
# cp /usr/lib/firewalld/zones/work.xml /etc/firewalld/zones/
</pre>
Die geänderten Definitionen enthalten die Umsetzung für die oben genannten Anforderungen:
<pre>
# cat /etc/firewalld/zones/work.xml
<?xml version="1.0" encoding="utf-8"?>
<zone>
<short>Work</short>
<description>For use in work areas. You mostly trust the other computers on networks to not harm your computer. Only selected incoming connections are accepted.</description>
<service name="ssh"/>
<rule family="ipv4">
<source address="172.16.21.10"/>
<service name="bacula"/>
<accept/>
</rule>
</zone>
</pre>
<pre>
# cat /etc/firewalld/zones/public.xml
<?xml version="1.0" encoding="utf-8"?>
<zone>
<short>Public</short>
<description>For use in public areas. You do not trust the other computers on networks to not harm your computer. Only selected incoming connections are accepted.</description>
</zone>
</pre>

Neustart der Firewall:
<pre>
# systemctl restart firewalld.service
</pre>

==NetworkManager==
Vorhandene Netze anzeigen:
<pre>
# nmcli connection show
NAME UUID TYP GERÄT
Freifunk fec93f72-3488-4008-abfc-ec372d6f8806 802-11-wireless --
WLAN1 82be9628-2709-495f-a389-d209b74fcd05 802-11-wireless --
VPN1 ec0aa457-d3ec-4089-8c8f-1a53a8a33374 vpn --
LAN1 ee9ee0aa-57b9-4c5d-9c76-d2722986c5d8 802-3-ethernet --
enp2s0 8c1c5b53-0c80-44df-8c49-678b6d122d42 802-3-ethernet enp2s0
WLAN2 1e906b64-4909-4dbe-8d81-705ea64767b4 802-11-wireless wlp8s0
VPN2 23c0b2c5-b5a6-4e82-95b2-9b198074391d vpn --
</pre>
Man erkennt, dass das Notebook kabelgebunden über das Interface ''enp2s0'' am Netzwerk ''enp2s0'' und per WLAN über wlp8s0 am eigenen Funk-Netzwerk ''WLAN2'' hängt.

Die Zuordnung der Zone 'work' an beide Netze erfolgt über die UUID der Netze im [[NetworkManager]]:
<pre>
# nmcli con mod "8c1c5b53-0c80-44df-8c49-678b6d122d42" connection.zone work
# nmcli con mod "1e906b64-4909-4dbe-8d81-705ea64767b4" connection.zone work
</pre>
Anschließend werden die Verbindungen noch aktiviert:
<pre>
# nmcli con up uuid 8c1c5b53-0c80-44df-8c49-678b6d122d42
Verbindung wurde erfolgreich aktiviert (aktiver D-Bus-Pfad: /org/freedesktop/NetworkManager/ActiveConnection/38)
# nmcli con up uuid 1e906b64-4909-4dbe-8d81-705ea64767b4
Verbindung wurde erfolgreich aktiviert (aktiver D-Bus-Pfad: /org/freedesktop/NetworkManager/ActiveConnection/39)
</pre>

=Überprüfung=
Abschließend ist die Konfiguration zu überprüfen.

Die Anzeige im Falle der Verbindung in den heimischen Netzen zeigt, dass die beiden Interfaces ''enp2s0'' und ''wlp8s0'' der Zone 'work' zugeordnet sind:
<pre>
# firewall-cmd --get-active-zones
work
interfaces: enp2s0 wlp8s0
</pre>
Anzeige der Konfiguration dieser Zone:
<pre>
# firewall-cmd --zone=work --list-all --permanent
work
interfaces:
sources:
services: ssh
ports:
masquerade: no
forward-ports:
icmp-blocks:
rich rules:
rule family="ipv4" source address="172.16.21.10" service name="bacula" accept
</pre>

Dagegen sollte bei einer Verbindung zu einem anderen Netzwerk die Default-Zone 'public' zugeordnet sein. Im folgenden Beispiel besteht ausschließlich eine Verbindung zum WLAN 'Freifunk':
<pre>
# nmcli connection show
NAME UUID TYP GERÄT
Freifunk fec93f72-3488-4008-abfc-ec372d6f8806 802-11-wireless wlp8s0
enp2s0 8c1c5b53-0c80-44df-8c49-678b6d122d42 802-3-ethernet --
WLAN1 82be9628-2709-495f-a389-d209b74fcd05 802-11-wireless --
VPN1 ec0aa457-d3ec-4089-8c8f-1a53a8a33374 vpn --
LAN1 ee9ee0aa-57b9-4c5d-9c76-d2722986c5d8 802-3-ethernet --
enp2s0 8c1c5b53-0c80-44df-8c49-678b6d122d42 802-3-ethernet --
WLAN2 1e906b64-4909-4dbe-8d81-705ea64767b4 802-11-wireless --
VPN2 23c0b2c5-b5a6-4e82-95b2-9b198074391d vpn --
</pre>
Dementsprechend zeigt die Prüfung, dass für das WLAN-Interface ''wlp8s0'' die Zone 'public' gesetzt wurde und das derzeit nicht verbundene ''enp2s0'' ohne Zuordnung verbleibt:
<pre>
# firewall-cmd --get-active-zones
public
interfaces: wlp8s0
</pre>
Es ist zu erkennen, dass [[SSH]] im Bereich ''services'' nicht zugelassen ist:
<pre>
# firewall-cmd --zone=public --list-all
public (default, active)
interfaces: wlp8s0
sources:
services:
ports:
masquerade: no
forward-ports:
icmp-blocks:
rich rules:
</pre>
Dabei erfolgt die Zuordnung der Zonen automatisch in Reaktion auf die Auswahl des Netzwerkes im [[NetworkManger]]. Eine manuelle Auswahl der Zone ist hierfür nicht erforderlich.

=Links=
<ToDo>

[[Category:Security]] [[Category:Netzwerk]] [[Category:HowTo]]

Konfigurationsbeispiel eines Notebooks für den Einsatz in unterschiedlichen Netzen mit 'firewalld' und 'NetworkManager'

2016-10-25T14:42:43Z

Gehrke: Bereinigung

{{UnderConstruction}}--[[Benutzer:Gehrke|Gehrke]] ([[Benutzer Diskussion:Gehrke|Diskussion]]) 22:09, 24. Okt. 2016 (CEST)

Im Folgenden soll eine Beispielkonfiguration für ein Notebook gezeigt werden, welches auf den Einsatz in '''Netzwerken mit unterschiedlichen Sicherheitsanforderungen''' eingerichtet ist.

Dieses System soll in vertrauenswürdigen Netzen (wie beispielsweise dem eigenen LAN oder WLAN) mit der Zone 'work' laufen, welche eine bestimmte Netzwerkfunktionalität wie [[SSH]] oder den File-Daemon von [[Bacula]] auf diesem Notebook erlaubt. In anderen Netzen dagegen soll die Default-Zone 'public' verwendet werden, welche nur eine sehr eingeschränkte Netzwerk-Konnektivität erlaubt.

Dabei soll die Zuordnung anhand der Auswahl des Netzwerkes im [[NetworkManager]] erfolgen, welche bei bekannten Netzen in der Regel '''automatisch''' durchgeführt wird. Beispielsweise beim Wechsel vom (als sicher eingestuften) heimischen LANs in ein unsicheres öffentliches WLAN nach einem Ruhezustand des Notebooks.

Gewünschte Eigenschaften der Zonen:
*work: [[SSH]] und bacula-fd nur vom [[bacula]]-Server (172.16.21.10)
*public: Keinerlei Zugriff (auch kein SSH)

Dieses Beispiel basiert auf der Distribution [[CentOS]] 7. Um eine effektive und eindeutig dokumentierbare Vorgehensweise darzustellen, soll für alle administrativen Zugriffe auf die verwendeten Tools das jeweilige ''Command Line Interface (CLI)'' verwendet werden.

=Konfiguration=
Um dieses Ziel zu erreichen, sind zwei Subsysteme zu konfigurieren:
*[[firewalld]]: Dieser Dienst übernimmt die dynamische Konfiguration und Steuerung der lokalen Firewall. Die von der Distribution vorgegebenen Templates (XML) für die beiden Zonen werden kopiert und angepasst, so dass die Konfiguration persistent zur Verfügung steht.
*[[NetworkManager]]: Der Dienst konfiguriert und steuert die Netzwerkanbindung dynamisch. Bekannten Netzen soll anhand der UUID die Zone 'work' zugewiesen werden. Andere Netze behalten die Default-Zone 'public'. Die Konfiguration erfolgt über das CLI auf der Kommandozeile.

==firewalld==
Im ersten Schritt werden die durch die Distribution vorgegebenen Zonen-Definitionen kopiert. Die folgenden Änderungen erfolgen auf den hier erzeugten Kopien:
<pre>
# cp /usr/lib/firewalld/zones/public.xml /etc/firewalld/zones/
# cp /usr/lib/firewalld/zones/work.xml /etc/firewalld/zones/
</pre>
Die geänderten Definitionen enthalten die Umsetzung für die oben genannten Anforderungen:
<pre>
# cat /etc/firewalld/zones/work.xml
<?xml version="1.0" encoding="utf-8"?>
<zone>
<short>Work</short>
<description>For use in work areas. You mostly trust the other computers on networks to not harm your computer. Only selected incoming connections are accepted.</description>
<service name="ssh"/>
<rule family="ipv4">
<source address="172.16.21.10"/>
<service name="bacula"/>
<accept/>
</rule>
</zone>
</pre>
<pre>
# cat /etc/firewalld/zones/public.xml
<?xml version="1.0" encoding="utf-8"?>
<zone>
<short>Public</short>
<description>For use in public areas. You do not trust the other computers on networks to not harm your computer. Only selected incoming connections are accepted.</description>
</zone>
</pre>

Neustart der Firewall:
<pre>
# systemctl restart firewalld.service
</pre>

==NetworkManager==
Vorhandene Netze anzeigen:
<pre>
# nmcli connection show
NAME UUID TYP GERÄT
Freifunk fec93f72-3488-4008-abfc-ec372d6f8806 802-11-wireless --
WLAN1 82be9628-2709-495f-a389-d209b74fcd05 802-11-wireless --
VPN1 ec0aa457-d3ec-4089-8c8f-1a53a8a33374 vpn --
LAN1 ee9ee0aa-57b9-4c5d-9c76-d2722986c5d8 802-3-ethernet --
enp2s0 8c1c5b53-0c80-44df-8c49-678b6d122d42 802-3-ethernet enp2s0
WLAN2 1e906b64-4909-4dbe-8d81-705ea64767b4 802-11-wireless wlp8s0
VPN2 23c0b2c5-b5a6-4e82-95b2-9b198074391d vpn --
</pre>
Man erkennt, dass das Notebook kabelgebunden über das Interface ''enp2s0'' am Netzwerk ''enp2s0'' und per WLAN über wlp8s0 am eigenen Funk-Netzwerk ''WLAN2'' hängt.

Die Zuordnung der Zone 'work' an beide Netze erfolgt über die UUID der Netze im [[NetworkManager]]:
<pre>
# nmcli con mod "8c1c5b53-0c80-44df-8c49-678b6d122d42" connection.zone work
# nmcli con mod "1e906b64-4909-4dbe-8d81-705ea64767b4" connection.zone work
</pre>
Anschließend werden die Verbindungen noch aktiviert:
<pre>
# nmcli con up uuid 8c1c5b53-0c80-44df-8c49-678b6d122d42
Verbindung wurde erfolgreich aktiviert (aktiver D-Bus-Pfad: /org/freedesktop/NetworkManager/ActiveConnection/38)
# nmcli con up uuid 1e906b64-4909-4dbe-8d81-705ea64767b4
Verbindung wurde erfolgreich aktiviert (aktiver D-Bus-Pfad: /org/freedesktop/NetworkManager/ActiveConnection/39)
</pre>

=Überprüfung=
Abschließend ist die Konfiguration zu überprüfen.

Die Anzeige im Falle der Verbindung in den heimischen Netzen zeigt, dass die beiden Interfaces ''enp2s0'' und ''wlp8s0'' der Zone 'work' zugeordnet sind:
<pre>
# firewall-cmd --get-active-zones
work
interfaces: enp2s0 wlp8s0
</pre>
Anzeige der Konfiguration dieser Zone:
<pre>
# firewall-cmd --zone=work --list-all --permanent
work
interfaces:
sources:
services: ssh
ports:
masquerade: no
forward-ports:
icmp-blocks:
rich rules:
rule family="ipv4" source address="172.16.21.10" service name="bacula" accept
</pre>

Dagegen sollte bei einer Verbindung zu einem anderen Netzwerk die Default-Zone 'public' zugeordnet sein. Im folgenden Beispiel besteht ausschließlich eine Verbindung zum WLAN 'Freifunk':
<pre>
# nmcli connection show
NAME UUID TYP GERÄT
Freifunk fec93f72-3488-4008-abfc-ec372d6f8806 802-11-wireless wlp8s0
enp2s0 8c1c5b53-0c80-44df-8c49-678b6d122d42 802-3-ethernet --
WLAN1 82be9628-2709-495f-a389-d209b74fcd05 802-11-wireless --
VPN1 ec0aa457-d3ec-4089-8c8f-1a53a8a33374 vpn --
LAN1 ee9ee0aa-57b9-4c5d-9c76-d2722986c5d8 802-3-ethernet --
enp2s0 8c1c5b53-0c80-44df-8c49-678b6d122d42 802-3-ethernet --
WLAN2 1e906b64-4909-4dbe-8d81-705ea64767b4 802-11-wireless --
VPN2 23c0b2c5-b5a6-4e82-95b2-9b198074391d vpn --
</pre>
Dementsprechend zeigt die Prüfung, dass für das WLAN-Interface ''wlp8s0'' die Zone 'public' gesetzt wurde und das derzeit nicht verbundene ''enp2s0'' ohne Zuordnung verbleibt:
<pre>
# firewall-cmd --get-active-zones
public
interfaces: wlp8s0
</pre>
Es ist zu erkennen, dass [[SSH]] im Bereich ''services'' nicht zugelassen ist:
<pre>
# firewall-cmd --zone=public --list-all
public (default, active)
interfaces: wlp8s0
sources:
services:
ports:
masquerade: no
forward-ports:
icmp-blocks:
rich rules:
</pre>
Dabei erfolgt die Zuordnung der Zonen automatisch in Reaktion auf die Auswahl des Netzwerkes im [[NetworkManger]]. Eine manuelle Auswahl der Zone ist hierfür nicht erforderlich.

[[Category:Security]] [[Category:Netzwerk]] [[Category:HowTo]]

Konfigurationsbeispiel eines Notebooks für den Einsatz in unterschiedlichen Netzen mit 'firewalld' und 'NetworkManager'

2016-10-25T14:40:46Z

Gehrke: Bereinigung

{{UnderConstruction}}--[[Benutzer:Gehrke|Gehrke]] ([[Benutzer Diskussion:Gehrke|Diskussion]]) 22:09, 24. Okt. 2016 (CEST)

Im Folgenden soll eine Beispielkonfiguration für ein Notebook gezeigt werden, welches auf den Einsatz in '''Netzwerken mit unterschiedlichen Sicherheitsanforderungen''' eingerichtet ist.

Dieses System soll in vertrauenswürdigen Netzen (wie beispielsweise dem eigenen LAN oder WLAN) mit der Zone 'work' laufen, welche eine bestimmte Netzwerkfunktionalität wie [[SSH]] oder den File-Daemon von [[Bacula]] auf diesem Notebook erlaubt. In anderen Netzen dagegen soll die Default-Zone 'public' verwendet werden, welche nur eine sehr eingeschränkte Netzwerk-Konnektivität erlaubt.

Dabei soll die Zuordnung anhand der Auswahl des Netzwerkes im [[NetworkManager]] erfolgen, welche bei bekannten Netzen in der Regel '''automatisch''' durchgeführt wird. Beispielsweise beim Wechsel vom (als sicher eingestuften) heimischen LANs in ein unsicheres öffentliches WLAN nach einem Ruhezustand des Notebooks.

Gewünschte Eigenschaften der Zonen:
*work: [[SSH]] und bacula-fd nur vom [[bacula]]-Server (172.16.21.10)
*public: Keinerlei Zugriff (auch kein SSH)

Dieses Beispiel basiert auf der Distribution [[CentOS]] 7. Um eine effektive und eindeutig dokumentierbare Vorgehensweise herzustellen, soll für alle administrativen Zugriffe auf die verwendeten Tools das jeweilige ''Command Line Interface (CLI)'' verwendet werden.

=Konfiguration=
Um dieses Ziel zu erreichen, sind zwei Subsysteme zu konfigurieren:
*[[firewalld]]: Dieser Dienst übernimmt die dynamische Konfiguration und Steuerung der lokalen Firewall. Die von der Distribution vorgegebenen Templates (XML) für die beiden Zonen werden kopiert und angepasst, so dass die Konfiguration persistent zur Verfügung steht.
*[[NetworkManager]]: Der Dienst konfiguriert und steuert die Netzwerkanbindung dynamisch. Bekannten Netzen soll anhand der UUID die Zone 'work' zugewiesen werden. Andere Netze behalten die Default-Zone 'public'. Die Konfiguration erfolgt über das CLI auf der Kommandozeile.

==firewalld==
Im ersten Schritt werden die durch die Distribution vorgegebenen Zonen-Definitionen kopiert. Die folgenden Änderungen erfolgen auf den hier erzeugten Kopien:
<pre>
# cp /usr/lib/firewalld/zones/public.xml /etc/firewalld/zones/
# cp /usr/lib/firewalld/zones/work.xml /etc/firewalld/zones/
</pre>
Die geänderten Definitionen enthalten die Umsetzung für die oben genannten Anforderungen:
<pre>
# cat /etc/firewalld/zones/work.xml
<?xml version="1.0" encoding="utf-8"?>
<zone>
<short>Work</short>
<description>For use in work areas. You mostly trust the other computers on networks to not harm your computer. Only selected incoming connections are accepted.</description>
<service name="ssh"/>
<rule family="ipv4">
<source address="172.16.21.10"/>
<service name="bacula"/>
<accept/>
</rule>
</zone>
</pre>
<pre>
# cat /etc/firewalld/zones/public.xml
<?xml version="1.0" encoding="utf-8"?>
<zone>
<short>Public</short>
<description>For use in public areas. You do not trust the other computers on networks to not harm your computer. Only selected incoming connections are accepted.</description>
</zone>
</pre>

Neustart der Firewall:
<pre>
# systemctl restart firewalld.service
</pre>

==NetworkManager==
Vorhandene Netze anzeigen:
<pre>
# nmcli connection show
NAME UUID TYP GERÄT
Freifunk fec93f72-3488-4008-abfc-ec372d6f8806 802-11-wireless --
WLAN1 82be9628-2709-495f-a389-d209b74fcd05 802-11-wireless --
VPN1 ec0aa457-d3ec-4089-8c8f-1a53a8a33374 vpn --
LAN1 ee9ee0aa-57b9-4c5d-9c76-d2722986c5d8 802-3-ethernet --
enp2s0 8c1c5b53-0c80-44df-8c49-678b6d122d42 802-3-ethernet enp2s0
WLAN2 1e906b64-4909-4dbe-8d81-705ea64767b4 802-11-wireless wlp8s0
VPN2 23c0b2c5-b5a6-4e82-95b2-9b198074391d vpn --
</pre>
Man erkennt, dass das Notebook kabelgebunden über das Interface ''enp2s0'' am Netzwerk ''enp2s0'' und per WLAN über wlp8s0 am eigenen Funk-Netzwerk ''WLAN2'' hängt.

Die Zuordnung der Zone 'work' an beide Netze erfolgt über die UUID der Netze im [[NetworkManager]]:
<pre>
# nmcli con mod "8c1c5b53-0c80-44df-8c49-678b6d122d42" connection.zone work
# nmcli con mod "1e906b64-4909-4dbe-8d81-705ea64767b4" connection.zone work
</pre>
Anschließend werden die Verbindungen noch aktiviert:
<pre>
# nmcli con up uuid 8c1c5b53-0c80-44df-8c49-678b6d122d42
Verbindung wurde erfolgreich aktiviert (aktiver D-Bus-Pfad: /org/freedesktop/NetworkManager/ActiveConnection/38)
# nmcli con up uuid 1e906b64-4909-4dbe-8d81-705ea64767b4
Verbindung wurde erfolgreich aktiviert (aktiver D-Bus-Pfad: /org/freedesktop/NetworkManager/ActiveConnection/39)
</pre>

=Überprüfung=
Abschließend ist die Konfiguration zu überprüfen.

Die Anzeige im Falle der Verbindung in den heimischen Netzen zeigt, dass die beiden Interfaces ''enp2s0'' und ''wlp8s0'' der Zone 'work' zugeordnet sind:
<pre>
# firewall-cmd --get-active-zones
work
interfaces: enp2s0 wlp8s0
</pre>
Anzeige der Konfiguration dieser Zone:
<pre>
# firewall-cmd --zone=work --list-all --permanent
work
interfaces:
sources:
services: ssh
ports:
masquerade: no
forward-ports:
icmp-blocks:
rich rules:
rule family="ipv4" source address="172.16.21.10" service name="bacula" accept
</pre>

Dagegen sollte bei einer Verbindung zu einem anderen Netzwerk die Default-Zone 'public' zugeordnet sein. Im folgenden Beispiel besteht ausschließlich eine Verbindung zum WLAN 'Freifunk':
<pre>
# nmcli connection show
NAME UUID TYP GERÄT
Freifunk fec93f72-3488-4008-abfc-ec372d6f8806 802-11-wireless wlp8s0
enp2s0 8c1c5b53-0c80-44df-8c49-678b6d122d42 802-3-ethernet --
WLAN1 82be9628-2709-495f-a389-d209b74fcd05 802-11-wireless --
VPN1 ec0aa457-d3ec-4089-8c8f-1a53a8a33374 vpn --
LAN1 ee9ee0aa-57b9-4c5d-9c76-d2722986c5d8 802-3-ethernet --
enp2s0 8c1c5b53-0c80-44df-8c49-678b6d122d42 802-3-ethernet --
WLAN2 1e906b64-4909-4dbe-8d81-705ea64767b4 802-11-wireless --
VPN2 23c0b2c5-b5a6-4e82-95b2-9b198074391d vpn --
</pre>
Dementsprechend zeigt die Prüfung, dass für das WLAN-Interface ''wlp8s0'' die Zone 'public' gesetzt wurde und das derzeit nicht verbundene ''enp2s0'' ohne Zuordnung verbleibt:
<pre>
# firewall-cmd --get-active-zones
public
interfaces: wlp8s0
</pre>
Es ist zu erkennen, dass [[SSH]] im Bereich ''services'' nicht zugelassen ist:
<pre>
# firewall-cmd --zone=public --list-all
public (default, active)
interfaces: wlp8s0
sources:
services:
ports:
masquerade: no
forward-ports:
icmp-blocks:
rich rules:
</pre>
Dabei erfolgt die Zuordnung der Zonen automatisch in Reaktion auf die Auswahl des Netzwerkes im [[NetworkManger]]. Eine manuelle Auswahl der Zone ist hierfür nicht erforderlich.

[[Category:Security]] [[Category:Netzwerk]] [[Category:HowTo]]

Konfigurationsbeispiel eines Notebooks für den Einsatz in unterschiedlichen Netzen mit 'firewalld' und 'NetworkManager'

2016-10-25T05:51:28Z

Gehrke: Command Line Interface (CLI)

{{UnderConstruction}}--[[Benutzer:Gehrke|Gehrke]] ([[Benutzer Diskussion:Gehrke|Diskussion]]) 22:09, 24. Okt. 2016 (CEST)

Im Folgenden soll eine Beispielkonfiguration für ein Notebook gezeigt werden, welches auf den Einsatz in '''Netzwerken mit unterschiedlichen Sicherheitsanforderungen''' eingerichtet ist. Dieses System soll im eigenen Netz (LAN und WLAN) mit der Zone 'work' laufen, welche eine bestimmte Netzwerkfunktionalität wie [[SSH]] oder den File-Daemon von [[Bacula]] auf diesem Notebook erlaubt. In anderen Netzen dagegen soll die Default-Zone 'public' verwendet werden, welche nur eine sehr eingeschränkte Netzwerk-Konnektivität erlaubt.

Dabei soll die Zuordnung anhand der Auswahl des Netzwerkes im [[NetworkManager]] erfolgen, welche bei bekannten Netzen in der Regel '''automatisch''' durchgeführt wird. Beispielsweise beim Wechsel vom (als sicher eingestuften) heimischen LANs in ein unsicheres öffentliches WLAN nach einem Ruhezustand des Notebooks.

Gewünschte Eigenschaften der Zonen:
*work: [[SSH]] und bacula-fd nur vom [[bacula]]-Server (172.16.21.10)
*public: Keinerlei Zugriff (auch kein SSH)

Dieses Beispiel basiert auf der Distribution [[CentOS]] 7. Um eine effektive und eindeutig dokumentierbare Vorgehensweise herzustellen, soll für alle administrativen Zugriffe auf die verwendeten Tools das jeweilige ''Command Line Interface (CLI)'' verwendet werden.

=Konfiguration=
Um dieses Ziel zu erreichen, sind zwei Subsysteme zu konfigurieren:
*[[firewalld]]: Dieser Dienst übernimmt die dynamische Konfiguration und Steuerung der lokalen Firewall. Die von der Distribution vorgegebenen Templates (XML) für die beiden Zonen werden kopiert und angepasst, so dass die Konfiguration persistent zur Verfügung steht.
*[[NetworkManager]]: Der Dienst konfiguriert und steuert die Netzwerkanbindung dynamisch. Bekannten Netzen soll anhand der UUID die Zone 'work' zugewiesen werden. Andere Netze behalten die Default-Zone 'public'. Die Konfiguration erfolgt über das CLI auf der Kommandozeile.

==firewalld==
Im ersten Schritt werden die durch die Distribution vorgegebenen Zonen-Definitionen kopiert. Die folgenden Änderungen erfolgen auf den hier erzeugten Kopien:
<pre>
# cp /usr/lib/firewalld/zones/public.xml /etc/firewalld/zones/
# cp /usr/lib/firewalld/zones/work.xml /etc/firewalld/zones/
</pre>
Die geänderten Definitionen enthalten die Umsetzung für die oben genannten Anforderungen:
<pre>
# cat /etc/firewalld/zones/work.xml
<?xml version="1.0" encoding="utf-8"?>
<zone>
<short>Work</short>
<description>For use in work areas. You mostly trust the other computers on networks to not harm your computer. Only selected incoming connections are accepted.</description>
<service name="ssh"/>
<rule family="ipv4">
<source address="172.16.21.10"/>
<service name="bacula"/>
<accept/>
</rule>
</zone>
</pre>
<pre>
# cat /etc/firewalld/zones/public.xml
<?xml version="1.0" encoding="utf-8"?>
<zone>
<short>Public</short>
<description>For use in public areas. You do not trust the other computers on networks to not harm your computer. Only selected incoming connections are accepted.</description>
</zone>
</pre>

Neustart der Firewall:
<pre>
# systemctl restart firewalld.service
</pre>

==NetworkManager==
Vorhandene Netze anzeigen:
<pre>
# nmcli connection show
NAME UUID TYP GERÄT
Freifunk fec93f72-3488-4008-abfc-ec372d6f8806 802-11-wireless --
WLAN1 82be9628-2709-495f-a389-d209b74fcd05 802-11-wireless --
VPN1 ec0aa457-d3ec-4089-8c8f-1a53a8a33374 vpn --
LAN1 ee9ee0aa-57b9-4c5d-9c76-d2722986c5d8 802-3-ethernet --
enp2s0 8c1c5b53-0c80-44df-8c49-678b6d122d42 802-3-ethernet enp2s0
WLAN2 1e906b64-4909-4dbe-8d81-705ea64767b4 802-11-wireless wlp8s0
VPN2 23c0b2c5-b5a6-4e82-95b2-9b198074391d vpn --
</pre>
Man erkennt, dass das Notebook kabelgebunden über das Interface ''enp2s0'' am Netzwerk ''enp2s0'' und per WLAN über wlp8s0 am eigenen Funk-Netzwerk ''WLAN2'' hängt.

Die Zuordnung der Zone 'work' an beide Netze erfolgt über die UUID der Netze im [[NetworkManager]]. Hierzu wird das CLI anstatt der GUI verwendet:
<pre>
# nmcli con mod "8c1c5b53-0c80-44df-8c49-678b6d122d42" connection.zone work
# nmcli con mod "1e906b64-4909-4dbe-8d81-705ea64767b4" connection.zone work
</pre>
Anschließend werden die Verbindungen noch aktiviert:
<pre>
# nmcli con up uuid 8c1c5b53-0c80-44df-8c49-678b6d122d42
Verbindung wurde erfolgreich aktiviert (aktiver D-Bus-Pfad: /org/freedesktop/NetworkManager/ActiveConnection/38)
# nmcli con up uuid 1e906b64-4909-4dbe-8d81-705ea64767b4
Verbindung wurde erfolgreich aktiviert (aktiver D-Bus-Pfad: /org/freedesktop/NetworkManager/ActiveConnection/39)
</pre>

=Überprüfung=
Abschließend die Konfiguration zu überprüfen.

Die Anzeige im Falle der Verbindung in den heimischen Netzen zeigt, dass die beiden Interfaces ''enp2s0'' und ''wlp8s0'' der Zone 'work' zugeordnet sind:
<pre>
# firewall-cmd --get-active-zones
work
interfaces: enp2s0 wlp8s0
</pre>
Anzeige der Konfiguration dieser Zone:
<pre>
# firewall-cmd --zone=work --list-all --permanent
work
interfaces:
sources:
services: ssh
ports:
masquerade: no
forward-ports:
icmp-blocks:
rich rules:
rule family="ipv4" source address="172.16.21.10" service name="bacula" accept
</pre>

Dagegen sollte bei einer Verbindung zu einem anderen Netzwerk die Default-Zone 'public' zugeordnet sein. Im folgenden Beispiel besteht ausschließlich eine Verbindung zum WLAN 'Freifunk':
<pre>
# nmcli connection show
NAME UUID TYP GERÄT
Freifunk fec93f72-3488-4008-abfc-ec372d6f8806 802-11-wireless wlp8s0
enp2s0 8c1c5b53-0c80-44df-8c49-678b6d122d42 802-3-ethernet --
WLAN1 82be9628-2709-495f-a389-d209b74fcd05 802-11-wireless --
VPN1 ec0aa457-d3ec-4089-8c8f-1a53a8a33374 vpn --
LAN1 ee9ee0aa-57b9-4c5d-9c76-d2722986c5d8 802-3-ethernet --
enp2s0 8c1c5b53-0c80-44df-8c49-678b6d122d42 802-3-ethernet --
WLAN2 1e906b64-4909-4dbe-8d81-705ea64767b4 802-11-wireless --
VPN2 23c0b2c5-b5a6-4e82-95b2-9b198074391d vpn --
</pre>
Dementsprechend zeigt die Prüfung, dass für das WLAN-Interface ''wlp8s0'' die Zone 'public' gesetzt wurde und das derzeit nicht verbundene ''enp2s0'' ohne Zuordnung verbleibt:
<pre>
# firewall-cmd --get-active-zones
public
interfaces: wlp8s0
</pre>
Es ist zu erkennen, dass [[SSH]] im Bereich ''services'' nicht zugelassen ist:
<pre>
# firewall-cmd --zone=public --list-all
public (default, active)
interfaces: wlp8s0
sources:
services:
ports:
masquerade: no
forward-ports:
icmp-blocks:
rich rules:
</pre>
Dabei erfolgt die Zuordnung der Zonen automatisch in Reaktion auf die Auswahl des Netzwerkes im [[NetworkManger]]. Eine manuelle Auswahl der Zone ist hierfür nicht erforderlich.

[[Category:Security]] [[Category:Netzwerk]] [[Category:HowTo]]

Konfigurationsbeispiel eines Notebooks für den Einsatz in unterschiedlichen Netzen mit 'firewalld' und 'NetworkManager'

2016-10-25T05:43:57Z

Gehrke: wording

{{UnderConstruction}}--[[Benutzer:Gehrke|Gehrke]] ([[Benutzer Diskussion:Gehrke|Diskussion]]) 22:09, 24. Okt. 2016 (CEST)

Im Folgenden soll eine Beispielkonfiguration für ein Notebook gezeigt werden, welches auf den Einsatz in '''Netzwerken mit unterschiedlichen Sicherheitsanforderungen''' eingerichtet ist. Dieses System soll im eigenen Netz (LAN und WLAN) mit der Zone 'work' laufen, welche eine bestimmte Netzwerkfunktionalität wie [[SSH]] oder den File-Daemon von [[Bacula]] auf diesem Notebook erlaubt. In anderen Netzen dagegen soll die Default-Zone 'public' verwendet werden, welche nur eine sehr eingeschränkte Netzwerk-Konnektivität erlaubt.

Dabei soll die Zuordnung anhand der Auswahl des Netzwerkes im [[NetworkManager]] erfolgen, welche bei bekannten Netzen in der Regel '''automatisch''' durchgeführt wird. Beispielsweise beim Wechsel vom (als sicher eingestuften) heimischen LANs in ein unsicheres öffentliches WLAN nach einem Ruhezustand des Notebooks.

Gewünschte Eigenschaften der Zonen:
*work: [[SSH]] und bacula-fd nur vom [[bacula]]-Server (172.16.21.10)
*public: Keinerlei Zugriff (auch kein SSH)

Dieses Beispiel basiert auf der Distribution [[CentOS]] 7.

=Konfiguration=
Um dieses Ziel zu erreichen, sind zwei Subsysteme zu konfigurieren:
*[[firewalld]]: Dieser Dienst übernimmt die dynamische Konfiguration und Steuerung der lokalen Firewall. Die von der Distribution vorgegebenen Templates (XML) für die beiden Zonen werden kopiert und angepasst, so dass die Konfiguration persistent zur Verfügung steht.
*[[NetworkManager]]: Der Dienst konfiguriert und steuert die Netzwerkanbindung dynamisch. Bekannten Netzen soll anhand der UUID die Zone 'work' zugewiesen werden. Andere Netze behalten die Default-Zone 'public'. Die Konfiguration erfolgt über das CLI auf der Kommandozeile.

==firewalld==
Im ersten Schritt werden die durch die Distribution vorgegebenen Zonen-Definitionen kopiert. Die folgenden Änderungen erfolgen auf den hier erzeugten Kopien:
<pre>
# cp /usr/lib/firewalld/zones/public.xml /etc/firewalld/zones/
# cp /usr/lib/firewalld/zones/work.xml /etc/firewalld/zones/
</pre>
Die geänderten Definitionen enthalten die Umsetzung für die oben genannten Anforderungen:
<pre>
# cat /etc/firewalld/zones/work.xml
<?xml version="1.0" encoding="utf-8"?>
<zone>
<short>Work</short>
<description>For use in work areas. You mostly trust the other computers on networks to not harm your computer. Only selected incoming connections are accepted.</description>
<service name="ssh"/>
<rule family="ipv4">
<source address="172.16.21.10"/>
<service name="bacula"/>
<accept/>
</rule>
</zone>
</pre>
<pre>
# cat /etc/firewalld/zones/public.xml
<?xml version="1.0" encoding="utf-8"?>
<zone>
<short>Public</short>
<description>For use in public areas. You do not trust the other computers on networks to not harm your computer. Only selected incoming connections are accepted.</description>
</zone>
</pre>

Neustart der Firewall:
<pre>
# systemctl restart firewalld.service
</pre>

==NetworkManager==
Vorhandene Netze anzeigen:
<pre>
# nmcli connection show
NAME UUID TYP GERÄT
Freifunk fec93f72-3488-4008-abfc-ec372d6f8806 802-11-wireless --
WLAN1 82be9628-2709-495f-a389-d209b74fcd05 802-11-wireless --
VPN1 ec0aa457-d3ec-4089-8c8f-1a53a8a33374 vpn --
LAN1 ee9ee0aa-57b9-4c5d-9c76-d2722986c5d8 802-3-ethernet --
enp2s0 8c1c5b53-0c80-44df-8c49-678b6d122d42 802-3-ethernet enp2s0
WLAN2 1e906b64-4909-4dbe-8d81-705ea64767b4 802-11-wireless wlp8s0
VPN2 23c0b2c5-b5a6-4e82-95b2-9b198074391d vpn --
</pre>
Man erkennt, dass das Notebook kabelgebunden über das Interface ''enp2s0'' am Netzwerk ''enp2s0'' und per WLAN über wlp8s0 am eigenen Funk-Netzwerk ''WLAN2'' hängt.

Die Zuordnung der Zone 'work' an beide Netze erfolgt über die UUID der Netze im [[NetworkManager]]. Hierzu wird das CLI anstatt der GUI verwendet:
<pre>
# nmcli con mod "8c1c5b53-0c80-44df-8c49-678b6d122d42" connection.zone work
# nmcli con mod "1e906b64-4909-4dbe-8d81-705ea64767b4" connection.zone work
</pre>
Anschließend werden die Verbindungen noch aktiviert:
<pre>
# nmcli con up uuid 8c1c5b53-0c80-44df-8c49-678b6d122d42
Verbindung wurde erfolgreich aktiviert (aktiver D-Bus-Pfad: /org/freedesktop/NetworkManager/ActiveConnection/38)
# nmcli con up uuid 1e906b64-4909-4dbe-8d81-705ea64767b4
Verbindung wurde erfolgreich aktiviert (aktiver D-Bus-Pfad: /org/freedesktop/NetworkManager/ActiveConnection/39)
</pre>

=Überprüfung=
Abschließend die Konfiguration zu überprüfen.

Die Anzeige im Falle der Verbindung in den heimischen Netzen zeigt, dass die beiden Interfaces ''enp2s0'' und ''wlp8s0'' der Zone 'work' zugeordnet sind:
<pre>
# firewall-cmd --get-active-zones
work
interfaces: enp2s0 wlp8s0
</pre>
Anzeige der Konfiguration dieser Zone:
<pre>
# firewall-cmd --zone=work --list-all --permanent
work
interfaces:
sources:
services: ssh
ports:
masquerade: no
forward-ports:
icmp-blocks:
rich rules:
rule family="ipv4" source address="172.16.21.10" service name="bacula" accept
</pre>

Dagegen sollte bei einer Verbindung zu einem anderen Netzwerk die Default-Zone 'public' zugeordnet sein. Im folgenden Beispiel besteht ausschließlich eine Verbindung zum WLAN 'Freifunk':
<pre>
# nmcli connection show
NAME UUID TYP GERÄT
Freifunk fec93f72-3488-4008-abfc-ec372d6f8806 802-11-wireless wlp8s0
enp2s0 8c1c5b53-0c80-44df-8c49-678b6d122d42 802-3-ethernet --
WLAN1 82be9628-2709-495f-a389-d209b74fcd05 802-11-wireless --
VPN1 ec0aa457-d3ec-4089-8c8f-1a53a8a33374 vpn --
LAN1 ee9ee0aa-57b9-4c5d-9c76-d2722986c5d8 802-3-ethernet --
enp2s0 8c1c5b53-0c80-44df-8c49-678b6d122d42 802-3-ethernet --
WLAN2 1e906b64-4909-4dbe-8d81-705ea64767b4 802-11-wireless --
VPN2 23c0b2c5-b5a6-4e82-95b2-9b198074391d vpn --
</pre>
Dementsprechend zeigt die Prüfung, dass für das WLAN-Interface ''wlp8s0'' die Zone 'public' gesetzt wurde und das derzeit nicht verbundene ''enp2s0'' ohne Zuordnung verbleibt:
<pre>
# firewall-cmd --get-active-zones
public
interfaces: wlp8s0
</pre>
Es ist zu erkennen, dass [[SSH]] im Bereich ''services'' nicht zugelassen ist:
<pre>
# firewall-cmd --zone=public --list-all
public (default, active)
interfaces: wlp8s0
sources:
services:
ports:
masquerade: no
forward-ports:
icmp-blocks:
rich rules:
</pre>
Dabei erfolgt die Zuordnung der Zonen automatisch in Reaktion auf die Auswahl des Netzwerkes im [[NetworkManger]]. Eine manuelle Auswahl der Zone ist hierfür nicht erforderlich.

[[Category:Security]] [[Category:Netzwerk]] [[Category:HowTo]]

Konfigurationsbeispiel eines Notebooks für den Einsatz in unterschiedlichen Netzen mit 'firewalld' und 'NetworkManager'

2016-10-24T21:32:49Z

Gehrke: Category:HowTo

{{UnderConstruction}}--[[Benutzer:Gehrke|Gehrke]] ([[Benutzer Diskussion:Gehrke|Diskussion]]) 22:09, 24. Okt. 2016 (CEST)

Im Folgenden soll eine Beispielkonfiguration für ein Notebook gezeigt werden, welches auf den Einsatz in '''Netzwerken mit unterschiedlichen Sicherheitsanforderungen''' eingerichtet ist. Dieses System soll im eigenen Netz (LAN und WLAN) mit der Zone 'work' laufen, welche eine bestimmte Netzwerkfunktionalität wie [[SSH]] oder den File-Daemon von [[Bacula]] auf diesem Notebook erlaubt. In anderen Netzen dagegen soll die Default-Zone 'public' verwendet werden, welche nur eine sehr eingeschränkte Netzwerk-Konnektivität erlaubt.

Dabei soll die Zuordnung anhand der Auswahl des Netzwerkes im [[NetworkManager]] erfolgen, welche bei bekannten Netzen in der Regel '''automatisch''' durchgeführt wird. Beispielsweise beim Wechsel vom (als sicher eingestuften) Heim-WLAN in ein unsicheres öffentliches Netz nach einem Ruhezustand des Notebooks.

Gewünschte Eigenschaften der Zonen:
*work: [[SSH]] und bacula-fd nur vom [[bacula]]-Server (172.16.21.10)
*public: Keinerlei Zugriff (auch kein SSH)

Dieses Beispiel basiert auf der Distribution [[CentOS]] 7.

=Konfiguration=
Um dieses Ziel zu erreichen, sind zwei Subsysteme zu konfigurieren:
*[[firewalld]]: Dieser Dienst übernimmt die dynamische Konfiguration und Steuerung der lokalen Firewall. Die von der Distribution vorgegebenen Templates (XML) für die beiden Zonen werden kopiert und angepasst, so dass die Konfiguration persistent zur Verfügung steht.
*[[NetworkManager]]: Der Dienst konfiguriert und steuert die Netzwerkanbindung dynamisch. Bekannten Netzen soll anhand der UUID die Zone 'work' zugewiesen werden. Andere Netze behalten die Default-Zone 'public'. Die Konfiguration erfolgt über das CLI auf der Kommandozeile.

==firewalld==
Im ersten Schritt werden die durch die Distribution vorgegebenen Zonen-Definitionen kopiert. Die folgenden Änderungen erfolgen auf den hier erzeugten Kopien:
<pre>
# cp /usr/lib/firewalld/zones/public.xml /etc/firewalld/zones/
# cp /usr/lib/firewalld/zones/work.xml /etc/firewalld/zones/
</pre>
Die geänderten Definitionen enthalten die Umsetzung für die oben genannten Anforderungen:
<pre>
# cat /etc/firewalld/zones/work.xml
<?xml version="1.0" encoding="utf-8"?>
<zone>
<short>Work</short>
<description>For use in work areas. You mostly trust the other computers on networks to not harm your computer. Only selected incoming connections are accepted.</description>
<service name="ssh"/>
<rule family="ipv4">
<source address="172.16.21.10"/>
<service name="bacula"/>
<accept/>
</rule>
</zone>
</pre>
<pre>
# cat /etc/firewalld/zones/public.xml
<?xml version="1.0" encoding="utf-8"?>
<zone>
<short>Public</short>
<description>For use in public areas. You do not trust the other computers on networks to not harm your computer. Only selected incoming connections are accepted.</description>
</zone>
</pre>

Neustart der Firewall:
<pre>
# systemctl restart firewalld.service
</pre>

==NetworkManager==
Vorhandene Netze anzeigen:
<pre>
# nmcli connection show
NAME UUID TYP GERÄT
Freifunk fec93f72-3488-4008-abfc-ec372d6f8806 802-11-wireless --
WLAN1 82be9628-2709-495f-a389-d209b74fcd05 802-11-wireless --
VPN1 ec0aa457-d3ec-4089-8c8f-1a53a8a33374 vpn --
LAN1 ee9ee0aa-57b9-4c5d-9c76-d2722986c5d8 802-3-ethernet --
enp2s0 8c1c5b53-0c80-44df-8c49-678b6d122d42 802-3-ethernet enp2s0
WLAN2 1e906b64-4909-4dbe-8d81-705ea64767b4 802-11-wireless wlp8s0
VPN2 23c0b2c5-b5a6-4e82-95b2-9b198074391d vpn --
</pre>
Man erkennt, dass das Notebook kabelgebunden über das Interface ''enp2s0'' am Netzwerk ''enp2s0'' und per WLAN über wlp8s0 am eigenen Funk-Netzwerk ''WLAN2'' hängt.

Die Zuordnung der Zone 'work' an beide Netze erfolgt über die UUID der Netze im [[NetworkManager]]. Hierzu wird das CLI anstatt der GUI verwendet:
<pre>
# nmcli con mod "8c1c5b53-0c80-44df-8c49-678b6d122d42" connection.zone work
# nmcli con mod "1e906b64-4909-4dbe-8d81-705ea64767b4" connection.zone work
</pre>
Anschließend werden die Verbindungen noch aktiviert:
<pre>
# nmcli con up uuid 8c1c5b53-0c80-44df-8c49-678b6d122d42
Verbindung wurde erfolgreich aktiviert (aktiver D-Bus-Pfad: /org/freedesktop/NetworkManager/ActiveConnection/38)
# nmcli con up uuid 1e906b64-4909-4dbe-8d81-705ea64767b4
Verbindung wurde erfolgreich aktiviert (aktiver D-Bus-Pfad: /org/freedesktop/NetworkManager/ActiveConnection/39)
</pre>

=Überprüfung=
Abschließend die Konfiguration zu überprüfen.

Die Anzeige im Falle der Verbindung in den heimischen Netzen zeigt, dass die beiden Interfaces ''enp2s0'' und ''wlp8s0'' der Zone 'work' zugeordnet sind:
<pre>
# firewall-cmd --get-active-zones
work
interfaces: enp2s0 wlp8s0
</pre>
Anzeige der Konfiguration dieser Zone:
<pre>
# firewall-cmd --zone=work --list-all --permanent
work
interfaces:
sources:
services: ssh
ports:
masquerade: no
forward-ports:
icmp-blocks:
rich rules:
rule family="ipv4" source address="172.16.21.10" service name="bacula" accept
</pre>

Dagegen sollte bei einer Verbindung zu einem anderen Netzwerk die Default-Zone 'public' zugeordnet sein. Im folgenden Beispiel besteht ausschließlich eine Verbindung zum WLAN 'Freifunk':
<pre>
# nmcli connection show
NAME UUID TYP GERÄT
Freifunk fec93f72-3488-4008-abfc-ec372d6f8806 802-11-wireless wlp8s0
enp2s0 8c1c5b53-0c80-44df-8c49-678b6d122d42 802-3-ethernet --
WLAN1 82be9628-2709-495f-a389-d209b74fcd05 802-11-wireless --
VPN1 ec0aa457-d3ec-4089-8c8f-1a53a8a33374 vpn --
LAN1 ee9ee0aa-57b9-4c5d-9c76-d2722986c5d8 802-3-ethernet --
enp2s0 8c1c5b53-0c80-44df-8c49-678b6d122d42 802-3-ethernet --
WLAN2 1e906b64-4909-4dbe-8d81-705ea64767b4 802-11-wireless --
VPN2 23c0b2c5-b5a6-4e82-95b2-9b198074391d vpn --
</pre>
Dementsprechend zeigt die Prüfung, dass für das WLAN-Interface ''wlp8s0'' die Zone 'public' gesetzt wurde und das derzeit nicht verbundene ''enp2s0'' ohne Zuordnung verbleibt:
<pre>
# firewall-cmd --get-active-zones
public
interfaces: wlp8s0
</pre>
Es ist zu erkennen, dass [[SSH]] im Bereich ''services'' nicht zugelassen ist:
<pre>
# firewall-cmd --zone=public --list-all
public (default, active)
interfaces: wlp8s0
sources:
services:
ports:
masquerade: no
forward-ports:
icmp-blocks:
rich rules:
</pre>
Dabei erfolgt die Zuordnung der Zonen automatisch in Reaktion auf die Auswahl des Netzwerkes im [[NetworkManger]]. Eine manuelle Auswahl der Zone ist hierfür nicht erforderlich.

[[Category:Security]] [[Category:Netzwerk]] [[Category:HowTo]]

Konfigurationsbeispiel eines Notebooks für den Einsatz in unterschiedlichen Netzen mit 'firewalld' und 'NetworkManager'

2016-10-24T21:26:52Z

Gehrke: Formatierung

{{UnderConstruction}}--[[Benutzer:Gehrke|Gehrke]] ([[Benutzer Diskussion:Gehrke|Diskussion]]) 22:09, 24. Okt. 2016 (CEST)

Im Folgenden soll eine Beispielkonfiguration für ein Notebook gezeigt werden, welches auf den Einsatz in '''Netzwerken mit unterschiedlichen Sicherheitsanforderungen''' eingerichtet ist. Dieses System soll im eigenen Netz (LAN und WLAN) mit der Zone 'work' laufen, welche eine bestimmte Netzwerkfunktionalität wie [[SSH]] oder den File-Daemon von [[Bacula]] auf diesem Notebook erlaubt. In anderen Netzen dagegen soll die Default-Zone 'public' verwendet werden, welche nur eine sehr eingeschränkte Netzwerk-Konnektivität erlaubt.

Dabei soll die Zuordnung anhand der Auswahl des Netzwerkes im [[NetworkManager]] erfolgen, welche bei bekannten Netzen in der Regel '''automatisch''' durchgeführt wird. Beispielsweise beim Wechsel vom (als sicher eingestuften) Heim-WLAN in ein unsicheres öffentliches Netz nach einem Ruhezustand des Notebooks.

Gewünschte Eigenschaften der Zonen:
*work: [[SSH]] und bacula-fd nur vom [[bacula]]-Server (172.16.21.10)
*public: Keinerlei Zugriff (auch kein SSH)

Dieses Beispiel basiert auf der Distribution [[CentOS]] 7.

=Konfiguration=
Um dieses Ziel zu erreichen, sind zwei Subsysteme zu konfigurieren:
*[[firewalld]]: Dieser Dienst übernimmt die dynamische Konfiguration und Steuerung der lokalen Firewall. Die von der Distribution vorgegebenen Templates (XML) für die beiden Zonen werden kopiert und angepasst, so dass die Konfiguration persistent zur Verfügung steht.
*[[NetworkManager]]: Der Dienst konfiguriert und steuert die Netzwerkanbindung dynamisch. Bekannten Netzen soll anhand der UUID die Zone 'work' zugewiesen werden. Andere Netze behalten die Default-Zone 'public'. Die Konfiguration erfolgt über das CLI auf der Kommandozeile.

==firewalld==
Im ersten Schritt werden die durch die Distribution vorgegebenen Zonen-Definitionen kopiert. Die folgenden Änderungen erfolgen auf den hier erzeugten Kopien:
<pre>
# cp /usr/lib/firewalld/zones/public.xml /etc/firewalld/zones/
# cp /usr/lib/firewalld/zones/work.xml /etc/firewalld/zones/
</pre>
Die geänderten Definitionen enthalten die Umsetzung für die oben genannten Anforderungen:
<pre>
# cat /etc/firewalld/zones/work.xml
<?xml version="1.0" encoding="utf-8"?>
<zone>
<short>Work</short>
<description>For use in work areas. You mostly trust the other computers on networks to not harm your computer. Only selected incoming connections are accepted.</description>
<service name="ssh"/>
<rule family="ipv4">
<source address="172.16.21.10"/>
<service name="bacula"/>
<accept/>
</rule>
</zone>
</pre>
<pre>
# cat /etc/firewalld/zones/public.xml
<?xml version="1.0" encoding="utf-8"?>
<zone>
<short>Public</short>
<description>For use in public areas. You do not trust the other computers on networks to not harm your computer. Only selected incoming connections are accepted.</description>
</zone>
</pre>

Neustart der Firewall:
<pre>
# systemctl restart firewalld.service
</pre>

==NetworkManager==
Vorhandene Netze anzeigen:
<pre>
# nmcli connection show
NAME UUID TYP GERÄT
Freifunk fec93f72-3488-4008-abfc-ec372d6f8806 802-11-wireless --
WLAN1 82be9628-2709-495f-a389-d209b74fcd05 802-11-wireless --
VPN1 ec0aa457-d3ec-4089-8c8f-1a53a8a33374 vpn --
LAN1 ee9ee0aa-57b9-4c5d-9c76-d2722986c5d8 802-3-ethernet --
enp2s0 8c1c5b53-0c80-44df-8c49-678b6d122d42 802-3-ethernet enp2s0
WLAN2 1e906b64-4909-4dbe-8d81-705ea64767b4 802-11-wireless wlp8s0
VPN2 23c0b2c5-b5a6-4e82-95b2-9b198074391d vpn --
</pre>
Man erkennt, dass das Notebook kabelgebunden über das Interface ''enp2s0'' am Netzwerk ''enp2s0'' und per WLAN über wlp8s0 am eigenen Funk-Netzwerk ''WLAN2'' hängt.

Die Zuordnung der Zone 'work' an beide Netze erfolgt über die UUID der Netze im [[NetworkManager]]. Hierzu wird das CLI anstatt der GUI verwendet:
<pre>
# nmcli con mod "8c1c5b53-0c80-44df-8c49-678b6d122d42" connection.zone work
# nmcli con mod "1e906b64-4909-4dbe-8d81-705ea64767b4" connection.zone work
</pre>
Anschließend werden die Verbindungen noch aktiviert:
<pre>
# nmcli con up uuid 8c1c5b53-0c80-44df-8c49-678b6d122d42
Verbindung wurde erfolgreich aktiviert (aktiver D-Bus-Pfad: /org/freedesktop/NetworkManager/ActiveConnection/38)
# nmcli con up uuid 1e906b64-4909-4dbe-8d81-705ea64767b4
Verbindung wurde erfolgreich aktiviert (aktiver D-Bus-Pfad: /org/freedesktop/NetworkManager/ActiveConnection/39)
</pre>

=Überprüfung=
Abschließend die Konfiguration zu überprüfen.

Die Anzeige im Falle der Verbindung in den heimischen Netzen zeigt, dass die beiden Interfaces ''enp2s0'' und ''wlp8s0'' der Zone 'work' zugeordnet sind:
<pre>
# firewall-cmd --get-active-zones
work
interfaces: enp2s0 wlp8s0
</pre>
Anzeige der Konfiguration dieser Zone:
<pre>
# firewall-cmd --zone=work --list-all --permanent
work
interfaces:
sources:
services: ssh
ports:
masquerade: no
forward-ports:
icmp-blocks:
rich rules:
rule family="ipv4" source address="172.16.21.10" service name="bacula" accept
</pre>

Dagegen sollte bei einer Verbindung zu einem anderen Netzwerk die Default-Zone 'public' zugeordnet sein. Im folgenden Beispiel besteht ausschließlich eine Verbindung zum WLAN 'Freifunk':
<pre>
# nmcli connection show
NAME UUID TYP GERÄT
Freifunk fec93f72-3488-4008-abfc-ec372d6f8806 802-11-wireless wlp8s0
enp2s0 8c1c5b53-0c80-44df-8c49-678b6d122d42 802-3-ethernet --
WLAN1 82be9628-2709-495f-a389-d209b74fcd05 802-11-wireless --
VPN1 ec0aa457-d3ec-4089-8c8f-1a53a8a33374 vpn --
LAN1 ee9ee0aa-57b9-4c5d-9c76-d2722986c5d8 802-3-ethernet --
enp2s0 8c1c5b53-0c80-44df-8c49-678b6d122d42 802-3-ethernet --
WLAN2 1e906b64-4909-4dbe-8d81-705ea64767b4 802-11-wireless --
VPN2 23c0b2c5-b5a6-4e82-95b2-9b198074391d vpn --
</pre>
Dementsprechend zeigt die Prüfung, dass für das WLAN-Interface ''wlp8s0'' die Zone 'public' gesetzt wurde und das derzeit nicht verbundene ''enp2s0'' ohne Zuordnung verbleibt:
<pre>
# firewall-cmd --get-active-zones
public
interfaces: wlp8s0
</pre>
Es ist zu erkennen, dass [[SSH]] im Bereich ''services'' nicht zugelassen ist:
<pre>
# firewall-cmd --zone=public --list-all
public (default, active)
interfaces: wlp8s0
sources:
services:
ports:
masquerade: no
forward-ports:
icmp-blocks:
rich rules:
</pre>
Dabei erfolgt die Zuordnung der Zonen automatisch in Reaktion auf die Auswahl des Netzwerkes im [[NetworkManger]]. Eine manuelle Auswahl der Zone ist hierfür nicht erforderlich.

[[Category:Security]] [[Category:Netzwerk]]

Konfigurationsbeispiel eines Notebooks für den Einsatz in unterschiedlichen Netzen mit 'firewalld' und 'NetworkManager'

2016-10-24T21:16:21Z

Gehrke: Formatierung

{{UnderConstruction}}--[[Benutzer:Gehrke|Gehrke]] ([[Benutzer Diskussion:Gehrke|Diskussion]]) 22:09, 24. Okt. 2016 (CEST)

Im Folgenden soll eine Beispielkonfiguration für ein Notebook gezeigt werden, welches auf den Einsatz in '''Netzwerken mit unterschiedlichen Sicherheitsanforderungen''' eingerichtet ist. Dieses System soll im eigenen Netz (LAN und WLAN) mit der Zone 'work' laufen, welche eine bestimmte Netzwerkfunktionalität wie [[SSH]] oder den File-Daemon von [[Bacula]] auf diesem Notebook erlaubt. In anderen Netzen dagegen soll die Default-Zone 'public' verwendet werden, welche nur eine sehr eingeschränkte Netzwerk-Konnektivität erlaubt.

Dabei soll die Zuordnung anhand der Auswahl des Netzwerkes im [[NetworkManager]] erfolgen, welche in der Regel automatisch erfolgt. Beispielsweise beim Wechsel vom (als sicher eingestuften) Heim-WLAN in ein unsicheres öffentliches Netz nach einem Ruhezustand des Notebooks.

Gewünschte Eigenschaften der Zonen:
*work: [[SSH]] und bacula-fd nur vom [[bacula]]-Server (172.16.21.10)
*public: Keinerlei Zugriff (auch kein SSH)

Dieses Beispiel basiert auf der Distribution [[CentOS]] 7.

=Konfiguration=
Um dieses Ziel zu erreichen, sind zwei Subsysteme zu konfigurieren:
*[[firewalld]]: Dieser Dienst übernimmt die dynamische Konfiguration und Steuerung der lokalen Firewall. Die von der Distribution vorgegebenen Templates (XML) für die beiden Zonen werden kopiert und angepasst, so dass die Konfiguration persistent zur Verfügung steht.
*[[NetworkManager]]: Der Dienst konfiguriert und steuert die Netzwerkanbindung dynamisch. Bekannten Netzen soll anhand der UUID die Zone 'work' zugewiesen werden. Andere Netze behalten die Default-Zone 'public'. Die Konfiguration erfolgt über das CLI auf der Kommandozeile.

==firewalld==
Im ersten Schritt werden die durch die Distribution vorgegebenen Zonen-Definitionen kopiert. Die folgenden Änderungen erfolgen auf den hier erzeugten Kopien:
<pre>
# cp /usr/lib/firewalld/zones/public.xml /etc/firewalld/zones/
# cp /usr/lib/firewalld/zones/work.xml /etc/firewalld/zones/
</pre>
Die geänderten Definitionen enthalten die Umsetzung für die oben genannten Anforderungen:
<pre>
# cat /etc/firewalld/zones/work.xml
<?xml version="1.0" encoding="utf-8"?>
<zone>
<short>Work</short>
<description>For use in work areas. You mostly trust the other computers on networks to not harm your computer. Only selected incoming connections are accepted.</description>
<service name="ssh"/>
<rule family="ipv4">
<source address="172.16.21.10"/>
<service name="bacula"/>
<accept/>
</rule>
</zone>
</pre>
<pre>
# cat /etc/firewalld/zones/public.xml
<?xml version="1.0" encoding="utf-8"?>
<zone>
<short>Public</short>
<description>For use in public areas. You do not trust the other computers on networks to not harm your computer. Only selected incoming connections are accepted.</description>
</zone>
</pre>

Neustart der Firewall:
<pre>
# systemctl restart firewalld.service
</pre>

==NetworkManager==
Vorhandene Netze anzeigen:
<pre>
# nmcli connection show
NAME UUID TYP GERÄT
Freifunk fec93f72-3488-4008-abfc-ec372d6f8806 802-11-wireless --
WLAN1 82be9628-2709-495f-a389-d209b74fcd05 802-11-wireless --
VPN1 ec0aa457-d3ec-4089-8c8f-1a53a8a33374 vpn --
LAN1 ee9ee0aa-57b9-4c5d-9c76-d2722986c5d8 802-3-ethernet --
enp2s0 8c1c5b53-0c80-44df-8c49-678b6d122d42 802-3-ethernet enp2s0
WLAN2 1e906b64-4909-4dbe-8d81-705ea64767b4 802-11-wireless wlp8s0
VPN2 23c0b2c5-b5a6-4e82-95b2-9b198074391d vpn --
</pre>
Man erkennt, dass das Notebook kabelgebunden über das Interface ''enp2s0'' am Netzwerk ''enp2s0'' und per WLAN über wlp8s0 am eigenen Funk-Netzwerk ''WLAN2'' hängt.

Die Zuordnung der Zone 'work' an beide Netze erfolgt über die UUID der Netze im [[NetworkManager]]. Hierzu wird das CLI anstatt der GUI verwendet:
<pre>
# nmcli con mod "8c1c5b53-0c80-44df-8c49-678b6d122d42" connection.zone work
# nmcli con mod "1e906b64-4909-4dbe-8d81-705ea64767b4" connection.zone work
</pre>
Anschließend werden die Verbindungen noch aktiviert:
<pre>
# nmcli con up uuid 8c1c5b53-0c80-44df-8c49-678b6d122d42
Verbindung wurde erfolgreich aktiviert (aktiver D-Bus-Pfad: /org/freedesktop/NetworkManager/ActiveConnection/38)
# nmcli con up uuid 1e906b64-4909-4dbe-8d81-705ea64767b4
Verbindung wurde erfolgreich aktiviert (aktiver D-Bus-Pfad: /org/freedesktop/NetworkManager/ActiveConnection/39)
</pre>

=Überprüfung=
Abschließend die Konfiguration zu überprüfen.

Die Anzeige im Falle der Verbindung in den heimischen Netzen zeigt, dass die beiden Interfaces ''enp2s0'' und ''wlp8s0'' der Zone 'work' zugeordnet sind:
<pre>
# firewall-cmd --get-active-zones
work
interfaces: enp2s0 wlp8s0
</pre>
Anzeige der Konfiguration dieser Zone:
<pre>
# firewall-cmd --zone=work --list-all --permanent
work
interfaces:
sources:
services: ssh
ports:
masquerade: no
forward-ports:
icmp-blocks:
rich rules:
rule family="ipv4" source address="172.16.21.10" service name="bacula" accept
</pre>

Dagegen sollte bei einer Verbindung zu einem anderen Netzwerk die Default-Zone 'public' zugeordnet sein. Im folgenden Beispiel besteht ausschließlich eine Verbindung zum WLAN 'Freifunk':
<pre>
# nmcli connection show
NAME UUID TYP GERÄT
Freifunk fec93f72-3488-4008-abfc-ec372d6f8806 802-11-wireless wlp8s0
enp2s0 8c1c5b53-0c80-44df-8c49-678b6d122d42 802-3-ethernet --
WLAN1 82be9628-2709-495f-a389-d209b74fcd05 802-11-wireless --
VPN1 ec0aa457-d3ec-4089-8c8f-1a53a8a33374 vpn --
LAN1 ee9ee0aa-57b9-4c5d-9c76-d2722986c5d8 802-3-ethernet --
enp2s0 8c1c5b53-0c80-44df-8c49-678b6d122d42 802-3-ethernet --
WLAN2 1e906b64-4909-4dbe-8d81-705ea64767b4 802-11-wireless --
VPN2 23c0b2c5-b5a6-4e82-95b2-9b198074391d vpn --
</pre>
Dementsprechend zeigt die Prüfung, dass für das WLAN-Interface ''wlp8s0'' die Zone 'public' gesetzt wurde und das derzeit nicht verbundene ''enp2s0'' ohne Zuordnung verbleibt:
<pre>
# firewall-cmd --get-active-zones
public
interfaces: wlp8s0
</pre>
Es ist zu erkennen, dass [[SSH]] im Bereich ''services'' nicht zugelassen ist:
<pre>
# firewall-cmd --zone=public --list-all
public (default, active)
interfaces: wlp8s0
sources:
services:
ports:
masquerade: no
forward-ports:
icmp-blocks:
rich rules:
</pre>
Dabei erfolgt die Zuordnung der Zonen automatisch in Reaktion auf die Auswahl des Netzwerkes im [[NetworkManger]]. Eine manuelle Auswahl der Zone ist hierfür nicht erforderlich.

[[Category:Security]] [[Category:Netzwerk]]

Konfigurationsbeispiel eines Notebooks für den Einsatz in unterschiedlichen Netzen mit 'firewalld' und 'NetworkManager'

2016-10-24T21:11:50Z

Gehrke: Initial

{{UnderConstruction}}--[[Benutzer:Gehrke|Gehrke]] ([[Benutzer Diskussion:Gehrke|Diskussion]]) 22:09, 24. Okt. 2016 (CEST)

Im Folgenden soll eine Beispielkonfiguration für ein Notebook gezeigt werden, welches auf den Einsatz in Netzwerken mit unterschiedlichen Sicherheitsanforderungen eingerichtet ist. Dieses System soll im eigenen Netz (LAN und WLAN) mit der Zone 'work' laufen, welche eine bestimmte Netzwerkfunktionalität wie [[SSH]] oder den File-Daemon von [[Bacula]] auf diesem Notebook erlaubt. In anderen Netzen dagegen soll die Default-Zone 'public' verwendet werden, welche nur eine sehr eingeschränkte Netzwerk-Konnektivität erlaubt.

Dabei soll die Zuordnung anhand der Auswahl des Netzwerkes im [[NetworkManager]] erfolgen, welche in der Regel automatisch erfolgt. Beispielsweise beim Wechsel vom (als sicher eingestuften) Heim-WLAN in ein unsicheres öffentliches Netz nach einem Ruhezustand des Notebooks.

Gewünschte Eigenschaften der Zonen:
*work: [[SSH]] und bacula-fd nur vom [[bacula]]-Server (172.16.21.10)
*public: Keinerlei Zugriff (auch kein SSH)

Dieses Beispiel basiert auf der Distribution [[CentOS]] 7.

=Konfiguration=
Um dieses Ziel zu erreichen, sind zwei Subsysteme zu konfigurieren:
*[[firewalld]]: Dieser Dienst übernimmt die dynamische Konfiguration und Steuerung der lokalen Firewall. Die von der Distribution vorgegebenen Templates (XML) für die beiden Zonen werden kopiert und angepasst, so dass die Konfiguration persistent zur Verfügung steht.
*[[NetworkManager]]: Der Dienst konfiguriert und steuert die Netzwerkanbindung dynamisch. Bekannten Netzen soll anhand der UUID die Zone 'work' zugewiesen werden. Andere Netze behalten die Default-Zone 'public'. Die Konfiguration erfolgt über das CLI auf der Kommandozeile.

==firewalld==
Im ersten Schritt werden die durch die Distribution vorgegebenen Zonen-Definitionen kopiert. Die folgenden Änderungen erfolgen auf den hier erzeugten Kopien:
<pre>
# cp /usr/lib/firewalld/zones/public.xml /etc/firewalld/zones/
# cp /usr/lib/firewalld/zones/work.xml /etc/firewalld/zones/
</pre>
Die geänderten Definitionen enthalten die Umsetzung für die oben genannten Anforderungen:
<pre>
# cat /etc/firewalld/zones/work.xml
<?xml version="1.0" encoding="utf-8"?>
<zone>
<short>Work</short>
<description>For use in work areas. You mostly trust the other computers on networks to not harm your computer. Only selected incoming connections are accepted.</description>
<service name="ssh"/>
<rule family="ipv4">
<source address="172.16.21.10"/>
<service name="bacula"/>
<accept/>
</rule>
</zone>
</pre>
<pre>
# cat /etc/firewalld/zones/public.xml
<?xml version="1.0" encoding="utf-8"?>
<zone>
<short>Public</short>
<description>For use in public areas. You do not trust the other computers on networks to not harm your computer. Only selected incoming connections are accepted.</description>
</zone>
</pre>

Neustart der Firewall:
<pre>
# systemctl restart firewalld.service
</pre>

==NetworkManager==
Vorhandene Netze anzeigen:
<pre>
# nmcli connection show
NAME UUID TYP GERÄT
Freifunk fec93f72-3488-4008-abfc-ec372d6f8806 802-11-wireless --
WLAN1 82be9628-2709-495f-a389-d209b74fcd05 802-11-wireless --
VPN1 ec0aa457-d3ec-4089-8c8f-1a53a8a33374 vpn --
LAN1 ee9ee0aa-57b9-4c5d-9c76-d2722986c5d8 802-3-ethernet --
enp2s0 8c1c5b53-0c80-44df-8c49-678b6d122d42 802-3-ethernet enp2s0
WLAN2 1e906b64-4909-4dbe-8d81-705ea64767b4 802-11-wireless wlp8s0
VPN2 23c0b2c5-b5a6-4e82-95b2-9b198074391d vpn --
</pre>
Man erkennt, dass das Notebook kabelgebunden über das Interface ''enp2s0'' am Netzwerk ''enp2s0'' und per WLAN über wlp8s0 am eigenen Funk-Netzwerk ''WLAN2'' hängt.

Die Zuordnung der Zone 'work' an beide Netze erfolgt über die UUID der Netze im [[NetworkManager]]. Hierzu wird das CLI anstatt der GUI verwendet:
<pre>
# nmcli con mod "8c1c5b53-0c80-44df-8c49-678b6d122d42" connection.zone work
# nmcli con mod "1e906b64-4909-4dbe-8d81-705ea64767b4" connection.zone work
</pre>
Anschließend werden die Verbindungen noch aktiviert:
<pre>
# nmcli con up uuid 8c1c5b53-0c80-44df-8c49-678b6d122d42
Verbindung wurde erfolgreich aktiviert (aktiver D-Bus-Pfad: /org/freedesktop/NetworkManager/ActiveConnection/38)
# nmcli con up uuid 1e906b64-4909-4dbe-8d81-705ea64767b4
Verbindung wurde erfolgreich aktiviert (aktiver D-Bus-Pfad: /org/freedesktop/NetworkManager/ActiveConnection/39)
</pre>

=Überprüfung=
Abschließend die Konfiguration zu überprüfen.

Die Anzeige im Falle der Verbindung in den heimischen Netzen zeigt, dass die beiden Interfaces ''enp2s0'' und ''wlp8s0'' der Zone 'work' zugeordnet sind:
<pre>
# firewall-cmd --get-active-zones
work
interfaces: enp2s0 wlp8s0
</pre>
Anzeige der Konfiguration dieser Zone:
<pre>
# firewall-cmd --zone=work --list-all --permanent
work
interfaces:
sources:
services: ssh
ports:
masquerade: no
forward-ports:
icmp-blocks:
rich rules:
rule family="ipv4" source address="172.16.21.10" service name="bacula" accept
</pre>

Dagegen sollte bei einer Verbindung zu einem anderen Netzwerk die Default-Zone 'public' zugeordnet sein. Im folgenden Beispiel besteht ausschließlich eine Verbindung zum WLAN 'Freifunk':
<pre>
# nmcli connection show
NAME UUID TYP GERÄT
Freifunk fec93f72-3488-4008-abfc-ec372d6f8806 802-11-wireless wlp8s0
enp2s0 8c1c5b53-0c80-44df-8c49-678b6d122d42 802-3-ethernet --
WLAN1 82be9628-2709-495f-a389-d209b74fcd05 802-11-wireless --
VPN1 ec0aa457-d3ec-4089-8c8f-1a53a8a33374 vpn --
LAN1 ee9ee0aa-57b9-4c5d-9c76-d2722986c5d8 802-3-ethernet --
enp2s0 8c1c5b53-0c80-44df-8c49-678b6d122d42 802-3-ethernet --
WLAN2 1e906b64-4909-4dbe-8d81-705ea64767b4 802-11-wireless --
VPN2 23c0b2c5-b5a6-4e82-95b2-9b198074391d vpn --
</pre>
Dementsprechend zeigt die Prüfung, dass für das WLAN-Interface ''wlp8s0'' die Zone 'public' gesetzt wurde und das derzeit nicht verbundene ''enp2s0'' ohne Zuordnung verbleibt:
<pre>
# firewall-cmd --get-active-zones
public
interfaces: wlp8s0
</pre>
Es ist zu erkennen, dass [[SSH]] im Bereich ''services'' nicht zugelassen ist:
<pre>
# firewall-cmd --zone=public --list-all
public (default, active)
interfaces: wlp8s0
sources:
services:
ports:
masquerade: no
forward-ports:
icmp-blocks:
rich rules:
</pre>
Dabei erfolgt die Zuordnung der Zonen automatisch in Reaktion auf die Auswahl des Netzwerkes im [[NetworkManger]]. Eine manuelle Auswahl der Zone ist hierfür nicht erforderlich.

[[Category:Security]] [[Category:Netzwerk]]

Konfigurationsbeispiel eines Notebooks für den Einsatz in unterschiedlichen Netzen mit 'firewalld' und 'NetworkManager'

2016-10-24T20:09:42Z

Gehrke: Initial

{{UnderConstruction}}--[[Benutzer:Gehrke|Gehrke]] ([[Benutzer Diskussion:Gehrke|Diskussion]]) 22:09, 24. Okt. 2016 (CEST)

[[Category:Security]] [[Category:Netzwerk]]

Security

2016-10-24T20:00:25Z

Gehrke: /* Sicherheit im Netzwerk */ Konfigurationsbeispiel

== Allgemeine und Lokale Sicherheit ==
* [[Absichern des eigenen Servers ]] - Tips welche Dinge zu tun sind um einen Server sicher zu machen.
* [[Kontrolliertes Ausfuehren von Befehlen als root]] - Wie kann man normale User berechtigen kontrolliert root Befehle abzusetzen? sudo oder ssh ist die Loesung.
* [[Festplatten verschlüsselt mit Linux und Windows nutzen]]
* [[Verschluesselung: dm-crypt/luks unter openSUSE|Verschlüsselung: dm-crypt/luks unter openSUSE]] - Mit cryptsetup (inkl. LUKS-Erweiterung) verschlüsselte Partitionen beim Systemstart einbinden.
* [[Mit dm-crypt/luks verschluesselte Home-Partition beim Login einbinden|Mit dm-crypt/luks verschlüsselte Home-Partition beim Login einbinden]]
* [[Partitionierung eines komplett verschlüsselten Linux-Systems]] - Über die Problematik von unverschlüsselten boot-Partitionen
* [[E-Mailverschluesselung und Signierung]] - Alles zum Verschlüsseln von eMails
* [[Wie eine Platte unwiederherstellbar und sicher loeschen]] - Immer wieder möchte man eine Platte absolut sicher löschen. Mit etwas Zeit ist das nahezu moeglich.
* [[Dateien aus dem Kontextmenue sicher loeschen|Dateien aus dem Kontextmenü sicher löschen]] - Neuer Eintrag im Kontextmenü des Konqueror
* [[AntiVir und Dazuko-On-Access Scanning]] - Anleitung wie man beim Zugriff auf Dateien eine automatischen Virenscan vornehmen lassen kann
* [[Literatur zu Security]] - Für alle die, die sich mit einem Thema intensiver befassen wollen
* [[Sichere Passwoerter erstellen|Sichere Passwörter erstellen]] - Wie erzeugen und handhaben die LC Mitglieder sichere Passwörter?

== Sicherheit im Netzwerk ==
* [[Top 100 Network Security Tools]] - Liste der 100 meistgenutzten Netzwerk Security Tools
* [[Welche Ports sind an meinem Server offen]] - Befehle und Webseiten, mit denen offene Ports am eigenen Server aufgespürt werden.
* [[SuSEfirewall2]] - inofficial Documentation
* [[Firewalleinstellungen fuer NFS]] - Was ist nötig um NFS durch Firewalls zu schleusen.
* [[Sicheres tunneln von unsicheren Protokollen mit ssh]] - Wie kann man mit ssh unsichere Protokolle (pop, smtp, ...) absichern?
* [[Erklärung der netfilter Firewall Meldungen online]]
* [[Wie sichere ich meinen ssh Server]] - Beschreibung von Möglichkeiten wie man eine ssh Server sicher ins Internet stellen kann sowie eine Liste wichtiger sshd_config Parameter.
* [[Einrichten von public keys mit ssh]] - Anleitung, wie ein asymmetischer key beim ssh erzeugt werden kann
* [[Mit putty und ssh key auf einen sicheren Linux Server zugreifen]] - Beschreibung wie ein putty unter Windows mit einem ssh key so einzurichten ist, dass Zugriffe auf einen Linux Server nur noch mit asymetrischem key moeglich sind. Gleichzeitig wird beschrieben, wie man den Linux Server sshd daemon konfigurieren muss um nur noch per key zugreifen zu können.
* [[Einrichten von shorewall mit Webmin ]]
* [[Kleines Howto IPsec mit racoon]] - Anleitung, wie ipsec aufzusetzen ist mit racoon
* [[Die Peter Huth Lücke in PHP Scripten vermeiden]] - Beschreibung, wie man relativ schnell seinen Webserver mittels PHP unsicher machen kann.
* [[Snort]]
* [[Firewall]]
* [[Konfigurationsbeispiel eines Notebooks für den Einsatz in unterschiedlichen Netzen mit 'firewalld' und 'NetworkManager']]

== Sicherheit der Daten ==
* [[Wie eine Platte unwiederherstellbar und sicher loeschen|Sicheres Löschen von Platten]] - Wie lösche ich meine Platten so dass niemand mehr die Daten lesen kann?

== Sicherheit & Anonymität ==
* [[Tor Netzwerk]] - Anonymes Surfen im Internet wie auch im Tor Netzwerk.
* [[I2p Projekt|i2p Projekt]] - Ein anonymes.- und pseudonymes Netzwerk.

[[Kategorie:Security]]
[[Kategorie:Übersicht]]

Diskussion:Amazon MP3 herunterladen

2016-03-20T10:28:01Z

Gehrke: Aktualisierung/Update 19. März 2016

=Aktualisierung/Update 19. März 2016=
@tomm.fa: Hatte die Tage ebenfalls dort ein paar MP3s gekauft und das amz-File für ''clamz'' vergeblich gesucht.
Gut, dass Du an diese Artikel gedacht hast...
--[[Benutzer:Gehrke|Gehrke]] ([[Benutzer Diskussion:Gehrke|Diskussion]]) 11:28, 20. Mär. 2016 (CET)

Umgang mit redundanten Laufwerken unter OpenSUSE 13.1 (GRUB2)

2016-03-19T14:19:53Z

Gehrke: /* Fall 2: Nur Festplatte 2 im System */ Leserzuschrift - grub2-install

{{Review|Kompletter Artikel}}--[[Benutzer:Gehrke|Gehrke]] ([[Benutzer Diskussion:Gehrke|Diskussion]]) 07:22, 19. Dez. 2013 (CET)

Diese Seite gehört zum Kontext [[Umgang mit redundanten Laufwerken (GRUB2)]].

=Systembeschreibung=

Partitionierung:
<pre>
localhost:~ # lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 8G 0 disk
├─sda1 8:1 0 509M 0 part
│ └─md0 9:0 0 509M 0 raid1 /boot
└─sda2 8:2 0 7.5G 0 part
└─md1 9:1 0 7.5G 0 raid1
└─cr_md1 253:0 0 7.5G 0 crypt
├─system-root 253:1 0 6.5G 0 lvm /
└─system-swap 253:2 0 1G 0 lvm [SWAP]
sdb 8:16 0 8G 0 disk
├─sdb1 8:17 0 509M 0 part
│ └─md0 9:0 0 509M 0 raid1 /boot
└─sdb2 8:18 0 7.5G 0 part
└─md1 9:1 0 7.5G 0 raid1
└─cr_md1 253:0 0 7.5G 0 crypt
├─system-root 253:1 0 6.5G 0 lvm /
└─system-swap 253:2 0 1G 0 lvm [SWAP]
</pre>

Zustand des Arrays:
<pre>
localhost:~ # cat /proc/mdstat
Personalities : [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] [linear]
md0 : active raid1 sda1[0] sdb1[1]
521152 blocks super 1.0 [2/2] [UU]
bitmap: 0/1 pages [0KB], 65536KB chunk

md1 : active raid1 sda2[0] sdb2[1]
7866304 blocks super 1.0 [2/2] [UU]
bitmap: 1/1 pages [4KB], 65536KB chunk

unused devices: <none>
</pre>

Details zum RAID:
<pre>
localhost:~ # mdadm -Evvs
mdadm: No md superblock detected on /dev/sr0.
mdadm: No md superblock detected on /dev/md0.
mdadm: No md superblock detected on /dev/dm-2.
mdadm: No md superblock detected on /dev/dm-1.
mdadm: No md superblock detected on /dev/dm-0.
mdadm: No md superblock detected on /dev/md1.
/dev/sdb2:
Magic : a92b4efc
Version : 1.0
Feature Map : 0x1
Array UUID : cbb0a19a:3ab9c866:a55c498b:dad77155
Name : linux:1
Creation Time : Thu Dec 12 21:41:51 2013
Raid Level : raid1
Raid Devices : 2

Avail Dev Size : 15732704 (7.50 GiB 8.06 GB)
Array Size : 7866304 (7.50 GiB 8.06 GB)
Used Dev Size : 15732608 (7.50 GiB 8.06 GB)
Super Offset : 15732720 sectors
Unused Space : before=0 sectors, after=96 sectors
State : clean
Device UUID : 3643b447:54e45c14:3ffbebc4:47a1727e

Internal Bitmap : -16 sectors from superblock
Update Time : Fri Dec 13 19:37:03 2013
Bad Block Log : 512 entries available at offset -8 sectors
Checksum : 484ff8f3 - correct
Events : 155

Device Role : Active device 1
Array State : AA ('A' == active, '.' == missing, 'R' == replacing)
/dev/sdb1:
Magic : a92b4efc
Version : 1.0
Feature Map : 0x1
Array UUID : ce6547f1:6bcb31bc:02c20a67:2587a62a
Name : linux:0
Creation Time : Thu Dec 12 21:41:50 2013
Raid Level : raid1
Raid Devices : 2

Avail Dev Size : 1042400 (509.07 MiB 533.71 MB)
Array Size : 521152 (509.02 MiB 533.66 MB)
Used Dev Size : 1042304 (509.02 MiB 533.66 MB)
Super Offset : 1042416 sectors
Unused Space : before=0 sectors, after=96 sectors
State : clean
Device UUID : c37e1f95:4d6611e3:a7046773:e84fa160

Internal Bitmap : -16 sectors from superblock
Update Time : Fri Dec 13 19:17:35 2013
Bad Block Log : 512 entries available at offset -8 sectors
Checksum : 4f7ccd48 - correct
Events : 21

Device Role : Active device 1
Array State : AA ('A' == active, '.' == missing, 'R' == replacing)
/dev/sdb:
MBR Magic : aa55
Partition[0] : 1042432 sectors at 2048 (type fd)
Partition[1] : 15732736 sectors at 1044480 (type fd)
/dev/sda2:
Magic : a92b4efc
Version : 1.0
Feature Map : 0x1
Array UUID : cbb0a19a:3ab9c866:a55c498b:dad77155
Name : linux:1
Creation Time : Thu Dec 12 21:41:51 2013
Raid Level : raid1
Raid Devices : 2

Avail Dev Size : 15732704 (7.50 GiB 8.06 GB)
Array Size : 7866304 (7.50 GiB 8.06 GB)
Used Dev Size : 15732608 (7.50 GiB 8.06 GB)
Super Offset : 15732720 sectors
Unused Space : before=0 sectors, after=96 sectors
State : clean
Device UUID : 3a81e6b4:ea6a410b:cc3668e9:26fc95dc

Internal Bitmap : -16 sectors from superblock
Update Time : Fri Dec 13 19:37:03 2013
Bad Block Log : 512 entries available at offset -8 sectors
Checksum : 2f0653f9 - correct
Events : 155

Device Role : Active device 0
Array State : AA ('A' == active, '.' == missing, 'R' == replacing)
/dev/sda1:
Magic : a92b4efc
Version : 1.0
Feature Map : 0x1
Array UUID : ce6547f1:6bcb31bc:02c20a67:2587a62a
Name : linux:0
Creation Time : Thu Dec 12 21:41:50 2013
Raid Level : raid1
Raid Devices : 2

Avail Dev Size : 1042400 (509.07 MiB 533.71 MB)
Array Size : 521152 (509.02 MiB 533.66 MB)
Used Dev Size : 1042304 (509.02 MiB 533.66 MB)
Super Offset : 1042416 sectors
Unused Space : before=0 sectors, after=96 sectors
State : clean
Device UUID : d3a6b43b:ec7adf57:042686a4:f665aa63

Internal Bitmap : -16 sectors from superblock
Update Time : Fri Dec 13 19:17:35 2013
Bad Block Log : 512 entries available at offset -8 sectors
Checksum : 9f084160 - correct
Events : 21

Device Role : Active device 0
Array State : AA ('A' == active, '.' == missing, 'R' == replacing)
/dev/sda:
MBR Magic : aa55
Partition[0] : 1042432 sectors at 2048 (type fd)
Partition[1] : 15732736 sectors at 1044480 (type fd)
</pre>

Diese grub.cfg wurde bei der Installation geschrieben:
<pre>
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub2-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#

### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
load_env
fi
if [ "${next_entry}" ] ; then
set default="${next_entry}"
set next_entry=
save_env next_entry
set boot_once=true
else
set default="${saved_entry}"
fi

if [ x"${feature_menuentry_id}" = xy ]; then
menuentry_id_option="--id"
else
menuentry_id_option=""
fi

export menuentry_id_option

if [ "${prev_saved_entry}" ]; then
set saved_entry="${prev_saved_entry}"
save_env saved_entry
set prev_saved_entry=
save_env prev_saved_entry
set boot_once=true
fi

function savedefault {
if [ -z "${boot_once}" ]; then
saved_entry="${chosen}"
save_env saved_entry
fi
}

function load_video {
if [ x$feature_all_video_module = xy ]; then
insmod all_video
else
insmod efi_gop
insmod efi_uga
insmod ieee1275_fb
insmod vbe
insmod vga
insmod video_bochs
insmod video_cirrus
fi
}

if loadfont unicode ; then
set gfxmode=auto
load_video
insmod gfxterm
set locale_dir=$prefix/locale
set lang=
insmod gettext
fi
terminal_output gfxterm
insmod part_msdos
insmod part_msdos
insmod diskfilter
insmod mdraid1x
insmod ext2
set root='mduuid/ce6547f16bcb31bc02c20a672587a62a'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint='mduuid/ce6547f16bcb31bc02c20a672587a62a' f19541aa-6e4a-4954-8c29-2ac69b9a4e21
else
search --no-floppy --fs-uuid --set=root f19541aa-6e4a-4954-8c29-2ac69b9a4e21
fi
insmod gfxmenu
loadfont ($root)/grub2/themes/openSUSE/DejaVuSans-Bold14.pf2
loadfont ($root)/grub2/themes/openSUSE/DejaVuSans10.pf2
loadfont ($root)/grub2/themes/openSUSE/DejaVuSans12.pf2
loadfont ($root)/grub2/themes/openSUSE/ascii.pf2
insmod png
set theme=($root)/grub2/themes/openSUSE/theme.txt
export theme
if [ x${boot_once} = xtrue ]; then
set timeout=0
elif sleep --interruptible 0 ; then
set timeout=8
fi
### END /etc/grub.d/00_header ###

### BEGIN /etc/grub.d/10_linux ###
menuentry 'openSUSE 13.1' --class 'opensuse-13-1' --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-9ca3c62f-d5b8-46a7-a494-8ce2270e2f47' {
load_video
set gfxpayload=keep
insmod gzio
insmod part_msdos
insmod part_msdos
insmod diskfilter
insmod mdraid1x
insmod ext2
set root='mduuid/ce6547f16bcb31bc02c20a672587a62a'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint='mduuid/ce6547f16bcb31bc02c20a672587a62a' f19541aa-6e4a-4954-8c29-2ac69b9a4e21
else
search --no-floppy --fs-uuid --set=root f19541aa-6e4a-4954-8c29-2ac69b9a4e21
fi
echo 'Loading Linux 3.11.6-4-desktop ...'
linux /vmlinuz-3.11.6-4-desktop root=/dev/mapper/system-root resume=/dev/system/swap splash=silent quiet showopts
echo 'Loading initial ramdisk ...'
initrd /initrd-3.11.6-4-desktop
}
submenu 'Advanced options for openSUSE 13.1' $menuentry_id_option 'gnulinux-advanced-9ca3c62f-d5b8-46a7-a494-8ce2270e2f47' {
menuentry 'openSUSE 13.1, with Linux 3.11.6-4-desktop' --class 'opensuse-13-1' --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-3.11.6-4-desktop-advanced-9ca3c62f-d5b8-46a7-a494-8ce2270e2f47' {
load_video
set gfxpayload=keep
insmod gzio
insmod part_msdos
insmod part_msdos
insmod diskfilter
insmod mdraid1x
insmod ext2
set root='mduuid/ce6547f16bcb31bc02c20a672587a62a'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint='mduuid/ce6547f16bcb31bc02c20a672587a62a' f19541aa-6e4a-4954-8c29-2ac69b9a4e21
else
search --no-floppy --fs-uuid --set=root f19541aa-6e4a-4954-8c29-2ac69b9a4e21
fi
echo 'Loading Linux 3.11.6-4-desktop ...'
linux /vmlinuz-3.11.6-4-desktop root=/dev/mapper/system-root resume=/dev/system/swap splash=silent quiet showopts
echo 'Loading initial ramdisk ...'
initrd /initrd-3.11.6-4-desktop
}
menuentry 'openSUSE 13.1, with Linux 3.11.6-4-desktop (recovery mode)' --class 'opensuse-13-1' --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-3.11.6-4-desktop-recovery-9ca3c62f-d5b8-46a7-a494-8ce2270e2f47' {
load_video
set gfxpayload=keep
insmod gzio
insmod part_msdos
insmod part_msdos
insmod diskfilter
insmod mdraid1x
insmod ext2
set root='mduuid/ce6547f16bcb31bc02c20a672587a62a'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint='mduuid/ce6547f16bcb31bc02c20a672587a62a' f19541aa-6e4a-4954-8c29-2ac69b9a4e21
else
search --no-floppy --fs-uuid --set=root f19541aa-6e4a-4954-8c29-2ac69b9a4e21
fi
echo 'Loading Linux 3.11.6-4-desktop ...'
linux /vmlinuz-3.11.6-4-desktop root=/dev/mapper/system-root showopts apm=off noresume edd=off powersaved=off nohz=off highres=off processor.max_cstate=1 nomodeset x11failsafe
echo 'Loading initial ramdisk ...'
initrd /initrd-3.11.6-4-desktop
}
}

### END /etc/grub.d/10_linux ###

### BEGIN /etc/grub.d/20_linux_xen ###
### END /etc/grub.d/20_linux_xen ###

### BEGIN /etc/grub.d/20_memtest86+ ###
### END /etc/grub.d/20_memtest86+ ###

### BEGIN /etc/grub.d/20_ppc_terminfo ###
### END /etc/grub.d/20_ppc_terminfo ###

### BEGIN /etc/grub.d/30_os-prober ###
### END /etc/grub.d/30_os-prober ###

### BEGIN /etc/grub.d/40_custom ###
# This file provides an easy way to add custom menu entries. Simply type the
# menu entries you want to add after this comment. Be careful not to change
# the 'exec tail' line above.
### END /etc/grub.d/40_custom ###

### BEGIN /etc/grub.d/41_custom ###
if [ -f ${config_directory}/custom.cfg ]; then
source ${config_directory}/custom.cfg
elif [ -z "${config_directory}" -a -f $prefix/custom.cfg ]; then
source $prefix/custom.cfg;
fi
### END /etc/grub.d/41_custom ###

### BEGIN /etc/grub.d/90_persistent ###
### END /etc/grub.d/90_persistent ###
</pre>

=Funktionale Tests=
==Test 1: Boot-Partitionen im RAID abschalten==
Mit diesem Test wird der Ausfall jeweils einer Partition simuliert. Das System sollte dank der Redundanz fehlerfrei booten.

Eine Boot-Partition aus dem RAID entfernen:
<pre>
localhost:~ # mdadm --set-faulty /dev/md0 /dev/sda1
mdadm: set /dev/sda1 faulty in /dev/md0
localhost:~ # cat /proc/mdstat
Personalities : [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] [linear]
md0 : active raid1 sda1[0](F) sdb1[1]
521152 blocks super 1.0 [2/1] [_U]
bitmap: 0/1 pages [0KB], 65536KB chunk
...

localhost:~ # reboot
</pre>
Reboot funktionierte problemlos.

Partition hinzufügen (etwas warten bis Recovery-Prozess abgeschlossen ist) und andere entfernen:
<pre>
localhost:~ # mdadm --re-add /dev/md0 /dev/sda1
mdadm: re-added /dev/sda1

localhost:~ # mdadm --set-faulty /dev/md0 /dev/sdb1
mdadm: set /dev/sdb1 faulty in /dev/md0
localhost:~ # cat /proc/mdstat
Personalities : [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] [linear]
md0 : active raid1 sda1[0] sdb1[1](F)
521152 blocks super 1.0 [2/1] [U_]
bitmap: 0/1 pages [0KB], 65536KB chunk
...

localhost:~ # reboot
</pre>
Reboot funktionierte problemlos.
<pre>
localhost:~ # mdadm --re-add /dev/md0 /dev/sdb1
mdadm: re-added /dev/sdb1
</pre>
'''Fazit:''' OK

==Test 2: Festplatten entfernen==
Zur Simulation einer ausgefallenen Festplatte wurde vor dem Start die Festplatte aus der Konfiguration von [[VirtualBox]] entfernt.

===Fall 1: Nur Festplatte 1 im System===
Beobachtung: Das Menü von GRUB erscheint. Bei Start des Systems kommt es zu einer Endlosschleife, ohne dass die Passphrase für [[dm-crypt]] eingegeben werden kann:
<pre>
PARTIAL MODE. Incomplete logical volumes will be processed.
Volume group "system" not found
No volume groups found
</pre>

===Fall 2: Nur Festplatte 2 im System===
Beobachtung: Das Menü von GRUB erscheint '''nicht'''.

Vermutung: GRUB-Installation fehlt im [[MBR]] auf zweiter Festplatte.

Lösungsversuch 1: Installation nachgeholt:
<pre>
localhost:~ # grub-install.unsupported /dev/sda
Probing devices to guess BIOS drives. This may take a long time.
/dev/md0 does not have any corresponding BIOS drive.
localhost:~ # grub-install.unsupported /dev/sdb
/dev/md0 does not have any corresponding BIOS drive.
</pre>
Ergebnis: Bootet nicht.

Fehlermeldung: keine (alles schwarz, Cursor blinkt nicht)

''Nachtrag 19.03.2016:'' Einer Leserzuschrift zufolge funktioniert hier der folgende Ansatz:
<pre>
localhost:~ # grub2-install /dev/sda
localhost:~ # grub2-install /dev/sdb
</pre>
Leider besteht heute das zum Zeitpunkt der Erstellung dieses Artikels verwendete Systemsetup nicht mehr, so dass dies nicht mehr geprüft werden kann.

Lösungsversuch 2: Per [[YaST]] nach sda und sdb schreiben

Beim Start von Yast gibt es schon diesen Hinweis:
<pre>
localhost:~ # yast2 bootloader
Perl-Bootloader: 2013-12-13 22:53:57 <3> yast-1572.1 MBRTools::examineMBR.189: Error: Examine MBR cannot open /dev/md
</pre>
Das explizite Schreiben über
*Boot Loader Location
**Custom Boot Partiton => /dev/sdb
sowie das ganze zusätzlich nach ''/dev/sda'' brachte nichts. Ohne die erste Disk bootete das System nicht.

Links:
*[http://lists.opensuse.org/opensuse/2013-03/msg00221.html Root and boot partitions on a sw raid volume (opensuse 12.2 - 12.3 rc1 64bit)]
*[https://bugzilla.novell.com/show_bug.cgi?id=811830 Bug 811830 - Root and boot partitions on a sw raid volume, system cannot boot]

[[Kategorie:Bootmanager]]

Diskussion:Einfache Sambafreigabe über YaST

2016-01-17T04:57:06Z

Gehrke: Quoting / Einrückung

=Aktualisieren oder Löschen?=
Diese Seite besteht visuell zum Großteil aus völlig veralteten Bildern (welche Release war das?). Selbst wenn das heute noch ähnlich funktioniert, wird wohl jeder User hier gleich weiter klicken. Aktualisieren oder Löschen??? Ich bin für Löschen, denn so einmalig sind diese Informationen nicht. --[[Benutzer:Gehrke|Gehrke]] ([[Benutzer Diskussion:Gehrke|Diskussion]]) 22:39, 25. Nov. 2013 (CET)
:Die Seite auf die der Redirect nun zeigt nach der Umlautsalatbereinigung hat Bilder drin die eben ein anderes Desktopdesign oder einen ganz anderen Windowmanager als den Standard nutzt (wenns ein anderer Windowmanager war tippe ich mal auf Sawfish ;) )...müsste zur Zeit der Erstellung wohl ein 9er SuSE gewesen sein.Löschen muss man das nicht da die Infos ja im Grunde noch immer stimmen, aber mal paar neue Bilder wär wohl nicht verkehrt..am besten mit der Defaultoptik von YaST. Hab selbst allerdings auch keine Defaultoptik hier am Start sondern Mac OSX artigen Style, sonst würd ich das mal eben machen und die Bilder aktualisieren ;) (ohne den Redirect hätten wir jetzt wohl mal wieder eine Diskussion ohne zugehörige Seite nach dem Verschieben dank der Überschneidung *G*)--[[Benutzer:TomcatMJ|TomcatMJ]] ([[Benutzer Diskussion:TomcatMJ|Diskussion]]) 22:47, 25. Nov. 2013 (CET)

:Habe das gerade Eben mit OpenSUSE Tumbleweed benutzt. Passt einwandfrei. Das alter der Screenshots hat mich nicht gestört. Bitte nicht Löschen. :) ::::--[[Benutzer:revealed|revealed]] ([[Benutzer Diskussion:revealed|revealed]]) 22:09, 16. Jan. 2016 (CEST)

Bootloader wiederherstellen

2016-01-14T18:03:22Z

Gehrke: Review-Tag entfernt

Im Falle eines nicht mehr funktionierenden Boot-Prozesses ist es manchmal notwendig, den [[Bootmanager]] neu zu installieren. In solchen Fällen erscheint möglicherweise nach dem Start des Rechners nur die lapidare Anzeige:
<pre>
GRUB
</pre>

Der Vorgang kann prinzipiell mit einem beliebigen bootbaren Linux von USB-Stick oder CD geschehen, allerdings ist es wichtig, dass die Systemarchitektur passt (i386 vs. x86_64).

Im folgenden Beispiel erfolgt die Reparatur von [[GRUB 2]] eines installierten [[OpenSUSE]] 13.1 mit einer KDE-Live-Version der selben Release. Analog dazu sollte die Vorgehensweise aber auch für andere Systeme und andere Bootloader funktionieren.

=System mit Live-Version booten=
Zuerst wird das System über den USB-Stick gebootet. Je nach [[BIOS|BIOS-Einstellungen]] muss man hierfür noch eine Tastenkombination (oft F2) drücken, um den Stick als Boot-Medium auswählen zu können. Nach dem Start öffnet man eine Shell und wird root-User:
<pre>
linux@linux:~> su -
</pre>
Oftmals starten Live-Systeme mit einem amerikanischen [[Tastaturlayout]]. Hier ist es für deutschsprachige Anwender hilfreich, eine passende Tastaturbelegung einzustellen. Dies kann beispielsweise so erreicht werden:
<pre>
linux@linux:~ #loadkeys de-latin1.map
</pre>

=Partitionierungslayout=
Für die folgenden Schritte ist es wichtig, das Partitionierungslayout des Zielsystems verstanden zu haben. Eine übersichtliche Darstellung erreicht man über den Befehl ''lsblk'':
<pre>
linux:~ # lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 1.8T 0 disk
├─sda1 8:1 0 156M 0 part
└─sda2 8:2 0 1.8T 0 part
sdb 8:16 1 1.9G 0 disk
├─sdb1 8:17 1 4M 0 part
├─sdb2 8:18 1 936M 0 part /livecd
└─sdb3 8:19 1 970M 0 part /read-write
loop7 7:7 0 826.1M 1 loop /read-only
</pre>
In diesem Beispiel steht 'sda' für die Festplatte und 'sdb' für den USB-Stick. Die Partition '/boot' liegt unverschlüsselt in 'sda1', der ersten primären Partition.

Die anderen Teile des Dateisystems liegen in einem mit [[dm-crypt]] verschlüsselten Bereich auf 'sda2', welches die Bezeichnung der zweiten primären Partition ist. Darin befindet sich ein auf [[LVM]] basierendes Partitionierungsschema. Zuerst müssen alle Bereiche nacheinander zugreifbar gemacht werden.

''Hinweis:'' Nicht alle Systeme sind so konfiguriert wie in diesem Beispiel. Oftmals findet man weder Verschlüsselung noch LVM vor, sondern nur primäre oder erweiterte Partitionen. Insofern sind die folgenden Abschnitte als '''optional''' anzusehen und werden bei Nicht-Verwendung ausgelassen:
*[[#Cryptbereich entschlüsseln|Cryptbereich entschlüsseln]]
*[[#LVM-Partitionierung einlesen|LVM-Partitionierung einlesen]]

=Cryptbereich entschlüsseln=
Zuerst muss der [[dm-crypt]]-Container entschlüsselt werden:
<pre>
linux:~ # cryptsetup luksOpen /dev/sda2 crypted
Enter passphrase for /dev/sda2:

linux:~ # lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 1.8T 0 disk
├─sda1 8:1 0 156M 0 part
└─sda2 8:2 0 1.8T 0 part
└─crypted 253:0 0 1.8T 0 crypt
sdb 8:16 1 1.9G 0 disk
├─sdb1 8:17 1 4M 0 part
├─sdb2 8:18 1 936M 0 part /livecd
└─sdb3 8:19 1 970M 0 part /read-write
loop7 7:7 0 826.1M 1 loop /read-only
</pre>
Man beachte das neu erzeugte Device 'crypted'.

=LVM-Partitionierung einlesen=
Die LVM-Partitionierung wird wie folgt eingelesen und verfügbar gemacht:
<pre>
linux:~ # lvs
LV VG Attr LSize Pool Origin Data% Move Log Copy% Convert
home system -wi------ 1.66t
os2 system -wi------ 10.00g
root system -wi------ 10.00g
swap system -wi------ 2.00g

linux:~ # vgchange -a y

linux:~ # lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 1.8T 0 disk
├─sda1 8:1 0 156M 0 part
└─sda2 8:2 0 1.8T 0 part
└─crypted 253:0 0 1.8T 0 crypt
├─system-home 253:1 0 1.7T 0 lvm
├─system-root 253:2 0 10G 0 lvm
├─system-swap 253:3 0 2G 0 lvm
└─system-os2 253:4 0 10G 0 lvm
sdb 8:16 1 1.9G 0 disk
├─sdb1 8:17 1 4M 0 part
├─sdb2 8:18 1 936M 0 part /livecd
└─sdb3 8:19 1 970M 0 part /read-write
loop7 7:7 0 826.1M 1 loop /read-only
</pre>
Im vorliegenden Beispiel liegt die 'root'-Partition in der Volume Group (VG) 'system' in der Logical Volume (LV) 'root'. Diese wird unter /dev/system/root bereitgestellt.

=chroot=
Nun stehen alle notwendigen Bereiche zur Verfügung. Im Folgenden werden sie im Dateisystem zu einer Struktur verbunden, um dann via 'chroot' temporär in diese Systemumgebung zu wechseln.

Zuerst die echten Dateisysteme '/' und '/boot':
<pre>
linux:~ # mount /dev/system/root /mnt/
linux:~ # mount /dev/sda1 /mnt/boot/
</pre>
Anschließend die virtuellen Dateisysteme:
<pre>

linux:~ # mount -o bind /dev /mnt/dev
linux:~ # mount -o bind /sys /mnt/sys
linux:~ # mount -t proc /proc /mnt/proc
</pre>
Abschließend wird das 'chroot' durchgeführt:
<pre>
linux:~ # chroot /mnt/ /bin/bash
</pre>
Hinweis: Wenn hierbei ein Fehler auftritt wie der folgende, dann stimmen möglicherweise die Systemarchitekturen der Live-Version einerseits und des Zielsystems anderseits nicht überein (i386 vs. x86_64):
<pre>
chroot: failed to run command ‘/bin/bash’: Exec format error

linux:/ # uname -i
x86_64
</pre>

=Bootloader neu installieren=
Nachdem nun die gewünschte Systemumgebung vollständig aktiv ist, kann der Bootloader neu geschrieben werden. Im Falle von [[GRUB 2]] wird diese erneute Installation so durchgeführt:
<pre>
linux:/ # grub2-install /dev/sda
Installation finished. No error reported.
</pre>
Dabei wird der [[MBR]] der Festplatte 'sda' als Ziel verwendet.

=Systemressourcen freigeben=
Um den sauberen Neustart vorzubereiten, sollten alle Schritte in umgekehrter Reihenfolge wieder aufgelöst werden.

chroot beenden:
<pre>
linux:/ # exit
exit
</pre>

Dateisysteme lösen (umount):
<pre>
linux:~ # umount /mnt/proc
linux:~ # umount /mnt/sys
linux:~ # umount /mnt/dev
linux:~ # umount /mnt/boot
linux:~ # umount /mnt/
</pre>

Die LVM-Struktur auflösen:
<pre>
linux:~ # vgchange -a n
</pre>

Das Crypt-Device schliessen:
<pre>
linux:~ # cryptsetup luksClose crypted
</pre>
Abschliessend sollte die Block-Struktur wieder wie zu Anfang aussehen.
<pre>
linux:~ # lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 1.8T 0 disk
├─sda1 8:1 0 156M 0 part
└─sda2 8:2 0 1.8T 0 part
sdb 8:16 1 1.9G 0 disk
├─sdb1 8:17 1 4M 0 part
├─sdb2 8:18 1 936M 0 part /livecd
└─sdb3 8:19 1 970M 0 part /read-write
loop7 7:7 0 826.1M 1 loop /read-only
</pre>
Nun sollte nach einem Reboot der Bootmanager wieder funktionieren:
<pre>
linux:~ # reboot
</pre>

=Links=
*[http://www.rootz.de/2012/05/grub2-bootloader-mittels-linux-boot-cd-reparieren/ Grub2-Bootloader mittels Linux-Boot-CD reparieren (rootz)]
*[https://de.wikipedia.org/wiki/Chroot chroot (Wikipedia)]
*[[Bootmanager]]
*[[GRUB 2]]

[[Kategorie:Bootmanager]]

Diskussion:Bootloader wiederherstellen

2016-01-14T18:02:38Z

Gehrke: Review

=Review=
Der Bitte um Review ist scheinbar seit Februar 2014 keiner nachgekommen. Nachdem ich der Anleitung hier soeben auch noch einmal erfolgreich gefolgt bin, entferne ich dieses Tag nun von der Seite. --[[Benutzer:Gehrke|Gehrke]] ([[Benutzer Diskussion:Gehrke|Diskussion]]) 19:02, 14. Jan. 2016 (CET)

Systemd

2015-11-20T19:22:53Z

Gehrke: /* Fähigkeiten */ externe Verlinkung korrigiert

{{Review|Kompletter Artikel}}
{{Achtung|'''Aus technischen Gründen ist es leider nicht Möglich der korrekten Schreibweise von "systemd" in der Überschrift dieses Artikels gerecht zu werden.'''}}

= Was ist systemd? =
Systemd ist ein Dienst oder Daemon und bietet einige grundlegende Werkzeuge für Linux Systeme. Er wird zur System- und Diensteverwaltung eingesetzt. Er läuft mit [[https://de.wikipedia.org/wiki/Process_identifier PID1]] und startet dann alle weiteren Prozesse des Betriebssystems. Des weiteren wird er als freie Software unter der [[LGPL |LGPL 2.1+]] veröffentlicht und wurde in [[Programmierung|C geschrieben]].

* http://www.freedesktop.org/wiki/Software/systemd/

''Er startet also als erstes ([[https://de.wikipedia.org/wiki/Process_identifier PID1]]), regelt und steuert dabei alle weiteren Dienste. Er beendet sich beim Herunterfahren als letztes. Der daemon systemd ist damit also tief im Ablauf eines Systemstarts verwurzelt.''

'''Wichtiges dazu:'''
* [[Bootmanager]]
* [[Bootvorgang]]
* [[YaST2_Dienste-Verwaltung|YaST2 Dienste-Verwaltung]]
 

= SUSE wechsel zu systemd =
Mit unter liebevoll vollzieht sich der Wechsel zu systemd als Init-System in SUSE mit Sätzen, zitert aus den Releasenotes und dem Adminguide zu [[https://www.suse.com/ SUSE Linux Enterprise Server 12]], wie:
<blockquote><pre style="background-color: #D4FFEF; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">New core technologies like systemd (replacing the time honored System V based init process) </pre></blockquote>
'''Versuchsweise frei übersetzt:''' ''Neue Kerntechnologien wie systemd (ersetzen den durch lange Dienstzeit geehrten System V basierten init prozess).''
<blockquote><pre style="background-color: #D4FFEF; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Starting with SUSE Linux Enterprise Server 12 systemd is a replacement for the popular System V init daemon. systemd is fully compatible with System V init (by supporting init scripts). </pre></blockquote>
'''Versuchsweise frei übersetzt:''' ''Beginnend mit [[https://www.suse.com/ SUSE Linux Enterprise Server 12]] ist systemd ein Ersatz für den populären System V init daemon. Er ist voll kompatibel mit dem System V Init-Vorgang, indem er Init Skripte unterstützt.''

= Integration in [[YaST]] =
{|
|rowspan=2|[[Bild:Yast.png]]
|colspan=3|Wie sich systemd im grafischen Konfigurationstool für [[openSUSE]] integriert, könnt ihr hier sehen:
|-
|style="text-align:center;"| ---------->
|style="text-align:center;"|[[YaST2_Dienste-Verwaltung|YaST2: Diensteverwaltung]]
|style="text-align:center;"| <----------
|-
|}

=Kompatibilität=
Als sogenanntes "drop-in replacement". Bietet systemd Kompatibilität zu seinen Vorgängern:
 
* kompatibel mit [https://de.wikipedia.org/wiki/Linux_Standard_Base LSB] init Skripten
* kompatibel mit SysV
Hier gibt es zu beachten, dass systemd nicht vollständig rückwärts kompatibel ist.
Einige Einschränkungen können hier nachgelesen werden: http://www.freedesktop.org/wiki/Software/systemd/Incompatibilities/

=Kritik=
Da ich nicht unnötig falsches sagen möchte, was Kritik gegenüber systemd angeht. Und da ich nur einige Grundlagen objektiv darstellen will, kann ich dazu nicht viel sagen. Allerdings kann ich folgendes berichten:
* Bei Linux Entwicklern als auch Benutzern steht systemd im Mittelpunkt der Kritik, da es im Ansatz sehr wichtige Kernfunktionen steuert und auch das alt eingefahrene SysV-Init ersetzen kann, bzw. kompatibel ist.
* Zu diesem Thema gibt es massenweise Informationen im Internet.
'''Ein besonders wichtiger Punkt:'''
* Es gibt viele Gegner als auch Befürworter.
 
{{Hinweis|'''Wer möchte informiert sich darüber bitte detaillierter mithilfe einer Suchmaschine eigener Wahl.'''}}
{{Hinweis|'''Das Forum würde sich hierfür als Diskussionsplatform anbieten, wer möchte. Es gibt sicher einige die an dieser Thematik interesse haben. http://forum.linux-club.de/'''}} 
---------
'''Meine Meinung zur Kritik:''' 
(Wer mir diesen Raum nicht lassen möchte: Bitte "skipping").
 
''Ich finde es wichtig, dass derart grundlegende Kernstrukturen im Betriebssystem kritisiert werden, solange es zielführend und im Sinne eines sicheren und korrekten Funktionierens und damit im Sinne des Endverbrauchers als auch der Entwickler ist. Was ich nicht verstehen kann, wenn Leute nur sagen "systemd ist mist ich will wieder das alte SysV-Init, weil ich mit systemd nicht umgehen kann." Deswegen möchte ich hier sagen:''
 
"''Bitte ich gebe euch Gelegenheit, euch zu informieren. Und ich hoffe dies halbwegs richtig zu machen.''"
---------

=Fähigkeiten=
Als Verwaltungsinstrument bringt systemd einige Neuerungen und Verbesserungen, setzt dabei allerdings auch stark auf alt bewährtes. Um nur einiges an Neuerungen und Fähigkeiten zu nennen:

* Fähigkeit zur aggressiven Parallelisierung
* Nutzt Socket und [[https://en.wikipedia.org/wiki/D-Bus D-Bus]] Aktivierung um Prozesse zu starten
* Bietet ein "auf Bedarf"-basiertes starten von Diensten
* Überwacht Prozesse die [[https://en.wikipedia.org/wiki/Cgroups cgroups]] verwenden
* unterstützt [[https://de.opensuse.org/SDB:Snapper Schnappschüsse]] und deren Wiederherstellung
* Verwaltet [[Zugriffsrechte#mount|mount und automount]] Einhängepunkte
* Implementiert abhängigkeitsbasierte Logik für Dienste
* Kann SysV-Init als drop-in ersetzen.
* uvm.
{{Hinweis|Mit Parallelisierung ist das Resultat dieser Prinzipien: [https://de.wikipedia.org/wiki/Nebenläufigkeit Nebenläufigkeit] bzw. [https://de.wikipedia.org/wiki/Parallele_Programmierung Parallele Programmierung] gemeint. Die wörter [https://de.wikipedia.org/wiki/Bedarf Bedarf] und [[Systemd#Abhängigkeit_darstellen:|Abhängigkeit]] müssen in der Auflistung differenziert werden.}}
 

=systemd Steuern=
Es gibt verschiedene Wege, wie systemd gesteuert werden kann. Einmal gibt es grafische Tools, wie die [[YaST2_Dienste-Verwaltung|Dienste-Verwaltung]] in [[YaST]]. Das ehemals benannte Menü: "Runlevel-Editor" nennt sich heute bei Migration zu systemd "Dienste-Verwaltung". Dann gibt es noch die Möglichkeit mit der [[Shell]]. Eine vollständige auflistung der Steuerungsmöglichkeiten, würde den Rahmen dieser Doku total sprengen. Ich nenne hier einige aus Nutzersicht durchaus wichtige Möglichkeiten:

{| class="wikitable"
|+Mitgelieferte Tools:
|-
|'''[[#Umgang_mit_systemctl|systemctl]]'''
|''(Den System- und Dienstmanager steuern.)''
|-
|'''[[#Umgang_mit_journalctl|journalctl]]'''
|''(Das systemd journal abfragen. Also logs.)''
|-
|'''[[#Tipp: systemd-tmpfiles|systemd-tmpfiles]]'''
|''(Erstellt und löscht temporäre Strukturen.)''
|-
|'''[[#Umgang_mit_systemd-analyze|systemd-analyze]]'''
|''(Analysiert die boot Geschwindigkeit.)''
|-
|'''[[#Umgang_mit_loginctl|loginctl]]'''
|''(Anbindung an die Sitzungsverwaltung)''
|-
|'''.. uvm.'''
|''(Alle die ich nicht nennen konnte)''
|-
|}

=Umgang mit systemctl=
Bitte zum detaillierten Umgang mit systemctl die [[Man_pages|manpage]] lesen. Oder beispielsweise im (Achtung externer Link): [https://www.suse.com/documentation/sles-12/book_sle_admin/data/sec_boot_systemd_basics.html Adminguide] nachschlagen.
<pre style="background-color: #FFFFC0">man systemctl</pre>
Nachfolgend einige einfache Befehle, die empfehlungsweise bekannt sein sollten.

==Dienste Starten und Beenden==
'''Starten'''
<pre style="background-color: #FFFFC0">systemctl start mein_dienst</pre>
'''Beenden'''
<pre style="background-color: #FFFFC0">systemctl stop mein_dienst</pre>

==Automatischen Start De-/Aktivieren==
'''Automatischen Start aktivieren:'''
<pre style="background-color: #FFFFC0">systemctl enable mein_dienst</pre>
'''Automatischen Start deaktivieren:'''
<pre style="background-color: #FFFFC0">systemctl disable mein_dienst</pre>

==Status eines Dienstes abfragen==
<pre style="background-color: #FFFFC0">systemctl status mein_dienst</pre>
In der Ausgabe würde das bei einem erfolgreich gestarteten und für den automatischen Start konfigurierten Dienst in etwa so aussehen:
<blockquote><pre style="background-color: #D4FFEF; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">
mein_dienst.service - mein_dienst Daemon
Loaded: loaded (/usr/lib/systemd/system/mein_dienst.service; enabled)
Active: active (running) since Sa 2015-08-22 02:17:01 CEST; 1s ago
Process: 6717 ExecStartPre=/usr/sbin/mein_dienst (code=exited, status=0/SUCCESS)
Main PID: 6721 (mein_dienst)
</pre></blockquote>

==systemd neu laden==
Angenommen, es wurden beispielsweise Änderungen an mein_dienst.service Dateien vorgenommen, muss systemd neu geladen werden, damit sie sofort wirksam werden.
<pre style="background-color: #FFFFC0">systemctl daemon-reload</pre>

=Wo sind meine Logs hin?=
{{Hinweis|'''Umsteigern von SysV-Init auf systemd empfehle ich zum Thema Log´s dies:'''}}
<pre style="background-color: #FFFFC0">less /var/log/README</pre>
'''Darin steht in etwa (versuchsweise frei übersetzt):''' 
<blockquote><pre style="background-color: #D4FFEF; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">
Sie suchen die traditionellen text log Dateien in /var/log, und diese sind verschwunden?

Hier eine erklärung, was vor sich geht:

Sie betreiben ein systemd basiertes BS in dem syslog durch das Journal ersetzt wurde. Das Journal speichert die selben (und mehr) Informationen wie das klassische syslog. Um das Journal zu nutzen und auf die Logdaten zuzugreifen, führen Sie einfach "journalctl" aus, welches die Logdaten in dem identischen textbasierten Format ausgeben wird, wie es auch mit syslog der Fall war. Für weitere Details, sehen Sie bitte journalctl(1) ein.
...
Thank you!
</pre></blockquote>
Das heisst, es bietet sich hier die Gelegenheit mit dem neuen Journal vertraut zu werden.
In folgenden Abschnitten möchte ich deswegen eine kurze Einleitung zum Umgang anbieten.

=Umgang mit journalctl=
Der Dienst systemd beinhaltet seinen eigenen Dienst zur Systemprotokollierung. Die Sammlung all dieser Informationen wird als journal bezeichnet. Diese Instanz sammelt wichtige Informationen und stellt diese wiederum zur Abfrage bereit. Das ist insbesondere zur Systemüberwachung von Nutzen. Es kann beispielsweise mit Hilfe von journalctl ein fehlerhafter Systemstart diagnostiziert werden. Angenommen dies wäre der Fall, so wird spätestens an dieser Stelle ein gewisses Grundwissen zum Umgang mit journalctl erforderlich, wenn es darum geht konkrete Fehlermeldungen bereitzustellen.
{{Hinweis|'''Generell erfolgt die Ansicht der Protokolle automatisch in einem Pager.'''}}
==Das journal betrachten:==
<pre style="background-color: #FFFFC0">journalctl</pre>
Wenn einfach nur 'journalctl' ausgeführt wird, zeigt ein pager das komplette journal, beginnend mit dem ältesten Eintrag.

==Nützliche Schalter==
Es gibt viele weitere wichtige Filter. Hier einige wenige, die bekannt sein sollten:
{| class="wikitable"
|+Schalter
|-
|"-k"
|dmesg betrachten
|-
|"-b"
|Bootvorgänge
|-
|"-u"
|Nach Unit bzw. Dienst
|-
|"-f"
|aktualisiert den Pager mit neuen Einträgen
|}
Für mehr Details bitte die [[Man_pages|manpage]] lesen.

==Das Startprotokoll==
<pre style="background-color: #FFFFC0">journalctl -b</pre>
Der Schalter '-b' sagt journalctl, dass das gesamte Startprotokoll gezeigt werden soll.

===Das Startprotokoll filtern===
Angenommen, es möchte nur ein bestimmtes Startprotokoll eingesehen werden. Etwa vom vorhergehenden Systemstart:
<pre style="background-color: #FFFFC0">journalctl --list-boots</pre>
(Gibt eine Liste vorangegangener Protokolle in einer Übersicht aus). Die erste Spalte kann als Indikator herangezogen werden. Beispielausgabe:
<blockquote><pre style="background-color: #D4FFEF; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"> ..
...
-2 9daa81e2ec374cb1b6adba8d96896605 Sa 2015-08-29 23:26:53 CEST—Sa 2015-08-29 23:49:17 CEST
-1 c430ed034607494ba2a3bc1ded4e4972 Sa 2015-08-29 23:49:35 CEST—Sa 2015-08-29 23:54:27 CEST
0 1f3a7894d0f34f4392c5517b83279c4d Sa 2015-08-29 23:54:53 CEST—So 2015-08-30 16:22:40 CEST</pre></blockquote>
Das gewünschte Startprotokoll wird durch Übergabe des jeweiligen Indikator im Pager dargestellt:
<pre style="background-color: #FFFFC0">journalctl -b -1</pre>

===journalctl -xb===
Wenn der Computer beispielsweise aufgrund eines Stromausfall im Emergency Mode startet, wird in der Shell statt dem grafischen Modus ein Login angeboten. Hier schlägt der Rechner oft vor, es solle die Ausgabe von 'journalctl -xb' zu Rate gezogen werden. Also das Startprotokoll prüfen:
<pre style="background-color: #FFFFC0">journalctl -xb</pre>
{| class="wikitable"
|+ Schalter
|-
|"-x"
|Blendet nützliche Hilfetexte in der Ausgabe ein.
|-
|"-b"
|Das Bootprotokoll anzeigen.
|-
|}

==journalctl -xn==
Duch den Schalter -n kann man die Ausgabe auf eine bestimmte Anzahl Zeilen beschränken. Wenn keine Zahl übergeben wird, werden die letzten 10 Zeilen ausgegeben. Beispielsweise die letzten 25 Zeilen ausgeben und Hilfstexte einblenden:
<pre style="background-color: #FFFFC0">journalctl -xn 25</pre>
{| class="wikitable"
|+ Schalter
|-
|"-x"
|Blendet nützliche Hilfetexte in der Ausgabe ein.
|-
|"-n"
|Ausgabe auf bestimmte Zeilenanzahl beschränken.
|-
|}

==Filtern nach Unit==
Angenommen es sollen nur Logeinträge zum Unit oder Dienst "sshd" in der Ausgabe angezeigt werden.
<pre style="background-color: #FFFFC0">journalctl -u sshd</pre>

==Eigener Filter==
Die Ausgabe von journalctl kann auch umgeleitet werden. So wird im folgenden Beispiel das ganze Systemprotokoll unter zuhilfenahme von 'egrep' nach Vorkommnissen von "Error" und "Failed" durchsucht. Die Ausgabe wird dann an einen Pager (less) umgeleitet:
<pre style="background-color: #FFFFC0">journalctl | egrep "Error|Failed" | less</pre>

==Speicherplatzbelegung==
Jedes Log wird für eine gewisse Dauer aufbewahrt. Das ist besonders für Systemadministratoren von besonderer Bedeutung, da Computer oft über einen längeren Zeitraum überwacht werden müssen. Einige Daten werden also permanent auf der Festplatte abgelegt. Von Haus aus sind seitens systemd für diese Informationen 10 Prozent des betroffenen Dateisystems vorgesehen. Bei einem Dateisystem mit 1 TiB Speicherplatz wären dies also 100 GiB logdaten, die von systemd angesammelt würden. Das Journal wird allerdings auch noch komprimiert.
{| class="wikitable"
|+Schalter für journalctl
|-
|"--disk-usage"
|Speicherplatzbelegung des Journal auf dem Datenträger zeigen.
|}
Wer auf die voreingestellten Limits und den dafür vorgesehenen Speicherplatz Einfluss haben möchte, kann dies in der Konfigurationsdatei tun:
<blockquote><pre style="background-color: #D4FFEF">/etc/systemd/journald.conf</pre></blockquote>
So liesse sich beispielsweise mit diesem Schalter das Journal auf eine Größe von 100M beschränken. Ich fände auch einen Wert bis 300M noch sinnvoll wieviel hier eingestellt wird, liegt an der eigenen Nutzenvorstellung:
<pre style="background-color: #FFFFC0">SystemMaxUse=100M</pre>
Zum Verständnis der Grössenrelation: [[Megabyte |Megabyte/Mibibyte]] 
Und Achtung externer Link: https://de.wikipedia.org/wiki/Datenmenge
{{Hinweis|'''Die Daten werden im Journal in anderer Form und komprimiert abgelegt. Dennoch, um eine Vorstellung zu haben: Eine Textdatei gefüllt mit Rautezeichen, die ein A4 Brief ausfüllen würden, hat ca. 4,1 KiB. Eine Ansammlung von 100 GiB mit solchen Dateien entspräche in etwa 261 888 249 Dokumente oder Seiten. Eine Packung Schreibmaschinenpapier hat ca 100 Blatt.'''}}
 

=Umgang mit systemd-analyze=
Der Befehl systemd-analyze kann dazu genutzt werden, die Leistung eines Systemstarts zu messen. Beispielsweise wie lange es dauert, bis ein bestimmtes festgelegtes Ziel beim Boot erreicht wurde. Ich möchte hier nur Kleinigkeiten zeigen, damit Verständnis erlangt werden kann, was denn bei einem Systemstart von gerade mal 20 Sekunden so alles abgeht. Auch hier bitte ich darum, zu Details wieder die manpage heranzuziehen.

==Startzeitanalyse==
<blockquote>'''Einfach ohne Zusätzliche Schalter:'''
<pre style="background-color: #FFFFC0">systemd-analyze</pre>
'''Beispielausgabe:'''
<blockquote><pre style="background-color: #D4FFEF; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Startup finished in 1.433s (kernel) + 493ms (initrd) + 17.842s (userspace) = 19.769s</pre></blockquote>
Die Ausgabe sollte weitestgehend selbsterklärend sein. Angegebene Messwerte sind an diesem Beispiel in Sekunden und Millisekunden.
</blockquote>

==Messung grafisch darstellen==
Es kann eine SVG Grafik als sog. "plot" erstellt werden, der in Details aufzeigt welche Systemdienste zu welcher Zeit gestartet wurden. Dabei wird visuell hervorgehoben, wie viel Zeit alle Dienste zur Initialisierung benötigten. 
-----
==='''Startzeiten aller Prozesse:'''===
<blockquote>{{Hinweis|'''Ich leite Die Ausgabe gleich in eine Datei um und öffne diese mit "gwenview":'''}}
<pre style="background-color: #FFFFC0; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">systemd-analyze plot > /tmp/plot.svg | gwenview /tmp/plot.svg</pre>
{{Achtung|Die SVG Datei ist zwar - nur - ca. 140k groß, das darstellen dieser Grafik kann aber sehr aufwendig für den Computer sein. Nachfolgend nur ein kleiner Ausschnitt aus so einer Grafik als GIF.}}
[[Bild:systemd-analyze_plot.gif|center|'''Plot als Grafik''']]
Hier kann man sehr schön sehen, was systemd beim Startvorgang so alles anstellen muss. Und was denn eigentlich so alles in diesen 20 Sekunden passiert bis am Beispielsystem ein vollständiger Systemstart abgeschlossen ist. </blockquote>
--------
==='''Abhängigkeit darstellen:''' ===
<blockquote>Wer das interessant fand, möchte eventuell die Möglichkeit nutzen sich grafisch darstellen zu lassen in welchen Abhängigkeiten ein Dienst gestartet wurde.
{{Hinweis|'''Ich leite Die Ausgabe am Beispiel "avahi-daemon" gleich in eine Datei um und öffne diese mit "gwenview":'''}}

<pre style="background-color: #FFFFC0; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">systemd-analyze dot 'avahi-daemon.*' | dot -Tsvg > /tmp/avahi.svg | gwenview /tmp/avahi.svg</pre>{{Achtung|'''Das ist ein Einzeiler!'''}}
Das Ergebnis präsentiert sich dann so (zu .gif umgewandelt):
[[Bild:Systemd-analyze_avahi.gif|center|'''Prozessabhängigkeit als Grafik''']]
</blockquote>
 

=Umgang mit loginctl=
Als wichtiger Systemdienst bindet sich systemd auch an den Anmeldevorgang im Betriebssystem. Dafür stellt er einen extra Dienst "systemd-login" zur Verfügung. Der Dienst bietet an dieser Stelle ein Anbindung an die D-Bus Schnittstelle. Wichtige Grundlagen betreffend Zugriffsberechtigungen: [[Zugriffsrechte]]

Das Tool loginctl kann dazu verwendet werden, Einblicke in den Status von Benutzeranmeldungen zu erlangen. Ausserdem kann es verwendet werden Veränderungen am Systemstatus vorzunehmen.

So können [[https://de.wikipedia.org/wiki/Portable_Operating_System_Interface POSIX]] kompatible Signale an Benutzersitzungen gesendet werden, wie beispielsweise [[https://de.wikipedia.org/wiki/SIGTERM SIGTERM]]. Das ist ein Signal zum Terminieren von Programmprozessen.
{{Warnung|'''Dieses Werkzeug sollte nur von erfahrenen Benutzern verwendet werden.'''}}
'''Hier nur ein ganz einfaches ungefährliches Anwendungsbeispiel:'''
<pre style="background-color: #FFFFC0">loginctl</pre>
'''Listet laufende Benutzersitzungen:'''
<blockquote><pre style="background-color: #D4FFEF"> SESSION UID USER SEAT
1 1000 user seat0</pre></blockquote>
 

=systemd-tmpfiles=
'''Grundlegendes:''' 
Der Dienst systemd-tmpfiles ist im System für die Verwaltung temporärer Dateisystemstrukturen zuständig. Er erstellt und löscht diese kann sie aber auch bereinigen. ..usw. Einige dieser Strukturen bestehen bei einem Linux Betriebssystem als persistenter bzw. weniger persistenter Ablagebereich. Gedacht ist das für Dateien, die entweder vorübergehend bzw. begrenzt oder längerfristig vorhanden sein müssen.

'''Interessant und erwähnenswert an dieser Stelle:''' 
Systemd hängt einige Dateisystemstrukturen automatisch als "tmpfs" ein. Dazu gehört beispielsweise auch der Pfad "/tmp". Wie dies geschieht, kann anhand des betreffenden tmp.mount units eingesehen werden. Aus dem Inhalt ergibt sich:
<blockquote><pre style="background-color: #D4FFEF; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">[Mount]
What=tmpfs
Where=/tmp
Type=tmpfs
Options=mode=1777,strictatime</pre></blockquote>
'''Ein zu SysV-Init zeiten nötiger [[fstab|fstab Eintrag]] hätte so ausgesehen:'''
<blockquote><pre style="background-color: #D4FFEF; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">tmpfs /tmp tmpfs defaults,strictatime,mode=1777 0 0</pre></blockquote>
<blockquote>
{{Hinweis|'''Der Pfad '/var/tmp/' wird hingegen beispielsweise nicht als tmpfs eingehängt. Ist dafür auch nicht bestimmt.'''}}
</blockquote>

{{Achtung|'''Der Tipp dazu: [[Tipp: systemd-tmpfiles]]'''}}
 

=Tipp: weekly trim durch systemd=
Das Paket 'util-linux-systemd' bringt einen Dienst mit, der es ermöglicht seine SSD wöchentlich trimmen zu lassen. Es gibt zu beachten, dass trim auf unterschiedlichem Weg im Betriebssystem zur [[SSD_Optimierungen|Optimierung von SSD's]] realisiert werden kann:
{| class="wikitable"
|+ Trim
|-
|Online discard (trim)
|moutoption "discard"
|Ersetzt batched trim und Skripte sowie manuelle Ausführung.
|-
|Manuell
|Durch ausführen des 'fstrim' Kommando in der Shell.
|[[http://man7.org/linux/man-pages/man8/fstrim.8.html man fstrim]]
|-
|rowspan="3"|Batched trim bzw. Mitgelieferte Skripte
|(eigener Skript) Bsp.: [[http://linux-club.de/wiki/opensuse/Batched-trim.sh ext4-trim.sh]]
|[[http://man7.org/linux/man-pages/man8/fstrim.8.html man fstrim]]
|-
|openSUSE bringt beispielsweise für [[https://de.wikipedia.org/wiki/Btrfs btrfs]] einen durch sysconfig steuerbaren trim Skript mit. ('btrfs-trim.sh');
|Funktioniert zum Stand von openSUSE 13.2 nur beim Einsatz von [[https://de.wikipedia.org/wiki/Btrfs btrfs]].
|-
|systemd bringt diese Möglichkeit als Dienst oder unit. ('fstrim.timer') - ('fstrim.service')
|Keine Einschränkung durch "automatik". "fstrim -a" beispielsweise bei ext4.
|-
|}
Wichtig ist zu beachten dass diese Kommandos nicht unnötig mehrfach ausgeführt werden oder vermischt zum Einsatz kommen. Einmal die Woche sollte bei batched trim völlig ausreichend sein. Wenn also die in openSUSE integrierte Trimfunktion nicht genutzt werden möchte, kann diese durch die von systemd durchaus ersetzt werden. Wenn beispielsweise Online discard verwendet wird, werden andere Skripte obsolet.
{{Achtung|'''Ich möchte hier nochmal darauf hinweisen, dass andere Skripte bei Nutzung von systemd zu diesem Zweck deaktiviert werden sollten! Und bei der mount option discard wird batched trim obsolet.'''}}
'''Folgendes genügt zum aktivieren der systemd variante:'''
<pre style="background-color: #FFFFC0">systemctl enable fstrim.timer</pre>
(''Der zugehörige fstrim.service wird vom Timer automatisch zur Ausführung aktiviert.'')
{{Hinweis|'''Es wird eine Datei mit einem Zeitstempel erstellt anhand dessen die letzte und nächste Ausführung nach dem ersten Aufruf abgehandelt wird.'''}}
'''Der eigentliche Dienst heisst:'''
<blockquote><pre style="background-color: #D4FFEF">fstrim.service</pre></blockquote>
'''Eine Steuerungsmöglichkeit hierfür ist auch:'''
<pre style="background-color: #FFFFC0">rcfstrim</pre>
'''Der Stempel befindet sich dann hier:'''
<blockquote><pre style="background-color: #D4FFEF">/usr/lib/systemd/system/fstrim.timer</pre></blockquote>
'''Der Dienst führt zurzeit wöchentlich folgendes Kommando aus:''' 
''Dies behandelt schlicht und automatisch alle eingehängten Dateisysteme mit trim.''
<pre style="background-color: #FFFFC0">fstrim -a</pre>
{{Warnung|'''Nicht jede SSD und SATA controller unterstützen jede TRIM Funktionalität. D.h. einige Geräte sind auf batched-discard angewiesen. Einige können mit Online-discard arbeiten, andere nicht. Einige haben wiederum Schwierigkeiten bei trim in Verbindung mit NCQ.'''}}
{{Hinweis|'''Es bietet sich auch an, dieses unit manuell durch einen eigenen Skript aufzurüsten.'''}}

 

=Quellen / Links:=
* https://www.suse.com/releasenotes/x86_64/SUSE-SLES/12/
* http://www.freedesktop.org/wiki/Software/systemd/
* https://www.suse.com/documentation/sles-12/book_sle_admin/data/cha_systemd.html
* https://de.wikipedia.org
* http://man7.org/
*[https://fedoraproject.org/wiki/Systemd fedoraproject.org wiki] {{englisch}}
*[http://cre.fm/cre209-das-linux-system CRE209 Das Linux System - systemd leitet die neue Generation der Linux Systemarchitektur ein] Tim Pritlove im Gespräch mit Lennart Poetering (Veröffentlicht am 10. November 2015)

[[Kategorie:Bootmanager‏‎]] [[Kategorie:systemd]]

Systemd

2015-11-20T19:21:03Z

Gehrke: /* Kompatibilität */ externe Verlinkung korrigiert

{{Review|Kompletter Artikel}}
{{Achtung|'''Aus technischen Gründen ist es leider nicht Möglich der korrekten Schreibweise von "systemd" in der Überschrift dieses Artikels gerecht zu werden.'''}}

= Was ist systemd? =
Systemd ist ein Dienst oder Daemon und bietet einige grundlegende Werkzeuge für Linux Systeme. Er wird zur System- und Diensteverwaltung eingesetzt. Er läuft mit [[https://de.wikipedia.org/wiki/Process_identifier PID1]] und startet dann alle weiteren Prozesse des Betriebssystems. Des weiteren wird er als freie Software unter der [[LGPL |LGPL 2.1+]] veröffentlicht und wurde in [[Programmierung|C geschrieben]].

* http://www.freedesktop.org/wiki/Software/systemd/

''Er startet also als erstes ([[https://de.wikipedia.org/wiki/Process_identifier PID1]]), regelt und steuert dabei alle weiteren Dienste. Er beendet sich beim Herunterfahren als letztes. Der daemon systemd ist damit also tief im Ablauf eines Systemstarts verwurzelt.''

'''Wichtiges dazu:'''
* [[Bootmanager]]
* [[Bootvorgang]]
* [[YaST2_Dienste-Verwaltung|YaST2 Dienste-Verwaltung]]
 

= SUSE wechsel zu systemd =
Mit unter liebevoll vollzieht sich der Wechsel zu systemd als Init-System in SUSE mit Sätzen, zitert aus den Releasenotes und dem Adminguide zu [[https://www.suse.com/ SUSE Linux Enterprise Server 12]], wie:
<blockquote><pre style="background-color: #D4FFEF; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">New core technologies like systemd (replacing the time honored System V based init process) </pre></blockquote>
'''Versuchsweise frei übersetzt:''' ''Neue Kerntechnologien wie systemd (ersetzen den durch lange Dienstzeit geehrten System V basierten init prozess).''
<blockquote><pre style="background-color: #D4FFEF; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Starting with SUSE Linux Enterprise Server 12 systemd is a replacement for the popular System V init daemon. systemd is fully compatible with System V init (by supporting init scripts). </pre></blockquote>
'''Versuchsweise frei übersetzt:''' ''Beginnend mit [[https://www.suse.com/ SUSE Linux Enterprise Server 12]] ist systemd ein Ersatz für den populären System V init daemon. Er ist voll kompatibel mit dem System V Init-Vorgang, indem er Init Skripte unterstützt.''

= Integration in [[YaST]] =
{|
|rowspan=2|[[Bild:Yast.png]]
|colspan=3|Wie sich systemd im grafischen Konfigurationstool für [[openSUSE]] integriert, könnt ihr hier sehen:
|-
|style="text-align:center;"| ---------->
|style="text-align:center;"|[[YaST2_Dienste-Verwaltung|YaST2: Diensteverwaltung]]
|style="text-align:center;"| <----------
|-
|}

=Kompatibilität=
Als sogenanntes "drop-in replacement". Bietet systemd Kompatibilität zu seinen Vorgängern:
 
* kompatibel mit [https://de.wikipedia.org/wiki/Linux_Standard_Base LSB] init Skripten
* kompatibel mit SysV
Hier gibt es zu beachten, dass systemd nicht vollständig rückwärts kompatibel ist.
Einige Einschränkungen können hier nachgelesen werden: http://www.freedesktop.org/wiki/Software/systemd/Incompatibilities/

=Kritik=
Da ich nicht unnötig falsches sagen möchte, was Kritik gegenüber systemd angeht. Und da ich nur einige Grundlagen objektiv darstellen will, kann ich dazu nicht viel sagen. Allerdings kann ich folgendes berichten:
* Bei Linux Entwicklern als auch Benutzern steht systemd im Mittelpunkt der Kritik, da es im Ansatz sehr wichtige Kernfunktionen steuert und auch das alt eingefahrene SysV-Init ersetzen kann, bzw. kompatibel ist.
* Zu diesem Thema gibt es massenweise Informationen im Internet.
'''Ein besonders wichtiger Punkt:'''
* Es gibt viele Gegner als auch Befürworter.
 
{{Hinweis|'''Wer möchte informiert sich darüber bitte detaillierter mithilfe einer Suchmaschine eigener Wahl.'''}}
{{Hinweis|'''Das Forum würde sich hierfür als Diskussionsplatform anbieten, wer möchte. Es gibt sicher einige die an dieser Thematik interesse haben. http://forum.linux-club.de/'''}} 
---------
'''Meine Meinung zur Kritik:''' 
(Wer mir diesen Raum nicht lassen möchte: Bitte "skipping").
 
''Ich finde es wichtig, dass derart grundlegende Kernstrukturen im Betriebssystem kritisiert werden, solange es zielführend und im Sinne eines sicheren und korrekten Funktionierens und damit im Sinne des Endverbrauchers als auch der Entwickler ist. Was ich nicht verstehen kann, wenn Leute nur sagen "systemd ist mist ich will wieder das alte SysV-Init, weil ich mit systemd nicht umgehen kann." Deswegen möchte ich hier sagen:''
 
"''Bitte ich gebe euch Gelegenheit, euch zu informieren. Und ich hoffe dies halbwegs richtig zu machen.''"
---------

=Fähigkeiten=
Als Verwaltungsinstrument bringt systemd einige Neuerungen und Verbesserungen, setzt dabei allerdings auch stark auf alt bewährtes. Um nur einiges an Neuerungen und Fähigkeiten zu nennen:

* Fähigkeit zur aggressiven Parallelisierung
* Nutzt Socket und [[https://en.wikipedia.org/wiki/D-Bus D-Bus]] Aktivierung um Prozesse zu starten
* Bietet ein "auf Bedarf"-basiertes starten von Diensten
* Überwacht Prozesse die [[https://en.wikipedia.org/wiki/Cgroups cgroups]] verwenden
* unterstützt [[https://de.opensuse.org/SDB:Snapper Schnappschüsse]] und deren Wiederherstellung
* Verwaltet [[Zugriffsrechte#mount|mount und automount]] Einhängepunkte
* Implementiert abhängigkeitsbasierte Logik für Dienste
* Kann SysV-Init als drop-in ersetzen.
* uvm.
{{Hinweis|Mit Parallelisierung ist das Resultat dieser Prinzipien: [[https://de.wikipedia.org/wiki/Nebenläufigkeit Nebenläufigkeit]] bzw. [[https://de.wikipedia.org/wiki/Parallele_Programmierung Parallele Programmierung]] gemeint. Die wörter [[https://de.wikipedia.org/wiki/Bedarf Bedarf]] und [[Systemd#Abhängigkeit_darstellen:|Abhängigkeit]] müssen in der Auflistung differenziert werden.}}
 

=systemd Steuern=
Es gibt verschiedene Wege, wie systemd gesteuert werden kann. Einmal gibt es grafische Tools, wie die [[YaST2_Dienste-Verwaltung|Dienste-Verwaltung]] in [[YaST]]. Das ehemals benannte Menü: "Runlevel-Editor" nennt sich heute bei Migration zu systemd "Dienste-Verwaltung". Dann gibt es noch die Möglichkeit mit der [[Shell]]. Eine vollständige auflistung der Steuerungsmöglichkeiten, würde den Rahmen dieser Doku total sprengen. Ich nenne hier einige aus Nutzersicht durchaus wichtige Möglichkeiten:

{| class="wikitable"
|+Mitgelieferte Tools:
|-
|'''[[#Umgang_mit_systemctl|systemctl]]'''
|''(Den System- und Dienstmanager steuern.)''
|-
|'''[[#Umgang_mit_journalctl|journalctl]]'''
|''(Das systemd journal abfragen. Also logs.)''
|-
|'''[[#Tipp: systemd-tmpfiles|systemd-tmpfiles]]'''
|''(Erstellt und löscht temporäre Strukturen.)''
|-
|'''[[#Umgang_mit_systemd-analyze|systemd-analyze]]'''
|''(Analysiert die boot Geschwindigkeit.)''
|-
|'''[[#Umgang_mit_loginctl|loginctl]]'''
|''(Anbindung an die Sitzungsverwaltung)''
|-
|'''.. uvm.'''
|''(Alle die ich nicht nennen konnte)''
|-
|}

=Umgang mit systemctl=
Bitte zum detaillierten Umgang mit systemctl die [[Man_pages|manpage]] lesen. Oder beispielsweise im (Achtung externer Link): [https://www.suse.com/documentation/sles-12/book_sle_admin/data/sec_boot_systemd_basics.html Adminguide] nachschlagen.
<pre style="background-color: #FFFFC0">man systemctl</pre>
Nachfolgend einige einfache Befehle, die empfehlungsweise bekannt sein sollten.

==Dienste Starten und Beenden==
'''Starten'''
<pre style="background-color: #FFFFC0">systemctl start mein_dienst</pre>
'''Beenden'''
<pre style="background-color: #FFFFC0">systemctl stop mein_dienst</pre>

==Automatischen Start De-/Aktivieren==
'''Automatischen Start aktivieren:'''
<pre style="background-color: #FFFFC0">systemctl enable mein_dienst</pre>
'''Automatischen Start deaktivieren:'''
<pre style="background-color: #FFFFC0">systemctl disable mein_dienst</pre>

==Status eines Dienstes abfragen==
<pre style="background-color: #FFFFC0">systemctl status mein_dienst</pre>
In der Ausgabe würde das bei einem erfolgreich gestarteten und für den automatischen Start konfigurierten Dienst in etwa so aussehen:
<blockquote><pre style="background-color: #D4FFEF; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">
mein_dienst.service - mein_dienst Daemon
Loaded: loaded (/usr/lib/systemd/system/mein_dienst.service; enabled)
Active: active (running) since Sa 2015-08-22 02:17:01 CEST; 1s ago
Process: 6717 ExecStartPre=/usr/sbin/mein_dienst (code=exited, status=0/SUCCESS)
Main PID: 6721 (mein_dienst)
</pre></blockquote>

==systemd neu laden==
Angenommen, es wurden beispielsweise Änderungen an mein_dienst.service Dateien vorgenommen, muss systemd neu geladen werden, damit sie sofort wirksam werden.
<pre style="background-color: #FFFFC0">systemctl daemon-reload</pre>

=Wo sind meine Logs hin?=
{{Hinweis|'''Umsteigern von SysV-Init auf systemd empfehle ich zum Thema Log´s dies:'''}}
<pre style="background-color: #FFFFC0">less /var/log/README</pre>
'''Darin steht in etwa (versuchsweise frei übersetzt):''' 
<blockquote><pre style="background-color: #D4FFEF; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">
Sie suchen die traditionellen text log Dateien in /var/log, und diese sind verschwunden?

Hier eine erklärung, was vor sich geht:

Sie betreiben ein systemd basiertes BS in dem syslog durch das Journal ersetzt wurde. Das Journal speichert die selben (und mehr) Informationen wie das klassische syslog. Um das Journal zu nutzen und auf die Logdaten zuzugreifen, führen Sie einfach "journalctl" aus, welches die Logdaten in dem identischen textbasierten Format ausgeben wird, wie es auch mit syslog der Fall war. Für weitere Details, sehen Sie bitte journalctl(1) ein.
...
Thank you!
</pre></blockquote>
Das heisst, es bietet sich hier die Gelegenheit mit dem neuen Journal vertraut zu werden.
In folgenden Abschnitten möchte ich deswegen eine kurze Einleitung zum Umgang anbieten.

=Umgang mit journalctl=
Der Dienst systemd beinhaltet seinen eigenen Dienst zur Systemprotokollierung. Die Sammlung all dieser Informationen wird als journal bezeichnet. Diese Instanz sammelt wichtige Informationen und stellt diese wiederum zur Abfrage bereit. Das ist insbesondere zur Systemüberwachung von Nutzen. Es kann beispielsweise mit Hilfe von journalctl ein fehlerhafter Systemstart diagnostiziert werden. Angenommen dies wäre der Fall, so wird spätestens an dieser Stelle ein gewisses Grundwissen zum Umgang mit journalctl erforderlich, wenn es darum geht konkrete Fehlermeldungen bereitzustellen.
{{Hinweis|'''Generell erfolgt die Ansicht der Protokolle automatisch in einem Pager.'''}}
==Das journal betrachten:==
<pre style="background-color: #FFFFC0">journalctl</pre>
Wenn einfach nur 'journalctl' ausgeführt wird, zeigt ein pager das komplette journal, beginnend mit dem ältesten Eintrag.

==Nützliche Schalter==
Es gibt viele weitere wichtige Filter. Hier einige wenige, die bekannt sein sollten:
{| class="wikitable"
|+Schalter
|-
|"-k"
|dmesg betrachten
|-
|"-b"
|Bootvorgänge
|-
|"-u"
|Nach Unit bzw. Dienst
|-
|"-f"
|aktualisiert den Pager mit neuen Einträgen
|}
Für mehr Details bitte die [[Man_pages|manpage]] lesen.

==Das Startprotokoll==
<pre style="background-color: #FFFFC0">journalctl -b</pre>
Der Schalter '-b' sagt journalctl, dass das gesamte Startprotokoll gezeigt werden soll.

===Das Startprotokoll filtern===
Angenommen, es möchte nur ein bestimmtes Startprotokoll eingesehen werden. Etwa vom vorhergehenden Systemstart:
<pre style="background-color: #FFFFC0">journalctl --list-boots</pre>
(Gibt eine Liste vorangegangener Protokolle in einer Übersicht aus). Die erste Spalte kann als Indikator herangezogen werden. Beispielausgabe:
<blockquote><pre style="background-color: #D4FFEF; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"> ..
...
-2 9daa81e2ec374cb1b6adba8d96896605 Sa 2015-08-29 23:26:53 CEST—Sa 2015-08-29 23:49:17 CEST
-1 c430ed034607494ba2a3bc1ded4e4972 Sa 2015-08-29 23:49:35 CEST—Sa 2015-08-29 23:54:27 CEST
0 1f3a7894d0f34f4392c5517b83279c4d Sa 2015-08-29 23:54:53 CEST—So 2015-08-30 16:22:40 CEST</pre></blockquote>
Das gewünschte Startprotokoll wird durch Übergabe des jeweiligen Indikator im Pager dargestellt:
<pre style="background-color: #FFFFC0">journalctl -b -1</pre>

===journalctl -xb===
Wenn der Computer beispielsweise aufgrund eines Stromausfall im Emergency Mode startet, wird in der Shell statt dem grafischen Modus ein Login angeboten. Hier schlägt der Rechner oft vor, es solle die Ausgabe von 'journalctl -xb' zu Rate gezogen werden. Also das Startprotokoll prüfen:
<pre style="background-color: #FFFFC0">journalctl -xb</pre>
{| class="wikitable"
|+ Schalter
|-
|"-x"
|Blendet nützliche Hilfetexte in der Ausgabe ein.
|-
|"-b"
|Das Bootprotokoll anzeigen.
|-
|}

==journalctl -xn==
Duch den Schalter -n kann man die Ausgabe auf eine bestimmte Anzahl Zeilen beschränken. Wenn keine Zahl übergeben wird, werden die letzten 10 Zeilen ausgegeben. Beispielsweise die letzten 25 Zeilen ausgeben und Hilfstexte einblenden:
<pre style="background-color: #FFFFC0">journalctl -xn 25</pre>
{| class="wikitable"
|+ Schalter
|-
|"-x"
|Blendet nützliche Hilfetexte in der Ausgabe ein.
|-
|"-n"
|Ausgabe auf bestimmte Zeilenanzahl beschränken.
|-
|}

==Filtern nach Unit==
Angenommen es sollen nur Logeinträge zum Unit oder Dienst "sshd" in der Ausgabe angezeigt werden.
<pre style="background-color: #FFFFC0">journalctl -u sshd</pre>

==Eigener Filter==
Die Ausgabe von journalctl kann auch umgeleitet werden. So wird im folgenden Beispiel das ganze Systemprotokoll unter zuhilfenahme von 'egrep' nach Vorkommnissen von "Error" und "Failed" durchsucht. Die Ausgabe wird dann an einen Pager (less) umgeleitet:
<pre style="background-color: #FFFFC0">journalctl | egrep "Error|Failed" | less</pre>

==Speicherplatzbelegung==
Jedes Log wird für eine gewisse Dauer aufbewahrt. Das ist besonders für Systemadministratoren von besonderer Bedeutung, da Computer oft über einen längeren Zeitraum überwacht werden müssen. Einige Daten werden also permanent auf der Festplatte abgelegt. Von Haus aus sind seitens systemd für diese Informationen 10 Prozent des betroffenen Dateisystems vorgesehen. Bei einem Dateisystem mit 1 TiB Speicherplatz wären dies also 100 GiB logdaten, die von systemd angesammelt würden. Das Journal wird allerdings auch noch komprimiert.
{| class="wikitable"
|+Schalter für journalctl
|-
|"--disk-usage"
|Speicherplatzbelegung des Journal auf dem Datenträger zeigen.
|}
Wer auf die voreingestellten Limits und den dafür vorgesehenen Speicherplatz Einfluss haben möchte, kann dies in der Konfigurationsdatei tun:
<blockquote><pre style="background-color: #D4FFEF">/etc/systemd/journald.conf</pre></blockquote>
So liesse sich beispielsweise mit diesem Schalter das Journal auf eine Größe von 100M beschränken. Ich fände auch einen Wert bis 300M noch sinnvoll wieviel hier eingestellt wird, liegt an der eigenen Nutzenvorstellung:
<pre style="background-color: #FFFFC0">SystemMaxUse=100M</pre>
Zum Verständnis der Grössenrelation: [[Megabyte |Megabyte/Mibibyte]] 
Und Achtung externer Link: https://de.wikipedia.org/wiki/Datenmenge
{{Hinweis|'''Die Daten werden im Journal in anderer Form und komprimiert abgelegt. Dennoch, um eine Vorstellung zu haben: Eine Textdatei gefüllt mit Rautezeichen, die ein A4 Brief ausfüllen würden, hat ca. 4,1 KiB. Eine Ansammlung von 100 GiB mit solchen Dateien entspräche in etwa 261 888 249 Dokumente oder Seiten. Eine Packung Schreibmaschinenpapier hat ca 100 Blatt.'''}}
 

=Umgang mit systemd-analyze=
Der Befehl systemd-analyze kann dazu genutzt werden, die Leistung eines Systemstarts zu messen. Beispielsweise wie lange es dauert, bis ein bestimmtes festgelegtes Ziel beim Boot erreicht wurde. Ich möchte hier nur Kleinigkeiten zeigen, damit Verständnis erlangt werden kann, was denn bei einem Systemstart von gerade mal 20 Sekunden so alles abgeht. Auch hier bitte ich darum, zu Details wieder die manpage heranzuziehen.

==Startzeitanalyse==
<blockquote>'''Einfach ohne Zusätzliche Schalter:'''
<pre style="background-color: #FFFFC0">systemd-analyze</pre>
'''Beispielausgabe:'''
<blockquote><pre style="background-color: #D4FFEF; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Startup finished in 1.433s (kernel) + 493ms (initrd) + 17.842s (userspace) = 19.769s</pre></blockquote>
Die Ausgabe sollte weitestgehend selbsterklärend sein. Angegebene Messwerte sind an diesem Beispiel in Sekunden und Millisekunden.
</blockquote>

==Messung grafisch darstellen==
Es kann eine SVG Grafik als sog. "plot" erstellt werden, der in Details aufzeigt welche Systemdienste zu welcher Zeit gestartet wurden. Dabei wird visuell hervorgehoben, wie viel Zeit alle Dienste zur Initialisierung benötigten. 
-----
==='''Startzeiten aller Prozesse:'''===
<blockquote>{{Hinweis|'''Ich leite Die Ausgabe gleich in eine Datei um und öffne diese mit "gwenview":'''}}
<pre style="background-color: #FFFFC0; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">systemd-analyze plot > /tmp/plot.svg | gwenview /tmp/plot.svg</pre>
{{Achtung|Die SVG Datei ist zwar - nur - ca. 140k groß, das darstellen dieser Grafik kann aber sehr aufwendig für den Computer sein. Nachfolgend nur ein kleiner Ausschnitt aus so einer Grafik als GIF.}}
[[Bild:systemd-analyze_plot.gif|center|'''Plot als Grafik''']]
Hier kann man sehr schön sehen, was systemd beim Startvorgang so alles anstellen muss. Und was denn eigentlich so alles in diesen 20 Sekunden passiert bis am Beispielsystem ein vollständiger Systemstart abgeschlossen ist. </blockquote>
--------
==='''Abhängigkeit darstellen:''' ===
<blockquote>Wer das interessant fand, möchte eventuell die Möglichkeit nutzen sich grafisch darstellen zu lassen in welchen Abhängigkeiten ein Dienst gestartet wurde.
{{Hinweis|'''Ich leite Die Ausgabe am Beispiel "avahi-daemon" gleich in eine Datei um und öffne diese mit "gwenview":'''}}

<pre style="background-color: #FFFFC0; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">systemd-analyze dot 'avahi-daemon.*' | dot -Tsvg > /tmp/avahi.svg | gwenview /tmp/avahi.svg</pre>{{Achtung|'''Das ist ein Einzeiler!'''}}
Das Ergebnis präsentiert sich dann so (zu .gif umgewandelt):
[[Bild:Systemd-analyze_avahi.gif|center|'''Prozessabhängigkeit als Grafik''']]
</blockquote>
 

=Umgang mit loginctl=
Als wichtiger Systemdienst bindet sich systemd auch an den Anmeldevorgang im Betriebssystem. Dafür stellt er einen extra Dienst "systemd-login" zur Verfügung. Der Dienst bietet an dieser Stelle ein Anbindung an die D-Bus Schnittstelle. Wichtige Grundlagen betreffend Zugriffsberechtigungen: [[Zugriffsrechte]]

Das Tool loginctl kann dazu verwendet werden, Einblicke in den Status von Benutzeranmeldungen zu erlangen. Ausserdem kann es verwendet werden Veränderungen am Systemstatus vorzunehmen.

So können [[https://de.wikipedia.org/wiki/Portable_Operating_System_Interface POSIX]] kompatible Signale an Benutzersitzungen gesendet werden, wie beispielsweise [[https://de.wikipedia.org/wiki/SIGTERM SIGTERM]]. Das ist ein Signal zum Terminieren von Programmprozessen.
{{Warnung|'''Dieses Werkzeug sollte nur von erfahrenen Benutzern verwendet werden.'''}}
'''Hier nur ein ganz einfaches ungefährliches Anwendungsbeispiel:'''
<pre style="background-color: #FFFFC0">loginctl</pre>
'''Listet laufende Benutzersitzungen:'''
<blockquote><pre style="background-color: #D4FFEF"> SESSION UID USER SEAT
1 1000 user seat0</pre></blockquote>
 

=systemd-tmpfiles=
'''Grundlegendes:''' 
Der Dienst systemd-tmpfiles ist im System für die Verwaltung temporärer Dateisystemstrukturen zuständig. Er erstellt und löscht diese kann sie aber auch bereinigen. ..usw. Einige dieser Strukturen bestehen bei einem Linux Betriebssystem als persistenter bzw. weniger persistenter Ablagebereich. Gedacht ist das für Dateien, die entweder vorübergehend bzw. begrenzt oder längerfristig vorhanden sein müssen.

'''Interessant und erwähnenswert an dieser Stelle:''' 
Systemd hängt einige Dateisystemstrukturen automatisch als "tmpfs" ein. Dazu gehört beispielsweise auch der Pfad "/tmp". Wie dies geschieht, kann anhand des betreffenden tmp.mount units eingesehen werden. Aus dem Inhalt ergibt sich:
<blockquote><pre style="background-color: #D4FFEF; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">[Mount]
What=tmpfs
Where=/tmp
Type=tmpfs
Options=mode=1777,strictatime</pre></blockquote>
'''Ein zu SysV-Init zeiten nötiger [[fstab|fstab Eintrag]] hätte so ausgesehen:'''
<blockquote><pre style="background-color: #D4FFEF; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">tmpfs /tmp tmpfs defaults,strictatime,mode=1777 0 0</pre></blockquote>
<blockquote>
{{Hinweis|'''Der Pfad '/var/tmp/' wird hingegen beispielsweise nicht als tmpfs eingehängt. Ist dafür auch nicht bestimmt.'''}}
</blockquote>

{{Achtung|'''Der Tipp dazu: [[Tipp: systemd-tmpfiles]]'''}}
 

=Tipp: weekly trim durch systemd=
Das Paket 'util-linux-systemd' bringt einen Dienst mit, der es ermöglicht seine SSD wöchentlich trimmen zu lassen. Es gibt zu beachten, dass trim auf unterschiedlichem Weg im Betriebssystem zur [[SSD_Optimierungen|Optimierung von SSD's]] realisiert werden kann:
{| class="wikitable"
|+ Trim
|-
|Online discard (trim)
|moutoption "discard"
|Ersetzt batched trim und Skripte sowie manuelle Ausführung.
|-
|Manuell
|Durch ausführen des 'fstrim' Kommando in der Shell.
|[[http://man7.org/linux/man-pages/man8/fstrim.8.html man fstrim]]
|-
|rowspan="3"|Batched trim bzw. Mitgelieferte Skripte
|(eigener Skript) Bsp.: [[http://linux-club.de/wiki/opensuse/Batched-trim.sh ext4-trim.sh]]
|[[http://man7.org/linux/man-pages/man8/fstrim.8.html man fstrim]]
|-
|openSUSE bringt beispielsweise für [[https://de.wikipedia.org/wiki/Btrfs btrfs]] einen durch sysconfig steuerbaren trim Skript mit. ('btrfs-trim.sh');
|Funktioniert zum Stand von openSUSE 13.2 nur beim Einsatz von [[https://de.wikipedia.org/wiki/Btrfs btrfs]].
|-
|systemd bringt diese Möglichkeit als Dienst oder unit. ('fstrim.timer') - ('fstrim.service')
|Keine Einschränkung durch "automatik". "fstrim -a" beispielsweise bei ext4.
|-
|}
Wichtig ist zu beachten dass diese Kommandos nicht unnötig mehrfach ausgeführt werden oder vermischt zum Einsatz kommen. Einmal die Woche sollte bei batched trim völlig ausreichend sein. Wenn also die in openSUSE integrierte Trimfunktion nicht genutzt werden möchte, kann diese durch die von systemd durchaus ersetzt werden. Wenn beispielsweise Online discard verwendet wird, werden andere Skripte obsolet.
{{Achtung|'''Ich möchte hier nochmal darauf hinweisen, dass andere Skripte bei Nutzung von systemd zu diesem Zweck deaktiviert werden sollten! Und bei der mount option discard wird batched trim obsolet.'''}}
'''Folgendes genügt zum aktivieren der systemd variante:'''
<pre style="background-color: #FFFFC0">systemctl enable fstrim.timer</pre>
(''Der zugehörige fstrim.service wird vom Timer automatisch zur Ausführung aktiviert.'')
{{Hinweis|'''Es wird eine Datei mit einem Zeitstempel erstellt anhand dessen die letzte und nächste Ausführung nach dem ersten Aufruf abgehandelt wird.'''}}
'''Der eigentliche Dienst heisst:'''
<blockquote><pre style="background-color: #D4FFEF">fstrim.service</pre></blockquote>
'''Eine Steuerungsmöglichkeit hierfür ist auch:'''
<pre style="background-color: #FFFFC0">rcfstrim</pre>
'''Der Stempel befindet sich dann hier:'''
<blockquote><pre style="background-color: #D4FFEF">/usr/lib/systemd/system/fstrim.timer</pre></blockquote>
'''Der Dienst führt zurzeit wöchentlich folgendes Kommando aus:''' 
''Dies behandelt schlicht und automatisch alle eingehängten Dateisysteme mit trim.''
<pre style="background-color: #FFFFC0">fstrim -a</pre>
{{Warnung|'''Nicht jede SSD und SATA controller unterstützen jede TRIM Funktionalität. D.h. einige Geräte sind auf batched-discard angewiesen. Einige können mit Online-discard arbeiten, andere nicht. Einige haben wiederum Schwierigkeiten bei trim in Verbindung mit NCQ.'''}}
{{Hinweis|'''Es bietet sich auch an, dieses unit manuell durch einen eigenen Skript aufzurüsten.'''}}

 

=Quellen / Links:=
* https://www.suse.com/releasenotes/x86_64/SUSE-SLES/12/
* http://www.freedesktop.org/wiki/Software/systemd/
* https://www.suse.com/documentation/sles-12/book_sle_admin/data/cha_systemd.html
* https://de.wikipedia.org
* http://man7.org/
*[https://fedoraproject.org/wiki/Systemd fedoraproject.org wiki] {{englisch}}
*[http://cre.fm/cre209-das-linux-system CRE209 Das Linux System - systemd leitet die neue Generation der Linux Systemarchitektur ein] Tim Pritlove im Gespräch mit Lennart Poetering (Veröffentlicht am 10. November 2015)

[[Kategorie:Bootmanager‏‎]] [[Kategorie:systemd]]

Systemd

2015-11-20T16:17:11Z

Gehrke: /* Quellen / Links: */ CRE209 Das Linux System

{{Review|Kompletter Artikel}}
{{Achtung|'''Aus technischen Gründen ist es leider nicht Möglich der korrekten Schreibweise von "systemd" in der Überschrift dieses Artikels gerecht zu werden.'''}}

= Was ist systemd? =
Systemd ist ein Dienst oder Daemon und bietet einige grundlegende Werkzeuge für Linux Systeme. Er wird zur System- und Diensteverwaltung eingesetzt. Er läuft mit [[https://de.wikipedia.org/wiki/Process_identifier PID1]] und startet dann alle weiteren Prozesse des Betriebssystems. Des weiteren wird er als freie Software unter der [[LGPL |LGPL 2.1+]] veröffentlicht und wurde in [[Programmierung|C geschrieben]].

* http://www.freedesktop.org/wiki/Software/systemd/

''Er startet also als erstes ([[https://de.wikipedia.org/wiki/Process_identifier PID1]]), regelt und steuert dabei alle weiteren Dienste. Er beendet sich beim Herunterfahren als letztes. Der daemon systemd ist damit also tief im Ablauf eines Systemstarts verwurzelt.''

'''Wichtiges dazu:'''
* [[Bootmanager]]
* [[Bootvorgang]]
* [[YaST2_Dienste-Verwaltung|YaST2 Dienste-Verwaltung]]
 

= SUSE wechsel zu systemd =
Mit unter liebevoll vollzieht sich der Wechsel zu systemd als Init-System in SUSE mit Sätzen, zitert aus den Releasenotes und dem Adminguide zu [[https://www.suse.com/ SUSE Linux Enterprise Server 12]], wie:
<blockquote><pre style="background-color: #D4FFEF; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">New core technologies like systemd (replacing the time honored System V based init process) </pre></blockquote>
'''Versuchsweise frei übersetzt:''' ''Neue Kerntechnologien wie systemd (ersetzen den durch lange Dienstzeit geehrten System V basierten init prozess).''
<blockquote><pre style="background-color: #D4FFEF; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Starting with SUSE Linux Enterprise Server 12 systemd is a replacement for the popular System V init daemon. systemd is fully compatible with System V init (by supporting init scripts). </pre></blockquote>
'''Versuchsweise frei übersetzt:''' ''Beginnend mit [[https://www.suse.com/ SUSE Linux Enterprise Server 12]] ist systemd ein Ersatz für den populären System V init daemon. Er ist voll kompatibel mit dem System V Init-Vorgang, indem er Init Skripte unterstützt.''

= Integration in [[YaST]] =
{|
|rowspan=2|[[Bild:Yast.png]]
|colspan=3|Wie sich systemd im grafischen Konfigurationstool für [[openSUSE]] integriert, könnt ihr hier sehen:
|-
|style="text-align:center;"| ---------->
|style="text-align:center;"|[[YaST2_Dienste-Verwaltung|YaST2: Diensteverwaltung]]
|style="text-align:center;"| <----------
|-
|}

=Kompatibilität=
Als sogenanntes "drop-in replacement". Bietet systemd Kompatibilität zu seinen Vorgängern:
 
* kompatibel mit [[https://de.wikipedia.org/wiki/Linux_Standard_Base LSB]] init Skripten
* kompatibel mit SysV
Hier gibt es zu beachten, dass systemd nicht vollständig rückwärts kompatibel ist.
Einige Einschränkungen können hier nachgelesen werden: http://www.freedesktop.org/wiki/Software/systemd/Incompatibilities/

=Kritik=
Da ich nicht unnötig falsches sagen möchte, was Kritik gegenüber systemd angeht. Und da ich nur einige Grundlagen objektiv darstellen will, kann ich dazu nicht viel sagen. Allerdings kann ich folgendes berichten:
* Bei Linux Entwicklern als auch Benutzern steht systemd im Mittelpunkt der Kritik, da es im Ansatz sehr wichtige Kernfunktionen steuert und auch das alt eingefahrene SysV-Init ersetzen kann, bzw. kompatibel ist.
* Zu diesem Thema gibt es massenweise Informationen im Internet.
'''Ein besonders wichtiger Punkt:'''
* Es gibt viele Gegner als auch Befürworter.
 
{{Hinweis|'''Wer möchte informiert sich darüber bitte detaillierter mithilfe einer Suchmaschine eigener Wahl.'''}}
{{Hinweis|'''Das Forum würde sich hierfür als Diskussionsplatform anbieten, wer möchte. Es gibt sicher einige die an dieser Thematik interesse haben. http://forum.linux-club.de/'''}} 
---------
'''Meine Meinung zur Kritik:''' 
(Wer mir diesen Raum nicht lassen möchte: Bitte "skipping").
 
''Ich finde es wichtig, dass derart grundlegende Kernstrukturen im Betriebssystem kritisiert werden, solange es zielführend und im Sinne eines sicheren und korrekten Funktionierens und damit im Sinne des Endverbrauchers als auch der Entwickler ist. Was ich nicht verstehen kann, wenn Leute nur sagen "systemd ist mist ich will wieder das alte SysV-Init, weil ich mit systemd nicht umgehen kann." Deswegen möchte ich hier sagen:''
 
"''Bitte ich gebe euch Gelegenheit, euch zu informieren. Und ich hoffe dies halbwegs richtig zu machen.''"
---------

=Fähigkeiten=
Als Verwaltungsinstrument bringt systemd einige Neuerungen und Verbesserungen, setzt dabei allerdings auch stark auf alt bewährtes. Um nur einiges an Neuerungen und Fähigkeiten zu nennen:

* Fähigkeit zur aggressiven Parallelisierung
* Nutzt Socket und [[https://en.wikipedia.org/wiki/D-Bus D-Bus]] Aktivierung um Prozesse zu starten
* Bietet ein "auf Bedarf"-basiertes starten von Diensten
* Überwacht Prozesse die [[https://en.wikipedia.org/wiki/Cgroups cgroups]] verwenden
* unterstützt [[https://de.opensuse.org/SDB:Snapper Schnappschüsse]] und deren Wiederherstellung
* Verwaltet [[Zugriffsrechte#mount|mount und automount]] Einhängepunkte
* Implementiert abhängigkeitsbasierte Logik für Dienste
* Kann SysV-Init als drop-in ersetzen.
* uvm.
{{Hinweis|Mit Parallelisierung ist das Resultat dieser Prinzipien: [[https://de.wikipedia.org/wiki/Nebenläufigkeit Nebenläufigkeit]] bzw. [[https://de.wikipedia.org/wiki/Parallele_Programmierung Parallele Programmierung]] gemeint. Die wörter [[https://de.wikipedia.org/wiki/Bedarf Bedarf]] und [[Systemd#Abhängigkeit_darstellen:|Abhängigkeit]] müssen in der Auflistung differenziert werden.}}
 

=systemd Steuern=
Es gibt verschiedene Wege, wie systemd gesteuert werden kann. Einmal gibt es grafische Tools, wie die [[YaST2_Dienste-Verwaltung|Dienste-Verwaltung]] in [[YaST]]. Das ehemals benannte Menü: "Runlevel-Editor" nennt sich heute bei Migration zu systemd "Dienste-Verwaltung". Dann gibt es noch die Möglichkeit mit der [[Shell]]. Eine vollständige auflistung der Steuerungsmöglichkeiten, würde den Rahmen dieser Doku total sprengen. Ich nenne hier einige aus Nutzersicht durchaus wichtige Möglichkeiten:

{| class="wikitable"
|+Mitgelieferte Tools:
|-
|'''[[#Umgang_mit_systemctl|systemctl]]'''
|''(Den System- und Dienstmanager steuern.)''
|-
|'''[[#Umgang_mit_journalctl|journalctl]]'''
|''(Das systemd journal abfragen. Also logs.)''
|-
|'''[[#Tipp: systemd-tmpfiles|systemd-tmpfiles]]'''
|''(Erstellt und löscht temporäre Strukturen.)''
|-
|'''[[#Umgang_mit_systemd-analyze|systemd-analyze]]'''
|''(Analysiert die boot Geschwindigkeit.)''
|-
|'''[[#Umgang_mit_loginctl|loginctl]]'''
|''(Anbindung an die Sitzungsverwaltung)''
|-
|'''.. uvm.'''
|''(Alle die ich nicht nennen konnte)''
|-
|}

=Umgang mit systemctl=
Bitte zum detaillierten Umgang mit systemctl die [[Man_pages|manpage]] lesen. Oder beispielsweise im (Achtung externer Link): [https://www.suse.com/documentation/sles-12/book_sle_admin/data/sec_boot_systemd_basics.html Adminguide] nachschlagen.
<pre style="background-color: #FFFFC0">man systemctl</pre>
Nachfolgend einige einfache Befehle, die empfehlungsweise bekannt sein sollten.

==Dienste Starten und Beenden==
'''Starten'''
<pre style="background-color: #FFFFC0">systemctl start mein_dienst</pre>
'''Beenden'''
<pre style="background-color: #FFFFC0">systemctl stop mein_dienst</pre>

==Automatischen Start De-/Aktivieren==
'''Automatischen Start aktivieren:'''
<pre style="background-color: #FFFFC0">systemctl enable mein_dienst</pre>
'''Automatischen Start deaktivieren:'''
<pre style="background-color: #FFFFC0">systemctl disable mein_dienst</pre>

==Status eines Dienstes abfragen==
<pre style="background-color: #FFFFC0">systemctl status mein_dienst</pre>
In der Ausgabe würde das bei einem erfolgreich gestarteten und für den automatischen Start konfigurierten Dienst in etwa so aussehen:
<blockquote><pre style="background-color: #D4FFEF; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">
mein_dienst.service - mein_dienst Daemon
Loaded: loaded (/usr/lib/systemd/system/mein_dienst.service; enabled)
Active: active (running) since Sa 2015-08-22 02:17:01 CEST; 1s ago
Process: 6717 ExecStartPre=/usr/sbin/mein_dienst (code=exited, status=0/SUCCESS)
Main PID: 6721 (mein_dienst)
</pre></blockquote>

==systemd neu laden==
Angenommen, es wurden beispielsweise Änderungen an mein_dienst.service Dateien vorgenommen, muss systemd neu geladen werden, damit sie sofort wirksam werden.
<pre style="background-color: #FFFFC0">systemctl daemon-reload</pre>

=Wo sind meine Logs hin?=
{{Hinweis|'''Umsteigern von SysV-Init auf systemd empfehle ich zum Thema Log´s dies:'''}}
<pre style="background-color: #FFFFC0">less /var/log/README</pre>
'''Darin steht in etwa (versuchsweise frei übersetzt):''' 
<blockquote><pre style="background-color: #D4FFEF; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">
Sie suchen die traditionellen text log Dateien in /var/log, und diese sind verschwunden?

Hier eine erklärung, was vor sich geht:

Sie betreiben ein systemd basiertes BS in dem syslog durch das Journal ersetzt wurde. Das Journal speichert die selben (und mehr) Informationen wie das klassische syslog. Um das Journal zu nutzen und auf die Logdaten zuzugreifen, führen Sie einfach "journalctl" aus, welches die Logdaten in dem identischen textbasierten Format ausgeben wird, wie es auch mit syslog der Fall war. Für weitere Details, sehen Sie bitte journalctl(1) ein.
...
Thank you!
</pre></blockquote>
Das heisst, es bietet sich hier die Gelegenheit mit dem neuen Journal vertraut zu werden.
In folgenden Abschnitten möchte ich deswegen eine kurze Einleitung zum Umgang anbieten.

=Umgang mit journalctl=
Der Dienst systemd beinhaltet seinen eigenen Dienst zur Systemprotokollierung. Die Sammlung all dieser Informationen wird als journal bezeichnet. Diese Instanz sammelt wichtige Informationen und stellt diese wiederum zur Abfrage bereit. Das ist insbesondere zur Systemüberwachung von Nutzen. Es kann beispielsweise mit Hilfe von journalctl ein fehlerhafter Systemstart diagnostiziert werden. Angenommen dies wäre der Fall, so wird spätestens an dieser Stelle ein gewisses Grundwissen zum Umgang mit journalctl erforderlich, wenn es darum geht konkrete Fehlermeldungen bereitzustellen.
{{Hinweis|'''Generell erfolgt die Ansicht der Protokolle automatisch in einem Pager.'''}}
==Das journal betrachten:==
<pre style="background-color: #FFFFC0">journalctl</pre>
Wenn einfach nur 'journalctl' ausgeführt wird, zeigt ein pager das komplette journal, beginnend mit dem ältesten Eintrag.

==Nützliche Schalter==
Es gibt viele weitere wichtige Filter. Hier einige wenige, die bekannt sein sollten:
{| class="wikitable"
|+Schalter
|-
|"-k"
|dmesg betrachten
|-
|"-b"
|Bootvorgänge
|-
|"-u"
|Nach Unit bzw. Dienst
|-
|"-f"
|aktualisiert den Pager mit neuen Einträgen
|}
Für mehr Details bitte die [[Man_pages|manpage]] lesen.

==Das Startprotokoll==
<pre style="background-color: #FFFFC0">journalctl -b</pre>
Der Schalter '-b' sagt journalctl, dass das gesamte Startprotokoll gezeigt werden soll.

===Das Startprotokoll filtern===
Angenommen, es möchte nur ein bestimmtes Startprotokoll eingesehen werden. Etwa vom vorhergehenden Systemstart:
<pre style="background-color: #FFFFC0">journalctl --list-boots</pre>
(Gibt eine Liste vorangegangener Protokolle in einer Übersicht aus). Die erste Spalte kann als Indikator herangezogen werden. Beispielausgabe:
<blockquote><pre style="background-color: #D4FFEF; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"> ..
...
-2 9daa81e2ec374cb1b6adba8d96896605 Sa 2015-08-29 23:26:53 CEST—Sa 2015-08-29 23:49:17 CEST
-1 c430ed034607494ba2a3bc1ded4e4972 Sa 2015-08-29 23:49:35 CEST—Sa 2015-08-29 23:54:27 CEST
0 1f3a7894d0f34f4392c5517b83279c4d Sa 2015-08-29 23:54:53 CEST—So 2015-08-30 16:22:40 CEST</pre></blockquote>
Das gewünschte Startprotokoll wird durch Übergabe des jeweiligen Indikator im Pager dargestellt:
<pre style="background-color: #FFFFC0">journalctl -b -1</pre>

===journalctl -xb===
Wenn der Computer beispielsweise aufgrund eines Stromausfall im Emergency Mode startet, wird in der Shell statt dem grafischen Modus ein Login angeboten. Hier schlägt der Rechner oft vor, es solle die Ausgabe von 'journalctl -xb' zu Rate gezogen werden. Also das Startprotokoll prüfen:
<pre style="background-color: #FFFFC0">journalctl -xb</pre>
{| class="wikitable"
|+ Schalter
|-
|"-x"
|Blendet nützliche Hilfetexte in der Ausgabe ein.
|-
|"-b"
|Das Bootprotokoll anzeigen.
|-
|}

==journalctl -xn==
Duch den Schalter -n kann man die Ausgabe auf eine bestimmte Anzahl Zeilen beschränken. Wenn keine Zahl übergeben wird, werden die letzten 10 Zeilen ausgegeben. Beispielsweise die letzten 25 Zeilen ausgeben und Hilfstexte einblenden:
<pre style="background-color: #FFFFC0">journalctl -xn 25</pre>
{| class="wikitable"
|+ Schalter
|-
|"-x"
|Blendet nützliche Hilfetexte in der Ausgabe ein.
|-
|"-n"
|Ausgabe auf bestimmte Zeilenanzahl beschränken.
|-
|}

==Filtern nach Unit==
Angenommen es sollen nur Logeinträge zum Unit oder Dienst "sshd" in der Ausgabe angezeigt werden.
<pre style="background-color: #FFFFC0">journalctl -u sshd</pre>

==Eigener Filter==
Die Ausgabe von journalctl kann auch umgeleitet werden. So wird im folgenden Beispiel das ganze Systemprotokoll unter zuhilfenahme von 'egrep' nach Vorkommnissen von "Error" und "Failed" durchsucht. Die Ausgabe wird dann an einen Pager (less) umgeleitet:
<pre style="background-color: #FFFFC0">journalctl | egrep "Error|Failed" | less</pre>

==Speicherplatzbelegung==
Jedes Log wird für eine gewisse Dauer aufbewahrt. Das ist besonders für Systemadministratoren von besonderer Bedeutung, da Computer oft über einen längeren Zeitraum überwacht werden müssen. Einige Daten werden also permanent auf der Festplatte abgelegt. Von Haus aus sind seitens systemd für diese Informationen 10 Prozent des betroffenen Dateisystems vorgesehen. Bei einem Dateisystem mit 1 TiB Speicherplatz wären dies also 100 GiB logdaten, die von systemd angesammelt würden. Das Journal wird allerdings auch noch komprimiert.
{| class="wikitable"
|+Schalter für journalctl
|-
|"--disk-usage"
|Speicherplatzbelegung des Journal auf dem Datenträger zeigen.
|}
Wer auf die voreingestellten Limits und den dafür vorgesehenen Speicherplatz Einfluss haben möchte, kann dies in der Konfigurationsdatei tun:
<blockquote><pre style="background-color: #D4FFEF">/etc/systemd/journald.conf</pre></blockquote>
So liesse sich beispielsweise mit diesem Schalter das Journal auf eine Größe von 100M beschränken. Ich fände auch einen Wert bis 300M noch sinnvoll wieviel hier eingestellt wird, liegt an der eigenen Nutzenvorstellung:
<pre style="background-color: #FFFFC0">SystemMaxUse=100M</pre>
Zum Verständnis der Grössenrelation: [[Megabyte |Megabyte/Mibibyte]] 
Und Achtung externer Link: https://de.wikipedia.org/wiki/Datenmenge
{{Hinweis|'''Die Daten werden im Journal in anderer Form und komprimiert abgelegt. Dennoch, um eine Vorstellung zu haben: Eine Textdatei gefüllt mit Rautezeichen, die ein A4 Brief ausfüllen würden, hat ca. 4,1 KiB. Eine Ansammlung von 100 GiB mit solchen Dateien entspräche in etwa 261 888 249 Dokumente oder Seiten. Eine Packung Schreibmaschinenpapier hat ca 100 Blatt.'''}}
 

=Umgang mit systemd-analyze=
Der Befehl systemd-analyze kann dazu genutzt werden, die Leistung eines Systemstarts zu messen. Beispielsweise wie lange es dauert, bis ein bestimmtes festgelegtes Ziel beim Boot erreicht wurde. Ich möchte hier nur Kleinigkeiten zeigen, damit Verständnis erlangt werden kann, was denn bei einem Systemstart von gerade mal 20 Sekunden so alles abgeht. Auch hier bitte ich darum, zu Details wieder die manpage heranzuziehen.

==Startzeitanalyse==
<blockquote>'''Einfach ohne Zusätzliche Schalter:'''
<pre style="background-color: #FFFFC0">systemd-analyze</pre>
'''Beispielausgabe:'''
<blockquote><pre style="background-color: #D4FFEF; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Startup finished in 1.433s (kernel) + 493ms (initrd) + 17.842s (userspace) = 19.769s</pre></blockquote>
Die Ausgabe sollte weitestgehend selbsterklärend sein. Angegebene Messwerte sind an diesem Beispiel in Sekunden und Millisekunden.
</blockquote>

==Messung grafisch darstellen==
Es kann eine SVG Grafik als sog. "plot" erstellt werden, der in Details aufzeigt welche Systemdienste zu welcher Zeit gestartet wurden. Dabei wird visuell hervorgehoben, wie viel Zeit alle Dienste zur Initialisierung benötigten. 
-----
==='''Startzeiten aller Prozesse:'''===
<blockquote>{{Hinweis|'''Ich leite Die Ausgabe gleich in eine Datei um und öffne diese mit "gwenview":'''}}
<pre style="background-color: #FFFFC0; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">systemd-analyze plot > /tmp/plot.svg | gwenview /tmp/plot.svg</pre>
{{Achtung|Die SVG Datei ist zwar - nur - ca. 140k groß, das darstellen dieser Grafik kann aber sehr aufwendig für den Computer sein. Nachfolgend nur ein kleiner Ausschnitt aus so einer Grafik als GIF.}}
[[Bild:systemd-analyze_plot.gif|center|'''Plot als Grafik''']]
Hier kann man sehr schön sehen, was systemd beim Startvorgang so alles anstellen muss. Und was denn eigentlich so alles in diesen 20 Sekunden passiert bis am Beispielsystem ein vollständiger Systemstart abgeschlossen ist. </blockquote>
--------
==='''Abhängigkeit darstellen:''' ===
<blockquote>Wer das interessant fand, möchte eventuell die Möglichkeit nutzen sich grafisch darstellen zu lassen in welchen Abhängigkeiten ein Dienst gestartet wurde.
{{Hinweis|'''Ich leite Die Ausgabe am Beispiel "avahi-daemon" gleich in eine Datei um und öffne diese mit "gwenview":'''}}

<pre style="background-color: #FFFFC0; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">systemd-analyze dot 'avahi-daemon.*' | dot -Tsvg > /tmp/avahi.svg | gwenview /tmp/avahi.svg</pre>{{Achtung|'''Das ist ein Einzeiler!'''}}
Das Ergebnis präsentiert sich dann so (zu .gif umgewandelt):
[[Bild:Systemd-analyze_avahi.gif|center|'''Prozessabhängigkeit als Grafik''']]
</blockquote>
 

=Umgang mit loginctl=
Als wichtiger Systemdienst bindet sich systemd auch an den Anmeldevorgang im Betriebssystem. Dafür stellt er einen extra Dienst "systemd-login" zur Verfügung. Der Dienst bietet an dieser Stelle ein Anbindung an die D-Bus Schnittstelle. Wichtige Grundlagen betreffend Zugriffsberechtigungen: [[Zugriffsrechte]]

Das Tool loginctl kann dazu verwendet werden, Einblicke in den Status von Benutzeranmeldungen zu erlangen. Ausserdem kann es verwendet werden Veränderungen am Systemstatus vorzunehmen.

So können [[https://de.wikipedia.org/wiki/Portable_Operating_System_Interface POSIX]] kompatible Signale an Benutzersitzungen gesendet werden, wie beispielsweise [[https://de.wikipedia.org/wiki/SIGTERM SIGTERM]]. Das ist ein Signal zum Terminieren von Programmprozessen.
{{Warnung|'''Dieses Werkzeug sollte nur von erfahrenen Benutzern verwendet werden.'''}}
'''Hier nur ein ganz einfaches ungefährliches Anwendungsbeispiel:'''
<pre style="background-color: #FFFFC0">loginctl</pre>
'''Listet laufende Benutzersitzungen:'''
<blockquote><pre style="background-color: #D4FFEF"> SESSION UID USER SEAT
1 1000 user seat0</pre></blockquote>
 

=systemd-tmpfiles=
'''Grundlegendes:''' 
Der Dienst systemd-tmpfiles ist im System für die Verwaltung temporärer Dateisystemstrukturen zuständig. Er erstellt und löscht diese kann sie aber auch bereinigen. ..usw. Einige dieser Strukturen bestehen bei einem Linux Betriebssystem als persistenter bzw. weniger persistenter Ablagebereich. Gedacht ist das für Dateien, die entweder vorübergehend bzw. begrenzt oder längerfristig vorhanden sein müssen.

'''Interessant und erwähnenswert an dieser Stelle:''' 
Systemd hängt einige Dateisystemstrukturen automatisch als "tmpfs" ein. Dazu gehört beispielsweise auch der Pfad "/tmp". Wie dies geschieht, kann anhand des betreffenden tmp.mount units eingesehen werden. Aus dem Inhalt ergibt sich:
<blockquote><pre style="background-color: #D4FFEF; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">[Mount]
What=tmpfs
Where=/tmp
Type=tmpfs
Options=mode=1777,strictatime</pre></blockquote>
'''Ein zu SysV-Init zeiten nötiger [[fstab|fstab Eintrag]] hätte so ausgesehen:'''
<blockquote><pre style="background-color: #D4FFEF; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">tmpfs /tmp tmpfs defaults,strictatime,mode=1777 0 0</pre></blockquote>
<blockquote>
{{Hinweis|'''Der Pfad '/var/tmp/' wird hingegen beispielsweise nicht als tmpfs eingehängt. Ist dafür auch nicht bestimmt.'''}}
</blockquote>

{{Achtung|'''Der Tipp dazu: [[Tipp: systemd-tmpfiles]]'''}}
 

=Tipp: weekly trim durch systemd=
Das Paket 'util-linux-systemd' bringt einen Dienst mit, der es ermöglicht seine SSD wöchentlich trimmen zu lassen. Es gibt zu beachten, dass trim auf unterschiedlichem Weg im Betriebssystem zur [[SSD_Optimierungen|Optimierung von SSD's]] realisiert werden kann:
{| class="wikitable"
|+ Trim
|-
|Online discard (trim)
|moutoption "discard"
|Ersetzt batched trim und Skripte sowie manuelle Ausführung.
|-
|Manuell
|Durch ausführen des 'fstrim' Kommando in der Shell.
|[[http://man7.org/linux/man-pages/man8/fstrim.8.html man fstrim]]
|-
|rowspan="3"|Batched trim bzw. Mitgelieferte Skripte
|(eigener Skript) Bsp.: [[http://linux-club.de/wiki/opensuse/Batched-trim.sh ext4-trim.sh]]
|[[http://man7.org/linux/man-pages/man8/fstrim.8.html man fstrim]]
|-
|openSUSE bringt beispielsweise für [[https://de.wikipedia.org/wiki/Btrfs btrfs]] einen durch sysconfig steuerbaren trim Skript mit. ('btrfs-trim.sh');
|Funktioniert zum Stand von openSUSE 13.2 nur beim Einsatz von [[https://de.wikipedia.org/wiki/Btrfs btrfs]].
|-
|systemd bringt diese Möglichkeit als Dienst oder unit. ('fstrim.timer') - ('fstrim.service')
|Keine Einschränkung durch "automatik". "fstrim -a" beispielsweise bei ext4.
|-
|}
Wichtig ist zu beachten dass diese Kommandos nicht unnötig mehrfach ausgeführt werden oder vermischt zum Einsatz kommen. Einmal die Woche sollte bei batched trim völlig ausreichend sein. Wenn also die in openSUSE integrierte Trimfunktion nicht genutzt werden möchte, kann diese durch die von systemd durchaus ersetzt werden. Wenn beispielsweise Online discard verwendet wird, werden andere Skripte obsolet.
{{Achtung|'''Ich möchte hier nochmal darauf hinweisen, dass andere Skripte bei Nutzung von systemd zu diesem Zweck deaktiviert werden sollten! Und bei der mount option discard wird batched trim obsolet.'''}}
'''Folgendes genügt zum aktivieren der systemd variante:'''
<pre style="background-color: #FFFFC0">systemctl enable fstrim.timer</pre>
(''Der zugehörige fstrim.service wird vom Timer automatisch zur Ausführung aktiviert.'')
{{Hinweis|'''Es wird eine Datei mit einem Zeitstempel erstellt anhand dessen die letzte und nächste Ausführung nach dem ersten Aufruf abgehandelt wird.'''}}
'''Der eigentliche Dienst heisst:'''
<blockquote><pre style="background-color: #D4FFEF">fstrim.service</pre></blockquote>
'''Eine Steuerungsmöglichkeit hierfür ist auch:'''
<pre style="background-color: #FFFFC0">rcfstrim</pre>
'''Der Stempel befindet sich dann hier:'''
<blockquote><pre style="background-color: #D4FFEF">/usr/lib/systemd/system/fstrim.timer</pre></blockquote>
'''Der Dienst führt zurzeit wöchentlich folgendes Kommando aus:''' 
''Dies behandelt schlicht und automatisch alle eingehängten Dateisysteme mit trim.''
<pre style="background-color: #FFFFC0">fstrim -a</pre>
{{Warnung|'''Nicht jede SSD und SATA controller unterstützen jede TRIM Funktionalität. D.h. einige Geräte sind auf batched-discard angewiesen. Einige können mit Online-discard arbeiten, andere nicht. Einige haben wiederum Schwierigkeiten bei trim in Verbindung mit NCQ.'''}}
{{Hinweis|'''Es bietet sich auch an, dieses unit manuell durch einen eigenen Skript aufzurüsten.'''}}

 

=Quellen / Links:=
* https://www.suse.com/releasenotes/x86_64/SUSE-SLES/12/
* http://www.freedesktop.org/wiki/Software/systemd/
* https://www.suse.com/documentation/sles-12/book_sle_admin/data/cha_systemd.html
* https://de.wikipedia.org
* http://man7.org/
*[https://fedoraproject.org/wiki/Systemd fedoraproject.org wiki] {{englisch}}
*[http://cre.fm/cre209-das-linux-system CRE209 Das Linux System - systemd leitet die neue Generation der Linux Systemarchitektur ein] Tim Pritlove im Gespräch mit Lennart Poetering (Veröffentlicht am 10. November 2015)

[[Kategorie:Bootmanager‏‎]] [[Kategorie:systemd]]

Diskussion:Systemd

2015-11-20T16:08:16Z

Gehrke: Strukturierung / Aufteilung auf mehrere Seiten

Ein einfacher Versuch. Ich denke mir zu dem Thema ist weniger eventuell mehr.

Sa. 22. Aug. 2015 -- Revealed

:An das große und kontrovers diskutierte Thema 'systemd' hat sich bislang hier noch niemand ran getraut. Jetzt haben wir zumindest schon mal einen Anfang...
:TNX

:--[[Benutzer:Gehrke|Gehrke]] ([[Benutzer Diskussion:Gehrke|Diskussion]]) 07:41, 23. Aug. 2015 (CEST)

=Review=
== 23.08.2015==
Ich habe mal einen Blick auf die Seite geworfen und der Seite mal die Kategorie 'Bootmanager' zugeordnet. Auch wenn systemd kein BootManager im klassischen Sinne ist/sein sollte, übernimmt es doch wichtige Teile das Boot-Prozesses. Und Seiten zum Boot-Prozess werden in der linupedia derzeit pauschal unter dieser Kategorie zusammengefasst.

Derzeit ist der Inhalt ja noch überschaubar, bis hierhin sieht es IMHO gut aus. Vermutlich kann das Review-Tag damit auch schon wieder entfernt werden. TNX

--[[Benutzer:Gehrke|Gehrke]] ([[Benutzer Diskussion:Gehrke|Diskussion]]) 07:58, 23. Aug. 2015 (CEST)

::: Nachdem Systemd das halbe System umgekrempelt hat bis sich fast niemand mehr wirklich auskennt, (vom Starten des Kernel, über die Initrd, das Verwalten der Geräteknoten, das Einhängen der Dateisysteme, das Starten und verwalten der Dienste, usw. und sich zusätzlich noch anmaßt alte klassische UNIX/LINUX Dienste abzulösen in dem einfach deren Funktion unnötiger Weise auch noch in Systemd integriert wurden), dann einfach mit dem Satz 
:::"'''Er läuft mit PID1 und startet dann alle weiteren Prozesse des Betriebssystems. Siehe [[Bootvorgang]].'''" 
:::auf ein halbwegs komplettes Thema zu verlinken, dass nun mit der Funktion von Systemd aber mal überhaupt nichts mehr zu tun hat, halte ich schon ein wenig dreist. [[Benutzer:Robi|Robi]] ([[Benutzer Diskussion:Robi|Diskussion]]) 19:50, 24. Aug. 2015 (CEST)

:::Meine Antwort auf Systemd nach dem ich mich einige Zeit näher intern damit befasst hatte, lautet schlicht und einfach "NOSYSTEMD", dazu stehe ich und das halte ich bequem noch die paar Jahre durch bis zu Rente durch. Wenn Systemd und deren Entwickler und die Distributionen der Meinung sind, sie müssen alles von Grund auf komplett anders machen, dann bitte sollen sie auch Dokumentation schreiben wie Systemd wirklich arbeitet, damit wenn sich jemand berufen fühlt das dem User in einem Bootvorgang Wikiartikel zu erklären dann auch entsprechende Quellen zur Recherche zu Verfügung hat.
:::Alles über den Haufen zu werfen und alles "besser" (anders) zu machen und dann auf die Dokumentation dessen zu verweisen was man quasi über Nacht alles abgeschafft hat, passt wahrscheinlich aus Bequemlichkeitstgründen gut in das Konzept von Systemd und deren Entwicklung, ist aber weder für einen User hilfreich der irgendwo beim Systemstart mit systemd hängen geblieben ist. noch ist es fair gegenüber denen die zwar nichts gegen Systemd haben, sich aber von diesem auch nicht aufzwingen lassen wollen wie Linux "besser" funktionieren soll. [[Benutzer:Robi|Robi]] ([[Benutzer Diskussion:Robi|Diskussion]]) 20:18, 24. Aug. 2015 (CEST)
--------
::: Hallo Ihr. Da bin ich euch ja schön in eine Falle gelaufen. Also ich wollte niemanden provozieren, oder dergleichen. Der Artikel "systemd" war als leere Seite vorhanden. Jemand hat in meinem [[ThinkPad_T60]]Guide das wörtchen "systemd" und einige andere netter Weise durch Verlinkung hervorgehoben. Beim überarbeiten habe ich gesucht ob im Wiki das Wörtchen "systemd" existiert. Da dies ebenfalls schon als Verknüpfung zu dem leeren Blatt vorhanden war, habe ich es ausgefüllt. Ihr könnt das gerne komplett umschreiben. Ich hätte jedoch aus eigennützigen Gründen für mein Tut sehr gerne die Nutzungsbeispiele darin gehabt. Und verzeiht mir bitte, dass ich mich verbal nicht auf dem Niveau vom Bootvorgang - Howto äußern kann. lg, [[Benutzer:revealed|revealed]] ([[Benutzer Diskussion:revealed|Diskussion]]) 21:03, 24. Aug. 2015 (CEST)
::::Ich denke nicht, dass Du hier etwas grundlegend falsch gemacht hast. Letztlich ist es so, dass 'systemd' existiert und scheinbar unaufhaltsam in die Distributionen einfließt (analog zu [[GRUB2]] oder UEFI). Dabei ist es erstmal unerheblich, ob wir das nun gut finden oder nicht. IMHO sollte es hier darum gehen, eine Dokumentationsbasis zu haben, welche bei Bedarf erweitert werden kann. So könnte ich mir die Analyse-Tools durchaus als interessantes Thema für dieses Wiki vorstellen, nur so als Beispiel. Bis dahin kann sie in der ersten Phase aber auch einfach nur als Anker dienen, auf die von anderen Seiten verlinkt wird und neben einem kurzen Intro noch weiterführende Links enthält, z.B. auch auf externe Seiten mit der Kritik an systemd.
::::--[[Benutzer:Gehrke|Gehrke]] ([[Benutzer Diskussion:Gehrke|Diskussion]]) 17:12, 25. Aug. 2015 (CEST)

--------
::: Gleich noch eine Nachricht von mir. Die Entwickler von "systemd" scheinen sehr auf die Schreibweise "systemd" zu achten. Da ich solchen Wünschen gerecht werden möchte, wollte ich fragen ob es möglich ist, Seitenüberschriften mit kleinschreibung beginnen zu lassen. Hier habe ich eine info gesucht, wie das machbar sein könnte. Wenn nicht, dann ist mir persönlich das dann auch nicht soooo wichtig. https://www.mediawiki.org/wiki/Manual:LocalSettings.php#Force_capital_links lg, R ([[Benutzer Diskussion:revealed|Diskussion]]) 21:26, 24. Aug. 2015 (CEST)
::::AFAIK können Seiten im Wiki nur anfänglich großgeschrieben angelegt werden. Daran kannst Du nichts ändern.
::::--[[Benutzer:Gehrke|Gehrke]] ([[Benutzer Diskussion:Gehrke|Diskussion]]) 21:00, 25. Aug. 2015 (CEST)
------
:::: Ah, danke für die Info. Ich selber komm damit zurecht ;) Wenn wer nochmal lesen würde und echt nichts mehr total dagegen spricht, nachdem ich nochmal einiges geändert habe würde ich den Artikel auch als fertig betrachten. Eine Kurze info wäre nett ob ich den Baustein dann rausnehmen soll. Oder vielleicht übernimmt das dann gleich noch wer, oder info bitte. Danke und Grüße, R
::::--[[Benutzer:revealed|revealed]] ([[Benutzer Diskussion:revealed|revealed]]) 21:22, 26. Aug. 2015 (CEST)
-----

=Strukturierung / Aufteilung auf mehrere Seiten=
Die Seite ist jetzt schon einigermaßen voll und unübersichtlich - und wir stehen erst am Anfang einer Dokumentation. Das Gesamtthema ist viel zu groß für eine einzelne Seite. Ich plädiere dafür, einzelne Themen herauszuziehen und auf separate Seiten zu verlagern. Diese Seite kann als Übersicht dienen und auf die Teilaspekte verlinken.
Als weitere Klammer bietet sich die Kategorie 'systemd' an, diese Seite ist schon damit markiert.

--[[Benutzer:Gehrke|Gehrke]] ([[Benutzer Diskussion:Gehrke|Diskussion]]) 17:08, 20. Nov. 2015 (CET)

Systemd

2015-11-20T15:38:06Z

Gehrke: /* Quellen / Links: */ fedoraproject.org wiki + Kategorie

{{Review|Kompletter Artikel}}
{{Achtung|'''Aus technischen Gründen ist es leider nicht Möglich der korrekten Schreibweise von "systemd" in der Überschrift dieses Artikels gerecht zu werden.'''}}

= Was ist systemd? =
Systemd ist ein Dienst oder Daemon und bietet einige grundlegende Werkzeuge für Linux Systeme. Er wird zur System- und Diensteverwaltung eingesetzt. Er läuft mit [[https://de.wikipedia.org/wiki/Process_identifier PID1]] und startet dann alle weiteren Prozesse des Betriebssystems. Des weiteren wird er als freie Software unter der [[LGPL |LGPL 2.1+]] veröffentlicht und wurde in [[Programmierung|C geschrieben]].

* http://www.freedesktop.org/wiki/Software/systemd/

''Er startet also als erstes ([[https://de.wikipedia.org/wiki/Process_identifier PID1]]), regelt und steuert dabei alle weiteren Dienste. Er beendet sich beim Herunterfahren als letztes. Der daemon systemd ist damit also tief im Ablauf eines Systemstarts verwurzelt.''

'''Wichtiges dazu:'''
* [[Bootmanager]]
* [[Bootvorgang]]
* [[YaST2_Dienste-Verwaltung|YaST2 Dienste-Verwaltung]]
 

= SUSE wechsel zu systemd =
Mit unter liebevoll vollzieht sich der Wechsel zu systemd als Init-System in SUSE mit Sätzen, zitert aus den Releasenotes und dem Adminguide zu [[https://www.suse.com/ SUSE Linux Enterprise Server 12]], wie:
<blockquote><pre style="background-color: #D4FFEF; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">New core technologies like systemd (replacing the time honored System V based init process) </pre></blockquote>
'''Versuchsweise frei übersetzt:''' ''Neue Kerntechnologien wie systemd (ersetzen den durch lange Dienstzeit geehrten System V basierten init prozess).''
<blockquote><pre style="background-color: #D4FFEF; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Starting with SUSE Linux Enterprise Server 12 systemd is a replacement for the popular System V init daemon. systemd is fully compatible with System V init (by supporting init scripts). </pre></blockquote>
'''Versuchsweise frei übersetzt:''' ''Beginnend mit [[https://www.suse.com/ SUSE Linux Enterprise Server 12]] ist systemd ein Ersatz für den populären System V init daemon. Er ist voll kompatibel mit dem System V Init-Vorgang, indem er Init Skripte unterstützt.''

= Integration in [[YaST]] =
{|
|rowspan=2|[[Bild:Yast.png]]
|colspan=3|Wie sich systemd im grafischen Konfigurationstool für [[openSUSE]] integriert, könnt ihr hier sehen:
|-
|style="text-align:center;"| ---------->
|style="text-align:center;"|[[YaST2_Dienste-Verwaltung|YaST2: Diensteverwaltung]]
|style="text-align:center;"| <----------
|-
|}

=Kompatibilität=
Als sogenanntes "drop-in replacement". Bietet systemd Kompatibilität zu seinen Vorgängern:
 
* kompatibel mit [[https://de.wikipedia.org/wiki/Linux_Standard_Base LSB]] init Skripten
* kompatibel mit SysV
Hier gibt es zu beachten, dass systemd nicht vollständig rückwärts kompatibel ist.
Einige Einschränkungen können hier nachgelesen werden: http://www.freedesktop.org/wiki/Software/systemd/Incompatibilities/

=Kritik=
Da ich nicht unnötig falsches sagen möchte, was Kritik gegenüber systemd angeht. Und da ich nur einige Grundlagen objektiv darstellen will, kann ich dazu nicht viel sagen. Allerdings kann ich folgendes berichten:
* Bei Linux Entwicklern als auch Benutzern steht systemd im Mittelpunkt der Kritik, da es im Ansatz sehr wichtige Kernfunktionen steuert und auch das alt eingefahrene SysV-Init ersetzen kann, bzw. kompatibel ist.
* Zu diesem Thema gibt es massenweise Informationen im Internet.
'''Ein besonders wichtiger Punkt:'''
* Es gibt viele Gegner als auch Befürworter.
 
{{Hinweis|'''Wer möchte informiert sich darüber bitte detaillierter mithilfe einer Suchmaschine eigener Wahl.'''}}
{{Hinweis|'''Das Forum würde sich hierfür als Diskussionsplatform anbieten, wer möchte. Es gibt sicher einige die an dieser Thematik interesse haben. http://forum.linux-club.de/'''}} 
---------
'''Meine Meinung zur Kritik:''' 
(Wer mir diesen Raum nicht lassen möchte: Bitte "skipping").
 
''Ich finde es wichtig, dass derart grundlegende Kernstrukturen im Betriebssystem kritisiert werden, solange es zielführend und im Sinne eines sicheren und korrekten Funktionierens und damit im Sinne des Endverbrauchers als auch der Entwickler ist. Was ich nicht verstehen kann, wenn Leute nur sagen "systemd ist mist ich will wieder das alte SysV-Init, weil ich mit systemd nicht umgehen kann." Deswegen möchte ich hier sagen:''
 
"''Bitte ich gebe euch Gelegenheit, euch zu informieren. Und ich hoffe dies halbwegs richtig zu machen.''"
---------

=Fähigkeiten=
Als Verwaltungsinstrument bringt systemd einige Neuerungen und Verbesserungen, setzt dabei allerdings auch stark auf alt bewährtes. Um nur einiges an Neuerungen und Fähigkeiten zu nennen:

* Fähigkeit zur aggressiven Parallelisierung
* Nutzt Socket und [[https://en.wikipedia.org/wiki/D-Bus D-Bus]] Aktivierung um Prozesse zu starten
* Bietet ein "auf Bedarf"-basiertes starten von Diensten
* Überwacht Prozesse die [[https://en.wikipedia.org/wiki/Cgroups cgroups]] verwenden
* unterstützt [[https://de.opensuse.org/SDB:Snapper Schnappschüsse]] und deren Wiederherstellung
* Verwaltet [[Zugriffsrechte#mount|mount und automount]] Einhängepunkte
* Implementiert abhängigkeitsbasierte Logik für Dienste
* Kann SysV-Init als drop-in ersetzen.
* uvm.
{{Hinweis|Mit Parallelisierung ist das Resultat dieser Prinzipien: [[https://de.wikipedia.org/wiki/Nebenläufigkeit Nebenläufigkeit]] bzw. [[https://de.wikipedia.org/wiki/Parallele_Programmierung Parallele Programmierung]] gemeint. Die wörter [[https://de.wikipedia.org/wiki/Bedarf Bedarf]] und [[Systemd#Abhängigkeit_darstellen:|Abhängigkeit]] müssen in der Auflistung differenziert werden.}}
 

=systemd Steuern=
Es gibt verschiedene Wege, wie systemd gesteuert werden kann. Einmal gibt es grafische Tools, wie die [[YaST2_Dienste-Verwaltung|Dienste-Verwaltung]] in [[YaST]]. Das ehemals benannte Menü: "Runlevel-Editor" nennt sich heute bei Migration zu systemd "Dienste-Verwaltung". Dann gibt es noch die Möglichkeit mit der [[Shell]]. Eine vollständige auflistung der Steuerungsmöglichkeiten, würde den Rahmen dieser Doku total sprengen. Ich nenne hier einige aus Nutzersicht durchaus wichtige Möglichkeiten:

{| class="wikitable"
|+Mitgelieferte Tools:
|-
|'''[[#Umgang_mit_systemctl|systemctl]]'''
|''(Den System- und Dienstmanager steuern.)''
|-
|'''[[#Umgang_mit_journalctl|journalctl]]'''
|''(Das systemd journal abfragen. Also logs.)''
|-
|'''[[#Tipp: systemd-tmpfiles|systemd-tmpfiles]]'''
|''(Erstellt und löscht temporäre Strukturen.)''
|-
|'''[[#Umgang_mit_systemd-analyze|systemd-analyze]]'''
|''(Analysiert die boot Geschwindigkeit.)''
|-
|'''[[#Umgang_mit_loginctl|loginctl]]'''
|''(Anbindung an die Sitzungsverwaltung)''
|-
|'''.. uvm.'''
|''(Alle die ich nicht nennen konnte)''
|-
|}

=Umgang mit systemctl=
Bitte zum detaillierten Umgang mit systemctl die [[Man_pages|manpage]] lesen. Oder beispielsweise im (Achtung externer Link): [https://www.suse.com/documentation/sles-12/book_sle_admin/data/sec_boot_systemd_basics.html Adminguide] nachschlagen.
<pre style="background-color: #FFFFC0">man systemctl</pre>
Nachfolgend einige einfache Befehle, die empfehlungsweise bekannt sein sollten.

==Dienste Starten und Beenden==
'''Starten'''
<pre style="background-color: #FFFFC0">systemctl start mein_dienst</pre>
'''Beenden'''
<pre style="background-color: #FFFFC0">systemctl stop mein_dienst</pre>

==Automatischen Start De-/Aktivieren==
'''Automatischen Start aktivieren:'''
<pre style="background-color: #FFFFC0">systemctl enable mein_dienst</pre>
'''Automatischen Start deaktivieren:'''
<pre style="background-color: #FFFFC0">systemctl disable mein_dienst</pre>

==Status eines Dienstes abfragen==
<pre style="background-color: #FFFFC0">systemctl status mein_dienst</pre>
In der Ausgabe würde das bei einem erfolgreich gestarteten und für den automatischen Start konfigurierten Dienst in etwa so aussehen:
<blockquote><pre style="background-color: #D4FFEF; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">
mein_dienst.service - mein_dienst Daemon
Loaded: loaded (/usr/lib/systemd/system/mein_dienst.service; enabled)
Active: active (running) since Sa 2015-08-22 02:17:01 CEST; 1s ago
Process: 6717 ExecStartPre=/usr/sbin/mein_dienst (code=exited, status=0/SUCCESS)
Main PID: 6721 (mein_dienst)
</pre></blockquote>

==systemd neu laden==
Angenommen, es wurden beispielsweise Änderungen an mein_dienst.service Dateien vorgenommen, muss systemd neu geladen werden, damit sie sofort wirksam werden.
<pre style="background-color: #FFFFC0">systemctl daemon-reload</pre>

=Wo sind meine Logs hin?=
{{Hinweis|'''Umsteigern von SysV-Init auf systemd empfehle ich zum Thema Log´s dies:'''}}
<pre style="background-color: #FFFFC0">less /var/log/README</pre>
'''Darin steht in etwa (versuchsweise frei übersetzt):''' 
<blockquote><pre style="background-color: #D4FFEF; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">
Sie suchen die traditionellen text log Dateien in /var/log, und diese sind verschwunden?

Hier eine erklärung, was vor sich geht:

Sie betreiben ein systemd basiertes BS in dem syslog durch das Journal ersetzt wurde. Das Journal speichert die selben (und mehr) Informationen wie das klassische syslog. Um das Journal zu nutzen und auf die Logdaten zuzugreifen, führen Sie einfach "journalctl" aus, welches die Logdaten in dem identischen textbasierten Format ausgeben wird, wie es auch mit syslog der Fall war. Für weitere Details, sehen Sie bitte journalctl(1) ein.
...
Thank you!
</pre></blockquote>
Das heisst, es bietet sich hier die Gelegenheit mit dem neuen Journal vertraut zu werden.
In folgenden Abschnitten möchte ich deswegen eine kurze Einleitung zum Umgang anbieten.

=Umgang mit journalctl=
Der Dienst systemd beinhaltet seinen eigenen Dienst zur Systemprotokollierung. Die Sammlung all dieser Informationen wird als journal bezeichnet. Diese Instanz sammelt wichtige Informationen und stellt diese wiederum zur Abfrage bereit. Das ist insbesondere zur Systemüberwachung von Nutzen. Es kann beispielsweise mit Hilfe von journalctl ein fehlerhafter Systemstart diagnostiziert werden. Angenommen dies wäre der Fall, so wird spätestens an dieser Stelle ein gewisses Grundwissen zum Umgang mit journalctl erforderlich, wenn es darum geht konkrete Fehlermeldungen bereitzustellen.
{{Hinweis|'''Generell erfolgt die Ansicht der Protokolle automatisch in einem Pager.'''}}
==Das journal betrachten:==
<pre style="background-color: #FFFFC0">journalctl</pre>
Wenn einfach nur 'journalctl' ausgeführt wird, zeigt ein pager das komplette journal, beginnend mit dem ältesten Eintrag.

==Nützliche Schalter==
Es gibt viele weitere wichtige Filter. Hier einige wenige, die bekannt sein sollten:
{| class="wikitable"
|+Schalter
|-
|"-k"
|dmesg betrachten
|-
|"-b"
|Bootvorgänge
|-
|"-u"
|Nach Unit bzw. Dienst
|-
|"-f"
|aktualisiert den Pager mit neuen Einträgen
|}
Für mehr Details bitte die [[Man_pages|manpage]] lesen.

==Das Startprotokoll==
<pre style="background-color: #FFFFC0">journalctl -b</pre>
Der Schalter '-b' sagt journalctl, dass das gesamte Startprotokoll gezeigt werden soll.

===Das Startprotokoll filtern===
Angenommen, es möchte nur ein bestimmtes Startprotokoll eingesehen werden. Etwa vom vorhergehenden Systemstart:
<pre style="background-color: #FFFFC0">journalctl --list-boots</pre>
(Gibt eine Liste vorangegangener Protokolle in einer Übersicht aus). Die erste Spalte kann als Indikator herangezogen werden. Beispielausgabe:
<blockquote><pre style="background-color: #D4FFEF; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"> ..
...
-2 9daa81e2ec374cb1b6adba8d96896605 Sa 2015-08-29 23:26:53 CEST—Sa 2015-08-29 23:49:17 CEST
-1 c430ed034607494ba2a3bc1ded4e4972 Sa 2015-08-29 23:49:35 CEST—Sa 2015-08-29 23:54:27 CEST
0 1f3a7894d0f34f4392c5517b83279c4d Sa 2015-08-29 23:54:53 CEST—So 2015-08-30 16:22:40 CEST</pre></blockquote>
Das gewünschte Startprotokoll wird durch Übergabe des jeweiligen Indikator im Pager dargestellt:
<pre style="background-color: #FFFFC0">journalctl -b -1</pre>

===journalctl -xb===
Wenn der Computer beispielsweise aufgrund eines Stromausfall im Emergency Mode startet, wird in der Shell statt dem grafischen Modus ein Login angeboten. Hier schlägt der Rechner oft vor, es solle die Ausgabe von 'journalctl -xb' zu Rate gezogen werden. Also das Startprotokoll prüfen:
<pre style="background-color: #FFFFC0">journalctl -xb</pre>
{| class="wikitable"
|+ Schalter
|-
|"-x"
|Blendet nützliche Hilfetexte in der Ausgabe ein.
|-
|"-b"
|Das Bootprotokoll anzeigen.
|-
|}

==journalctl -xn==
Duch den Schalter -n kann man die Ausgabe auf eine bestimmte Anzahl Zeilen beschränken. Wenn keine Zahl übergeben wird, werden die letzten 10 Zeilen ausgegeben. Beispielsweise die letzten 25 Zeilen ausgeben und Hilfstexte einblenden:
<pre style="background-color: #FFFFC0">journalctl -xn 25</pre>
{| class="wikitable"
|+ Schalter
|-
|"-x"
|Blendet nützliche Hilfetexte in der Ausgabe ein.
|-
|"-n"
|Ausgabe auf bestimmte Zeilenanzahl beschränken.
|-
|}

==Filtern nach Unit==
Angenommen es sollen nur Logeinträge zum Unit oder Dienst "sshd" in der Ausgabe angezeigt werden.
<pre style="background-color: #FFFFC0">journalctl -u sshd</pre>

==Eigener Filter==
Die Ausgabe von journalctl kann auch umgeleitet werden. So wird im folgenden Beispiel das ganze Systemprotokoll unter zuhilfenahme von 'egrep' nach Vorkommnissen von "Error" und "Failed" durchsucht. Die Ausgabe wird dann an einen Pager (less) umgeleitet:
<pre style="background-color: #FFFFC0">journalctl | egrep "Error|Failed" | less</pre>

==Speicherplatzbelegung==
Jedes Log wird für eine gewisse Dauer aufbewahrt. Das ist besonders für Systemadministratoren von besonderer Bedeutung, da Computer oft über einen längeren Zeitraum überwacht werden müssen. Einige Daten werden also permanent auf der Festplatte abgelegt. Von Haus aus sind seitens systemd für diese Informationen 10 Prozent des betroffenen Dateisystems vorgesehen. Bei einem Dateisystem mit 1 TiB Speicherplatz wären dies also 100 GiB logdaten, die von systemd angesammelt würden. Das Journal wird allerdings auch noch komprimiert.
{| class="wikitable"
|+Schalter für journalctl
|-
|"--disk-usage"
|Speicherplatzbelegung des Journal auf dem Datenträger zeigen.
|}
Wer auf die voreingestellten Limits und den dafür vorgesehenen Speicherplatz Einfluss haben möchte, kann dies in der Konfigurationsdatei tun:
<blockquote><pre style="background-color: #D4FFEF">/etc/systemd/journald.conf</pre></blockquote>
So liesse sich beispielsweise mit diesem Schalter das Journal auf eine Größe von 100M beschränken. Ich fände auch einen Wert bis 300M noch sinnvoll wieviel hier eingestellt wird, liegt an der eigenen Nutzenvorstellung:
<pre style="background-color: #FFFFC0">SystemMaxUse=100M</pre>
Zum Verständnis der Grössenrelation: [[Megabyte |Megabyte/Mibibyte]] 
Und Achtung externer Link: https://de.wikipedia.org/wiki/Datenmenge
{{Hinweis|'''Die Daten werden im Journal in anderer Form und komprimiert abgelegt. Dennoch, um eine Vorstellung zu haben: Eine Textdatei gefüllt mit Rautezeichen, die ein A4 Brief ausfüllen würden, hat ca. 4,1 KiB. Eine Ansammlung von 100 GiB mit solchen Dateien entspräche in etwa 261 888 249 Dokumente oder Seiten. Eine Packung Schreibmaschinenpapier hat ca 100 Blatt.'''}}
 

=Umgang mit systemd-analyze=
Der Befehl systemd-analyze kann dazu genutzt werden, die Leistung eines Systemstarts zu messen. Beispielsweise wie lange es dauert, bis ein bestimmtes festgelegtes Ziel beim Boot erreicht wurde. Ich möchte hier nur Kleinigkeiten zeigen, damit Verständnis erlangt werden kann, was denn bei einem Systemstart von gerade mal 20 Sekunden so alles abgeht. Auch hier bitte ich darum, zu Details wieder die manpage heranzuziehen.

==Startzeitanalyse==
<blockquote>'''Einfach ohne Zusätzliche Schalter:'''
<pre style="background-color: #FFFFC0">systemd-analyze</pre>
'''Beispielausgabe:'''
<blockquote><pre style="background-color: #D4FFEF; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Startup finished in 1.433s (kernel) + 493ms (initrd) + 17.842s (userspace) = 19.769s</pre></blockquote>
Die Ausgabe sollte weitestgehend selbsterklärend sein. Angegebene Messwerte sind an diesem Beispiel in Sekunden und Millisekunden.
</blockquote>

==Messung grafisch darstellen==
Es kann eine SVG Grafik als sog. "plot" erstellt werden, der in Details aufzeigt welche Systemdienste zu welcher Zeit gestartet wurden. Dabei wird visuell hervorgehoben, wie viel Zeit alle Dienste zur Initialisierung benötigten. 
-----
==='''Startzeiten aller Prozesse:'''===
<blockquote>{{Hinweis|'''Ich leite Die Ausgabe gleich in eine Datei um und öffne diese mit "gwenview":'''}}
<pre style="background-color: #FFFFC0; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">systemd-analyze plot > /tmp/plot.svg | gwenview /tmp/plot.svg</pre>
{{Achtung|Die SVG Datei ist zwar - nur - ca. 140k groß, das darstellen dieser Grafik kann aber sehr aufwendig für den Computer sein. Nachfolgend nur ein kleiner Ausschnitt aus so einer Grafik als GIF.}}
[[Bild:systemd-analyze_plot.gif|center|'''Plot als Grafik''']]
Hier kann man sehr schön sehen, was systemd beim Startvorgang so alles anstellen muss. Und was denn eigentlich so alles in diesen 20 Sekunden passiert bis am Beispielsystem ein vollständiger Systemstart abgeschlossen ist. </blockquote>
--------
==='''Abhängigkeit darstellen:''' ===
<blockquote>Wer das interessant fand, möchte eventuell die Möglichkeit nutzen sich grafisch darstellen zu lassen in welchen Abhängigkeiten ein Dienst gestartet wurde.
{{Hinweis|'''Ich leite Die Ausgabe am Beispiel "avahi-daemon" gleich in eine Datei um und öffne diese mit "gwenview":'''}}

<pre style="background-color: #FFFFC0; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">systemd-analyze dot 'avahi-daemon.*' | dot -Tsvg > /tmp/avahi.svg | gwenview /tmp/avahi.svg</pre>{{Achtung|'''Das ist ein Einzeiler!'''}}
Das Ergebnis präsentiert sich dann so (zu .gif umgewandelt):
[[Bild:Systemd-analyze_avahi.gif|center|'''Prozessabhängigkeit als Grafik''']]
</blockquote>
 

=Umgang mit loginctl=
Als wichtiger Systemdienst bindet sich systemd auch an den Anmeldevorgang im Betriebssystem. Dafür stellt er einen extra Dienst "systemd-login" zur Verfügung. Der Dienst bietet an dieser Stelle ein Anbindung an die D-Bus Schnittstelle. Wichtige Grundlagen betreffend Zugriffsberechtigungen: [[Zugriffsrechte]]

Das Tool loginctl kann dazu verwendet werden, Einblicke in den Status von Benutzeranmeldungen zu erlangen. Ausserdem kann es verwendet werden Veränderungen am Systemstatus vorzunehmen.

So können [[https://de.wikipedia.org/wiki/Portable_Operating_System_Interface POSIX]] kompatible Signale an Benutzersitzungen gesendet werden, wie beispielsweise [[https://de.wikipedia.org/wiki/SIGTERM SIGTERM]]. Das ist ein Signal zum Terminieren von Programmprozessen.
{{Warnung|'''Dieses Werkzeug sollte nur von erfahrenen Benutzern verwendet werden.'''}}
'''Hier nur ein ganz einfaches ungefährliches Anwendungsbeispiel:'''
<pre style="background-color: #FFFFC0">loginctl</pre>
'''Listet laufende Benutzersitzungen:'''
<blockquote><pre style="background-color: #D4FFEF"> SESSION UID USER SEAT
1 1000 user seat0</pre></blockquote>
 

=systemd-tmpfiles=
'''Grundlegendes:''' 
Der Dienst systemd-tmpfiles ist im System für die Verwaltung temporärer Dateisystemstrukturen zuständig. Er erstellt und löscht diese kann sie aber auch bereinigen. ..usw. Einige dieser Strukturen bestehen bei einem Linux Betriebssystem als persistenter bzw. weniger persistenter Ablagebereich. Gedacht ist das für Dateien, die entweder vorübergehend bzw. begrenzt oder längerfristig vorhanden sein müssen.

'''Interessant und erwähnenswert an dieser Stelle:''' 
Systemd hängt einige Dateisystemstrukturen automatisch als "tmpfs" ein. Dazu gehört beispielsweise auch der Pfad "/tmp". Wie dies geschieht, kann anhand des betreffenden tmp.mount units eingesehen werden. Aus dem Inhalt ergibt sich:
<blockquote><pre style="background-color: #D4FFEF; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">[Mount]
What=tmpfs
Where=/tmp
Type=tmpfs
Options=mode=1777,strictatime</pre></blockquote>
'''Ein zu SysV-Init zeiten nötiger [[fstab|fstab Eintrag]] hätte so ausgesehen:'''
<blockquote><pre style="background-color: #D4FFEF; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">tmpfs /tmp tmpfs defaults,strictatime,mode=1777 0 0</pre></blockquote>
<blockquote>
{{Hinweis|'''Der Pfad '/var/tmp/' wird hingegen beispielsweise nicht als tmpfs eingehängt. Ist dafür auch nicht bestimmt.'''}}
</blockquote>

{{Achtung|'''Der Tipp dazu: [[Tipp: systemd-tmpfiles]]'''}}
 

=Tipp: weekly trim durch systemd=
Das Paket 'util-linux-systemd' bringt einen Dienst mit, der es ermöglicht seine SSD wöchentlich trimmen zu lassen. Es gibt zu beachten, dass trim auf unterschiedlichem Weg im Betriebssystem zur [[SSD_Optimierungen|Optimierung von SSD's]] realisiert werden kann:
{| class="wikitable"
|+ Trim
|-
|Online discard (trim)
|moutoption "discard"
|Ersetzt batched trim und Skripte sowie manuelle Ausführung.
|-
|Manuell
|Durch ausführen des 'fstrim' Kommando in der Shell.
|[[http://man7.org/linux/man-pages/man8/fstrim.8.html man fstrim]]
|-
|rowspan="3"|Batched trim bzw. Mitgelieferte Skripte
|(eigener Skript) Bsp.: [[http://linux-club.de/wiki/opensuse/Batched-trim.sh ext4-trim.sh]]
|[[http://man7.org/linux/man-pages/man8/fstrim.8.html man fstrim]]
|-
|openSUSE bringt beispielsweise für [[https://de.wikipedia.org/wiki/Btrfs btrfs]] einen durch sysconfig steuerbaren trim Skript mit. ('btrfs-trim.sh');
|Funktioniert zum Stand von openSUSE 13.2 nur beim Einsatz von [[https://de.wikipedia.org/wiki/Btrfs btrfs]].
|-
|systemd bringt diese Möglichkeit als Dienst oder unit. ('fstrim.timer') - ('fstrim.service')
|Keine Einschränkung durch "automatik". "fstrim -a" beispielsweise bei ext4.
|-
|}
Wichtig ist zu beachten dass diese Kommandos nicht unnötig mehrfach ausgeführt werden oder vermischt zum Einsatz kommen. Einmal die Woche sollte bei batched trim völlig ausreichend sein. Wenn also die in openSUSE integrierte Trimfunktion nicht genutzt werden möchte, kann diese durch die von systemd durchaus ersetzt werden. Wenn beispielsweise Online discard verwendet wird, werden andere Skripte obsolet.
{{Achtung|'''Ich möchte hier nochmal darauf hinweisen, dass andere Skripte bei Nutzung von systemd zu diesem Zweck deaktiviert werden sollten! Und bei der mount option discard wird batched trim obsolet.'''}}
'''Folgendes genügt zum aktivieren der systemd variante:'''
<pre style="background-color: #FFFFC0">systemctl enable fstrim.timer</pre>
(''Der zugehörige fstrim.service wird vom Timer automatisch zur Ausführung aktiviert.'')
{{Hinweis|'''Es wird eine Datei mit einem Zeitstempel erstellt anhand dessen die letzte und nächste Ausführung nach dem ersten Aufruf abgehandelt wird.'''}}
'''Der eigentliche Dienst heisst:'''
<blockquote><pre style="background-color: #D4FFEF">fstrim.service</pre></blockquote>
'''Eine Steuerungsmöglichkeit hierfür ist auch:'''
<pre style="background-color: #FFFFC0">rcfstrim</pre>
'''Der Stempel befindet sich dann hier:'''
<blockquote><pre style="background-color: #D4FFEF">/usr/lib/systemd/system/fstrim.timer</pre></blockquote>
'''Der Dienst führt zurzeit wöchentlich folgendes Kommando aus:''' 
''Dies behandelt schlicht und automatisch alle eingehängten Dateisysteme mit trim.''
<pre style="background-color: #FFFFC0">fstrim -a</pre>
{{Warnung|'''Nicht jede SSD und SATA controller unterstützen jede TRIM Funktionalität. D.h. einige Geräte sind auf batched-discard angewiesen. Einige können mit Online-discard arbeiten, andere nicht. Einige haben wiederum Schwierigkeiten bei trim in Verbindung mit NCQ.'''}}
{{Hinweis|'''Es bietet sich auch an, dieses unit manuell durch einen eigenen Skript aufzurüsten.'''}}

 

=Quellen / Links:=
* https://www.suse.com/releasenotes/x86_64/SUSE-SLES/12/
* http://www.freedesktop.org/wiki/Software/systemd/
* https://www.suse.com/documentation/sles-12/book_sle_admin/data/cha_systemd.html
* https://de.wikipedia.org
* http://man7.org/
*[https://fedoraproject.org/wiki/Systemd fedoraproject.org wiki] {{englisch}}

[[Kategorie:Bootmanager‏‎]] [[Kategorie:systemd]]

GRUB 2

2015-11-18T14:52:28Z

Gehrke: /* Die Kommandozeile */

{{Lückenhaft|Im aktuellen Zustand beschreibt dieser Artikel ausschließlich Systeme mit herkömmlichen [[BIOS]], aber nicht die zunehmend weiter verbreiteten [[UEFI]]-Systeme. Diese Technologie und ihre Implikationen auf GRUB2 sollte in zukünftigen Versionen das Artikels berücksichtigt werden.}}

GNU GRUB (GRand Unified Bootloader)

=Abgrenzung zu 'GRUB Legacy'=
''GRUB 2'' ist eine vollständige Neuentwicklung des Vorgängers [[GRUB Legacy]]. Seit 2009 wird es in größeren Distributionen als Standard eingeführt, [[OpenSUSE]] beispielsweise vollführte diesen Schritt mit Release 12.2 im Herbst 2012.

Um eine Reihe neuer Funktionalitäten anbieten zu können, haben sich die Entwickler für eine radikale Neu-Implementierung entschieden. Es gibt dementsprechend bis auf den Namen kaum Gemeinsamkeiten und bewusst wurde auf '''Kompatibilität zum Vorgänger verzichtet'''.

Die aktuelle Version kann beispielsweise so abgefragt werden:
<pre>
# rpm -qv grub2
grub2-2.00-39.1.3.x86_64

# grub2-install -v
grub2-install (GRUB2) 2.00
</pre>

==Erweiterte Funktionalitäten==
*Script-gesteuerte, dynamischere Konfiguration
*Unterstützung von mehr [[Dateisystem]]en wie beispielsweise [[ext4]], HFS+, [[NTFS]] ([http://www.gnu.org/software/grub/manual/html_node/Internationalisation.html#Filesystems vollständige Liste])
*Direkter Zugriff auf [[LVM]] und [[RAID]]-Devices möglich
*Steuerung über ein graphisches Terminal (besonders ''Rescue Mode'') und graphisches Menüsystem gegeben
*Mehrsprachigkeit inklusive der Einträge
*Zusätzliche Unterstützung für weitere Systemsoftware neben PC [[BIOS]]: [[UEFI|PC EFI]], PC coreboot, PowerPC, SPARC, MIPS Lemote Yeeloong
*Support für Boot via Netzwerk über [[tftp]] (PXE)
*Zugriff über serielle Konsole möglich (vor allem Embedded Devices)
*Boot Password möglich
*Start von LiveCD ISO-Images direkt von der Festplatte möglich
*Unterstützung von weiteren Plattformen neben x86 (z.B. PowerPC)
*Einführung eines Modells zur Erzeugung von angepassten Layouts (Themes)

==Unterschiede zu 'GRUB Legacy'==
An dieser Stelle werden die Unterschiede zu [[GRUB Legacy]] hervorgehoben:
*In ''Grub 2'' existiert die stufenweise Reihenfolge in den Einzelphasen ('Stage 1', 'Stage 1.5', 'Stage 2') nicht mehr.
*In der Konfiguration werden Partitionen ebenfalls über Zahlen adressiert, aber die Nummerierung beginnt mit 1 (und nicht 0).
:*Hinweis: Das gilt aber nur für Partitionen, nicht für Festplatten. Festplatten werden mit 'hdX' benannt und X beginnt bei 0!
*Die Konfiguration wurde komplett umgestellt. Wo früher eine einzelne Datei (menu.lst) zu editieren war, gibt es heute ein komplettes Konfigurationssystem aus vielen Dateien mit eigener Struktur und eigenem Build-System, welches die eigentlichen Konfigurationsdateien generiert (s. [[#Konfiguration]]).

=Installation=
{{Lückenhaft|Im aktuellen Zustand beschreibt dieser Artikel ausschließlich Systeme, welche das [[MBR]]-Partitionierungsschema verwenden. Andere Schemata wie beispielsweise [[GPT]] werden hier derzeit nicht behandelt. Da GPT-Partitionierung zunehmend an Verbreitung gewinnt, sollte dies in zukünftigen Versionen das Artikels berücksichtigt werden.}}

Analog zum Vorgänger wird zur Installation des Boot-Sektors das Script 'grub2-install' verwendet. Als Parameter wird das Ziel-Device angegeben (im Beispiel der [[MBR]] der ersten Festplatten 'sda'):
<pre>
# grub2-install /dev/sda
Installation finished. No error reported.
</pre>
Alternativ können auch Partitionen ausgewählt werden.

Unter [[OpenSUSE]] ist alternativ zu verwenden:
*yast2 bootloader

{{Box Achtung||Dieser Schritt überschreibt möglicherweise [[Bootmanager]] anderer Systeme!}}

=Konfiguration=

==Die Kommandozeile==
''GRUB2'' verfügt über eine eingebaute Shell, welche unter anderem TAB-Completion beherrscht. Diese kann entweder direkt angesteuert werden oder wird angezeigt, wenn es Probleme mit einer invaliden Konfiguration gibt.

Hier können die selben Befehle verwendet werden, die in der Konfiguration möglich sind. Damit können beispielsweise im ''Rescue Mode'' beliebige Systeme manuell gestartet werden.

Direkt angesteuert werden kann die Kommandozeile innerhalb des [[#Der Editor|Editors]] mit den Tasten 'Ctrl-C' oder 'F2', Verlassen funktioniert via 'ESC'.

==Der Editor==
[[Bild:GRUB2-editor.png|right|thumb|300px|Der GRUB2-Editor (Beispiel)]]''GRUB2'' verfügt auch über einen eingebauten Editor. Dieser erlaubt es, einen ausgewählten Boot-Eintrag zu verändern. Dies kann sehr nützlich sein in Situationen, in denen die aktuelle Konfiguration nicht zu einem sauber gebooteten System führt - beispielsweise bei einem defekten Grafikkartentreiber infolge eines missglückten Updates.

In solchen Fällen ist es manchmal hilfreich, beim Start bestimmte Kernel-Parameter mitzugeben oder den Runlevel zu verändern.

Ein weiterer möglicher Anwendungsfall ist das schnelle Ausprobieren von Konfigurationsänderungen ohne Gefahr zu laufen, das System dauerhaft in einen Fehlerzustand zu versetzen (nicht persistente Änderung).

Dieser Editor wird aufgerufen, indem in der Anzeigephase von GRUB2 ein Eintrag ausgewählt und dann die Taste 'E' gedrückt wird. Daraufhin wird genau dieser betreffende Eintrag aus der aktuellen Datei ''grub.cfg'' in einen Editor geladen und kann dort verändert werden. Für die Steuerung des Editors gibt es eine Handvoll Tastenkürzel, welche unter dem Editor kurz aufgeführt werden. Mit 'ESC' verwirft man die Änderungen und kommt zur Auswahl zurück, mit 'Ctrl-X' oder 'F10' bootet man das System mit den angepassten Parametern.

Die Änderungen sind einmalig und werden nicht persistiert!

==YaST: boot loader==
[[OpenSUSE]]-typisch kann man einige Einstellungen auch in der Systemverwaltung [[YaST]] unter ''System / boot loader'' vornehmen.

==Default-Konfiguration: /etc/default/grub==
Globale Grundeinstellungen (Timeout, Standard-Eintrag, Layout...) werden hier definiert.

==/etc/sysconfig/bootloader==
Diese Datei enthält Konfigurationsoptionen, welche von der ''perl-bootloader library'' verwendet werden. Dies passiert dann, wenn eine Konfiguration über [[YaST]] durchgeführt wird oder ein neuer [[Kernel]] installiert wird.

Diese Datei ist [[openSUSE]]-spezifisch. Die Optionen hier werden auch nicht ausschließlich für ''GRUB 2'' verwendet, sondern auch bei anderen supporteten [[Bootmanager]]n.

==Buildsystem: /etc/grub.d==
Das Buildsystem ist eine Sammlung von Scripten. Ein Nummernpräfix sorgt für eine Abfolge in definierter Reihenfolge (bei '00' beginnend):
<pre>
# ls -l /etc/grub.d
-rwxr-xr-x 1 root root 7649 Jul 31 11:48 00_header
-rwxr-xr-x 1 root root 10535 Jul 31 11:48 10_linux
-rwxr-xr-x 1 root root 11019 Jul 31 11:48 20_linux_xen
-rwxr-xr-x 1 root root 1802 Jul 31 11:49 20_memtest86+
-rwxr-xr-x 1 root root 2596 Jul 31 11:48 20_ppc_terminfo
-rwxr-xr-x 1 root root 10132 Jul 31 11:48 30_os-prober
-rwxr-xr-x 1 root root 489 Jul 11 15:04 40_custom
-rwxr-xr-x 1 root root 216 Jul 31 11:48 41_custom
-rwxr-xr-x 1 root root 1259 Jul 31 11:49 90_persistent
-rw-r--r-- 1 root root 483 Jul 31 11:48 README
</pre>
Dieses Beispiel stammt aus einer [[OpenSUSE]]-Installation (Release 12.3). Andere Distribution liefern geringfügig andere Scripten aus. Es können diesem Schema entsprechend auch eigene Scripte hinzugefügt werden.

Bedeutung der Standard-Scripten:
*00_header: Initialisierung des Systems anhand der Einträge in /etc/default/grub ([[#Default-Konfiguration: /etc/default/grub|Default-Konfiguration]]).
*10_linux: Hier wird versucht, alle validen Kernel zu finden. Aus diesen wird dann das Bootmenü generiert.
*20_linux_xen: Für den Hypervisor [[Xen]] sind dedizierte Kernel notwendig. Hier wird die notwendige Parametrisierung hierfür durchgeführt.
*20_memtest86+: Aufnahme von [[memtest]] in das Bootmenü.
*20_ppc_terminfo: <ToDo: Funktionalität noch beschreiben>
*30_os-prober: Suche nach weiteren Bootladern sowie weiteren installierten Betriebssystemen. In einem Multi-Boot-Kontext werden hier Einträge beispielsweise für Windows oder parallele Linux-Installationen generiert.
*40_custom: Eigene Booteinträge können hier manuell hinterlegt werden. Dieses Script wird bei System-Updates nicht überschrieben.
*41_custom: Einbindung der Datei /boot/grub/custom.cfg
*90_persistent: Teile aus der aktuellen grub.cfg können hier rein kopiert werden. Dieser Inhalt wird bei einem erneuten Durchlauf des Build-Systems '''nicht''' überschrieben.

Siehe auch: [[#Konfiguration neu generieren]]

==Module laden==
''GRUB 2'' bietet direkten Zugriff auf bestimmte Ressourcen wie beispielsweise [[LVM]], [[RAID]] oder diverse [[Dateisysteme]]. Dieser Zugriff wird über Module implementiert, welche per 'insmod' bei Bedarf geladen werden können.

Unter [[OpenSUSE]] liegen diese Module (architekturabhängig) unter:
<pre>
# tree -d /usr/lib/grub2/
/usr/lib/grub2/
├── i386-pc
└── x86_64-efi
</pre>

Verfügbare Module (nur x86_64-efi):
<pre>
# ls -r --format=commas *.mod
zfsinfo.mod, zfscrypt.mod, zfs.mod, xzio.mod, xnu_uuid.mod, xnu.mod, xfs.mod, videotest.mod, videoinfo.mod, video_fb.mod, video_cirrus.mod, video_bochs.mod, video.mod,
usbtest.mod, usbserial_pl2303.mod, usbserial_ftdi.mod, usbserial_common.mod, usbms.mod, usb_keyboard.mod, usb.mod, uhci.mod, ufs2.mod, ufs1.mod, udf.mod, true.mod, trig.mod,
time.mod, tga.mod, tftp.mod, testload.mod, test_blockarg.mod, test.mod, terminfo.mod, terminal.mod, tar.mod, squash4.mod, sleep.mod, sfs.mod, setpci.mod, setjmp.mod,
serial.mod, search_label.mod, search_fs_uuid.mod, search_fs_file.mod, search.mod, scsi.mod, romfs.mod, relocator.mod, reiserfs.mod, regexp.mod, reboot.mod, read.mod,
raid6rec.mod, raid5rec.mod, probe.mod, priority_queue.mod, png.mod, play.mod, pbkdf2.mod, pata.mod, password_pbkdf2.mod, password.mod, parttool.mod, part_sunpc.mod,
part_sun.mod, part_plan.mod, part_msdos.mod, part_gpt.mod, part_dvh.mod, part_bsd.mod, part_apple.mod, part_amiga.mod, part_acorn.mod, ohci.mod, odc.mod, ntfscomp.mod,
ntfs.mod, normal.mod, nilfs2.mod, newc.mod, net.mod, multiboot2.mod, multiboot.mod, msdospart.mod, mmap.mod, minix_be.mod, minix3_be.mod, minix3.mod, minix2_be.mod, minix2.mod,
minix.mod, minicmd.mod, memrw.mod, memdisk.mod, mdraid1x.mod, mdraid09_be.mod, mdraid09.mod, lzopio.mod, lvm.mod, luks.mod, lssal.mod, lspci.mod, lsmmap.mod, lsefisystab.mod,
lsefimmap.mod, lsacpi.mod, ls.mod, loopback.mod, loadenv.mod, loadbios.mod, linuxefi.mod, linux.mod, ldm.mod, keystatus.mod, keylayouts.mod, jpeg.mod, jfs.mod, iso9660.mod,
iorw.mod, http.mod, hfsplus.mod, hfs.mod, hexdump.mod, help.mod, hello.mod, hdparm.mod, hashsum.mod, halt.mod, gzio.mod, gptsync.mod, gfxterm.mod, gfxmenu.mod, gettext.mod,
geli.mod, gcry_whirlpool.mod, gcry_twofish.mod, gcry_tiger.mod, gcry_sha512.mod, gcry_sha256.mod, gcry_sha1.mod, gcry_serpent.mod, gcry_seed.mod, gcry_rmd160.mod,
gcry_rijndael.mod, gcry_rfc2268.mod, gcry_md5.mod, gcry_md4.mod, gcry_des.mod, gcry_crc.mod, gcry_cast5.mod, gcry_camellia.mod, gcry_blowfish.mod, gcry_arcfour.mod,
functional_test.mod, fshelp.mod, font.mod, fixvideo.mod, fat.mod, extcmd.mod, ext2.mod, exfctest.mod, exfat.mod, elf.mod, ehci.mod, efinet.mod, efi_uga.mod, efi_gop.mod,
echo.mod, dm_nv.mod, diskfilter.mod, datetime.mod, datehook.mod, date.mod, cs5536.mod, cryptodisk.mod, crypto.mod, crc64.mod, cpuid.mod, cpio_be.mod, cpio.mod, configfile.mod,
cmp.mod, chain.mod, cat.mod, bufio.mod, btrfs.mod, bsd.mod, boot.mod, blocklist.mod, bitmap_scale.mod, bitmap.mod, bfs.mod, backtrace.mod, ata.mod, at_keyboard.mod,
appleldr.mod, aout.mod, all_video.mod, ahci.mod, afs.mod, affs.mod, adler32.mod, acpi.mod
</pre>

In der Konfiguration können Module über den Befehl ''insmod'' geladen werden. Ein Beispiel für die [[#Die Kommandozeile|Kommandozeile]]:
<pre>
insmod mdraid1x
</pre>

==Boot Password setzen==
Diese Funktionalität ist sinnvoll geworden, weil durch die [[#Erweiterte Funktionalitäten|erheblich ausgeweitete Funktionalität]] schon vor dem Start des OS potentiell Zugriff auf schützenswerte Daten erfolgen kann (möglicherweise auch über das Netzwerk) oder nicht gewünschte Systeme gebootet werden können. Es besteht auf diesem Wege die Möglichkeit, das Starten ausgewählter Systeme oder anderer Eigenschaften von ''GRUB2'' nur bestimmten Usern zu ermöglichen. Hierzu ist ein Authentifizierungsmechanismus und ein simples Usermangagement vorgesehen.

Hinweis: Die hier vorgestellten Mechanismen bieten keinen wirksamen Schutz vor Angreifern, welche '''physischen Zugang''' zu einem System haben sowie über ausreichend Zeit, Gelegenheit und über das notwendige KnowHow verfügen. Sollte der Angriff dem Datenbestand gelten, dann könnten die Festplatte auch ausgebaut und in einem anderen Computer eingelesen werden. Gegen solche Angriffe hilft nur eine ausreichende physikalische Sicherung und/oder eine Verschlüsselung der Daten mit ausgereiften kryptographischen Verfahren wie beispielsweise [[dm-crypt]].
Auch sollte erwähnt werden, dass hierdurch naturgemäß die Administration erschwert wird, insbesondere im Fall, dass ein System aus irgendwelchen Gründen gar nicht mehr bootet und repariert werden muss.

Gleichwohl kann das hier beschriebene Verfahren sehr wohl in bestimmten Kontexten zu einem höheren Maß an Sicherheit führen. Oftmals geht es in der IT-Sicherheit auch 'nur' darum, Hürden aufzubauen um schwächere Angriffsszenarien abdecken zu können oder Kombinationen von Sicherheitslücken zu entschärfen. So kann es durchaus sinnvoll sein, das Booten von externen Medien (USB-Stick, Netzwerk...) in Kombination mit entsprechenden Einträgen im [[BIOS]] einem Administrator vor zu behalten oder bestimmte installierte Betriebssysteme auf ausgewählte User einzugrenzen.
Einige Anwendungsfälle wurden beispielsweise [http://www.linux-club.de/viewtopic.php?f=90&t=118585 hier] diskutiert.

===Authentifizierung===
Es besteht die Möglichkeit, die Passwörter in Klartext in der Konfiguration zu hinterlegen. Viel sicherer ist es aber, anstatt von Klarttext-Passworten einen kryptographisch gesicherten [https://de.wikipedia.org/wiki/Kryptologische_Hashfunktion Passwort-Hash] zu verwenden, welcher mit einem angemessenen [https://de.wikipedia.org/wiki/Salt_%28Kryptologie%29 Salt] versehen ist (um Angriffen mit [https://de.wikipedia.org/wiki/Rainbow_Table Rainbow-Tables] abwehren zu können).

Hierzu wird das Kommando 'grub2-mkpasswd-pbkdf2' verwendet. Es generiert einen Password-Hash, welcher an den geeigneten Stellen eingetragen werden kann.

Aufruf für Password '123':
<pre>
# grub2-mkpasswd-pbkdf2
Enter password:
Reenter password:
PBKDF2 hash of your password is grub.pbkdf2.sha512.10000.DD2DF79436A5F2CA4F7363030C6C1555A7263BD692A61AAAE2847EDEF9D12B25EBBD0791EA875CBD1726D90DE9E99644BC4A630637D615AA42C06C19C26A6DC8.C68EC9D01A2DFCBEB2B36FDF6836290E8DB6F50B2BD85932AF7E6BEC8E4AC9A5BB4F027EF906AFD97FC2DC2A38745F5CA63DCC1E05049DC3CA12DC5336647249
</pre>
Folgende Aufrufe mit dem selben Password rufen immer andere Hashes hervor, was auf das Salting zurückzuführen ist.

Weitere Optionen:
<pre>
# grub2-mkpasswd-pbkdf2 -?
Usage: grub2-mkpasswd-pbkdf2 [OPTION...] [OPTIONS]
Generate PBKDF2 password hash.

-c, --iteration-count=NUM Number of PBKDF2 iterations
-l, --buflen=NUM Length of generated hash
-s, --salt=NUM Length of salt
-?, --help give this help list
--usage give a short usage message
-V, --version print program version

Mandatory or optional arguments to long options are also mandatory or optional
for any corresponding short options.
</pre>

Siehe auch: [https://de.wikipedia.org/wiki/PBKDF2 PBKDF2 (Wikipedia)]

===Authorisierung===
Zu erst wird die Liste der User definiert, welchen root-Zugriff zugebilligt werden soll. In diesem Beispiel einfach nur der User 'root':
<pre>
set superusers="root"
</pre>
Wenn diese Umgebungsvariable gesetzt ist, wird der Zugang zur [[#Kommandozeile|Kommandozeile]] nur den entsprechenden Usern erlaubt.

Als nächstes wird das Password mit den vorher generierten Password-Hashes den Usern zugeordnet:
<pre>
password_pbkdf2 root grub.pbkdf2.sha512.10000.DD2DF79436A5F2CA4F7363030C6C1555A7263BD692A61AAAE2847EDEF9D12B25EBBD0791EA875CBD1726D90DE9E99644BC4A630637D615AA42C06C19C26A6DC8.C68EC9D01A2DFCBEB2B36FDF6836290E8DB6F50B2BD85932AF7E6BEC8E4AC9A5BB4F027EF906AFD97FC2DC2A38745F5CA63DCC1E05049DC3CA12DC5336647249
password_pbkdf2 user1 grub.pbkdf2.sha512.10000.C3FFA2E95A6F933C562CFEFAFF86EE4BBE50FA20BD0575080C364D7EB37DE9CA6D7BDC58DB853EF00ECEB97376B1B7F50E051853A7DDBD917F201D58617397C1.6E29B095569E5BABD4380C47B61210F63D6F9156DA6D43C8D5F8AEAC88C7146C6C58A373C3CF4326D4B9F9CD50DDE4D890A0BDFC3E69EF5B42D5B2C09CA8086E
</pre>

Anwendugsbeispiele:

''Windows XP'' wird als unsicher eingestuft und sollte - wenn überhaupt - nicht in unsicheren Netzen eingesetzt werden. Um das sicherzustellen, wird dieses Recht nur dem besonders vertrauenswürdigen User 'user1' (oder implizit 'root') zugestanden:
<pre>
menuentry 'Windows XP (Achtung: kein Support mehr - unsicher)' --users user1 [...]
</pre>

Dieser Eintrag kann aufgrund des Parameters ''unrestricted'' von allen Benutzern gestartet werden:
<pre>
menuentry 'openSUSE 12.3, with Linux 3.7.10-1.11-desktop' --unrestricted [...]
</pre>
Ausgrenzung aller User, nur 'root' darf das Starten:
<pre>
menuentry 'openSUSE 12.3, with Linux 3.7.10-1.11-desktop (recovery mode)' --users '' [...]
</pre>

Falls weder der Parameter ''unrestricted'' noch ''users'' gesetzt ist, dann wird als User 'root' verwendet.

Hinweis: Derzeit gibt es noch keine Integration des Usermanagements in das [[#Buildsystem: /etc/grub.d|automatische Build]]. Die oben genannte Konfiguration muss also manuell in den Custom-Bereich eingetragen werden.

==Konfigurationsdatei: /boot/grub2/grub.cfg==
Dies ist die Hauptkonfigurationsdatei, welche wie oben beschrieben aber '''nicht manuell editiert''' werden sollte, weil sie vom [[#Buildsystem: /etc/grub.d|Buildsystem]] generiert wird! Es gibt System-Prozesse, welche genau das veranlassen, beispielsweise bei einem Kernelupdate. Manuelle Änderungen an dieser Datei würden spätestens da überschrieben.

Diese Datei wird beim eigentlichen Systemstart ausgewertet und bestimmt somit, welche Systeme zur Ausführung gelangen . Sie ersetzt die von [[GRUB Legacy]] bekannte Datei 'menu.lst'.

==Konfiguration neu generieren==
Um Konfigurationsänderungen zu aktivieren, muss abschließend das Kommando 'grub2-mkconfig' aufgerufen werden. Bei erfolgreicher Abarbeitung wird die [[#Konfigurationsdatei: /boot/grub2/grub.cfg|Hauptkonfigurationsdatei]] neu generiert:
<pre>
# grub2-mkconfig -o /boot/grub2/grub.cfg
Generating grub.cfg ...
Found theme: /boot/grub2/themes/openSUSE/theme.txt
Found linux image: /boot/vmlinuz-3.11.6-4-desktop
Found initrd image: /boot/initrd-3.11.6-4-desktop
Found linux image: /boot/vmlinuz-3.7.10-1.16-desktop
Found initrd image: /boot/initrd-3.7.10-1.16-desktop
Found openSUSE 12.3 (x86_64) on /dev/mapper/system-os2
done
</pre>
Im Falle von Syntax-Fehlern wird die Zieldatei nicht neu geschrieben. So wird sichergestellt ist, dass immer eine valide Konfiguration für den Systemstart vorliegt.

==Abhängigkeit zum Patch-Prozess==
Die Einträge ''initrd'' und ''linux'' in dieser Konfiguration unterliegen einer gewissen Dynamik. Es gibt eine Abhängigkeit zwischen den im Verzeichnis /boot liegenden Image-Dateien und der Konfiguration. So gibt es Anwendungsfälle, in welchen im Rahmen eines Systemupdates (Patch-Prozess) diese Images neu generiert werden (beispielsweise die ''initrd'' neu geschrieben wird). Um den Code des geänderten oder neuen Images auch nutzen zu können, wird vom Update-Prozess explizit auch die GRUB-Konfiguration neu generiert.

=Grundsätzliche Boot-Methoden=
''GRUB 2'' kennt zwei grundsätzliche Methoden, Betriebssysteme zu booten:
#Direktes Booten: Bei Betriebssystemen nach 'Multiboot Specification' wird diese Methode verwendet. Das sind hauptsächlich [[Open Source]]-Systeme.
#Chain Loading: Wird hauptsächlich bei nicht freien Betriebssystemen angewendet, für die es keinen nativen Support gibt.

==Direktes Booten (Multiboot Specification)==
Es gibt eine Spezifikation namens 'Multiboot', welche einen sauberen Multi-Boot-Betrieb zwischen unterschiedlichen Betriebssystemen zum Inhalt hat. Auf diesem Wege ist direkte Ansteuerung der installierten Systeme durch einen einzigen BootManager möglich.

Betriebssysteme mit Multiboot-Support: GNU/Linux, FreeBSD, NetBSD, OpenBSD, ...

Siehe: [http://www.gnu.org/software/grub/manual/multiboot/html_node/index.html Multiboot Specification (GNU)]

==Chain Loading==
Bei nicht quelloffenen Betriebssystemen gibt es fast immer keinen Support für direktes Booten. An diesen Stellen wird 'chain loading' verwendet, wobei hier der vorgeschaltete Boatloader (GRUB2) den Staffelstab an den nachgeschalteten (z.B. Windows) weitergibt:
<pre>
menuentry "Windows" {
insmod chain
insmod ntfs
set root=(hd0,1)
chainloader +1
}
</pre>

=Anwendungsfälle=
An dieser Stelle sollen Anleitungen zu ausgesuchten Anwendungsfällen im Zusammenhang mit ''GRUB 2'' aufgezeigt werden:
*[[Standardeintrag Bootmenü ändern (GRUB2)]]
*[[Umgang mit redundanten Laufwerken (GRUB2)]]
*[[Start von ISO-Image auf der Festplatte (GRUB2)]]
*[[Bootloader wiederherstellen]]

=Links=
*[http://www.gnu.org/software/grub/manual/html_node/index.html#SEC_Contents GRUB Documentation (GNU)] {{englisch}}
*[http://doc.opensuse.org/documentation/html/openSUSE_122/opensuse-reference/grub2.html The Boot Loader GRUB2 (doc.opensuse.org)] {{englisch}}
*[http://en.wikipedia.org/wiki/Grub2 GNU GRUB (Wikipedia)] {{englisch}}
*[https://help.ubuntu.com/community/Grub2 Grub2 (Ubuntu Documentation)] {{englisch}}
*[[GRUB]]
*[[GRUB Legacy]]

[[Kategorie:Bootmanager]] [[Kategorie:Security]]

GRUB 2

2015-11-18T11:08:42Z

Gehrke: /* Der Editor */

{{Lückenhaft|Im aktuellen Zustand beschreibt dieser Artikel ausschließlich Systeme mit herkömmlichen [[BIOS]], aber nicht die zunehmend weiter verbreiteten [[UEFI]]-Systeme. Diese Technologie und ihre Implikationen auf GRUB2 sollte in zukünftigen Versionen das Artikels berücksichtigt werden.}}

GNU GRUB (GRand Unified Bootloader)

=Abgrenzung zu 'GRUB Legacy'=
''GRUB 2'' ist eine vollständige Neuentwicklung des Vorgängers [[GRUB Legacy]]. Seit 2009 wird es in größeren Distributionen als Standard eingeführt, [[OpenSUSE]] beispielsweise vollführte diesen Schritt mit Release 12.2 im Herbst 2012.

Um eine Reihe neuer Funktionalitäten anbieten zu können, haben sich die Entwickler für eine radikale Neu-Implementierung entschieden. Es gibt dementsprechend bis auf den Namen kaum Gemeinsamkeiten und bewusst wurde auf '''Kompatibilität zum Vorgänger verzichtet'''.

Die aktuelle Version kann beispielsweise so abgefragt werden:
<pre>
# rpm -qv grub2
grub2-2.00-39.1.3.x86_64

# grub2-install -v
grub2-install (GRUB2) 2.00
</pre>

==Erweiterte Funktionalitäten==
*Script-gesteuerte, dynamischere Konfiguration
*Unterstützung von mehr [[Dateisystem]]en wie beispielsweise [[ext4]], HFS+, [[NTFS]] ([http://www.gnu.org/software/grub/manual/html_node/Internationalisation.html#Filesystems vollständige Liste])
*Direkter Zugriff auf [[LVM]] und [[RAID]]-Devices möglich
*Steuerung über ein graphisches Terminal (besonders ''Rescue Mode'') und graphisches Menüsystem gegeben
*Mehrsprachigkeit inklusive der Einträge
*Zusätzliche Unterstützung für weitere Systemsoftware neben PC [[BIOS]]: [[UEFI|PC EFI]], PC coreboot, PowerPC, SPARC, MIPS Lemote Yeeloong
*Support für Boot via Netzwerk über [[tftp]] (PXE)
*Zugriff über serielle Konsole möglich (vor allem Embedded Devices)
*Boot Password möglich
*Start von LiveCD ISO-Images direkt von der Festplatte möglich
*Unterstützung von weiteren Plattformen neben x86 (z.B. PowerPC)
*Einführung eines Modells zur Erzeugung von angepassten Layouts (Themes)

==Unterschiede zu 'GRUB Legacy'==
An dieser Stelle werden die Unterschiede zu [[GRUB Legacy]] hervorgehoben:
*In ''Grub 2'' existiert die stufenweise Reihenfolge in den Einzelphasen ('Stage 1', 'Stage 1.5', 'Stage 2') nicht mehr.
*In der Konfiguration werden Partitionen ebenfalls über Zahlen adressiert, aber die Nummerierung beginnt mit 1 (und nicht 0).
:*Hinweis: Das gilt aber nur für Partitionen, nicht für Festplatten. Festplatten werden mit 'hdX' benannt und X beginnt bei 0!
*Die Konfiguration wurde komplett umgestellt. Wo früher eine einzelne Datei (menu.lst) zu editieren war, gibt es heute ein komplettes Konfigurationssystem aus vielen Dateien mit eigener Struktur und eigenem Build-System, welches die eigentlichen Konfigurationsdateien generiert (s. [[#Konfiguration]]).

=Installation=
{{Lückenhaft|Im aktuellen Zustand beschreibt dieser Artikel ausschließlich Systeme, welche das [[MBR]]-Partitionierungsschema verwenden. Andere Schemata wie beispielsweise [[GPT]] werden hier derzeit nicht behandelt. Da GPT-Partitionierung zunehmend an Verbreitung gewinnt, sollte dies in zukünftigen Versionen das Artikels berücksichtigt werden.}}

Analog zum Vorgänger wird zur Installation des Boot-Sektors das Script 'grub2-install' verwendet. Als Parameter wird das Ziel-Device angegeben (im Beispiel der [[MBR]] der ersten Festplatten 'sda'):
<pre>
# grub2-install /dev/sda
Installation finished. No error reported.
</pre>
Alternativ können auch Partitionen ausgewählt werden.

Unter [[OpenSUSE]] ist alternativ zu verwenden:
*yast2 bootloader

{{Box Achtung||Dieser Schritt überschreibt möglicherweise [[Bootmanager]] anderer Systeme!}}

=Konfiguration=

==Die Kommandozeile==
''GRUB2'' verfügt über eine eingebaute Shell, welche unter anderem TAB-Completion beherrscht. Diese kann entweder direkt angesteuert werden oder wird angezeigt, wenn es Probleme mit einer invaliden Konfiguration gibt.

Hier können die selben Befehle verwendet werden, die in der Konfiguration möglich sind. Damit können beispielsweise im ''Rescue Mode'' beliebige Systeme manuell gestartet werden.

Direkt angesteuert werden kann die Kommandozeile innerhalb des [[#Der Editor|Editors]] mit den Tasten 'F2' oder 'Ctrl-C', Verlassen funktioniert via 'ESC'.

==Der Editor==
[[Bild:GRUB2-editor.png|right|thumb|300px|Der GRUB2-Editor (Beispiel)]]''GRUB2'' verfügt auch über einen eingebauten Editor. Dieser erlaubt es, einen ausgewählten Boot-Eintrag zu verändern. Dies kann sehr nützlich sein in Situationen, in denen die aktuelle Konfiguration nicht zu einem sauber gebooteten System führt - beispielsweise bei einem defekten Grafikkartentreiber infolge eines missglückten Updates.

In solchen Fällen ist es manchmal hilfreich, beim Start bestimmte Kernel-Parameter mitzugeben oder den Runlevel zu verändern.

Ein weiterer möglicher Anwendungsfall ist das schnelle Ausprobieren von Konfigurationsänderungen ohne Gefahr zu laufen, das System dauerhaft in einen Fehlerzustand zu versetzen (nicht persistente Änderung).

Dieser Editor wird aufgerufen, indem in der Anzeigephase von GRUB2 ein Eintrag ausgewählt und dann die Taste 'E' gedrückt wird. Daraufhin wird genau dieser betreffende Eintrag aus der aktuellen Datei ''grub.cfg'' in einen Editor geladen und kann dort verändert werden. Für die Steuerung des Editors gibt es eine Handvoll Tastenkürzel, welche unter dem Editor kurz aufgeführt werden. Mit 'ESC' verwirft man die Änderungen und kommt zur Auswahl zurück, mit 'Ctrl-X' oder 'F10' bootet man das System mit den angepassten Parametern.

Die Änderungen sind einmalig und werden nicht persistiert!

==YaST: boot loader==
[[OpenSUSE]]-typisch kann man einige Einstellungen auch in der Systemverwaltung [[YaST]] unter ''System / boot loader'' vornehmen.

==Default-Konfiguration: /etc/default/grub==
Globale Grundeinstellungen (Timeout, Standard-Eintrag, Layout...) werden hier definiert.

==/etc/sysconfig/bootloader==
Diese Datei enthält Konfigurationsoptionen, welche von der ''perl-bootloader library'' verwendet werden. Dies passiert dann, wenn eine Konfiguration über [[YaST]] durchgeführt wird oder ein neuer [[Kernel]] installiert wird.

Diese Datei ist [[openSUSE]]-spezifisch. Die Optionen hier werden auch nicht ausschließlich für ''GRUB 2'' verwendet, sondern auch bei anderen supporteten [[Bootmanager]]n.

==Buildsystem: /etc/grub.d==
Das Buildsystem ist eine Sammlung von Scripten. Ein Nummernpräfix sorgt für eine Abfolge in definierter Reihenfolge (bei '00' beginnend):
<pre>
# ls -l /etc/grub.d
-rwxr-xr-x 1 root root 7649 Jul 31 11:48 00_header
-rwxr-xr-x 1 root root 10535 Jul 31 11:48 10_linux
-rwxr-xr-x 1 root root 11019 Jul 31 11:48 20_linux_xen
-rwxr-xr-x 1 root root 1802 Jul 31 11:49 20_memtest86+
-rwxr-xr-x 1 root root 2596 Jul 31 11:48 20_ppc_terminfo
-rwxr-xr-x 1 root root 10132 Jul 31 11:48 30_os-prober
-rwxr-xr-x 1 root root 489 Jul 11 15:04 40_custom
-rwxr-xr-x 1 root root 216 Jul 31 11:48 41_custom
-rwxr-xr-x 1 root root 1259 Jul 31 11:49 90_persistent
-rw-r--r-- 1 root root 483 Jul 31 11:48 README
</pre>
Dieses Beispiel stammt aus einer [[OpenSUSE]]-Installation (Release 12.3). Andere Distribution liefern geringfügig andere Scripten aus. Es können diesem Schema entsprechend auch eigene Scripte hinzugefügt werden.

Bedeutung der Standard-Scripten:
*00_header: Initialisierung des Systems anhand der Einträge in /etc/default/grub ([[#Default-Konfiguration: /etc/default/grub|Default-Konfiguration]]).
*10_linux: Hier wird versucht, alle validen Kernel zu finden. Aus diesen wird dann das Bootmenü generiert.
*20_linux_xen: Für den Hypervisor [[Xen]] sind dedizierte Kernel notwendig. Hier wird die notwendige Parametrisierung hierfür durchgeführt.
*20_memtest86+: Aufnahme von [[memtest]] in das Bootmenü.
*20_ppc_terminfo: <ToDo: Funktionalität noch beschreiben>
*30_os-prober: Suche nach weiteren Bootladern sowie weiteren installierten Betriebssystemen. In einem Multi-Boot-Kontext werden hier Einträge beispielsweise für Windows oder parallele Linux-Installationen generiert.
*40_custom: Eigene Booteinträge können hier manuell hinterlegt werden. Dieses Script wird bei System-Updates nicht überschrieben.
*41_custom: Einbindung der Datei /boot/grub/custom.cfg
*90_persistent: Teile aus der aktuellen grub.cfg können hier rein kopiert werden. Dieser Inhalt wird bei einem erneuten Durchlauf des Build-Systems '''nicht''' überschrieben.

Siehe auch: [[#Konfiguration neu generieren]]

==Module laden==
''GRUB 2'' bietet direkten Zugriff auf bestimmte Ressourcen wie beispielsweise [[LVM]], [[RAID]] oder diverse [[Dateisysteme]]. Dieser Zugriff wird über Module implementiert, welche per 'insmod' bei Bedarf geladen werden können.

Unter [[OpenSUSE]] liegen diese Module (architekturabhängig) unter:
<pre>
# tree -d /usr/lib/grub2/
/usr/lib/grub2/
├── i386-pc
└── x86_64-efi
</pre>

Verfügbare Module (nur x86_64-efi):
<pre>
# ls -r --format=commas *.mod
zfsinfo.mod, zfscrypt.mod, zfs.mod, xzio.mod, xnu_uuid.mod, xnu.mod, xfs.mod, videotest.mod, videoinfo.mod, video_fb.mod, video_cirrus.mod, video_bochs.mod, video.mod,
usbtest.mod, usbserial_pl2303.mod, usbserial_ftdi.mod, usbserial_common.mod, usbms.mod, usb_keyboard.mod, usb.mod, uhci.mod, ufs2.mod, ufs1.mod, udf.mod, true.mod, trig.mod,
time.mod, tga.mod, tftp.mod, testload.mod, test_blockarg.mod, test.mod, terminfo.mod, terminal.mod, tar.mod, squash4.mod, sleep.mod, sfs.mod, setpci.mod, setjmp.mod,
serial.mod, search_label.mod, search_fs_uuid.mod, search_fs_file.mod, search.mod, scsi.mod, romfs.mod, relocator.mod, reiserfs.mod, regexp.mod, reboot.mod, read.mod,
raid6rec.mod, raid5rec.mod, probe.mod, priority_queue.mod, png.mod, play.mod, pbkdf2.mod, pata.mod, password_pbkdf2.mod, password.mod, parttool.mod, part_sunpc.mod,
part_sun.mod, part_plan.mod, part_msdos.mod, part_gpt.mod, part_dvh.mod, part_bsd.mod, part_apple.mod, part_amiga.mod, part_acorn.mod, ohci.mod, odc.mod, ntfscomp.mod,
ntfs.mod, normal.mod, nilfs2.mod, newc.mod, net.mod, multiboot2.mod, multiboot.mod, msdospart.mod, mmap.mod, minix_be.mod, minix3_be.mod, minix3.mod, minix2_be.mod, minix2.mod,
minix.mod, minicmd.mod, memrw.mod, memdisk.mod, mdraid1x.mod, mdraid09_be.mod, mdraid09.mod, lzopio.mod, lvm.mod, luks.mod, lssal.mod, lspci.mod, lsmmap.mod, lsefisystab.mod,
lsefimmap.mod, lsacpi.mod, ls.mod, loopback.mod, loadenv.mod, loadbios.mod, linuxefi.mod, linux.mod, ldm.mod, keystatus.mod, keylayouts.mod, jpeg.mod, jfs.mod, iso9660.mod,
iorw.mod, http.mod, hfsplus.mod, hfs.mod, hexdump.mod, help.mod, hello.mod, hdparm.mod, hashsum.mod, halt.mod, gzio.mod, gptsync.mod, gfxterm.mod, gfxmenu.mod, gettext.mod,
geli.mod, gcry_whirlpool.mod, gcry_twofish.mod, gcry_tiger.mod, gcry_sha512.mod, gcry_sha256.mod, gcry_sha1.mod, gcry_serpent.mod, gcry_seed.mod, gcry_rmd160.mod,
gcry_rijndael.mod, gcry_rfc2268.mod, gcry_md5.mod, gcry_md4.mod, gcry_des.mod, gcry_crc.mod, gcry_cast5.mod, gcry_camellia.mod, gcry_blowfish.mod, gcry_arcfour.mod,
functional_test.mod, fshelp.mod, font.mod, fixvideo.mod, fat.mod, extcmd.mod, ext2.mod, exfctest.mod, exfat.mod, elf.mod, ehci.mod, efinet.mod, efi_uga.mod, efi_gop.mod,
echo.mod, dm_nv.mod, diskfilter.mod, datetime.mod, datehook.mod, date.mod, cs5536.mod, cryptodisk.mod, crypto.mod, crc64.mod, cpuid.mod, cpio_be.mod, cpio.mod, configfile.mod,
cmp.mod, chain.mod, cat.mod, bufio.mod, btrfs.mod, bsd.mod, boot.mod, blocklist.mod, bitmap_scale.mod, bitmap.mod, bfs.mod, backtrace.mod, ata.mod, at_keyboard.mod,
appleldr.mod, aout.mod, all_video.mod, ahci.mod, afs.mod, affs.mod, adler32.mod, acpi.mod
</pre>

In der Konfiguration können Module über den Befehl ''insmod'' geladen werden. Ein Beispiel für die [[#Die Kommandozeile|Kommandozeile]]:
<pre>
insmod mdraid1x
</pre>

==Boot Password setzen==
Diese Funktionalität ist sinnvoll geworden, weil durch die [[#Erweiterte Funktionalitäten|erheblich ausgeweitete Funktionalität]] schon vor dem Start des OS potentiell Zugriff auf schützenswerte Daten erfolgen kann (möglicherweise auch über das Netzwerk) oder nicht gewünschte Systeme gebootet werden können. Es besteht auf diesem Wege die Möglichkeit, das Starten ausgewählter Systeme oder anderer Eigenschaften von ''GRUB2'' nur bestimmten Usern zu ermöglichen. Hierzu ist ein Authentifizierungsmechanismus und ein simples Usermangagement vorgesehen.

Hinweis: Die hier vorgestellten Mechanismen bieten keinen wirksamen Schutz vor Angreifern, welche '''physischen Zugang''' zu einem System haben sowie über ausreichend Zeit, Gelegenheit und über das notwendige KnowHow verfügen. Sollte der Angriff dem Datenbestand gelten, dann könnten die Festplatte auch ausgebaut und in einem anderen Computer eingelesen werden. Gegen solche Angriffe hilft nur eine ausreichende physikalische Sicherung und/oder eine Verschlüsselung der Daten mit ausgereiften kryptographischen Verfahren wie beispielsweise [[dm-crypt]].
Auch sollte erwähnt werden, dass hierdurch naturgemäß die Administration erschwert wird, insbesondere im Fall, dass ein System aus irgendwelchen Gründen gar nicht mehr bootet und repariert werden muss.

Gleichwohl kann das hier beschriebene Verfahren sehr wohl in bestimmten Kontexten zu einem höheren Maß an Sicherheit führen. Oftmals geht es in der IT-Sicherheit auch 'nur' darum, Hürden aufzubauen um schwächere Angriffsszenarien abdecken zu können oder Kombinationen von Sicherheitslücken zu entschärfen. So kann es durchaus sinnvoll sein, das Booten von externen Medien (USB-Stick, Netzwerk...) in Kombination mit entsprechenden Einträgen im [[BIOS]] einem Administrator vor zu behalten oder bestimmte installierte Betriebssysteme auf ausgewählte User einzugrenzen.
Einige Anwendungsfälle wurden beispielsweise [http://www.linux-club.de/viewtopic.php?f=90&t=118585 hier] diskutiert.

===Authentifizierung===
Es besteht die Möglichkeit, die Passwörter in Klartext in der Konfiguration zu hinterlegen. Viel sicherer ist es aber, anstatt von Klarttext-Passworten einen kryptographisch gesicherten [https://de.wikipedia.org/wiki/Kryptologische_Hashfunktion Passwort-Hash] zu verwenden, welcher mit einem angemessenen [https://de.wikipedia.org/wiki/Salt_%28Kryptologie%29 Salt] versehen ist (um Angriffen mit [https://de.wikipedia.org/wiki/Rainbow_Table Rainbow-Tables] abwehren zu können).

Hierzu wird das Kommando 'grub2-mkpasswd-pbkdf2' verwendet. Es generiert einen Password-Hash, welcher an den geeigneten Stellen eingetragen werden kann.

Aufruf für Password '123':
<pre>
# grub2-mkpasswd-pbkdf2
Enter password:
Reenter password:
PBKDF2 hash of your password is grub.pbkdf2.sha512.10000.DD2DF79436A5F2CA4F7363030C6C1555A7263BD692A61AAAE2847EDEF9D12B25EBBD0791EA875CBD1726D90DE9E99644BC4A630637D615AA42C06C19C26A6DC8.C68EC9D01A2DFCBEB2B36FDF6836290E8DB6F50B2BD85932AF7E6BEC8E4AC9A5BB4F027EF906AFD97FC2DC2A38745F5CA63DCC1E05049DC3CA12DC5336647249
</pre>
Folgende Aufrufe mit dem selben Password rufen immer andere Hashes hervor, was auf das Salting zurückzuführen ist.

Weitere Optionen:
<pre>
# grub2-mkpasswd-pbkdf2 -?
Usage: grub2-mkpasswd-pbkdf2 [OPTION...] [OPTIONS]
Generate PBKDF2 password hash.

-c, --iteration-count=NUM Number of PBKDF2 iterations
-l, --buflen=NUM Length of generated hash
-s, --salt=NUM Length of salt
-?, --help give this help list
--usage give a short usage message
-V, --version print program version

Mandatory or optional arguments to long options are also mandatory or optional
for any corresponding short options.
</pre>

Siehe auch: [https://de.wikipedia.org/wiki/PBKDF2 PBKDF2 (Wikipedia)]

===Authorisierung===
Zu erst wird die Liste der User definiert, welchen root-Zugriff zugebilligt werden soll. In diesem Beispiel einfach nur der User 'root':
<pre>
set superusers="root"
</pre>
Wenn diese Umgebungsvariable gesetzt ist, wird der Zugang zur [[#Kommandozeile|Kommandozeile]] nur den entsprechenden Usern erlaubt.

Als nächstes wird das Password mit den vorher generierten Password-Hashes den Usern zugeordnet:
<pre>
password_pbkdf2 root grub.pbkdf2.sha512.10000.DD2DF79436A5F2CA4F7363030C6C1555A7263BD692A61AAAE2847EDEF9D12B25EBBD0791EA875CBD1726D90DE9E99644BC4A630637D615AA42C06C19C26A6DC8.C68EC9D01A2DFCBEB2B36FDF6836290E8DB6F50B2BD85932AF7E6BEC8E4AC9A5BB4F027EF906AFD97FC2DC2A38745F5CA63DCC1E05049DC3CA12DC5336647249
password_pbkdf2 user1 grub.pbkdf2.sha512.10000.C3FFA2E95A6F933C562CFEFAFF86EE4BBE50FA20BD0575080C364D7EB37DE9CA6D7BDC58DB853EF00ECEB97376B1B7F50E051853A7DDBD917F201D58617397C1.6E29B095569E5BABD4380C47B61210F63D6F9156DA6D43C8D5F8AEAC88C7146C6C58A373C3CF4326D4B9F9CD50DDE4D890A0BDFC3E69EF5B42D5B2C09CA8086E
</pre>

Anwendugsbeispiele:

''Windows XP'' wird als unsicher eingestuft und sollte - wenn überhaupt - nicht in unsicheren Netzen eingesetzt werden. Um das sicherzustellen, wird dieses Recht nur dem besonders vertrauenswürdigen User 'user1' (oder implizit 'root') zugestanden:
<pre>
menuentry 'Windows XP (Achtung: kein Support mehr - unsicher)' --users user1 [...]
</pre>

Dieser Eintrag kann aufgrund des Parameters ''unrestricted'' von allen Benutzern gestartet werden:
<pre>
menuentry 'openSUSE 12.3, with Linux 3.7.10-1.11-desktop' --unrestricted [...]
</pre>
Ausgrenzung aller User, nur 'root' darf das Starten:
<pre>
menuentry 'openSUSE 12.3, with Linux 3.7.10-1.11-desktop (recovery mode)' --users '' [...]
</pre>

Falls weder der Parameter ''unrestricted'' noch ''users'' gesetzt ist, dann wird als User 'root' verwendet.

Hinweis: Derzeit gibt es noch keine Integration des Usermanagements in das [[#Buildsystem: /etc/grub.d|automatische Build]]. Die oben genannte Konfiguration muss also manuell in den Custom-Bereich eingetragen werden.

==Konfigurationsdatei: /boot/grub2/grub.cfg==
Dies ist die Hauptkonfigurationsdatei, welche wie oben beschrieben aber '''nicht manuell editiert''' werden sollte, weil sie vom [[#Buildsystem: /etc/grub.d|Buildsystem]] generiert wird! Es gibt System-Prozesse, welche genau das veranlassen, beispielsweise bei einem Kernelupdate. Manuelle Änderungen an dieser Datei würden spätestens da überschrieben.

Diese Datei wird beim eigentlichen Systemstart ausgewertet und bestimmt somit, welche Systeme zur Ausführung gelangen . Sie ersetzt die von [[GRUB Legacy]] bekannte Datei 'menu.lst'.

==Konfiguration neu generieren==
Um Konfigurationsänderungen zu aktivieren, muss abschließend das Kommando 'grub2-mkconfig' aufgerufen werden. Bei erfolgreicher Abarbeitung wird die [[#Konfigurationsdatei: /boot/grub2/grub.cfg|Hauptkonfigurationsdatei]] neu generiert:
<pre>
# grub2-mkconfig -o /boot/grub2/grub.cfg
Generating grub.cfg ...
Found theme: /boot/grub2/themes/openSUSE/theme.txt
Found linux image: /boot/vmlinuz-3.11.6-4-desktop
Found initrd image: /boot/initrd-3.11.6-4-desktop
Found linux image: /boot/vmlinuz-3.7.10-1.16-desktop
Found initrd image: /boot/initrd-3.7.10-1.16-desktop
Found openSUSE 12.3 (x86_64) on /dev/mapper/system-os2
done
</pre>
Im Falle von Syntax-Fehlern wird die Zieldatei nicht neu geschrieben. So wird sichergestellt ist, dass immer eine valide Konfiguration für den Systemstart vorliegt.

==Abhängigkeit zum Patch-Prozess==
Die Einträge ''initrd'' und ''linux'' in dieser Konfiguration unterliegen einer gewissen Dynamik. Es gibt eine Abhängigkeit zwischen den im Verzeichnis /boot liegenden Image-Dateien und der Konfiguration. So gibt es Anwendungsfälle, in welchen im Rahmen eines Systemupdates (Patch-Prozess) diese Images neu generiert werden (beispielsweise die ''initrd'' neu geschrieben wird). Um den Code des geänderten oder neuen Images auch nutzen zu können, wird vom Update-Prozess explizit auch die GRUB-Konfiguration neu generiert.

=Grundsätzliche Boot-Methoden=
''GRUB 2'' kennt zwei grundsätzliche Methoden, Betriebssysteme zu booten:
#Direktes Booten: Bei Betriebssystemen nach 'Multiboot Specification' wird diese Methode verwendet. Das sind hauptsächlich [[Open Source]]-Systeme.
#Chain Loading: Wird hauptsächlich bei nicht freien Betriebssystemen angewendet, für die es keinen nativen Support gibt.

==Direktes Booten (Multiboot Specification)==
Es gibt eine Spezifikation namens 'Multiboot', welche einen sauberen Multi-Boot-Betrieb zwischen unterschiedlichen Betriebssystemen zum Inhalt hat. Auf diesem Wege ist direkte Ansteuerung der installierten Systeme durch einen einzigen BootManager möglich.

Betriebssysteme mit Multiboot-Support: GNU/Linux, FreeBSD, NetBSD, OpenBSD, ...

Siehe: [http://www.gnu.org/software/grub/manual/multiboot/html_node/index.html Multiboot Specification (GNU)]

==Chain Loading==
Bei nicht quelloffenen Betriebssystemen gibt es fast immer keinen Support für direktes Booten. An diesen Stellen wird 'chain loading' verwendet, wobei hier der vorgeschaltete Boatloader (GRUB2) den Staffelstab an den nachgeschalteten (z.B. Windows) weitergibt:
<pre>
menuentry "Windows" {
insmod chain
insmod ntfs
set root=(hd0,1)
chainloader +1
}
</pre>

=Anwendungsfälle=
An dieser Stelle sollen Anleitungen zu ausgesuchten Anwendungsfällen im Zusammenhang mit ''GRUB 2'' aufgezeigt werden:
*[[Standardeintrag Bootmenü ändern (GRUB2)]]
*[[Umgang mit redundanten Laufwerken (GRUB2)]]
*[[Start von ISO-Image auf der Festplatte (GRUB2)]]
*[[Bootloader wiederherstellen]]

=Links=
*[http://www.gnu.org/software/grub/manual/html_node/index.html#SEC_Contents GRUB Documentation (GNU)] {{englisch}}
*[http://doc.opensuse.org/documentation/html/openSUSE_122/opensuse-reference/grub2.html The Boot Loader GRUB2 (doc.opensuse.org)] {{englisch}}
*[http://en.wikipedia.org/wiki/Grub2 GNU GRUB (Wikipedia)] {{englisch}}
*[https://help.ubuntu.com/community/Grub2 Grub2 (Ubuntu Documentation)] {{englisch}}
*[[GRUB]]
*[[GRUB Legacy]]

[[Kategorie:Bootmanager]] [[Kategorie:Security]]

GRUB 2

2015-11-18T11:04:36Z

Gehrke: /* Die Kommandozeile */ Aufruf via Editor

{{Lückenhaft|Im aktuellen Zustand beschreibt dieser Artikel ausschließlich Systeme mit herkömmlichen [[BIOS]], aber nicht die zunehmend weiter verbreiteten [[UEFI]]-Systeme. Diese Technologie und ihre Implikationen auf GRUB2 sollte in zukünftigen Versionen das Artikels berücksichtigt werden.}}

GNU GRUB (GRand Unified Bootloader)

=Abgrenzung zu 'GRUB Legacy'=
''GRUB 2'' ist eine vollständige Neuentwicklung des Vorgängers [[GRUB Legacy]]. Seit 2009 wird es in größeren Distributionen als Standard eingeführt, [[OpenSUSE]] beispielsweise vollführte diesen Schritt mit Release 12.2 im Herbst 2012.

Um eine Reihe neuer Funktionalitäten anbieten zu können, haben sich die Entwickler für eine radikale Neu-Implementierung entschieden. Es gibt dementsprechend bis auf den Namen kaum Gemeinsamkeiten und bewusst wurde auf '''Kompatibilität zum Vorgänger verzichtet'''.

Die aktuelle Version kann beispielsweise so abgefragt werden:
<pre>
# rpm -qv grub2
grub2-2.00-39.1.3.x86_64

# grub2-install -v
grub2-install (GRUB2) 2.00
</pre>

==Erweiterte Funktionalitäten==
*Script-gesteuerte, dynamischere Konfiguration
*Unterstützung von mehr [[Dateisystem]]en wie beispielsweise [[ext4]], HFS+, [[NTFS]] ([http://www.gnu.org/software/grub/manual/html_node/Internationalisation.html#Filesystems vollständige Liste])
*Direkter Zugriff auf [[LVM]] und [[RAID]]-Devices möglich
*Steuerung über ein graphisches Terminal (besonders ''Rescue Mode'') und graphisches Menüsystem gegeben
*Mehrsprachigkeit inklusive der Einträge
*Zusätzliche Unterstützung für weitere Systemsoftware neben PC [[BIOS]]: [[UEFI|PC EFI]], PC coreboot, PowerPC, SPARC, MIPS Lemote Yeeloong
*Support für Boot via Netzwerk über [[tftp]] (PXE)
*Zugriff über serielle Konsole möglich (vor allem Embedded Devices)
*Boot Password möglich
*Start von LiveCD ISO-Images direkt von der Festplatte möglich
*Unterstützung von weiteren Plattformen neben x86 (z.B. PowerPC)
*Einführung eines Modells zur Erzeugung von angepassten Layouts (Themes)

==Unterschiede zu 'GRUB Legacy'==
An dieser Stelle werden die Unterschiede zu [[GRUB Legacy]] hervorgehoben:
*In ''Grub 2'' existiert die stufenweise Reihenfolge in den Einzelphasen ('Stage 1', 'Stage 1.5', 'Stage 2') nicht mehr.
*In der Konfiguration werden Partitionen ebenfalls über Zahlen adressiert, aber die Nummerierung beginnt mit 1 (und nicht 0).
:*Hinweis: Das gilt aber nur für Partitionen, nicht für Festplatten. Festplatten werden mit 'hdX' benannt und X beginnt bei 0!
*Die Konfiguration wurde komplett umgestellt. Wo früher eine einzelne Datei (menu.lst) zu editieren war, gibt es heute ein komplettes Konfigurationssystem aus vielen Dateien mit eigener Struktur und eigenem Build-System, welches die eigentlichen Konfigurationsdateien generiert (s. [[#Konfiguration]]).

=Installation=
{{Lückenhaft|Im aktuellen Zustand beschreibt dieser Artikel ausschließlich Systeme, welche das [[MBR]]-Partitionierungsschema verwenden. Andere Schemata wie beispielsweise [[GPT]] werden hier derzeit nicht behandelt. Da GPT-Partitionierung zunehmend an Verbreitung gewinnt, sollte dies in zukünftigen Versionen das Artikels berücksichtigt werden.}}

Analog zum Vorgänger wird zur Installation des Boot-Sektors das Script 'grub2-install' verwendet. Als Parameter wird das Ziel-Device angegeben (im Beispiel der [[MBR]] der ersten Festplatten 'sda'):
<pre>
# grub2-install /dev/sda
Installation finished. No error reported.
</pre>
Alternativ können auch Partitionen ausgewählt werden.

Unter [[OpenSUSE]] ist alternativ zu verwenden:
*yast2 bootloader

{{Box Achtung||Dieser Schritt überschreibt möglicherweise [[Bootmanager]] anderer Systeme!}}

=Konfiguration=

==Die Kommandozeile==
''GRUB2'' verfügt über eine eingebaute Shell, welche unter anderem TAB-Completion beherrscht. Diese kann entweder direkt angesteuert werden oder wird angezeigt, wenn es Probleme mit einer invaliden Konfiguration gibt.

Hier können die selben Befehle verwendet werden, die in der Konfiguration möglich sind. Damit können beispielsweise im ''Rescue Mode'' beliebige Systeme manuell gestartet werden.

Direkt angesteuert werden kann die Kommandozeile innerhalb des [[#Der Editor|Editors]] mit den Tasten 'F2' oder 'Ctrl-C', Verlassen funktioniert via 'ESC'.

==Der Editor==
[[Bild:GRUB2-editor.png|right|thumb|300px|Der GRUB2-Editor (Beispiel)]]''GRUB2'' verfügt auch über einen eingebauten Editor. Dieser erlaubt es, einen ausgewählten Boot-Eintrag zu verändern. Dies kann sehr nützlich sein in Situationen, in denen die aktuelle Konfiguration nicht zu einem sauber gebooteten System führt - beispielsweise bei einem defekten Grafikkartentreiber infolge eines missglückten Updates.

In solchen Fällen ist es manchmal hilfreich, beim Start bestimmte Kernel-Paramter mitzugeben oder den Runlevel zu verändern.

Ein weiterer möglicher Anwendungsfall ist das schnelle Ausprobieren von Konfigurationsänderungen ohne Gefahr zu laufen, das System dauerhaft in einen Fehlerzustand zu versetzen (nicht persistente Änderung).

Dieser Editor wird aufgerufen, indem in der Anzeigephase von GRUB2 ein Eintrag ausgewählt und dann die Taste 'E' gedrückt wird. Daraufhin wird genau dieser betreffende Eintrag aus der aktuellen Datei ''grub.cfg'' in einen Editor geladen und kann dort verändert werden. Für die Steuerung des Editors gibt es eine Handvoll Tastenkürzel, welche unter dem Editor kurz aufgeführt werden. Mit 'ESC' verwirft man die Änderungen und kommt zur Auswahl zurück, mit 'Ctrl-X' oder 'F10' bootet man das System mit den angepassten Parametern.

Die Änderungen sind einmalig und werden nicht persistiert!

==YaST: boot loader==
[[OpenSUSE]]-typisch kann man einige Einstellungen auch in der Systemverwaltung [[YaST]] unter ''System / boot loader'' vornehmen.

==Default-Konfiguration: /etc/default/grub==
Globale Grundeinstellungen (Timeout, Standard-Eintrag, Layout...) werden hier definiert.

==/etc/sysconfig/bootloader==
Diese Datei enthält Konfigurationsoptionen, welche von der ''perl-bootloader library'' verwendet werden. Dies passiert dann, wenn eine Konfiguration über [[YaST]] durchgeführt wird oder ein neuer [[Kernel]] installiert wird.

Diese Datei ist [[openSUSE]]-spezifisch. Die Optionen hier werden auch nicht ausschließlich für ''GRUB 2'' verwendet, sondern auch bei anderen supporteten [[Bootmanager]]n.

==Buildsystem: /etc/grub.d==
Das Buildsystem ist eine Sammlung von Scripten. Ein Nummernpräfix sorgt für eine Abfolge in definierter Reihenfolge (bei '00' beginnend):
<pre>
# ls -l /etc/grub.d
-rwxr-xr-x 1 root root 7649 Jul 31 11:48 00_header
-rwxr-xr-x 1 root root 10535 Jul 31 11:48 10_linux
-rwxr-xr-x 1 root root 11019 Jul 31 11:48 20_linux_xen
-rwxr-xr-x 1 root root 1802 Jul 31 11:49 20_memtest86+
-rwxr-xr-x 1 root root 2596 Jul 31 11:48 20_ppc_terminfo
-rwxr-xr-x 1 root root 10132 Jul 31 11:48 30_os-prober
-rwxr-xr-x 1 root root 489 Jul 11 15:04 40_custom
-rwxr-xr-x 1 root root 216 Jul 31 11:48 41_custom
-rwxr-xr-x 1 root root 1259 Jul 31 11:49 90_persistent
-rw-r--r-- 1 root root 483 Jul 31 11:48 README
</pre>
Dieses Beispiel stammt aus einer [[OpenSUSE]]-Installation (Release 12.3). Andere Distribution liefern geringfügig andere Scripten aus. Es können diesem Schema entsprechend auch eigene Scripte hinzugefügt werden.

Bedeutung der Standard-Scripten:
*00_header: Initialisierung des Systems anhand der Einträge in /etc/default/grub ([[#Default-Konfiguration: /etc/default/grub|Default-Konfiguration]]).
*10_linux: Hier wird versucht, alle validen Kernel zu finden. Aus diesen wird dann das Bootmenü generiert.
*20_linux_xen: Für den Hypervisor [[Xen]] sind dedizierte Kernel notwendig. Hier wird die notwendige Parametrisierung hierfür durchgeführt.
*20_memtest86+: Aufnahme von [[memtest]] in das Bootmenü.
*20_ppc_terminfo: <ToDo: Funktionalität noch beschreiben>
*30_os-prober: Suche nach weiteren Bootladern sowie weiteren installierten Betriebssystemen. In einem Multi-Boot-Kontext werden hier Einträge beispielsweise für Windows oder parallele Linux-Installationen generiert.
*40_custom: Eigene Booteinträge können hier manuell hinterlegt werden. Dieses Script wird bei System-Updates nicht überschrieben.
*41_custom: Einbindung der Datei /boot/grub/custom.cfg
*90_persistent: Teile aus der aktuellen grub.cfg können hier rein kopiert werden. Dieser Inhalt wird bei einem erneuten Durchlauf des Build-Systems '''nicht''' überschrieben.

Siehe auch: [[#Konfiguration neu generieren]]

==Module laden==
''GRUB 2'' bietet direkten Zugriff auf bestimmte Ressourcen wie beispielsweise [[LVM]], [[RAID]] oder diverse [[Dateisysteme]]. Dieser Zugriff wird über Module implementiert, welche per 'insmod' bei Bedarf geladen werden können.

Unter [[OpenSUSE]] liegen diese Module (architekturabhängig) unter:
<pre>
# tree -d /usr/lib/grub2/
/usr/lib/grub2/
├── i386-pc
└── x86_64-efi
</pre>

Verfügbare Module (nur x86_64-efi):
<pre>
# ls -r --format=commas *.mod
zfsinfo.mod, zfscrypt.mod, zfs.mod, xzio.mod, xnu_uuid.mod, xnu.mod, xfs.mod, videotest.mod, videoinfo.mod, video_fb.mod, video_cirrus.mod, video_bochs.mod, video.mod,
usbtest.mod, usbserial_pl2303.mod, usbserial_ftdi.mod, usbserial_common.mod, usbms.mod, usb_keyboard.mod, usb.mod, uhci.mod, ufs2.mod, ufs1.mod, udf.mod, true.mod, trig.mod,
time.mod, tga.mod, tftp.mod, testload.mod, test_blockarg.mod, test.mod, terminfo.mod, terminal.mod, tar.mod, squash4.mod, sleep.mod, sfs.mod, setpci.mod, setjmp.mod,
serial.mod, search_label.mod, search_fs_uuid.mod, search_fs_file.mod, search.mod, scsi.mod, romfs.mod, relocator.mod, reiserfs.mod, regexp.mod, reboot.mod, read.mod,
raid6rec.mod, raid5rec.mod, probe.mod, priority_queue.mod, png.mod, play.mod, pbkdf2.mod, pata.mod, password_pbkdf2.mod, password.mod, parttool.mod, part_sunpc.mod,
part_sun.mod, part_plan.mod, part_msdos.mod, part_gpt.mod, part_dvh.mod, part_bsd.mod, part_apple.mod, part_amiga.mod, part_acorn.mod, ohci.mod, odc.mod, ntfscomp.mod,
ntfs.mod, normal.mod, nilfs2.mod, newc.mod, net.mod, multiboot2.mod, multiboot.mod, msdospart.mod, mmap.mod, minix_be.mod, minix3_be.mod, minix3.mod, minix2_be.mod, minix2.mod,
minix.mod, minicmd.mod, memrw.mod, memdisk.mod, mdraid1x.mod, mdraid09_be.mod, mdraid09.mod, lzopio.mod, lvm.mod, luks.mod, lssal.mod, lspci.mod, lsmmap.mod, lsefisystab.mod,
lsefimmap.mod, lsacpi.mod, ls.mod, loopback.mod, loadenv.mod, loadbios.mod, linuxefi.mod, linux.mod, ldm.mod, keystatus.mod, keylayouts.mod, jpeg.mod, jfs.mod, iso9660.mod,
iorw.mod, http.mod, hfsplus.mod, hfs.mod, hexdump.mod, help.mod, hello.mod, hdparm.mod, hashsum.mod, halt.mod, gzio.mod, gptsync.mod, gfxterm.mod, gfxmenu.mod, gettext.mod,
geli.mod, gcry_whirlpool.mod, gcry_twofish.mod, gcry_tiger.mod, gcry_sha512.mod, gcry_sha256.mod, gcry_sha1.mod, gcry_serpent.mod, gcry_seed.mod, gcry_rmd160.mod,
gcry_rijndael.mod, gcry_rfc2268.mod, gcry_md5.mod, gcry_md4.mod, gcry_des.mod, gcry_crc.mod, gcry_cast5.mod, gcry_camellia.mod, gcry_blowfish.mod, gcry_arcfour.mod,
functional_test.mod, fshelp.mod, font.mod, fixvideo.mod, fat.mod, extcmd.mod, ext2.mod, exfctest.mod, exfat.mod, elf.mod, ehci.mod, efinet.mod, efi_uga.mod, efi_gop.mod,
echo.mod, dm_nv.mod, diskfilter.mod, datetime.mod, datehook.mod, date.mod, cs5536.mod, cryptodisk.mod, crypto.mod, crc64.mod, cpuid.mod, cpio_be.mod, cpio.mod, configfile.mod,
cmp.mod, chain.mod, cat.mod, bufio.mod, btrfs.mod, bsd.mod, boot.mod, blocklist.mod, bitmap_scale.mod, bitmap.mod, bfs.mod, backtrace.mod, ata.mod, at_keyboard.mod,
appleldr.mod, aout.mod, all_video.mod, ahci.mod, afs.mod, affs.mod, adler32.mod, acpi.mod
</pre>

In der Konfiguration können Module über den Befehl ''insmod'' geladen werden. Ein Beispiel für die [[#Die Kommandozeile|Kommandozeile]]:
<pre>
insmod mdraid1x
</pre>

==Boot Password setzen==
Diese Funktionalität ist sinnvoll geworden, weil durch die [[#Erweiterte Funktionalitäten|erheblich ausgeweitete Funktionalität]] schon vor dem Start des OS potentiell Zugriff auf schützenswerte Daten erfolgen kann (möglicherweise auch über das Netzwerk) oder nicht gewünschte Systeme gebootet werden können. Es besteht auf diesem Wege die Möglichkeit, das Starten ausgewählter Systeme oder anderer Eigenschaften von ''GRUB2'' nur bestimmten Usern zu ermöglichen. Hierzu ist ein Authentifizierungsmechanismus und ein simples Usermangagement vorgesehen.

Hinweis: Die hier vorgestellten Mechanismen bieten keinen wirksamen Schutz vor Angreifern, welche '''physischen Zugang''' zu einem System haben sowie über ausreichend Zeit, Gelegenheit und über das notwendige KnowHow verfügen. Sollte der Angriff dem Datenbestand gelten, dann könnten die Festplatte auch ausgebaut und in einem anderen Computer eingelesen werden. Gegen solche Angriffe hilft nur eine ausreichende physikalische Sicherung und/oder eine Verschlüsselung der Daten mit ausgereiften kryptographischen Verfahren wie beispielsweise [[dm-crypt]].
Auch sollte erwähnt werden, dass hierdurch naturgemäß die Administration erschwert wird, insbesondere im Fall, dass ein System aus irgendwelchen Gründen gar nicht mehr bootet und repariert werden muss.

Gleichwohl kann das hier beschriebene Verfahren sehr wohl in bestimmten Kontexten zu einem höheren Maß an Sicherheit führen. Oftmals geht es in der IT-Sicherheit auch 'nur' darum, Hürden aufzubauen um schwächere Angriffsszenarien abdecken zu können oder Kombinationen von Sicherheitslücken zu entschärfen. So kann es durchaus sinnvoll sein, das Booten von externen Medien (USB-Stick, Netzwerk...) in Kombination mit entsprechenden Einträgen im [[BIOS]] einem Administrator vor zu behalten oder bestimmte installierte Betriebssysteme auf ausgewählte User einzugrenzen.
Einige Anwendungsfälle wurden beispielsweise [http://www.linux-club.de/viewtopic.php?f=90&t=118585 hier] diskutiert.

===Authentifizierung===
Es besteht die Möglichkeit, die Passwörter in Klartext in der Konfiguration zu hinterlegen. Viel sicherer ist es aber, anstatt von Klarttext-Passworten einen kryptographisch gesicherten [https://de.wikipedia.org/wiki/Kryptologische_Hashfunktion Passwort-Hash] zu verwenden, welcher mit einem angemessenen [https://de.wikipedia.org/wiki/Salt_%28Kryptologie%29 Salt] versehen ist (um Angriffen mit [https://de.wikipedia.org/wiki/Rainbow_Table Rainbow-Tables] abwehren zu können).

Hierzu wird das Kommando 'grub2-mkpasswd-pbkdf2' verwendet. Es generiert einen Password-Hash, welcher an den geeigneten Stellen eingetragen werden kann.

Aufruf für Password '123':
<pre>
# grub2-mkpasswd-pbkdf2
Enter password:
Reenter password:
PBKDF2 hash of your password is grub.pbkdf2.sha512.10000.DD2DF79436A5F2CA4F7363030C6C1555A7263BD692A61AAAE2847EDEF9D12B25EBBD0791EA875CBD1726D90DE9E99644BC4A630637D615AA42C06C19C26A6DC8.C68EC9D01A2DFCBEB2B36FDF6836290E8DB6F50B2BD85932AF7E6BEC8E4AC9A5BB4F027EF906AFD97FC2DC2A38745F5CA63DCC1E05049DC3CA12DC5336647249
</pre>
Folgende Aufrufe mit dem selben Password rufen immer andere Hashes hervor, was auf das Salting zurückzuführen ist.

Weitere Optionen:
<pre>
# grub2-mkpasswd-pbkdf2 -?
Usage: grub2-mkpasswd-pbkdf2 [OPTION...] [OPTIONS]
Generate PBKDF2 password hash.

-c, --iteration-count=NUM Number of PBKDF2 iterations
-l, --buflen=NUM Length of generated hash
-s, --salt=NUM Length of salt
-?, --help give this help list
--usage give a short usage message
-V, --version print program version

Mandatory or optional arguments to long options are also mandatory or optional
for any corresponding short options.
</pre>

Siehe auch: [https://de.wikipedia.org/wiki/PBKDF2 PBKDF2 (Wikipedia)]

===Authorisierung===
Zu erst wird die Liste der User definiert, welchen root-Zugriff zugebilligt werden soll. In diesem Beispiel einfach nur der User 'root':
<pre>
set superusers="root"
</pre>
Wenn diese Umgebungsvariable gesetzt ist, wird der Zugang zur [[#Kommandozeile|Kommandozeile]] nur den entsprechenden Usern erlaubt.

Als nächstes wird das Password mit den vorher generierten Password-Hashes den Usern zugeordnet:
<pre>
password_pbkdf2 root grub.pbkdf2.sha512.10000.DD2DF79436A5F2CA4F7363030C6C1555A7263BD692A61AAAE2847EDEF9D12B25EBBD0791EA875CBD1726D90DE9E99644BC4A630637D615AA42C06C19C26A6DC8.C68EC9D01A2DFCBEB2B36FDF6836290E8DB6F50B2BD85932AF7E6BEC8E4AC9A5BB4F027EF906AFD97FC2DC2A38745F5CA63DCC1E05049DC3CA12DC5336647249
password_pbkdf2 user1 grub.pbkdf2.sha512.10000.C3FFA2E95A6F933C562CFEFAFF86EE4BBE50FA20BD0575080C364D7EB37DE9CA6D7BDC58DB853EF00ECEB97376B1B7F50E051853A7DDBD917F201D58617397C1.6E29B095569E5BABD4380C47B61210F63D6F9156DA6D43C8D5F8AEAC88C7146C6C58A373C3CF4326D4B9F9CD50DDE4D890A0BDFC3E69EF5B42D5B2C09CA8086E
</pre>

Anwendugsbeispiele:

''Windows XP'' wird als unsicher eingestuft und sollte - wenn überhaupt - nicht in unsicheren Netzen eingesetzt werden. Um das sicherzustellen, wird dieses Recht nur dem besonders vertrauenswürdigen User 'user1' (oder implizit 'root') zugestanden:
<pre>
menuentry 'Windows XP (Achtung: kein Support mehr - unsicher)' --users user1 [...]
</pre>

Dieser Eintrag kann aufgrund des Parameters ''unrestricted'' von allen Benutzern gestartet werden:
<pre>
menuentry 'openSUSE 12.3, with Linux 3.7.10-1.11-desktop' --unrestricted [...]
</pre>
Ausgrenzung aller User, nur 'root' darf das Starten:
<pre>
menuentry 'openSUSE 12.3, with Linux 3.7.10-1.11-desktop (recovery mode)' --users '' [...]
</pre>

Falls weder der Parameter ''unrestricted'' noch ''users'' gesetzt ist, dann wird als User 'root' verwendet.

Hinweis: Derzeit gibt es noch keine Integration des Usermanagements in das [[#Buildsystem: /etc/grub.d|automatische Build]]. Die oben genannte Konfiguration muss also manuell in den Custom-Bereich eingetragen werden.

==Konfigurationsdatei: /boot/grub2/grub.cfg==
Dies ist die Hauptkonfigurationsdatei, welche wie oben beschrieben aber '''nicht manuell editiert''' werden sollte, weil sie vom [[#Buildsystem: /etc/grub.d|Buildsystem]] generiert wird! Es gibt System-Prozesse, welche genau das veranlassen, beispielsweise bei einem Kernelupdate. Manuelle Änderungen an dieser Datei würden spätestens da überschrieben.

Diese Datei wird beim eigentlichen Systemstart ausgewertet und bestimmt somit, welche Systeme zur Ausführung gelangen . Sie ersetzt die von [[GRUB Legacy]] bekannte Datei 'menu.lst'.

==Konfiguration neu generieren==
Um Konfigurationsänderungen zu aktivieren, muss abschließend das Kommando 'grub2-mkconfig' aufgerufen werden. Bei erfolgreicher Abarbeitung wird die [[#Konfigurationsdatei: /boot/grub2/grub.cfg|Hauptkonfigurationsdatei]] neu generiert:
<pre>
# grub2-mkconfig -o /boot/grub2/grub.cfg
Generating grub.cfg ...
Found theme: /boot/grub2/themes/openSUSE/theme.txt
Found linux image: /boot/vmlinuz-3.11.6-4-desktop
Found initrd image: /boot/initrd-3.11.6-4-desktop
Found linux image: /boot/vmlinuz-3.7.10-1.16-desktop
Found initrd image: /boot/initrd-3.7.10-1.16-desktop
Found openSUSE 12.3 (x86_64) on /dev/mapper/system-os2
done
</pre>
Im Falle von Syntax-Fehlern wird die Zieldatei nicht neu geschrieben. So wird sichergestellt ist, dass immer eine valide Konfiguration für den Systemstart vorliegt.

==Abhängigkeit zum Patch-Prozess==
Die Einträge ''initrd'' und ''linux'' in dieser Konfiguration unterliegen einer gewissen Dynamik. Es gibt eine Abhängigkeit zwischen den im Verzeichnis /boot liegenden Image-Dateien und der Konfiguration. So gibt es Anwendungsfälle, in welchen im Rahmen eines Systemupdates (Patch-Prozess) diese Images neu generiert werden (beispielsweise die ''initrd'' neu geschrieben wird). Um den Code des geänderten oder neuen Images auch nutzen zu können, wird vom Update-Prozess explizit auch die GRUB-Konfiguration neu generiert.

=Grundsätzliche Boot-Methoden=
''GRUB 2'' kennt zwei grundsätzliche Methoden, Betriebssysteme zu booten:
#Direktes Booten: Bei Betriebssystemen nach 'Multiboot Specification' wird diese Methode verwendet. Das sind hauptsächlich [[Open Source]]-Systeme.
#Chain Loading: Wird hauptsächlich bei nicht freien Betriebssystemen angewendet, für die es keinen nativen Support gibt.

==Direktes Booten (Multiboot Specification)==
Es gibt eine Spezifikation namens 'Multiboot', welche einen sauberen Multi-Boot-Betrieb zwischen unterschiedlichen Betriebssystemen zum Inhalt hat. Auf diesem Wege ist direkte Ansteuerung der installierten Systeme durch einen einzigen BootManager möglich.

Betriebssysteme mit Multiboot-Support: GNU/Linux, FreeBSD, NetBSD, OpenBSD, ...

Siehe: [http://www.gnu.org/software/grub/manual/multiboot/html_node/index.html Multiboot Specification (GNU)]

==Chain Loading==
Bei nicht quelloffenen Betriebssystemen gibt es fast immer keinen Support für direktes Booten. An diesen Stellen wird 'chain loading' verwendet, wobei hier der vorgeschaltete Boatloader (GRUB2) den Staffelstab an den nachgeschalteten (z.B. Windows) weitergibt:
<pre>
menuentry "Windows" {
insmod chain
insmod ntfs
set root=(hd0,1)
chainloader +1
}
</pre>

=Anwendungsfälle=
An dieser Stelle sollen Anleitungen zu ausgesuchten Anwendungsfällen im Zusammenhang mit ''GRUB 2'' aufgezeigt werden:
*[[Standardeintrag Bootmenü ändern (GRUB2)]]
*[[Umgang mit redundanten Laufwerken (GRUB2)]]
*[[Start von ISO-Image auf der Festplatte (GRUB2)]]
*[[Bootloader wiederherstellen]]

=Links=
*[http://www.gnu.org/software/grub/manual/html_node/index.html#SEC_Contents GRUB Documentation (GNU)] {{englisch}}
*[http://doc.opensuse.org/documentation/html/openSUSE_122/opensuse-reference/grub2.html The Boot Loader GRUB2 (doc.opensuse.org)] {{englisch}}
*[http://en.wikipedia.org/wiki/Grub2 GNU GRUB (Wikipedia)] {{englisch}}
*[https://help.ubuntu.com/community/Grub2 Grub2 (Ubuntu Documentation)] {{englisch}}
*[[GRUB]]
*[[GRUB Legacy]]

[[Kategorie:Bootmanager]] [[Kategorie:Security]]

GRUB 2

2015-11-18T10:56:38Z

Gehrke: /* Der Editor */ das schnelle Ausprobieren

{{Lückenhaft|Im aktuellen Zustand beschreibt dieser Artikel ausschließlich Systeme mit herkömmlichen [[BIOS]], aber nicht die zunehmend weiter verbreiteten [[UEFI]]-Systeme. Diese Technologie und ihre Implikationen auf GRUB2 sollte in zukünftigen Versionen das Artikels berücksichtigt werden.}}

GNU GRUB (GRand Unified Bootloader)

=Abgrenzung zu 'GRUB Legacy'=
''GRUB 2'' ist eine vollständige Neuentwicklung des Vorgängers [[GRUB Legacy]]. Seit 2009 wird es in größeren Distributionen als Standard eingeführt, [[OpenSUSE]] beispielsweise vollführte diesen Schritt mit Release 12.2 im Herbst 2012.

Um eine Reihe neuer Funktionalitäten anbieten zu können, haben sich die Entwickler für eine radikale Neu-Implementierung entschieden. Es gibt dementsprechend bis auf den Namen kaum Gemeinsamkeiten und bewusst wurde auf '''Kompatibilität zum Vorgänger verzichtet'''.

Die aktuelle Version kann beispielsweise so abgefragt werden:
<pre>
# rpm -qv grub2
grub2-2.00-39.1.3.x86_64

# grub2-install -v
grub2-install (GRUB2) 2.00
</pre>

==Erweiterte Funktionalitäten==
*Script-gesteuerte, dynamischere Konfiguration
*Unterstützung von mehr [[Dateisystem]]en wie beispielsweise [[ext4]], HFS+, [[NTFS]] ([http://www.gnu.org/software/grub/manual/html_node/Internationalisation.html#Filesystems vollständige Liste])
*Direkter Zugriff auf [[LVM]] und [[RAID]]-Devices möglich
*Steuerung über ein graphisches Terminal (besonders ''Rescue Mode'') und graphisches Menüsystem gegeben
*Mehrsprachigkeit inklusive der Einträge
*Zusätzliche Unterstützung für weitere Systemsoftware neben PC [[BIOS]]: [[UEFI|PC EFI]], PC coreboot, PowerPC, SPARC, MIPS Lemote Yeeloong
*Support für Boot via Netzwerk über [[tftp]] (PXE)
*Zugriff über serielle Konsole möglich (vor allem Embedded Devices)
*Boot Password möglich
*Start von LiveCD ISO-Images direkt von der Festplatte möglich
*Unterstützung von weiteren Plattformen neben x86 (z.B. PowerPC)
*Einführung eines Modells zur Erzeugung von angepassten Layouts (Themes)

==Unterschiede zu 'GRUB Legacy'==
An dieser Stelle werden die Unterschiede zu [[GRUB Legacy]] hervorgehoben:
*In ''Grub 2'' existiert die stufenweise Reihenfolge in den Einzelphasen ('Stage 1', 'Stage 1.5', 'Stage 2') nicht mehr.
*In der Konfiguration werden Partitionen ebenfalls über Zahlen adressiert, aber die Nummerierung beginnt mit 1 (und nicht 0).
:*Hinweis: Das gilt aber nur für Partitionen, nicht für Festplatten. Festplatten werden mit 'hdX' benannt und X beginnt bei 0!
*Die Konfiguration wurde komplett umgestellt. Wo früher eine einzelne Datei (menu.lst) zu editieren war, gibt es heute ein komplettes Konfigurationssystem aus vielen Dateien mit eigener Struktur und eigenem Build-System, welches die eigentlichen Konfigurationsdateien generiert (s. [[#Konfiguration]]).

=Installation=
{{Lückenhaft|Im aktuellen Zustand beschreibt dieser Artikel ausschließlich Systeme, welche das [[MBR]]-Partitionierungsschema verwenden. Andere Schemata wie beispielsweise [[GPT]] werden hier derzeit nicht behandelt. Da GPT-Partitionierung zunehmend an Verbreitung gewinnt, sollte dies in zukünftigen Versionen das Artikels berücksichtigt werden.}}

Analog zum Vorgänger wird zur Installation des Boot-Sektors das Script 'grub2-install' verwendet. Als Parameter wird das Ziel-Device angegeben (im Beispiel der [[MBR]] der ersten Festplatten 'sda'):
<pre>
# grub2-install /dev/sda
Installation finished. No error reported.
</pre>
Alternativ können auch Partitionen ausgewählt werden.

Unter [[OpenSUSE]] ist alternativ zu verwenden:
*yast2 bootloader

{{Box Achtung||Dieser Schritt überschreibt möglicherweise [[Bootmanager]] anderer Systeme!}}

=Konfiguration=

==Die Kommandozeile==
''GRUB2'' verfügt über eine eingebaute Shell, welche unter anderem TAB-Completion beherrscht. Diese kann entweder direkt angesteuert werden oder wird angezeigt, wenn es Probleme mit einer invaliden Konfiguration gibt.

Hier können die selben Befehle verwendet werden, die in der Konfiguration möglich sind. Damit können beispielsweise im ''Rescue Mode'' beliebige Systeme manuell gestartet werden.

==Der Editor==
[[Bild:GRUB2-editor.png|right|thumb|300px|Der GRUB2-Editor (Beispiel)]]''GRUB2'' verfügt auch über einen eingebauten Editor. Dieser erlaubt es, einen ausgewählten Boot-Eintrag zu verändern. Dies kann sehr nützlich sein in Situationen, in denen die aktuelle Konfiguration nicht zu einem sauber gebooteten System führt - beispielsweise bei einem defekten Grafikkartentreiber infolge eines missglückten Updates.

In solchen Fällen ist es manchmal hilfreich, beim Start bestimmte Kernel-Paramter mitzugeben oder den Runlevel zu verändern.

Ein weiterer möglicher Anwendungsfall ist das schnelle Ausprobieren von Konfigurationsänderungen ohne Gefahr zu laufen, das System dauerhaft in einen Fehlerzustand zu versetzen (nicht persistente Änderung).

Dieser Editor wird aufgerufen, indem in der Anzeigephase von GRUB2 ein Eintrag ausgewählt und dann die Taste 'E' gedrückt wird. Daraufhin wird genau dieser betreffende Eintrag aus der aktuellen Datei ''grub.cfg'' in einen Editor geladen und kann dort verändert werden. Für die Steuerung des Editors gibt es eine Handvoll Tastenkürzel, welche unter dem Editor kurz aufgeführt werden. Mit 'ESC' verwirft man die Änderungen und kommt zur Auswahl zurück, mit 'Ctrl-X' oder 'F10' bootet man das System mit den angepassten Parametern.

Die Änderungen sind einmalig und werden nicht persistiert!

==YaST: boot loader==
[[OpenSUSE]]-typisch kann man einige Einstellungen auch in der Systemverwaltung [[YaST]] unter ''System / boot loader'' vornehmen.

==Default-Konfiguration: /etc/default/grub==
Globale Grundeinstellungen (Timeout, Standard-Eintrag, Layout...) werden hier definiert.

==/etc/sysconfig/bootloader==
Diese Datei enthält Konfigurationsoptionen, welche von der ''perl-bootloader library'' verwendet werden. Dies passiert dann, wenn eine Konfiguration über [[YaST]] durchgeführt wird oder ein neuer [[Kernel]] installiert wird.

Diese Datei ist [[openSUSE]]-spezifisch. Die Optionen hier werden auch nicht ausschließlich für ''GRUB 2'' verwendet, sondern auch bei anderen supporteten [[Bootmanager]]n.

==Buildsystem: /etc/grub.d==
Das Buildsystem ist eine Sammlung von Scripten. Ein Nummernpräfix sorgt für eine Abfolge in definierter Reihenfolge (bei '00' beginnend):
<pre>
# ls -l /etc/grub.d
-rwxr-xr-x 1 root root 7649 Jul 31 11:48 00_header
-rwxr-xr-x 1 root root 10535 Jul 31 11:48 10_linux
-rwxr-xr-x 1 root root 11019 Jul 31 11:48 20_linux_xen
-rwxr-xr-x 1 root root 1802 Jul 31 11:49 20_memtest86+
-rwxr-xr-x 1 root root 2596 Jul 31 11:48 20_ppc_terminfo
-rwxr-xr-x 1 root root 10132 Jul 31 11:48 30_os-prober
-rwxr-xr-x 1 root root 489 Jul 11 15:04 40_custom
-rwxr-xr-x 1 root root 216 Jul 31 11:48 41_custom
-rwxr-xr-x 1 root root 1259 Jul 31 11:49 90_persistent
-rw-r--r-- 1 root root 483 Jul 31 11:48 README
</pre>
Dieses Beispiel stammt aus einer [[OpenSUSE]]-Installation (Release 12.3). Andere Distribution liefern geringfügig andere Scripten aus. Es können diesem Schema entsprechend auch eigene Scripte hinzugefügt werden.

Bedeutung der Standard-Scripten:
*00_header: Initialisierung des Systems anhand der Einträge in /etc/default/grub ([[#Default-Konfiguration: /etc/default/grub|Default-Konfiguration]]).
*10_linux: Hier wird versucht, alle validen Kernel zu finden. Aus diesen wird dann das Bootmenü generiert.
*20_linux_xen: Für den Hypervisor [[Xen]] sind dedizierte Kernel notwendig. Hier wird die notwendige Parametrisierung hierfür durchgeführt.
*20_memtest86+: Aufnahme von [[memtest]] in das Bootmenü.
*20_ppc_terminfo: <ToDo: Funktionalität noch beschreiben>
*30_os-prober: Suche nach weiteren Bootladern sowie weiteren installierten Betriebssystemen. In einem Multi-Boot-Kontext werden hier Einträge beispielsweise für Windows oder parallele Linux-Installationen generiert.
*40_custom: Eigene Booteinträge können hier manuell hinterlegt werden. Dieses Script wird bei System-Updates nicht überschrieben.
*41_custom: Einbindung der Datei /boot/grub/custom.cfg
*90_persistent: Teile aus der aktuellen grub.cfg können hier rein kopiert werden. Dieser Inhalt wird bei einem erneuten Durchlauf des Build-Systems '''nicht''' überschrieben.

Siehe auch: [[#Konfiguration neu generieren]]

==Module laden==
''GRUB 2'' bietet direkten Zugriff auf bestimmte Ressourcen wie beispielsweise [[LVM]], [[RAID]] oder diverse [[Dateisysteme]]. Dieser Zugriff wird über Module implementiert, welche per 'insmod' bei Bedarf geladen werden können.

Unter [[OpenSUSE]] liegen diese Module (architekturabhängig) unter:
<pre>
# tree -d /usr/lib/grub2/
/usr/lib/grub2/
├── i386-pc
└── x86_64-efi
</pre>

Verfügbare Module (nur x86_64-efi):
<pre>
# ls -r --format=commas *.mod
zfsinfo.mod, zfscrypt.mod, zfs.mod, xzio.mod, xnu_uuid.mod, xnu.mod, xfs.mod, videotest.mod, videoinfo.mod, video_fb.mod, video_cirrus.mod, video_bochs.mod, video.mod,
usbtest.mod, usbserial_pl2303.mod, usbserial_ftdi.mod, usbserial_common.mod, usbms.mod, usb_keyboard.mod, usb.mod, uhci.mod, ufs2.mod, ufs1.mod, udf.mod, true.mod, trig.mod,
time.mod, tga.mod, tftp.mod, testload.mod, test_blockarg.mod, test.mod, terminfo.mod, terminal.mod, tar.mod, squash4.mod, sleep.mod, sfs.mod, setpci.mod, setjmp.mod,
serial.mod, search_label.mod, search_fs_uuid.mod, search_fs_file.mod, search.mod, scsi.mod, romfs.mod, relocator.mod, reiserfs.mod, regexp.mod, reboot.mod, read.mod,
raid6rec.mod, raid5rec.mod, probe.mod, priority_queue.mod, png.mod, play.mod, pbkdf2.mod, pata.mod, password_pbkdf2.mod, password.mod, parttool.mod, part_sunpc.mod,
part_sun.mod, part_plan.mod, part_msdos.mod, part_gpt.mod, part_dvh.mod, part_bsd.mod, part_apple.mod, part_amiga.mod, part_acorn.mod, ohci.mod, odc.mod, ntfscomp.mod,
ntfs.mod, normal.mod, nilfs2.mod, newc.mod, net.mod, multiboot2.mod, multiboot.mod, msdospart.mod, mmap.mod, minix_be.mod, minix3_be.mod, minix3.mod, minix2_be.mod, minix2.mod,
minix.mod, minicmd.mod, memrw.mod, memdisk.mod, mdraid1x.mod, mdraid09_be.mod, mdraid09.mod, lzopio.mod, lvm.mod, luks.mod, lssal.mod, lspci.mod, lsmmap.mod, lsefisystab.mod,
lsefimmap.mod, lsacpi.mod, ls.mod, loopback.mod, loadenv.mod, loadbios.mod, linuxefi.mod, linux.mod, ldm.mod, keystatus.mod, keylayouts.mod, jpeg.mod, jfs.mod, iso9660.mod,
iorw.mod, http.mod, hfsplus.mod, hfs.mod, hexdump.mod, help.mod, hello.mod, hdparm.mod, hashsum.mod, halt.mod, gzio.mod, gptsync.mod, gfxterm.mod, gfxmenu.mod, gettext.mod,
geli.mod, gcry_whirlpool.mod, gcry_twofish.mod, gcry_tiger.mod, gcry_sha512.mod, gcry_sha256.mod, gcry_sha1.mod, gcry_serpent.mod, gcry_seed.mod, gcry_rmd160.mod,
gcry_rijndael.mod, gcry_rfc2268.mod, gcry_md5.mod, gcry_md4.mod, gcry_des.mod, gcry_crc.mod, gcry_cast5.mod, gcry_camellia.mod, gcry_blowfish.mod, gcry_arcfour.mod,
functional_test.mod, fshelp.mod, font.mod, fixvideo.mod, fat.mod, extcmd.mod, ext2.mod, exfctest.mod, exfat.mod, elf.mod, ehci.mod, efinet.mod, efi_uga.mod, efi_gop.mod,
echo.mod, dm_nv.mod, diskfilter.mod, datetime.mod, datehook.mod, date.mod, cs5536.mod, cryptodisk.mod, crypto.mod, crc64.mod, cpuid.mod, cpio_be.mod, cpio.mod, configfile.mod,
cmp.mod, chain.mod, cat.mod, bufio.mod, btrfs.mod, bsd.mod, boot.mod, blocklist.mod, bitmap_scale.mod, bitmap.mod, bfs.mod, backtrace.mod, ata.mod, at_keyboard.mod,
appleldr.mod, aout.mod, all_video.mod, ahci.mod, afs.mod, affs.mod, adler32.mod, acpi.mod
</pre>

In der Konfiguration können Module über den Befehl ''insmod'' geladen werden. Ein Beispiel für die [[#Die Kommandozeile|Kommandozeile]]:
<pre>
insmod mdraid1x
</pre>

==Boot Password setzen==
Diese Funktionalität ist sinnvoll geworden, weil durch die [[#Erweiterte Funktionalitäten|erheblich ausgeweitete Funktionalität]] schon vor dem Start des OS potentiell Zugriff auf schützenswerte Daten erfolgen kann (möglicherweise auch über das Netzwerk) oder nicht gewünschte Systeme gebootet werden können. Es besteht auf diesem Wege die Möglichkeit, das Starten ausgewählter Systeme oder anderer Eigenschaften von ''GRUB2'' nur bestimmten Usern zu ermöglichen. Hierzu ist ein Authentifizierungsmechanismus und ein simples Usermangagement vorgesehen.

Hinweis: Die hier vorgestellten Mechanismen bieten keinen wirksamen Schutz vor Angreifern, welche '''physischen Zugang''' zu einem System haben sowie über ausreichend Zeit, Gelegenheit und über das notwendige KnowHow verfügen. Sollte der Angriff dem Datenbestand gelten, dann könnten die Festplatte auch ausgebaut und in einem anderen Computer eingelesen werden. Gegen solche Angriffe hilft nur eine ausreichende physikalische Sicherung und/oder eine Verschlüsselung der Daten mit ausgereiften kryptographischen Verfahren wie beispielsweise [[dm-crypt]].
Auch sollte erwähnt werden, dass hierdurch naturgemäß die Administration erschwert wird, insbesondere im Fall, dass ein System aus irgendwelchen Gründen gar nicht mehr bootet und repariert werden muss.

Gleichwohl kann das hier beschriebene Verfahren sehr wohl in bestimmten Kontexten zu einem höheren Maß an Sicherheit führen. Oftmals geht es in der IT-Sicherheit auch 'nur' darum, Hürden aufzubauen um schwächere Angriffsszenarien abdecken zu können oder Kombinationen von Sicherheitslücken zu entschärfen. So kann es durchaus sinnvoll sein, das Booten von externen Medien (USB-Stick, Netzwerk...) in Kombination mit entsprechenden Einträgen im [[BIOS]] einem Administrator vor zu behalten oder bestimmte installierte Betriebssysteme auf ausgewählte User einzugrenzen.
Einige Anwendungsfälle wurden beispielsweise [http://www.linux-club.de/viewtopic.php?f=90&t=118585 hier] diskutiert.

===Authentifizierung===
Es besteht die Möglichkeit, die Passwörter in Klartext in der Konfiguration zu hinterlegen. Viel sicherer ist es aber, anstatt von Klarttext-Passworten einen kryptographisch gesicherten [https://de.wikipedia.org/wiki/Kryptologische_Hashfunktion Passwort-Hash] zu verwenden, welcher mit einem angemessenen [https://de.wikipedia.org/wiki/Salt_%28Kryptologie%29 Salt] versehen ist (um Angriffen mit [https://de.wikipedia.org/wiki/Rainbow_Table Rainbow-Tables] abwehren zu können).

Hierzu wird das Kommando 'grub2-mkpasswd-pbkdf2' verwendet. Es generiert einen Password-Hash, welcher an den geeigneten Stellen eingetragen werden kann.

Aufruf für Password '123':
<pre>
# grub2-mkpasswd-pbkdf2
Enter password:
Reenter password:
PBKDF2 hash of your password is grub.pbkdf2.sha512.10000.DD2DF79436A5F2CA4F7363030C6C1555A7263BD692A61AAAE2847EDEF9D12B25EBBD0791EA875CBD1726D90DE9E99644BC4A630637D615AA42C06C19C26A6DC8.C68EC9D01A2DFCBEB2B36FDF6836290E8DB6F50B2BD85932AF7E6BEC8E4AC9A5BB4F027EF906AFD97FC2DC2A38745F5CA63DCC1E05049DC3CA12DC5336647249
</pre>
Folgende Aufrufe mit dem selben Password rufen immer andere Hashes hervor, was auf das Salting zurückzuführen ist.

Weitere Optionen:
<pre>
# grub2-mkpasswd-pbkdf2 -?
Usage: grub2-mkpasswd-pbkdf2 [OPTION...] [OPTIONS]
Generate PBKDF2 password hash.

-c, --iteration-count=NUM Number of PBKDF2 iterations
-l, --buflen=NUM Length of generated hash
-s, --salt=NUM Length of salt
-?, --help give this help list
--usage give a short usage message
-V, --version print program version

Mandatory or optional arguments to long options are also mandatory or optional
for any corresponding short options.
</pre>

Siehe auch: [https://de.wikipedia.org/wiki/PBKDF2 PBKDF2 (Wikipedia)]

===Authorisierung===
Zu erst wird die Liste der User definiert, welchen root-Zugriff zugebilligt werden soll. In diesem Beispiel einfach nur der User 'root':
<pre>
set superusers="root"
</pre>
Wenn diese Umgebungsvariable gesetzt ist, wird der Zugang zur [[#Kommandozeile|Kommandozeile]] nur den entsprechenden Usern erlaubt.

Als nächstes wird das Password mit den vorher generierten Password-Hashes den Usern zugeordnet:
<pre>
password_pbkdf2 root grub.pbkdf2.sha512.10000.DD2DF79436A5F2CA4F7363030C6C1555A7263BD692A61AAAE2847EDEF9D12B25EBBD0791EA875CBD1726D90DE9E99644BC4A630637D615AA42C06C19C26A6DC8.C68EC9D01A2DFCBEB2B36FDF6836290E8DB6F50B2BD85932AF7E6BEC8E4AC9A5BB4F027EF906AFD97FC2DC2A38745F5CA63DCC1E05049DC3CA12DC5336647249
password_pbkdf2 user1 grub.pbkdf2.sha512.10000.C3FFA2E95A6F933C562CFEFAFF86EE4BBE50FA20BD0575080C364D7EB37DE9CA6D7BDC58DB853EF00ECEB97376B1B7F50E051853A7DDBD917F201D58617397C1.6E29B095569E5BABD4380C47B61210F63D6F9156DA6D43C8D5F8AEAC88C7146C6C58A373C3CF4326D4B9F9CD50DDE4D890A0BDFC3E69EF5B42D5B2C09CA8086E
</pre>

Anwendugsbeispiele:

''Windows XP'' wird als unsicher eingestuft und sollte - wenn überhaupt - nicht in unsicheren Netzen eingesetzt werden. Um das sicherzustellen, wird dieses Recht nur dem besonders vertrauenswürdigen User 'user1' (oder implizit 'root') zugestanden:
<pre>
menuentry 'Windows XP (Achtung: kein Support mehr - unsicher)' --users user1 [...]
</pre>

Dieser Eintrag kann aufgrund des Parameters ''unrestricted'' von allen Benutzern gestartet werden:
<pre>
menuentry 'openSUSE 12.3, with Linux 3.7.10-1.11-desktop' --unrestricted [...]
</pre>
Ausgrenzung aller User, nur 'root' darf das Starten:
<pre>
menuentry 'openSUSE 12.3, with Linux 3.7.10-1.11-desktop (recovery mode)' --users '' [...]
</pre>

Falls weder der Parameter ''unrestricted'' noch ''users'' gesetzt ist, dann wird als User 'root' verwendet.

Hinweis: Derzeit gibt es noch keine Integration des Usermanagements in das [[#Buildsystem: /etc/grub.d|automatische Build]]. Die oben genannte Konfiguration muss also manuell in den Custom-Bereich eingetragen werden.

==Konfigurationsdatei: /boot/grub2/grub.cfg==
Dies ist die Hauptkonfigurationsdatei, welche wie oben beschrieben aber '''nicht manuell editiert''' werden sollte, weil sie vom [[#Buildsystem: /etc/grub.d|Buildsystem]] generiert wird! Es gibt System-Prozesse, welche genau das veranlassen, beispielsweise bei einem Kernelupdate. Manuelle Änderungen an dieser Datei würden spätestens da überschrieben.

Diese Datei wird beim eigentlichen Systemstart ausgewertet und bestimmt somit, welche Systeme zur Ausführung gelangen . Sie ersetzt die von [[GRUB Legacy]] bekannte Datei 'menu.lst'.

==Konfiguration neu generieren==
Um Konfigurationsänderungen zu aktivieren, muss abschließend das Kommando 'grub2-mkconfig' aufgerufen werden. Bei erfolgreicher Abarbeitung wird die [[#Konfigurationsdatei: /boot/grub2/grub.cfg|Hauptkonfigurationsdatei]] neu generiert:
<pre>
# grub2-mkconfig -o /boot/grub2/grub.cfg
Generating grub.cfg ...
Found theme: /boot/grub2/themes/openSUSE/theme.txt
Found linux image: /boot/vmlinuz-3.11.6-4-desktop
Found initrd image: /boot/initrd-3.11.6-4-desktop
Found linux image: /boot/vmlinuz-3.7.10-1.16-desktop
Found initrd image: /boot/initrd-3.7.10-1.16-desktop
Found openSUSE 12.3 (x86_64) on /dev/mapper/system-os2
done
</pre>
Im Falle von Syntax-Fehlern wird die Zieldatei nicht neu geschrieben. So wird sichergestellt ist, dass immer eine valide Konfiguration für den Systemstart vorliegt.

==Abhängigkeit zum Patch-Prozess==
Die Einträge ''initrd'' und ''linux'' in dieser Konfiguration unterliegen einer gewissen Dynamik. Es gibt eine Abhängigkeit zwischen den im Verzeichnis /boot liegenden Image-Dateien und der Konfiguration. So gibt es Anwendungsfälle, in welchen im Rahmen eines Systemupdates (Patch-Prozess) diese Images neu generiert werden (beispielsweise die ''initrd'' neu geschrieben wird). Um den Code des geänderten oder neuen Images auch nutzen zu können, wird vom Update-Prozess explizit auch die GRUB-Konfiguration neu generiert.

=Grundsätzliche Boot-Methoden=
''GRUB 2'' kennt zwei grundsätzliche Methoden, Betriebssysteme zu booten:
#Direktes Booten: Bei Betriebssystemen nach 'Multiboot Specification' wird diese Methode verwendet. Das sind hauptsächlich [[Open Source]]-Systeme.
#Chain Loading: Wird hauptsächlich bei nicht freien Betriebssystemen angewendet, für die es keinen nativen Support gibt.

==Direktes Booten (Multiboot Specification)==
Es gibt eine Spezifikation namens 'Multiboot', welche einen sauberen Multi-Boot-Betrieb zwischen unterschiedlichen Betriebssystemen zum Inhalt hat. Auf diesem Wege ist direkte Ansteuerung der installierten Systeme durch einen einzigen BootManager möglich.

Betriebssysteme mit Multiboot-Support: GNU/Linux, FreeBSD, NetBSD, OpenBSD, ...

Siehe: [http://www.gnu.org/software/grub/manual/multiboot/html_node/index.html Multiboot Specification (GNU)]

==Chain Loading==
Bei nicht quelloffenen Betriebssystemen gibt es fast immer keinen Support für direktes Booten. An diesen Stellen wird 'chain loading' verwendet, wobei hier der vorgeschaltete Boatloader (GRUB2) den Staffelstab an den nachgeschalteten (z.B. Windows) weitergibt:
<pre>
menuentry "Windows" {
insmod chain
insmod ntfs
set root=(hd0,1)
chainloader +1
}
</pre>

=Anwendungsfälle=
An dieser Stelle sollen Anleitungen zu ausgesuchten Anwendungsfällen im Zusammenhang mit ''GRUB 2'' aufgezeigt werden:
*[[Standardeintrag Bootmenü ändern (GRUB2)]]
*[[Umgang mit redundanten Laufwerken (GRUB2)]]
*[[Start von ISO-Image auf der Festplatte (GRUB2)]]
*[[Bootloader wiederherstellen]]

=Links=
*[http://www.gnu.org/software/grub/manual/html_node/index.html#SEC_Contents GRUB Documentation (GNU)] {{englisch}}
*[http://doc.opensuse.org/documentation/html/openSUSE_122/opensuse-reference/grub2.html The Boot Loader GRUB2 (doc.opensuse.org)] {{englisch}}
*[http://en.wikipedia.org/wiki/Grub2 GNU GRUB (Wikipedia)] {{englisch}}
*[https://help.ubuntu.com/community/Grub2 Grub2 (Ubuntu Documentation)] {{englisch}}
*[[GRUB]]
*[[GRUB Legacy]]

[[Kategorie:Bootmanager]] [[Kategorie:Security]]

GRUB 2

2015-11-18T10:53:04Z

Gehrke: /* Boot-Einträge manuell ändern */ ersetzt durch GRUB-Editor

{{Lückenhaft|Im aktuellen Zustand beschreibt dieser Artikel ausschließlich Systeme mit herkömmlichen [[BIOS]], aber nicht die zunehmend weiter verbreiteten [[UEFI]]-Systeme. Diese Technologie und ihre Implikationen auf GRUB2 sollte in zukünftigen Versionen das Artikels berücksichtigt werden.}}

GNU GRUB (GRand Unified Bootloader)

=Abgrenzung zu 'GRUB Legacy'=
''GRUB 2'' ist eine vollständige Neuentwicklung des Vorgängers [[GRUB Legacy]]. Seit 2009 wird es in größeren Distributionen als Standard eingeführt, [[OpenSUSE]] beispielsweise vollführte diesen Schritt mit Release 12.2 im Herbst 2012.

Um eine Reihe neuer Funktionalitäten anbieten zu können, haben sich die Entwickler für eine radikale Neu-Implementierung entschieden. Es gibt dementsprechend bis auf den Namen kaum Gemeinsamkeiten und bewusst wurde auf '''Kompatibilität zum Vorgänger verzichtet'''.

Die aktuelle Version kann beispielsweise so abgefragt werden:
<pre>
# rpm -qv grub2
grub2-2.00-39.1.3.x86_64

# grub2-install -v
grub2-install (GRUB2) 2.00
</pre>

==Erweiterte Funktionalitäten==
*Script-gesteuerte, dynamischere Konfiguration
*Unterstützung von mehr [[Dateisystem]]en wie beispielsweise [[ext4]], HFS+, [[NTFS]] ([http://www.gnu.org/software/grub/manual/html_node/Internationalisation.html#Filesystems vollständige Liste])
*Direkter Zugriff auf [[LVM]] und [[RAID]]-Devices möglich
*Steuerung über ein graphisches Terminal (besonders ''Rescue Mode'') und graphisches Menüsystem gegeben
*Mehrsprachigkeit inklusive der Einträge
*Zusätzliche Unterstützung für weitere Systemsoftware neben PC [[BIOS]]: [[UEFI|PC EFI]], PC coreboot, PowerPC, SPARC, MIPS Lemote Yeeloong
*Support für Boot via Netzwerk über [[tftp]] (PXE)
*Zugriff über serielle Konsole möglich (vor allem Embedded Devices)
*Boot Password möglich
*Start von LiveCD ISO-Images direkt von der Festplatte möglich
*Unterstützung von weiteren Plattformen neben x86 (z.B. PowerPC)
*Einführung eines Modells zur Erzeugung von angepassten Layouts (Themes)

==Unterschiede zu 'GRUB Legacy'==
An dieser Stelle werden die Unterschiede zu [[GRUB Legacy]] hervorgehoben:
*In ''Grub 2'' existiert die stufenweise Reihenfolge in den Einzelphasen ('Stage 1', 'Stage 1.5', 'Stage 2') nicht mehr.
*In der Konfiguration werden Partitionen ebenfalls über Zahlen adressiert, aber die Nummerierung beginnt mit 1 (und nicht 0).
:*Hinweis: Das gilt aber nur für Partitionen, nicht für Festplatten. Festplatten werden mit 'hdX' benannt und X beginnt bei 0!
*Die Konfiguration wurde komplett umgestellt. Wo früher eine einzelne Datei (menu.lst) zu editieren war, gibt es heute ein komplettes Konfigurationssystem aus vielen Dateien mit eigener Struktur und eigenem Build-System, welches die eigentlichen Konfigurationsdateien generiert (s. [[#Konfiguration]]).

=Installation=
{{Lückenhaft|Im aktuellen Zustand beschreibt dieser Artikel ausschließlich Systeme, welche das [[MBR]]-Partitionierungsschema verwenden. Andere Schemata wie beispielsweise [[GPT]] werden hier derzeit nicht behandelt. Da GPT-Partitionierung zunehmend an Verbreitung gewinnt, sollte dies in zukünftigen Versionen das Artikels berücksichtigt werden.}}

Analog zum Vorgänger wird zur Installation des Boot-Sektors das Script 'grub2-install' verwendet. Als Parameter wird das Ziel-Device angegeben (im Beispiel der [[MBR]] der ersten Festplatten 'sda'):
<pre>
# grub2-install /dev/sda
Installation finished. No error reported.
</pre>
Alternativ können auch Partitionen ausgewählt werden.

Unter [[OpenSUSE]] ist alternativ zu verwenden:
*yast2 bootloader

{{Box Achtung||Dieser Schritt überschreibt möglicherweise [[Bootmanager]] anderer Systeme!}}

=Konfiguration=

==Die Kommandozeile==
''GRUB2'' verfügt über eine eingebaute Shell, welche unter anderem TAB-Completion beherrscht. Diese kann entweder direkt angesteuert werden oder wird angezeigt, wenn es Probleme mit einer invaliden Konfiguration gibt.

Hier können die selben Befehle verwendet werden, die in der Konfiguration möglich sind. Damit können beispielsweise im ''Rescue Mode'' beliebige Systeme manuell gestartet werden.

==Der Editor==
[[Bild:GRUB2-editor.png|right|thumb|300px|Der GRUB2-Editor (Beispiel)]]''GRUB2'' verfügt auch über einen eingebauten Editor. Dieser erlaubt es, einen ausgewählten Boot-Eintrag zu verändern. Dies kann sehr nützlich sein in Situationen, in denen die aktuelle Konfiguration nicht zu einem sauber gebooteten System führt - beispielsweise bei einem defekten Grafikkartentreiber infolge eines missglückten Updates.

In solchen Fällen ist es manchmal hilfreich, beim Start bestimmte Kernel-Paramter mitzugeben oder den Runlevel zu verändern.

Dieser Editor wird aufgerufen, indem in der Anzeigephase von GRUB2 ein Eintrag ausgewählt und dann die Taste 'E' gedrückt wird. Daraufhin wird genau dieser betreffende Eintrag aus der aktuellen Datei ''grub.cfg'' in einen Editor geladen und kann dort verändert werden. Für die Steuerung des Editors gibt es eine Handvoll Tastenkürzel, welche unter dem Editor kurz aufgeführt werden. Mit 'ESC' verwirft man die Änderungen und kommt zur Auswahl zurück, mit 'Ctrl-X' oder 'F10' bootet man das System mit den angepassten Parametern.

Die Änderungen sind einmalig und werden nicht persistiert!

==YaST: boot loader==
[[OpenSUSE]]-typisch kann man einige Einstellungen auch in der Systemverwaltung [[YaST]] unter ''System / boot loader'' vornehmen.

==Default-Konfiguration: /etc/default/grub==
Globale Grundeinstellungen (Timeout, Standard-Eintrag, Layout...) werden hier definiert.

==/etc/sysconfig/bootloader==
Diese Datei enthält Konfigurationsoptionen, welche von der ''perl-bootloader library'' verwendet werden. Dies passiert dann, wenn eine Konfiguration über [[YaST]] durchgeführt wird oder ein neuer [[Kernel]] installiert wird.

Diese Datei ist [[openSUSE]]-spezifisch. Die Optionen hier werden auch nicht ausschließlich für ''GRUB 2'' verwendet, sondern auch bei anderen supporteten [[Bootmanager]]n.

==Buildsystem: /etc/grub.d==
Das Buildsystem ist eine Sammlung von Scripten. Ein Nummernpräfix sorgt für eine Abfolge in definierter Reihenfolge (bei '00' beginnend):
<pre>
# ls -l /etc/grub.d
-rwxr-xr-x 1 root root 7649 Jul 31 11:48 00_header
-rwxr-xr-x 1 root root 10535 Jul 31 11:48 10_linux
-rwxr-xr-x 1 root root 11019 Jul 31 11:48 20_linux_xen
-rwxr-xr-x 1 root root 1802 Jul 31 11:49 20_memtest86+
-rwxr-xr-x 1 root root 2596 Jul 31 11:48 20_ppc_terminfo
-rwxr-xr-x 1 root root 10132 Jul 31 11:48 30_os-prober
-rwxr-xr-x 1 root root 489 Jul 11 15:04 40_custom
-rwxr-xr-x 1 root root 216 Jul 31 11:48 41_custom
-rwxr-xr-x 1 root root 1259 Jul 31 11:49 90_persistent
-rw-r--r-- 1 root root 483 Jul 31 11:48 README
</pre>
Dieses Beispiel stammt aus einer [[OpenSUSE]]-Installation (Release 12.3). Andere Distribution liefern geringfügig andere Scripten aus. Es können diesem Schema entsprechend auch eigene Scripte hinzugefügt werden.

Bedeutung der Standard-Scripten:
*00_header: Initialisierung des Systems anhand der Einträge in /etc/default/grub ([[#Default-Konfiguration: /etc/default/grub|Default-Konfiguration]]).
*10_linux: Hier wird versucht, alle validen Kernel zu finden. Aus diesen wird dann das Bootmenü generiert.
*20_linux_xen: Für den Hypervisor [[Xen]] sind dedizierte Kernel notwendig. Hier wird die notwendige Parametrisierung hierfür durchgeführt.
*20_memtest86+: Aufnahme von [[memtest]] in das Bootmenü.
*20_ppc_terminfo: <ToDo: Funktionalität noch beschreiben>
*30_os-prober: Suche nach weiteren Bootladern sowie weiteren installierten Betriebssystemen. In einem Multi-Boot-Kontext werden hier Einträge beispielsweise für Windows oder parallele Linux-Installationen generiert.
*40_custom: Eigene Booteinträge können hier manuell hinterlegt werden. Dieses Script wird bei System-Updates nicht überschrieben.
*41_custom: Einbindung der Datei /boot/grub/custom.cfg
*90_persistent: Teile aus der aktuellen grub.cfg können hier rein kopiert werden. Dieser Inhalt wird bei einem erneuten Durchlauf des Build-Systems '''nicht''' überschrieben.

Siehe auch: [[#Konfiguration neu generieren]]

==Module laden==
''GRUB 2'' bietet direkten Zugriff auf bestimmte Ressourcen wie beispielsweise [[LVM]], [[RAID]] oder diverse [[Dateisysteme]]. Dieser Zugriff wird über Module implementiert, welche per 'insmod' bei Bedarf geladen werden können.

Unter [[OpenSUSE]] liegen diese Module (architekturabhängig) unter:
<pre>
# tree -d /usr/lib/grub2/
/usr/lib/grub2/
├── i386-pc
└── x86_64-efi
</pre>

Verfügbare Module (nur x86_64-efi):
<pre>
# ls -r --format=commas *.mod
zfsinfo.mod, zfscrypt.mod, zfs.mod, xzio.mod, xnu_uuid.mod, xnu.mod, xfs.mod, videotest.mod, videoinfo.mod, video_fb.mod, video_cirrus.mod, video_bochs.mod, video.mod,
usbtest.mod, usbserial_pl2303.mod, usbserial_ftdi.mod, usbserial_common.mod, usbms.mod, usb_keyboard.mod, usb.mod, uhci.mod, ufs2.mod, ufs1.mod, udf.mod, true.mod, trig.mod,
time.mod, tga.mod, tftp.mod, testload.mod, test_blockarg.mod, test.mod, terminfo.mod, terminal.mod, tar.mod, squash4.mod, sleep.mod, sfs.mod, setpci.mod, setjmp.mod,
serial.mod, search_label.mod, search_fs_uuid.mod, search_fs_file.mod, search.mod, scsi.mod, romfs.mod, relocator.mod, reiserfs.mod, regexp.mod, reboot.mod, read.mod,
raid6rec.mod, raid5rec.mod, probe.mod, priority_queue.mod, png.mod, play.mod, pbkdf2.mod, pata.mod, password_pbkdf2.mod, password.mod, parttool.mod, part_sunpc.mod,
part_sun.mod, part_plan.mod, part_msdos.mod, part_gpt.mod, part_dvh.mod, part_bsd.mod, part_apple.mod, part_amiga.mod, part_acorn.mod, ohci.mod, odc.mod, ntfscomp.mod,
ntfs.mod, normal.mod, nilfs2.mod, newc.mod, net.mod, multiboot2.mod, multiboot.mod, msdospart.mod, mmap.mod, minix_be.mod, minix3_be.mod, minix3.mod, minix2_be.mod, minix2.mod,
minix.mod, minicmd.mod, memrw.mod, memdisk.mod, mdraid1x.mod, mdraid09_be.mod, mdraid09.mod, lzopio.mod, lvm.mod, luks.mod, lssal.mod, lspci.mod, lsmmap.mod, lsefisystab.mod,
lsefimmap.mod, lsacpi.mod, ls.mod, loopback.mod, loadenv.mod, loadbios.mod, linuxefi.mod, linux.mod, ldm.mod, keystatus.mod, keylayouts.mod, jpeg.mod, jfs.mod, iso9660.mod,
iorw.mod, http.mod, hfsplus.mod, hfs.mod, hexdump.mod, help.mod, hello.mod, hdparm.mod, hashsum.mod, halt.mod, gzio.mod, gptsync.mod, gfxterm.mod, gfxmenu.mod, gettext.mod,
geli.mod, gcry_whirlpool.mod, gcry_twofish.mod, gcry_tiger.mod, gcry_sha512.mod, gcry_sha256.mod, gcry_sha1.mod, gcry_serpent.mod, gcry_seed.mod, gcry_rmd160.mod,
gcry_rijndael.mod, gcry_rfc2268.mod, gcry_md5.mod, gcry_md4.mod, gcry_des.mod, gcry_crc.mod, gcry_cast5.mod, gcry_camellia.mod, gcry_blowfish.mod, gcry_arcfour.mod,
functional_test.mod, fshelp.mod, font.mod, fixvideo.mod, fat.mod, extcmd.mod, ext2.mod, exfctest.mod, exfat.mod, elf.mod, ehci.mod, efinet.mod, efi_uga.mod, efi_gop.mod,
echo.mod, dm_nv.mod, diskfilter.mod, datetime.mod, datehook.mod, date.mod, cs5536.mod, cryptodisk.mod, crypto.mod, crc64.mod, cpuid.mod, cpio_be.mod, cpio.mod, configfile.mod,
cmp.mod, chain.mod, cat.mod, bufio.mod, btrfs.mod, bsd.mod, boot.mod, blocklist.mod, bitmap_scale.mod, bitmap.mod, bfs.mod, backtrace.mod, ata.mod, at_keyboard.mod,
appleldr.mod, aout.mod, all_video.mod, ahci.mod, afs.mod, affs.mod, adler32.mod, acpi.mod
</pre>

In der Konfiguration können Module über den Befehl ''insmod'' geladen werden. Ein Beispiel für die [[#Die Kommandozeile|Kommandozeile]]:
<pre>
insmod mdraid1x
</pre>

==Boot Password setzen==
Diese Funktionalität ist sinnvoll geworden, weil durch die [[#Erweiterte Funktionalitäten|erheblich ausgeweitete Funktionalität]] schon vor dem Start des OS potentiell Zugriff auf schützenswerte Daten erfolgen kann (möglicherweise auch über das Netzwerk) oder nicht gewünschte Systeme gebootet werden können. Es besteht auf diesem Wege die Möglichkeit, das Starten ausgewählter Systeme oder anderer Eigenschaften von ''GRUB2'' nur bestimmten Usern zu ermöglichen. Hierzu ist ein Authentifizierungsmechanismus und ein simples Usermangagement vorgesehen.

Hinweis: Die hier vorgestellten Mechanismen bieten keinen wirksamen Schutz vor Angreifern, welche '''physischen Zugang''' zu einem System haben sowie über ausreichend Zeit, Gelegenheit und über das notwendige KnowHow verfügen. Sollte der Angriff dem Datenbestand gelten, dann könnten die Festplatte auch ausgebaut und in einem anderen Computer eingelesen werden. Gegen solche Angriffe hilft nur eine ausreichende physikalische Sicherung und/oder eine Verschlüsselung der Daten mit ausgereiften kryptographischen Verfahren wie beispielsweise [[dm-crypt]].
Auch sollte erwähnt werden, dass hierdurch naturgemäß die Administration erschwert wird, insbesondere im Fall, dass ein System aus irgendwelchen Gründen gar nicht mehr bootet und repariert werden muss.

Gleichwohl kann das hier beschriebene Verfahren sehr wohl in bestimmten Kontexten zu einem höheren Maß an Sicherheit führen. Oftmals geht es in der IT-Sicherheit auch 'nur' darum, Hürden aufzubauen um schwächere Angriffsszenarien abdecken zu können oder Kombinationen von Sicherheitslücken zu entschärfen. So kann es durchaus sinnvoll sein, das Booten von externen Medien (USB-Stick, Netzwerk...) in Kombination mit entsprechenden Einträgen im [[BIOS]] einem Administrator vor zu behalten oder bestimmte installierte Betriebssysteme auf ausgewählte User einzugrenzen.
Einige Anwendungsfälle wurden beispielsweise [http://www.linux-club.de/viewtopic.php?f=90&t=118585 hier] diskutiert.

===Authentifizierung===
Es besteht die Möglichkeit, die Passwörter in Klartext in der Konfiguration zu hinterlegen. Viel sicherer ist es aber, anstatt von Klarttext-Passworten einen kryptographisch gesicherten [https://de.wikipedia.org/wiki/Kryptologische_Hashfunktion Passwort-Hash] zu verwenden, welcher mit einem angemessenen [https://de.wikipedia.org/wiki/Salt_%28Kryptologie%29 Salt] versehen ist (um Angriffen mit [https://de.wikipedia.org/wiki/Rainbow_Table Rainbow-Tables] abwehren zu können).

Hierzu wird das Kommando 'grub2-mkpasswd-pbkdf2' verwendet. Es generiert einen Password-Hash, welcher an den geeigneten Stellen eingetragen werden kann.

Aufruf für Password '123':
<pre>
# grub2-mkpasswd-pbkdf2
Enter password:
Reenter password:
PBKDF2 hash of your password is grub.pbkdf2.sha512.10000.DD2DF79436A5F2CA4F7363030C6C1555A7263BD692A61AAAE2847EDEF9D12B25EBBD0791EA875CBD1726D90DE9E99644BC4A630637D615AA42C06C19C26A6DC8.C68EC9D01A2DFCBEB2B36FDF6836290E8DB6F50B2BD85932AF7E6BEC8E4AC9A5BB4F027EF906AFD97FC2DC2A38745F5CA63DCC1E05049DC3CA12DC5336647249
</pre>
Folgende Aufrufe mit dem selben Password rufen immer andere Hashes hervor, was auf das Salting zurückzuführen ist.

Weitere Optionen:
<pre>
# grub2-mkpasswd-pbkdf2 -?
Usage: grub2-mkpasswd-pbkdf2 [OPTION...] [OPTIONS]
Generate PBKDF2 password hash.

-c, --iteration-count=NUM Number of PBKDF2 iterations
-l, --buflen=NUM Length of generated hash
-s, --salt=NUM Length of salt
-?, --help give this help list
--usage give a short usage message
-V, --version print program version

Mandatory or optional arguments to long options are also mandatory or optional
for any corresponding short options.
</pre>

Siehe auch: [https://de.wikipedia.org/wiki/PBKDF2 PBKDF2 (Wikipedia)]

===Authorisierung===
Zu erst wird die Liste der User definiert, welchen root-Zugriff zugebilligt werden soll. In diesem Beispiel einfach nur der User 'root':
<pre>
set superusers="root"
</pre>
Wenn diese Umgebungsvariable gesetzt ist, wird der Zugang zur [[#Kommandozeile|Kommandozeile]] nur den entsprechenden Usern erlaubt.

Als nächstes wird das Password mit den vorher generierten Password-Hashes den Usern zugeordnet:
<pre>
password_pbkdf2 root grub.pbkdf2.sha512.10000.DD2DF79436A5F2CA4F7363030C6C1555A7263BD692A61AAAE2847EDEF9D12B25EBBD0791EA875CBD1726D90DE9E99644BC4A630637D615AA42C06C19C26A6DC8.C68EC9D01A2DFCBEB2B36FDF6836290E8DB6F50B2BD85932AF7E6BEC8E4AC9A5BB4F027EF906AFD97FC2DC2A38745F5CA63DCC1E05049DC3CA12DC5336647249
password_pbkdf2 user1 grub.pbkdf2.sha512.10000.C3FFA2E95A6F933C562CFEFAFF86EE4BBE50FA20BD0575080C364D7EB37DE9CA6D7BDC58DB853EF00ECEB97376B1B7F50E051853A7DDBD917F201D58617397C1.6E29B095569E5BABD4380C47B61210F63D6F9156DA6D43C8D5F8AEAC88C7146C6C58A373C3CF4326D4B9F9CD50DDE4D890A0BDFC3E69EF5B42D5B2C09CA8086E
</pre>

Anwendugsbeispiele:

''Windows XP'' wird als unsicher eingestuft und sollte - wenn überhaupt - nicht in unsicheren Netzen eingesetzt werden. Um das sicherzustellen, wird dieses Recht nur dem besonders vertrauenswürdigen User 'user1' (oder implizit 'root') zugestanden:
<pre>
menuentry 'Windows XP (Achtung: kein Support mehr - unsicher)' --users user1 [...]
</pre>

Dieser Eintrag kann aufgrund des Parameters ''unrestricted'' von allen Benutzern gestartet werden:
<pre>
menuentry 'openSUSE 12.3, with Linux 3.7.10-1.11-desktop' --unrestricted [...]
</pre>
Ausgrenzung aller User, nur 'root' darf das Starten:
<pre>
menuentry 'openSUSE 12.3, with Linux 3.7.10-1.11-desktop (recovery mode)' --users '' [...]
</pre>

Falls weder der Parameter ''unrestricted'' noch ''users'' gesetzt ist, dann wird als User 'root' verwendet.

Hinweis: Derzeit gibt es noch keine Integration des Usermanagements in das [[#Buildsystem: /etc/grub.d|automatische Build]]. Die oben genannte Konfiguration muss also manuell in den Custom-Bereich eingetragen werden.

==Konfigurationsdatei: /boot/grub2/grub.cfg==
Dies ist die Hauptkonfigurationsdatei, welche wie oben beschrieben aber '''nicht manuell editiert''' werden sollte, weil sie vom [[#Buildsystem: /etc/grub.d|Buildsystem]] generiert wird! Es gibt System-Prozesse, welche genau das veranlassen, beispielsweise bei einem Kernelupdate. Manuelle Änderungen an dieser Datei würden spätestens da überschrieben.

Diese Datei wird beim eigentlichen Systemstart ausgewertet und bestimmt somit, welche Systeme zur Ausführung gelangen . Sie ersetzt die von [[GRUB Legacy]] bekannte Datei 'menu.lst'.

==Konfiguration neu generieren==
Um Konfigurationsänderungen zu aktivieren, muss abschließend das Kommando 'grub2-mkconfig' aufgerufen werden. Bei erfolgreicher Abarbeitung wird die [[#Konfigurationsdatei: /boot/grub2/grub.cfg|Hauptkonfigurationsdatei]] neu generiert:
<pre>
# grub2-mkconfig -o /boot/grub2/grub.cfg
Generating grub.cfg ...
Found theme: /boot/grub2/themes/openSUSE/theme.txt
Found linux image: /boot/vmlinuz-3.11.6-4-desktop
Found initrd image: /boot/initrd-3.11.6-4-desktop
Found linux image: /boot/vmlinuz-3.7.10-1.16-desktop
Found initrd image: /boot/initrd-3.7.10-1.16-desktop
Found openSUSE 12.3 (x86_64) on /dev/mapper/system-os2
done
</pre>
Im Falle von Syntax-Fehlern wird die Zieldatei nicht neu geschrieben. So wird sichergestellt ist, dass immer eine valide Konfiguration für den Systemstart vorliegt.

==Abhängigkeit zum Patch-Prozess==
Die Einträge ''initrd'' und ''linux'' in dieser Konfiguration unterliegen einer gewissen Dynamik. Es gibt eine Abhängigkeit zwischen den im Verzeichnis /boot liegenden Image-Dateien und der Konfiguration. So gibt es Anwendungsfälle, in welchen im Rahmen eines Systemupdates (Patch-Prozess) diese Images neu generiert werden (beispielsweise die ''initrd'' neu geschrieben wird). Um den Code des geänderten oder neuen Images auch nutzen zu können, wird vom Update-Prozess explizit auch die GRUB-Konfiguration neu generiert.

=Grundsätzliche Boot-Methoden=
''GRUB 2'' kennt zwei grundsätzliche Methoden, Betriebssysteme zu booten:
#Direktes Booten: Bei Betriebssystemen nach 'Multiboot Specification' wird diese Methode verwendet. Das sind hauptsächlich [[Open Source]]-Systeme.
#Chain Loading: Wird hauptsächlich bei nicht freien Betriebssystemen angewendet, für die es keinen nativen Support gibt.

==Direktes Booten (Multiboot Specification)==
Es gibt eine Spezifikation namens 'Multiboot', welche einen sauberen Multi-Boot-Betrieb zwischen unterschiedlichen Betriebssystemen zum Inhalt hat. Auf diesem Wege ist direkte Ansteuerung der installierten Systeme durch einen einzigen BootManager möglich.

Betriebssysteme mit Multiboot-Support: GNU/Linux, FreeBSD, NetBSD, OpenBSD, ...

Siehe: [http://www.gnu.org/software/grub/manual/multiboot/html_node/index.html Multiboot Specification (GNU)]

==Chain Loading==
Bei nicht quelloffenen Betriebssystemen gibt es fast immer keinen Support für direktes Booten. An diesen Stellen wird 'chain loading' verwendet, wobei hier der vorgeschaltete Boatloader (GRUB2) den Staffelstab an den nachgeschalteten (z.B. Windows) weitergibt:
<pre>
menuentry "Windows" {
insmod chain
insmod ntfs
set root=(hd0,1)
chainloader +1
}
</pre>

=Anwendungsfälle=
An dieser Stelle sollen Anleitungen zu ausgesuchten Anwendungsfällen im Zusammenhang mit ''GRUB 2'' aufgezeigt werden:
*[[Standardeintrag Bootmenü ändern (GRUB2)]]
*[[Umgang mit redundanten Laufwerken (GRUB2)]]
*[[Start von ISO-Image auf der Festplatte (GRUB2)]]
*[[Bootloader wiederherstellen]]

=Links=
*[http://www.gnu.org/software/grub/manual/html_node/index.html#SEC_Contents GRUB Documentation (GNU)] {{englisch}}
*[http://doc.opensuse.org/documentation/html/openSUSE_122/opensuse-reference/grub2.html The Boot Loader GRUB2 (doc.opensuse.org)] {{englisch}}
*[http://en.wikipedia.org/wiki/Grub2 GNU GRUB (Wikipedia)] {{englisch}}
*[https://help.ubuntu.com/community/Grub2 Grub2 (Ubuntu Documentation)] {{englisch}}
*[[GRUB]]
*[[GRUB Legacy]]

[[Kategorie:Bootmanager]] [[Kategorie:Security]]

GRUB 2

2015-11-18T09:44:43Z

Gehrke: /* Der Editor */ Wording

{{Lückenhaft|Im aktuellen Zustand beschreibt dieser Artikel ausschließlich Systeme mit herkömmlichen [[BIOS]], aber nicht die zunehmend weiter verbreiteten [[UEFI]]-Systeme. Diese Technologie und ihre Implikationen auf GRUB2 sollte in zukünftigen Versionen das Artikels berücksichtigt werden.}}

GNU GRUB (GRand Unified Bootloader)

=Abgrenzung zu 'GRUB Legacy'=
''GRUB 2'' ist eine vollständige Neuentwicklung des Vorgängers [[GRUB Legacy]]. Seit 2009 wird es in größeren Distributionen als Standard eingeführt, [[OpenSUSE]] beispielsweise vollführte diesen Schritt mit Release 12.2 im Herbst 2012.

Um eine Reihe neuer Funktionalitäten anbieten zu können, haben sich die Entwickler für eine radikale Neu-Implementierung entschieden. Es gibt dementsprechend bis auf den Namen kaum Gemeinsamkeiten und bewusst wurde auf '''Kompatibilität zum Vorgänger verzichtet'''.

Die aktuelle Version kann beispielsweise so abgefragt werden:
<pre>
# rpm -qv grub2
grub2-2.00-39.1.3.x86_64

# grub2-install -v
grub2-install (GRUB2) 2.00
</pre>

==Erweiterte Funktionalitäten==
*Script-gesteuerte, dynamischere Konfiguration
*Unterstützung von mehr [[Dateisystem]]en wie beispielsweise [[ext4]], HFS+, [[NTFS]] ([http://www.gnu.org/software/grub/manual/html_node/Internationalisation.html#Filesystems vollständige Liste])
*Direkter Zugriff auf [[LVM]] und [[RAID]]-Devices möglich
*Steuerung über ein graphisches Terminal (besonders ''Rescue Mode'') und graphisches Menüsystem gegeben
*Mehrsprachigkeit inklusive der Einträge
*Zusätzliche Unterstützung für weitere Systemsoftware neben PC [[BIOS]]: [[UEFI|PC EFI]], PC coreboot, PowerPC, SPARC, MIPS Lemote Yeeloong
*Support für Boot via Netzwerk über [[tftp]] (PXE)
*Zugriff über serielle Konsole möglich (vor allem Embedded Devices)
*Boot Password möglich
*Start von LiveCD ISO-Images direkt von der Festplatte möglich
*Unterstützung von weiteren Plattformen neben x86 (z.B. PowerPC)
*Einführung eines Modells zur Erzeugung von angepassten Layouts (Themes)

==Unterschiede zu 'GRUB Legacy'==
An dieser Stelle werden die Unterschiede zu [[GRUB Legacy]] hervorgehoben:
*In ''Grub 2'' existiert die stufenweise Reihenfolge in den Einzelphasen ('Stage 1', 'Stage 1.5', 'Stage 2') nicht mehr.
*In der Konfiguration werden Partitionen ebenfalls über Zahlen adressiert, aber die Nummerierung beginnt mit 1 (und nicht 0).
:*Hinweis: Das gilt aber nur für Partitionen, nicht für Festplatten. Festplatten werden mit 'hdX' benannt und X beginnt bei 0!
*Die Konfiguration wurde komplett umgestellt. Wo früher eine einzelne Datei (menu.lst) zu editieren war, gibt es heute ein komplettes Konfigurationssystem aus vielen Dateien mit eigener Struktur und eigenem Build-System, welches die eigentlichen Konfigurationsdateien generiert (s. [[#Konfiguration]]).

=Installation=
{{Lückenhaft|Im aktuellen Zustand beschreibt dieser Artikel ausschließlich Systeme, welche das [[MBR]]-Partitionierungsschema verwenden. Andere Schemata wie beispielsweise [[GPT]] werden hier derzeit nicht behandelt. Da GPT-Partitionierung zunehmend an Verbreitung gewinnt, sollte dies in zukünftigen Versionen das Artikels berücksichtigt werden.}}

Analog zum Vorgänger wird zur Installation des Boot-Sektors das Script 'grub2-install' verwendet. Als Parameter wird das Ziel-Device angegeben (im Beispiel der [[MBR]] der ersten Festplatten 'sda'):
<pre>
# grub2-install /dev/sda
Installation finished. No error reported.
</pre>
Alternativ können auch Partitionen ausgewählt werden.

Unter [[OpenSUSE]] ist alternativ zu verwenden:
*yast2 bootloader

{{Box Achtung||Dieser Schritt überschreibt möglicherweise [[Bootmanager]] anderer Systeme!}}

=Konfiguration=

==Boot-Einträge manuell ändern==
Manchmal will oder kann man nicht das komplette Setup von GRUB persistent ändern. Wenn das System beispielsweise infolge von Konfigurationsfehlern gar nicht mehr bootet oder der komplette Konfigurationszyklus zu lange dauert oder schlicht etwas ausprobiert werden soll, dann macht es Sinn, die Einträge vor dem Start manuell zu editieren.

Dies kann erreicht werden durch Drücken von 'E' während der Anzeige des Boot-Menüs. Die zu diesem Zeitpunkt selektierte Zeile wird dann in einen kleinen Editor geladen und kann dort überarbeitet werden. Mit der Tastenkombination <Strg>-<X> wird der geänderte Eintrag dann gestartet.

Die auf diesem Wege durchgeführten Änderungen sind nicht persistent.

==Die Kommandozeile==
''GRUB2'' verfügt über eine eingebaute Shell, welche unter anderem TAB-Completion beherrscht. Diese kann entweder direkt angesteuert werden oder wird angezeigt, wenn es Probleme mit einer invaliden Konfiguration gibt.

Hier können die selben Befehle verwendet werden, die in der Konfiguration möglich sind. Damit können beispielsweise im ''Rescue Mode'' beliebige Systeme manuell gestartet werden.

==Der Editor==
[[Bild:GRUB2-editor.png|right|thumb|300px|Der GRUB2-Editor (Beispiel)]]''GRUB2'' verfügt auch über einen eingebauten Editor. Dieser erlaubt es, einen ausgewählten Boot-Eintrag zu verändern. Dies kann sehr nützlich sein in Situationen, in denen die aktuelle Konfiguration nicht zu einem sauber gebooteten System führt - beispielsweise bei einem defekten Grafikkartentreiber infolge eines missglückten Updates.

In solchen Fällen ist es manchmal hilfreich, beim Start bestimmte Kernel-Paramter mitzugeben oder den Runlevel zu verändern.

Dieser Editor wird aufgerufen, indem in der Anzeigephase von GRUB2 ein Eintrag ausgewählt und dann die Taste 'E' gedrückt wird. Daraufhin wird genau dieser betreffende Eintrag aus der aktuellen Datei ''grub.cfg'' in einen Editor geladen und kann dort verändert werden. Für die Steuerung des Editors gibt es eine Handvoll Tastenkürzel, welche unter dem Editor kurz aufgeführt werden. Mit 'ESC' verwirft man die Änderungen und kommt zur Auswahl zurück, mit 'Ctrl-X' oder 'F10' bootet man das System mit den angepassten Parametern.

Die Änderungen sind einmalig und werden nicht persistiert!

==YaST: boot loader==
[[OpenSUSE]]-typisch kann man einige Einstellungen auch in der Systemverwaltung [[YaST]] unter ''System / boot loader'' vornehmen.

==Default-Konfiguration: /etc/default/grub==
Globale Grundeinstellungen (Timeout, Standard-Eintrag, Layout...) werden hier definiert.

==/etc/sysconfig/bootloader==
Diese Datei enthält Konfigurationsoptionen, welche von der ''perl-bootloader library'' verwendet werden. Dies passiert dann, wenn eine Konfiguration über [[YaST]] durchgeführt wird oder ein neuer [[Kernel]] installiert wird.

Diese Datei ist [[openSUSE]]-spezifisch. Die Optionen hier werden auch nicht ausschließlich für ''GRUB 2'' verwendet, sondern auch bei anderen supporteten [[Bootmanager]]n.

==Buildsystem: /etc/grub.d==
Das Buildsystem ist eine Sammlung von Scripten. Ein Nummernpräfix sorgt für eine Abfolge in definierter Reihenfolge (bei '00' beginnend):
<pre>
# ls -l /etc/grub.d
-rwxr-xr-x 1 root root 7649 Jul 31 11:48 00_header
-rwxr-xr-x 1 root root 10535 Jul 31 11:48 10_linux
-rwxr-xr-x 1 root root 11019 Jul 31 11:48 20_linux_xen
-rwxr-xr-x 1 root root 1802 Jul 31 11:49 20_memtest86+
-rwxr-xr-x 1 root root 2596 Jul 31 11:48 20_ppc_terminfo
-rwxr-xr-x 1 root root 10132 Jul 31 11:48 30_os-prober
-rwxr-xr-x 1 root root 489 Jul 11 15:04 40_custom
-rwxr-xr-x 1 root root 216 Jul 31 11:48 41_custom
-rwxr-xr-x 1 root root 1259 Jul 31 11:49 90_persistent
-rw-r--r-- 1 root root 483 Jul 31 11:48 README
</pre>
Dieses Beispiel stammt aus einer [[OpenSUSE]]-Installation (Release 12.3). Andere Distribution liefern geringfügig andere Scripten aus. Es können diesem Schema entsprechend auch eigene Scripte hinzugefügt werden.

Bedeutung der Standard-Scripten:
*00_header: Initialisierung des Systems anhand der Einträge in /etc/default/grub ([[#Default-Konfiguration: /etc/default/grub|Default-Konfiguration]]).
*10_linux: Hier wird versucht, alle validen Kernel zu finden. Aus diesen wird dann das Bootmenü generiert.
*20_linux_xen: Für den Hypervisor [[Xen]] sind dedizierte Kernel notwendig. Hier wird die notwendige Parametrisierung hierfür durchgeführt.
*20_memtest86+: Aufnahme von [[memtest]] in das Bootmenü.
*20_ppc_terminfo: <ToDo: Funktionalität noch beschreiben>
*30_os-prober: Suche nach weiteren Bootladern sowie weiteren installierten Betriebssystemen. In einem Multi-Boot-Kontext werden hier Einträge beispielsweise für Windows oder parallele Linux-Installationen generiert.
*40_custom: Eigene Booteinträge können hier manuell hinterlegt werden. Dieses Script wird bei System-Updates nicht überschrieben.
*41_custom: Einbindung der Datei /boot/grub/custom.cfg
*90_persistent: Teile aus der aktuellen grub.cfg können hier rein kopiert werden. Dieser Inhalt wird bei einem erneuten Durchlauf des Build-Systems '''nicht''' überschrieben.

Siehe auch: [[#Konfiguration neu generieren]]

==Module laden==
''GRUB 2'' bietet direkten Zugriff auf bestimmte Ressourcen wie beispielsweise [[LVM]], [[RAID]] oder diverse [[Dateisysteme]]. Dieser Zugriff wird über Module implementiert, welche per 'insmod' bei Bedarf geladen werden können.

Unter [[OpenSUSE]] liegen diese Module (architekturabhängig) unter:
<pre>
# tree -d /usr/lib/grub2/
/usr/lib/grub2/
├── i386-pc
└── x86_64-efi
</pre>

Verfügbare Module (nur x86_64-efi):
<pre>
# ls -r --format=commas *.mod
zfsinfo.mod, zfscrypt.mod, zfs.mod, xzio.mod, xnu_uuid.mod, xnu.mod, xfs.mod, videotest.mod, videoinfo.mod, video_fb.mod, video_cirrus.mod, video_bochs.mod, video.mod,
usbtest.mod, usbserial_pl2303.mod, usbserial_ftdi.mod, usbserial_common.mod, usbms.mod, usb_keyboard.mod, usb.mod, uhci.mod, ufs2.mod, ufs1.mod, udf.mod, true.mod, trig.mod,
time.mod, tga.mod, tftp.mod, testload.mod, test_blockarg.mod, test.mod, terminfo.mod, terminal.mod, tar.mod, squash4.mod, sleep.mod, sfs.mod, setpci.mod, setjmp.mod,
serial.mod, search_label.mod, search_fs_uuid.mod, search_fs_file.mod, search.mod, scsi.mod, romfs.mod, relocator.mod, reiserfs.mod, regexp.mod, reboot.mod, read.mod,
raid6rec.mod, raid5rec.mod, probe.mod, priority_queue.mod, png.mod, play.mod, pbkdf2.mod, pata.mod, password_pbkdf2.mod, password.mod, parttool.mod, part_sunpc.mod,
part_sun.mod, part_plan.mod, part_msdos.mod, part_gpt.mod, part_dvh.mod, part_bsd.mod, part_apple.mod, part_amiga.mod, part_acorn.mod, ohci.mod, odc.mod, ntfscomp.mod,
ntfs.mod, normal.mod, nilfs2.mod, newc.mod, net.mod, multiboot2.mod, multiboot.mod, msdospart.mod, mmap.mod, minix_be.mod, minix3_be.mod, minix3.mod, minix2_be.mod, minix2.mod,
minix.mod, minicmd.mod, memrw.mod, memdisk.mod, mdraid1x.mod, mdraid09_be.mod, mdraid09.mod, lzopio.mod, lvm.mod, luks.mod, lssal.mod, lspci.mod, lsmmap.mod, lsefisystab.mod,
lsefimmap.mod, lsacpi.mod, ls.mod, loopback.mod, loadenv.mod, loadbios.mod, linuxefi.mod, linux.mod, ldm.mod, keystatus.mod, keylayouts.mod, jpeg.mod, jfs.mod, iso9660.mod,
iorw.mod, http.mod, hfsplus.mod, hfs.mod, hexdump.mod, help.mod, hello.mod, hdparm.mod, hashsum.mod, halt.mod, gzio.mod, gptsync.mod, gfxterm.mod, gfxmenu.mod, gettext.mod,
geli.mod, gcry_whirlpool.mod, gcry_twofish.mod, gcry_tiger.mod, gcry_sha512.mod, gcry_sha256.mod, gcry_sha1.mod, gcry_serpent.mod, gcry_seed.mod, gcry_rmd160.mod,
gcry_rijndael.mod, gcry_rfc2268.mod, gcry_md5.mod, gcry_md4.mod, gcry_des.mod, gcry_crc.mod, gcry_cast5.mod, gcry_camellia.mod, gcry_blowfish.mod, gcry_arcfour.mod,
functional_test.mod, fshelp.mod, font.mod, fixvideo.mod, fat.mod, extcmd.mod, ext2.mod, exfctest.mod, exfat.mod, elf.mod, ehci.mod, efinet.mod, efi_uga.mod, efi_gop.mod,
echo.mod, dm_nv.mod, diskfilter.mod, datetime.mod, datehook.mod, date.mod, cs5536.mod, cryptodisk.mod, crypto.mod, crc64.mod, cpuid.mod, cpio_be.mod, cpio.mod, configfile.mod,
cmp.mod, chain.mod, cat.mod, bufio.mod, btrfs.mod, bsd.mod, boot.mod, blocklist.mod, bitmap_scale.mod, bitmap.mod, bfs.mod, backtrace.mod, ata.mod, at_keyboard.mod,
appleldr.mod, aout.mod, all_video.mod, ahci.mod, afs.mod, affs.mod, adler32.mod, acpi.mod
</pre>

In der Konfiguration können Module über den Befehl ''insmod'' geladen werden. Ein Beispiel für die [[#Die Kommandozeile|Kommandozeile]]:
<pre>
insmod mdraid1x
</pre>

==Boot Password setzen==
Diese Funktionalität ist sinnvoll geworden, weil durch die [[#Erweiterte Funktionalitäten|erheblich ausgeweitete Funktionalität]] schon vor dem Start des OS potentiell Zugriff auf schützenswerte Daten erfolgen kann (möglicherweise auch über das Netzwerk) oder nicht gewünschte Systeme gebootet werden können. Es besteht auf diesem Wege die Möglichkeit, das Starten ausgewählter Systeme oder anderer Eigenschaften von ''GRUB2'' nur bestimmten Usern zu ermöglichen. Hierzu ist ein Authentifizierungsmechanismus und ein simples Usermangagement vorgesehen.

Hinweis: Die hier vorgestellten Mechanismen bieten keinen wirksamen Schutz vor Angreifern, welche '''physischen Zugang''' zu einem System haben sowie über ausreichend Zeit, Gelegenheit und über das notwendige KnowHow verfügen. Sollte der Angriff dem Datenbestand gelten, dann könnten die Festplatte auch ausgebaut und in einem anderen Computer eingelesen werden. Gegen solche Angriffe hilft nur eine ausreichende physikalische Sicherung und/oder eine Verschlüsselung der Daten mit ausgereiften kryptographischen Verfahren wie beispielsweise [[dm-crypt]].
Auch sollte erwähnt werden, dass hierdurch naturgemäß die Administration erschwert wird, insbesondere im Fall, dass ein System aus irgendwelchen Gründen gar nicht mehr bootet und repariert werden muss.

Gleichwohl kann das hier beschriebene Verfahren sehr wohl in bestimmten Kontexten zu einem höheren Maß an Sicherheit führen. Oftmals geht es in der IT-Sicherheit auch 'nur' darum, Hürden aufzubauen um schwächere Angriffsszenarien abdecken zu können oder Kombinationen von Sicherheitslücken zu entschärfen. So kann es durchaus sinnvoll sein, das Booten von externen Medien (USB-Stick, Netzwerk...) in Kombination mit entsprechenden Einträgen im [[BIOS]] einem Administrator vor zu behalten oder bestimmte installierte Betriebssysteme auf ausgewählte User einzugrenzen.
Einige Anwendungsfälle wurden beispielsweise [http://www.linux-club.de/viewtopic.php?f=90&t=118585 hier] diskutiert.

===Authentifizierung===
Es besteht die Möglichkeit, die Passwörter in Klartext in der Konfiguration zu hinterlegen. Viel sicherer ist es aber, anstatt von Klarttext-Passworten einen kryptographisch gesicherten [https://de.wikipedia.org/wiki/Kryptologische_Hashfunktion Passwort-Hash] zu verwenden, welcher mit einem angemessenen [https://de.wikipedia.org/wiki/Salt_%28Kryptologie%29 Salt] versehen ist (um Angriffen mit [https://de.wikipedia.org/wiki/Rainbow_Table Rainbow-Tables] abwehren zu können).

Hierzu wird das Kommando 'grub2-mkpasswd-pbkdf2' verwendet. Es generiert einen Password-Hash, welcher an den geeigneten Stellen eingetragen werden kann.

Aufruf für Password '123':
<pre>
# grub2-mkpasswd-pbkdf2
Enter password:
Reenter password:
PBKDF2 hash of your password is grub.pbkdf2.sha512.10000.DD2DF79436A5F2CA4F7363030C6C1555A7263BD692A61AAAE2847EDEF9D12B25EBBD0791EA875CBD1726D90DE9E99644BC4A630637D615AA42C06C19C26A6DC8.C68EC9D01A2DFCBEB2B36FDF6836290E8DB6F50B2BD85932AF7E6BEC8E4AC9A5BB4F027EF906AFD97FC2DC2A38745F5CA63DCC1E05049DC3CA12DC5336647249
</pre>
Folgende Aufrufe mit dem selben Password rufen immer andere Hashes hervor, was auf das Salting zurückzuführen ist.

Weitere Optionen:
<pre>
# grub2-mkpasswd-pbkdf2 -?
Usage: grub2-mkpasswd-pbkdf2 [OPTION...] [OPTIONS]
Generate PBKDF2 password hash.

-c, --iteration-count=NUM Number of PBKDF2 iterations
-l, --buflen=NUM Length of generated hash
-s, --salt=NUM Length of salt
-?, --help give this help list
--usage give a short usage message
-V, --version print program version

Mandatory or optional arguments to long options are also mandatory or optional
for any corresponding short options.
</pre>

Siehe auch: [https://de.wikipedia.org/wiki/PBKDF2 PBKDF2 (Wikipedia)]

===Authorisierung===
Zu erst wird die Liste der User definiert, welchen root-Zugriff zugebilligt werden soll. In diesem Beispiel einfach nur der User 'root':
<pre>
set superusers="root"
</pre>
Wenn diese Umgebungsvariable gesetzt ist, wird der Zugang zur [[#Kommandozeile|Kommandozeile]] nur den entsprechenden Usern erlaubt.

Als nächstes wird das Password mit den vorher generierten Password-Hashes den Usern zugeordnet:
<pre>
password_pbkdf2 root grub.pbkdf2.sha512.10000.DD2DF79436A5F2CA4F7363030C6C1555A7263BD692A61AAAE2847EDEF9D12B25EBBD0791EA875CBD1726D90DE9E99644BC4A630637D615AA42C06C19C26A6DC8.C68EC9D01A2DFCBEB2B36FDF6836290E8DB6F50B2BD85932AF7E6BEC8E4AC9A5BB4F027EF906AFD97FC2DC2A38745F5CA63DCC1E05049DC3CA12DC5336647249
password_pbkdf2 user1 grub.pbkdf2.sha512.10000.C3FFA2E95A6F933C562CFEFAFF86EE4BBE50FA20BD0575080C364D7EB37DE9CA6D7BDC58DB853EF00ECEB97376B1B7F50E051853A7DDBD917F201D58617397C1.6E29B095569E5BABD4380C47B61210F63D6F9156DA6D43C8D5F8AEAC88C7146C6C58A373C3CF4326D4B9F9CD50DDE4D890A0BDFC3E69EF5B42D5B2C09CA8086E
</pre>

Anwendugsbeispiele:

''Windows XP'' wird als unsicher eingestuft und sollte - wenn überhaupt - nicht in unsicheren Netzen eingesetzt werden. Um das sicherzustellen, wird dieses Recht nur dem besonders vertrauenswürdigen User 'user1' (oder implizit 'root') zugestanden:
<pre>
menuentry 'Windows XP (Achtung: kein Support mehr - unsicher)' --users user1 [...]
</pre>

Dieser Eintrag kann aufgrund des Parameters ''unrestricted'' von allen Benutzern gestartet werden:
<pre>
menuentry 'openSUSE 12.3, with Linux 3.7.10-1.11-desktop' --unrestricted [...]
</pre>
Ausgrenzung aller User, nur 'root' darf das Starten:
<pre>
menuentry 'openSUSE 12.3, with Linux 3.7.10-1.11-desktop (recovery mode)' --users '' [...]
</pre>

Falls weder der Parameter ''unrestricted'' noch ''users'' gesetzt ist, dann wird als User 'root' verwendet.

Hinweis: Derzeit gibt es noch keine Integration des Usermanagements in das [[#Buildsystem: /etc/grub.d|automatische Build]]. Die oben genannte Konfiguration muss also manuell in den Custom-Bereich eingetragen werden.

==Konfigurationsdatei: /boot/grub2/grub.cfg==
Dies ist die Hauptkonfigurationsdatei, welche wie oben beschrieben aber '''nicht manuell editiert''' werden sollte, weil sie vom [[#Buildsystem: /etc/grub.d|Buildsystem]] generiert wird! Es gibt System-Prozesse, welche genau das veranlassen, beispielsweise bei einem Kernelupdate. Manuelle Änderungen an dieser Datei würden spätestens da überschrieben.

Diese Datei wird beim eigentlichen Systemstart ausgewertet und bestimmt somit, welche Systeme zur Ausführung gelangen . Sie ersetzt die von [[GRUB Legacy]] bekannte Datei 'menu.lst'.

==Konfiguration neu generieren==
Um Konfigurationsänderungen zu aktivieren, muss abschließend das Kommando 'grub2-mkconfig' aufgerufen werden. Bei erfolgreicher Abarbeitung wird die [[#Konfigurationsdatei: /boot/grub2/grub.cfg|Hauptkonfigurationsdatei]] neu generiert:
<pre>
# grub2-mkconfig -o /boot/grub2/grub.cfg
Generating grub.cfg ...
Found theme: /boot/grub2/themes/openSUSE/theme.txt
Found linux image: /boot/vmlinuz-3.11.6-4-desktop
Found initrd image: /boot/initrd-3.11.6-4-desktop
Found linux image: /boot/vmlinuz-3.7.10-1.16-desktop
Found initrd image: /boot/initrd-3.7.10-1.16-desktop
Found openSUSE 12.3 (x86_64) on /dev/mapper/system-os2
done
</pre>
Im Falle von Syntax-Fehlern wird die Zieldatei nicht neu geschrieben. So wird sichergestellt ist, dass immer eine valide Konfiguration für den Systemstart vorliegt.

==Abhängigkeit zum Patch-Prozess==
Die Einträge ''initrd'' und ''linux'' in dieser Konfiguration unterliegen einer gewissen Dynamik. Es gibt eine Abhängigkeit zwischen den im Verzeichnis /boot liegenden Image-Dateien und der Konfiguration. So gibt es Anwendungsfälle, in welchen im Rahmen eines Systemupdates (Patch-Prozess) diese Images neu generiert werden (beispielsweise die ''initrd'' neu geschrieben wird). Um den Code des geänderten oder neuen Images auch nutzen zu können, wird vom Update-Prozess explizit auch die GRUB-Konfiguration neu generiert.

=Grundsätzliche Boot-Methoden=
''GRUB 2'' kennt zwei grundsätzliche Methoden, Betriebssysteme zu booten:
#Direktes Booten: Bei Betriebssystemen nach 'Multiboot Specification' wird diese Methode verwendet. Das sind hauptsächlich [[Open Source]]-Systeme.
#Chain Loading: Wird hauptsächlich bei nicht freien Betriebssystemen angewendet, für die es keinen nativen Support gibt.

==Direktes Booten (Multiboot Specification)==
Es gibt eine Spezifikation namens 'Multiboot', welche einen sauberen Multi-Boot-Betrieb zwischen unterschiedlichen Betriebssystemen zum Inhalt hat. Auf diesem Wege ist direkte Ansteuerung der installierten Systeme durch einen einzigen BootManager möglich.

Betriebssysteme mit Multiboot-Support: GNU/Linux, FreeBSD, NetBSD, OpenBSD, ...

Siehe: [http://www.gnu.org/software/grub/manual/multiboot/html_node/index.html Multiboot Specification (GNU)]

==Chain Loading==
Bei nicht quelloffenen Betriebssystemen gibt es fast immer keinen Support für direktes Booten. An diesen Stellen wird 'chain loading' verwendet, wobei hier der vorgeschaltete Boatloader (GRUB2) den Staffelstab an den nachgeschalteten (z.B. Windows) weitergibt:
<pre>
menuentry "Windows" {
insmod chain
insmod ntfs
set root=(hd0,1)
chainloader +1
}
</pre>

=Anwendungsfälle=
An dieser Stelle sollen Anleitungen zu ausgesuchten Anwendungsfällen im Zusammenhang mit ''GRUB 2'' aufgezeigt werden:
*[[Standardeintrag Bootmenü ändern (GRUB2)]]
*[[Umgang mit redundanten Laufwerken (GRUB2)]]
*[[Start von ISO-Image auf der Festplatte (GRUB2)]]
*[[Bootloader wiederherstellen]]

=Links=
*[http://www.gnu.org/software/grub/manual/html_node/index.html#SEC_Contents GRUB Documentation (GNU)] {{englisch}}
*[http://doc.opensuse.org/documentation/html/openSUSE_122/opensuse-reference/grub2.html The Boot Loader GRUB2 (doc.opensuse.org)] {{englisch}}
*[http://en.wikipedia.org/wiki/Grub2 GNU GRUB (Wikipedia)] {{englisch}}
*[https://help.ubuntu.com/community/Grub2 Grub2 (Ubuntu Documentation)] {{englisch}}
*[[GRUB]]
*[[GRUB Legacy]]

[[Kategorie:Bootmanager]] [[Kategorie:Security]]

GRUB 2

2015-11-18T09:43:46Z

Gehrke: /* Der Editor */

{{Lückenhaft|Im aktuellen Zustand beschreibt dieser Artikel ausschließlich Systeme mit herkömmlichen [[BIOS]], aber nicht die zunehmend weiter verbreiteten [[UEFI]]-Systeme. Diese Technologie und ihre Implikationen auf GRUB2 sollte in zukünftigen Versionen das Artikels berücksichtigt werden.}}

GNU GRUB (GRand Unified Bootloader)

=Abgrenzung zu 'GRUB Legacy'=
''GRUB 2'' ist eine vollständige Neuentwicklung des Vorgängers [[GRUB Legacy]]. Seit 2009 wird es in größeren Distributionen als Standard eingeführt, [[OpenSUSE]] beispielsweise vollführte diesen Schritt mit Release 12.2 im Herbst 2012.

Um eine Reihe neuer Funktionalitäten anbieten zu können, haben sich die Entwickler für eine radikale Neu-Implementierung entschieden. Es gibt dementsprechend bis auf den Namen kaum Gemeinsamkeiten und bewusst wurde auf '''Kompatibilität zum Vorgänger verzichtet'''.

Die aktuelle Version kann beispielsweise so abgefragt werden:
<pre>
# rpm -qv grub2
grub2-2.00-39.1.3.x86_64

# grub2-install -v
grub2-install (GRUB2) 2.00
</pre>

==Erweiterte Funktionalitäten==
*Script-gesteuerte, dynamischere Konfiguration
*Unterstützung von mehr [[Dateisystem]]en wie beispielsweise [[ext4]], HFS+, [[NTFS]] ([http://www.gnu.org/software/grub/manual/html_node/Internationalisation.html#Filesystems vollständige Liste])
*Direkter Zugriff auf [[LVM]] und [[RAID]]-Devices möglich
*Steuerung über ein graphisches Terminal (besonders ''Rescue Mode'') und graphisches Menüsystem gegeben
*Mehrsprachigkeit inklusive der Einträge
*Zusätzliche Unterstützung für weitere Systemsoftware neben PC [[BIOS]]: [[UEFI|PC EFI]], PC coreboot, PowerPC, SPARC, MIPS Lemote Yeeloong
*Support für Boot via Netzwerk über [[tftp]] (PXE)
*Zugriff über serielle Konsole möglich (vor allem Embedded Devices)
*Boot Password möglich
*Start von LiveCD ISO-Images direkt von der Festplatte möglich
*Unterstützung von weiteren Plattformen neben x86 (z.B. PowerPC)
*Einführung eines Modells zur Erzeugung von angepassten Layouts (Themes)

==Unterschiede zu 'GRUB Legacy'==
An dieser Stelle werden die Unterschiede zu [[GRUB Legacy]] hervorgehoben:
*In ''Grub 2'' existiert die stufenweise Reihenfolge in den Einzelphasen ('Stage 1', 'Stage 1.5', 'Stage 2') nicht mehr.
*In der Konfiguration werden Partitionen ebenfalls über Zahlen adressiert, aber die Nummerierung beginnt mit 1 (und nicht 0).
:*Hinweis: Das gilt aber nur für Partitionen, nicht für Festplatten. Festplatten werden mit 'hdX' benannt und X beginnt bei 0!
*Die Konfiguration wurde komplett umgestellt. Wo früher eine einzelne Datei (menu.lst) zu editieren war, gibt es heute ein komplettes Konfigurationssystem aus vielen Dateien mit eigener Struktur und eigenem Build-System, welches die eigentlichen Konfigurationsdateien generiert (s. [[#Konfiguration]]).

=Installation=
{{Lückenhaft|Im aktuellen Zustand beschreibt dieser Artikel ausschließlich Systeme, welche das [[MBR]]-Partitionierungsschema verwenden. Andere Schemata wie beispielsweise [[GPT]] werden hier derzeit nicht behandelt. Da GPT-Partitionierung zunehmend an Verbreitung gewinnt, sollte dies in zukünftigen Versionen das Artikels berücksichtigt werden.}}

Analog zum Vorgänger wird zur Installation des Boot-Sektors das Script 'grub2-install' verwendet. Als Parameter wird das Ziel-Device angegeben (im Beispiel der [[MBR]] der ersten Festplatten 'sda'):
<pre>
# grub2-install /dev/sda
Installation finished. No error reported.
</pre>
Alternativ können auch Partitionen ausgewählt werden.

Unter [[OpenSUSE]] ist alternativ zu verwenden:
*yast2 bootloader

{{Box Achtung||Dieser Schritt überschreibt möglicherweise [[Bootmanager]] anderer Systeme!}}

=Konfiguration=

==Boot-Einträge manuell ändern==
Manchmal will oder kann man nicht das komplette Setup von GRUB persistent ändern. Wenn das System beispielsweise infolge von Konfigurationsfehlern gar nicht mehr bootet oder der komplette Konfigurationszyklus zu lange dauert oder schlicht etwas ausprobiert werden soll, dann macht es Sinn, die Einträge vor dem Start manuell zu editieren.

Dies kann erreicht werden durch Drücken von 'E' während der Anzeige des Boot-Menüs. Die zu diesem Zeitpunkt selektierte Zeile wird dann in einen kleinen Editor geladen und kann dort überarbeitet werden. Mit der Tastenkombination <Strg>-<X> wird der geänderte Eintrag dann gestartet.

Die auf diesem Wege durchgeführten Änderungen sind nicht persistent.

==Die Kommandozeile==
''GRUB2'' verfügt über eine eingebaute Shell, welche unter anderem TAB-Completion beherrscht. Diese kann entweder direkt angesteuert werden oder wird angezeigt, wenn es Probleme mit einer invaliden Konfiguration gibt.

Hier können die selben Befehle verwendet werden, die in der Konfiguration möglich sind. Damit können beispielsweise im ''Rescue Mode'' beliebige Systeme manuell gestartet werden.

==Der Editor==
[[Bild:GRUB2-editor.png|right|thumb|300px|Der GRUB2-Editor (Beispiel)]]''GRUB2'' verfügt auch über einen eingebauten Editor. Dieser erlaubt es, einen ausgewählten Boot-Eintrag zu verändern. Dies kann sehr nützlich sein in Situationen, in denen die aktuelle Konfiguration nicht zu einem sauber gebooteten System führt - beispielsweise bei einem defekten Grafikkartentreiber infolge eines missglückten Updates.

In solchen Fällen ist es manchmal hilfreich, beim Start bestimmte Kernel-Paramter mitzugeben oder den Runlevel zu verändern.

Dieser Editor wird aufgerufen, indem in der Anzeigephase von GRUB2 ein Eintrag ausgewählt und dann die Taste 'E' gedrückt wird. Daraufhin wird genau dieser betreffende Eintrag aus der aktuellen Datei ''grub.cfg'' in einen Editor geladen und kann dort verändert werden. Für die Steuerung des Editors gibt es eine Handvoll Tastenkürzel, welche unter dem Editor kurz aufgeführt werden. Mit 'ESC' verwirft man die Änderungen und kommt zur Auswahl zurück, mit 'Ctrl-X' oder 'F10' bootet man das System mit den editierten Parametern.

Die Änderungen sind einmalig und werden nicht persistiert!

==YaST: boot loader==
[[OpenSUSE]]-typisch kann man einige Einstellungen auch in der Systemverwaltung [[YaST]] unter ''System / boot loader'' vornehmen.

==Default-Konfiguration: /etc/default/grub==
Globale Grundeinstellungen (Timeout, Standard-Eintrag, Layout...) werden hier definiert.

==/etc/sysconfig/bootloader==
Diese Datei enthält Konfigurationsoptionen, welche von der ''perl-bootloader library'' verwendet werden. Dies passiert dann, wenn eine Konfiguration über [[YaST]] durchgeführt wird oder ein neuer [[Kernel]] installiert wird.

Diese Datei ist [[openSUSE]]-spezifisch. Die Optionen hier werden auch nicht ausschließlich für ''GRUB 2'' verwendet, sondern auch bei anderen supporteten [[Bootmanager]]n.

==Buildsystem: /etc/grub.d==
Das Buildsystem ist eine Sammlung von Scripten. Ein Nummernpräfix sorgt für eine Abfolge in definierter Reihenfolge (bei '00' beginnend):
<pre>
# ls -l /etc/grub.d
-rwxr-xr-x 1 root root 7649 Jul 31 11:48 00_header
-rwxr-xr-x 1 root root 10535 Jul 31 11:48 10_linux
-rwxr-xr-x 1 root root 11019 Jul 31 11:48 20_linux_xen
-rwxr-xr-x 1 root root 1802 Jul 31 11:49 20_memtest86+
-rwxr-xr-x 1 root root 2596 Jul 31 11:48 20_ppc_terminfo
-rwxr-xr-x 1 root root 10132 Jul 31 11:48 30_os-prober
-rwxr-xr-x 1 root root 489 Jul 11 15:04 40_custom
-rwxr-xr-x 1 root root 216 Jul 31 11:48 41_custom
-rwxr-xr-x 1 root root 1259 Jul 31 11:49 90_persistent
-rw-r--r-- 1 root root 483 Jul 31 11:48 README
</pre>
Dieses Beispiel stammt aus einer [[OpenSUSE]]-Installation (Release 12.3). Andere Distribution liefern geringfügig andere Scripten aus. Es können diesem Schema entsprechend auch eigene Scripte hinzugefügt werden.

Bedeutung der Standard-Scripten:
*00_header: Initialisierung des Systems anhand der Einträge in /etc/default/grub ([[#Default-Konfiguration: /etc/default/grub|Default-Konfiguration]]).
*10_linux: Hier wird versucht, alle validen Kernel zu finden. Aus diesen wird dann das Bootmenü generiert.
*20_linux_xen: Für den Hypervisor [[Xen]] sind dedizierte Kernel notwendig. Hier wird die notwendige Parametrisierung hierfür durchgeführt.
*20_memtest86+: Aufnahme von [[memtest]] in das Bootmenü.
*20_ppc_terminfo: <ToDo: Funktionalität noch beschreiben>
*30_os-prober: Suche nach weiteren Bootladern sowie weiteren installierten Betriebssystemen. In einem Multi-Boot-Kontext werden hier Einträge beispielsweise für Windows oder parallele Linux-Installationen generiert.
*40_custom: Eigene Booteinträge können hier manuell hinterlegt werden. Dieses Script wird bei System-Updates nicht überschrieben.
*41_custom: Einbindung der Datei /boot/grub/custom.cfg
*90_persistent: Teile aus der aktuellen grub.cfg können hier rein kopiert werden. Dieser Inhalt wird bei einem erneuten Durchlauf des Build-Systems '''nicht''' überschrieben.

Siehe auch: [[#Konfiguration neu generieren]]

==Module laden==
''GRUB 2'' bietet direkten Zugriff auf bestimmte Ressourcen wie beispielsweise [[LVM]], [[RAID]] oder diverse [[Dateisysteme]]. Dieser Zugriff wird über Module implementiert, welche per 'insmod' bei Bedarf geladen werden können.

Unter [[OpenSUSE]] liegen diese Module (architekturabhängig) unter:
<pre>
# tree -d /usr/lib/grub2/
/usr/lib/grub2/
├── i386-pc
└── x86_64-efi
</pre>

Verfügbare Module (nur x86_64-efi):
<pre>
# ls -r --format=commas *.mod
zfsinfo.mod, zfscrypt.mod, zfs.mod, xzio.mod, xnu_uuid.mod, xnu.mod, xfs.mod, videotest.mod, videoinfo.mod, video_fb.mod, video_cirrus.mod, video_bochs.mod, video.mod,
usbtest.mod, usbserial_pl2303.mod, usbserial_ftdi.mod, usbserial_common.mod, usbms.mod, usb_keyboard.mod, usb.mod, uhci.mod, ufs2.mod, ufs1.mod, udf.mod, true.mod, trig.mod,
time.mod, tga.mod, tftp.mod, testload.mod, test_blockarg.mod, test.mod, terminfo.mod, terminal.mod, tar.mod, squash4.mod, sleep.mod, sfs.mod, setpci.mod, setjmp.mod,
serial.mod, search_label.mod, search_fs_uuid.mod, search_fs_file.mod, search.mod, scsi.mod, romfs.mod, relocator.mod, reiserfs.mod, regexp.mod, reboot.mod, read.mod,
raid6rec.mod, raid5rec.mod, probe.mod, priority_queue.mod, png.mod, play.mod, pbkdf2.mod, pata.mod, password_pbkdf2.mod, password.mod, parttool.mod, part_sunpc.mod,
part_sun.mod, part_plan.mod, part_msdos.mod, part_gpt.mod, part_dvh.mod, part_bsd.mod, part_apple.mod, part_amiga.mod, part_acorn.mod, ohci.mod, odc.mod, ntfscomp.mod,
ntfs.mod, normal.mod, nilfs2.mod, newc.mod, net.mod, multiboot2.mod, multiboot.mod, msdospart.mod, mmap.mod, minix_be.mod, minix3_be.mod, minix3.mod, minix2_be.mod, minix2.mod,
minix.mod, minicmd.mod, memrw.mod, memdisk.mod, mdraid1x.mod, mdraid09_be.mod, mdraid09.mod, lzopio.mod, lvm.mod, luks.mod, lssal.mod, lspci.mod, lsmmap.mod, lsefisystab.mod,
lsefimmap.mod, lsacpi.mod, ls.mod, loopback.mod, loadenv.mod, loadbios.mod, linuxefi.mod, linux.mod, ldm.mod, keystatus.mod, keylayouts.mod, jpeg.mod, jfs.mod, iso9660.mod,
iorw.mod, http.mod, hfsplus.mod, hfs.mod, hexdump.mod, help.mod, hello.mod, hdparm.mod, hashsum.mod, halt.mod, gzio.mod, gptsync.mod, gfxterm.mod, gfxmenu.mod, gettext.mod,
geli.mod, gcry_whirlpool.mod, gcry_twofish.mod, gcry_tiger.mod, gcry_sha512.mod, gcry_sha256.mod, gcry_sha1.mod, gcry_serpent.mod, gcry_seed.mod, gcry_rmd160.mod,
gcry_rijndael.mod, gcry_rfc2268.mod, gcry_md5.mod, gcry_md4.mod, gcry_des.mod, gcry_crc.mod, gcry_cast5.mod, gcry_camellia.mod, gcry_blowfish.mod, gcry_arcfour.mod,
functional_test.mod, fshelp.mod, font.mod, fixvideo.mod, fat.mod, extcmd.mod, ext2.mod, exfctest.mod, exfat.mod, elf.mod, ehci.mod, efinet.mod, efi_uga.mod, efi_gop.mod,
echo.mod, dm_nv.mod, diskfilter.mod, datetime.mod, datehook.mod, date.mod, cs5536.mod, cryptodisk.mod, crypto.mod, crc64.mod, cpuid.mod, cpio_be.mod, cpio.mod, configfile.mod,
cmp.mod, chain.mod, cat.mod, bufio.mod, btrfs.mod, bsd.mod, boot.mod, blocklist.mod, bitmap_scale.mod, bitmap.mod, bfs.mod, backtrace.mod, ata.mod, at_keyboard.mod,
appleldr.mod, aout.mod, all_video.mod, ahci.mod, afs.mod, affs.mod, adler32.mod, acpi.mod
</pre>

In der Konfiguration können Module über den Befehl ''insmod'' geladen werden. Ein Beispiel für die [[#Die Kommandozeile|Kommandozeile]]:
<pre>
insmod mdraid1x
</pre>

==Boot Password setzen==
Diese Funktionalität ist sinnvoll geworden, weil durch die [[#Erweiterte Funktionalitäten|erheblich ausgeweitete Funktionalität]] schon vor dem Start des OS potentiell Zugriff auf schützenswerte Daten erfolgen kann (möglicherweise auch über das Netzwerk) oder nicht gewünschte Systeme gebootet werden können. Es besteht auf diesem Wege die Möglichkeit, das Starten ausgewählter Systeme oder anderer Eigenschaften von ''GRUB2'' nur bestimmten Usern zu ermöglichen. Hierzu ist ein Authentifizierungsmechanismus und ein simples Usermangagement vorgesehen.

Hinweis: Die hier vorgestellten Mechanismen bieten keinen wirksamen Schutz vor Angreifern, welche '''physischen Zugang''' zu einem System haben sowie über ausreichend Zeit, Gelegenheit und über das notwendige KnowHow verfügen. Sollte der Angriff dem Datenbestand gelten, dann könnten die Festplatte auch ausgebaut und in einem anderen Computer eingelesen werden. Gegen solche Angriffe hilft nur eine ausreichende physikalische Sicherung und/oder eine Verschlüsselung der Daten mit ausgereiften kryptographischen Verfahren wie beispielsweise [[dm-crypt]].
Auch sollte erwähnt werden, dass hierdurch naturgemäß die Administration erschwert wird, insbesondere im Fall, dass ein System aus irgendwelchen Gründen gar nicht mehr bootet und repariert werden muss.

Gleichwohl kann das hier beschriebene Verfahren sehr wohl in bestimmten Kontexten zu einem höheren Maß an Sicherheit führen. Oftmals geht es in der IT-Sicherheit auch 'nur' darum, Hürden aufzubauen um schwächere Angriffsszenarien abdecken zu können oder Kombinationen von Sicherheitslücken zu entschärfen. So kann es durchaus sinnvoll sein, das Booten von externen Medien (USB-Stick, Netzwerk...) in Kombination mit entsprechenden Einträgen im [[BIOS]] einem Administrator vor zu behalten oder bestimmte installierte Betriebssysteme auf ausgewählte User einzugrenzen.
Einige Anwendungsfälle wurden beispielsweise [http://www.linux-club.de/viewtopic.php?f=90&t=118585 hier] diskutiert.

===Authentifizierung===
Es besteht die Möglichkeit, die Passwörter in Klartext in der Konfiguration zu hinterlegen. Viel sicherer ist es aber, anstatt von Klarttext-Passworten einen kryptographisch gesicherten [https://de.wikipedia.org/wiki/Kryptologische_Hashfunktion Passwort-Hash] zu verwenden, welcher mit einem angemessenen [https://de.wikipedia.org/wiki/Salt_%28Kryptologie%29 Salt] versehen ist (um Angriffen mit [https://de.wikipedia.org/wiki/Rainbow_Table Rainbow-Tables] abwehren zu können).

Hierzu wird das Kommando 'grub2-mkpasswd-pbkdf2' verwendet. Es generiert einen Password-Hash, welcher an den geeigneten Stellen eingetragen werden kann.

Aufruf für Password '123':
<pre>
# grub2-mkpasswd-pbkdf2
Enter password:
Reenter password:
PBKDF2 hash of your password is grub.pbkdf2.sha512.10000.DD2DF79436A5F2CA4F7363030C6C1555A7263BD692A61AAAE2847EDEF9D12B25EBBD0791EA875CBD1726D90DE9E99644BC4A630637D615AA42C06C19C26A6DC8.C68EC9D01A2DFCBEB2B36FDF6836290E8DB6F50B2BD85932AF7E6BEC8E4AC9A5BB4F027EF906AFD97FC2DC2A38745F5CA63DCC1E05049DC3CA12DC5336647249
</pre>
Folgende Aufrufe mit dem selben Password rufen immer andere Hashes hervor, was auf das Salting zurückzuführen ist.

Weitere Optionen:
<pre>
# grub2-mkpasswd-pbkdf2 -?
Usage: grub2-mkpasswd-pbkdf2 [OPTION...] [OPTIONS]
Generate PBKDF2 password hash.

-c, --iteration-count=NUM Number of PBKDF2 iterations
-l, --buflen=NUM Length of generated hash
-s, --salt=NUM Length of salt
-?, --help give this help list
--usage give a short usage message
-V, --version print program version

Mandatory or optional arguments to long options are also mandatory or optional
for any corresponding short options.
</pre>

Siehe auch: [https://de.wikipedia.org/wiki/PBKDF2 PBKDF2 (Wikipedia)]

===Authorisierung===
Zu erst wird die Liste der User definiert, welchen root-Zugriff zugebilligt werden soll. In diesem Beispiel einfach nur der User 'root':
<pre>
set superusers="root"
</pre>
Wenn diese Umgebungsvariable gesetzt ist, wird der Zugang zur [[#Kommandozeile|Kommandozeile]] nur den entsprechenden Usern erlaubt.

Als nächstes wird das Password mit den vorher generierten Password-Hashes den Usern zugeordnet:
<pre>
password_pbkdf2 root grub.pbkdf2.sha512.10000.DD2DF79436A5F2CA4F7363030C6C1555A7263BD692A61AAAE2847EDEF9D12B25EBBD0791EA875CBD1726D90DE9E99644BC4A630637D615AA42C06C19C26A6DC8.C68EC9D01A2DFCBEB2B36FDF6836290E8DB6F50B2BD85932AF7E6BEC8E4AC9A5BB4F027EF906AFD97FC2DC2A38745F5CA63DCC1E05049DC3CA12DC5336647249
password_pbkdf2 user1 grub.pbkdf2.sha512.10000.C3FFA2E95A6F933C562CFEFAFF86EE4BBE50FA20BD0575080C364D7EB37DE9CA6D7BDC58DB853EF00ECEB97376B1B7F50E051853A7DDBD917F201D58617397C1.6E29B095569E5BABD4380C47B61210F63D6F9156DA6D43C8D5F8AEAC88C7146C6C58A373C3CF4326D4B9F9CD50DDE4D890A0BDFC3E69EF5B42D5B2C09CA8086E
</pre>

Anwendugsbeispiele:

''Windows XP'' wird als unsicher eingestuft und sollte - wenn überhaupt - nicht in unsicheren Netzen eingesetzt werden. Um das sicherzustellen, wird dieses Recht nur dem besonders vertrauenswürdigen User 'user1' (oder implizit 'root') zugestanden:
<pre>
menuentry 'Windows XP (Achtung: kein Support mehr - unsicher)' --users user1 [...]
</pre>

Dieser Eintrag kann aufgrund des Parameters ''unrestricted'' von allen Benutzern gestartet werden:
<pre>
menuentry 'openSUSE 12.3, with Linux 3.7.10-1.11-desktop' --unrestricted [...]
</pre>
Ausgrenzung aller User, nur 'root' darf das Starten:
<pre>
menuentry 'openSUSE 12.3, with Linux 3.7.10-1.11-desktop (recovery mode)' --users '' [...]
</pre>

Falls weder der Parameter ''unrestricted'' noch ''users'' gesetzt ist, dann wird als User 'root' verwendet.

Hinweis: Derzeit gibt es noch keine Integration des Usermanagements in das [[#Buildsystem: /etc/grub.d|automatische Build]]. Die oben genannte Konfiguration muss also manuell in den Custom-Bereich eingetragen werden.

==Konfigurationsdatei: /boot/grub2/grub.cfg==
Dies ist die Hauptkonfigurationsdatei, welche wie oben beschrieben aber '''nicht manuell editiert''' werden sollte, weil sie vom [[#Buildsystem: /etc/grub.d|Buildsystem]] generiert wird! Es gibt System-Prozesse, welche genau das veranlassen, beispielsweise bei einem Kernelupdate. Manuelle Änderungen an dieser Datei würden spätestens da überschrieben.

Diese Datei wird beim eigentlichen Systemstart ausgewertet und bestimmt somit, welche Systeme zur Ausführung gelangen . Sie ersetzt die von [[GRUB Legacy]] bekannte Datei 'menu.lst'.

==Konfiguration neu generieren==
Um Konfigurationsänderungen zu aktivieren, muss abschließend das Kommando 'grub2-mkconfig' aufgerufen werden. Bei erfolgreicher Abarbeitung wird die [[#Konfigurationsdatei: /boot/grub2/grub.cfg|Hauptkonfigurationsdatei]] neu generiert:
<pre>
# grub2-mkconfig -o /boot/grub2/grub.cfg
Generating grub.cfg ...
Found theme: /boot/grub2/themes/openSUSE/theme.txt
Found linux image: /boot/vmlinuz-3.11.6-4-desktop
Found initrd image: /boot/initrd-3.11.6-4-desktop
Found linux image: /boot/vmlinuz-3.7.10-1.16-desktop
Found initrd image: /boot/initrd-3.7.10-1.16-desktop
Found openSUSE 12.3 (x86_64) on /dev/mapper/system-os2
done
</pre>
Im Falle von Syntax-Fehlern wird die Zieldatei nicht neu geschrieben. So wird sichergestellt ist, dass immer eine valide Konfiguration für den Systemstart vorliegt.

==Abhängigkeit zum Patch-Prozess==
Die Einträge ''initrd'' und ''linux'' in dieser Konfiguration unterliegen einer gewissen Dynamik. Es gibt eine Abhängigkeit zwischen den im Verzeichnis /boot liegenden Image-Dateien und der Konfiguration. So gibt es Anwendungsfälle, in welchen im Rahmen eines Systemupdates (Patch-Prozess) diese Images neu generiert werden (beispielsweise die ''initrd'' neu geschrieben wird). Um den Code des geänderten oder neuen Images auch nutzen zu können, wird vom Update-Prozess explizit auch die GRUB-Konfiguration neu generiert.

=Grundsätzliche Boot-Methoden=
''GRUB 2'' kennt zwei grundsätzliche Methoden, Betriebssysteme zu booten:
#Direktes Booten: Bei Betriebssystemen nach 'Multiboot Specification' wird diese Methode verwendet. Das sind hauptsächlich [[Open Source]]-Systeme.
#Chain Loading: Wird hauptsächlich bei nicht freien Betriebssystemen angewendet, für die es keinen nativen Support gibt.

==Direktes Booten (Multiboot Specification)==
Es gibt eine Spezifikation namens 'Multiboot', welche einen sauberen Multi-Boot-Betrieb zwischen unterschiedlichen Betriebssystemen zum Inhalt hat. Auf diesem Wege ist direkte Ansteuerung der installierten Systeme durch einen einzigen BootManager möglich.

Betriebssysteme mit Multiboot-Support: GNU/Linux, FreeBSD, NetBSD, OpenBSD, ...

Siehe: [http://www.gnu.org/software/grub/manual/multiboot/html_node/index.html Multiboot Specification (GNU)]

==Chain Loading==
Bei nicht quelloffenen Betriebssystemen gibt es fast immer keinen Support für direktes Booten. An diesen Stellen wird 'chain loading' verwendet, wobei hier der vorgeschaltete Boatloader (GRUB2) den Staffelstab an den nachgeschalteten (z.B. Windows) weitergibt:
<pre>
menuentry "Windows" {
insmod chain
insmod ntfs
set root=(hd0,1)
chainloader +1
}
</pre>

=Anwendungsfälle=
An dieser Stelle sollen Anleitungen zu ausgesuchten Anwendungsfällen im Zusammenhang mit ''GRUB 2'' aufgezeigt werden:
*[[Standardeintrag Bootmenü ändern (GRUB2)]]
*[[Umgang mit redundanten Laufwerken (GRUB2)]]
*[[Start von ISO-Image auf der Festplatte (GRUB2)]]
*[[Bootloader wiederherstellen]]

=Links=
*[http://www.gnu.org/software/grub/manual/html_node/index.html#SEC_Contents GRUB Documentation (GNU)] {{englisch}}
*[http://doc.opensuse.org/documentation/html/openSUSE_122/opensuse-reference/grub2.html The Boot Loader GRUB2 (doc.opensuse.org)] {{englisch}}
*[http://en.wikipedia.org/wiki/Grub2 GNU GRUB (Wikipedia)] {{englisch}}
*[https://help.ubuntu.com/community/Grub2 Grub2 (Ubuntu Documentation)] {{englisch}}
*[[GRUB]]
*[[GRUB Legacy]]

[[Kategorie:Bootmanager]] [[Kategorie:Security]]

GRUB 2

2015-11-18T09:42:55Z

Gehrke: /* Der Editor */ Dimension des Bildes angepasst

{{Lückenhaft|Im aktuellen Zustand beschreibt dieser Artikel ausschließlich Systeme mit herkömmlichen [[BIOS]], aber nicht die zunehmend weiter verbreiteten [[UEFI]]-Systeme. Diese Technologie und ihre Implikationen auf GRUB2 sollte in zukünftigen Versionen das Artikels berücksichtigt werden.}}

GNU GRUB (GRand Unified Bootloader)

=Abgrenzung zu 'GRUB Legacy'=
''GRUB 2'' ist eine vollständige Neuentwicklung des Vorgängers [[GRUB Legacy]]. Seit 2009 wird es in größeren Distributionen als Standard eingeführt, [[OpenSUSE]] beispielsweise vollführte diesen Schritt mit Release 12.2 im Herbst 2012.

Um eine Reihe neuer Funktionalitäten anbieten zu können, haben sich die Entwickler für eine radikale Neu-Implementierung entschieden. Es gibt dementsprechend bis auf den Namen kaum Gemeinsamkeiten und bewusst wurde auf '''Kompatibilität zum Vorgänger verzichtet'''.

Die aktuelle Version kann beispielsweise so abgefragt werden:
<pre>
# rpm -qv grub2
grub2-2.00-39.1.3.x86_64

# grub2-install -v
grub2-install (GRUB2) 2.00
</pre>

==Erweiterte Funktionalitäten==
*Script-gesteuerte, dynamischere Konfiguration
*Unterstützung von mehr [[Dateisystem]]en wie beispielsweise [[ext4]], HFS+, [[NTFS]] ([http://www.gnu.org/software/grub/manual/html_node/Internationalisation.html#Filesystems vollständige Liste])
*Direkter Zugriff auf [[LVM]] und [[RAID]]-Devices möglich
*Steuerung über ein graphisches Terminal (besonders ''Rescue Mode'') und graphisches Menüsystem gegeben
*Mehrsprachigkeit inklusive der Einträge
*Zusätzliche Unterstützung für weitere Systemsoftware neben PC [[BIOS]]: [[UEFI|PC EFI]], PC coreboot, PowerPC, SPARC, MIPS Lemote Yeeloong
*Support für Boot via Netzwerk über [[tftp]] (PXE)
*Zugriff über serielle Konsole möglich (vor allem Embedded Devices)
*Boot Password möglich
*Start von LiveCD ISO-Images direkt von der Festplatte möglich
*Unterstützung von weiteren Plattformen neben x86 (z.B. PowerPC)
*Einführung eines Modells zur Erzeugung von angepassten Layouts (Themes)

==Unterschiede zu 'GRUB Legacy'==
An dieser Stelle werden die Unterschiede zu [[GRUB Legacy]] hervorgehoben:
*In ''Grub 2'' existiert die stufenweise Reihenfolge in den Einzelphasen ('Stage 1', 'Stage 1.5', 'Stage 2') nicht mehr.
*In der Konfiguration werden Partitionen ebenfalls über Zahlen adressiert, aber die Nummerierung beginnt mit 1 (und nicht 0).
:*Hinweis: Das gilt aber nur für Partitionen, nicht für Festplatten. Festplatten werden mit 'hdX' benannt und X beginnt bei 0!
*Die Konfiguration wurde komplett umgestellt. Wo früher eine einzelne Datei (menu.lst) zu editieren war, gibt es heute ein komplettes Konfigurationssystem aus vielen Dateien mit eigener Struktur und eigenem Build-System, welches die eigentlichen Konfigurationsdateien generiert (s. [[#Konfiguration]]).

=Installation=
{{Lückenhaft|Im aktuellen Zustand beschreibt dieser Artikel ausschließlich Systeme, welche das [[MBR]]-Partitionierungsschema verwenden. Andere Schemata wie beispielsweise [[GPT]] werden hier derzeit nicht behandelt. Da GPT-Partitionierung zunehmend an Verbreitung gewinnt, sollte dies in zukünftigen Versionen das Artikels berücksichtigt werden.}}

Analog zum Vorgänger wird zur Installation des Boot-Sektors das Script 'grub2-install' verwendet. Als Parameter wird das Ziel-Device angegeben (im Beispiel der [[MBR]] der ersten Festplatten 'sda'):
<pre>
# grub2-install /dev/sda
Installation finished. No error reported.
</pre>
Alternativ können auch Partitionen ausgewählt werden.

Unter [[OpenSUSE]] ist alternativ zu verwenden:
*yast2 bootloader

{{Box Achtung||Dieser Schritt überschreibt möglicherweise [[Bootmanager]] anderer Systeme!}}

=Konfiguration=

==Boot-Einträge manuell ändern==
Manchmal will oder kann man nicht das komplette Setup von GRUB persistent ändern. Wenn das System beispielsweise infolge von Konfigurationsfehlern gar nicht mehr bootet oder der komplette Konfigurationszyklus zu lange dauert oder schlicht etwas ausprobiert werden soll, dann macht es Sinn, die Einträge vor dem Start manuell zu editieren.

Dies kann erreicht werden durch Drücken von 'E' während der Anzeige des Boot-Menüs. Die zu diesem Zeitpunkt selektierte Zeile wird dann in einen kleinen Editor geladen und kann dort überarbeitet werden. Mit der Tastenkombination <Strg>-<X> wird der geänderte Eintrag dann gestartet.

Die auf diesem Wege durchgeführten Änderungen sind nicht persistent.

==Die Kommandozeile==
''GRUB2'' verfügt über eine eingebaute Shell, welche unter anderem TAB-Completion beherrscht. Diese kann entweder direkt angesteuert werden oder wird angezeigt, wenn es Probleme mit einer invaliden Konfiguration gibt.

Hier können die selben Befehle verwendet werden, die in der Konfiguration möglich sind. Damit können beispielsweise im ''Rescue Mode'' beliebige Systeme manuell gestartet werden.

==Der Editor==
[[Bild:GRUB2-editor.png|right|thumb|300px|Der GRUB2-Editor (Beispiel)]]''GRUB2'' verfügt auch über einen eingebauten Editor. Dieser erlaubt es, einen ausgewählten Boot-Eintrag zu verändern. Dies kann sehr nützlich sein in Situationen, in denen die aktuelle Konfiguration nicht zu einem sauber gebooteten System führt - beispielsweise bei einem defekten Grafikkartentreiber infolge eines missglückten Updates.

In solchen Fällen ist es manchmal hilfreich, beim Start bestimmte Kernel-Paramter mitzugeben oder den Runlevel zu verändern.

Dieser Editor wird aufgerufen, indem in der Anzeigephase von GRUB2 ein Eintrag ausgewählt wird und dann die Taste 'E' gedrückt wird. Daraufhin wird genau dieser betreffende Eintrag aus der aktuellen Datei ''grub.cfg'' in einen Editor geladen und kann dort verändert werden. Für die Steuerung des Editors gibt es eine Handvoll Tastenkürzel, welche unter dem Editor kurz aufgeführt werden. Mit 'ESC' verwirft man die Änderungen und kommt zur Auswahl zurück, mit 'Ctrl-X' oder 'F10' bootet man das System mit den editierten Parametern.

Die Änderungen sind einmalig und werden nicht persistiert!

==YaST: boot loader==
[[OpenSUSE]]-typisch kann man einige Einstellungen auch in der Systemverwaltung [[YaST]] unter ''System / boot loader'' vornehmen.

==Default-Konfiguration: /etc/default/grub==
Globale Grundeinstellungen (Timeout, Standard-Eintrag, Layout...) werden hier definiert.

==/etc/sysconfig/bootloader==
Diese Datei enthält Konfigurationsoptionen, welche von der ''perl-bootloader library'' verwendet werden. Dies passiert dann, wenn eine Konfiguration über [[YaST]] durchgeführt wird oder ein neuer [[Kernel]] installiert wird.

Diese Datei ist [[openSUSE]]-spezifisch. Die Optionen hier werden auch nicht ausschließlich für ''GRUB 2'' verwendet, sondern auch bei anderen supporteten [[Bootmanager]]n.

==Buildsystem: /etc/grub.d==
Das Buildsystem ist eine Sammlung von Scripten. Ein Nummernpräfix sorgt für eine Abfolge in definierter Reihenfolge (bei '00' beginnend):
<pre>
# ls -l /etc/grub.d
-rwxr-xr-x 1 root root 7649 Jul 31 11:48 00_header
-rwxr-xr-x 1 root root 10535 Jul 31 11:48 10_linux
-rwxr-xr-x 1 root root 11019 Jul 31 11:48 20_linux_xen
-rwxr-xr-x 1 root root 1802 Jul 31 11:49 20_memtest86+
-rwxr-xr-x 1 root root 2596 Jul 31 11:48 20_ppc_terminfo
-rwxr-xr-x 1 root root 10132 Jul 31 11:48 30_os-prober
-rwxr-xr-x 1 root root 489 Jul 11 15:04 40_custom
-rwxr-xr-x 1 root root 216 Jul 31 11:48 41_custom
-rwxr-xr-x 1 root root 1259 Jul 31 11:49 90_persistent
-rw-r--r-- 1 root root 483 Jul 31 11:48 README
</pre>
Dieses Beispiel stammt aus einer [[OpenSUSE]]-Installation (Release 12.3). Andere Distribution liefern geringfügig andere Scripten aus. Es können diesem Schema entsprechend auch eigene Scripte hinzugefügt werden.

Bedeutung der Standard-Scripten:
*00_header: Initialisierung des Systems anhand der Einträge in /etc/default/grub ([[#Default-Konfiguration: /etc/default/grub|Default-Konfiguration]]).
*10_linux: Hier wird versucht, alle validen Kernel zu finden. Aus diesen wird dann das Bootmenü generiert.
*20_linux_xen: Für den Hypervisor [[Xen]] sind dedizierte Kernel notwendig. Hier wird die notwendige Parametrisierung hierfür durchgeführt.
*20_memtest86+: Aufnahme von [[memtest]] in das Bootmenü.
*20_ppc_terminfo: <ToDo: Funktionalität noch beschreiben>
*30_os-prober: Suche nach weiteren Bootladern sowie weiteren installierten Betriebssystemen. In einem Multi-Boot-Kontext werden hier Einträge beispielsweise für Windows oder parallele Linux-Installationen generiert.
*40_custom: Eigene Booteinträge können hier manuell hinterlegt werden. Dieses Script wird bei System-Updates nicht überschrieben.
*41_custom: Einbindung der Datei /boot/grub/custom.cfg
*90_persistent: Teile aus der aktuellen grub.cfg können hier rein kopiert werden. Dieser Inhalt wird bei einem erneuten Durchlauf des Build-Systems '''nicht''' überschrieben.

Siehe auch: [[#Konfiguration neu generieren]]

==Module laden==
''GRUB 2'' bietet direkten Zugriff auf bestimmte Ressourcen wie beispielsweise [[LVM]], [[RAID]] oder diverse [[Dateisysteme]]. Dieser Zugriff wird über Module implementiert, welche per 'insmod' bei Bedarf geladen werden können.

Unter [[OpenSUSE]] liegen diese Module (architekturabhängig) unter:
<pre>
# tree -d /usr/lib/grub2/
/usr/lib/grub2/
├── i386-pc
└── x86_64-efi
</pre>

Verfügbare Module (nur x86_64-efi):
<pre>
# ls -r --format=commas *.mod
zfsinfo.mod, zfscrypt.mod, zfs.mod, xzio.mod, xnu_uuid.mod, xnu.mod, xfs.mod, videotest.mod, videoinfo.mod, video_fb.mod, video_cirrus.mod, video_bochs.mod, video.mod,
usbtest.mod, usbserial_pl2303.mod, usbserial_ftdi.mod, usbserial_common.mod, usbms.mod, usb_keyboard.mod, usb.mod, uhci.mod, ufs2.mod, ufs1.mod, udf.mod, true.mod, trig.mod,
time.mod, tga.mod, tftp.mod, testload.mod, test_blockarg.mod, test.mod, terminfo.mod, terminal.mod, tar.mod, squash4.mod, sleep.mod, sfs.mod, setpci.mod, setjmp.mod,
serial.mod, search_label.mod, search_fs_uuid.mod, search_fs_file.mod, search.mod, scsi.mod, romfs.mod, relocator.mod, reiserfs.mod, regexp.mod, reboot.mod, read.mod,
raid6rec.mod, raid5rec.mod, probe.mod, priority_queue.mod, png.mod, play.mod, pbkdf2.mod, pata.mod, password_pbkdf2.mod, password.mod, parttool.mod, part_sunpc.mod,
part_sun.mod, part_plan.mod, part_msdos.mod, part_gpt.mod, part_dvh.mod, part_bsd.mod, part_apple.mod, part_amiga.mod, part_acorn.mod, ohci.mod, odc.mod, ntfscomp.mod,
ntfs.mod, normal.mod, nilfs2.mod, newc.mod, net.mod, multiboot2.mod, multiboot.mod, msdospart.mod, mmap.mod, minix_be.mod, minix3_be.mod, minix3.mod, minix2_be.mod, minix2.mod,
minix.mod, minicmd.mod, memrw.mod, memdisk.mod, mdraid1x.mod, mdraid09_be.mod, mdraid09.mod, lzopio.mod, lvm.mod, luks.mod, lssal.mod, lspci.mod, lsmmap.mod, lsefisystab.mod,
lsefimmap.mod, lsacpi.mod, ls.mod, loopback.mod, loadenv.mod, loadbios.mod, linuxefi.mod, linux.mod, ldm.mod, keystatus.mod, keylayouts.mod, jpeg.mod, jfs.mod, iso9660.mod,
iorw.mod, http.mod, hfsplus.mod, hfs.mod, hexdump.mod, help.mod, hello.mod, hdparm.mod, hashsum.mod, halt.mod, gzio.mod, gptsync.mod, gfxterm.mod, gfxmenu.mod, gettext.mod,
geli.mod, gcry_whirlpool.mod, gcry_twofish.mod, gcry_tiger.mod, gcry_sha512.mod, gcry_sha256.mod, gcry_sha1.mod, gcry_serpent.mod, gcry_seed.mod, gcry_rmd160.mod,
gcry_rijndael.mod, gcry_rfc2268.mod, gcry_md5.mod, gcry_md4.mod, gcry_des.mod, gcry_crc.mod, gcry_cast5.mod, gcry_camellia.mod, gcry_blowfish.mod, gcry_arcfour.mod,
functional_test.mod, fshelp.mod, font.mod, fixvideo.mod, fat.mod, extcmd.mod, ext2.mod, exfctest.mod, exfat.mod, elf.mod, ehci.mod, efinet.mod, efi_uga.mod, efi_gop.mod,
echo.mod, dm_nv.mod, diskfilter.mod, datetime.mod, datehook.mod, date.mod, cs5536.mod, cryptodisk.mod, crypto.mod, crc64.mod, cpuid.mod, cpio_be.mod, cpio.mod, configfile.mod,
cmp.mod, chain.mod, cat.mod, bufio.mod, btrfs.mod, bsd.mod, boot.mod, blocklist.mod, bitmap_scale.mod, bitmap.mod, bfs.mod, backtrace.mod, ata.mod, at_keyboard.mod,
appleldr.mod, aout.mod, all_video.mod, ahci.mod, afs.mod, affs.mod, adler32.mod, acpi.mod
</pre>

In der Konfiguration können Module über den Befehl ''insmod'' geladen werden. Ein Beispiel für die [[#Die Kommandozeile|Kommandozeile]]:
<pre>
insmod mdraid1x
</pre>

==Boot Password setzen==
Diese Funktionalität ist sinnvoll geworden, weil durch die [[#Erweiterte Funktionalitäten|erheblich ausgeweitete Funktionalität]] schon vor dem Start des OS potentiell Zugriff auf schützenswerte Daten erfolgen kann (möglicherweise auch über das Netzwerk) oder nicht gewünschte Systeme gebootet werden können. Es besteht auf diesem Wege die Möglichkeit, das Starten ausgewählter Systeme oder anderer Eigenschaften von ''GRUB2'' nur bestimmten Usern zu ermöglichen. Hierzu ist ein Authentifizierungsmechanismus und ein simples Usermangagement vorgesehen.

Hinweis: Die hier vorgestellten Mechanismen bieten keinen wirksamen Schutz vor Angreifern, welche '''physischen Zugang''' zu einem System haben sowie über ausreichend Zeit, Gelegenheit und über das notwendige KnowHow verfügen. Sollte der Angriff dem Datenbestand gelten, dann könnten die Festplatte auch ausgebaut und in einem anderen Computer eingelesen werden. Gegen solche Angriffe hilft nur eine ausreichende physikalische Sicherung und/oder eine Verschlüsselung der Daten mit ausgereiften kryptographischen Verfahren wie beispielsweise [[dm-crypt]].
Auch sollte erwähnt werden, dass hierdurch naturgemäß die Administration erschwert wird, insbesondere im Fall, dass ein System aus irgendwelchen Gründen gar nicht mehr bootet und repariert werden muss.

Gleichwohl kann das hier beschriebene Verfahren sehr wohl in bestimmten Kontexten zu einem höheren Maß an Sicherheit führen. Oftmals geht es in der IT-Sicherheit auch 'nur' darum, Hürden aufzubauen um schwächere Angriffsszenarien abdecken zu können oder Kombinationen von Sicherheitslücken zu entschärfen. So kann es durchaus sinnvoll sein, das Booten von externen Medien (USB-Stick, Netzwerk...) in Kombination mit entsprechenden Einträgen im [[BIOS]] einem Administrator vor zu behalten oder bestimmte installierte Betriebssysteme auf ausgewählte User einzugrenzen.
Einige Anwendungsfälle wurden beispielsweise [http://www.linux-club.de/viewtopic.php?f=90&t=118585 hier] diskutiert.

===Authentifizierung===
Es besteht die Möglichkeit, die Passwörter in Klartext in der Konfiguration zu hinterlegen. Viel sicherer ist es aber, anstatt von Klarttext-Passworten einen kryptographisch gesicherten [https://de.wikipedia.org/wiki/Kryptologische_Hashfunktion Passwort-Hash] zu verwenden, welcher mit einem angemessenen [https://de.wikipedia.org/wiki/Salt_%28Kryptologie%29 Salt] versehen ist (um Angriffen mit [https://de.wikipedia.org/wiki/Rainbow_Table Rainbow-Tables] abwehren zu können).

Hierzu wird das Kommando 'grub2-mkpasswd-pbkdf2' verwendet. Es generiert einen Password-Hash, welcher an den geeigneten Stellen eingetragen werden kann.

Aufruf für Password '123':
<pre>
# grub2-mkpasswd-pbkdf2
Enter password:
Reenter password:
PBKDF2 hash of your password is grub.pbkdf2.sha512.10000.DD2DF79436A5F2CA4F7363030C6C1555A7263BD692A61AAAE2847EDEF9D12B25EBBD0791EA875CBD1726D90DE9E99644BC4A630637D615AA42C06C19C26A6DC8.C68EC9D01A2DFCBEB2B36FDF6836290E8DB6F50B2BD85932AF7E6BEC8E4AC9A5BB4F027EF906AFD97FC2DC2A38745F5CA63DCC1E05049DC3CA12DC5336647249
</pre>
Folgende Aufrufe mit dem selben Password rufen immer andere Hashes hervor, was auf das Salting zurückzuführen ist.

Weitere Optionen:
<pre>
# grub2-mkpasswd-pbkdf2 -?
Usage: grub2-mkpasswd-pbkdf2 [OPTION...] [OPTIONS]
Generate PBKDF2 password hash.

-c, --iteration-count=NUM Number of PBKDF2 iterations
-l, --buflen=NUM Length of generated hash
-s, --salt=NUM Length of salt
-?, --help give this help list
--usage give a short usage message
-V, --version print program version

Mandatory or optional arguments to long options are also mandatory or optional
for any corresponding short options.
</pre>

Siehe auch: [https://de.wikipedia.org/wiki/PBKDF2 PBKDF2 (Wikipedia)]

===Authorisierung===
Zu erst wird die Liste der User definiert, welchen root-Zugriff zugebilligt werden soll. In diesem Beispiel einfach nur der User 'root':
<pre>
set superusers="root"
</pre>
Wenn diese Umgebungsvariable gesetzt ist, wird der Zugang zur [[#Kommandozeile|Kommandozeile]] nur den entsprechenden Usern erlaubt.

Als nächstes wird das Password mit den vorher generierten Password-Hashes den Usern zugeordnet:
<pre>
password_pbkdf2 root grub.pbkdf2.sha512.10000.DD2DF79436A5F2CA4F7363030C6C1555A7263BD692A61AAAE2847EDEF9D12B25EBBD0791EA875CBD1726D90DE9E99644BC4A630637D615AA42C06C19C26A6DC8.C68EC9D01A2DFCBEB2B36FDF6836290E8DB6F50B2BD85932AF7E6BEC8E4AC9A5BB4F027EF906AFD97FC2DC2A38745F5CA63DCC1E05049DC3CA12DC5336647249
password_pbkdf2 user1 grub.pbkdf2.sha512.10000.C3FFA2E95A6F933C562CFEFAFF86EE4BBE50FA20BD0575080C364D7EB37DE9CA6D7BDC58DB853EF00ECEB97376B1B7F50E051853A7DDBD917F201D58617397C1.6E29B095569E5BABD4380C47B61210F63D6F9156DA6D43C8D5F8AEAC88C7146C6C58A373C3CF4326D4B9F9CD50DDE4D890A0BDFC3E69EF5B42D5B2C09CA8086E
</pre>

Anwendugsbeispiele:

''Windows XP'' wird als unsicher eingestuft und sollte - wenn überhaupt - nicht in unsicheren Netzen eingesetzt werden. Um das sicherzustellen, wird dieses Recht nur dem besonders vertrauenswürdigen User 'user1' (oder implizit 'root') zugestanden:
<pre>
menuentry 'Windows XP (Achtung: kein Support mehr - unsicher)' --users user1 [...]
</pre>

Dieser Eintrag kann aufgrund des Parameters ''unrestricted'' von allen Benutzern gestartet werden:
<pre>
menuentry 'openSUSE 12.3, with Linux 3.7.10-1.11-desktop' --unrestricted [...]
</pre>
Ausgrenzung aller User, nur 'root' darf das Starten:
<pre>
menuentry 'openSUSE 12.3, with Linux 3.7.10-1.11-desktop (recovery mode)' --users '' [...]
</pre>

Falls weder der Parameter ''unrestricted'' noch ''users'' gesetzt ist, dann wird als User 'root' verwendet.

Hinweis: Derzeit gibt es noch keine Integration des Usermanagements in das [[#Buildsystem: /etc/grub.d|automatische Build]]. Die oben genannte Konfiguration muss also manuell in den Custom-Bereich eingetragen werden.

==Konfigurationsdatei: /boot/grub2/grub.cfg==
Dies ist die Hauptkonfigurationsdatei, welche wie oben beschrieben aber '''nicht manuell editiert''' werden sollte, weil sie vom [[#Buildsystem: /etc/grub.d|Buildsystem]] generiert wird! Es gibt System-Prozesse, welche genau das veranlassen, beispielsweise bei einem Kernelupdate. Manuelle Änderungen an dieser Datei würden spätestens da überschrieben.

Diese Datei wird beim eigentlichen Systemstart ausgewertet und bestimmt somit, welche Systeme zur Ausführung gelangen . Sie ersetzt die von [[GRUB Legacy]] bekannte Datei 'menu.lst'.

==Konfiguration neu generieren==
Um Konfigurationsänderungen zu aktivieren, muss abschließend das Kommando 'grub2-mkconfig' aufgerufen werden. Bei erfolgreicher Abarbeitung wird die [[#Konfigurationsdatei: /boot/grub2/grub.cfg|Hauptkonfigurationsdatei]] neu generiert:
<pre>
# grub2-mkconfig -o /boot/grub2/grub.cfg
Generating grub.cfg ...
Found theme: /boot/grub2/themes/openSUSE/theme.txt
Found linux image: /boot/vmlinuz-3.11.6-4-desktop
Found initrd image: /boot/initrd-3.11.6-4-desktop
Found linux image: /boot/vmlinuz-3.7.10-1.16-desktop
Found initrd image: /boot/initrd-3.7.10-1.16-desktop
Found openSUSE 12.3 (x86_64) on /dev/mapper/system-os2
done
</pre>
Im Falle von Syntax-Fehlern wird die Zieldatei nicht neu geschrieben. So wird sichergestellt ist, dass immer eine valide Konfiguration für den Systemstart vorliegt.

==Abhängigkeit zum Patch-Prozess==
Die Einträge ''initrd'' und ''linux'' in dieser Konfiguration unterliegen einer gewissen Dynamik. Es gibt eine Abhängigkeit zwischen den im Verzeichnis /boot liegenden Image-Dateien und der Konfiguration. So gibt es Anwendungsfälle, in welchen im Rahmen eines Systemupdates (Patch-Prozess) diese Images neu generiert werden (beispielsweise die ''initrd'' neu geschrieben wird). Um den Code des geänderten oder neuen Images auch nutzen zu können, wird vom Update-Prozess explizit auch die GRUB-Konfiguration neu generiert.

=Grundsätzliche Boot-Methoden=
''GRUB 2'' kennt zwei grundsätzliche Methoden, Betriebssysteme zu booten:
#Direktes Booten: Bei Betriebssystemen nach 'Multiboot Specification' wird diese Methode verwendet. Das sind hauptsächlich [[Open Source]]-Systeme.
#Chain Loading: Wird hauptsächlich bei nicht freien Betriebssystemen angewendet, für die es keinen nativen Support gibt.

==Direktes Booten (Multiboot Specification)==
Es gibt eine Spezifikation namens 'Multiboot', welche einen sauberen Multi-Boot-Betrieb zwischen unterschiedlichen Betriebssystemen zum Inhalt hat. Auf diesem Wege ist direkte Ansteuerung der installierten Systeme durch einen einzigen BootManager möglich.

Betriebssysteme mit Multiboot-Support: GNU/Linux, FreeBSD, NetBSD, OpenBSD, ...

Siehe: [http://www.gnu.org/software/grub/manual/multiboot/html_node/index.html Multiboot Specification (GNU)]

==Chain Loading==
Bei nicht quelloffenen Betriebssystemen gibt es fast immer keinen Support für direktes Booten. An diesen Stellen wird 'chain loading' verwendet, wobei hier der vorgeschaltete Boatloader (GRUB2) den Staffelstab an den nachgeschalteten (z.B. Windows) weitergibt:
<pre>
menuentry "Windows" {
insmod chain
insmod ntfs
set root=(hd0,1)
chainloader +1
}
</pre>

=Anwendungsfälle=
An dieser Stelle sollen Anleitungen zu ausgesuchten Anwendungsfällen im Zusammenhang mit ''GRUB 2'' aufgezeigt werden:
*[[Standardeintrag Bootmenü ändern (GRUB2)]]
*[[Umgang mit redundanten Laufwerken (GRUB2)]]
*[[Start von ISO-Image auf der Festplatte (GRUB2)]]
*[[Bootloader wiederherstellen]]

=Links=
*[http://www.gnu.org/software/grub/manual/html_node/index.html#SEC_Contents GRUB Documentation (GNU)] {{englisch}}
*[http://doc.opensuse.org/documentation/html/openSUSE_122/opensuse-reference/grub2.html The Boot Loader GRUB2 (doc.opensuse.org)] {{englisch}}
*[http://en.wikipedia.org/wiki/Grub2 GNU GRUB (Wikipedia)] {{englisch}}
*[https://help.ubuntu.com/community/Grub2 Grub2 (Ubuntu Documentation)] {{englisch}}
*[[GRUB]]
*[[GRUB Legacy]]

[[Kategorie:Bootmanager]] [[Kategorie:Security]]

Datei:GRUB2-editor.png

2015-11-18T09:41:00Z

Gehrke: Der Editor von GRUB2 (Beispiel)

Der Editor von GRUB2 (Beispiel)

GRUB 2

2015-11-18T09:40:07Z

Gehrke: /* Der Editor */ Beispiel-Bild

{{Lückenhaft|Im aktuellen Zustand beschreibt dieser Artikel ausschließlich Systeme mit herkömmlichen [[BIOS]], aber nicht die zunehmend weiter verbreiteten [[UEFI]]-Systeme. Diese Technologie und ihre Implikationen auf GRUB2 sollte in zukünftigen Versionen das Artikels berücksichtigt werden.}}

GNU GRUB (GRand Unified Bootloader)

=Abgrenzung zu 'GRUB Legacy'=
''GRUB 2'' ist eine vollständige Neuentwicklung des Vorgängers [[GRUB Legacy]]. Seit 2009 wird es in größeren Distributionen als Standard eingeführt, [[OpenSUSE]] beispielsweise vollführte diesen Schritt mit Release 12.2 im Herbst 2012.

Um eine Reihe neuer Funktionalitäten anbieten zu können, haben sich die Entwickler für eine radikale Neu-Implementierung entschieden. Es gibt dementsprechend bis auf den Namen kaum Gemeinsamkeiten und bewusst wurde auf '''Kompatibilität zum Vorgänger verzichtet'''.

Die aktuelle Version kann beispielsweise so abgefragt werden:
<pre>
# rpm -qv grub2
grub2-2.00-39.1.3.x86_64

# grub2-install -v
grub2-install (GRUB2) 2.00
</pre>

==Erweiterte Funktionalitäten==
*Script-gesteuerte, dynamischere Konfiguration
*Unterstützung von mehr [[Dateisystem]]en wie beispielsweise [[ext4]], HFS+, [[NTFS]] ([http://www.gnu.org/software/grub/manual/html_node/Internationalisation.html#Filesystems vollständige Liste])
*Direkter Zugriff auf [[LVM]] und [[RAID]]-Devices möglich
*Steuerung über ein graphisches Terminal (besonders ''Rescue Mode'') und graphisches Menüsystem gegeben
*Mehrsprachigkeit inklusive der Einträge
*Zusätzliche Unterstützung für weitere Systemsoftware neben PC [[BIOS]]: [[UEFI|PC EFI]], PC coreboot, PowerPC, SPARC, MIPS Lemote Yeeloong
*Support für Boot via Netzwerk über [[tftp]] (PXE)
*Zugriff über serielle Konsole möglich (vor allem Embedded Devices)
*Boot Password möglich
*Start von LiveCD ISO-Images direkt von der Festplatte möglich
*Unterstützung von weiteren Plattformen neben x86 (z.B. PowerPC)
*Einführung eines Modells zur Erzeugung von angepassten Layouts (Themes)

==Unterschiede zu 'GRUB Legacy'==
An dieser Stelle werden die Unterschiede zu [[GRUB Legacy]] hervorgehoben:
*In ''Grub 2'' existiert die stufenweise Reihenfolge in den Einzelphasen ('Stage 1', 'Stage 1.5', 'Stage 2') nicht mehr.
*In der Konfiguration werden Partitionen ebenfalls über Zahlen adressiert, aber die Nummerierung beginnt mit 1 (und nicht 0).
:*Hinweis: Das gilt aber nur für Partitionen, nicht für Festplatten. Festplatten werden mit 'hdX' benannt und X beginnt bei 0!
*Die Konfiguration wurde komplett umgestellt. Wo früher eine einzelne Datei (menu.lst) zu editieren war, gibt es heute ein komplettes Konfigurationssystem aus vielen Dateien mit eigener Struktur und eigenem Build-System, welches die eigentlichen Konfigurationsdateien generiert (s. [[#Konfiguration]]).

=Installation=
{{Lückenhaft|Im aktuellen Zustand beschreibt dieser Artikel ausschließlich Systeme, welche das [[MBR]]-Partitionierungsschema verwenden. Andere Schemata wie beispielsweise [[GPT]] werden hier derzeit nicht behandelt. Da GPT-Partitionierung zunehmend an Verbreitung gewinnt, sollte dies in zukünftigen Versionen das Artikels berücksichtigt werden.}}

Analog zum Vorgänger wird zur Installation des Boot-Sektors das Script 'grub2-install' verwendet. Als Parameter wird das Ziel-Device angegeben (im Beispiel der [[MBR]] der ersten Festplatten 'sda'):
<pre>
# grub2-install /dev/sda
Installation finished. No error reported.
</pre>
Alternativ können auch Partitionen ausgewählt werden.

Unter [[OpenSUSE]] ist alternativ zu verwenden:
*yast2 bootloader

{{Box Achtung||Dieser Schritt überschreibt möglicherweise [[Bootmanager]] anderer Systeme!}}

=Konfiguration=

==Boot-Einträge manuell ändern==
Manchmal will oder kann man nicht das komplette Setup von GRUB persistent ändern. Wenn das System beispielsweise infolge von Konfigurationsfehlern gar nicht mehr bootet oder der komplette Konfigurationszyklus zu lange dauert oder schlicht etwas ausprobiert werden soll, dann macht es Sinn, die Einträge vor dem Start manuell zu editieren.

Dies kann erreicht werden durch Drücken von 'E' während der Anzeige des Boot-Menüs. Die zu diesem Zeitpunkt selektierte Zeile wird dann in einen kleinen Editor geladen und kann dort überarbeitet werden. Mit der Tastenkombination <Strg>-<X> wird der geänderte Eintrag dann gestartet.

Die auf diesem Wege durchgeführten Änderungen sind nicht persistent.

==Die Kommandozeile==
''GRUB2'' verfügt über eine eingebaute Shell, welche unter anderem TAB-Completion beherrscht. Diese kann entweder direkt angesteuert werden oder wird angezeigt, wenn es Probleme mit einer invaliden Konfiguration gibt.

Hier können die selben Befehle verwendet werden, die in der Konfiguration möglich sind. Damit können beispielsweise im ''Rescue Mode'' beliebige Systeme manuell gestartet werden.

==Der Editor==
[[Bild:GRUB2-editor.png|right|thumb|633px|Der GRUB2-Editor (Beispiel)]]''GRUB2'' verfügt auch über einen eingebauten Editor. Dieser erlaubt es, einen ausgewählten Boot-Eintrag zu verändern. Dies kann sehr nützlich sein in Situationen, in denen die aktuelle Konfiguration nicht zu einem sauber gebooteten System führt - beispielsweise bei einem defekten Grafikkartentreiber infolge eines missglückten Updates.

In solchen Fällen ist es manchmal hilfreich, beim Start bestimmte Kernel-Paramter mitzugeben oder den Runlevel zu verändern.

Dieser Editor wird aufgerufen, indem in der Anzeigephase von GRUB2 ein Eintrag ausgewählt wird und dann die Taste 'E' gedrückt wird. Daraufhin wird genau dieser betreffende Eintrag aus der aktuellen Datei ''grub.cfg'' in einen Editor geladen und kann dort verändert werden. Für die Steuerung des Editors gibt es eine Handvoll Tastenkürzel, welche unter dem Editor kurz aufgeführt werden. Mit 'ESC' verwirft man die Änderungen und kommt zur Auswahl zurück, mit 'Ctrl-X' oder 'F10' bootet man das System mit den editierten Parametern.

Die Änderungen sind einmalig und werden nicht persistiert!

==YaST: boot loader==
[[OpenSUSE]]-typisch kann man einige Einstellungen auch in der Systemverwaltung [[YaST]] unter ''System / boot loader'' vornehmen.

==Default-Konfiguration: /etc/default/grub==
Globale Grundeinstellungen (Timeout, Standard-Eintrag, Layout...) werden hier definiert.

==/etc/sysconfig/bootloader==
Diese Datei enthält Konfigurationsoptionen, welche von der ''perl-bootloader library'' verwendet werden. Dies passiert dann, wenn eine Konfiguration über [[YaST]] durchgeführt wird oder ein neuer [[Kernel]] installiert wird.

Diese Datei ist [[openSUSE]]-spezifisch. Die Optionen hier werden auch nicht ausschließlich für ''GRUB 2'' verwendet, sondern auch bei anderen supporteten [[Bootmanager]]n.

==Buildsystem: /etc/grub.d==
Das Buildsystem ist eine Sammlung von Scripten. Ein Nummernpräfix sorgt für eine Abfolge in definierter Reihenfolge (bei '00' beginnend):
<pre>
# ls -l /etc/grub.d
-rwxr-xr-x 1 root root 7649 Jul 31 11:48 00_header
-rwxr-xr-x 1 root root 10535 Jul 31 11:48 10_linux
-rwxr-xr-x 1 root root 11019 Jul 31 11:48 20_linux_xen
-rwxr-xr-x 1 root root 1802 Jul 31 11:49 20_memtest86+
-rwxr-xr-x 1 root root 2596 Jul 31 11:48 20_ppc_terminfo
-rwxr-xr-x 1 root root 10132 Jul 31 11:48 30_os-prober
-rwxr-xr-x 1 root root 489 Jul 11 15:04 40_custom
-rwxr-xr-x 1 root root 216 Jul 31 11:48 41_custom
-rwxr-xr-x 1 root root 1259 Jul 31 11:49 90_persistent
-rw-r--r-- 1 root root 483 Jul 31 11:48 README
</pre>
Dieses Beispiel stammt aus einer [[OpenSUSE]]-Installation (Release 12.3). Andere Distribution liefern geringfügig andere Scripten aus. Es können diesem Schema entsprechend auch eigene Scripte hinzugefügt werden.

Bedeutung der Standard-Scripten:
*00_header: Initialisierung des Systems anhand der Einträge in /etc/default/grub ([[#Default-Konfiguration: /etc/default/grub|Default-Konfiguration]]).
*10_linux: Hier wird versucht, alle validen Kernel zu finden. Aus diesen wird dann das Bootmenü generiert.
*20_linux_xen: Für den Hypervisor [[Xen]] sind dedizierte Kernel notwendig. Hier wird die notwendige Parametrisierung hierfür durchgeführt.
*20_memtest86+: Aufnahme von [[memtest]] in das Bootmenü.
*20_ppc_terminfo: <ToDo: Funktionalität noch beschreiben>
*30_os-prober: Suche nach weiteren Bootladern sowie weiteren installierten Betriebssystemen. In einem Multi-Boot-Kontext werden hier Einträge beispielsweise für Windows oder parallele Linux-Installationen generiert.
*40_custom: Eigene Booteinträge können hier manuell hinterlegt werden. Dieses Script wird bei System-Updates nicht überschrieben.
*41_custom: Einbindung der Datei /boot/grub/custom.cfg
*90_persistent: Teile aus der aktuellen grub.cfg können hier rein kopiert werden. Dieser Inhalt wird bei einem erneuten Durchlauf des Build-Systems '''nicht''' überschrieben.

Siehe auch: [[#Konfiguration neu generieren]]

==Module laden==
''GRUB 2'' bietet direkten Zugriff auf bestimmte Ressourcen wie beispielsweise [[LVM]], [[RAID]] oder diverse [[Dateisysteme]]. Dieser Zugriff wird über Module implementiert, welche per 'insmod' bei Bedarf geladen werden können.

Unter [[OpenSUSE]] liegen diese Module (architekturabhängig) unter:
<pre>
# tree -d /usr/lib/grub2/
/usr/lib/grub2/
├── i386-pc
└── x86_64-efi
</pre>

Verfügbare Module (nur x86_64-efi):
<pre>
# ls -r --format=commas *.mod
zfsinfo.mod, zfscrypt.mod, zfs.mod, xzio.mod, xnu_uuid.mod, xnu.mod, xfs.mod, videotest.mod, videoinfo.mod, video_fb.mod, video_cirrus.mod, video_bochs.mod, video.mod,
usbtest.mod, usbserial_pl2303.mod, usbserial_ftdi.mod, usbserial_common.mod, usbms.mod, usb_keyboard.mod, usb.mod, uhci.mod, ufs2.mod, ufs1.mod, udf.mod, true.mod, trig.mod,
time.mod, tga.mod, tftp.mod, testload.mod, test_blockarg.mod, test.mod, terminfo.mod, terminal.mod, tar.mod, squash4.mod, sleep.mod, sfs.mod, setpci.mod, setjmp.mod,
serial.mod, search_label.mod, search_fs_uuid.mod, search_fs_file.mod, search.mod, scsi.mod, romfs.mod, relocator.mod, reiserfs.mod, regexp.mod, reboot.mod, read.mod,
raid6rec.mod, raid5rec.mod, probe.mod, priority_queue.mod, png.mod, play.mod, pbkdf2.mod, pata.mod, password_pbkdf2.mod, password.mod, parttool.mod, part_sunpc.mod,
part_sun.mod, part_plan.mod, part_msdos.mod, part_gpt.mod, part_dvh.mod, part_bsd.mod, part_apple.mod, part_amiga.mod, part_acorn.mod, ohci.mod, odc.mod, ntfscomp.mod,
ntfs.mod, normal.mod, nilfs2.mod, newc.mod, net.mod, multiboot2.mod, multiboot.mod, msdospart.mod, mmap.mod, minix_be.mod, minix3_be.mod, minix3.mod, minix2_be.mod, minix2.mod,
minix.mod, minicmd.mod, memrw.mod, memdisk.mod, mdraid1x.mod, mdraid09_be.mod, mdraid09.mod, lzopio.mod, lvm.mod, luks.mod, lssal.mod, lspci.mod, lsmmap.mod, lsefisystab.mod,
lsefimmap.mod, lsacpi.mod, ls.mod, loopback.mod, loadenv.mod, loadbios.mod, linuxefi.mod, linux.mod, ldm.mod, keystatus.mod, keylayouts.mod, jpeg.mod, jfs.mod, iso9660.mod,
iorw.mod, http.mod, hfsplus.mod, hfs.mod, hexdump.mod, help.mod, hello.mod, hdparm.mod, hashsum.mod, halt.mod, gzio.mod, gptsync.mod, gfxterm.mod, gfxmenu.mod, gettext.mod,
geli.mod, gcry_whirlpool.mod, gcry_twofish.mod, gcry_tiger.mod, gcry_sha512.mod, gcry_sha256.mod, gcry_sha1.mod, gcry_serpent.mod, gcry_seed.mod, gcry_rmd160.mod,
gcry_rijndael.mod, gcry_rfc2268.mod, gcry_md5.mod, gcry_md4.mod, gcry_des.mod, gcry_crc.mod, gcry_cast5.mod, gcry_camellia.mod, gcry_blowfish.mod, gcry_arcfour.mod,
functional_test.mod, fshelp.mod, font.mod, fixvideo.mod, fat.mod, extcmd.mod, ext2.mod, exfctest.mod, exfat.mod, elf.mod, ehci.mod, efinet.mod, efi_uga.mod, efi_gop.mod,
echo.mod, dm_nv.mod, diskfilter.mod, datetime.mod, datehook.mod, date.mod, cs5536.mod, cryptodisk.mod, crypto.mod, crc64.mod, cpuid.mod, cpio_be.mod, cpio.mod, configfile.mod,
cmp.mod, chain.mod, cat.mod, bufio.mod, btrfs.mod, bsd.mod, boot.mod, blocklist.mod, bitmap_scale.mod, bitmap.mod, bfs.mod, backtrace.mod, ata.mod, at_keyboard.mod,
appleldr.mod, aout.mod, all_video.mod, ahci.mod, afs.mod, affs.mod, adler32.mod, acpi.mod
</pre>

In der Konfiguration können Module über den Befehl ''insmod'' geladen werden. Ein Beispiel für die [[#Die Kommandozeile|Kommandozeile]]:
<pre>
insmod mdraid1x
</pre>

==Boot Password setzen==
Diese Funktionalität ist sinnvoll geworden, weil durch die [[#Erweiterte Funktionalitäten|erheblich ausgeweitete Funktionalität]] schon vor dem Start des OS potentiell Zugriff auf schützenswerte Daten erfolgen kann (möglicherweise auch über das Netzwerk) oder nicht gewünschte Systeme gebootet werden können. Es besteht auf diesem Wege die Möglichkeit, das Starten ausgewählter Systeme oder anderer Eigenschaften von ''GRUB2'' nur bestimmten Usern zu ermöglichen. Hierzu ist ein Authentifizierungsmechanismus und ein simples Usermangagement vorgesehen.

Hinweis: Die hier vorgestellten Mechanismen bieten keinen wirksamen Schutz vor Angreifern, welche '''physischen Zugang''' zu einem System haben sowie über ausreichend Zeit, Gelegenheit und über das notwendige KnowHow verfügen. Sollte der Angriff dem Datenbestand gelten, dann könnten die Festplatte auch ausgebaut und in einem anderen Computer eingelesen werden. Gegen solche Angriffe hilft nur eine ausreichende physikalische Sicherung und/oder eine Verschlüsselung der Daten mit ausgereiften kryptographischen Verfahren wie beispielsweise [[dm-crypt]].
Auch sollte erwähnt werden, dass hierdurch naturgemäß die Administration erschwert wird, insbesondere im Fall, dass ein System aus irgendwelchen Gründen gar nicht mehr bootet und repariert werden muss.

Gleichwohl kann das hier beschriebene Verfahren sehr wohl in bestimmten Kontexten zu einem höheren Maß an Sicherheit führen. Oftmals geht es in der IT-Sicherheit auch 'nur' darum, Hürden aufzubauen um schwächere Angriffsszenarien abdecken zu können oder Kombinationen von Sicherheitslücken zu entschärfen. So kann es durchaus sinnvoll sein, das Booten von externen Medien (USB-Stick, Netzwerk...) in Kombination mit entsprechenden Einträgen im [[BIOS]] einem Administrator vor zu behalten oder bestimmte installierte Betriebssysteme auf ausgewählte User einzugrenzen.
Einige Anwendungsfälle wurden beispielsweise [http://www.linux-club.de/viewtopic.php?f=90&t=118585 hier] diskutiert.

===Authentifizierung===
Es besteht die Möglichkeit, die Passwörter in Klartext in der Konfiguration zu hinterlegen. Viel sicherer ist es aber, anstatt von Klarttext-Passworten einen kryptographisch gesicherten [https://de.wikipedia.org/wiki/Kryptologische_Hashfunktion Passwort-Hash] zu verwenden, welcher mit einem angemessenen [https://de.wikipedia.org/wiki/Salt_%28Kryptologie%29 Salt] versehen ist (um Angriffen mit [https://de.wikipedia.org/wiki/Rainbow_Table Rainbow-Tables] abwehren zu können).

Hierzu wird das Kommando 'grub2-mkpasswd-pbkdf2' verwendet. Es generiert einen Password-Hash, welcher an den geeigneten Stellen eingetragen werden kann.

Aufruf für Password '123':
<pre>
# grub2-mkpasswd-pbkdf2
Enter password:
Reenter password:
PBKDF2 hash of your password is grub.pbkdf2.sha512.10000.DD2DF79436A5F2CA4F7363030C6C1555A7263BD692A61AAAE2847EDEF9D12B25EBBD0791EA875CBD1726D90DE9E99644BC4A630637D615AA42C06C19C26A6DC8.C68EC9D01A2DFCBEB2B36FDF6836290E8DB6F50B2BD85932AF7E6BEC8E4AC9A5BB4F027EF906AFD97FC2DC2A38745F5CA63DCC1E05049DC3CA12DC5336647249
</pre>
Folgende Aufrufe mit dem selben Password rufen immer andere Hashes hervor, was auf das Salting zurückzuführen ist.

Weitere Optionen:
<pre>
# grub2-mkpasswd-pbkdf2 -?
Usage: grub2-mkpasswd-pbkdf2 [OPTION...] [OPTIONS]
Generate PBKDF2 password hash.

-c, --iteration-count=NUM Number of PBKDF2 iterations
-l, --buflen=NUM Length of generated hash
-s, --salt=NUM Length of salt
-?, --help give this help list
--usage give a short usage message
-V, --version print program version

Mandatory or optional arguments to long options are also mandatory or optional
for any corresponding short options.
</pre>

Siehe auch: [https://de.wikipedia.org/wiki/PBKDF2 PBKDF2 (Wikipedia)]

===Authorisierung===
Zu erst wird die Liste der User definiert, welchen root-Zugriff zugebilligt werden soll. In diesem Beispiel einfach nur der User 'root':
<pre>
set superusers="root"
</pre>
Wenn diese Umgebungsvariable gesetzt ist, wird der Zugang zur [[#Kommandozeile|Kommandozeile]] nur den entsprechenden Usern erlaubt.

Als nächstes wird das Password mit den vorher generierten Password-Hashes den Usern zugeordnet:
<pre>
password_pbkdf2 root grub.pbkdf2.sha512.10000.DD2DF79436A5F2CA4F7363030C6C1555A7263BD692A61AAAE2847EDEF9D12B25EBBD0791EA875CBD1726D90DE9E99644BC4A630637D615AA42C06C19C26A6DC8.C68EC9D01A2DFCBEB2B36FDF6836290E8DB6F50B2BD85932AF7E6BEC8E4AC9A5BB4F027EF906AFD97FC2DC2A38745F5CA63DCC1E05049DC3CA12DC5336647249
password_pbkdf2 user1 grub.pbkdf2.sha512.10000.C3FFA2E95A6F933C562CFEFAFF86EE4BBE50FA20BD0575080C364D7EB37DE9CA6D7BDC58DB853EF00ECEB97376B1B7F50E051853A7DDBD917F201D58617397C1.6E29B095569E5BABD4380C47B61210F63D6F9156DA6D43C8D5F8AEAC88C7146C6C58A373C3CF4326D4B9F9CD50DDE4D890A0BDFC3E69EF5B42D5B2C09CA8086E
</pre>

Anwendugsbeispiele:

''Windows XP'' wird als unsicher eingestuft und sollte - wenn überhaupt - nicht in unsicheren Netzen eingesetzt werden. Um das sicherzustellen, wird dieses Recht nur dem besonders vertrauenswürdigen User 'user1' (oder implizit 'root') zugestanden:
<pre>
menuentry 'Windows XP (Achtung: kein Support mehr - unsicher)' --users user1 [...]
</pre>

Dieser Eintrag kann aufgrund des Parameters ''unrestricted'' von allen Benutzern gestartet werden:
<pre>
menuentry 'openSUSE 12.3, with Linux 3.7.10-1.11-desktop' --unrestricted [...]
</pre>
Ausgrenzung aller User, nur 'root' darf das Starten:
<pre>
menuentry 'openSUSE 12.3, with Linux 3.7.10-1.11-desktop (recovery mode)' --users '' [...]
</pre>

Falls weder der Parameter ''unrestricted'' noch ''users'' gesetzt ist, dann wird als User 'root' verwendet.

Hinweis: Derzeit gibt es noch keine Integration des Usermanagements in das [[#Buildsystem: /etc/grub.d|automatische Build]]. Die oben genannte Konfiguration muss also manuell in den Custom-Bereich eingetragen werden.

==Konfigurationsdatei: /boot/grub2/grub.cfg==
Dies ist die Hauptkonfigurationsdatei, welche wie oben beschrieben aber '''nicht manuell editiert''' werden sollte, weil sie vom [[#Buildsystem: /etc/grub.d|Buildsystem]] generiert wird! Es gibt System-Prozesse, welche genau das veranlassen, beispielsweise bei einem Kernelupdate. Manuelle Änderungen an dieser Datei würden spätestens da überschrieben.

Diese Datei wird beim eigentlichen Systemstart ausgewertet und bestimmt somit, welche Systeme zur Ausführung gelangen . Sie ersetzt die von [[GRUB Legacy]] bekannte Datei 'menu.lst'.

==Konfiguration neu generieren==
Um Konfigurationsänderungen zu aktivieren, muss abschließend das Kommando 'grub2-mkconfig' aufgerufen werden. Bei erfolgreicher Abarbeitung wird die [[#Konfigurationsdatei: /boot/grub2/grub.cfg|Hauptkonfigurationsdatei]] neu generiert:
<pre>
# grub2-mkconfig -o /boot/grub2/grub.cfg
Generating grub.cfg ...
Found theme: /boot/grub2/themes/openSUSE/theme.txt
Found linux image: /boot/vmlinuz-3.11.6-4-desktop
Found initrd image: /boot/initrd-3.11.6-4-desktop
Found linux image: /boot/vmlinuz-3.7.10-1.16-desktop
Found initrd image: /boot/initrd-3.7.10-1.16-desktop
Found openSUSE 12.3 (x86_64) on /dev/mapper/system-os2
done
</pre>
Im Falle von Syntax-Fehlern wird die Zieldatei nicht neu geschrieben. So wird sichergestellt ist, dass immer eine valide Konfiguration für den Systemstart vorliegt.

==Abhängigkeit zum Patch-Prozess==
Die Einträge ''initrd'' und ''linux'' in dieser Konfiguration unterliegen einer gewissen Dynamik. Es gibt eine Abhängigkeit zwischen den im Verzeichnis /boot liegenden Image-Dateien und der Konfiguration. So gibt es Anwendungsfälle, in welchen im Rahmen eines Systemupdates (Patch-Prozess) diese Images neu generiert werden (beispielsweise die ''initrd'' neu geschrieben wird). Um den Code des geänderten oder neuen Images auch nutzen zu können, wird vom Update-Prozess explizit auch die GRUB-Konfiguration neu generiert.

=Grundsätzliche Boot-Methoden=
''GRUB 2'' kennt zwei grundsätzliche Methoden, Betriebssysteme zu booten:
#Direktes Booten: Bei Betriebssystemen nach 'Multiboot Specification' wird diese Methode verwendet. Das sind hauptsächlich [[Open Source]]-Systeme.
#Chain Loading: Wird hauptsächlich bei nicht freien Betriebssystemen angewendet, für die es keinen nativen Support gibt.

==Direktes Booten (Multiboot Specification)==
Es gibt eine Spezifikation namens 'Multiboot', welche einen sauberen Multi-Boot-Betrieb zwischen unterschiedlichen Betriebssystemen zum Inhalt hat. Auf diesem Wege ist direkte Ansteuerung der installierten Systeme durch einen einzigen BootManager möglich.

Betriebssysteme mit Multiboot-Support: GNU/Linux, FreeBSD, NetBSD, OpenBSD, ...

Siehe: [http://www.gnu.org/software/grub/manual/multiboot/html_node/index.html Multiboot Specification (GNU)]

==Chain Loading==
Bei nicht quelloffenen Betriebssystemen gibt es fast immer keinen Support für direktes Booten. An diesen Stellen wird 'chain loading' verwendet, wobei hier der vorgeschaltete Boatloader (GRUB2) den Staffelstab an den nachgeschalteten (z.B. Windows) weitergibt:
<pre>
menuentry "Windows" {
insmod chain
insmod ntfs
set root=(hd0,1)
chainloader +1
}
</pre>

=Anwendungsfälle=
An dieser Stelle sollen Anleitungen zu ausgesuchten Anwendungsfällen im Zusammenhang mit ''GRUB 2'' aufgezeigt werden:
*[[Standardeintrag Bootmenü ändern (GRUB2)]]
*[[Umgang mit redundanten Laufwerken (GRUB2)]]
*[[Start von ISO-Image auf der Festplatte (GRUB2)]]
*[[Bootloader wiederherstellen]]

=Links=
*[http://www.gnu.org/software/grub/manual/html_node/index.html#SEC_Contents GRUB Documentation (GNU)] {{englisch}}
*[http://doc.opensuse.org/documentation/html/openSUSE_122/opensuse-reference/grub2.html The Boot Loader GRUB2 (doc.opensuse.org)] {{englisch}}
*[http://en.wikipedia.org/wiki/Grub2 GNU GRUB (Wikipedia)] {{englisch}}
*[https://help.ubuntu.com/community/Grub2 Grub2 (Ubuntu Documentation)] {{englisch}}
*[[GRUB]]
*[[GRUB Legacy]]

[[Kategorie:Bootmanager]] [[Kategorie:Security]]

GRUB 2

2015-11-18T09:29:04Z

Gehrke: /* Der Editor */

{{Lückenhaft|Im aktuellen Zustand beschreibt dieser Artikel ausschließlich Systeme mit herkömmlichen [[BIOS]], aber nicht die zunehmend weiter verbreiteten [[UEFI]]-Systeme. Diese Technologie und ihre Implikationen auf GRUB2 sollte in zukünftigen Versionen das Artikels berücksichtigt werden.}}

GNU GRUB (GRand Unified Bootloader)

=Abgrenzung zu 'GRUB Legacy'=
''GRUB 2'' ist eine vollständige Neuentwicklung des Vorgängers [[GRUB Legacy]]. Seit 2009 wird es in größeren Distributionen als Standard eingeführt, [[OpenSUSE]] beispielsweise vollführte diesen Schritt mit Release 12.2 im Herbst 2012.

Um eine Reihe neuer Funktionalitäten anbieten zu können, haben sich die Entwickler für eine radikale Neu-Implementierung entschieden. Es gibt dementsprechend bis auf den Namen kaum Gemeinsamkeiten und bewusst wurde auf '''Kompatibilität zum Vorgänger verzichtet'''.

Die aktuelle Version kann beispielsweise so abgefragt werden:
<pre>
# rpm -qv grub2
grub2-2.00-39.1.3.x86_64

# grub2-install -v
grub2-install (GRUB2) 2.00
</pre>

==Erweiterte Funktionalitäten==
*Script-gesteuerte, dynamischere Konfiguration
*Unterstützung von mehr [[Dateisystem]]en wie beispielsweise [[ext4]], HFS+, [[NTFS]] ([http://www.gnu.org/software/grub/manual/html_node/Internationalisation.html#Filesystems vollständige Liste])
*Direkter Zugriff auf [[LVM]] und [[RAID]]-Devices möglich
*Steuerung über ein graphisches Terminal (besonders ''Rescue Mode'') und graphisches Menüsystem gegeben
*Mehrsprachigkeit inklusive der Einträge
*Zusätzliche Unterstützung für weitere Systemsoftware neben PC [[BIOS]]: [[UEFI|PC EFI]], PC coreboot, PowerPC, SPARC, MIPS Lemote Yeeloong
*Support für Boot via Netzwerk über [[tftp]] (PXE)
*Zugriff über serielle Konsole möglich (vor allem Embedded Devices)
*Boot Password möglich
*Start von LiveCD ISO-Images direkt von der Festplatte möglich
*Unterstützung von weiteren Plattformen neben x86 (z.B. PowerPC)
*Einführung eines Modells zur Erzeugung von angepassten Layouts (Themes)

==Unterschiede zu 'GRUB Legacy'==
An dieser Stelle werden die Unterschiede zu [[GRUB Legacy]] hervorgehoben:
*In ''Grub 2'' existiert die stufenweise Reihenfolge in den Einzelphasen ('Stage 1', 'Stage 1.5', 'Stage 2') nicht mehr.
*In der Konfiguration werden Partitionen ebenfalls über Zahlen adressiert, aber die Nummerierung beginnt mit 1 (und nicht 0).
:*Hinweis: Das gilt aber nur für Partitionen, nicht für Festplatten. Festplatten werden mit 'hdX' benannt und X beginnt bei 0!
*Die Konfiguration wurde komplett umgestellt. Wo früher eine einzelne Datei (menu.lst) zu editieren war, gibt es heute ein komplettes Konfigurationssystem aus vielen Dateien mit eigener Struktur und eigenem Build-System, welches die eigentlichen Konfigurationsdateien generiert (s. [[#Konfiguration]]).

=Installation=
{{Lückenhaft|Im aktuellen Zustand beschreibt dieser Artikel ausschließlich Systeme, welche das [[MBR]]-Partitionierungsschema verwenden. Andere Schemata wie beispielsweise [[GPT]] werden hier derzeit nicht behandelt. Da GPT-Partitionierung zunehmend an Verbreitung gewinnt, sollte dies in zukünftigen Versionen das Artikels berücksichtigt werden.}}

Analog zum Vorgänger wird zur Installation des Boot-Sektors das Script 'grub2-install' verwendet. Als Parameter wird das Ziel-Device angegeben (im Beispiel der [[MBR]] der ersten Festplatten 'sda'):
<pre>
# grub2-install /dev/sda
Installation finished. No error reported.
</pre>
Alternativ können auch Partitionen ausgewählt werden.

Unter [[OpenSUSE]] ist alternativ zu verwenden:
*yast2 bootloader

{{Box Achtung||Dieser Schritt überschreibt möglicherweise [[Bootmanager]] anderer Systeme!}}

=Konfiguration=

==Boot-Einträge manuell ändern==
Manchmal will oder kann man nicht das komplette Setup von GRUB persistent ändern. Wenn das System beispielsweise infolge von Konfigurationsfehlern gar nicht mehr bootet oder der komplette Konfigurationszyklus zu lange dauert oder schlicht etwas ausprobiert werden soll, dann macht es Sinn, die Einträge vor dem Start manuell zu editieren.

Dies kann erreicht werden durch Drücken von 'E' während der Anzeige des Boot-Menüs. Die zu diesem Zeitpunkt selektierte Zeile wird dann in einen kleinen Editor geladen und kann dort überarbeitet werden. Mit der Tastenkombination <Strg>-<X> wird der geänderte Eintrag dann gestartet.

Die auf diesem Wege durchgeführten Änderungen sind nicht persistent.

==Die Kommandozeile==
''GRUB2'' verfügt über eine eingebaute Shell, welche unter anderem TAB-Completion beherrscht. Diese kann entweder direkt angesteuert werden oder wird angezeigt, wenn es Probleme mit einer invaliden Konfiguration gibt.

Hier können die selben Befehle verwendet werden, die in der Konfiguration möglich sind. Damit können beispielsweise im ''Rescue Mode'' beliebige Systeme manuell gestartet werden.

==Der Editor==
''GRUB2'' verfügt auch über einen eingebauten Editor. Dieser erlaubt es, einen ausgewählten Boot-Eintrag zu verändern. Dies kann sehr nützlich sein in Situationen, in denen die aktuelle Konfiguration nicht zu einem sauber gebooteten System führt - beispielsweise bei einem defekten Grafikkartentreiber infolge eines missglückten Updates.

In solchen Fällen ist es manchmal hilfreich, beim Start bestimmte Kernel-Paramter mitzugeben oder den Runlevel zu verändern.

Dieser Editor wird aufgerufen, indem in der Anzeigephase von GRUB2 ein Eintrag ausgewählt wird und dann die Taste 'E' gedrückt wird. Daraufhin wird genau dieser betreffende Eintrag aus der aktuellen Datei ''grub.cfg'' in einen Editor geladen und kann dort verändert werden. Für die Steuerung des Editors gibt es eine Handvoll Tastenkürzel, welche unter dem Editor kurz aufgeführt werden. Mit 'ESC' verwirft man die Änderungen und kommt zur Auswahl zurück, mit 'Ctrl-X' oder 'F10' bootet man das System mit den editierten Parametern.

Die Änderungen sind einmalig und werden nicht persistiert!

==YaST: boot loader==
[[OpenSUSE]]-typisch kann man einige Einstellungen auch in der Systemverwaltung [[YaST]] unter ''System / boot loader'' vornehmen.

==Default-Konfiguration: /etc/default/grub==
Globale Grundeinstellungen (Timeout, Standard-Eintrag, Layout...) werden hier definiert.

==/etc/sysconfig/bootloader==
Diese Datei enthält Konfigurationsoptionen, welche von der ''perl-bootloader library'' verwendet werden. Dies passiert dann, wenn eine Konfiguration über [[YaST]] durchgeführt wird oder ein neuer [[Kernel]] installiert wird.

Diese Datei ist [[openSUSE]]-spezifisch. Die Optionen hier werden auch nicht ausschließlich für ''GRUB 2'' verwendet, sondern auch bei anderen supporteten [[Bootmanager]]n.

==Buildsystem: /etc/grub.d==
Das Buildsystem ist eine Sammlung von Scripten. Ein Nummernpräfix sorgt für eine Abfolge in definierter Reihenfolge (bei '00' beginnend):
<pre>
# ls -l /etc/grub.d
-rwxr-xr-x 1 root root 7649 Jul 31 11:48 00_header
-rwxr-xr-x 1 root root 10535 Jul 31 11:48 10_linux
-rwxr-xr-x 1 root root 11019 Jul 31 11:48 20_linux_xen
-rwxr-xr-x 1 root root 1802 Jul 31 11:49 20_memtest86+
-rwxr-xr-x 1 root root 2596 Jul 31 11:48 20_ppc_terminfo
-rwxr-xr-x 1 root root 10132 Jul 31 11:48 30_os-prober
-rwxr-xr-x 1 root root 489 Jul 11 15:04 40_custom
-rwxr-xr-x 1 root root 216 Jul 31 11:48 41_custom
-rwxr-xr-x 1 root root 1259 Jul 31 11:49 90_persistent
-rw-r--r-- 1 root root 483 Jul 31 11:48 README
</pre>
Dieses Beispiel stammt aus einer [[OpenSUSE]]-Installation (Release 12.3). Andere Distribution liefern geringfügig andere Scripten aus. Es können diesem Schema entsprechend auch eigene Scripte hinzugefügt werden.

Bedeutung der Standard-Scripten:
*00_header: Initialisierung des Systems anhand der Einträge in /etc/default/grub ([[#Default-Konfiguration: /etc/default/grub|Default-Konfiguration]]).
*10_linux: Hier wird versucht, alle validen Kernel zu finden. Aus diesen wird dann das Bootmenü generiert.
*20_linux_xen: Für den Hypervisor [[Xen]] sind dedizierte Kernel notwendig. Hier wird die notwendige Parametrisierung hierfür durchgeführt.
*20_memtest86+: Aufnahme von [[memtest]] in das Bootmenü.
*20_ppc_terminfo: <ToDo: Funktionalität noch beschreiben>
*30_os-prober: Suche nach weiteren Bootladern sowie weiteren installierten Betriebssystemen. In einem Multi-Boot-Kontext werden hier Einträge beispielsweise für Windows oder parallele Linux-Installationen generiert.
*40_custom: Eigene Booteinträge können hier manuell hinterlegt werden. Dieses Script wird bei System-Updates nicht überschrieben.
*41_custom: Einbindung der Datei /boot/grub/custom.cfg
*90_persistent: Teile aus der aktuellen grub.cfg können hier rein kopiert werden. Dieser Inhalt wird bei einem erneuten Durchlauf des Build-Systems '''nicht''' überschrieben.

Siehe auch: [[#Konfiguration neu generieren]]

==Module laden==
''GRUB 2'' bietet direkten Zugriff auf bestimmte Ressourcen wie beispielsweise [[LVM]], [[RAID]] oder diverse [[Dateisysteme]]. Dieser Zugriff wird über Module implementiert, welche per 'insmod' bei Bedarf geladen werden können.

Unter [[OpenSUSE]] liegen diese Module (architekturabhängig) unter:
<pre>
# tree -d /usr/lib/grub2/
/usr/lib/grub2/
├── i386-pc
└── x86_64-efi
</pre>

Verfügbare Module (nur x86_64-efi):
<pre>
# ls -r --format=commas *.mod
zfsinfo.mod, zfscrypt.mod, zfs.mod, xzio.mod, xnu_uuid.mod, xnu.mod, xfs.mod, videotest.mod, videoinfo.mod, video_fb.mod, video_cirrus.mod, video_bochs.mod, video.mod,
usbtest.mod, usbserial_pl2303.mod, usbserial_ftdi.mod, usbserial_common.mod, usbms.mod, usb_keyboard.mod, usb.mod, uhci.mod, ufs2.mod, ufs1.mod, udf.mod, true.mod, trig.mod,
time.mod, tga.mod, tftp.mod, testload.mod, test_blockarg.mod, test.mod, terminfo.mod, terminal.mod, tar.mod, squash4.mod, sleep.mod, sfs.mod, setpci.mod, setjmp.mod,
serial.mod, search_label.mod, search_fs_uuid.mod, search_fs_file.mod, search.mod, scsi.mod, romfs.mod, relocator.mod, reiserfs.mod, regexp.mod, reboot.mod, read.mod,
raid6rec.mod, raid5rec.mod, probe.mod, priority_queue.mod, png.mod, play.mod, pbkdf2.mod, pata.mod, password_pbkdf2.mod, password.mod, parttool.mod, part_sunpc.mod,
part_sun.mod, part_plan.mod, part_msdos.mod, part_gpt.mod, part_dvh.mod, part_bsd.mod, part_apple.mod, part_amiga.mod, part_acorn.mod, ohci.mod, odc.mod, ntfscomp.mod,
ntfs.mod, normal.mod, nilfs2.mod, newc.mod, net.mod, multiboot2.mod, multiboot.mod, msdospart.mod, mmap.mod, minix_be.mod, minix3_be.mod, minix3.mod, minix2_be.mod, minix2.mod,
minix.mod, minicmd.mod, memrw.mod, memdisk.mod, mdraid1x.mod, mdraid09_be.mod, mdraid09.mod, lzopio.mod, lvm.mod, luks.mod, lssal.mod, lspci.mod, lsmmap.mod, lsefisystab.mod,
lsefimmap.mod, lsacpi.mod, ls.mod, loopback.mod, loadenv.mod, loadbios.mod, linuxefi.mod, linux.mod, ldm.mod, keystatus.mod, keylayouts.mod, jpeg.mod, jfs.mod, iso9660.mod,
iorw.mod, http.mod, hfsplus.mod, hfs.mod, hexdump.mod, help.mod, hello.mod, hdparm.mod, hashsum.mod, halt.mod, gzio.mod, gptsync.mod, gfxterm.mod, gfxmenu.mod, gettext.mod,
geli.mod, gcry_whirlpool.mod, gcry_twofish.mod, gcry_tiger.mod, gcry_sha512.mod, gcry_sha256.mod, gcry_sha1.mod, gcry_serpent.mod, gcry_seed.mod, gcry_rmd160.mod,
gcry_rijndael.mod, gcry_rfc2268.mod, gcry_md5.mod, gcry_md4.mod, gcry_des.mod, gcry_crc.mod, gcry_cast5.mod, gcry_camellia.mod, gcry_blowfish.mod, gcry_arcfour.mod,
functional_test.mod, fshelp.mod, font.mod, fixvideo.mod, fat.mod, extcmd.mod, ext2.mod, exfctest.mod, exfat.mod, elf.mod, ehci.mod, efinet.mod, efi_uga.mod, efi_gop.mod,
echo.mod, dm_nv.mod, diskfilter.mod, datetime.mod, datehook.mod, date.mod, cs5536.mod, cryptodisk.mod, crypto.mod, crc64.mod, cpuid.mod, cpio_be.mod, cpio.mod, configfile.mod,
cmp.mod, chain.mod, cat.mod, bufio.mod, btrfs.mod, bsd.mod, boot.mod, blocklist.mod, bitmap_scale.mod, bitmap.mod, bfs.mod, backtrace.mod, ata.mod, at_keyboard.mod,
appleldr.mod, aout.mod, all_video.mod, ahci.mod, afs.mod, affs.mod, adler32.mod, acpi.mod
</pre>

In der Konfiguration können Module über den Befehl ''insmod'' geladen werden. Ein Beispiel für die [[#Die Kommandozeile|Kommandozeile]]:
<pre>
insmod mdraid1x
</pre>

==Boot Password setzen==
Diese Funktionalität ist sinnvoll geworden, weil durch die [[#Erweiterte Funktionalitäten|erheblich ausgeweitete Funktionalität]] schon vor dem Start des OS potentiell Zugriff auf schützenswerte Daten erfolgen kann (möglicherweise auch über das Netzwerk) oder nicht gewünschte Systeme gebootet werden können. Es besteht auf diesem Wege die Möglichkeit, das Starten ausgewählter Systeme oder anderer Eigenschaften von ''GRUB2'' nur bestimmten Usern zu ermöglichen. Hierzu ist ein Authentifizierungsmechanismus und ein simples Usermangagement vorgesehen.

Hinweis: Die hier vorgestellten Mechanismen bieten keinen wirksamen Schutz vor Angreifern, welche '''physischen Zugang''' zu einem System haben sowie über ausreichend Zeit, Gelegenheit und über das notwendige KnowHow verfügen. Sollte der Angriff dem Datenbestand gelten, dann könnten die Festplatte auch ausgebaut und in einem anderen Computer eingelesen werden. Gegen solche Angriffe hilft nur eine ausreichende physikalische Sicherung und/oder eine Verschlüsselung der Daten mit ausgereiften kryptographischen Verfahren wie beispielsweise [[dm-crypt]].
Auch sollte erwähnt werden, dass hierdurch naturgemäß die Administration erschwert wird, insbesondere im Fall, dass ein System aus irgendwelchen Gründen gar nicht mehr bootet und repariert werden muss.

Gleichwohl kann das hier beschriebene Verfahren sehr wohl in bestimmten Kontexten zu einem höheren Maß an Sicherheit führen. Oftmals geht es in der IT-Sicherheit auch 'nur' darum, Hürden aufzubauen um schwächere Angriffsszenarien abdecken zu können oder Kombinationen von Sicherheitslücken zu entschärfen. So kann es durchaus sinnvoll sein, das Booten von externen Medien (USB-Stick, Netzwerk...) in Kombination mit entsprechenden Einträgen im [[BIOS]] einem Administrator vor zu behalten oder bestimmte installierte Betriebssysteme auf ausgewählte User einzugrenzen.
Einige Anwendungsfälle wurden beispielsweise [http://www.linux-club.de/viewtopic.php?f=90&t=118585 hier] diskutiert.

===Authentifizierung===
Es besteht die Möglichkeit, die Passwörter in Klartext in der Konfiguration zu hinterlegen. Viel sicherer ist es aber, anstatt von Klarttext-Passworten einen kryptographisch gesicherten [https://de.wikipedia.org/wiki/Kryptologische_Hashfunktion Passwort-Hash] zu verwenden, welcher mit einem angemessenen [https://de.wikipedia.org/wiki/Salt_%28Kryptologie%29 Salt] versehen ist (um Angriffen mit [https://de.wikipedia.org/wiki/Rainbow_Table Rainbow-Tables] abwehren zu können).

Hierzu wird das Kommando 'grub2-mkpasswd-pbkdf2' verwendet. Es generiert einen Password-Hash, welcher an den geeigneten Stellen eingetragen werden kann.

Aufruf für Password '123':
<pre>
# grub2-mkpasswd-pbkdf2
Enter password:
Reenter password:
PBKDF2 hash of your password is grub.pbkdf2.sha512.10000.DD2DF79436A5F2CA4F7363030C6C1555A7263BD692A61AAAE2847EDEF9D12B25EBBD0791EA875CBD1726D90DE9E99644BC4A630637D615AA42C06C19C26A6DC8.C68EC9D01A2DFCBEB2B36FDF6836290E8DB6F50B2BD85932AF7E6BEC8E4AC9A5BB4F027EF906AFD97FC2DC2A38745F5CA63DCC1E05049DC3CA12DC5336647249
</pre>
Folgende Aufrufe mit dem selben Password rufen immer andere Hashes hervor, was auf das Salting zurückzuführen ist.

Weitere Optionen:
<pre>
# grub2-mkpasswd-pbkdf2 -?
Usage: grub2-mkpasswd-pbkdf2 [OPTION...] [OPTIONS]
Generate PBKDF2 password hash.

-c, --iteration-count=NUM Number of PBKDF2 iterations
-l, --buflen=NUM Length of generated hash
-s, --salt=NUM Length of salt
-?, --help give this help list
--usage give a short usage message
-V, --version print program version

Mandatory or optional arguments to long options are also mandatory or optional
for any corresponding short options.
</pre>

Siehe auch: [https://de.wikipedia.org/wiki/PBKDF2 PBKDF2 (Wikipedia)]

===Authorisierung===
Zu erst wird die Liste der User definiert, welchen root-Zugriff zugebilligt werden soll. In diesem Beispiel einfach nur der User 'root':
<pre>
set superusers="root"
</pre>
Wenn diese Umgebungsvariable gesetzt ist, wird der Zugang zur [[#Kommandozeile|Kommandozeile]] nur den entsprechenden Usern erlaubt.

Als nächstes wird das Password mit den vorher generierten Password-Hashes den Usern zugeordnet:
<pre>
password_pbkdf2 root grub.pbkdf2.sha512.10000.DD2DF79436A5F2CA4F7363030C6C1555A7263BD692A61AAAE2847EDEF9D12B25EBBD0791EA875CBD1726D90DE9E99644BC4A630637D615AA42C06C19C26A6DC8.C68EC9D01A2DFCBEB2B36FDF6836290E8DB6F50B2BD85932AF7E6BEC8E4AC9A5BB4F027EF906AFD97FC2DC2A38745F5CA63DCC1E05049DC3CA12DC5336647249
password_pbkdf2 user1 grub.pbkdf2.sha512.10000.C3FFA2E95A6F933C562CFEFAFF86EE4BBE50FA20BD0575080C364D7EB37DE9CA6D7BDC58DB853EF00ECEB97376B1B7F50E051853A7DDBD917F201D58617397C1.6E29B095569E5BABD4380C47B61210F63D6F9156DA6D43C8D5F8AEAC88C7146C6C58A373C3CF4326D4B9F9CD50DDE4D890A0BDFC3E69EF5B42D5B2C09CA8086E
</pre>

Anwendugsbeispiele:

''Windows XP'' wird als unsicher eingestuft und sollte - wenn überhaupt - nicht in unsicheren Netzen eingesetzt werden. Um das sicherzustellen, wird dieses Recht nur dem besonders vertrauenswürdigen User 'user1' (oder implizit 'root') zugestanden:
<pre>
menuentry 'Windows XP (Achtung: kein Support mehr - unsicher)' --users user1 [...]
</pre>

Dieser Eintrag kann aufgrund des Parameters ''unrestricted'' von allen Benutzern gestartet werden:
<pre>
menuentry 'openSUSE 12.3, with Linux 3.7.10-1.11-desktop' --unrestricted [...]
</pre>
Ausgrenzung aller User, nur 'root' darf das Starten:
<pre>
menuentry 'openSUSE 12.3, with Linux 3.7.10-1.11-desktop (recovery mode)' --users '' [...]
</pre>

Falls weder der Parameter ''unrestricted'' noch ''users'' gesetzt ist, dann wird als User 'root' verwendet.

Hinweis: Derzeit gibt es noch keine Integration des Usermanagements in das [[#Buildsystem: /etc/grub.d|automatische Build]]. Die oben genannte Konfiguration muss also manuell in den Custom-Bereich eingetragen werden.

==Konfigurationsdatei: /boot/grub2/grub.cfg==
Dies ist die Hauptkonfigurationsdatei, welche wie oben beschrieben aber '''nicht manuell editiert''' werden sollte, weil sie vom [[#Buildsystem: /etc/grub.d|Buildsystem]] generiert wird! Es gibt System-Prozesse, welche genau das veranlassen, beispielsweise bei einem Kernelupdate. Manuelle Änderungen an dieser Datei würden spätestens da überschrieben.

Diese Datei wird beim eigentlichen Systemstart ausgewertet und bestimmt somit, welche Systeme zur Ausführung gelangen . Sie ersetzt die von [[GRUB Legacy]] bekannte Datei 'menu.lst'.

==Konfiguration neu generieren==
Um Konfigurationsänderungen zu aktivieren, muss abschließend das Kommando 'grub2-mkconfig' aufgerufen werden. Bei erfolgreicher Abarbeitung wird die [[#Konfigurationsdatei: /boot/grub2/grub.cfg|Hauptkonfigurationsdatei]] neu generiert:
<pre>
# grub2-mkconfig -o /boot/grub2/grub.cfg
Generating grub.cfg ...
Found theme: /boot/grub2/themes/openSUSE/theme.txt
Found linux image: /boot/vmlinuz-3.11.6-4-desktop
Found initrd image: /boot/initrd-3.11.6-4-desktop
Found linux image: /boot/vmlinuz-3.7.10-1.16-desktop
Found initrd image: /boot/initrd-3.7.10-1.16-desktop
Found openSUSE 12.3 (x86_64) on /dev/mapper/system-os2
done
</pre>
Im Falle von Syntax-Fehlern wird die Zieldatei nicht neu geschrieben. So wird sichergestellt ist, dass immer eine valide Konfiguration für den Systemstart vorliegt.

==Abhängigkeit zum Patch-Prozess==
Die Einträge ''initrd'' und ''linux'' in dieser Konfiguration unterliegen einer gewissen Dynamik. Es gibt eine Abhängigkeit zwischen den im Verzeichnis /boot liegenden Image-Dateien und der Konfiguration. So gibt es Anwendungsfälle, in welchen im Rahmen eines Systemupdates (Patch-Prozess) diese Images neu generiert werden (beispielsweise die ''initrd'' neu geschrieben wird). Um den Code des geänderten oder neuen Images auch nutzen zu können, wird vom Update-Prozess explizit auch die GRUB-Konfiguration neu generiert.

=Grundsätzliche Boot-Methoden=
''GRUB 2'' kennt zwei grundsätzliche Methoden, Betriebssysteme zu booten:
#Direktes Booten: Bei Betriebssystemen nach 'Multiboot Specification' wird diese Methode verwendet. Das sind hauptsächlich [[Open Source]]-Systeme.
#Chain Loading: Wird hauptsächlich bei nicht freien Betriebssystemen angewendet, für die es keinen nativen Support gibt.

==Direktes Booten (Multiboot Specification)==
Es gibt eine Spezifikation namens 'Multiboot', welche einen sauberen Multi-Boot-Betrieb zwischen unterschiedlichen Betriebssystemen zum Inhalt hat. Auf diesem Wege ist direkte Ansteuerung der installierten Systeme durch einen einzigen BootManager möglich.

Betriebssysteme mit Multiboot-Support: GNU/Linux, FreeBSD, NetBSD, OpenBSD, ...

Siehe: [http://www.gnu.org/software/grub/manual/multiboot/html_node/index.html Multiboot Specification (GNU)]

==Chain Loading==
Bei nicht quelloffenen Betriebssystemen gibt es fast immer keinen Support für direktes Booten. An diesen Stellen wird 'chain loading' verwendet, wobei hier der vorgeschaltete Boatloader (GRUB2) den Staffelstab an den nachgeschalteten (z.B. Windows) weitergibt:
<pre>
menuentry "Windows" {
insmod chain
insmod ntfs
set root=(hd0,1)
chainloader +1
}
</pre>

=Anwendungsfälle=
An dieser Stelle sollen Anleitungen zu ausgesuchten Anwendungsfällen im Zusammenhang mit ''GRUB 2'' aufgezeigt werden:
*[[Standardeintrag Bootmenü ändern (GRUB2)]]
*[[Umgang mit redundanten Laufwerken (GRUB2)]]
*[[Start von ISO-Image auf der Festplatte (GRUB2)]]
*[[Bootloader wiederherstellen]]

=Links=
*[http://www.gnu.org/software/grub/manual/html_node/index.html#SEC_Contents GRUB Documentation (GNU)] {{englisch}}
*[http://doc.opensuse.org/documentation/html/openSUSE_122/opensuse-reference/grub2.html The Boot Loader GRUB2 (doc.opensuse.org)] {{englisch}}
*[http://en.wikipedia.org/wiki/Grub2 GNU GRUB (Wikipedia)] {{englisch}}
*[https://help.ubuntu.com/community/Grub2 Grub2 (Ubuntu Documentation)] {{englisch}}
*[[GRUB]]
*[[GRUB Legacy]]

[[Kategorie:Bootmanager]] [[Kategorie:Security]]

Tipp: Profile Sync Daemon

2015-09-18T20:06:14Z

Gehrke: /* Vorwort */

{{Review|alles}}
=Vorwort=
Ich wollte euch hier schreiben, da ich bisher noch keine bzw. wenig gute Infos zu PSD zu [[openSUSE]] 13.2 gefunden habe, wie ich mir diesen nach meinem eigenen Geschmack für Firefox und Chromium eingerichtet habe. Den Performance-Gewinn der Webbrowser finde ich derart super, dass ich das auf meinem Desktop als auch auf meinem alten Notebook einsetze. Tutorials die ich fand, beschrieben keine Nutzung von overlayfs und waren auch nicht speziell auf openSUSE zielgerichtet. Das wollte ich dann alles zusammen - so weit es mir im Sinn liegt - ausbauen und anwenden. Wie folgt:
{{Hinweis|'''Bitte lasst euch von den Warnungen nicht abschrecken''''}}
{{Achtung|'''Bitte macht auch nochmal vorher eine SICHERUNG! (Browser PROFILE etc.). Bei falscher Handhabung können alle Lesezeichen und alle Einstellungen des Browser verloren gehen. Und ihr müsstet mit einem leeren neuen Profil beginnen.'''}}
{{Warnung|'''Das anwenden aller hier niedergeschriebenen Modifikationen geschieht auf eigene Gefahr. Ich übernehme keine Verantwortung für etwäige Probleme die durch die Verwendung dieser Tipps entstehen könnten!'''}}
{{Warnung|'''Es ist besonders Wichtig, dass alle Browser beendet werden, bevor PSD beendet oder gestartet wird. Ansonsten kann es zu Datenverlust beim Browserprofil führen.'''}}
==Das Paket besorgen==
'''Es gibt ein RPM im Buildservice:'''
(Es sei möglicherweise instabil). Ich kann davon nichts feststellen. Das läuft einfach wunderbar. Ich gehe davon aus, dass da jeder seine Möglichkeit dazu hat (hier ein Link):
*https://software.opensuse.org/package/profile-sync-daemon?search_term=profile+sync+daemon
'''Nach dem Download:'''
<pre style="background-color: #FFFFC0">rpm -Uhv profile-sync-daemon-5.73-6.1.noarch</pre>
{{Hinweis|Nach der Installation ist der Dienst PSD zunächst deaktiviert und nicht funktionsfähig. Er muss noch durch einige Schritte konfiguriert werden. Im Anschluss kann er gestartet werden.}}

==Overlayfs==
{{Hinweis|'''Damit das Browserprofil komprimiert im RAM abgelegt wird, Verwendet PSD ein Kernel-Modul namens "overlayfs".'''}}
*'''Vorab laden'''
Damit es gleich ohne den Computer neu zu starten für das Howto direkt verwendet werden kann, muss folgender Befehl abgesetzt werden:
<pre style="background-color: #FFFFC0">modprobe overlayfs</pre>
*'''Prüfen:''' (ob es erfolgreich geladen wurde):
<pre style="background-color: #FFFFC0">lsmod | grep overlayfs</pre>
<blockquote><pre style="background-color: #D4FFEF">overlayfs 32012 2</pre></blockquote>
{{Achtung|'''Wenn das Modul overlayfs nicht geladen werden kann, müsste in der Konfiguration darauf verzichtet werden.'''}}
*'''Einrichten, dass es bei jedem reboot geladen wird:'''
Damit das Modul 'overlayfs' beim nächsten Systemstart automatisch geladen wird, muss dem Kernel Bescheid gesagt werden. Das passiert mithilfe einer eigens dafür angelegten Datei.
*'''Datei erstellen:'''
<pre style="background-color: #FFFFC0">touch /etc/modules-load.d/MODULES_LOADED_ON_BOOT.conf</pre>
*'''Inhalt einfügen:'''
<pre style="background-color: #FFFFC0">echo "overlayfs" > /etc/modules-load.d/MODULES_LOADED_ON_BOOT.conf</pre>
{{Hinweis|'''Jetzt ist das Kernelmodul geladen und wird auch beim nächsten Start automatisch geladen.'''}}

==Die Konfigurationsdatei==
Da PSD zunächst nicht konfiguriert ist. Und wir bisher nur overlayfs vorbereitet haben, muss noch die Konfigurationsdatei angepasst werden bevor wir mit dem Start beginnen. Diese Datei findet ihr in folgendem Pfad:
<blockquote><pre style="background-color: #D4FFEF">/etc/psd.conf</pre></blockquote>
Hier müssen entsprechende werte ggf. unkommentiert werden. Bitte beschäftigt euch auch selbst nochmal mit der Datei. Über jedem der entsprechenden Werte stehen Warnungen und gute Kommentare. Deswegen nenne ich hier nur kurz die wichtigsten Optionen.
'''Vorgeschlagene Anpassungen:'''
<pre>
# WICHTIG! Hier Muss der Benutzer eingetragen werden,
# für den PSD aktiviert wird. Also der Anmeldename.
USERS=

# Die Komprimierung nutzen. (Hierfür wurde das Modul bereits geladen).
USE_OVERLAYFS="yes"

# Backups bringen Gummipluspunkte:
USE_BACKUPS="yes"

# Pfad zum RAM-Laufwerk:
VOLATILE="/tmp"
</pre>
{{Hinweis|'''Bitte überarbeitet eure Konfigurationsdatei weitestgehend selbständig.''' Wer sich unsicher ist, kann einfach nur oben benannte Werte eintragen und ansonsten die voreingestellten belassen.}}
'''Hier noch einige Anmerkungen:'''
<blockquote>
*'''Zu der Einstellung für die Browser:'''
Wenn in den Zeilen mit den Browsern keine Einstellung gemacht wird, werden installierte und unterstützte Browser wie Firefox und Chromium bzw. die aufgeführten auskommentierten selbständig erkannt. An der Stelle ist deshalb kein Eingriff notwendig.
*'''Zu der Einstellung für das RAM-Laufwerk:'''
Das Verzeichnis "/tmp" wird von systemd von Haus aus als tmpfs (So etwas wie ein RAM Laufwerk.) geladen. Das passiert mithilfe des Unit:
<blockquote><pre style="background-color: #D4FFEF">/usr/lib/systemd/system/tmp.mount</pre></blockquote>
*'''Ob das Unit oder der Dienst läuft, prüfen mit:'''
<pre style="background-color: #FFFFC0">systemctl status tmp.mount</pre>
*'''Prüfen:''' (Ausgabe beinhaltet):
<blockquote><pre style="background-color: #D4FFEF">Active: active (mounted)</pre></blockquote>
</blockquote>
 

==PSD aktivieren mit Trockenlauf==
Weiter geht es mit einem Trockenlauf, was passieren würde wenn der Dienst aktiviert wird nachdem unsere Konfigurationsdatei zuvor eingerichtet wurde.
{{Hinweis|'''Wenn hier Fehler auftreten würden, müsste die Konfiguration und das Paket erneut überprüft, bzw. Hilfe gesucht werden.'''}}
*'''Trockenlauf:'''
<pre style="background-color: #FFFFC0">profile-sync-daemon parse</pre>
<blockquote><pre style="background-color: #D4FFEF">
tmpfs dir: /tmp/deinUSER-firefox-zufälligenummer.default
profile size: 47M
overlayfs size: 24M
recovery dirs: none
</pre></blockquote>
{{Achtung|'''Achte bitte darauf dass diese Ausgabe keine Fehler enthält!'''}}

==Aktivierung mit systemctl==
Wenn jetzt alles gepasst hat soweit, kann eingerichtet werden dass der Dienst automatisch startet. Im Anschluss daran kann er auch gleich das erste mal am Laufenden System aktiviert werden.
{{Warnung|'''Es ist besonders Wichtig, dass alle Browser beendet werden, bevor PSD beendet oder gestartet wird. Ansonsten kann es zu Datenverlust beim Browserprofil führen.'''}}
*'''Starten'''
<pre style="background-color: #FFFFC0">systemctl start psd.service</pre>
*'''Aktivieren (Autostart)'''
<pre style="background-color: #FFFFC0">systemctl enable psd.service</pre>
{{Hinweis|'''Damit ist der Dienst gestartet und wird automatisch aktiviert.'''}}
 

=Nachwort=
{{Hinweis|'''So läuft des Ding bei mir wunderbar. Ich wollte das weitergeben, und hoffe nichts wichtiges übersehen zu haben.'''}}
'''An dieser Stelle nochmal:'''
{{Achtung|'''Macht eine Sicherung und schaut genau was ihr tut.'''}}
 

=Quellen/Links:=
* https://wiki.archlinux.org/index.php/Profile-sync-daemon
* https://github.com/graysky2/profile-sync-daemon
---------
{| class="wikitable"
|-
|'''Navi:'''
|[[Mini_Tuning_guide_für_openSUSE_13.2|Zurück zum Guide]]
|-
|}
--------

[[Kategorie:HowTo]]

Tipp: Profile Sync Daemon

2015-09-18T19:53:48Z

Gehrke: Kategorie:HowTo

{{Review|alles}}
=Vorwort=
Ich wollte euch hier schreiben, da ich bisher noch keine bzw. wenig gute Infos zu PSD zu openSUSE 13.2 gefunden habe, wie ich mir diesen nach meinem eigenen Geschmack für Firefox und Chromium eingerichtet habe. Den Performance Gewinn der Webbrowser finde ich derart super, dass ich das auf meinem Desktop als auch auf meinem alten Notebook einsetze. Tutorials die ich fand beschrieben keine Nutzung von overlayfs und waren auch nicht speziell auf openSUSE zielgerichtet. Das wollte ich dann alles zusammen so weit es mir im Sinn liegt ausbauen und anwenden. Wie folgt:
{{Hinweis|'''Bitte lasst euch von den Warnungen nicht abschrecken''''}}
{{Achtung|'''Bitte macht auch nochmal vorher eine SICHERUNG! (Browser PROFILE etc.). Bei falscher Handhabung können alle Lesezeichen und alle Einstellungen des Browser verloren gehen. Und ihr müsstet mit einem leeren neuen Profil beginnen.'''}}
{{Warnung|'''Das anwenden aller hier niedergeschriebenen Modifikationen geschieht auf eigene Gefahr. Ich übernehme keine Verantwortung für etwäige Probleme die durch die Verwendung dieser Tipps entstehen könnten!'''}}
{{Warnung|'''Es ist besonders Wichtig, dass alle Browser beendet werden, bevor PSD beendet oder gestartet wird. Ansonsten kann es zu Datenverlust beim Browserprofil führen.'''}}
==Das Paket besorgen==
'''Es gibt ein RPM im Buildservice:'''
(Es sei möglicherweise instabil). Ich kann davon nichts feststellen. Das läuft einfach wunderbar. Ich gehe davon aus, dass da jeder seine Möglichkeit dazu hat (hier ein Link):
*https://software.opensuse.org/package/profile-sync-daemon?search_term=profile+sync+daemon
'''Nach dem Download:'''
<pre style="background-color: #FFFFC0">rpm -Uhv profile-sync-daemon-5.73-6.1.noarch</pre>
{{Hinweis|Nach der Installation ist der Dienst PSD zunächst deaktiviert und nicht funktionsfähig. Er muss noch durch einige Schritte konfiguriert werden. Im Anschluss kann er gestartet werden.}}

==Overlayfs==
{{Hinweis|'''Damit das Browserprofil komprimiert im RAM abgelegt wird Verwendet PSD ein Kernel-Modul namens "overlayfs".'''}}
*'''Vorab laden'''
Damit es gleich ohne den Computer neu zu starten für das Howto direkt verwendet werden kann muss folgender Befehl abgesetzt werden:
<pre style="background-color: #FFFFC0">modprobe overlayfs</pre>
*'''Prüfen:''' (ob es erfolgreich geladen wurde):
<pre style="background-color: #FFFFC0">lsmod | grep overlayfs</pre>
<blockquote><pre style="background-color: #D4FFEF">overlayfs 32012 2</pre></blockquote>
{{Achtung|'''Wenn das Modul overlayfs nicht geladen werden kann, müsste in der Konfiguration darauf verzichtet werden.'''}}
*'''Einrichten, dass es bei jedem reboot geladen wird:'''
Damit das Modul 'overlayfs' beim nächsten Systemstart automatisch geladen wird, muss dem Kernel Bescheid gesagt werden. Das passiert mithilfe einer eigens dafür angelegten Datei.
*'''Datei erstellen:'''
<pre style="background-color: #FFFFC0">touch /etc/modules-load.d/MODULES_LOADED_ON_BOOT.conf</pre>
*'''Inhalt einfügen:'''
<pre style="background-color: #FFFFC0">echo "overlayfs" > /etc/modules-load.d/MODULES_LOADED_ON_BOOT.conf</pre>
{{Hinweis|'''Jetzt ist das Kernelmodul geladen und wird auch beim nächsten Start automatisch geladen.'''}}

==Die Konfigurationsdatei==
Da PSD zunächst nicht konfiguriert ist. Und wir bisher nur overlayfs vorbereitet haben, muss noch die Konfigurationsdatei angepasst werden bevor wir mit dem Start beginnen. Diese Datei findet ihr in folgendem Pfad:
<blockquote><pre style="background-color: #D4FFEF">/etc/psd.conf</pre></blockquote>
Hier müssen entsprechende werte ggf. unkommentiert werden. Bitte beschäftigt euch auch selbst nochmal mit der Datei. Über jedem der entsprechenden Werte stehen Warnungen und gute Kommentare. Deswegen nenne ich hier nur kurz die wichtigsten Optionen.
'''Vorgeschlagene Anpassungen:'''
<pre>
# WICHTIG! Hier Muss der Benutzer eingetragen werden,
# für den PSD aktiviert wird. Also der Anmeldename.
USERS=

# Die Komprimierung nutzen. (Hierfür wurde das Modul bereits geladen).
USE_OVERLAYFS="yes"

# Backups bringen Gummipluspunkte:
USE_BACKUPS="yes"

# Pfad zum RAM-Laufwerk:
VOLATILE="/tmp"
</pre>
{{Hinweis|'''Bitte überarbeitet eure Konfigurationsdatei weitestgehend selbständig.''' Wer sich unsicher ist, kann einfach nur oben benannte Werte eintragen und ansonsten die voreingestellten belassen.}}
'''Hier noch einige Anmerkungen:'''
<blockquote>
*'''Zu der Einstellung für die Browser:'''
Wenn in den Zeilen mit den Browsern keine Einstellung gemacht wird, werden installierte und unterstützte Browser wie Firefox und Chromium bzw. die aufgeführten auskommentierten selbständig erkannt. An der Stelle ist deshalb kein Eingriff notwendig.
*'''Zu der Einstellung für das RAM-Laufwerk:'''
Das Verzeichnis "/tmp" wird von systemd von Haus aus als tmpfs (So etwas wie ein RAM Laufwerk.) geladen. Das passiert mithilfe des Unit:
<blockquote><pre style="background-color: #D4FFEF">/usr/lib/systemd/system/tmp.mount</pre></blockquote>
*'''Ob das Unit oder der Dienst läuft, prüfen mit:'''
<pre style="background-color: #FFFFC0">systemctl status tmp.mount</pre>
*'''Prüfen:''' (Ausgabe beinhaltet):
<blockquote><pre style="background-color: #D4FFEF">Active: active (mounted)</pre></blockquote>
</blockquote>
 

==PSD aktivieren mit Trockenlauf==
Weiter geht es mit einem Trockenlauf, was passieren würde wenn der Dienst aktiviert wird nachdem unsere Konfigurationsdatei zuvor eingerichtet wurde.
{{Hinweis|'''Wenn hier Fehler auftreten würden, müsste die Konfiguration und das Paket erneut überprüft, bzw. Hilfe gesucht werden.'''}}
*'''Trockenlauf:'''
<pre style="background-color: #FFFFC0">profile-sync-daemon parse</pre>
<blockquote><pre style="background-color: #D4FFEF">
tmpfs dir: /tmp/deinUSER-firefox-zufälligenummer.default
profile size: 47M
overlayfs size: 24M
recovery dirs: none
</pre></blockquote>
{{Achtung|'''Achte bitte darauf dass diese Ausgabe keine Fehler enthält!'''}}

==Aktivierung mit systemctl==
Wenn jetzt alles gepasst hat soweit, kann eingerichtet werden dass der Dienst automatisch startet. Im Anschluss daran kann er auch gleich das erste mal am Laufenden System aktiviert werden.
{{Warnung|'''Es ist besonders Wichtig, dass alle Browser beendet werden, bevor PSD beendet oder gestartet wird. Ansonsten kann es zu Datenverlust beim Browserprofil führen.'''}}
*'''Starten'''
<pre style="background-color: #FFFFC0">systemctl start psd.service</pre>
*'''Aktivieren (Autostart)'''
<pre style="background-color: #FFFFC0">systemctl enable psd.service</pre>
{{Hinweis|'''Damit ist der Dienst gestartet und wird automatisch aktiviert.'''}}
 

=Nachwort=
{{Hinweis|'''So läuft des Ding bei mir wunderbar. Ich wollte das weitergeben, und hoffe nichts wichtiges übersehen zu haben.'''}}
'''An dieser Stelle nochmal:'''
{{Achtung|'''Macht eine Sicherung und schaut genau was ihr tut.'''}}
 

=Quellen/Links:=
* https://wiki.archlinux.org/index.php/Profile-sync-daemon
* https://github.com/graysky2/profile-sync-daemon
---------
{| class="wikitable"
|-
|'''Navi:'''
|[[Mini_Tuning_guide_für_openSUSE_13.2|Zurück zum Guide]]
|-
|}
--------

[[Kategorie:HowTo]]

Tipp: zswap aktivieren

2015-09-18T19:51:43Z

Gehrke: Kategorie:HowTo

{{Review|alles}}
{{Warnung|'''Das anwenden aller hier niedergeschriebenen Modifikationen geschieht auf eigene Gefahr. Ich übernehme keine Verantwortung für etwäige Probleme die durch die Verwendung dieser Tipps entstehen könnten!'''}}
Der zswap ist eine Art komprimierter Cache für swap Seiten im RAM. Seiten die normalerweise mehr oder minder direkt auf die Festplatte ausgelagert würden, werden stattdessen zunächst im RAM komprimiert verwaltet und erst, wenn es ganz hart auf hart kommt auf die Festplatte ausgelagert.
{{Achtung|'''Ein physisch existierender swap Bereich, ist hierfür wiederum Voraussetzung. Teilweise ist zswap noch nicht ganz erforscht und ausgetestet. Daher wird in der Doku diesbezüglich gewarnt und deswegen ist es standardmäßig auch deaktiviert!!'''}}

Hier die Dokumentation zu zswap:
* https://www.kernel.org/doc/Documentation/vm/zswap.txt

'''Ich bin mir eventueller Folgen bewusst und aktiviere es hier einfach mit Voreinstellungen:'''
* 1. Dazu starte ich YaST.
* 2. öffne dort Bootloader
* 3. wechsele zur Seite "Kernel-Parameter"
* 4. füge bei: "Optionaler Parameter für Kernel-Befehlszeile" am Ende der Zeile folgendes ein:
<blockquote><pre style="background-color: #D4FFEF">zswap.enabled=1</pre></blockquote>
{{Hinweis|'''Wenn diese Einstellung dann abgespeichert wurde, ist zswap beim nächsten Systemstart aktiv.'''}}
'''Überprüfung nach dem Neustart:'''
<pre style="background-color: #FFFFC0">dmesg | grep 'zswap.* compressor'</pre>
<blockquote><pre style="background-color: #D4FFEF">zswap: using lzo compressor</pre></blockquote>
---------
{| class="wikitable"
|-
|'''Navi:'''
|[[Mini_Tuning_guide_für_openSUSE_13.2|Zurück zum Guide]]
|-
|}
--------

[[Kategorie:HowTo]]

Tipp: Snapper entschärfen

2015-09-18T19:50:02Z

Gehrke: Kategorie:HowTo

{{UnderConstruction}}
{{Überarbeiten}}
{{Warnung|'''Das anwenden aller hier niedergeschriebenen Modifikationen geschieht auf eigene Gefahr. Ich übernehme keine Verantwortung für etwäige Probleme die durch die Verwendung dieser Tipps entstehen könnten!'''}}

Grundlage definition (Standardeinstellung):
 
'''Timeline Snapshots:''' 
Ein einzelner Schnappschuss der alle Stunde erstellt wird. Alte werden automatisch gelöscht. Der erste der letzten 10 Tage / Monate / Jahre wird behalten.
 
'''Installationsschnappschuss:''' 
Wird immer erstellt, wenn veränderungen mit dem Paketmanagement via YaST oder zypper vorgenommen werden. Immer einer vor 'Pre' und nach 'Post'. Alte werden automatisch gelöscht. Die davon 10 letzten als wichtig und regulär markierten Schnappschüsse werden behalten.
 
'''Administrations Schnappschüsse:''' 
Wenn man veränderungen an YaST Modulen (Drucker oder so.) vornimmt wird immer einer vor 'Pre' und nach 'Post' erstellt. Alte werden automatisch gelöscht. Hier werden die 10 letzten wichtigen sowie regulären Schnappschüsse behalten.
 
*Einstellungen: 
NUMBER_LIMIT (Standard=50) Anzahl unwichtiger Schnappschüsse die behalten werden. 
NUMBER_LIMIT_IMPORTANT (Standard=10)Anzahl wichtiger Schnappschüsse die behalten werden. 
NUMBER_CLEANUP=YES (Nur die jüngsten NUMBER_LIMIT und NUMBER_LIMIT_IMPORTANT werden behalten). 

'''Problemstellung:'''
*Snapper erstellt momentan in openSUSE 13.2 standardmäßig 50 Schnappschüsse ein. Bei einer sehr kleinen Festplatte, von nur 30 GiB größe, ist diese damit binnen kürzesterzeit vollgeschrieben und überlastet.

* Für SSD Fetischisten (entschuldigt bitte das Wort). Ist es nicht sonderlich schön, wenn ein Dienst ständig auf der Festplatte schreibt. Ideen dazu:
# Snapper deaktivieren
##Installations Schnappschüsse deaktivieren: (Paket snapper-zypp-plugin deinstallieren)
##Timeline Snapshots (Stündliche) deaktivieren: (TIMLINE_CREATE=NO)
##Administrations Schnappschüsse deaktivieren: Sysconfigeditor: USE_SNAPPER=no.
# Schreiben auf HDD reduzieren durch gezielte Einstellungen (Mittelwert)?? Eventuell stündliche Schnappschüsse deaktivieren und einen Täglich?

'''Was tun im Fehlerfall?'''
{{Hinweis|Aktuell ist es wohl so, dass irgendwann die Festplatte mit Schnappschüssen voll läuft bis kein Speicherplatz mehr frei ist. Das kann dazu führen, dass der Computer nicht mehr startet.}}

*https://www.suse.com/documentation/sles11/stor_admin/data/trbl_btrfs_volfull.html

''' Hier meine aktuell verwendete Konfiguration Für eine HDD mit wenig Speicherplatz:'''
{{Achtung|Diese Einstellungen beschränken die Schnappschüsse möglichst auf ein Minimum (Einen). Das ist nicht sonderlich sinvoll aber Wirkungsvoll.}}

Von jeglicherm Snapshot wird eine Ausgabe behalten. Eventuell sollte man eher 2 - 3 Machen? Die Frage ist, wieviel ist sinnvoll? 50 (standard) sind jedenfalls zu viel!
<pre style="background-color: #FFFFC0">pico /etc/snapper/configs/root</pre>
<blockquote><pre style="background-color: #D4FFEF">
SYNC_ACL="no"
BACKGROUND_COMPARISON="no"
NUMBER_CLEANUP="yes"
NUMBER_MIN_AGE="200"
NUMBER_LIMIT="1"
NUMBER_LIMIT_IMPORTANT="1"
TIMELINE_CREATE="no"
TIMELINE_CLEANUP="yes"

TIMELINE_MIN_AGE="200"
TIMELINE_LIMIT_HOURLY="1"
TIMELINE_LIMIT_DAILY="1"
TIMELINE_LIMIT_MONTHLY="1"
TIMELINE_LIMIT_YEARLY="1"

EMPTY_PRE_POST_CLEANUP="yes"
EMPTY_PRE_POST_MIN_AGE="200"
</pre></blockquote>

{{Hinweis|'''Für eine vorgeschlagene Konfiguration wäre ich hier dankbar, da ich da selbst noch nicht ganz durchgestiegen bin, was wirklich sinnvoll ist, da ich ihn auch noch nie nutzen musste.'''}}
Lesestoff:
* http://snapper.io/manpages/snapper-configs.html
* http://snapper.io/
*https://en.opensuse.org/openSUSE:Snapper_Tutorial
---------
{| class="wikitable"
|-
|'''Navi:'''
|[[Mini_Tuning_guide_für_openSUSE_13.2|Zurück zum Guide]]
|-
|}
--------

[[Kategorie:HowTo]]

Mini Tuning guide für openSUSE 13.2

2015-09-18T19:48:29Z

Gehrke: Kategorie:HowTo

{{Review|alles}}
=Vorwort:=
{{Hinweis|'''Hier eine Sammlung nützlicher Tipps zu openSUSE 13.2:'''}}
Hier möchte ich einige Kniffe zeigen, mit denen experimentierfreudige ihren Rechner ein wenig tweaken können. Fokus liegt dabei auf Veränderungen am Auslagerungsverhalten und dem damit verbundenen minimieren von Schreibvorgängen auf die Festplatte. Auch geht es darum den Computer etwas zu Entrümpfeln. Vorab ein Wort der Warnung: {{Warnung|'''Das anwenden aller hier niedergeschriebenen Modifikationen geschieht auf eigene Gefahr. Ich übernehme keine Verantwortung für etwäige Probleme die durch die Verwendung dieser Tipps entstehen könnten!'''}}

{{Box Wissen||
* Umgang mit der [[Shell]]
* Umgang mit einem [[Paketmanager]] und die Unterschiede solcher.
* [[Systemd#Was_ist_systemd.3F|Was ist Systemd?]]
* [[Systemd#Umgang_mit_systemctl|Umgang mit systemctl.]]
}}

==Temporäre Dateien automatisch bereinigen==
Dateisystem automatisch von temporären Überbleibseln befreien:
 
[[Tipp: systemd-tmpfiles]]

==Speicherplatzbelegung des 'journal'==
Verhindern, dass unnötig viel Speicherplatz von Logdateien belegt wird:
 
[[Systemd#Speicherplatzbelegung|Tipp: Speicherplatzbelegung des 'journal']]

==Browser im RAM schnell wie nie mit: Profile Sync Daemon==
Browser, Profile inklusive Cache im Speicher behalten und periodisch mit rsync auf die Festplatte synchronisieren:
 
[[Tipp: Profile Sync Daemon|Tipp: Profile-Sync-Daemon]]

==Swap verhalten optimieren==
Beeinflussen wie frequent der Kernel auf die Festplatte auslagert:
 
[[Tipp:_Swapverhalten_optimieren|Tipp: Swapverhalten optimieren]]

==zswap aktivieren==
Verbindet Komprimierung mit einer Verbesserung des SWAP-verhaltens. 
[[Tipp:_zswap_aktivieren|Tipp: zswap aktivieren]]

==zramswap verwenden==
Erzeugt ein zram basiertes swap gerät beim Systemstart.
 
[[Tipp:_zramswap_verwenden|Tipp: zramswap verwenden]]

==Snapper entschärfen==
Ist noch in Arbeit und daher noch nicht ganz zielführend. 
Speicherplatzverbrauch von Sicherungen durch 'snapper' beschränken:
 
[[Tipp:_Snapper_entschärfen|Tipp: Snapper entschärfen]]

=Viel Spass!=
Ich hoffe der ein oder andere findet hier doch etwas neues und nützliches!

[[Kategorie:HowTo]]

Tipp: zramswap verwenden

2015-09-18T19:46:23Z

Gehrke: Kategorie:HowTo

{{Review|alles}}
=Vorwort=
Zramswap ist ein Skript und ermöglicht es, komprimierten swap Bereich im RAM zu erstellen. Quasi swap als RAM-Laufwerk. Er erstellt pro CPU automatisch einen Bereich. Bei einem Quadcorce Prozessor, wären dies also 4 komprimierte Laufwerke die hoch verfügbar im Arbeitsspeicher liegen und einen im Idealfall als Desktopbenutzer von der Festplatte lösen können. Das Skript bedient sich hierfür am zram Modul:
* Dokumentation zu zram: https://www.kernel.org/doc/Documentation/blockdev/zram.txt
* Idee zum Howto aus: https://wiki.archlinux.org/index.php/Maximizing_performance#Zram_or_zswap

'''Es ist wichtig, abzuwägen ob der Skript am eigenen System verwendet werden kann.'''
{{Warnung|'''Suspend to Disk Funktioniert nur mit einem swapbereich auf der Festplatte'''}}
{{Achtung|'''Wer also nicht auf suspend to disk verzichten möchte oder kann, sollte hier abbrechen, da es nicht mehr funktionieren kann!'''}}
{{Hinweis|'''Bei Verwendung einer SSD ist dieser Tipp sinnvoll, da ohnehin S2DISK deaktiviert wird um das Gerät zu schonen.'''}}
{{Warnung|'''Das anwenden aller hier niedergeschriebenen Modifikationen geschieht auf eigene Gefahr. Ich übernehme keine Verantwortung für etwäige Probleme die durch die Verwendung dieser Tipps entstehen könnten!'''}}
==Paket herunterladen==
Es gibt im Buildservice glücklicher Weise ein RPM. Dies kann über die Softwaresuche gefunden werden: 
https://software.opensuse.org/package/zramswap?search_term=zramswap

==Paket installieren==
Nachdem das Paket heruntergeladen wurde, kann es mit folgendem Befehl installiert werden:
<pre style="background-color: #FFFFC0">rpm -Uhv zramswap-1-4.1.noarch</pre>

==zramswap konfigurieren==
{{Hinweis|'''Wer die Standardeinstellungen verwenden möchte, kann diesen Abschnitt überspringen'''}}
'''Ich kenne nur diesen leider etwas komplizierten Weg:''' 
Der Hauptskript muss für persönliche Einstellungen editiert werden. Diesen findet ihr hier:
<blockquote><pre style="background-color: #D4FFEF">/usr/lib/systemd/scripts/zramctrl</pre></blockquote>

Vorhin habe ich angesprochen, dass pro CPU ein Auslagerungsbereich im RAM angelegt wird. Bei einem Computer mit 8 GiB RAM möchte ich dafür ca. 2 GiB verwenden. Dafür ändere ich folgenden Wert wie beschrieben auf den Faktor 256 (Diesen habe ich ausgerechnet):
<pre style="background-color: #FFFFC0">mem_total = (0 + $2) * 256</pre>
{{Hinweis|'''256 entspricht ca. 508348 KiB mal 4 Kerne ist ca. 2 GIB, ausgehend von 8 GiB RAM.'''}}

==Dienst aktivieren==
{{Hinweis|'''Das geschieht bei systemd mit der Verwendung des zubehörigen Tools:''}}
<blockquote>
'''Prozess starten'''
<pre style="background-color: #FFFFC0">systemctl start zramswap</pre>
'''Autostart an'''
<pre style="background-color: #FFFFC0">systemctl enable zramswap</pre>
'''Status abfragen'''
<pre style="background-color: #FFFFC0">systemctl status zramswap</pre>
</blockquote>
{{Achtung|'''Die Statusabfrage sollte keine Fehlermeldungen beinhalten:'''}}
<blockquote>
<blockquote><pre style="background-color: #D4FFEF">
zramswap.service - Zram-based swap (compressed RAM block devices)
Loaded: loaded (/usr/lib/systemd/system/zramswap.service; enabled)
Active: active (exited) since Di 2015-09-15 10:37:07 CEST; 3h 34min ago
Process: 847 ExecStart=/usr/lib/systemd/scripts/zramctrl start (code=exited, status=0/SUCCESS)
Main PID: 847 (code=exited, status=0/SUCCESS)
CGroup: /system.slice/zramswap.service
</pre></blockquote>
</blockquote>
{{Hinweis|'''Der Dienst ist jetzt gestartet und für den automatischen Start aktiviert.''}}

==Für Mutige==
Der Kernel wird bei Verwendung von 'zramswap' erst auf die Festplatte auslagern, wenn er vollgelaufen ist. Wer also ganz mutig ist, kann noch folgendes tun:
{{Warnung|'''Wenn der Computer zu wenig Speicher hat, kann es zu einem sog. Deadlock führen, wenn der Speicher voll ist.'''}}
Wer jetzt sagt, sein Gerät hat genug Speicher und benötigt deswegen keinen SWAP mehr '''auf der Festplatte''', sondern nur noch im RAM, kann SWAP in der fstab auskommentieren.
{{Hinweis|'''Bei meinem Computer mit 8 GiB RAM ist das einwandfrei möglich. Getestet: 3 verschiedene VM´s gleichzeitig (Virtualbox insg. 6 GiB zugewiesener Speicher) -- dazu Webbrowser im RAM mit Profile Sync Daemon, Office E-mail auf KDE, bissl Desktopcube drehen, es wurden gerade mal 300 KIB in das virtuelle Laufwerk geswappt. Also passt schon.'''}}

=Quellen/Links:=
* https://www.kernel.org/doc/Documentation/blockdev/zram.txt
* https://wiki.archlinux.org/index.php/Maximizing_performance#Zram_or_zswap
* https://software.opensuse.org/package/zramswap?search_term=zramswap

---------
{| class="wikitable"
|-
|'''Navi:'''
|[[Mini_Tuning_guide_für_openSUSE_13.2|Zurück zum Guide]]
|-
|}
--------

[[Kategorie:HowTo]]