Re: [systemd-devel] networkd with radv advertised prefixes
Dne 09. 07. 2014 17:06, piše Tom Gundersen: On Wed, Jul 9, 2014 at 4:19 PM, Vasiliy Tolstov v.tols...@selfip.ru wrote: As i see, networkd now able to do dhcpv6, what about configuring interfaces to accept radv messages and configure it interfaces? What i need to do on systemd-networkd side? Currently that is not supported, but it is definitely something we want. So if you are interested in extending our libraries to cover this usecase, that would be awesome. I don't want to inject noise in signal of your conversation, but doesnt kernel itself do client side of ipv6 router solicitation/advertisement ? As I understood it, whole point of ra is to be so simple so that it doesn't need any special SW component on the client side and to be able to initialize automatically within interface activation. Branko ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] networkd with radv advertised prefixes
Dne 10. 07. 2014 08:14, piše brane2: Dne 09. 07. 2014 17:06, piše Tom Gundersen: On Wed, Jul 9, 2014 at 4:19 PM, Vasiliy Tolstov v.tols...@selfip.ru wrote: As i see, networkd now able to do dhcpv6, what about configuring interfaces to accept radv messages and configure it interfaces? What i need to do on systemd-networkd side? Currently that is not supported, but it is definitely something we want. So if you are interested in extending our libraries to cover this usecase, that would be awesome. I don't want to inject noise in signal of your conversation, but doesnt kernel itself do client side of ipv6 router solicitation/advertisement ? As I understood it, whole point of ra is to be so simple so that it doesn't need any special SW component on the client side and to be able to initialize automatically within interface activation. Branko Two more points: 1. Since RA mechanism is automatic - without userland involvement, it would be nice to have an option to either deactivate ( presumably within kernel option line) or to remove such adress from adapter if needed. Without this, malevolent or misconfigured node within network could do some damage on the local segment. 2. dhcpv6 is kind of stupid. It should be intelligent, but amongst all those options it has no option for client's or network list with gateway for each network. So, without tricks, you get one /64 span and you are supposed to use it for ONE node just for configuration convenience. That is usually solved by defining user-set options ( ipv6-netmask etc) on server and client side and using hooks on dhclient to execute small scripts that set ip/mask themselves. Version 215 doesn't have docs for dhcpv6, so this is probably just in latest dev version I can't check, but just in case am asking for equivalent functionality here. Otherwise, such dhcpv6 would be useless for most clients... ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] networkd with radv advertised prefixes
Dne 10. 07. 2014 09:11, piše brane2: Dne 10. 07. 2014 08:14, piše brane2: Dne 09. 07. 2014 17:06, piše Tom Gundersen: On Wed, Jul 9, 2014 at 4:19 PM, Vasiliy Tolstov v.tols...@selfip.ru wrote: As i see, networkd now able to do dhcpv6, what about configuring interfaces to accept radv messages and configure it interfaces? What i need to do on systemd-networkd side? Currently that is not supported, but it is definitely something we want. So if you are interested in extending our libraries to cover this usecase, that would be awesome. I don't want to inject noise in signal of your conversation, but doesnt kernel itself do client side of ipv6 router solicitation/advertisement ? As I understood it, whole point of ra is to be so simple so that it doesn't need any special SW component on the client side and to be able to initialize automatically within interface activation. Branko Version 215 doesn't have docs for dhcpv6, so this is probably just in latest dev version I can't check, but just in case am asking for equivalent functionality here. Otherwise, such dhcpv6 would be useless for most clients... Also, since systemd is supposed to be compact and fast and as self-sufficient as practical, I suppose calling bash or similar scripts from it would be far too much of a kludge. Maybe you could have some hooks for code that could be linked-in at runtime and compiled from some boilerplate source to achieve similar functionality ? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] sysusers: allow overrides in /etc and /run
An administrator might want to block a certain sysusers config file from
being executed, e.g. to block the creation of a certain user.
---
src/sysusers/sysusers.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/sysusers/sysusers.c b/src/sysusers/sysusers.c
index 129493a1e7..68c552d24a 100644
--- a/src/sysusers/sysusers.c
+++ b/src/sysusers/sysusers.c
@@ -62,6 +62,8 @@ typedef struct Item {
static char *arg_root = NULL;
static const char conf_file_dirs[] =
+/etc/sysusers.d\0
+/run/sysusers.d\0
/usr/local/lib/sysusers.d\0
/usr/lib/sysusers.d\0
#ifdef HAVE_SPLIT_USR
--
2.0.0
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Separate cpu cgroup parameters
Hi, Even though cpu.shares and cpu.cfs_period_us/cfs_quota_us parameters are in the cpu cgroup, they can be turned off individually. Our kernel only enables cpu.shares property and due to that we see error messages. systemd[1]: Failed to set cpu.cfs_period_us on /system.slice/system-sshd.slice: Permission denied systemd[1]: Failed to set cpu.cfs_quota_us on /system.slice/system-sshd.slice: Permission denied Proposed solutions: - Should we have separate CGroupControllerMask mask like CGROUP_CPU_SHARES CGROUP_CPU_QUOTA OR - Should we just ignore the cg_set_attribute() within cgroup_context_apply() if setting attribute fails due to missing parameter? Umut ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] sysusers: allow overrides in /etc and /run
'Twas brillig, and Zbigniew Jędrzejewski-Szmek at 10/07/14 13:51 did
gyre and gimble:
An administrator might want to block a certain sysusers config file from
being executed, e.g. to block the creation of a certain user.
---
src/sysusers/sysusers.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/sysusers/sysusers.c b/src/sysusers/sysusers.c
index 129493a1e7..68c552d24a 100644
--- a/src/sysusers/sysusers.c
+++ b/src/sysusers/sysusers.c
@@ -62,6 +62,8 @@ typedef struct Item {
static char *arg_root = NULL;
static const char conf_file_dirs[] =
+/etc/sysusers.d\0
+/run/sysusers.d\0
/usr/local/lib/sysusers.d\0
/usr/lib/sysusers.d\0
#ifdef HAVE_SPLIT_USR
I guess this is probably OK, but isn't it a bit counter intuitive? I
mean one of the reasons for sysuser is due to /etc/ being bootstrapped.
In this case I'd have thought that looking in /etc/ is a bit weird.
What if you create a tmpfiles snippet to create a
/etc/sysusers.d/foo.conf file, does that mean we have to run tmpfiles
before sysusers?
But then I do accept that when sysusers is used for non-bootstrapping
(i.e. just instead of the %pre useradd in RPM scripts and the like) it
might be something an administrator would want to override. That said,
AFAIK, there is no way to override this current with rpm scripts, so I
wonder if this is really something to bother supporting ongoing.
Col
--
Colin Guthrie
gmane(at)colin.guthr.ie
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
Re: [systemd-devel] [PATCH] sysusers: allow overrides in /etc and /run
'Twas brillig, and Tobias Geerinckx-Rice at 10/07/14 15:53 did gyre and gimble: On 10 July 2014 13:41, Colin Guthrie gm...@colin.guthr.ie wrote: 'Twas brillig, and Zbigniew Jędrzejewski-Szmek at 10/07/14 13:51 did gyre and gimble: An administrator might want to block a certain sysusers config file from being executed, e.g. to block the creation of a certain user. I guess this is probably OK, but isn't it a bit counter intuitive? I mean one of the reasons for sysuser is due to /etc/ being bootstrapped. In this case I'd have thought that looking in /etc/ is a bit weird. Starting one's laptop in 2014 and seeing a new tape user added is also a bit weird :-) Although I'm running -git at the moment, not a distribution package, so maybe that's not what's supposed to happen. My first reaction was to create my own /etc/sysuser.d/basic.conf without it. Of course, that didn't work. Oh well. It wouldn't have been an ideal solution anyway, probably breaking future upgrades if the upstream basic.conf were to change. Well, this is a reasonable assumption overall I guess, especially considering the usual logic of overriding supported elsewhere in similar tools. It would only break things in future if basic.conf changed to have more essential users. I would suggest that we should put some of these standard, but legacy, users into a legacy.conf instead which should lessen the risk of future updates should you override it on your system (and assuming this patch is accepted!) But then I do accept that when sysusers is used for non-bootstrapping (i.e. just instead of the %pre useradd in RPM scripts and the like) it might be something an administrator would want to override. That said, AFAIK, there is no way to override this current with rpm scripts, so I wonder if this is really something to bother supporting ongoing. non-contributor tangent alert I don't use RPM, but having your system's user policy consist of running useradd in a pre-installation script seems... sub-optimal. It is :) But sadly that's the way it's been done for a while, but now that there is a mechanism to decouple this from pre scripts, we'll be good. (there is a small issue of ownership of certain files according to rpm - e.g. if the package wants to ship files that are user or group owned by users the package itself creates - but I suspect most of these cases will refer to files in /etc or /var both of which should be bootstrapable and thus have files fixed up by tmpfiles so it's likely not a huge issue practically speaking). Replacing this kind of distribution-level system user management -- if any -- with something remotely scalable still smells like a good idea. Yup, totally agree. I really like the sysusers.d stuff generally and look forward to cleaning up a lot of packages to get rid of these old %pre bits So does separating package-managed users/groups from administrator-managed ones: my /etc/groups currently contains openvpn, clamav and kvm, despite my having purged those packages ages ago. Why? I'm not convinced that users or admins, no matter how grey their beards, should be expected to manage such details *by default*. Well, the issue there is one of file ownership. Typically these users are created on installation but never purged on uninstall simply because files may have been stored using those users. e.g. /var/spool/clamav/virusmails/ might all be owned by clamav. If the user was purged when clamav was removed, all that data might sit there owned by the uid/gid (no longer attached to a named account). If then some other package is installed, and it creates a user account it *might* pick up the uid/gid vacated by clamav and thus suddenly become the owner of that data. This could obviously then be a vector for a data leak. That's the reasoning. There may be a better solution (such as scanning all files to find those owned by the uid/gid and deleting them on package removal), but this is the simplest - i.e. leave it to the admin! Having packages contain or depend on a sysusers.d/username.conf containing the relevant fields seems like a nice solution, with /etc then allowing full customisation. Or am I missing something obvious? Don't get me wrong, I really like sysusers.d/ It's just the slight chicken and egg thing that seems slightly odd! I'm not totally against this patch, but I do worry that it enables some weird corner cases when bootstrapping /etc/ from empty - but those are probably not big enough concerns to justify not accepting the patch! Col -- Colin Guthrie gmane(at)colin.guthr.ie 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
Re: [systemd-devel] [PATCH] sysusers: allow overrides in /etc and /run
Am 10.07.2014 16:59, schrieb Jóhann B. Guðmundsson:
On 07/10/2014 12:51 PM, Zbigniew Jędrzejewski-Szmek wrote:
An administrator might want to block a certain sysusers config file from
being executed, e.g. to block the creation of a certain user.
---
src/sysusers/sysusers.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/sysusers/sysusers.c b/src/sysusers/sysusers.c
index 129493a1e7..68c552d24a 100644
--- a/src/sysusers/sysusers.c
+++ b/src/sysusers/sysusers.c
@@ -62,6 +62,8 @@ typedef struct Item {
static char *arg_root = NULL;
static const char conf_file_dirs[] =
+/etc/sysusers.d\0
+/run/sysusers.d\0
/usr/local/lib/sysusers.d\0
/usr/lib/sysusers.d\0
#ifdef HAVE_SPLIT_USR
How does this handle multiple users and if I as an administrator I wanted to
block some users from being created I simply would not have installed the
component that created him in the first place no?
you sound like it is always clear what package, probably installed as
dependency creates a user before - not speaking about that most packages
due uninstall don't remove the users created in rpm scripts
signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] sysusers: allow overrides in /etc and /run
On Thu, Jul 10, 2014 at 02:59:10PM +, Jóhann B. Guðmundsson wrote:
On 07/10/2014 12:51 PM, Zbigniew Jędrzejewski-Szmek wrote:
An administrator might want to block a certain sysusers config file from
being executed, e.g. to block the creation of a certain user.
---
src/sysusers/sysusers.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/sysusers/sysusers.c b/src/sysusers/sysusers.c
index 129493a1e7..68c552d24a 100644
--- a/src/sysusers/sysusers.c
+++ b/src/sysusers/sysusers.c
@@ -62,6 +62,8 @@ typedef struct Item {
static char *arg_root = NULL;
static const char conf_file_dirs[] =
+/etc/sysusers.d\0
+/run/sysusers.d\0
/usr/local/lib/sysusers.d\0
/usr/lib/sysusers.d\0
#ifdef HAVE_SPLIT_USR
How does this handle multiple users and if I as an administrator I
wanted to block some users from being created I simply would not
have installed the component that created him in the first place no?
Let's say that mydatabase.rpm wants to use mydatabaseuser, and creates
the user using sysusers.d, and has a config file which contains
user = mydatabaseuser.
You as an admin know this, but want to use a different user for
whatever reason. So you provide the config file, but sysusers will
still create the user. This is not harmful usually, but can lead
e.g. to confusion, if you or the other admin later sees that this
user exists. So you might do 'ln -s /dev/null /etc/sysusers.d/mydatabase.conf',
to avoid that.
Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] sysusers: allow overrides in /etc and /run
On 07/10/2014 03:10 PM, Reindl Harald wrote:
Am 10.07.2014 16:59, schrieb Jóhann B. Guðmundsson:
On 07/10/2014 12:51 PM, Zbigniew Je;drzejewski-Szmek wrote:
An administrator might want to block a certain sysusers config file from
being executed, e.g. to block the creation of a certain user.
---
src/sysusers/sysusers.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/sysusers/sysusers.c b/src/sysusers/sysusers.c
index 129493a1e7..68c552d24a 100644
--- a/src/sysusers/sysusers.c
+++ b/src/sysusers/sysusers.c
@@ -62,6 +62,8 @@ typedef struct Item {
static char *arg_root = NULL;
static const char conf_file_dirs[] =
+/etc/sysusers.d\0
+/run/sysusers.d\0
/usr/local/lib/sysusers.d\0
/usr/lib/sysusers.d\0
#ifdef HAVE_SPLIT_USR
How does this handle multiple users and if I as an administrator I wanted to
block some users from being created I simply would not have installed the
component that created him in the first place no?
you sound like it is always clear what package, probably installed as
dependency creates a user before - not speaking about that most packages
due uninstall don't remove the users created in rpm scripts
If you are an administrator you will quickly notice or do the necessary
research into what created the user that you dont want installed on your
system and take the necessary precaution from that happening again.
And arguable upstream should not be binding itself to solve downstream
distribution packaging problems be it rpm, be it deb or something else
since the installation scene is on the verge of changing...
JBG
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] sysusers: allow overrides in /etc and /run
On Thu, Jul 10, 2014 at 02:41:14PM +0100, Colin Guthrie wrote: I guess this is probably OK, but isn't it a bit counter intuitive? I mean one of the reasons for sysuser is due to /etc/ being bootstrapped. In this case I'd have thought that looking in /etc/ is a bit weird. This probably wouldn't be useful for the case when /etc is bootstrapped, like you say below. What if you create a tmpfiles snippet to create a /etc/sysusers.d/foo.conf file, does that mean we have to run tmpfiles before sysusers? I think that's a bit of an artificial problem. Like with everything else, the outcome depends on the ordering. What would happen if tmpfiles.d were to create a .service file in /etc/systemd/system? Anyway, in this specific case, I believe sysusers should run before tmpfiles, so it is possible to use tmpfiles to create files owned by users created by sysusers. But then I do accept that when sysusers is used for non-bootstrapping (i.e. just instead of the %pre useradd in RPM scripts and the like) it might be something an administrator would want to override. That said, AFAIK, there is no way to override this current with rpm scripts, so I wonder if this is really something to bother supporting ongoing. Currently, even if you delete a user like this, there's no mechanism to prevent recreation on the next update of this or another unrelated package. So in some sense it is even worse, because with normal rpm scripts you are safe until this specific package is upgraded. But anyway, I find it very nice that the configuration loading mechanism is consistent between tools, and this inability to override sysusers is annoying. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] sysusers: allow overrides in /etc and /run
On Thu, Jul 10, 2014 at 04:18:15PM +0100, Colin Guthrie wrote: I don't use RPM, but having your system's user policy consist of running useradd in a pre-installation script seems... sub-optimal. It is :) But sadly that's the way it's been done for a while, but now that there is a mechanism to decouple this from pre scripts, we'll be good. BTW., does anyone know what happened to the filetriggers idea [1]? Is it available in upstream rpm generally and/or in Fedora? It would be really nice to use this to avoid %post macros in every rpm using sysusers and tmpfiles. Zbyszek [1] https://wiki.mageia.org/en/RPM_filetriggers ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/4] Add ENVIRONMENT to hostnamectl
On Tue, Jul 8, 2014 at 10:23 PM, Jóhann B. Guðmundsson johan...@gmail.com wrote: On 07/08/2014 07:31 PM, Tollef Fog Heen wrote: ]] Tom Gundersen Patches look good. Only found one tiny nit. We should come up with a better name though, feels wrong that the name is very generic (and clashes with other uses), whilst the usage is quite specific (limited to testing, staging, production). Surely at least qa and dev should go onto that list. (You generally want more than one dev environment too, often one or more per developer.) These days people usually use only 3 tier level ( used to be four back in the day ) as in Development and Integration is done the same tier while Staging and Production are separated tiers altogether. We could extend that and include the fourth tier missing tier ( as in Integration ) as optional for those that prefer 4 tier layer over 3 tier but people moved away form that model to the 3 tier one. Development tier Is the working environment for individual developers or small teams. More often than not this work is done in isolation with the rest of the tiers, the developer(s) can try radical changes to the code without adversely affecting the rest of the development team. Integration tier A common environment where all developers commit code changes. This environment combines and validates the work of the entire project team so it can be tested before being promoted to the Staging Environment. More common these days is for Development and Integration to be the same environment as well as run automate tests etc. Staging tier The staging tier is a environment that is as identical to the production environment as possible. The purpose of the Staging environment is to simulate as much of the Production environment as possible for the final test phase ( test using deployment process and test using an real data source, final test of the application itself etc ) as well as more often than not acts as an demonstration/training environment. Production The production tier consist the final products and might include a single machine or or cluster of machines or containers, cloud whatever. Seeing this list, why not name the variable Tier= ? Or DeploymentTier=, if just Tier is too specific? Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/4] Add ENVIRONMENT to hostnamectl
On Thu, Jul 10, 2014 at 7:06 PM, Tom Gundersen t...@jklm.no wrote: On Tue, Jul 8, 2014 at 10:23 PM, Jóhann B. Guðmundsson johan...@gmail.com wrote: On 07/08/2014 07:31 PM, Tollef Fog Heen wrote: ]] Tom Gundersen Patches look good. Only found one tiny nit. We should come up with a better name though, feels wrong that the name is very generic (and clashes with other uses), whilst the usage is quite specific (limited to testing, staging, production). Surely at least qa and dev should go onto that list. (You generally want more than one dev environment too, often one or more per developer.) These days people usually use only 3 tier level ( used to be four back in the day ) as in Development and Integration is done the same tier while Staging and Production are separated tiers altogether. We could extend that and include the fourth tier missing tier ( as in Integration ) as optional for those that prefer 4 tier layer over 3 tier but people moved away form that model to the 3 tier one. Development tier Is the working environment for individual developers or small teams. More often than not this work is done in isolation with the rest of the tiers, the developer(s) can try radical changes to the code without adversely affecting the rest of the development team. Integration tier A common environment where all developers commit code changes. This environment combines and validates the work of the entire project team so it can be tested before being promoted to the Staging Environment. More common these days is for Development and Integration to be the same environment as well as run automate tests etc. Staging tier The staging tier is a environment that is as identical to the production environment as possible. The purpose of the Staging environment is to simulate as much of the Production environment as possible for the final test phase ( test using deployment process and test using an real data source, final test of the application itself etc ) as well as more often than not acts as an demonstration/training environment. Production The production tier consist the final products and might include a single machine or or cluster of machines or containers, cloud whatever. Seeing this list, why not name the variable Tier= ? Or DeploymentTier=, if just Tier is too specific? ^^^too generic Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] sysusers: allow overrides in /etc and /run
On 07/10/2014 04:47 PM, Zbigniew Jędrzejewski-Szmek wrote:
On Thu, Jul 10, 2014 at 02:59:10PM +, Jóhann B. Guðmundsson wrote:
On 07/10/2014 12:51 PM, Zbigniew Jędrzejewski-Szmek wrote:
An administrator might want to block a certain sysusers config file from
being executed, e.g. to block the creation of a certain user.
---
src/sysusers/sysusers.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/sysusers/sysusers.c b/src/sysusers/sysusers.c
index 129493a1e7..68c552d24a 100644
--- a/src/sysusers/sysusers.c
+++ b/src/sysusers/sysusers.c
@@ -62,6 +62,8 @@ typedef struct Item {
static char *arg_root = NULL;
static const char conf_file_dirs[] =
+/etc/sysusers.d\0
+/run/sysusers.d\0
/usr/local/lib/sysusers.d\0
/usr/lib/sysusers.d\0
#ifdef HAVE_SPLIT_USR
How does this handle multiple users and if I as an administrator I
wanted to block some users from being created I simply would not
have installed the component that created him in the first place no?
Let's say that mydatabase.rpm wants to use mydatabaseuser, and creates
the user using sysusers.d, and has a config file which contains
user = mydatabaseuser.
You as an admin know this, but want to use a different user for
whatever reason.
We need to know that reason as in what exactly is the problem
administrators is trying to solve by doing that and is that problem not
already solved with containers or sandboxed application?
So you provide the config file, but sysusers will
still create the user. This is not harmful usually, but can lead
e.g. to confusion, if you or the other admin later sees that this
user exists. So you might do 'ln -s /dev/null /etc/sysusers.d/mydatabase.conf',
to avoid that.
Surely Sandboxed applications when designed was not strictly intended
for GNOME or limited to Gnome existing on the machine for it to be used
mean surely I should be able to download/install/run the Sandboxed
applications postgresql which I fetched directly from postgresql
upstream and it's community and deploy it on my server
As I said before aren't we wasting time solving problems for packaging
formats that are becoming obsolete if things continue to progress in
sandboxed/containerized future?
I have to ask at this point is there something that is preventing us to
introduce type container unit?
JBG
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/4] Add ENVIRONMENT to hostnamectl
On 07/10/2014 05:06 PM, Tom Gundersen wrote: On Thu, Jul 10, 2014 at 7:06 PM, Tom Gundersen t...@jklm.no wrote: On Tue, Jul 8, 2014 at 10:23 PM, Jóhann B. Guðmundsson johan...@gmail.com wrote: On 07/08/2014 07:31 PM, Tollef Fog Heen wrote: ]] Tom Gundersen Patches look good. Only found one tiny nit. We should come up with a better name though, feels wrong that the name is very generic (and clashes with other uses), whilst the usage is quite specific (limited to testing, staging, production). Surely at least qa and dev should go onto that list. (You generally want more than one dev environment too, often one or more per developer.) These days people usually use only 3 tier level ( used to be four back in the day ) as in Development and Integration is done the same tier while Staging and Production are separated tiers altogether. We could extend that and include the fourth tier missing tier ( as in Integration ) as optional for those that prefer 4 tier layer over 3 tier but people moved away form that model to the 3 tier one. Development tier Is the working environment for individual developers or small teams. More often than not this work is done in isolation with the rest of the tiers, the developer(s) can try radical changes to the code without adversely affecting the rest of the development team. Integration tier A common environment where all developers commit code changes. This environment combines and validates the work of the entire project team so it can be tested before being promoted to the Staging Environment. More common these days is for Development and Integration to be the same environment as well as run automate tests etc. Staging tier The staging tier is a environment that is as identical to the production environment as possible. The purpose of the Staging environment is to simulate as much of the Production environment as possible for the final test phase ( test using deployment process and test using an real data source, final test of the application itself etc ) as well as more often than not acts as an demonstration/training environment. Production The production tier consist the final products and might include a single machine or or cluster of machines or containers, cloud whatever. Seeing this list, why not name the variable Tier= ? Or DeploymentTier=, if just Tier is too specific? This is specific for defining staging environment not their layer so can I simple get an ack nack on the deployment patch and those that also want to be able to define free string in there can just patch it. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] sysusers: allow overrides in /etc and /run
On Thu, Jul 10, 2014 at 06:43:26PM +, Jóhann B. Guðmundsson wrote:
On 07/10/2014 04:47 PM, Zbigniew Jędrzejewski-Szmek wrote:
On Thu, Jul 10, 2014 at 02:59:10PM +, Jóhann B. Guðmundsson wrote:
On 07/10/2014 12:51 PM, Zbigniew Jędrzejewski-Szmek wrote:
An administrator might want to block a certain sysusers config file from
being executed, e.g. to block the creation of a certain user.
---
src/sysusers/sysusers.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/sysusers/sysusers.c b/src/sysusers/sysusers.c
index 129493a1e7..68c552d24a 100644
--- a/src/sysusers/sysusers.c
+++ b/src/sysusers/sysusers.c
@@ -62,6 +62,8 @@ typedef struct Item {
static char *arg_root = NULL;
static const char conf_file_dirs[] =
+/etc/sysusers.d\0
+/run/sysusers.d\0
/usr/local/lib/sysusers.d\0
/usr/lib/sysusers.d\0
#ifdef HAVE_SPLIT_USR
How does this handle multiple users and if I as an administrator I
wanted to block some users from being created I simply would not
have installed the component that created him in the first place no?
Let's say that mydatabase.rpm wants to use mydatabaseuser, and creates
the user using sysusers.d, and has a config file which contains
user = mydatabaseuser.
You as an admin know this, but want to use a different user for
whatever reason.
We need to know that reason as in what exactly is the problem
administrators is trying to solve by doing that and is that problem
not already solved with containers or sandboxed application?
The same justifications apply as with any other override in /etc...
Everything from testing, debugging to local setups and workarounds
for bugs in packaging or upstream.
Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] sysusers: allow overrides in /etc and /run
On 07/10/2014 07:10 PM, Zbigniew Jędrzejewski-Szmek wrote:
On Thu, Jul 10, 2014 at 06:43:26PM +, Jóhann B. Guðmundsson wrote:
On 07/10/2014 04:47 PM, Zbigniew Jędrzejewski-Szmek wrote:
On Thu, Jul 10, 2014 at 02:59:10PM +, Jóhann B. Guðmundsson wrote:
On 07/10/2014 12:51 PM, Zbigniew Jędrzejewski-Szmek wrote:
An administrator might want to block a certain sysusers config file from
being executed, e.g. to block the creation of a certain user.
---
src/sysusers/sysusers.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/sysusers/sysusers.c b/src/sysusers/sysusers.c
index 129493a1e7..68c552d24a 100644
--- a/src/sysusers/sysusers.c
+++ b/src/sysusers/sysusers.c
@@ -62,6 +62,8 @@ typedef struct Item {
static char *arg_root = NULL;
static const char conf_file_dirs[] =
+/etc/sysusers.d\0
+/run/sysusers.d\0
/usr/local/lib/sysusers.d\0
/usr/lib/sysusers.d\0
#ifdef HAVE_SPLIT_USR
How does this handle multiple users and if I as an administrator I
wanted to block some users from being created I simply would not
have installed the component that created him in the first place no?
Let's say that mydatabase.rpm wants to use mydatabaseuser, and creates
the user using sysusers.d, and has a config file which contains
user = mydatabaseuser.
You as an admin know this, but want to use a different user for
whatever reason.
We need to know that reason as in what exactly is the problem
administrators is trying to solve by doing that and is that problem
not already solved with containers or sandboxed application?
The same justifications apply as with any other override in /etc...
Everything from testing, debugging to local setups and workarounds
for bugs in packaging or upstream.
Right which begs the question what's the solution to do administrative
overwrites for containers thus the suggestion for type container units.
JBG
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] sysusers: allow overrides in /etc and /run
On Thu, 10.07.14 14:51, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:
An administrator might want to block a certain sysusers config file from
being executed, e.g. to block the creation of a certain user.
---
src/sysusers/sysusers.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/sysusers/sysusers.c b/src/sysusers/sysusers.c
index 129493a1e7..68c552d24a 100644
--- a/src/sysusers/sysusers.c
+++ b/src/sysusers/sysusers.c
@@ -62,6 +62,8 @@ typedef struct Item {
static char *arg_root = NULL;
static const char conf_file_dirs[] =
+/etc/sysusers.d\0
+/run/sysusers.d\0
/usr/local/lib/sysusers.d\0
/usr/lib/sysusers.d\0
#ifdef HAVE_SPLIT_USR
Makes sense, commit!
(Also needs man page update I figure...)
Lennart
--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/4] Add ENVIRONMENT to hostnamectl
On Thu, 10.07.14 18:45, Jóhann B. Guðmundsson (johan...@gmail.com) wrote: Seeing this list, why not name the variable Tier= ? Or DeploymentTier=, if just Tier is too specific? This is specific for defining staging environment not their layer so can I simple get an ack nack on the deployment patch and those that also want to be able to define free string in there can just patch it. Well, as I mentioned earlier, patch looks generally OK, but I am not OK with the strict checking of the value. It sounds Ok to verify that it is a single word, from a limited charset, but we are not going to become the standardization institute for IT workflows. Please remove the strict checking against the vocabulary, and repost! (also needs man page updates...) Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/4] Add ENVIRONMENT to hostnamectl
]] Lennart Poettering On Thu, 10.07.14 18:45, Jóhann B. Guðmundsson (johan...@gmail.com) wrote: Seeing this list, why not name the variable Tier= ? Or DeploymentTier=, if just Tier is too specific? This is specific for defining staging environment not their layer so can I simple get an ack nack on the deployment patch and those that also want to be able to define free string in there can just patch it. Well, as I mentioned earlier, patch looks generally OK, but I am not OK with the strict checking of the value. It sounds Ok to verify that it is a single word, from a limited charset, but we are not going to become the standardization institute for IT workflows. Did we agree on the name? If Environment is out, maybe ProductionLevel or something like that might fly. And yes, it should be freeform. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/4] Add ENVIRONMENT to hostnamectl
On 07/10/2014 08:44 PM, Lennart Poettering wrote: On Thu, 10.07.14 18:45, Jóhann B. Guðmundsson (johan...@gmail.com) wrote: Seeing this list, why not name the variable Tier= ? Or DeploymentTier=, if just Tier is too specific? This is specific for defining staging environment not their layer so can I simple get an ack nack on the deployment patch and those that also want to be able to define free string in there can just patch it. Well, as I mentioned earlier, patch looks generally OK, but I am not OK with the strict checking of the value. It sounds Ok to verify that it is a single word, from a limited charset, but we are not going to become the standardization institute for IT workflows. Please remove the strict checking against the vocabulary, and repost! (also needs man page updates...) Then it wont solve the problem I was hoping to solve nor can I continue the other work I planned on based on these specific values so feel free to implement as you see fit or drop it altogether. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/4] Add ENVIRONMENT to hostnamectl
On 07/10/2014 08:53 PM, Tollef Fog Heen wrote: ]] Lennart Poettering On Thu, 10.07.14 18:45, Jóhann B. Guðmundsson (johan...@gmail.com) wrote: Seeing this list, why not name the variable Tier= ? Or DeploymentTier=, if just Tier is too specific? This is specific for defining staging environment not their layer so can I simple get an ack nack on the deployment patch and those that also want to be able to define free string in there can just patch it. Well, as I mentioned earlier, patch looks generally OK, but I am not OK with the strict checking of the value. It sounds Ok to verify that it is a single word, from a limited charset, but we are not going to become the standardization institute for IT workflows. Did we agree on the name? If Environment is out, maybe ProductionLevel or something like that might fly. And yes, it should be freeform. Then submit the patch with freeform implemented and call it whatever you want. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd freeze with assertion failed error message during bootup
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, I'm having a problem on a fedora 20 Xen guest that freezes systemd with an assertion failed message and bootup stops at that point: https://bugzilla.redhat.com/show_bug.cgi?id=1116510 Is anyone aware of this problem and knows of a workaround? (It is hard to use the system at all with this bug.) thanks in advance, Joonas -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJTvwv9AAoJEG58zmw5nc+vUjMQAMCylAY3SbS0GVIDTJdJztHE VyPc48XW1rMGtPmz22sBcuDZQ9Nxi4KZcOuLXGx//rejAVRqknuUT/k3WsDRYggb mmvk4EuS3z7lxzE9IPMDx9CzxEcfG6t3Dr9YUZccUffQ8mBP9wGZMhyKEsMVrcb/ D6/5Wl+rGKs25WNtbBK2gsb2FvxIeEJTGtIeBl0ADhry8T7TZ59380XOAm5jnP9M DvKwZphlrel1A+2oFrN9Kw01SAlDbOcxA9W/RScnTPCBfOAJWb6Dk90wtEqIfEsx gHDxEGn6pYX4KhObYuW+iJZK8biLLeZ1upa5GbAtkdmTSSouWWfNYFw0tIyWAUWN G+arHfEBDilb5BENZ1Z/XcwmddvcGBYO+dsjFFYSwHAYtPLBIs4jIdNBxu/9WrM1 ovr3AzdkZx8hvPguvZbBjF8BRlPJ8zitMqi62rnjC2I6ADhMPnq26taqQEKSh/Ve PhgaOlc0XabBhVc2fovJh3D2uo64YlhQP9YZqxKHY3jf3e86aCAWgLV8AxfH5IHq 33TnxGPrlPr7rb1mBmXg9V8kGV4UoQdTGdpg+eCsTcgRwzV+0ofcggi1vH4QVjSe lcfkN60u9ghWV0pmpdY8iZoYvchkKz7l48XBKgPsusBTitM/+bG6QJlLse/pjQmG SX/zdIbHuBxqTiCgQJcm =gi5h -END PGP SIGNATURE- ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd freeze with assertion failed error message during bootup
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, I'm having a problem on a fedora 20 Xen guest that freezes systemd with an assertion failed message and bootup stops at that point: https://bugzilla.redhat.com/show_bug.cgi?id=1116510 Is anyone aware of this problem and knows of a workaround? (It is hard to use the system at all with this bug.) thanks in advance, Joonas -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJTvwrQAAoJEG58zmw5nc+vye0P/005+xr/wApbU7Kc0rb/3XVz wKKCpgBgCPtrxL01x7posFlapGvQv5AfE8rfSTFXZfgFyT3KM3fK2EMGbDO1Ctmr FY5nDajxArY7kOTeVZxrX7d7Fa9rHqOl6L1JFQpRUtvIbF8xDgkLQnvB190UklPx KJl3Pm4sq+nNk2lL91fAnF2Wk632XWKvpKMzqSwd6qQXTKwT6eTUoy9zLGNAevr5 sj0beSgs5TWnar3g8Mf4UcPKPYxUlv7Z9pRtw5rFFvv6vLzk1lWWJHZBjsLLSNOa cYOmtLAu43JuKS7hprMDXhpcZXqUgza2Lioy1RD+n3QHL/D2Kcrrr9PMdqaR/P6c nZ1KH8lq07Dm202lDECUkr6rf2LyI54SIFsGbkZJMnqOXOGZhcoYpwad3qiN6ezw qjD03fu8VkRoCRH7dWIB4+z//k/NXND7MqNLQ3MgmPBVfhI3IiH1foFAZFaccKRc vTlN9nmE4Gy+P4ld0VqKa9Zrkr5CZKpGavFdpi52MYasIszqzBQMbGBokaCxG3VZ P53tXLIFVbDniS0drPdaBNuoF5KCo+TGXohIxaa3Z+wmxXjnEfJBCoSzZRLrNb5+ 55ikOlcgIYIPi5UKrJUeFwdZfCknu/sE2AH9eOwlr1nAzVT5JwpWS0AtTH3XLWSb 0uNABQHiody/7csvD1rJ =KAkn -END PGP SIGNATURE- ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/4] Add ENVIRONMENT to hostnamectl
On Thu, 10.07.14 21:04, Jóhann B. Guðmundsson (johan...@gmail.com) wrote: On 07/10/2014 08:44 PM, Lennart Poettering wrote: On Thu, 10.07.14 18:45, Jóhann B. Guðmundsson (johan...@gmail.com) wrote: Seeing this list, why not name the variable Tier= ? Or DeploymentTier=, if just Tier is too specific? This is specific for defining staging environment not their layer so can I simple get an ack nack on the deployment patch and those that also want to be able to define free string in there can just patch it. Well, as I mentioned earlier, patch looks generally OK, but I am not OK with the strict checking of the value. It sounds Ok to verify that it is a single word, from a limited charset, but we are not going to become the standardization institute for IT workflows. Please remove the strict checking against the vocabulary, and repost! (also needs man page updates...) Then it wont solve the problem I was hoping to solve nor can I continue the other work I planned on based on these specific values so feel free to implement as you see fit or drop it altogether. Hmm? Not follow here. You still can use the exact values you want, however, the service will not check them against a whitelist, that's all. Anyway, if Jóhann lost interest, is anybody else interested to see this being added? Tollef? If so, I'd take Jóhann's patch, drop the checking and commit it... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/4] Add ENVIRONMENT to hostnamectl
On 07/10/2014 11:37 PM, Lennart Poettering wrote: On Thu, 10.07.14 21:04, Jóhann B. Guðmundsson (johan...@gmail.com) wrote: On 07/10/2014 08:44 PM, Lennart Poettering wrote: On Thu, 10.07.14 18:45, Jóhann B. Guðmundsson (johan...@gmail.com) wrote: Seeing this list, why not name the variable Tier= ? Or DeploymentTier=, if just Tier is too specific? This is specific for defining staging environment not their layer so can I simple get an ack nack on the deployment patch and those that also want to be able to define free string in there can just patch it. Well, as I mentioned earlier, patch looks generally OK, but I am not OK with the strict checking of the value. It sounds Ok to verify that it is a single word, from a limited charset, but we are not going to become the standardization institute for IT workflows. Please remove the strict checking against the vocabulary, and repost! (also needs man page updates...) Then it wont solve the problem I was hoping to solve nor can I continue the other work I planned on based on these specific values so feel free to implement as you see fit or drop it altogether. Hmm? Not follow here. You still can use the exact values you want, however, the service will not check them against a whitelist, that's all. Systemd integration was just one part, the other part was I was going to contact Karel since I had noticed he has been gradually working on bringing consistency in terminal colorized output in commands the core/baseOS so I wanted to see if we could not come up with terminal color system theme ( which basically administrators have been trying to do and fail miserable in doing so based on the machine staging environment ) and work on integrating that. Something like DEPLOYMENT=Development could be associated with green terminal colour theme DEPLOYMENT=Integration could be associated with yellow terminal colour theme DEPLOYMENT=Staging could be associated with orange terminal colour theme DEPLOYMENT=Production could be associated with red terminal colour theme Then David had suggested to extend this further with in systemd by adding ConditionDeployment= which is a valid request from my point ( we disable for example various servers depending on which staging environments they are in ) I had already submitted new patch with deployment [PATCH] Add DEPLOYMENT to hostnamectl which Zbyszek had suggested and you agreed to and FYI this has nothing to with trying to standardize anything it's about bringing consistency in the system for machines in certain deployment stages so administrators/developers will immediately identify in which stage the environment they are working in, is at. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] How to Listen for SessionRemoved Signal
Hello folks, Apologies if anybody is getting this message twice; I originally posted on d...@lists.freedesktop.org and was directed here. I am attempting to listen to the SessionRemoved signal from the login manager http://www.freedesktop.org/wiki/Software/systemd/logind/. I have no trouble in the case where the user logs out and waits for ~15 seconds before shutting down, but when the user shuts down the system without first logging out I don't hear the SessionRemoved signal in time. I would've thought that inhibiting shutdown (by calling the Inhibit method of the login manager http://www.freedesktop.org/wiki/Software/systemd/inhibit/) would be the appropriate way to keep my process alive long enough to record the SessionRemoved signal before my process gets killed. Apparently that is not the case though. I am fairly certain that I am actually inhibiting shutdown, because my process shows up when I call ListInhibitors in D-Feet https://wiki.gnome.org/action/show/Apps/DFeet. In case it's relevant, I'm using the delay mode of the inhibit method, and my process runs as root. To test whether my process was running in the user session, I called getsid (0) http://linux.about.com/library/cmd/blcmdl2_getsid.htm. It returned the PID of my process, which does not match the session ID of the SessionRemoved signals I was able to record. Is this a legitimate way to verify that my process isn't running in the user session? My original assumption was that my process couldn't possibly be in the user session because I am able to hear the SessionRemoved signal when the user logs out and waits for ~15 seconds. Is that a bad assumption to make? I was advised that some shutdown commands bypass logind, so I tried shutting down several different ways (systemctl shutdown, shutdown now, sudo shutdown now, calling Shutdown method on org.gnome.SessionManager from D-Feet, and the typical GUI way). In all cases I got the same result: I didn't hear the SessionRemoved signal. If anyone has any suggestions on how to debug this or knows what I am missing here, that would be greatly appreciated. Please let me know if any additional details would be helpful. Be well, Kurt -- Kurt von Laven | Endless Mobile | EndlessM.com http://endlessm.com/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
