Server

Subnetz, Zusatz-IPs oder Failover-IPs mit netplan / systemd bei Hetzner konfigurieren (Ubuntu 18.04 / Xen)

kelly — Fri, 06 Jul 2018 06:31:14 +0000

Subnetz, Zusatz-IPs oder Failover-IPs mit netplan / systemd bei Hetzner konfigurieren (Ubuntu 18.04 / Xen) kelly Fr., 06.07.2018 - 08:31 Uhr

Host-Konfiguration

Der Server unter Ubuntu 18.04 wird vom Hetzner-Script installimage mit netplan installiert (vorher mit systemd-network).

Netzwerk-Konfiguration

Für Zusatz-IPs, Subnetze oder Fail-Over-IP-Adressen ist keine Konfiguration des Hosts-System nötig, wenn diese Adressen von den Xen-Gästen verwendet werden sollen.

Routed Network

Bei Hetzner muss xen als routed network betrieben werden. Die entsprechenden Konfigurations-Dateien /etc/xen/xl.conf sind dahingehend anzupassen:

vif.default.script="vif-route"
vif.default.gatewaydev="eth0"

Statt eth0 muss die Bezeichnung der Netzwerkkarte verwendet werden.

Anschließend muss das Routing im System in der Datei /etc/sysctl.d/99-hetzner.conf aktiviert werden:

net.ipv4.ip_forward=1

Anschließend laden der Konfigurationen:

sysctl -p /etc/sysctl.conf

Konfiguration virtueller Maschinen

Nach der Einrichtung mit xen-tools existiert keine funktionierende Netzwerk-Konfiguration. Über die xen-Konsole muss das Netzwerk eingerichtet werden.

Netzwerk

Netzwerk-Einstellungen in /etc/systemd/network/10-eth0.network:

[Match]
Name=eth0
 
[Address]
Address=aaa.bbb.ccc.ddd
Peer=AAA.BBB.CCC.DDD/32
 
[Route]
Gateway=AAA.BBB.CCC.DDD

aaa.bbb.ccc.ddd IP-Adresse der VM
AAA.BBB.CCC.DDD IP-Adresse des Host-Systems

Durch die Verwendung von Peer (was PointToPoint) entspricht, können alle IP-Adressen eines Subnetzes verwendet werden, da kein Routing im Subnetz benötigt wird.

Konfiguration laden

systemctl enable systemd-networkd
service systemd-networkd start
ip route add default via AAA.BBB.CCC.DDD

AAA.BBB.CCC.DDD IP-Adresse des Host-Systems

Nameserver ohne systemd

systemctl disable systemd-resolved.service
systemctl stop systemd-resolved
 
rm /etc/resolv.conf
 
cat << EOF > /etc/resolv.conf
nameserver 213.133.98.98
nameserver 213.133.100.100
nameserver 213.133.99.99
EOF
 
service postfix restart

Nameserver mit systemd

In Datei /etc/systemd/resolved.conf ergänzen:

DNS=213.133.98.98 213.133.100.100 213.133.99.99

Konfiguration laden

service systemd-resolved restart

Resolver-Status kontrollieren

systemd-resolve --status

Löschen /etc/network/interfaces

Die alte Konfiguration muss noch gelöscht werden, damit diese nicht später genutzt wird.

rm /etc/network/interfaces

Weitere IP-Adressen konfigurieren

Werden weitere IP-Adressen benötigt (z.B. eine zusätzliche Failover-IP), wird diese als weitere IP-Adresse in der Xen-Gast-Konfiguration hinterlegt:

vif         = [
   'ip=aaa.bbb.ccc.ddd/32 eee.fff.ggg.hhh/32 iii.jjj.kkk.lll/32,mac=AA:AA:AA:AA:AA:AA',
 ]

Es empfiehlt sich, eine MAC-Adresse zu vergeben, um nach dem Neustart eines Gastes nicht mit dem arp-cache des Hosts in Konflikt zu geraten.

Die IP-Adressen werden alle auf eth0 im Gast zur Verfügung gestellt.

Die Konfiguration von eth0 muss entsprchend in /etc/systemd/network/10-eth0.network angepasst werden:

[Match]
Name=eth0
 
[Address]
Address=aaa.bbb.ccc.ddd
Peer=AAA.BBB.CCC.DDD/32
 
[Address]
Address=eee.fff.ggg.hhh
Peer=AAA.BBB.CCC.DDD/32
 
[Address]
Address=iii.jjj.kkk.lll
Peer=AAA.BBB.CCC.DDD/32
 
[Route]
Gateway=AAA.BBB.CCC.DDD

aaa.bbb.ccc.ddd IP-Adresse der ursprünglichen IP-Adresse
eee.fff.ggg.hhh IP-Adresse der zusätzlichen IP-Adresse
iii.hhh.jjj.lll IP-Adresse der weiteren zusätzlichen IP-Adresse
AAA.BBB.CCC.DDD IP-Adresse des Host-Systems

Nicht immer funktioniert der Neustart von systemd-networkd sauber. Ein reboot des Systems liefert verlässlichere Ergebnisse.

Aktualisiert am 2018-12-17. Die vorherige Lösung mit verschiedenen Netzwerk-Adaptern im Gast hat sich nicht bewährt.

Systeme

Server

Spectre und Meltdown

kelly — Thu, 04 Jan 2018 21:05:10 +0000

Spectre und Meltdown

kelly Do., 04.01.2018 - 22:05 Uhr

Stand 2018-02-12 21:30 - Wir beobachten die Nachrichten rund um die Exploits mit großem Interesse, da auch wir für den sicheren Betrieb von Servern verantwortlich sind. Unsere Erkenntnisse sammeln wir hier und haben uns entschieden, diese öffentlich zu machen. Die Zusammenstellung hat keinen Anspruch auf Vollständigkeit oder auf Richtigkeit. Dieses Dokument wird laufend überarbeitet (Update-Notizen finden sich am Ende), über Hinweise sind wir jederzeit dankbar. ky.

Die Exploits
Angriffsmöglichkeiten
Linux-Server
Firewalls
Updates

Die Exploits

Unter den Namen Spectre und Meltdown sind im Frühjahr 2017 drei Sicherheitslücken entdeckt worden, die sich bestimmte Eigenschaften der CPU zu nutze machen, um sensible Informationen aus anderen Prozessen auszulesen (Spectre) bzw. unerlaubt Informationen aus dem kompletten Hauptspeicher der physischen Maschine auszulesen (Meltdown). Neben dem Datenklau (z.B. Passworte) könnten sensible Informationen auch für die Erlangung von privilegierten lokalen Rechten verwendet werden.

Die Fehlerbehebung ist sehr komplex bzw. nach Einschätzung vieler Expert*innen gar nicht völlig möglich, ohne die CPUs auszutauschen; daher konzentrieren sich zur Zeit alle Entwicklungen auf eine Minimierung der Risiken („Mitigation“).

Für die Bugs sind drei international gültige Bug-Einträge (CVE - CVE-2017-5753 CVE-2017-5715 CVE-2017-5754 ) erzeugt worden, gleichzeitig wurde vereinbart, vor dem 09.01.2018 diese Bugs nicht zu veröffentlichen („Embargo“). Dieses Embargo dient dazu, allen Beteiligten genug Zeit für die Bereitstellung von Updates einzuräumen. (Urlaubs- und ferienbedingt macht dieser Zeitpunkt Sinn - die Updates müssen ja auch zeitnah von irgendwelchen Admins* eingespielt werden.)

Leider hat das Embargo nicht gegriffen, aus Entwicklungskreisen drangen Hinweise nach außen, zuerst berichtete TheRegister über eine derartige Lücke, woraufhin Google seine Erkenntnisse am 3.1.18 veröffentlicht hat („Disclosure“), in den letzten Stunden haben viele weitere Anbieter nachgezogen.

Das Problem ist, dass nun diese Angriffsvektoren bekannt sind aber in vielen Fällen noch keine Updates bereit stehen. Angesichts der Tatsache, dass jegliche Hardware mit einem Prozessor von Intel, AMD oder Arm (AMD und Arm „nur“ Spectre) betroffen sind, ist das verdammt viel - PCs, Server, Smartphones, Router, Firewalls, IoT-Geräte, Embedded Hardware in Industrie oder Autos. Also eigentlich alles.

Cert Bund informiert in CB-K18/0010.

Angriffsmöglichkeiten

Um diese Exploits auszunutzen, muss natürlich erst einmal der Angriffscode auf den Rechner gelangen und dort ausgeführt werden.
Meltdown ist daher (bisher) kein Remote-Angriff, dafür kann mit einem erfolgreichen Angriff eines lokalen Accounts der ganze Hauptspeicher des ganzen physischen Servers ausgelesen werden. Mit etwas Pech finden sich dort genug Informationen, um danach das System zu übernernehmen. Unterdessen (8.1.) berichtet Fefe über Hinweise, dass Meltdown nicht ohne Weiteres ausgenutzt werden kann. Das bringt vielleicht etwas Zeit, bis die Kernel überarbeitet worden sind, v.a. auch in Hinblick auf künftige Performancegewinne - die aktuellen Lösungen dienen in meiner Wahrnehmnung vor allem dazu, die Lücke zuzunageln.
Spectre hingegen kann auch remote verwendet werden, zum Beispiel scheint geschickt programmierter Javascriptcode (Javascript wird auf de facto jeder Webseite eingesetzt) auszureichen, damit der lokale Browser diese Lücke ausnutzt und ein Angriff stattfinden kann. Theoretisch ist also ein Angriff (Ausspähen von Daten wie Passworten oder Dokumenten aus dem Browser (andere Tabs!), evtl. Installation von Schadcode) über Webseiten möglich. Microsoft, Chrome und Mozilla arbeiten bereits an Sofortmaßnahmen oder haben diese veröffentlicht (Mozilla Chrome Microsoft Safari).
Gute Infos zu Exploits und Proof of Concepts liefern die Kolleg*en von entwickler.de.

Fatal ist die Lücke für Multiusersysteme, wie z.B. Hochschulserver. Jede/r User*in mit lokaler Kommandozeile kann theoretisch diese Lücken ausnutzen bzw. Opfer eines solchen Angriffs sein (z.B. Ausspähen von Daten wie Passworte oder E-Mails).

Noch schlimmer wird es in der „Cloud“ bzw. Virtualisierungsservern. Die dort laufenden virtuellen Systeme ("VServer") haben durch die Lücke von Meltdown die Möglichkeit, den Hauptspeicher aller anderen derzeit laufenden virtuellen Maschinen auszulesen. Alle im Hauptspeicher enthaltenen Daten all dieser virtuellen Maschinen auf der gleichen Hardware können im Klartext abgerufen und gespeichert werden. Dies sind nicht nur Dokumente, sondern auch Variablen von laufenden Programmen, in denen Daten oder Passworte abgelegt sein können.
Betroffen davon sind wahrscheinlich ebenso Cloud-Dienste wie Amazon Cloud, Microsoft Azure oder Google Compute Engine - bei allen diesen Diensten teilen sich mehrere virtuelle Server die gleiche Hardware. Alle diese Dienste arbeiten bereits an Lösungen oder haben diese bereits eingespielt. Schwierig wird es für kleine Cloud-Betreiber sein, die nicht vorab über die Sicherheitslücken informiert wurden und nun einige schlaflose Nächte haben werden (die Kunden wohl auch).
Betroffen sind aber auch Hostingprovider, die mit Virtualisierung arbeiten und einzelne VServer anbieten (wie Hetzner, Strato oder 1&1 zum Beispiel - Hetzner informiert übrigens vorbildlich). In den nächsten Tagen ist hier hoffentlich mit Updates zu rechnen.

Für Windows-PCs, Apple (MacOS) und Smartphones gibt es bei n-tv eine gute Übersicht. (Hoffentlich bieten viele Smartphone-Anbieter zügig Updates auch für alte Systeme an - ein riesen Sicherheitsproblem!)

Microsoft hat für Windows bereits sehr früh Updates geliefert und informiert, weitere Updates folgten am 18.01. und 31.01..

Apple hat sich am 5.1. auch geäußert: Mitigations für Meltdown sind bereits veröffentlicht (iOS 11.2, macOS 10.13.2, and tvOS 11.2). Spectre: Updates für Safari (11.02) für iOS (11.2.2), macOS (10.13.2 und 10.12.6 und 10.11.6), für tvOS und watchOS ist anscheinend gegen Spectre noch nichts erschienen oder sie sind nicht betroffen.

Privatanwender sollten also dringend ihre PCs, Smartphones und Browser aktualisieren.

Linux-Server

Für Linux-Server haben die Distributionen verschiedene Stände. Ein sinnvolles Update umfasst nach unserer Einschätzung ein Update des Microcodes der CPU, des Linux (Kernel) und der Virtualisierungssoftware / Hypervisor (kvm, qemu, xen, ...):

Mit einem Update des Microcodes kann das Verhalten der CPU geändert werden ("Firmware-Update"). Die modernen CPUs bieten dafür Möglichkeiten, damit diesen Updatevorgang die Betriebssystem-Software übernimmt.
Intel hat am 4.1. mitgeteilt, dass Updates für Prozessoren der letzten fünf Jahre bereitgestellt werden. Dieses wird in einer Mitteilung vom 09.01. konkretisiert. In einem offenen Brief ("Security-First Pledge") vom 11.01. sichert Intel die Zurverfügungstellung der Microcode-Updates bis Ende Januar vor, wobei bis zum 15.1. bereits Patches für 90% der Prozessoren aus den letzten fünf Jahren bereit gestellt werden sollen. Das hat offensichtlich nicht geklappt.
Am 09.01. hat Intel neuen Microcode bereitgestellt, der aber nach einigen Tagen aufgrund diverser Probleme wieder zurückgezogen wurde (Link zur Liste der Microcode-Updates).
Außerdem existiert ein Intel Security Advisory. Am 7.2. hat Intel eine neue Version des Microcodes an die Industrie- und OEM-Partner zur Verfügung gestellt. Wann diese als stabile Veröffentlichung frei gegeben werden bleibt abzuwarten. Eine Liste der betroffenen Prozessoren gibt es unterdessen auch.
Am 12.02. hat ein Intel dieses PDF-Dokument veröffentlicht, in dem alle CPUs gelistet sind, für die es Mitigitaions geben wird, ebenso wie der Arbeitsstand dafür ist.
Was mit einem Microcode-Update gerettet werden kann, bleibt abzuwarten. Wie oben beschrieben, gehen die meisten davon aus, dass nur mit neuen CPUs Abhilfe wirksam geschaffen werden kann.
Links zu Intel-OSS-10002 und Intel-OSS-10003.

Für Xen existiert bisher ein Sicherheits-Advisory (unterdessen Version 10 vom 2018-01-18 18:38) und eine FAQ vom 4.1. und eine aktualisierte FAQ vom 22.1.. Im Fokus stehen Schutzmaßnahmen gegen Meltdown ("SP3"). Betroffen sind 64-Bit PV-Gäste. Xen arbeitet an einer Lösung für die Versionen ab 4.6 und neuer, um PTI/Kaiser für Xen zu ermöglichen, die Performance wird als "fair" angegeben und der Testing-Status als "very new". Bis dahin empfiehlt Xen den Einsatz von HVM, was jedoch den Umbau der PV-Gäste erfordert und die Leistung beeinträchtigt. Um den Übergang zu erleichtern, wurde die Lösung HVM shim für alle Xen-Versionen geschaffen, um einen "PV-Gast mit Beiwagen" zu betreiben (HVM shim "Vixen"). Als empfohlene Lösung wird PVH vorgeschlagen, das nachträglich für Version 4.8. "als Beiwagen-Lösung" bereit gestellt wird (PVH shim "Comet" - Link). In Version 4.10 wird PVH nativ enthalten sein wird. Für die Unterschiede der "Beiwagen-Lösungen" gibt es dieses Dokument, für die Umwandlung von PV nach HVM shim with "sidecar" ISO gibt es dieses Script.
Am 24.01. wurde die Version 4.8.3 veröffentlicht, die bereits die PTI-Patches und enthält. Für alle anderen Versionen ab 4.6 und neuer sind bereits commits angegeben, jedoch wurde noch keine Version veröffentlicht.
Alle Xen-basierten Hostsysteme (bis auf 4.8) sind derzeit verwundbar. Xen hat noch ein weiteres Dokument veröffentlicht, in dem Vorschläge für die praktische Sicherung erörtert werden. Klar ist, dass durch die Updates nicht alle Probleme gelöst werden können. Damit stünden für Meltdown zwei Lösungsvarianten zur Verfügung: Entweder ein sicheres Gastsystem (Kernel mit KPTI-Update und Xen-Hypervisor mit KPI-Patches) oder die Umstellung auf HVM bzw. PVH (wobei PVH erst ab xen 4.10 zur Verfügug steht und damit für Ubuntu 16.04 und auch Ubuntu 18.04 keine Lösung zu sein scheint.)
Um Xen 4.10 zu nutzen, muss dieses für Ubuntu 16.04 und wahrscheinlich 18.04 aus den Quellen selbst gebaut werden (Howto).

Bei Opensuse existiert dieses Advisory, außerdem existieren bereits diverse Updates (kernel, qemu, kvm, microcode). Die haben die Zeit echt genutzt.

Bei RedHat wurde ebenfalls ein gutes Advisory veröffentlicht, ebenso zahlreiche Updates (Kernel, qemu-kvm, libvirt). Auch hier scheint die Zeit gut genutzt worden zu sein.

Ubuntu hat bisher ein Advisory (inkl. Übersicht der betroffenen Kernel und Updates) sowie mehrere Updates veröffentlicht. Hier die Einträge im CVE-Tracker:

xen fehlt leider jedoch völlig in den Listen der möglicherweise betroffenen Pakete. Im o.g. Advisory sind die Updates (v.a. Kernel-Updates) aufgelistet. Mit den Kernel-Updates sind die Systeme gegen Spectre 1, Spectre-2 (Retpoline) und Meltdown geschützt. Der Betrieb von sicheren Xen-Gästen (Meltdown!) mit ist jedoch bisher nur mit Umwandlung nach HVM möglich, da PVHVM noch nicht unterstützt wird. Auch wenn xen an updates für 4.6 arbeitet (s.o.) ist unklar, wann diese erscheinen und ob Ubuntu diese Übernimmt. Alternative: Xen per Hand bauen.

Bei Debian habe ich kein Security Advisory gefunden, stattdessen nur eine Mail auf debian-user - auf debian-security oder debian-security-announce gab es keine Mail. Nicht befriedigend! Immerhin hier der CVE-Tracker:

Am 04.01.2018 erschien ein erstes Debian Security Advisory DSA-4078 mit einem Update für CVE-2017-5754 für die stable-Version mit dem aktuellen Kernel 4.9.65-3+deb9u2 (stretch). Unterdessen (Stand 8.1.) sind ebenfalls die Kernel 3.2.96-3 (wheezy) und 4.14.12-2 (sid) verfügbar. Am 09.01. kam ist das Update für Meltdown für Jessie erscheinen (DSA-4082-1). Gegen Spectre wurden bsiher keine Updates veröffentlicht.

Auf BSD beruhen viele Sicherheits-Appliances, allerdings wurde BSD erst Ende Dezember informiert (Was soll das?!). A m 8.1. hat FreeBSD einen Fahrplan vorgelegt. Für Updates hier ab und zu einen Blick werfen oder die Debatten auf der Mailingliste bsd-security verfolgen. Interessant ist noch dieser Blog-Eintrag, in dem über das Vorgehen für Hardened-BSD und die Überlegung über retpoline berichtet wird. Für BSD liegen seit dem 21.2. Patches gegen Meltdown vor.

Eine Übersicht über die Linux-Updates wird auch vom Serverspezialisten Thomas Krenn gepflegt.

Firewalls

Der Firewallhersteller Cisco informiert in seinen Advisories über CPU Side-Channel Information Disclosure Vulnerabilities und betroffene Geräte. Die Liste wird regelmäßig aktualisiert und enthält unterdessen auch Datumsangaben für die Verfügbarkeit von Updates. Generell stellt Cisco klar, dass auf Hardware-Appliances in der Regel keine lokale User existieren, die Code ausführen können, so dass die Angriffsvektoren kleiner sind als auf Servern, auf die verschiedene User zugreifen können. Ähnliches gilt natürlich auch andere Appliances.

Der Firewallhersteller Juniper informiert in diesem Blogbeitrag über betroffene Geräte und kündigt Updates an (siehe Security Advisories). Am 05.01. hat Cisco das Security Advisory JSA10842 veröffentlicht, in dem die betroffenen Geräte benannt werden und das regelmäßig aktualisiert wird. Als Mitigation wird empfohlen, nur Software aus verlässlichen Quellen einzusetzen und den Zugriff nur vertrauenswürdigen Administrator*innen zu gewähren (Äh? Und sonst darf da ja jeder ran?!).

Der Firewallhersteller Sophos hat bereits Informationen für die Software-Version veröffentlicht. Am 6.1. wurden Informationen über die Hardware-Appliances ergänzt: An den Updates für die Kernel und ggf. Firmware wird gearbeitet. Dies haben alle Kund*innen auch nochmals per Mail am 9.1. erhalten. Seit dem 5.1. stellt Sophos außerdem Protections zum Schutz vor Threats zur Verfügung. In der Liste Advisories kann man den Stand neuer Meldungen verfolgen.

Die Opensource-Firewall OPNsense (BSD-basiert) hat zeitnah am 03.01. per twitter reagiert und auf BSD verwiesen, die bereits an Updates arbeiten. Einen aktuellen Stand dürfte es dann auch der Blog-Seite oder dem twitter-channel geben. Seit dem sind mehrere RCs und Versionen schienen, die jedoch noch keine Updates für Meltdown und Spectre enthalten. In den Releasenotes für OPNSense 18.1 steht der Hinweis: "Meltdown and Spectre patches are currently being worked on in FreeBSD, but there is no reliable timeline. We will keep you up to date through the usual channels as more news become available. Hang in there!" mit diesem Link.

Die ebenfalls BSD-basierende Firewall pfSense hat am 4.1. per twitter ebenfalls auf Updates von freeBSD verwiesen, seit dem 08.01. existiert dieser Blogeintrag zum weiteren Vorgehen. Link zu den Security Advisories und twitter-channel.

Zum Schluss

Hier eine sehr gute und verständliche Zusammenfassung auf Englisch: https://www.renditioninfosec.com/files/Rendition_Infosec_Meltdown_and_Spectre.pdf
fefe hat wie immer Recht:
"Komplexität ist der Feind [von Sicherheit]."

Updates:

2018-01-04 23:44 Debian veröffentlicht Kernel-Update für CVE-2017-5754.
2018-01-05 07:30 ergänzt BSD, Cisco, Juniper, Sophos und pfsense und OPNsense.
2018-01-05 09:00 ergänzt Informationen zu Apple.
2018-01-05 09:45 Ergänzt qemu bei xen.
2018-01-05 11:30 Ergänzt Intel-Announcement und Xen-FAQ.
2018-01-05 13:00 Link zu entwickler.de ergänzt.
2018-01-05 22:45 Ubuntu-Zeitplanung ergänzt.
2018-01-06 13:00 Ergänzung bei Xen um "Respond to Meltdown and Spectre" und Lösungsskizzen
2018-01-07 01:30 Richtigstellung: OPNsense hat sehr schnell via twitter reagiert - sorry! Dank an @mimu_muc
2018-01-07 01:30 Cisco-Informationen aktualisiert - Danke an an @opnsense
2018-01-07 01:30 Infos zu Hardened-BSD übernommen - danke an @opnsense (retweet).
2018-01-07 02:15 Link zum Debian Advisory DSA-4078-1 ergänzt.
2018-01-07 02:15 Link zur FreeBSD-Mailingliste freebsd-security ergänzt.
2018-01-07 02:40 Ergänzung zu Sophos-Appliances und Protections.
2018-01-07 20:30 Juniper-Advisory JSA10842 ergänzt.
2018-01-07 22:45 Link zu Thomas Krenn ergänzt.
2018-01-08 09:15 Ubuntu: Verfügbarkeit der Test-Kernels ergänzt.
2018-01-08 23:30 Weitere Debian-Kernel aktualisiert.
2018-01-08 23:30 FreeBSD-Fahrplan ergänzt.
2018-01-09 01:30 Neue Informationen von pfsense/netgate ergänzt.
2018-01-09 17:30 Debian-Update für Jessie ergänzt.
2018-01-09 18:00 Hinweis auf Fefe zu Risiken von Meltdown ergänzt.
2018-01-10 05:30 Ubuntu stellt Kernel-Updates gegen Meltdown zur Verfügung.
2018-01-10 20:00 Ubuntu stellt neue Kernel-Updates zur Verfügung (regression updates).
2018-01-11 23:30 Intel-Bereich überarbeitet und aktualisiert
2018-01-11 23:30 Link zu Intel-Microcode ergänzt.
2018-01-11 23:30 Ubuntu stellt neuen Intel-Microcode bereit.
2018-01-12 00:30 Ergänzt RC1 für OPNsense.
2018-01-12 00:45 Aktualisierung Xen (v.4).
2018-02-07 23:45 Aktualisierung Updates Microsoft inkl. Links.
2018-02-07 23:45 Aktualisierung Updates Apple inkl. Links.
2018-02-07 23:45 Aktualisierung Intel-Microcode inkl. Link zur Liste der betroffenen Prozessoren.
2018-02-07 23:45 Überarbeitung des Xen-Abschnitts (v. 10) und Ergänzung Links.
2018-02-07 23:45 Aktualisierung Ubuntu.
2018-02-07 23:45 Aktualisierung Debian.
2018-02-07 23:45 Aktualisierung OPNsense.
2018-02-12 10:45 Informationen zu Intel ergänzt
2018-02-21 23:00 Information zu Meltdown und BSD ergänzt
2018-02-22 21:30 Informationen zu Ubuntu und Spectre-2 ergänzt.

Systeme

Server

Set Limit for open files for MySQL on Ubuntu 16.04 with systemd

kelly — Wed, 19 Apr 2017 15:42:40 +0000

Limit für open files für MySQL auf Ubuntu 16.04 mit systemd neu setzen kelly Mi., 19.04.2017 - 17:59 Uhr

Um die Fehlermeldung

Out of resources when opening file './database/table.MYD' (Errcode: 24 - Too many open files)

auf Ubuntu 16.04 zu beheben, müssen die Limits erhöht und Änderungen an der systemd-Konfiguration vorgenommen werden.

1. Limits erhöhen

vi /etc/security/limits.d/99-openfiles.conf

#<domain>      <type>  <item>         <value>
mysql          soft    nofile         8192
mysql          hard    nofile         8192

Wenn die Limits für alle user und root neu gesetzt werden sollen, können auch diese Einstellungen verwendet werden:

#<domain>      <type>  <item>         <value>
*              soft    nofile         8192
*              hard    nofile         8192
root           soft    nofile         8192
root           hard    nofile         8192

2. Anpassen der systemd-Konfiguration

Auf Ubuntu 16.04 werden die Dienste mit systemd gestartet. Daher müssen auch hier noch Anpassungen vorgenommen werden:

systemctl edit mysql

[Service]
LimitNOFILE=8192

(Editor verlassen mit :x)

systemctl daemon-reload
service mysql restart

3. Kontrollieren der MySQL-Einstellungen

Standardmäßig ist die MySQL-Variable open_files_limit auf 5000 gesetzt. Wenn der Wert erhöht werden muss:

vi /etc/mysql/mysql.conf.d/xx-openfiles.cnf

[mysqld]
open_files_limit        = 20000

Alternativ kann natürlich auch diese Variable in der /etc/mysql/my.cnf im Abschnitt [mysqld] ergänzt werden.

Systeme

Server