> Projekt wird von Red Hat unterstützt und in den Red Hat-Produkten verwendet.
systemctl enable systemd-timesyncd.service
Wozu ein weiteres Projekt und wozu die Unterstützung in Red Hat, wenn sie eigens dafür das systemd entwickelt haben ? Da ist doch schon alles enthalten... Man braucht weder ntpd nachinstallieren bzw. chrony nutzen...
Von Patricia Klar am Di, 3. Oktober 2017 um 20:53 #
systemd-timesyncd ist ein SNTP-Client, kein NTP-Server.
Verwirr doch diese »ichbinLinuxexperteweilichUbuntuinstallierenkann« mit deinen richtigen Aussagen nicht. Dieser Mensch war froh, dass er seinen Satz einigermaßen verständlich absetzen konnte.
Du übersiehst da wohl einen wichtigen Aspekt: "Im Vergleich zu einem "echten" NTP-Server ist in diesem Dienst nur die Clientfunktionalität umgesetzt." Quelle: Zeit per Systemd mit timesyncd synchronisieren
Und der Review nennt zumindest auch Fehler in der Serverkomponente.
Wer nur Clients betreibt und diese auch mit systemd, für den ist dein Vorschlag sicher eine Option. (Wobei der entsprechende Dienst von systemd im Zweifel noch nicht überprüft wurde.)
Ich wage auch zu bezweifeln das der systemd eine gute Wahl ist wenn Sicherheut relevant ist. Einfach weil die Art wie dort mit Sicherheitsfehlern umgegangen wird nicht gerade hinreichend Professionalität erwarten lässt.
Hallo, da möchte ich 100% zustimmen! In unserer Kölner LUG durfte ich mich dank genau dieser Argumente schon als Ewiggestriger anpöbeln lassen. Ich finde den Umgang mit Bugs wichtig, und die Entwickler von systemd haben sich hierbei bislang nicht mit Ruhm bekleckert viele Grüße!
die Entwickler von systemd haben sich hierbei bislang nicht mit Ruhm bekleckert
Du bist ein Ewiggestriger, denn sonst würdest deiner Behauptung zumindest etwas Recherche angedeihen lassen. Wie viele Sicherheitsrelevante Bugs - die auch wirklich auszunutzen waren - gab es im gesamten Entwicklungszeitraum von systemd und welcher dieser Bugs wurde nicht zeitnah gefixt?
Er spielt vermutlich auf das inzwischen geänderte Verhalten von systemd an welches eintrat wenn in einem systemweiten Service-Unit, laut Meinung der systemd-Entwickler, ein "ungültiger" Benutzer angegeben wurde. Eine Designentscheidung welche ich ebenfalls als suboptimal angesehen habe aber trotzdem verstehe ich für meinen Teil unter einem Bug eigentlich etwas anderes.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 04. Okt 2017 um 11:06.
trotzdem verstehe ich für meinen Teil unter einem Bug eigentlich etwas anderes.
Wie bereits richtig erwähnt, ist dies eine Designentscheidung und kein Bug! Doch diese Möchtegern-Auskenner schrieben allerdings etwas von Sicherheitsrelevantem Bug und dazu hätte ich gern die Quellen.
That's exactly what happens, and what I wrote above: if the username is valid but the user doesn't exist we'll let the unit fail on start. If the username is already invalid syntax-wise we'll log about it but proceed.
Part of this behavior is actually documented in systemd.unit(5): "Unit files may contain additional options on top of those listed here. If systemd encounters an unknown option, it will write a warning log message but continue loading the unit."
Diese Studien -- beziehen die sich auf ein Jahr oder unterschiedliche Zeiträume oder die gesamte Projekrlaufzeit der Projekte?
Dann entwickel ich jetzt nämlich nen superntpd und mach sofort ne Studie bevor jemand eine Sicherheitslücke findet. Dann hab ich den sichersten Zeitserver entwickelt den es je gab.
OpenNTPD, ein Server und Client. http://www.openntpd.org. Die liefern auch ganz andere bekannte und weniger bekannte Software OpenSSH und libressl. Merkwürdig dass dieser nicht erwähnt wurde, vor allem ist das Paket in fast allen wichtigen RPM Repositories vorhanden.
> Projekt wird von Red Hat unterstützt und in den Red Hat-Produkten verwendet.
systemctl enable systemd-timesyncd.service
Wozu ein weiteres Projekt und wozu die Unterstützung in Red Hat, wenn sie eigens dafür das systemd entwickelt haben ? Da ist doch schon alles enthalten... Man braucht weder ntpd nachinstallieren bzw. chrony nutzen...
systemd-timesyncd ist ein SNTP-Client, kein NTP-Server.
Verwirr doch diese »ichbinLinuxexperteweilichUbuntuinstallierenkann« mit deinen richtigen Aussagen nicht.
Dieser Mensch war froh, dass er seinen Satz einigermaßen verständlich absetzen konnte.
Die Patricia, welche mit dem Feuer wirft?
Du übersiehst da wohl einen wichtigen Aspekt:
"Im Vergleich zu einem "echten" NTP-Server ist in diesem Dienst nur die Clientfunktionalität umgesetzt."
Quelle: Zeit per Systemd mit timesyncd synchronisieren
Und der Review nennt zumindest auch Fehler in der Serverkomponente.
Wer nur Clients betreibt und diese auch mit systemd, für den ist dein Vorschlag sicher eine Option. (Wobei der entsprechende Dienst von systemd im Zweifel noch nicht überprüft wurde.)
Ich wage auch zu bezweifeln das der systemd eine gute Wahl ist wenn Sicherheut relevant ist. Einfach weil die Art wie dort mit Sicherheitsfehlern umgegangen wird nicht gerade hinreichend Professionalität erwarten lässt.
Hallo, da möchte ich 100% zustimmen! In unserer Kölner LUG durfte ich mich dank genau dieser Argumente schon als Ewiggestriger anpöbeln lassen. Ich finde den Umgang mit Bugs wichtig, und die Entwickler von systemd haben sich hierbei bislang nicht mit Ruhm bekleckert
viele Grüße!
Du bist ein Ewiggestriger, denn sonst würdest deiner Behauptung zumindest etwas Recherche angedeihen lassen.
Wie viele Sicherheitsrelevante Bugs - die auch wirklich auszunutzen waren - gab es im gesamten Entwicklungszeitraum von systemd und welcher dieser Bugs wurde nicht zeitnah gefixt?
Und jetzt möchte ich bitte valide Quellen zu deiner Behauptung sehen!
Er spielt vermutlich auf das inzwischen geänderte Verhalten von systemd an welches eintrat wenn in einem systemweiten Service-Unit, laut Meinung der systemd-Entwickler, ein "ungültiger" Benutzer angegeben wurde. Eine Designentscheidung welche ich ebenfalls als suboptimal angesehen habe aber trotzdem verstehe ich für meinen Teil unter einem Bug eigentlich etwas anderes.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 04. Okt 2017 um 11:06.Wie bereits richtig erwähnt, ist dies eine Designentscheidung und kein Bug!
Doch diese Möchtegern-Auskenner schrieben allerdings etwas von Sicherheitsrelevantem Bug und dazu hätte ich gern die Quellen.
Ich weiß wirklich nicht wieso immer diese Aufregung um poettering. Es ist kein Bug in Systemd, weil das Verhalten so gewollt und dokumentiert ist.
https://github.com/systemd/systemd/issues/6237#issuecomment-312481714
https://github.com/systemd/systemd/issues/6237#issuecomment-312461325
Beweis durch Behauptung? Oder was soll das hier sein?
Diese Studien -- beziehen die sich auf ein Jahr oder unterschiedliche Zeiträume oder die gesamte Projekrlaufzeit der Projekte?
Dann entwickel ich jetzt nämlich nen superntpd und mach sofort ne Studie bevor jemand eine Sicherheitslücke findet. Dann hab ich den sichersten Zeitserver entwickelt den es je gab.
Das blöde ist nur dass IN dieser Studie die Fehler gefunden wurden nicht?
Ein Pentest bezieht sich meist auf das letzte Release oder die am häufigsten eingesetzte Version.
OpenNTPD, ein Server und Client. http://www.openntpd.org. Die liefern auch ganz andere bekannte und weniger bekannte Software OpenSSH und libressl. Merkwürdig dass dieser nicht erwähnt wurde, vor allem ist das Paket in fast allen wichtigen RPM Repositories vorhanden.
mfg
needle
Für zu Hause i. O., aber
https://en.wikipedia.org/wiki/OpenNTPD#Criticism
den letzten Satz mal lesen.
OMG!
Keine leap seconds!
Für den täglichen Gebrauch absolut unbrauchbar!
Da verpasse ich ja den Bus!
LOL!
Falsch. Due hast den Bus bereits verpasst!