Re: [systemd-devel] How do I easily resolve conflicting jobs in custom units?
23.03.2017 18:44, John Florian пишет: > On Thu, 2017-03-23 at 06:38 +0300, Andrei Borzenkov wrote: >> 22.03.2017 23:47, John Florian пишет: >>> I build an mostly-stateless appliance OS derived from Fedora (25 >>> ATM) >>> and have several custom units to make it all possible. My units >>> had >>> worked great with F21, but are now giving me problems with >>> F25. One >>> pair of the custom units do some trickery to relocate sshd host >>> keys >>> from /etc/ssh to an alternate location that provides persistence: >>> >>> >> >> Please make full log available as well as actual unit definitions >> that >> are not started. >> > > Okay, attached are a complete boot.log (journalctl > boot.log) as well > as the most relevant units. Please note that while I need a solution, > it's just as important I understand HOW to resolve this kind of issue. > I've struggled through similar problems in the past and I never feel > adept at the process, like I'm not using a fundamental tool for the job > and instead relying more on trial and error. > > While there's no doubt a lot of change between F21 and F25, the one I do not use Fedora. You still did not show definitions of units that have problem: sshd.service, sshd-keygen.target, sshd.socket. Providing output of systemctl show sshd.service sshd-keygen.target sshd.socket is probably better as it dumps full information. > thing that forced a change on my part was systemd transitioning from a > single sshd-keygen.service to a templated sshd-keygen@.service. For me > that meant the following change: > > diff --git lib/systemd/sshd-persist-keys.service lib/systemd/sshd- > persist-keys.service > index d3508a8..7500b68 100644 > --- lib/systemd/sshd-persist-keys.service > +++ lib/systemd/sshd-persist-keys.service > @@ -1,8 +1,8 @@ > [Unit] > Description=OpenSSH server - persist volatile keys for the AOS > -After=sshd-keygen.service > +After=sshd-keygen.target > Before=sshd.service > -Wants=sshd-keygen.service > +Wants=sshd-keygen.target > > [Service] > ExecStart=/usr/sbin/sshd-persist-keys > diff --git lib/systemd/sshd-restore-keys.service lib/systemd/sshd- > restore-keys.service > index 475cede..85ac3bc 100644 > --- lib/systemd/sshd-restore-keys.service > +++ lib/systemd/sshd-restore-keys.service > @@ -1,7 +1,7 @@ > [Unit] > Description=OpenSSH server - restore persisted keys for the AOS > After=aos-storage-init.service > -Before=sshd-keygen.service > +Before=sshd-keygen@rsa.service sshd-keygen@ecdsa.service sshd-keygen@e > d25519.service > > [Service] > ExecStart=/usr/sbin/sshd-restore-keys > > > I'd love to know of a better way for my sshd-restore-kes.service to be > coded such that it's unnecessary to list individual key types, but my > experience has led me to believe that targets only define a point in > time when a collection of units have completed and that there's no > equivalent to a point in time prior to any of them having begun. Thus > I found I couldn't use Before=sshd-keygen.target because keys were > being generated and restored concurrently rather than serially > (restored if possible and then the missing generated as needed). > ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How do I easily resolve conflicting jobs in custom units?
On Thu, 2017-03-23 at 06:38 +0300, Andrei Borzenkov wrote: > 22.03.2017 23:47, John Florian пишет: > > I build an mostly-stateless appliance OS derived from Fedora (25 > > ATM) > > and have several custom units to make it all possible. My units > > had > > worked great with F21, but are now giving me problems with > > F25. One > > pair of the custom units do some trickery to relocate sshd host > > keys > > from /etc/ssh to an alternate location that provides persistence: > > > > > > Please make full log available as well as actual unit definitions > that > are not started. > Okay, attached are a complete boot.log (journalctl > boot.log) as well as the most relevant units. Please note that while I need a solution, it's just as important I understand HOW to resolve this kind of issue. I've struggled through similar problems in the past and I never feel adept at the process, like I'm not using a fundamental tool for the job and instead relying more on trial and error. While there's no doubt a lot of change between F21 and F25, the one thing that forced a change on my part was systemd transitioning from a single sshd-keygen.service to a templated sshd-keygen@.service. For me that meant the following change: diff --git lib/systemd/sshd-persist-keys.service lib/systemd/sshd- persist-keys.service index d3508a8..7500b68 100644 --- lib/systemd/sshd-persist-keys.service +++ lib/systemd/sshd-persist-keys.service @@ -1,8 +1,8 @@ [Unit] Description=OpenSSH server - persist volatile keys for the AOS -After=sshd-keygen.service +After=sshd-keygen.target Before=sshd.service -Wants=sshd-keygen.service +Wants=sshd-keygen.target [Service] ExecStart=/usr/sbin/sshd-persist-keys diff --git lib/systemd/sshd-restore-keys.service lib/systemd/sshd- restore-keys.service index 475cede..85ac3bc 100644 --- lib/systemd/sshd-restore-keys.service +++ lib/systemd/sshd-restore-keys.service @@ -1,7 +1,7 @@ [Unit] Description=OpenSSH server - restore persisted keys for the AOS After=aos-storage-init.service -Before=sshd-keygen.service +Before=sshd-keygen@rsa.service sshd-keygen@ecdsa.service sshd-keygen@e d25519.service [Service] ExecStart=/usr/sbin/sshd-restore-keys I'd love to know of a better way for my sshd-restore-kes.service to be coded such that it's unnecessary to list individual key types, but my experience has led me to believe that targets only define a point in time when a collection of units have completed and that there's no equivalent to a point in time prior to any of them having begun. Thus I found I couldn't use Before=sshd-keygen.target because keys were being generated and restored concurrently rather than serially (restored if possible and then the missing generated as needed). sshd-startup-failure.tar.gz Description: application/compressed-tar ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] sd-bus connections & authentication timeout
On Mon, 20 Mar 2017 at 19:40:04 +0100, Stanislav Angelovič wrote: > Regarding polling, I understand, but I fear this way we could get race > condition on the connection instance, since we'd have a thread doing the > polling and processing in a loop on the connection, and some other thread (say > handling the UI, or an external system event, or incoming DBus call from > another connection or whatever else) issuing a DBus call on the same > connection. Don't do this. The sd-bus connection is not designed to be safe to access from multiple threads. If you need thread-safe D-Bus, then you will need a design where one thread "dispatches" the D-Bus connection (with sd-event or the GLib main loop or whatever abstraction around epoll/poll/select you prefer), and all other threads submit requests to it and get events back from it. This is essentially what GLib's GDBus does - all the public APIs just submit requests to a worker thread that is not directly accessible by user code. libdbus (the reference implementation of D-Bus) did try to support the situation you are concerned about, but doing that turns out to be basically unmaintainable; we've fixed the worst issues, but it has never been very reliable, and we strongly recommend not doing it. For best results, choose either always-threaded (GDBus' design) or never-threaded (sd-bus' design, and also the recommended pattern for libdbus for the last few years) and stick to it. > This involves asynchronous programming paradigm for quite a simple > thing, IMHO. D-Bus is fundamentally an asynchronous message-passing system, in the same sorts of ways that X11, Wayland and most network protocols are. If asynchronous message passing is not acceptable to you, then D-Bus is probably not going to be the right solution to your requirements. If you stop reading from your D-Bus socket, the dbus-daemon will eventually have to disconnect you, because it cannot distinguish between that and a denial of service attack. The timeout that you encountered is precisely there to stop malicious processes from carrying out a denial of service attack on the system dbus-daemon instance by tying up all of its file descriptors with unauthenticated connections, and there are similar limits to stop a malicious process from carrying out a DoS attack on the system dbus-daemon instance by making it consume unbounded amounts of memory. In general we put these arbitrary limits in for good reasons, not just to make your life difficult :-) In this case the relevant security vulnerability was CVE-2014-3639. S ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-journald: prioritize system log over user log
On 03/23/2017 06:29 PM, Michael Chapman wrote: On Thu, 23 Mar 2017, Yunchih Chen wrote: Hello: At my organization, there can be hundreds of user logins in a public workstation each day, among more than one thousand of users. Since each user login produces a 8MiB sparse log file in /var/log/journal/x/, significant disk space is consumed. From the administrator point of view, it is desirable to prioritize system log over user log. For example, when total log size exceeds SystemMaxUse, user log is vacuumed / rotated before system log. Can we achieve this goal under current implementation? I don't think journald has support for that itself currently. Have you considered using SplitMode=none in journald.conf? If you do that the per-UID journal files will not be created. Instead, all messages will go into the system journal. Of course, using SplitMode=none does mean unprivileged users probably won't be able to view their own logs, but it does mean you won't get this per-UID overhead. Thanks for your reply. But we actually intend to let users view their own logs and we don't like to pollute system log with user log. Maybe consider my original proposal as a feature request? Regards, -- -- Yun-Chih Chen 陳耘志 Network/Workstation Assistant Dept. of Computer Science and Information Engineering National Taiwan University Tel: +886-2-33664888 ext. 217/204 Email: ta...@csie.ntu.edu.tw Website: http://wslab.csie.ntu.edu.tw/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-journald: prioritize system log over user log
On Thu, 23 Mar 2017, Yunchih Chen wrote: Hello: At my organization, there can be hundreds of user logins in a public workstation each day, among more than one thousand of users. Since each user login produces a 8MiB sparse log file in /var/log/journal/x/, significant disk space is consumed. From the administrator point of view, it is desirable to prioritize system log over user log. For example, when total log size exceeds SystemMaxUse, user log is vacuumed / rotated before system log. Can we achieve this goal under current implementation? I don't think journald has support for that itself currently. Have you considered using SplitMode=none in journald.conf? If you do that the per-UID journal files will not be created. Instead, all messages will go into the system journal. Of course, using SplitMode=none does mean unprivileged users probably won't be able to view their own logs, but it does mean you won't get this per-UID overhead. -- Michael ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd-journald: prioritize system log over user log
Hello: At my organization, there can be hundreds of user logins in a public workstation each day, among more than one thousand of users. Since each user login produces a 8MiB sparse log file in /var/log/journal/x/, significant disk space is consumed. From the administrator point of view, it is desirable to prioritize system log over user log. For example, when total log size exceeds SystemMaxUse, user log is vacuumed / rotated before system log. Can we achieve this goal under current implementation? I guess the size of pre-allocation (in my case, 8MiB), is probably determined platform-wise. Here[1] I include some relevant platform info that might aids debugging. Many thanks! [1] https://www.csie.ntu.edu.tw/~yunchih/s/systemd-journald-sample-output.log -- Yun-Chih Chen 陳耘志 Network/Workstation Assistant Dept. of Computer Science and Information Engineering National Taiwan University Tel: +886-2-33664888 ext. 217/204 Email: ta...@csie.ntu.edu.tw Website: http://wslab.csie.ntu.edu.tw/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
