[systemd-devel] ~/.local/share/systemd/user
Hi, Currently, systemd symlinks ~/.local/share/systemd/user to ~/.config/systemd/user. I'd prefer to not have that symlink. I'd want the two locations have different semantics, analogous to the separation between /usr/lib/systemd/user and /etc/systemd/user, i.e. service upstreams should install units to ~/.local/share/systemd/user and users should customize in ~/.config/systemd/user. I suppose there are very few service upstreams that install their software to the user home directory, but I happen to be writing such software myself. My project is just a toy, though, but I think the general approach of installing a user service to the user home directory makes sense, as it avoids the need to have root access. So, would a patch that removes the symlinking be accepted? -- Tanu ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Add a network-pre.target to avoid firewall leaks
Andrey Borzenkov: В Fri, 06 Jun 2014 12:53:01 + Rusty Bird rustyb...@openmailbox.org пишет: --- a/man/systemd.special.xml +++ b/man/systemd.special.xml @@ -71,6 +71,7 @@ filenamelocal-fs-pre.target/filename, filenamemulti-user.target/filename, filenamenetwork.target/filename, +filenamenetwork-pre.target/filename, filenamenetwork-online.target/filename, filenamenss-lookup.target/filename, filenamenss-user-lookup.target/filename, That's rather terse documentation :) What, can't you read my thoughts or something. I'll reply with a v2 patch that includes a manpage. Rusty signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH v2] Add a network-pre.target to avoid firewall leaks
https://bugs.freedesktop.org/show_bug.cgi?id=79600 --- Makefile.am | 1 + man/network-pre.target.xml| 82 +++ units/network-pre.target | 11 ++ units/network.target | 8 units/systemd-networkd.service.in | 3 +- 5 files changed, 104 insertions(+), 1 deletion(-) create mode 100644 man/network-pre.target.xml create mode 100644 units/network-pre.target diff --git a/Makefile.am b/Makefile.am index a2a01d0..79adc34 100644 --- a/Makefile.am +++ b/Makefile.am @@ -413,6 +413,7 @@ dist_systemunit_DATA = \ units/remote-fs.target \ units/remote-fs-pre.target \ units/network.target \ + units/network-pre.target \ units/network-online.target \ units/nss-lookup.target \ units/nss-user-lookup.target \ diff --git a/man/network-pre.target.xml b/man/network-pre.target.xml new file mode 100644 index 000..db52b33 --- /dev/null +++ b/man/network-pre.target.xml @@ -0,0 +1,82 @@ +?xml version='1.0'? !--*-nxml-*-- +!DOCTYPE refentry PUBLIC -//OASIS//DTD DocBook XML V4.2//EN +http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd; + +!-- + This file is part of systemd. + + Copyright 2014 Tom Gundersen + + systemd is free software; you can redistribute it and/or modify it + under the terms of the GNU Lesser General Public License as published by + the Free Software Foundation; either version 2.1 of the License, or + (at your option) any later version. + + systemd is distributed in the hope that it will be useful, but + WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + Lesser General Public License for more details. + + You should have received a copy of the GNU Lesser General Public License + along with systemd; If not, see http://www.gnu.org/licenses/. +-- + +refentry id=network-pre.target + +refentryinfo +titlenetwork-pre.target/title +productnamesystemd/productname + +authorgroup +author +contribDeveloper/contrib +firstnameRusty/firstname +surnameBird/surname +emailrustyb...@openmailbox.org/email +/author +/authorgroup +/refentryinfo + +refmeta +refentrytitlenetwork-pre.target/refentrytitle +manvolnum8/manvolnum +/refmeta + +refnamediv +refnamenetwork-pre.target/refname +refpurposeNetwork interface configuration has not yet begun/refpurpose +/refnamediv + +refsect1 +titleDescription/title + +paravarnamenetwork-pre.target/varname is a systemd target intended to be +activated before any network interface configuration begins./para +/refsect1 + +refsect1 +titleUsage/title + +paraNetwork interface configuration services must varnameRequire=/varname, +and order themselves varnameAfter=/varname, varnamenetwork-pre.target/varname./para + +paraFirewall services should order themselves varnameBefore=/varname, and +declare a varnameRequiredBy=/varname relation to, varnamenetwork-pre.target/varname. +Once enabled, their failure to start will impede network communication, avoiding +dangerous leaks./para + +para(These usages are compatible with older versions of systemd that do not ship +varnamenetwork-pre.target/varname, because relations to missing units are +dropped.)/para +/refsect1 + +refsect1 +titleSee Also/title +para + citerefentryrefentrytitlesystemd/refentrytitlemanvolnum1/manvolnum/citerefentry, + citerefentryrefentrytitlesystemd.target/refentrytitlemanvolnum5/manvolnum/citerefentry + citerefentryrefentrytitlesystemd.unit/refentrytitlemanvolnum5/manvolnum/citerefentry +/para +/refsect1 + +/refentry diff --git a/units/network-pre.target b/units/network-pre.target new file mode 100644 index 000..0d4d363 --- /dev/null +++ b/units/network-pre.target @@ -0,0 +1,11 @@ +# This file is part of systemd. +# +# systemd is free software; you can redistribute it and/or modify it +# under the terms of the GNU Lesser General Public License as published by +# the Free Software Foundation; either version 2.1 of the License, or +# (at your option) any later version. + +[Unit] +Description=Network (Pre) +Documentation=man:network-pre.target(8) +RefuseManualStart=yes diff --git a/units/network.target b/units/network.target index 65fc64b..b80a8cc 100644 ---
Re: [systemd-devel] ~/.local/share/systemd/user
On Sat, Jun 07, 2014 at 01:07:08PM +0300, Tanu Kaskinen wrote: Hi, Currently, systemd symlinks ~/.local/share/systemd/user to ~/.config/systemd/user. I'd prefer to not have that symlink. I'd want the two locations have different semantics, analogous to the separation between /usr/lib/systemd/user and /etc/systemd/user, i.e. service upstreams should install units to ~/.local/share/systemd/user and users should customize in ~/.config/systemd/user. For me this is a directory, not a symlink. I suppose there are very few service upstreams that install their software to the user home directory, but I happen to be writing such software myself. My project is just a toy, though, but I think the general approach of installing a user service to the user home directory makes sense, as it avoids the need to have root access. So, would a patch that removes the symlinking be accepted? So for user services there are 3 directories that packages can be, checked in order: ~/.config/systemd/user /etc/systemd/user/ /usr/lib/systemd/user I don't see a reason to have a fourth one 'for packages' in a users home directory. Thanks, -- William Giokas | KaiSforza | http://kaictl.net/ GnuPG Key: 0x73CD09CF Fingerprint: F73F 50EF BBE2 9846 8306 E6B8 6902 06D8 73CD 09CF pgpvxu0pe6Koi.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] ~/.local/share/systemd/user
On Sat, 2014-06-07 at 07:42 -0500, William Giokas wrote: On Sat, Jun 07, 2014 at 01:07:08PM +0300, Tanu Kaskinen wrote: Hi, Currently, systemd symlinks ~/.local/share/systemd/user to ~/.config/systemd/user. I'd prefer to not have that symlink. I'd want the two locations have different semantics, analogous to the separation between /usr/lib/systemd/user and /etc/systemd/user, i.e. service upstreams should install units to ~/.local/share/systemd/user and users should customize in ~/.config/systemd/user. For me this is a directory, not a symlink. By this, do you mean ~/.local/share/systemd/user? I don't know how that got created. The current systemd code creates the symlink, unless ~/.local/share/systemd/user already exists (so on your machine the symlink won't be created, unless you remove the directory first). I suppose there are very few service upstreams that install their software to the user home directory, but I happen to be writing such software myself. My project is just a toy, though, but I think the general approach of installing a user service to the user home directory makes sense, as it avoids the need to have root access. So, would a patch that removes the symlinking be accepted? So for user services there are 3 directories that packages can be, checked in order: ~/.config/systemd/user /etc/systemd/user/ /usr/lib/systemd/user I don't see a reason to have a fourth one 'for packages' in a users home directory. The same reasons apply that apply for the /etc and /usr/lib separation: it makes sense to keep upstream units separate from local stuff. If you think that it doesn't make sense to support the rare kind of services that are meant to be installed in the home directory, then ok, I can live with that. But then I wonder why systemd bothers looking at all at ~/.local/share/systemd/user as it currently does. -- Tanu ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] policy: clean up headers and code documentation
Signed-off-by: Djalal Harouni tix...@opendz.org --- policy.c | 9 +++-- 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/policy.c b/policy.c index 5a9770d..6f2bb1f 100644 --- a/policy.c +++ b/policy.c @@ -10,11 +10,8 @@ * your option) any later version. */ -#include linux/device.h #include linux/fs.h -#include linux/idr.h #include linux/init.h -#include linux/module.h #include linux/mutex.h #include linux/sched.h #include linux/sizes.h @@ -129,7 +126,7 @@ exit_free: } /** - * kdbus_policy_free - drop a policy database reference + * kdbus_policy_db_free - drop a policy database reference * @db:The policy database */ void kdbus_policy_db_free(struct kdbus_policy_db *db) @@ -162,7 +159,7 @@ void kdbus_policy_db_free(struct kdbus_policy_db *db) } /** - * kdbus_policy_new() - create a new policy database + * kdbus_policy_db_new() - create a new policy database * @db:The location where to store the new database * * Return: 0 on success, negative errno on failure @@ -294,7 +291,7 @@ kdbus_policy_cache_entry_new(struct kdbus_conn *conn_a, } /** - * kdbus_policy_check_send_access() - check if one connection is allowed + * kdbus_policy_check_talk_access() - check if one connection is allowed *to send a message to another connection * @db:The policy database * @conn_src: The source connection -- 1.9.0 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] policy: clean up headers and code documentation
On 06/07/2014 06:26 PM, Djalal Harouni wrote: Signed-off-by: Djalal Harouni tix...@opendz.org Applied, thanks! --- policy.c | 9 +++-- 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/policy.c b/policy.c index 5a9770d..6f2bb1f 100644 --- a/policy.c +++ b/policy.c @@ -10,11 +10,8 @@ * your option) any later version. */ -#include linux/device.h #include linux/fs.h -#include linux/idr.h #include linux/init.h -#include linux/module.h #include linux/mutex.h #include linux/sched.h #include linux/sizes.h @@ -129,7 +126,7 @@ exit_free: } /** - * kdbus_policy_free - drop a policy database reference + * kdbus_policy_db_free - drop a policy database reference * @db: The policy database */ void kdbus_policy_db_free(struct kdbus_policy_db *db) @@ -162,7 +159,7 @@ void kdbus_policy_db_free(struct kdbus_policy_db *db) } /** - * kdbus_policy_new() - create a new policy database + * kdbus_policy_db_new() - create a new policy database * @db: The location where to store the new database * * Return: 0 on success, negative errno on failure @@ -294,7 +291,7 @@ kdbus_policy_cache_entry_new(struct kdbus_conn *conn_a, } /** - * kdbus_policy_check_send_access() - check if one connection is allowed + * kdbus_policy_check_talk_access() - check if one connection is allowed * to send a message to another connection * @db: The policy database * @conn_src:The source connection ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] policy: clean up headers and code documentation
Hi, I'm sending this to have some updates on the policy! I did notice some issues and others still *to confirm*, so first I'm writing some policy tests to make sure we don't break. I'll clean what I've and get get back to you. For the moment can you please confirm: 1) I assume the policy.c on the master branch is the correct one to work on? 2) So buses and custom endpoints can have their own policy db. From reading the sources, I assume: * The two *share* the same internal format! * The two are unrelated, and the endpoint policy takes precedence over the bus policy when doing the talk check! Thanks! On Sat, Jun 07, 2014 at 05:26:55PM +0100, Djalal Harouni wrote: Signed-off-by: Djalal Harouni tix...@opendz.org --- policy.c | 9 +++-- 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/policy.c b/policy.c index 5a9770d..6f2bb1f 100644 --- a/policy.c +++ b/policy.c @@ -10,11 +10,8 @@ * your option) any later version. */ -#include linux/device.h #include linux/fs.h -#include linux/idr.h #include linux/init.h -#include linux/module.h #include linux/mutex.h #include linux/sched.h #include linux/sizes.h @@ -129,7 +126,7 @@ exit_free: } /** - * kdbus_policy_free - drop a policy database reference + * kdbus_policy_db_free - drop a policy database reference * @db: The policy database */ void kdbus_policy_db_free(struct kdbus_policy_db *db) @@ -162,7 +159,7 @@ void kdbus_policy_db_free(struct kdbus_policy_db *db) } /** - * kdbus_policy_new() - create a new policy database + * kdbus_policy_db_new() - create a new policy database * @db: The location where to store the new database * * Return: 0 on success, negative errno on failure @@ -294,7 +291,7 @@ kdbus_policy_cache_entry_new(struct kdbus_conn *conn_a, } /** - * kdbus_policy_check_send_access() - check if one connection is allowed + * kdbus_policy_check_talk_access() - check if one connection is allowed * to send a message to another connection * @db: The policy database * @conn_src:The source connection -- 1.9.0 -- Djalal Harouni http://opendz.org ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] policy: clean up headers and code documentation
On Sat, Jun 07, 2014 at 06:29:21PM +0200, Daniel Mack wrote: On 06/07/2014 06:26 PM, Djalal Harouni wrote: Signed-off-by: Djalal Harouni tix...@opendz.org Applied, thanks! Oh that was quick! This answers my first question of the other email! Thanks Daniel! --- policy.c | 9 +++-- 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/policy.c b/policy.c index 5a9770d..6f2bb1f 100644 --- a/policy.c +++ b/policy.c @@ -10,11 +10,8 @@ * your option) any later version. */ -#include linux/device.h #include linux/fs.h -#include linux/idr.h #include linux/init.h -#include linux/module.h #include linux/mutex.h #include linux/sched.h #include linux/sizes.h @@ -129,7 +126,7 @@ exit_free: } /** - * kdbus_policy_free - drop a policy database reference + * kdbus_policy_db_free - drop a policy database reference * @db:The policy database */ void kdbus_policy_db_free(struct kdbus_policy_db *db) @@ -162,7 +159,7 @@ void kdbus_policy_db_free(struct kdbus_policy_db *db) } /** - * kdbus_policy_new() - create a new policy database + * kdbus_policy_db_new() - create a new policy database * @db:The location where to store the new database * * Return: 0 on success, negative errno on failure @@ -294,7 +291,7 @@ kdbus_policy_cache_entry_new(struct kdbus_conn *conn_a, } /** - * kdbus_policy_check_send_access() - check if one connection is allowed + * kdbus_policy_check_talk_access() - check if one connection is allowed *to send a message to another connection * @db:The policy database * @conn_src: The source connection -- Djalal Harouni http://opendz.org ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] policy: clean up headers and code documentation
Hi Djalal, On 06/07/2014 06:47 PM, Djalal Harouni wrote: I'm sending this to have some updates on the policy! I did notice some issues and others still *to confirm*, so first I'm writing some policy tests to make sure we don't break. I'll clean what I've and get get back to you. Sure, thanks for having a look. Note that the endpoint policy is currently not well tested, as we lack support for custom endpoints in userland. This will change soon, and it might be that kernel-side corner cases went unnoticed. For the moment can you please confirm: 1) I assume the policy.c on the master branch is the correct one to work on? Yes. 2) So buses and custom endpoints can have their own policy db. From reading the sources, I assume: * The two *share* the same internal format! Not only that, they also kind of share the same external interface. And internally, they're exactly the same thing, yes. They are talked to through different ioctls though, but the layout of items is the same, and the code is written so that we can share as much as possible for both APIs. * The two are unrelated, and the endpoint policy takes precedence over the bus policy when doing the talk check! Well, there no such thing as precedence really, they are simply checked both. For example, when sending a message, both the endpoint and the bus policy have to give TALK permission for the connections involved, otherwise the message is rejected. But as I said, some of that code has not been in production yet, so there might be minor updates in that area. Thanks, Daniel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] policy: clean up headers and code documentation
On Sat, Jun 07, 2014 at 06:58:50PM +0200, Daniel Mack wrote: Hi Djalal, On 06/07/2014 06:47 PM, Djalal Harouni wrote: I'm sending this to have some updates on the policy! I did notice some issues and others still *to confirm*, so first I'm writing some policy tests to make sure we don't break. I'll clean what I've and get get back to you. Sure, thanks for having a look. Note that the endpoint policy is currently not well tested, as we lack support for custom endpoints in userland. This will change soon, and it might be that kernel-side corner cases went unnoticed. Yes I noticed the custom endpoint part, I did write a test which didn't work, Ok! So first, I'll try to help and test the bus policy. For the moment can you please confirm: 1) I assume the policy.c on the master branch is the correct one to work on? Yes. 2) So buses and custom endpoints can have their own policy db. From reading the sources, I assume: * The two *share* the same internal format! Not only that, they also kind of share the same external interface. And internally, they're exactly the same thing, yes. They are talked to through different ioctls though, but the layout of items is the same, and the code is written so that we can share as much as possible for both APIs. Ok. * The two are unrelated, and the endpoint policy takes precedence over the bus policy when doing the talk check! Well, there no such thing as precedence really, they are simply checked both. For example, when sending a message, both the endpoint and the bus policy have to give TALK permission for the connections involved, otherwise the message is rejected. I misread the code, indeed we check both of them. But as I said, some of that code has not been in production yet, so there might be minor updates in that area. Ok, many thanks Daniel! I'll clean what I've and get back to you. Thanks, Daniel -- Djalal Harouni http://opendz.org ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [systemd-netword]
Hello. It is said in the man systemd-netword-wait-online.service: systemd-networkd-wait-online is a one-shot system service that waits for the network to be configured. By default, it will wait for all links it is aware of and which are managed by systemd-networkd.service(8) to be fully configured or failed, and for at least one link to gain a carrier. What exactly mean configured or failed, in this context ? If i have two interface managed by systemd-networkd, one which is up and fully configured and one another that is not (like, an ethernet interface with no cable plugged in), does that mean this other one is failed ? In which state is he ? I think (maybe wrongly) this should be precised somewhere, because I searched for fail in the associated man pages, and found nothing. Thank you. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-netword]
`failed` is a state of a unit and as such it is documented in `systemd` man page. I'm not sure if `systemd` man page fits into your definition of “associated”. Units may be active (meaning started, bound, plugged in, ..., depending on the unit type, see below), or inactive (meaning stopped, unbound, unplugged, ...), as well as in the process of being activated or deactivated, i.e. between the two states (these states are called activating, deactivating). A special failed state is available as well, which is very similar to inactive and is entered when the service failed in some way (process returned error code on exit, or crashed, or an operation timed out). If this state is entered, the cause will be logged, for later reference. ~~~ -- Кирилл Елагин On Sat, Jun 7, 2014 at 11:57 PM, Unknown contact+systemd...@volcanis.me wrote: Hello. It is said in the man systemd-netword-wait-online.service: systemd-networkd-wait-online is a one-shot system service that waits for the network to be configured. By default, it will wait for all links it is aware of and which are managed by systemd-networkd.service(8) to be fully configured or failed, and for at least one link to gain a carrier. What exactly mean configured or failed, in this context ? If i have two interface managed by systemd-networkd, one which is up and fully configured and one another that is not (like, an ethernet interface with no cable plugged in), does that mean this other one is failed ? In which state is he ? I think (maybe wrongly) this should be precised somewhere, because I searched for fail in the associated man pages, and found nothing. Thank you. ___ 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] FixMe need a coredump HOOK
Hi, the coredump machinery provided by the kernel only works for user space processes. Kernel faults usually end in a traceback being printed to the console and are handled differently. To receive information about past and future coredumps stored in the journal you need to: 1. Add a filter which limits entries to MESSAGE_ID=fc2e22bc6ee647b6b90729ab34a250b1 (I think you already have this) 2. retrieve a journal file descriptor which can be used for polling with sd_journal_get_fd() 3. loop over existing entries (You also seem to have this implemented) 4. establish a loop which will poll for journal changes. sd_journal_wait() implements such a loop, but if you want to run this code from a different event loop, you should add the file descriptor received from sd_journal_get_fd() to this external event loop. This is described in some detail in the sd_journal_wait(3) man page. You can use 'journalctl -f MESSAGE_ID=fc2e22bc6ee647b6b90729ab34a250b1' as a general guide. HTH, Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-netword]
Le Sun, 8 Jun 2014 00:21:24 +0400, Kirill Elagin kirela...@gmail.com a écrit : `failed` is a state of a unit and as such it is documented in `systemd` man page. What kind of unit ? I quote: By default, it will wait for all links it is aware of and which are managed by systemd-networkd.service(8) Are these links the one described in the systemd.link manpage ? What happens if I don't have any .link file, and systemd-networkd still manage my ethernet link using a .network file ? Thank your for your answer. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v2] Add a network-pre.target to avoid firewall leaks
Hi, we *might* want to add a target like this. People often have things which they want to do before network is configured and it would be a convenient hook for them. But the reasons should be made clearer. Currently my iptables.service has Before=basic.target. Why is doing something like that not enough? If it is added, the documentation for the target should be added to systemd.special(7), we don't want to have a separate man page for every target. Also, Description= is part of the documentation, and it should be changed to something meaningful. +refsect1 +titleUsage/title + +paraNetwork interface configuration services must varnameRequire=/varname, +and order themselves varnameAfter=/varname, varnamenetwork-pre.target/varname./para + +paraFirewall services should order themselves varnameBefore=/varname, and +declare a varnameRequiredBy=/varname relation to, varnamenetwork-pre.target/varname. +Once enabled, their failure to start will impede network communication, avoiding +dangerous leaks./para dangerous leaks is unclear and imprecise. +para(These usages are compatible with older versions of systemd that do not ship +varnamenetwork-pre.target/varname, because relations to missing units are +dropped.)/para This is not true. Require=network-pre.target will prevent a service from being started if network-pre.target unit is not present. +[Unit] +Description=Network (Pre) +Documentation=man:network-pre.target(8) +RefuseManualStart=yes Why? Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] ~/.local/share/systemd/user
On Sat, Jun 07, 2014 at 04:03:33PM +0300, Tanu Kaskinen wrote: On Sat, 2014-06-07 at 07:42 -0500, William Giokas wrote: On Sat, Jun 07, 2014 at 01:07:08PM +0300, Tanu Kaskinen wrote: Hi, Currently, systemd symlinks ~/.local/share/systemd/user to ~/.config/systemd/user. I'd prefer to not have that symlink. I'd want the two locations have different semantics, analogous to the separation between /usr/lib/systemd/user and /etc/systemd/user, i.e. service upstreams should install units to ~/.local/share/systemd/user and users should customize in ~/.config/systemd/user. For me this is a directory, not a symlink. By this, do you mean ~/.local/share/systemd/user? I don't know how that got created. The current systemd code creates the symlink, unless ~/.local/share/systemd/user already exists (so on your machine the symlink won't be created, unless you remove the directory first). I suppose there are very few service upstreams that install their software to the user home directory, but I happen to be writing such software myself. My project is just a toy, though, but I think the general approach of installing a user service to the user home directory makes sense, as it avoids the need to have root access. So, would a patch that removes the symlinking be accepted? So for user services there are 3 directories that packages can be, checked in order: ~/.config/systemd/user /etc/systemd/user/ /usr/lib/systemd/user I don't see a reason to have a fourth one 'for packages' in a users home directory. Both directories are supported, i.e. you can drop a unit using either path, and it will be used by systemd. A symlink is used to avoid having two directories. Your usecase hasn't been brought up before, so there was little reason to have two. The same reasons apply that apply for the /etc and /usr/lib separation: it makes sense to keep upstream units separate from local stuff. If you think that it doesn't make sense to support the rare kind of services that are meant to be installed in the home directory, then ok, I can live with that. But then I wonder why systemd bothers looking at all at ~/.local/share/systemd/user as it currently does. So far nobody raised this subject, but systemd --user is still relatively unused, so maybe that's why. Lennart, do you have any master plan here? Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Add a network-pre.target to avoid firewall leaks
Could you elaborate why Before=network.target is too late? Am 06.06.2014 14:53 schrieb Rusty Bird rustyb...@openmailbox.org: https://bugs.freedesktop.org/show_bug.cgi?id=79600 --- Makefile.am | 1 + man/systemd.special.xml | 1 + units/network-pre.target | 11 +++ units/network.target | 2 ++ units/systemd-networkd.service.in | 3 ++- 5 files changed, 17 insertions(+), 1 deletion(-) create mode 100644 units/network-pre.target diff --git a/Makefile.am b/Makefile.am index a2a01d0..79adc34 100644 --- a/Makefile.am +++ b/Makefile.am @@ -413,6 +413,7 @@ dist_systemunit_DATA = \ units/remote-fs.target \ units/remote-fs-pre.target \ units/network.target \ + units/network-pre.target \ units/network-online.target \ units/nss-lookup.target \ units/nss-user-lookup.target \ diff --git a/man/systemd.special.xml b/man/systemd.special.xml index 8c2..7515cf8 100644 --- a/man/systemd.special.xml +++ b/man/systemd.special.xml @@ -71,6 +71,7 @@ filenamelocal-fs-pre.target/filename, filenamemulti-user.target/filename, filenamenetwork.target/filename, +filenamenetwork-pre.target/filename, filenamenetwork-online.target/filename, filenamenss-lookup.target/filename, filenamenss-user-lookup.target/filename, diff --git a/units/network-pre.target b/units/network-pre.target new file mode 100644 index 000..0c4a0ca --- /dev/null +++ b/units/network-pre.target @@ -0,0 +1,11 @@ +# This file is part of systemd. +# +# systemd is free software; you can redistribute it and/or modify it +# under the terms of the GNU Lesser General Public License as published by +# the Free Software Foundation; either version 2.1 of the License, or +# (at your option) any later version. + +[Unit] +Description=Network (Pre) +Documentation=man:systemd.special(7) +RefuseManualStart=yes diff --git a/units/network.target b/units/network.target index 65fc64b..6966035 100644 --- a/units/network.target +++ b/units/network.target @@ -9,3 +9,5 @@ Description=Network Documentation=man:systemd.special(7) Documentation= http://www.freedesktop.org/wiki/Software/systemd/NetworkTarget +Requires=network-pre.target +After=network-pre.target diff --git a/units/systemd-networkd.service.in b/units/ systemd-networkd.service.in index 373ac4e..8e4d213 100644 --- a/units/systemd-networkd.service.in +++ b/units/systemd-networkd.service.in @@ -9,8 +9,9 @@ Description=Network Service Documentation=man:systemd-networkd.service(8) DefaultDependencies=no -After=dbus.service +After=dbus.service network-pre.target Before=network.target +Requires=network-pre.target Wants=network.target ConditionCapability=CAP_NET_ADMIN -- 2.0.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] [PATCH] Add a network-pre.target to avoid firewall leaks
On Sun, Jun 08, 2014 at 12:55:55AM +0200, Michael Biebl wrote: Could you elaborate why Before=network.target is too late? Because then network setup races with e.g. iptables setup. Depending on the timing, a window in which the network has been set up, but the firewall is not yet in place. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] FixMe need a coredump HOOK
On Sat, Jun 7, 2014 at 8:49 AM, Leslie Zhai xiangzha...@gmail.com wrote: [...] But I do NOT know how to hook coredump in user space... I simply cat /proc/sys/kernel/core_pattern |/usr/lib/systemd/systemd-coredump %p %u %g %s %t %e Then systemd-coredump collector will be called (HOOKed), for example, BANG ... segfault occured in user or kernel space. but there is NO dbus interface provided for other App such as bug reporter frontend. so I have to inotify /var/log/journal/SUBDIR https://github.com/AOSC-Dev/FixMe/blob/master/test/qinotify/qinotify.cpp#L99 Please someone give me some advice, how to hook coredump in user/kernel space based on systemd or other LIB, thanks a lot! inotify is actually the official method for watching journal entries -- just not directly, but using the sd_journal_get_fd() API that Zbigniew mentioned... From http://www.freedesktop.org/wiki/Software/systemd/journal-files/: Clients intending to show a live view of the journal should use inotify() for this to watch for files changes. -- Mantas Mikulėnas graw...@gmail.com ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Add a network-pre.target to avoid firewall leaks
On Sun, Jun 08, 2014 at 01:07:38AM +0200, Zbigniew Jędrzejewski-Szmek wrote: Date: Sun, 8 Jun 2014 01:07:38 +0200 From: Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl To: Michael Biebl mbi...@gmail.com Cc: systemd Mailing List systemd-devel@lists.freedesktop.org Subject: Re: [systemd-devel] [PATCH] Add a network-pre.target to avoid firewall leaks User-Agent: Mutt/1.5.20 (2009-06-14) On Sun, Jun 08, 2014 at 12:55:55AM +0200, Michael Biebl wrote: Could you elaborate why Before=network.target is too late? Because then network setup races with e.g. iptables setup. Depending on the timing, a window in which the network has been set up, but the firewall is not yet in place. But by the time network.target is reached there are no listening services yet, are there? So, why would one need a firewall? Thanks, Leonid. -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D pgpxmHWBdpNa1.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Add a network-pre.target to avoid firewall leaks
2014-06-08 1:07 GMT+02:00 Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl: On Sun, Jun 08, 2014 at 12:55:55AM +0200, Michael Biebl wrote: Could you elaborate why Before=network.target is too late? Because then network setup races with e.g. iptables setup. Depending on the timing, a window in which the network has been set up, but the firewall is not yet in place. If the iptables setup has Before=network.target, why is that not sufficient? -- 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] [PATCH] Add a network-pre.target to avoid firewall leaks
There are. You have socket-activated services, and you have services that bind to 0.0.0.0 or ::, and you have services that make use of IP_FREEBIND to avoid having to wait for addresses to be assigned... -- Mantas Mikulėnas graw...@gmail.com On Jun 8, 2014 2:27 AM, Leonid Isaev lis...@umail.iu.edu wrote: On Sun, Jun 08, 2014 at 01:07:38AM +0200, Zbigniew Jędrzejewski-Szmek wrote: Date: Sun, 8 Jun 2014 01:07:38 +0200 From: Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl To: Michael Biebl mbi...@gmail.com Cc: systemd Mailing List systemd-devel@lists.freedesktop.org Subject: Re: [systemd-devel] [PATCH] Add a network-pre.target to avoid firewall leaks User-Agent: Mutt/1.5.20 (2009-06-14) On Sun, Jun 08, 2014 at 12:55:55AM +0200, Michael Biebl wrote: Could you elaborate why Before=network.target is too late? Because then network setup races with e.g. iptables setup. Depending on the timing, a window in which the network has been set up, but the firewall is not yet in place. But by the time network.target is reached there are no listening services yet, are there? So, why would one need a firewall? Thanks, Leonid. -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D ___ 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
[systemd-devel] Disable IPv6?
Hi, Every time I boot I can see a 'failed to insert ipv6 module' message, pretty annoying I want to disable IPv6 service, is that possible? For the record, I disabled IPv6 intentionally in my customized kernel -- Best Regards, Aaron Lewis - PGP: 0x13714D33 - http://pgp.mit.edu/ Finger Print: 9F67 391B B770 8FF6 99DC D92D 87F6 2602 1371 4D33 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Disable IPv6?
On Sun, Jun 8, 2014 at 4:16 AM, Aaron Lewis the.warl0ck.1...@gmail.com wrote: Hi, Every time I boot I can see a 'failed to insert ipv6 module' message, pretty annoying I want to disable IPv6 service, is that possible? No, not unless you remove it from kmod-setup.c. For the record, I disabled IPv6 intentionally in my customized kernel For the record, what good reason is there for doing that? -- Mantas Mikulėnas graw...@gmail.com ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Disable IPv6?
On Sun, Jun 08, 2014 at 09:16:43AM +0800, Aaron Lewis wrote: Date: Sun, 8 Jun 2014 09:16:43 +0800 From: Aaron Lewis the.warl0ck.1...@gmail.com To: systemd-devel@lists.freedesktop.org Subject: [systemd-devel] Disable IPv6? Hi, Every time I boot I can see a 'failed to insert ipv6 module' message, pretty annoying I want to disable IPv6 service, is that possible? For the record, I disabled IPv6 intentionally in my customized kernel See https://bugs.archlinux.org/task/38661 . My suggestion would be to either compile a kernel with CONFIG_IPV6=y and then use ipv6.disable=1 in the kernel cmdline (that's what I do), or build ipv6 as a module and blacklist it via modprobe.conf -- Best Regards, Aaron Lewis - PGP: 0x13714D33 - http://pgp.mit.edu/ Finger Print: 9F67 391B B770 8FF6 99DC D92D 87F6 2602 1371 4D33 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel Cheers, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D pgpth3iLounnB.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Add a network-pre.target to avoid firewall leaks
В Sun, 8 Jun 2014 01:42:18 +0200 Michael Biebl mbi...@gmail.com пишет: 2014-06-08 1:07 GMT+02:00 Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl: On Sun, Jun 08, 2014 at 12:55:55AM +0200, Michael Biebl wrote: Could you elaborate why Before=network.target is too late? Because then network setup races with e.g. iptables setup. Depending on the timing, a window in which the network has been set up, but the firewall is not yet in place. If the iptables setup has Before=network.target, why is that not sufficient? Because network.target itself does not do anything at all. You have some other service which does actual job of setting up networking. This other service is ordered before network.target. Ordering something else before network.target will simply run them concurrently. In case of iptables this leaves you with window where interfaces are up but iptables is not yet setup. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
