Re: [systemd-devel] offline updates
On Tue, 2015-07-21 at 03:27 +, Zbigniew Jędrzejewski-Szmek wrote: fedup-system-upgrade.service uses an additional flag file which is checked with ConditionPathExists so it will not run if 'dnf fedup reboot' did not create the flag, even if we go into system-upgrade.target. packagekit-offline-update.service does not have anything like this, and is always run in system-upgrade.target. Strange - from what I can tell from the source, pk-offline-update is supposed to bail out unless the update was prepared by PackageKit itself[1]? Perhaps your system was also trying to install new updates via PackageKit at the time? Maybe packagekit-offline-update.service also needs a ConditionPathExists.. Running two upgrade mechanisms in parallel does not seem like a good idea. (Even if they use a lock file to prevent concurrent access to the rpm database, they are bound to interfere with one another: the first finishes and decides to reboot, or the first updates some packages and messes up the state for the second one...) It seems that *some* mechanism to run only one upgrade mechanism is wanted. The approach that dnf-plugin-fedup uses seems reasonable: it creates the file only when a reboot with 'dnf fedup reboot' is requested. As an alternative we could allow only one upgrade mechanism to be enabled. Dunno. How would that be enforced, though? Special handling for system -updates.target? Or: does systemd need some convention/support for handling the general problem of choosing one of multiple (mutually-exclusive) services that provide the same functionality? Also, which is a minor thing, but related: OnFailure=reboot.target seems inferior to FailureAction=reboot. IIRC, the second one uses irreversible transaction and should be more robust. It also is a higher level setting in some sense. OnFailure=reboot.target is taken directly from the spec, so should be changed there first. I'll add a note about this to the fedup-system-upgrade.service, I guess, and if the spec changes I'll change it there too. So maybe tmpfiles snippet should be used to remove the link. Such a change would mean that the update services should not depend on the symlink being present, and should instead look for their installation data in their own state directory. Right - this is what dnf-plugin-fedup does, since pk-offline-update might run first and remove the symlink before we get there. To summarize, following changes to the spec are proposed: - use Condition* or similar to conditionalize whether a specific upgrade mechanism should run - use Action=reboot FailureAction=reboot, I guess? - use Type=oneshot This is the default, correct? Should it be explicitly listed in the unit file, or should I rely on the default behavior? - check that logind.Reboot() is not called on failure by the service - services should not look for /systemd-update symlink, and the symlink should be removed by tmpfiles before we even get to the upgrade. These all seem reasonable to me. I'll happily make changes to dnf -plugin-fedup to follow any changes to the spec, once consensus is reached and the spec is changed. Thanks for testing this! -w [1] https://github.com/hughsie/PackageKit/blob/PACKAGEKIT_1_0_7/client/ pk-offline-update.c#L404 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to properly write an umbrella unit
Have a look at the openvpn package in Debian. It implements something like you have in mind. There are multiple openvpn@.service instances and a single openvpn.service which can be used by the admin to start/stop/restart them. 2015-07-21 13:43 GMT+02:00 Marc Haber mh+systemd-de...@zugschlus.de: Hi, I am trying to systemd'ize a daemon which is useful to be run in two instances. It is usually the case that both instances need to be started and stopped simultaneously, and the local admin would want a _single_ command to start and stop both instances. Therefore, an umbrella is needed. As a beginner, I have written: nifty.target: [Unit] Description=nifty Server (all protocols) After=network.target [Install] WantedBy=multi-user.target nifty-v4.service: [Unit] Description=nifty Server for IPv4 (niftyd4.conf) After=network.target PartOf=nifty.target [Service] ExecStart=/usr/sbin/niftyd -f -4 -q -cf /etc/nifty/niftyd4.conf [Install] WantedBy=nifty.target nifty-v6.service: [Unit] Description=nifty Server for IPv6 After=network.target PartOf=nifty.target [Service] ExecStart=/usr/sbin/niftyd -f -6 -q -cf /etc/nifty/niftyd6.conf [Install] WantedBy=nifty.target This works as designed. Unfortunately, my Distribution's build tools don't handle package-provided targets too well, and I feel that using a target here is kind of wrong anyway. Can I write my nifty.target as a service? I have seen in this case nifty.service files with Exec=/bin/true to basically create a no-op service, but that's ugly. If I move my service to a nifty@.service, how would I start two instances from a single shell command? How would one handle this situation in the clear, recommended way? Greetings Marc -- - Marc Haber | I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things.Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to properly write an umbrella unit
On Tue, Jul 21, 2015 at 02:20:39PM +0100, Dimitri John Ledkov wrote: And then people can do e.g.: systemctl enable nifty@4.service nifty@6.service systemctl start nifty@*.service systemctl stop nifty@*.service As I mentioned in my original mail, this is explictly not wanted, as most users will have to start and stop both instances together. We cannot make our lives simpler at the cost of our users. And yes, this is true for both systemd upstream and software packagers, a transitive relationship. Greetings Marc -- - Marc Haber | I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things.Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] offline updates
On Tue, Jul 21, 2015 at 03:00:39PM -0400, Will Woods wrote: On Tue, 2015-07-21 at 03:27 +, Zbigniew Jędrzejewski-Szmek wrote: fedup-system-upgrade.service uses an additional flag file which is checked with ConditionPathExists so it will not run if 'dnf fedup reboot' did not create the flag, even if we go into system-upgrade.target. packagekit-offline-update.service does not have anything like this, and is always run in system-upgrade.target. Perhaps your system was also trying to install new updates via PackageKit at the time? This seems to be a likely explanation. This VM had a graphical environment installed at some point, so maybe there was a pending update scheduled. Next time I'll try to test in a pristine environment ;) Strange - from what I can tell from the source, pk-offline-update is supposed to bail out unless the update was prepared by PackageKit itself[1]? You're right, it the code seems to do that. But there's still a problem: if the update is started, action is set to e.g. PK_OFFLINE_ACTION_REBOOT, and then an error occurs, pk_offline_update_reboot() will be called in line 466. This should be easy enough to fix: https://github.com/hughsie/PackageKit/pull/72 Maybe packagekit-offline-update.service also needs a ConditionPathExists.. Let's see... If dnf fedup scheduled an offline update, packagekit-offline-update.service would run too. It would look for it's state files, not find them, and return with an error. systemd would treat this as a signal to start reboot.target. Yikes, indeed, this cannot work in current version. (Based on this, a new proposal below.) Running two upgrade mechanisms in parallel does not seem like a good idea. (Even if they use a lock file to prevent concurrent access to the rpm database, they are bound to interfere with one another: the first finishes and decides to reboot, or the first updates some packages and messes up the state for the second one...) It seems that *some* mechanism to run only one upgrade mechanism is wanted. The approach that dnf-plugin-fedup uses seems reasonable: it creates the file only when a reboot with 'dnf fedup reboot' is requested. As an alternative we could allow only one upgrade mechanism to be enabled. Dunno. How would that be enforced, though? Special handling for system -updates.target? Or: does systemd need some convention/support for handling the general problem of choosing one of multiple (mutually-exclusive) services that provide the same functionality? One can play with Alias=, but I don't think this is applicable here, because we want something dynamic: even if I have packagekit-offline-update.service enabled to run updates from gnome, it should not preclude me from running 'dnf fedup' to update the system. So a solution might be to use /system-update as a flag: updater service should run, look for /system-update, and if it is missing or does not point to it's own cache, do nothing and return 0. If it points at its own cache, try to run an update, and either schedule a reboot/shutdown at the end, or return an error. Also, which is a minor thing, but related: OnFailure=reboot.target seems inferior to FailureAction=reboot. IIRC, the second one uses irreversible transaction and should be more robust. It also is a higher level setting in some sense. OnFailure=reboot.target is taken directly from the spec, so should be changed there first. I'll add a note about this to the fedup-system-upgrade.service, I guess, and if the spec changes I'll change it there too. I prepared a patch locally, and I'll send a pull request if the spec is updated. So maybe tmpfiles snippet should be used to remove the link. Such a change would mean that the update services should not depend on the symlink being present, and should instead look for their installation data in their own state directory. Right - this is what dnf-plugin-fedup does, since pk-offline-update might run first and remove the symlink before we get there. I think that running two system updates concurrently or sequentially is risky. I think only one update should be allowed to be scheduled and to run. To summarize, following changes to the spec are proposed: - use Condition* or similar to conditionalize whether a specific upgrade mechanism should run - use Action=reboot FailureAction=reboot, I guess? Right. - use Type=oneshot This is the default, correct? Should it be explicitly listed in the unit file, or should I rely on the default behavior? No, the default it Type=simple. - check that logind.Reboot() is not called on failure by the service - services should not look for /systemd-update symlink, and the symlink should be removed by tmpfiles before we even get to the upgrade. These all seem reasonable to me. I'll happily make changes to dnf -plugin-fedup to follow any changes to the spec, once consensus is reached and the spec is changed.
Re: [systemd-devel] Use of capabilities in default service files
On 07/20/2015 02:34 PM, Reindl Harald wrote: Am 20.07.2015 um 13:58 schrieb Florian Weimer: On 07/20/2015 01:52 PM, Reindl Harald wrote: Am 20.07.2015 um 13:24 schrieb Florian Weimer: CapabilityBoundingSet=CAP_IPC_OWNER CAP_SETUID CAP_SETGID CAP_SETPCAP m4_ifdef(`HAVE_SMACK', CAP_MAC_ADMIN ) … What's the intent of these settings? Is it a form of hardening? If yes, it is rather ineffective because UID=0 does not need any capabilities to completely compromise the system. UID=0 *does* need capabilities, drwxr-xr-x. 2 root root 37 Jun 13 10:09 /etc/cron.d -rw-r--r--. 1 root root 3068 Jul 17 19:47 /etc/passwd UID=0 without CAP_DAC_OVERRIDE (or any other capabilities) can write to these locations and escalate fairly directly to full root. why should it need CAP_DAC_OVERRIDE when it *owns* the files and has write permissions? Exactly, it's the reason why I suspect something fishy is going on if people to harden services running UID=0 by taking away capabilities. chown the file to a different user and root no longer can write there to protect /etc and /usr ReadOnlyDirectories is the way to go ReadOnlyDirectories=/etc ReadOnlyDirectories=/usr Then you still have instant root through: drwx--. 2 root root 20 Feb 3 12:36 /var/spool/cron/ I found the “CapabilityBoundingSet=” line (empty set) somewhat worrying, it seems to me that this service should use a separate UID, not 0 that's a different story and works for services wich don't need to read files only readable by root and not listening on privileged ports like mysqld and in that case even if there is a root exploit CapabilityBoundingSet would reduce the damage [Service] Type=simple User=mysql Group=mysql And that's fine. But doing hardening for UID=0 services seems a very bad practice to me because it looks like someone is assuming that UID=0 without capabilities is just another “nobody” user. Which is not surprising, because capabilities are often advertised that way. -- Florian Weimer / Red Hat Product Security ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] sd-bus object manager question
Hi
On Mon, Jul 20, 2015 at 9:26 PM, David Härdeman da...@hardeman.nu wrote:
On Sat, Jun 27, 2015 at 09:22:45AM +0200, David Härdeman wrote:
On Thu, Jun 25, 2015 at 04:25:29PM +0200, David Herrmann wrote:
On Tue, Jun 23, 2015 at 2:41 PM, David Härdeman da...@hardeman.nu wrote:
...
Now, a question...how is an object manager supposed to be implemented in
sd-bus?
I've seen that there's a sd_bus_add_object_manager() function in sd-bus.h,
but how would I notify the object manager when objects are added and
removed?
Two likely candidates seemed to be:
sd_bus_emit_object_added()
sd_bus_emit_object_removed()
But calling them did not seem to do the right thing. And there seems to be
zero usage of sd_bus_add_object_manager() in the systemd tree itself
(though
plenty of calls to sd_bus_add_node_enumerator() which might be related?).
Not sure where the confusion is. Those calls generate the
InterfacesAdded/Removed signals that the objectmanager API specifies.
They collect the interfaces based on the vtables you registered on a
given path. have a look at test-bus-objects.c which uses these
interfaces.
I've done some more experimentation and I think I've got a better idea
of what's going on. Sorry if my first email was a bit confusing.
My problem is that I couldn't get the sd-bus object manager to properly
notify clients when objects are added or removed.
I'm testing my sd-bus server with a gdbus client. The
GDBusObjectManagerClient should normally generate signals (gobject
signals, that is) when objects are added or removed.
Anyway, I tried implementing an object manager server with gdbus as
well, and when talking to the gdbus server, the client is notified of
object additions/removals, so I used used busctl to monitor the signals
that were generated. I think I've found the problem.
Assume there's an object manager at /org/example/mgr and that a new
object is created at /org/example/mgr/object1.
With sd-bus, I'd call:
sd_bus_emit_object_added(bus, /org/example/mgr/object1);
The generated signal would be:
‣ Type=signal Endian=l Flags=1 Version=1 Priority=0 Cookie=11
Sender=:1.297 Path=/org/example/mgr/object1
Interface=org.freedesktop.DBus.ObjectManager Member=InterfacesAdded
UniqueName=:1.297
MESSAGE oa{sa{sv}} {
OBJECT_PATH /org/example/mgr/object1;
With gdbus, the generated signal is instead:
The generated signal would be:
‣ Type=signal Endian=l Flags=1 Version=1 Priority=0 Cookie=21
Sender=:1.297 Path=/org/example/mgr
Interface=org.freedesktop.DBus.ObjectManager Member=InterfacesAdded
UniqueName=:1.297
MESSAGE oa{sa{sv}} {
OBJECT_PATH /org/example/mgr/object1;
Note the difference in the sender path.
The GDBusObjectManagerClient seems to ignore the signal sd-bus generates
because of the different path.
I think that means that sd_bus_emit_object_added() would need to take
both the object manager path and the object path as arguments instead of
a single path?
Ping?
Thanks for the reminder, almost forgot about this. And sorry for the
delay, many of us are on vacation right now, and the remaining few
have a hard time keeping up with reports.
I pushed a fix here:
https://github.com/systemd/systemd/pull/641
I'd prefer if we can move this discussion to github.
Thanks
David
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] How to properly write an umbrella unit
Hi, I am trying to systemd'ize a daemon which is useful to be run in two instances. It is usually the case that both instances need to be started and stopped simultaneously, and the local admin would want a _single_ command to start and stop both instances. Therefore, an umbrella is needed. As a beginner, I have written: nifty.target: [Unit] Description=nifty Server (all protocols) After=network.target [Install] WantedBy=multi-user.target nifty-v4.service: [Unit] Description=nifty Server for IPv4 (niftyd4.conf) After=network.target PartOf=nifty.target [Service] ExecStart=/usr/sbin/niftyd -f -4 -q -cf /etc/nifty/niftyd4.conf [Install] WantedBy=nifty.target nifty-v6.service: [Unit] Description=nifty Server for IPv6 After=network.target PartOf=nifty.target [Service] ExecStart=/usr/sbin/niftyd -f -6 -q -cf /etc/nifty/niftyd6.conf [Install] WantedBy=nifty.target This works as designed. Unfortunately, my Distribution's build tools don't handle package-provided targets too well, and I feel that using a target here is kind of wrong anyway. Can I write my nifty.target as a service? I have seen in this case nifty.service files with Exec=/bin/true to basically create a no-op service, but that's ugly. If I move my service to a nifty@.service, how would I start two instances from a single shell command? How would one handle this situation in the clear, recommended way? Greetings Marc -- - Marc Haber | I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things.Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to properly write an umbrella unit
Le mardi 21 juillet 2015, 13:43:48 Marc Haber a écrit : This works as designed. Unfortunately, my Distribution's build tools don't handle package-provided targets too well, and I feel that using a target here is kind of wrong anyway. Hi, Package-provided targets works well, but by default debhelper will try to enable everything. You'd need to overide dh_systemd_enable dh_systemd_start: https://sources.debian.net/src/systemd-cron/1.5.2-1/debian/rules/ | override_dh_systemd_enable: | # Only enable cron.target, it pulls in all the others via .timer files. | dh_systemd_enable cron.target | | override_dh_systemd_start: | # Only start cron.target, it pulls in all the others via .timer files. | dh_systemd_start cron.target Can I write my nifty.target as a service? I have seen in this case nifty.service files with Exec=/bin/true to basically create a no-op service, but that's ugly. PostgreSQL does that for some reason: https://sources.debian.net/src/postgresql-common/169/systemd/postgresql.service/ How would one handle this situation in the clear, recommended way? Can't help for this. Greets, Alexandre ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Does socket activation block a TCP port for listening by other processes?
We have quite a zoo of services which listen on localhost, on a fixed TCP port, for use by local clients. The canonical example is PostgreSQL on 5432/TCP, for the benefit of Java clients (which cannot use the UNIX domain socket). This has the obvious issue that if a local attacker crashes the service, they can impersonate it by binding to the same port. Does socket activation reliably prevent such impersonation attacks? Or is there race, say during systemd configuration reloading or service restarts, where systemd temporarily does not listen to that port? -- Florian Weimer / Red Hat Product Security ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Does socket activation block a TCP port for listening by other processes?
Hi On Tue, Jul 21, 2015 at 1:37 PM, Florian Weimer fwei...@redhat.com wrote: We have quite a zoo of services which listen on localhost, on a fixed TCP port, for use by local clients. The canonical example is PostgreSQL on 5432/TCP, for the benefit of Java clients (which cannot use the UNIX domain socket). This has the obvious issue that if a local attacker crashes the service, they can impersonate it by binding to the same port. Does socket activation reliably prevent such impersonation attacks? Or is there race, say during systemd configuration reloading or service restarts, where systemd temporarily does not listen to that port? This race *does* exist with socket activation. The sockets may be re-created if the unit transitions between states (like restart). However, this is only triggered by actions on the socket-unit, not the actually activated unit. A crash of the activated service will thus not trigger state-changes on the socket-unit. Furthermore, we do not treat occupying a resource as security mechanism. If an attacker has access to bind such a port, we do not place restrictions to prevent that. Instead, you should place LSM restrictions to prevent this. And please note, the actual activated unit usually does *not* have rights to bind the socket. This is done by pid1. So an attacker would require rights of PID1 for such an attack. Thanks David ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Changing configure.ac to make LTO optional.
Hi On Mon, Jul 20, 2015 at 4:56 PM, Kinsella, Ray ray.kinse...@intel.com wrote: There is a bug in GCC LTO such that it ignores assembler directives. This patch makes LTO enabled by default but also allows it to be disabled if required. See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47785 This is a gcc bug. They better fix it and backport it to stable. We do not work around bugs in other software, unless they explicitly state why it is not fixed in stable releases. I cannot see a statement why this bug is unhandled since _2011_. If gcc developers reject to respond to bug-reports, why do distributions compile gcc with LTO enabled? Anyway, why don't you use this workaround instead: ./configure CFLAGS=$CFLAGS -flto=n *confused* David --- configure.ac | 17 - 1 file changed, 12 insertions(+), 5 deletions(-) diff --git a/configure.ac b/configure.ac index 999f9f8..294c440 100644 --- a/configure.ac +++ b/configure.ac @@ -194,11 +194,18 @@ AS_CASE([$CC], [*clang*], -Wno-gnu-variable-sized-type-not-at-end \ ])]) -AS_CASE([$CFLAGS], [*-O[[12345sz\ ]]*], -[CC_CHECK_FLAGS_APPEND([with_cflags], [CFLAGS], [\ - -flto -ffat-lto-objects])], -[AC_MSG_RESULT([skipping -flto, optimization not enabled])]) -AC_SUBST([OUR_CFLAGS], $with_cflags $sanitizer_cflags) +AC_ARG_ENABLE(lto, +[AS_HELP_STRING([--enable-lto], [Enable link time optimization])], + enable_lto=$enableval, + enable_lto=yes; default_enable_lto=yes) + +if test x$enable_lto != xno; then +AS_CASE([$CFLAGS], [*-O[[12345sz\ ]]*], +[CC_CHECK_FLAGS_APPEND([with_cflags], [CFLAGS], [\ +-flto -ffat-lto-objects])], +[AC_MSG_RESULT([skipping -flto, optimization not enabled])]) +AC_SUBST([OUR_CFLAGS], $with_cflags $sanitizer_cflags) +fi AS_CASE([$CFLAGS], [*-O[[12345sz\ ]]*], [CC_CHECK_FLAGS_APPEND([with_cppflags], [CPPFLAGS], [\ -- 2.1.0 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to properly write an umbrella unit
On Tue, Jul 21, 2015 at 01:40:31PM +0100, Colin Guthrie wrote: In this case, I'd perhaps recommend NOT including [Install] sections fir your two .service files and instead make your make install action write symlinks into /usr/lib/systemd/system/nifty.target.wants.d/ thus the user could never disable the individual components of your daemon themselves and thus not need to rely on distro scripts to create them at install time. No, I'd like to give the local admin an option to disable parts of course. My work is about choice and robustness. Greetings Marc -- - Marc Haber | I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things.Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to properly write an umbrella unit
Hi Alexandre, thanks for your fast answer and correctly guessing my Distribution ,-) On Tue, Jul 21, 2015 at 02:13:12PM +0200, Alexandre Detiste wrote: Le mardi 21 juillet 2015, 13:43:48 Marc Haber a écrit : This works as designed. Unfortunately, my Distribution's build tools don't handle package-provided targets too well, and I feel that using a target here is kind of wrong anyway. Hi, Package-provided targets works well, but by default debhelper will try to enable everything. In my case, dh_systemd_enable doesn't install the file: dh_systemd_enable --verbose -pisc-dhcp-server --name=isc-dhcp-server.target echo # Automatically added by dh_systemd_enable debian/isc-dhcp-server.postinst.debhelper sed s/#UNITFILE#/isc-dhcp-server-v6.service/ /usr/share/debhelper/autoscripts/postinst-systemd-enable debian/isc-dhcp-server.postinst.debhelper echo '# End automatically added section' debian/isc-dhcp-server.postinst.debhelper echo # Automatically added by dh_systemd_enable debian/isc-dhcp-server.postinst.debhelper sed s/#UNITFILE#/isc-dhcp-server-v4.service/ /usr/share/debhelper/autoscripts/postinst-systemd-enable debian/isc-dhcp-server.postinst.debhelper echo '# End automatically added section' debian/isc-dhcp-server.postinst.debhelper echo # Automatically added by dh_systemd_enable debian/isc-dhcp-server.postinst.debhelper sed s/#UNITFILE#/isc-dhcp-server-v4-old.service/ /usr/share/debhelper/autoscripts/postinst-systemd-enable debian/isc-dhcp-server.postinst.debhelper echo '# End automatically added section' debian/isc-dhcp-server.postinst.debhelper echo # Automatically added by dh_systemd_enable debian/isc-dhcp-server.postrm.debhelper.new sed s/#UNITFILES#/isc-dhcp-server-v6.service isc-dhcp-server-v4.service isc-dhcp-server-v4-old.service/ /usr/share/debhelper/autoscripts/postrm-systemd debian/isc-dhcp-server.postrm.debhelper.new echo '# End automatically added section' debian/isc-dhcp-server.postrm.debhelper.new cat debian/isc-dhcp-server.postrm.debhelper debian/isc-dhcp-server.postrm.debhelper.new mv debian/isc-dhcp-server.postrm.debhelper.new debian/isc-dhcp-server.postrm.debhelper (grep -s -v misc:Depends debian/isc-dhcp-server.substvars; echo misc:Depends=debconf (= 0.5) | debconf-2.0, init-system-helpers (= 1.18~)) debian/isc-dhcp-server.substvars.new mv debian/isc-dhcp-server.substvars.new debian/isc-dhcp-server.substvars dh_installinit -Nisc-dhcp-server install -d debian/isc-dhcp-relay/etc/init.d install -p -m755 debian/isc-dhcp-relay.init.d debian/isc-dhcp-relay/etc/init.d/isc-dhcp-relay echo # Automatically added by dh_installinit debian/isc-dhcp-relay.postinst.debhelper sed s/#SCRIPT#/isc-dhcp-relay/;s/#INITPARMS#/defaults/;s/#ERROR_HANDLER#/exit \$?/ /usr/share/debhelper/autoscripts/postinst-init debian/isc-dhcp-relay.postinst.debhelper echo '# End automatically added section' debian/isc-dhcp-relay.postinst.debhelper echo # Automatically added by dh_installinit debian/isc-dhcp-relay.prerm.debhelper sed s/#SCRIPT#/isc-dhcp-relay/;s/#INITPARMS#/defaults/;s/#ERROR_HANDLER#/exit \$?/ /usr/share/debhelper/autoscripts/prerm-init debian/isc-dhcp-relay.prerm.debhelper echo '# End automatically added section' debian/isc-dhcp-relay.prerm.debhelper echo # Automatically added by dh_installinit debian/isc-dhcp-relay.postrm.debhelper.new sed s/#SCRIPT#/isc-dhcp-relay/;s/#INITPARMS#/defaults/;s/#ERROR_HANDLER#/exit \$?/ /usr/share/debhelper/autoscripts/postrm-init debian/isc-dhcp-relay.postrm.debhelper.new echo '# End automatically added section' debian/isc-dhcp-relay.postrm.debhelper.new cat debian/isc-dhcp-relay.postrm.debhelper debian/isc-dhcp-relay.postrm.debhelper.new mv debian/isc-dhcp-relay.postrm.debhelper.new debian/isc-dhcp-relay.postrm.debhelper dh_installinit -pisc-dhcp-server --error-handler=true #dh_systemd_start isc-dhcp-server.target and dh_systemd_enable's code specialcasing service, socket, and tmpfile, but not target, gave me the impression that target files are unsupported. My debian/rules is: override_dh_installinit: dh_systemd_enable -pisc-dhcp-server --name=isc-dhcp-server-v4 dh_systemd_enable -pisc-dhcp-server --name=isc-dhcp-server-v4-old dh_systemd_enable -pisc-dhcp-server --name=isc-dhcp-server-v6 dh_systemd_enable --verbose -pisc-dhcp-server --name=isc-dhcp-server.target dh_installinit -Nisc-dhcp-server dh_installinit -pisc-dhcp-server --error-handler=true what is wrong here? (if this is off-topic in systemd-devel, which I suspect, please feel free to reply in private mail instead). Greetings Marc -- - Marc Haber | I don't trust Computers. They |
Re: [systemd-devel] How to properly write an umbrella unit
Marc Haber wrote on 21/07/15 12:43: Hi, I am trying to systemd'ize a daemon which is useful to be run in two instances. It is usually the case that both instances need to be started and stopped simultaneously, and the local admin would want a _single_ command to start and stop both instances. Therefore, an umbrella is needed. As a beginner, I have written: nifty.target: [Unit] Description=nifty Server (all protocols) After=network.target [Install] WantedBy=multi-user.target nifty-v4.service: [Unit] Description=nifty Server for IPv4 (niftyd4.conf) After=network.target PartOf=nifty.target [Service] ExecStart=/usr/sbin/niftyd -f -4 -q -cf /etc/nifty/niftyd4.conf [Install] WantedBy=nifty.target nifty-v6.service: [Unit] Description=nifty Server for IPv6 After=network.target PartOf=nifty.target [Service] ExecStart=/usr/sbin/niftyd -f -6 -q -cf /etc/nifty/niftyd6.conf [Install] WantedBy=nifty.target This works as designed. Unfortunately, my Distribution's build tools don't handle package-provided targets too well, and I feel that using a target here is kind of wrong anyway. In this case, I'd perhaps recommend NOT including [Install] sections fir your two .service files and instead make your make install action write symlinks into /usr/lib/systemd/system/nifty.target.wants.d/ thus the user could never disable the individual components of your daemon themselves and thus not need to rely on distro scripts to create them at install time. Your package install script would still have to enable (or preset) the nifty.target however. This might or might not be desirable overall (in the example above, I can imagine someone still wanting to disable only the IPv6 component for example!). Col -- Colin Guthrie colin(at)mageia.org http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Problems with Ethernet link configuration using udevd
Hi there, I seem to have come across a couple of issues with udevd v219's configuration of Ethernet link-level parameters specified in .link files, in particular the speed and duplex settings. Firstly, the speed and duplex ioctl() call is succeeding but without any changes taking effect on the interface. Secondly, the Duplex parameter of the .link file does not appear to be parsed correctly; the duplex value presented to link_apply_config() is not the value specified in the .link file while the speed value is. With the attached .link file specifying a speed of 100M, half duplex, and MAC address of 52:54:00:77:77:77, I get the following after boot: root@qemux86-64:~# ethtool eth0 Settings for eth0: Supported ports: [ TP ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Supported pause frame use: No Supports auto-negotiation: Yes Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Advertised pause frame use: No Advertised auto-negotiation: Yes Speed: 1000Mb/s Duplex: Full Port: Twisted Pair PHYAD: 0 Transceiver: internal Auto-negotiation: on MDI-X: off (auto) Supports Wake-on: umbg Wake-on: d Current message level: 0x0007 (7) drv probe link Link detected: yes root@qemux86-64:~# journalctl -b -u systemd-udevd.service -- Logs begin at Tue 2015-07-21 13:08:03 UTC, end at Tue 2015-07-21 13:08:21 UTC. -- Jul 21 13:08:04 qemux86-64 systemd[1]: Starting udev Kernel Device Manager... Jul 21 13:08:04 qemux86-64 systemd-udevd[91]: starting version 219 Jul 21 13:08:05 qemux86-64 systemd[1]: Started udev Kernel Device Manager. Jul 21 13:08:05 qemux86-64 systemd-udevd[108]: failed to execute '/lib/systemd/systemd-vconsole-setup' '/lib/systemd/systemd-vconsole-setup': No such file or directory Jul 21 13:08:06 qemux86-64 systemd-udevd[98]: Failed to apply ACL on /dev/sequencer: Operation not supported Jul 21 13:08:06 qemux86-64 systemd-udevd[98]: Failed to apply ACL on /dev/sequencer2: Operation not supported Jul 21 13:08:06 qemux86-64 systemd-udevd[99]: Failed to apply ACL on /dev/snd/timer: Operation not supported Jul 21 13:08:06 qemux86-64 systemd-udevd[96]: Failed to apply ACL on /dev/snd/seq: Operation not supported Jul 21 13:08:08 qemux86-64 systemd-udevd[130]: failed to execute '/lib/systemd/systemd-vconsole-setup' '/lib/systemd/systemd-vconsole-setup': No such file or directory Jul 21 13:08:08 qemux86-64 systemd-udevd[129]: failed to execute '/lib/systemd/systemd-vconsole-setup' '/lib/systemd/systemd-vconsole-setup': No such file or directory root@qemux86-64:~# ifconfig eth0 eth0 Link encap:Ethernet HWaddr 52:54:00:77:77:77 ... but with the attached patch, which adds a system() call to execute the ethtool program using the specified parameters, I get advertised link modes different from above: root@qemux86-64:~# ethtool eth0 Settings for eth0: Supported ports: [ TP ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Supported pause frame use: No Supports auto-negotiation: Yes Advertised link modes: 100baseT/Full Advertised pause frame use: No Advertised auto-negotiation: Yes Speed: 1000Mb/s Duplex: Full Port: Twisted Pair PHYAD: 0 Transceiver: internal Auto-negotiation: on MDI-X: off (auto) Supports Wake-on: umbg Wake-on: d Current message level: 0x0007 (7) drv probe link Link detected: yes root@qemux86-64:~# journalctl -b -u systemd-udevd.service -- Logs begin at Tue 2015-07-21 12:42:35 UTC, end at Tue 2015-07-21 12:43:00 UTC. -- Jul 21 12:42:36 qemux86-64 systemd[1]: Starting udev Kernel Device Manager... Jul 21 12:42:37 qemux86-64 systemd-udevd[91]: starting version 219 Jul 21 12:42:37 qemux86-64 systemd[1]: Started udev Kernel Device Manager. Jul 21 12:42:37 qemux86-64 systemd-udevd[104]: failed to execute '/lib/systemd/systemd-vconsole-setup' '/lib/systemd/systemd-vconsole-setup': No such file or directory Jul 21 12:42:38 qemux86-64 systemd-udevd[101]: Setting link eth0 speed to 97656 Mbps, duplex: full Jul 21 12:42:38 qemux86-64 systemd-udevd[101]: Successfully set link eth0 speed to 97656 Mbps (raw: 1), duplex: full Jul 21 12:42:38 qemux86-64 systemd-udevd[102]: Failed to apply ACL on /dev/sequencer: Operation not supported Jul 21 12:42:38 qemux86-64 systemd-udevd[99]: Failed to apply ACL on /dev/snd/seq: Operation not supported Jul 21 12:42:38 qemux86-64 systemd-udevd[98]: Setting link sit0
Re: [systemd-devel] How to properly write an umbrella unit
Heya, On 21 July 2015 at 12:43, Marc Haber mh+systemd-de...@zugschlus.de wrote: Hi, I am trying to systemd'ize a daemon which is useful to be run in two instances. It is usually the case that both instances need to be started and stopped simultaneously, and the local admin would want a _single_ command to start and stop both instances. Therefore, an umbrella is needed. As a beginner, I have written: Imho targets are ugly =) I'd do a nifty@.service with: ExecStart= -%I -cf /etc/nifty/niftyd%I.conf And then people can do e.g.: systemctl enable nifty@4.service nifty@6.service systemctl start nifty@*.service systemctl stop nifty@*.service And the install section would have e.g. default instance name 4, and wanted by multi-user target. And such service should be trivial to integrate into any maintainer scripts. -- Regards, Dimitri. Pura Vida! https://clearlinux.org Open Source Technology Center Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Does socket activation block a TCP port for listening by other processes?
On 07/21/2015 01:52 PM, David Herrmann wrote: Hi On Tue, Jul 21, 2015 at 1:37 PM, Florian Weimer fwei...@redhat.com wrote: We have quite a zoo of services which listen on localhost, on a fixed TCP port, for use by local clients. The canonical example is PostgreSQL on 5432/TCP, for the benefit of Java clients (which cannot use the UNIX domain socket). This has the obvious issue that if a local attacker crashes the service, they can impersonate it by binding to the same port. Does socket activation reliably prevent such impersonation attacks? Or is there race, say during systemd configuration reloading or service restarts, where systemd temporarily does not listen to that port? This race *does* exist with socket activation. The sockets may be re-created if the unit transitions between states (like restart). Thanks. Would it make sense to fix this in some way, so that the socket sticks around? However, this is only triggered by actions on the socket-unit, not the actually activated unit. A crash of the activated service will thus not trigger state-changes on the socket-unit. Good to know. Furthermore, we do not treat occupying a resource as security mechanism. If an attacker has access to bind such a port, we do not place restrictions to prevent that. Instead, you should place LSM restrictions to prevent this. I'm stuck with SELinux and the unconfined_t user, so I don't think I can set an LSM ACL on the port. And please note, the actual activated unit usually does *not* have rights to bind the socket. This is done by pid1. So an attacker would require rights of PID1 for such an attack. unconfined_t unfortunately has this right for port numbers larger than 1023, unfortunately. -- Florian Weimer / Red Hat Product Security ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
