[systemd-devel] Infiniband network (IPoIB) support in networkd
Greetings What are the current plans for Infiniband network (IPoIB) support in networkd? JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Infiniband network (IPoIB) support in networkd
On 02/21/2014 06:34 PM, Greg KH wrote: On Fri, Feb 21, 2014 at 06:23:25PM +, Jóhann B. Guðmundsson wrote: Greetings What are the current plans for Infiniband network (IPoIB) support in networkd? Why wouldn't it just work today? Have you tried it? If so, what is missing? Nope not tried it, I assumed since it had TYPE=Infiniband in the ifcfg file for it that it required an entry in netdev_kind_table ( NETDEV_KIND_INFINIBAND]= infiniband ) went looking did not see it then simply asked. If it's not required and just works today problem solved. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] service: don't create extra cgroup for control process when reloading SysV service
On 03/11/2014 09:05 AM, Michael Biebl wrote: 2014-03-10 15:25 GMT+01:00 Lukas Nykryn lnyk...@redhat.com: Unfortunately common practice in initscripts is to have reload as an alias for restart (https://fedoraproject.org/wiki/Packaging:SysVInitScript). In that case the newly started process will be killed immediately after the reload process ends and its cgroup is destroyed. Interesting. The Debian/Ubuntu packaging policies are quite contrary in that regard. LSB/SysV init scripts only have the reload option, if the daemon actually supports it. There is a force-reload action though, which is mapped to reload, if the daemon supports reload and to restart, if not. Given that, I wonder if this should be maintained as a Fedora specific patch? Debian is getting it right in this regard since LSB defines the behavior of reload to be [1] *reload* cause the configuration of the service to be reloaded without actually stopping and restarting the service In anycase systemd should follow LSB in this regard leaving any downstream distribution having to patch their own common practices in initscripts by themselves. JBG 1. http://refspecs.linuxbase.org/LSB_4.1.0/LSB-Core-generic/LSB-Core-generic/iniscrptact.html ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] sudo -u app_user systemctl --user
On 03/25/2014 08:42 AM, David Schmitt wrote: If that is a better supported way of achieving my goal of giving a set of users the power to manage their own services... Can you further explain why you want to do that? What's the use case here for embedded/server/desktop? What are you trying to achieve? What behavior do you want? JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC PATCH] service: add FailureAction= option
On 03/26/2014 09:02 AM, Michael Olbrich wrote: It has the same possible values as StartLimitAction= and is executed immediately if a service fails. --- Hi Lennart, Something like this maybe? I'm not quite sure about the condition in service_enter_dead(). I don't think the action should be executed when the service is explicitly stopped. Maybe it should depend on !forbid_restart? If you like, I'll add some documentation. An maybe a follow-up patch to rename the StartLimitAction type? To what though? Dont we already have OnFailure= for this ( or can be used for this instead of introducing FailureAction= which can be confusing to users )? JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Requiring hardware device and escaping device names
On 03/26/2014 01:50 PM, Kai Hendry wrote:
Thanks Michael for answering, :)
On 26 March 2014 18:59, Michael Biebl mbi...@gmail.com wrote:
2014-03-26 3:56 GMT+01:00 Kai Hendry hen...@webconverger.com:
If your daemon is not functional if the hardware is not present, I'd
probably start it via a udev rule and SYSTEMD_WANTS.
Do you have an example for this please?
I don't quite understand why I can't I just name the device in the
service file. Why does it have to be so confusing. Still don't
understand the need for escaping... is there a need?
The reason is when your hardware becomes available you activate the
service.
My udev foo is a bit rusty but you can try something along the lines of...
/etc/udev/rules.d/98-shk-local.rules
SUBSYSTEM==input, ENV{ID_INPUT_KEYBOARD}==?*,
ENV{.INPUT_CLASS}=kbd, TAG+=systemd,
ENV{SYSTEMD_WANTS}+=shkd@%p.service
/etc/systemd/system/shkd@.service
[Unit]
Description=Simple HotKey Daemon
[Service]
ExecStart=/usr/local/bin/shkd %I
Restart=always
[Install]
WantedBy=multi-user.target
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] networkd: Introduce ipip tunnel
On 04/07/2014 04:35 AM, Susant Sahani wrote: This will be much nicer if we simply use ipip as the kind, rather than tunnel. Done ! Hmm... I think it got right the first place from a usability perspective as in kind=tunnel then we need to introduce mode= in the associated network file as in |.netdev| |[NetDev] Name=tunnel0 Kind=tunnel ||[Match] Name=enp2s0 .network [Network] |||# one of the following| Mode=ipip | gre | sit | isatap | vti Address=192.168.0.15/24 Gateway=192.168.0.1| Or have the Mode= in the .netdev file itself JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] networkd: Introduce ipip tunnel
On 04/07/2014 11:09 AM, Susant Sahani wrote: On 04/07/2014 03:13 PM, Jóhann B. Guðmundsson wrote: On 04/07/2014 04:35 AM, Susant Sahani wrote: This will be much nicer if we simply use ipip as the kind, rather than tunnel. Done ! Hmm... I think it got right the first place from a usability perspective as in kind=tunnel then we need to introduce mode= in the associated network file as in Yes from user perceptive this is nice but few line code more ;) I think this is more correct since you are dealing with multiple types of tunnel so the kind= should specify you are using an tunnel and then specify what type of tunnel in either .netdev file itself or .network file JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/1] networkd: Introduce ipip tunnel
On 04/08/2014 03:22 AM, Susant Sahani wrote: file: ipip.netdev -- [NetDev] Name=ipip-tun Kind=ipip [Tunnel] Local=192.168.8.102 Remote=10.4.4.4 TTL=64 MTUBytes=1480 file: ipip.network -- [Match] Name=eth0 [Network] Tunnel=ipip-tun I think this is worse from previous example since now you have moved the network definitions out from the network file and into the net device file. The best way to define this from my pov is like this since the tunnel is the network device type aka Kind=tunnel and the mode is the operation mode of that tunnel ||tunnel0|.netdev| |[NetDev] Name=|||tunnel0| Kind=tunnel ||[Match] Name=enp2s0 .network [Network] |||# one of the following| Mode=ipip | gre | sit | isatap | vti -- Address=192.168.0.15/24 Gateway=192.168.0.1| Or |tunnel0.netdev| |[NetDev] Name=|||tunnel0| Kind=tunnel ||[Match] Name=enp2s0 .network [Network] |||# one of the following| Mode=ipip | gre | sit | isatap | vti -- ||DHCP=yes| or if you want to be consistent with how it's done with bridging you would swap the Mode= in the [Network] section to Tunnel=|ipip | gre | sit | isatap | vti| JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Netconsole NG
On 04/08/2014 12:25 PM, Tom Gundersen wrote: This looks like a definitive improvement. I beg the differ that unit file created/provided is rubbish I even go so far as saying every line in the [Service] section is a sample of what not to do. Anyone reading this thread should stay away from duplicating what is being done in it. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Netconsole NG
On 04/08/2014 09:53 PM, poma wrote: How do you know so much about swallows? Given that you respond in random unrelated quotes on threads and reports then perhaps it's best that people start replying to you in same manner since it seems to be your preferred way of communication. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/2] networkd: ipip tunell add address support
On 04/14/2014 04:06 AM, Susant Sahani wrote: This patch extends supports to configure address for ipip tunnel patch. File: ipip.network [Match] Name=em1 [Network] Tunnel=ipip-tun Address=192.168.10.24 You might want to skip tun from ipip-tun to match modes directly ( ip tu ad ipiptun mode ipip -- local foo remote bar ttl 64 dev em1 ) or atleast remove the - so it matches the ip commands which uses ipiptun, gretun and sittun ( ip tu ad ipiptun -- mode ipip local foo remote bar ttl 64 dev em1 ) JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/2] networkd: ipip tunell add address support
On 04/14/2014 10:31 AM, Susant Sahani wrote: It's a name not tunnel type. Tunnel type configured in .netdev . you can put anything here . Should match the .netdev Name='XYZ' The Kind is mode which you can replace with ipip/sit/gre . file: ipip.netdev -- [NetDev] Name=ipip-tun===Name Kind=ipip == tunnel type I thought you had switched to correct it Kind=tunnel just like you define bridging, bonding and vlan there, with Tunnel= in the network section setting the mode of the tunnel. I guess Tom just has to rule on this since to me how you are implementing things adds an additional learning curve to administrators both since it deviates from the command line as well as configuration this from /etc/net configuration perspective. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 17/17] networkd: add dhcp server support
On 05/27/2014 03:20 PM, Tom Gundersen wrote: On Tue, May 27, 2014 at 2:48 PM, Tollef Fog Heentfh...@err.no wrote: ]] Lennart Poettering If we set up links (and especially, create them like we do for veth), then hel, yeah we should be prepared to make sure everybody gets an address on it. Should we also include BGP, OSPF, RIP, ISIS (and their IPv6 variants) to make sure it's possible to push routes? The sarcasm is not lost on me, but just for the record, I'd say those are out-of-scope. I would beg the differ you will need this to be able to properly support containers, isolating them to their own vlans etc. I would have gone the route of implementing this into a separated systemd network server ( optionally being hidden from the network itself for security reasons which is required ) and have networkd tightly integrated and communicate with that server but you seem to be wanting to integrate all of this into networkd which does not lessen the requirements just complicates configuring them a bit more. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Drop the udev firmware loader
On 05/30/2014 02:51 AM, Greg KH wrote: On Fri, May 30, 2014 at 04:41:01AM +0200, Michael Biebl wrote: 2014-05-30 4:32 GMT+02:00 Michael Bieblmbi...@gmail.com: 2014-05-30 4:26 GMT+02:00 Greg KHgre...@linuxfoundation.org: You update systemd but you don't update the kernel? How does that make any sense? There might be very valid reasons why you need to stick with the old kernel. As said, one example could be that the new one simply doesn't boot. Requiring lock-step upgrades makes the system less fault-tolerant. So where possible this should be avoided. What I'm trying to say here is: let's rip this code out once all stable distros out there in the wild ship a kernel with builti-in firmware loader support, but please not before. What is all? Do we really have to wait 10+ years just because some random disto doesn't want to update their kernel? Since when does systemd care about what random distros do? Agreed. Upstream should always be the driving force forwards thus carrying the most modern code as well as being the decisive factor when it's time to obsolete things from their code base and the burden be put on downstream to carry and maintaining the legacy code being removed if for whatever reason they still require the functionality it provided, be it the udev firmware loader or legacy compatibility mode or generators etc. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Restart best practices
On 06/05/2014 05:00 PM, Lennart Poettering wrote: I think it would make sense to recommend that packagers and upstream packages adopt Restart=on-failure or Restart=on-abnormal (where the former is not appropriate) for all long-running daemons. However, this recommendation should be taken with a grain of salt, as for some services it might be a bad choice to just tape over problems and restarting it again on failure... Hence, this is really not something to blindly apply to all services on the world, but just a recommendation that individually should be considered. We already have units in the wild upstream where the internet has effectively spread ignorance once again which contain Restart=Always when they should not so I would think it would be better send the signal to upstream not to set these settings et all but rather expected downstream distribution to set this based on their own policy so those downstream distribution can provide consistent end user expectation for their administrative user base. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Restart best practices
On 06/06/2014 11:56 AM, Lennart Poettering wrote: On Fri, 06.06.14 09:48, Jóhann B. Guðmundsson (johan...@gmail.com) wrote: On 06/05/2014 05:00 PM, Lennart Poettering wrote: I think it would make sense to recommend that packagers and upstream packages adopt Restart=on-failure or Restart=on-abnormal (where the former is not appropriate) for all long-running daemons. However, this recommendation should be taken with a grain of salt, as for some services it might be a bad choice to just tape over problems and restarting it again on failure... Hence, this is really not something to blindly apply to all services on the world, but just a recommendation that individually should be considered. We already have units in the wild upstream where the internet has effectively spread ignorance once again which contain Restart=Always when they should not so I would think it would be better send the signal to upstream not to set these settings et all but rather expected downstream distribution to set this based on their own policy so those downstream distribution can provide consistent end user expectation for their administrative user base. It is actually our intention to unify distributions, and thus encourage developers to ship unit files upstream that need no modification. I'd thus enjoy if Debian and Fedora could adopt similar guidelines here. I'm very well aware of the intention, it was the reason I signed up in the first place but I dont think you will be able to achieve that unification with the direction Fedora/Red Hat are taking and probably never with distribution that have corporation dictating and deciding things in it's background since you have conflict of interest between corporates and the community one always. But let's put that fact aside and say that conflict did not exist then we are still faced with the fragmentation between various upstreams shipping daemon and or services where for example some upstream refuse to ship init scripts of anykind since they are writing their software to be used between *nixes and they think this should be handled entirely downstream. So as far as I can tell the closest and the only way we can effectively achieve the goal of unifying distribution in that regard is for those of us doing systemd integration work in distribution and other places, to collaborative maintaining unit files in a centralized repository for upstream component, which then upstream and or distribution directly would sync from git repository as I think I have already mentioned before since this become more or less clear in F15/F16 era. I created a repository for such thing a while back where I had removed the idiotic and no longer necessary Red Hat specific bits which I know for a fact will be hard to remove from Fedora with similar things existing in other distribution to make the unit files I created truly cross distribution and reusable. Tom did as well create a repository for similar purpose a year or two later after some discussion at some conference or hackfest and then merged what I had in mine but I think that work has stagnated since he started working full time on Systemd and I myself was to busy doing the systemd integration into Fedora With centralized managed repository for type systemd units we ought to be better and more efficiently equipped to push changes to type units into distribution but first all of us need to agree that should be the way forward for type systemd units and start doing the required work to make that happen if that agreement is made. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Extending os-release
Hi I've noticed repeated problem through history where administrators seem to be struggling with clearly identify the server environment they are working in. Some try to come up with terminal colours associated with it, others use hostnaming scheme etc, so I was wondering if we could not solve that by introducing a new option to os-release called ENVIRONMENT which would be string that uniquely identifies the system environment in an three-tier server scheme as in Development, Staging, and Production ( or simply have it free for administrators own definition) as in ENVIRONMENT=Development ENVIRONMENT=Staging ENVIRONMENT=Production Thoughts? JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Extending os-release
On 07/07/2014 08:38 PM, Zbigniew Jędrzejewski-Szmek wrote: On Mon, Jul 07, 2014 at 08:02:19PM +, Jóhann B. Guðmundsson wrote: On 07/07/2014 08:00 PM, Tom Gundersen wrote: On Mon, Jul 7, 2014 at 9:44 PM, Mantas Mikulėnas graw...@gmail.com wrote: Sounds like a better fit for /etc/machine-info, as it's really not a distro thing. Yeah, this sort of info should probably not go in /etc/os-release (we are moving that to /usr/lib/os-release, which should make it clearer that this is really static info given by the distro, rather than config stuff for the admin). Right it's an better fit there and accommodates chassis= nicely as in...| CHASSIS=server Environment=Production s/Environment/ENVIRONMENT/ I'd like to see ANSI_COLOR in machine-info too. Maybe systemd (or something else) could generate one randomly when populating machine-info. Then a suitable shell prompt could use that. I had pinged Karel Zak on G+ since I had noticed he has been working on bringing consistency in terminal colorized output in the core/baseOS, with the idea and question if each environment could have an different terminal colour profile associated with it as in: ENVIRONMENT=Development could be associated with green terminal colour profile ENVIRONMENT=Staging could be associated with yellow terminal colour profile ENVIRONMENT=Production could be associated with red terminal colour profile No environment entry would just use the system defaults. So when an administrator logs into a server he would immediately know if he was operating on development server or an production server based on the terminal colour profile he was greeted with when he logged in. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 1/4] Add ENVIRONMENT to hostnamectl
---
src/hostname/hostnamectl.c | 20 +---
1 file changed, 17 insertions(+), 3 deletions(-)
diff --git a/src/hostname/hostnamectl.c b/src/hostname/hostnamectl.c
index 267cd74..e164086 100644
--- a/src/hostname/hostnamectl.c
+++ b/src/hostname/hostnamectl.c
@@ -67,6 +67,7 @@ typedef struct StatusInfo {
char *pretty_hostname;
char *icon_name;
char *chassis;
+char *environment;
char *kernel_name;
char *kernel_release;
char *os_pretty_name;
@@ -92,9 +93,11 @@ static void print_status_info(StatusInfo *i) {
printf(Transient hostname: %s\n, i-hostname);
printf( Icon name: %s\n
- Chassis: %s\n,
+ Chassis: %s\n
+ Environment: %s\n,
strna(i-icon_name),
- strna(i-chassis));
+ strna(i-chassis),
+ strna(i-environment));
r = sd_id128_get_machine(mid);
if (r = 0)
@@ -157,6 +160,7 @@ static int show_all_names(sd_bus *bus) {
{ PrettyHostname, s, NULL, offsetof(StatusInfo,
pretty_hostname) },
{ IconName, s, NULL, offsetof(StatusInfo, icon_name)
},
{ Chassis,s, NULL, offsetof(StatusInfo, chassis) },
+{ Environment,s, NULL, offsetof(StatusInfo,
environment) },
{ KernelName, s, NULL, offsetof(StatusInfo,
kernel_name) },
{ KernelRelease, s, NULL, offsetof(StatusInfo,
kernel_release) },
{ OperatingSystemPrettyName, s, NULL,
offsetof(StatusInfo, os_pretty_name) },
@@ -194,6 +198,7 @@ fail:
free(info.pretty_hostname);
free(info.icon_name);
free(info.chassis);
+free(info.environment);
free(info.kernel_name);
free(info.kernel_release);
free(info.os_pretty_name);
@@ -309,6 +314,13 @@ static int set_chassis(sd_bus *bus, char **args, unsigned
n) {
return set_simple_string(bus, SetChassis, args[1]);
}
+static int set_environment(sd_bus *bus, char **args, unsigned n) {
+assert(args);
+assert(n == 2);
+
+return set_simple_string(bus, SetEnvironment, args[1]);
+}
+
static int help(void) {
printf(%s [OPTIONS...] COMMAND ...\n\n
@@ -325,7 +337,8 @@ static int help(void) {
status Show current hostname settings\n
set-hostname NAME Set system hostname\n
set-icon-name NAME Set icon name for host\n
- set-chassis NAME Set chassis type for host\n,
+ set-chassis NAME Set chassis type for host\n
+ set-environment NAME Set environment for host\n,
program_invocation_short_name);
return 0;
@@ -423,6 +436,7 @@ static int hostnamectl_main(sd_bus *bus, int argc, char
*argv[]) {
{ set-hostname, EQUAL, 2, set_hostname },
{ set-icon-name, EQUAL, 2, set_icon_name },
{ set-chassis, EQUAL, 2, set_chassis },
+{ set-environment, EQUAL, 2, set_environment },
};
int left;
--
1.9.3
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 2/4] Add ENVIRONMENT to hostnamed
---
src/hostname/hostnamed.c | 49 +---
1 file changed, 46 insertions(+), 3 deletions(-)
diff --git a/src/hostname/hostnamed.c b/src/hostname/hostnamed.c
index 514554d..b5ed3e9 100644
--- a/src/hostname/hostnamed.c
+++ b/src/hostname/hostnamed.c
@@ -41,6 +41,7 @@ enum {
PROP_PRETTY_HOSTNAME,
PROP_ICON_NAME,
PROP_CHASSIS,
+PROP_ENVIRONMENT,
PROP_KERNEL_NAME,
PROP_KERNEL_RELEASE,
PROP_KERNEL_VERSION,
@@ -100,6 +101,7 @@ static int context_read_data(Context *c) {
PRETTY_HOSTNAME, c-data[PROP_PRETTY_HOSTNAME],
ICON_NAME, c-data[PROP_ICON_NAME],
CHASSIS, c-data[PROP_CHASSIS],
+ ENVIRONMENT, c-data[PROP_ENVIRONMENT],
NULL);
if (r 0 r != -ENOENT)
return r;
@@ -148,6 +150,18 @@ static bool valid_chassis(const char *chassis) {
chassis);
}
+static bool valid_environment(const char *environment) {
+
+assert(environment);
+
+return nulstr_contains(
+development\0
+staging\0
+production\0,
+environment);
+}
+
+
static const char* fallback_chassis(void) {
int r;
char *type;
@@ -257,6 +271,7 @@ static char* context_fallback_icon_name(Context *c) {
return strdup(computer);
}
+
static bool hostname_is_useful(const char *hn) {
return !isempty(hn) !is_localhost(hn);
}
@@ -311,7 +326,8 @@ static int context_write_data_machine_info(Context *c) {
static const char * const name[_PROP_MAX] = {
[PROP_PRETTY_HOSTNAME] = PRETTY_HOSTNAME,
[PROP_ICON_NAME] = ICON_NAME,
-[PROP_CHASSIS] = CHASSIS
+[PROP_CHASSIS] = CHASSIS,
+[PROP_ENVIRONMENT] = ENVIRONMENT,
};
_cleanup_strv_free_ char **l = NULL;
@@ -323,7 +339,7 @@ static int context_write_data_machine_info(Context *c) {
if (r 0 r != -ENOENT)
return r;
-for (p = PROP_PRETTY_HOSTNAME; p = PROP_CHASSIS; p++) {
+for (p = PROP_PRETTY_HOSTNAME; p = PROP_ENVIRONMENT; p++) {
char *t, **u;
assert(name[p]);
@@ -401,6 +417,23 @@ static int property_get_chassis(
return sd_bus_message_append(reply, s, name);
}
+static int property_get_environment(
+sd_bus *bus,
+const char *path,
+const char *interface,
+const char *property,
+sd_bus_message *reply,
+void *userdata,
+sd_bus_error *error) {
+
+Context *c = userdata;
+const char *name;
+
+name = c-data[PROP_ENVIRONMENT];
+
+return sd_bus_message_append(reply, s, name);
+}
+
static int method_set_hostname(sd_bus *bus, sd_bus_message *m, void *userdata,
sd_bus_error *error) {
Context *c = userdata;
const char *name;
@@ -554,6 +587,8 @@ static int set_machine_info(Context *c, sd_bus *bus,
sd_bus_message *m, int prop
return sd_bus_error_setf(error,
SD_BUS_ERROR_INVALID_ARGS, Invalid pretty host name '%s', name);
if (prop == PROP_CHASSIS !valid_chassis(name))
return sd_bus_error_setf(error,
SD_BUS_ERROR_INVALID_ARGS, Invalid chassis '%s', name);
+if (prop == PROP_ENVIRONMENT !valid_environment(name))
+return sd_bus_error_setf(error,
SD_BUS_ERROR_INVALID_ARGS, Invalid environment '%s', name);
h = strdup(name);
if (!h)
@@ -571,11 +606,13 @@ static int set_machine_info(Context *c, sd_bus *bus,
sd_bus_message *m, int prop
log_info(Changed %s to '%s',
prop == PROP_PRETTY_HOSTNAME ? pretty host name :
+prop == PROP_ENVIRONMENT ? environment :
prop == PROP_CHASSIS ? chassis : icon name,
strna(c-data[prop]));
sd_bus_emit_properties_changed(bus, /org/freedesktop/hostname1,
org.freedesktop.hostname1,
prop == PROP_PRETTY_HOSTNAME ?
PrettyHostname :
- prop == PROP_CHASSIS ? Chassis :
IconName, NULL);
+ prop == PROP_ENVIRONMENT ?
Environment :
+ prop == PROP_CHASSIS ? Chassis :
IconName , NULL);
return sd_bus_reply_method_return(m, NULL);
}
@@ -592,6 +629,10 @@ static int method_set_chassis(sd_bus *bus, sd_bus_message
*m, void *userdata, sd
return set_machine_info(userdata, bus, m, PROP_CHASSIS,
method_set_chassis, error);
}
+static int method_set_environment(sd_bus *bus, sd_bus_message *m, void
*userdata, sd_bus_error *error) {
+return
[systemd-devel] [PATCH 4/4] Add ENVIRONMENT to machine-info man page
--- man/machine-info.xml | 16 +++- 1 file changed, 15 insertions(+), 1 deletion(-) diff --git a/man/machine-info.xml b/man/machine-info.xml index 7448e68..b7e5604 100644 --- a/man/machine-info.xml +++ b/man/machine-info.xml @@ -156,6 +156,19 @@ available./para/listitem /varlistentry +varlistentry +termvarnameENVIRONMENT=/varname/term + +listitemparaSet the system Three-Tier +environment. Currently, the following +environments are defined: +literaldevelopment/literal, +literalstaging/literal, +literalproduction/literal, +/para/listitem +/varlistentry + + /variablelist /refsect1 @@ -165,7 +178,8 @@ programlistingPRETTY_HOSTNAME=Lennart's Tablet ICON_NAME=computer-tablet -CHASSIS=tablet/programlisting +CHASSIS=tablet +ENVIRONMENT=production/programlisting /refsect1 refsect1 -- 1.9.3 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 3/4] Add ENVIRONMENT to hostnamectl man page
--- man/hostnamectl.xml | 13 + 1 file changed, 13 insertions(+) diff --git a/man/hostnamectl.xml b/man/hostnamectl.xml index 7729ef6..8c31e2f 100644 --- a/man/hostnamectl.xml +++ b/man/hostnamectl.xml @@ -223,6 +223,19 @@ parameters./para/listitem /varlistentry +varlistentry +termcommandset-environment [ENVIRONMENT]/command/term + +listitemparaSet the system Three-Tier +environment. Currently, the following +environments are defined: +literaldevelopment/literal, +literalstaging/literal, +literalproduction/literal, +/para/listitem +/varlistentry + + /variablelist /refsect1 -- 1.9.3 ___ 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/08/2014 12:55 AM, Kay Sievers wrote: Shouldn't we possibly we find a word for environment which explains itself a bit better? Environment we usually call the numerous variables of a process or service. I was aware of that but decided to move forward since people should be able to make the distinction vs introduces an new word with added learning curve but yeah sure I will resubmit with atmosphere instead. 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/08/2014 11:28 AM, Peter Sztanojev wrote: On Tue, Jul 8, 2014 at 9:31 AM, Jóhann B. Guðmundsson johan...@gmail.com wrote: On 07/08/2014 12:55 AM, Kay Sievers wrote: Shouldn't we possibly we find a word for environment which explains itself a bit better? Environment we usually call the numerous variables of a process or service. I was aware of that but decided to move forward since people should be able to make the distinction vs introduces an new word with added learning curve but yeah sure I will resubmit with atmosphere instead. How about MachineRole? Machine role is different and define the purpose of the machine not the 3 tier environment it resides in. It was on my todo list to look at. 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/08/2014 11:40 AM, Lennart Poettering wrote:
On Tue, 08.07.14 02:55, Kay Sievers (k...@vrfy.org) wrote:
On Tue, Jul 8, 2014 at 2:38 AM, Jóhann B. Guðmundsson
johan...@gmail.com wrote:
---
src/hostname/hostnamectl.c | 20 +---
1 file changed, 17 insertions(+), 3 deletions(-)
diff --git a/src/hostname/hostnamectl.c b/src/hostname/hostnamectl.c
index 267cd74..e164086 100644
--- a/src/hostname/hostnamectl.c
+++ b/src/hostname/hostnamectl.c
@@ -67,6 +67,7 @@ typedef struct StatusInfo {
char *pretty_hostname;
char *icon_name;
char *chassis;
+char *environment;
char *kernel_name;
char *kernel_release;
char *os_pretty_name;
@@ -92,9 +93,11 @@ static void print_status_info(StatusInfo *i) {
printf(Transient hostname: %s\n, i-hostname);
printf( Icon name: %s\n
- Chassis: %s\n,
+ Chassis: %s\n
+ Environment: %s\n,
Shouldn't we possibly we find a word for environment which explains
itself a bit better? Environment we usually call the numerous
variables of a process or service.
Yeah, I don't really like environment as name for this either. This is
already used quite commonly in the environment variable sense, we
shouldn't redefine this in this comment.
I hardly call this redefinition but OK
I'd go for something generic like description or comment or so. Or
maybe purpose. I think simply description appears to be the best
option for me.
This is very specific to deployment environment and to solve a very
specific long standing problem ( describe the operating environment ) so
the options can only be development,staging,production or if people see
the need to extend it further, it could include as well integration and
testing so an description ( which is even more generic than
environment) is a no go.
I think personally that atmosphere is the best synonym for
environment and should be used here since people are insisting using
something else then environment and are under the assumption that
administrators, developers and end users in in general will be confused
by this .
In the long run I think we should be working on an machine information
specificationand amongst other thing redefine Computer Chassis as
System Enclosure or even just drop it altogethersince it's usefulness
is limited to application which might behave differently based on the
System Enclosure type it's running on
For example M$ has 24 definition for chassis [1] while we have 5 (
vm,container,desktop,laptop,handset,server ) which we arguably could
simply reduce to 3 vm,container,hardware provided information ( limited
to the 29 bios standard only [2] ).
Anyway as I said in the long run I think we should be working on an
machine information specification
1. http://technet.microsoft.com/en-us/library/ee156537.aspx
2.
http://www.dmtf.org/sites/default/files/standards/documents/DSP0134_2.8.0.pdf
___
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/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. 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/08/2014 08:31 PM, Tomasz Torcz wrote: We also have Disaster Recovery (DR) tier. It's basically copy of production, started when disaster strucks. I dont think we should add Recovery as an layer since it's just a replica of production in one form or another and as an administrator or developer you treat that as an production as well as DR being a layered process of their own. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] Add DEPLOYMENT to hostnamectl
---
man/hostnamectl.xml| 14 +
man/machine-info.xml | 17 +++-
src/hostname/hostnamectl.c | 20 ---
src/hostname/hostnamed.c | 50 +++---
4 files changed, 94 insertions(+), 7 deletions(-)
diff --git a/man/hostnamectl.xml b/man/hostnamectl.xml
index 7729ef6..42d3863 100644
--- a/man/hostnamectl.xml
+++ b/man/hostnamectl.xml
@@ -223,6 +223,20 @@
parameters./para/listitem
/varlistentry
+varlistentry
+termcommandset-deployment
[ENVIRONMENT]/command/term
+
+listitemparaSet the deployment
+environment. Currently, the following
+environments are defined:
+literaldevelopment/literal,
+ literalintegration/literal,
+literalstaging/literal,
+literalproduction/literal,
+/para/listitem
+/varlistentry
+
+
/variablelist
/refsect1
diff --git a/man/machine-info.xml b/man/machine-info.xml
index 7448e68..b380975 100644
--- a/man/machine-info.xml
+++ b/man/machine-info.xml
@@ -156,6 +156,20 @@
available./para/listitem
/varlistentry
+varlistentry
+termvarnameDEPLOYMENT=/varname/term
+
+listitemparaSet the system deployment
+environment. Currently, the following
+environments are defined:
+literaldevelopment/literal,
+ literalintegration/literal,
+literalstaging/literal,
+literalproduction/literal,
+/para/listitem
+/varlistentry
+
+
/variablelist
/refsect1
@@ -165,7 +179,8 @@
programlistingPRETTY_HOSTNAME=Lennart's Tablet
ICON_NAME=computer-tablet
-CHASSIS=tablet/programlisting
+CHASSIS=tablet
+DEPLOYMENT=production/programlisting
/refsect1
refsect1
diff --git a/src/hostname/hostnamectl.c b/src/hostname/hostnamectl.c
index 267cd74..7e6922b 100644
--- a/src/hostname/hostnamectl.c
+++ b/src/hostname/hostnamectl.c
@@ -67,6 +67,7 @@ typedef struct StatusInfo {
char *pretty_hostname;
char *icon_name;
char *chassis;
+char *deployment;
char *kernel_name;
char *kernel_release;
char *os_pretty_name;
@@ -92,9 +93,11 @@ static void print_status_info(StatusInfo *i) {
printf(Transient hostname: %s\n, i-hostname);
printf( Icon name: %s\n
- Chassis: %s\n,
+ Chassis: %s\n
+ Deployment: %s\n,
strna(i-icon_name),
- strna(i-chassis));
+ strna(i-chassis),
+ strna(i-deployment));
r = sd_id128_get_machine(mid);
if (r = 0)
@@ -157,6 +160,7 @@ static int show_all_names(sd_bus *bus) {
{ PrettyHostname, s, NULL, offsetof(StatusInfo,
pretty_hostname) },
{ IconName, s, NULL, offsetof(StatusInfo, icon_name)
},
{ Chassis,s, NULL, offsetof(StatusInfo, chassis) },
+{ Deployment,s, NULL, offsetof(StatusInfo,
deployment) },
{ KernelName, s, NULL, offsetof(StatusInfo,
kernel_name) },
{ KernelRelease, s, NULL, offsetof(StatusInfo,
kernel_release) },
{ OperatingSystemPrettyName, s, NULL,
offsetof(StatusInfo, os_pretty_name) },
@@ -194,6 +198,7 @@ fail:
free(info.pretty_hostname);
free(info.icon_name);
free(info.chassis);
+free(info.deployment);
free(info.kernel_name);
free(info.kernel_release);
free(info.os_pretty_name);
@@ -309,6 +314,13 @@ static int set_chassis(sd_bus *bus, char **args, unsigned
n) {
return set_simple_string(bus, SetChassis, args[1]);
}
+static int set_deployment(sd_bus *bus, char **args, unsigned n) {
+assert(args);
+assert(n == 2);
+
+return set_simple_string(bus, SetDeployment, args[1]);
+}
+
static int help(void) {
printf(%s [OPTIONS...] COMMAND ...\n\n
@@ -325,7 +337,8 @@ static int help(void) {
status Show current hostname settings\n
set-hostname NAME Set system hostname\n
set-icon-name NAME Set icon name for host\n
- set-chassis NAME Set chassis type for host\n,
+
Re: [systemd-devel] Deployment/environment names [was: Re: [PATCH 2/4] Add ENVIRONMENT to hostnamed]
On 07/08/2014 10:45 PM, Josh Triplett wrote:
[Responding to this version because the latest thread hasn't appeared in
the mbox archives yet. The comments apply equally well to the latest
version, Add DEPLOYMENT to hostnamectl.]
On Tue, Jul 08, 2014 at 12:38:50AM +, Jóhann B. Guðmundsson wrote:
+static bool valid_environment(const char *environment) {
+
+assert(environment);
+
+return nulstr_contains(
+development\0
+staging\0
+production\0,
+environment);
+}
Can we please *not* attempt to limit or standardize this particular
set of machine roles? As already demonstrated in the previous thread,
people have all sorts of staged deployment strategies. Furthermore,
the concept of a machine role shouldn't be limited to service deployment
strategies.
Roles != the environment they run in.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Extending machine-info to include machine roles
Now let's start the dialog with machine roles and start by agreeing what roles are From my point of view roles are human representation of the primary duty the machine performs it's not the environment they are run in. ( like development,staging,production ) nor is it the components themselves that full fill the role ( like postgresql would full fill an role of an database server ) For example Monitoring Server Name server Mail server Database server Print server File server Directory Server Application Server Jump Server Terminal Server Remote Access Server Media Server Network Server Proxy server Network Server Web Server CMS Workstation Load Balancer Firewall etc... These are all roles who can exist in different environments like the role of an web server can exist in development, staging and production environments hence the clear distinction thus the clear need for the ability to define both as in... DEPLOYMENT=production ROLE=application server etc. Thoughts comments flames JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Add DEPLOYMENT to hostnamectl
On 07/08/2014 11:52 PM, David Timothy Strauss wrote: As someone who deploys developer VMs and production ones, this is useful. Will it be possible to make units have ConditionDeployment=? That would allow disabling, say, pushes of log messages to our log aggregation servers from development and testing deployments. If we can settle on the environment implementation I cannot see why not. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Extending machine-info to include machine roles
On 07/09/2014 12:14 AM, David Timothy Strauss wrote: I don't see much value in choosing a role from a predefined list. Rarely do machines fit into one single, straightforward role. I would disagree here like for one example security wise you want to implement only one primary role per server to prevent roles that require different security levels from co-existing on the same server. (For example the roles of web servers, database servers should be implemented on separate servers.) as well as for other practical deployment practices. It would be more useful to support machine tags/labels/roles that map to units, especially if that's dynamically configurable using, say, DHCP(v6). Then, something may be WantedBy=nameserver.role. That would support both livestock deployments with a standardized /usr and pet deployments where admins sign on and may enable roles shipped with the distribution. I think this would overlap with targets and we really should be very restrict on introducing new type units and basically what I was thinking was the other way around. Then again, I don't see how those would be different from shipping more unit.target files and adding some method to dynamically enable them. The general idea I had in my mind was to define primary role or machinerole then trying to get us to agree on standardize predefined set of roles. If we manage to do that, introduce rolefulfilment= in units which we would define those standardized predefined set of roles as in for httpd.service we might have rolefulfilment=web server, for postgresql, rolefulfilment=database server etc. so you could list/query etc the machine primary role and at the same time list the daemon/service who fulfills that role As well as all the other running service role fulfilment on the host and maybe introduce ConditionRoleFulfilment= or ConditionRole= if valid use cases existed for that etc. That's basically how I pictured the role implementation and from my point of view if we cant standardized on predefined set of roles there is no point in implementing it since we cant properly integrate roles with units JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Deployment/environment names [was: Re: [PATCH 2/4] Add ENVIRONMENT to hostnamed]
On 07/09/2014 01:05 AM, j...@joshtriplett.org wrote:
On Tue, Jul 08, 2014 at 10:45:11PM +, Jóhann B. Guðmundsson wrote:
On 07/08/2014 10:45 PM, Josh Triplett wrote:
[Responding to this version because the latest thread hasn't appeared in
the mbox archives yet. The comments apply equally well to the latest
version, Add DEPLOYMENT to hostnamectl.]
On Tue, Jul 08, 2014 at 12:38:50AM +, Jóhann B. Guðmundsson wrote:
+static bool valid_environment(const char *environment) {
+
+assert(environment);
+
+return nulstr_contains(
+development\0
+staging\0
+production\0,
+environment);
+}
Can we please*not* attempt to limit or standardize this particular
set of machine roles? As already demonstrated in the previous thread,
people have all sorts of staged deployment strategies. Furthermore,
the concept of a machine role shouldn't be limited to service deployment
strategies.
Roles != the environment they run in.
I'm not trying to bikeshed over the naming of the variable itself. I'm
arguing that standardizing this particular bit of metadata won't work
well when so many different deployment strategies exist. Thus, rather
than having a fixed set of keywords, I'd propose simply saying this
contains keywords, and leaving the specific keywords up to the admin.
If you attempt to standardize production/development/staging, you'll
either end up with a model that only works for a small subset of
deployments, or you'll end up adding twelve more keywords, at which
point you might as well have just said use whatever keyword you like.
The 4 tier covers the majority of the models since more or less the
entire internet recommend three tier model including M$ [1]
Anyone wanting to extend that further can do so using the
PRETTY_HOSTNAME=
This patch is very specific to deployment environment and to solve a
very specific long standing problem and to achieve that we need to a
standardize, if we dont we can just as well drop this patch since in the
long run we cannot introduce something like ConditionDeployment= like
David mentioned and it kinda defeat's my purpose working in this in the
firsplace...
1. http://msdn.microsoft.com/en-US/library/cc982570%28v=bts.10%29.aspx
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Extending machine-info to include machine roles
On 07/09/2014 08:33 AM, Tollef Fog Heen wrote: ]] Jóhann B. Guðmundsson If we manage to do that, introduce rolefulfilment= in units which we would define those standardized predefined set of roles as in for httpd.service we might have rolefulfilment=web server, for postgresql, rolefulfilment=database server etc. so you could list/query etc the machine primary role and at the same time list the daemon/service who fulfills that role It's not useful to know that a machine is a database server. It's useful to know if it's a postgres server or a mysql server or an oracle server, be it for monitoring or for connecting to it. Yes it is and if you dont see the benefits of knowing the roles of your machine or containers and using roles in your infrastructure I cannot help you. Making statement like this just because they might not be useful to your usecase scenario or workflow is simply silly. My best advice to you if this would get implement is simply dont use roles. 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 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 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 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 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
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
Re: [systemd-devel] Misc patches from the Debian systemd package
On 07/16/2014 10:09 AM, Jon Severinsson wrote: Hi I'm part of the team working on updating the Debian systemd package to v214. As part of that work I have been rebasing and updating the Debian specific patches, and found several that might be appropriate for upstream. While I'm not the original author of these I have been rebasing and updating them, so while most the credit goes to the original autors, any blame should fall on me :-P Given that there already has been Debian developer involved with pushing and integrating systemd into Debian so I have to ask are you sure these patches are not downstream with Debian simply because they are Debian specific or atleast at this point I would think they would have been submitted and merged already if they where not... JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Misc patches from the Debian systemd package
On 07/16/2014 01:56 PM, Jon Severinsson wrote: Well, I did filter out 30 Debian-specific hacks, 40 downstream distribution specific hacks for just component in Debian ( and one init system ). It would be interesting to see how much added maintenance burdens takes place in the Debian community for the sake of choice. You dont happen to know if Debian collects that data do you? JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] lastlog and friends
On 07/29/2014 07:28 PM, Lennart Poettering wrote: Not sure where precisely that tool should actually live though. I am tempted to say it should just be a one or two additional verbs for loginctl (which should gain some journal integration anyway, for example to show log messages of a specific session and suchlike). Hmm... Does it really need two new verbs? Cant list-sessions and list-users simply list active for the active user(s) and show timestamps for the rest which should cover the usefulness of who,last and lastlog? ( It's a bit redundant info seeing who has never logged as well as seeing who has ) loginctl list-sessions SESSIONUID USER SEATLast Active 1 1000 johannbg seat0ACTIVE 1 1001 suzyseat0$DATE And equivalent for list-users. I guess if that's not good enough show-active, show-last could be added to list-sessions, list-users JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] sysv: order initscripts which provide $network before network.target
On 07/23/2014 11:04 AM, Lukas Nykryn wrote: Due to recent changes where $network maps to network-online.target Ah so that's why people are experiencing slowdown and breakage, you probably can close few bugs in bz.rh due to this change and from my pov network-online should just have been left to be enable in Fedora by the administrator as it started out to be the case... JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Support for pre-restart check
On 07/30/2014 10:22 AM, Ansgar Burchardt wrote: Hi, while looking at how to convert sysvinit scripts to service files in Debian, I noticed that some scripts do an additional sanity check during the restart action. That is, they run an extra command to validate the configuration and only restart the service on success. Systemd doesn't seem to provide such an option so far. Would you think this is something one would like to see? If yes, what about the following idea: Add an ExecRestartPre option in the [Service] section. These commands are executed when a restart is requested, before the service is stopped. If they fail, the restart is aborted with an error. Re-sending to list due to simple clicking reply not reply-list mistake. This has been discussed before and check the archive for that discussion but the bottom line is that this is not needed we already have ExecStartPre=, ExecStartPost=, ExecStop=, ExecStopPost=, or ExecReload= which cover those usecases JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Support for pre-restart check
On 07/30/2014 12:09 PM, Lennart Poettering wrote: On Wed, 30.07.14 12:22, Ansgar Burchardt (ans...@debian.org) wrote: Hi, while looking at how to convert sysvinit scripts to service files in Debian, I noticed that some scripts do an additional sanity check during the restart action. That is, they run an extra command to validate the configuration and only restart the service on success. Systemd doesn't seem to provide such an option so far. Would you think this is something one would like to see? If yes, what about the following idea: Add an ExecRestartPre option in the [Service] section. These commands are executed when a restart is requested, before the service is stopped. If they fail, the restart is aborted with an error. This has been a TODO item since a long time. The usecase seems valid. We discussed this either here on the mailinglist, in a bug report in bz.rh or in one of the hackfest and it's on that TODO list is there because in the beginning I thought this was required but after we discussed this the behaviour and after going through the more or less all of the legacy sysv initscripts in Fedora simply using ExecStartPre and ExecStop covered this but by all means introduce this if you no longer think that is the case. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Support for pre-restart check
On 07/30/2014 12:02 PM, Reindl Harald wrote: they don't Perhaps not in your world which seems to differ from many but in the world that the guy that went through and migrated around 800 legacy sysv initscript you want the exact same check run before the service is started and we already cover that with ExecStartPre= And of those 800 it was exception not a rule if those legacy sysv initscript simply did not call stop/start on restart... Ansgar Burchardt will need to post the initscript he's migrating so we can see if it actually provides an valid usecase to implement this I would be very surprised if it actually did... JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Support for pre-restart check
On 07/30/2014 12:34 PM, Reindl Harald wrote: *how* should that both help in calling apachectl -t*before* stop the service and in case of a error-repsonse keep it running? ExecStartPre= takes care of the startup check as in the usecase when the unit is not running and you initially configured the Apache daemon Adding ExecStop= before actual ExecStop= line to stop the daemon takes care of preventing you from restarting you if you made configuration changes while the daemon/services was running should not continue with the stop process if the ExecStop command fails. Anyway beside that point daemon,services that actual come with configuration file syntax checkers like apache does ( maybe in what 20 or so range ) , are few and far between let alone those configuration syntax checker that actually exist out there fail properly if they do... JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Support for pre-restart check
On 07/31/2014 12:16 AM, Colin Guthrie wrote: I think the use case is pretty clear tho'. Config (or general machine state) has transitioned from working to broken in the time since the service was started and while it's really not a nice situation to find yourself in (relying on a running service not crashng!), this at least helps avoid nasty consequences for the most part while you work to fix things. The use case administrator want, is fixing their own lazyness and incompetence not having to run the configuration syntax checker by hand after they made changes to the configuration for one of those handful of daemon/service that actually come with those. But let's continue on this path once that is implemented they want to be notified one way or another why the service failed to be restarted as in the actual failed line of the configuration mistake they made so they can go and fix it ( and apachctl -t purpose is... ) but that cannot be implemented in the status output because. remember they where to lazy to run the configuration syntax checker by hand after the change they made so they are to lazy to run systemctl status foo so you do realize the underlying problem for this cannot be solved right? People tried in the past doing so by writing massive initscript that never worked... Now that broken machine state is not limited to configuration changes since it could also happen due to an bad update or incompatable update ( configuration file syntax changes between releases, apache 2.2 vs 2.4 for example ) so the only way you can try to solve this is by introducing a fake restart of the service which cannot be manually defined what is but has to be built in with the know of only turning it on or off for type units which covers *something* has changed can the service be restarted *safely* afterwards, if it does restart the service. Bottom line if the intent is for systemd to solve the use case you stated the solution for this need to be a permanent fix that covers all service/daemons not yet another line that leads to administrators define another command to take care of that... JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Support for pre-restart check
On 07/31/2014 12:41 AM, Michael Biebl wrote: 2014-07-30 14:34 GMT+02:00 Reindl Harald h.rei...@thelounge.net: ExecStopPre would be better suited as the pre-restart check because it would achieve the goal and also prevent stop a service until it's configuration is fixed - that catchs cases where you stop something for whatever reason and expect it would be started at the next boot I don't think that would be a wise thing to do. If I want to reboot my system, it shouldn't fail to reboot because of a buggy apache configuration. Apache should shutdown and simply fail to start on next reboot. Right the solution to this cannot interfere with normal starting and shutdown and wont be solve with introducing yet another Exec* line in one form or another. What is needed to solve this problem ( as in to reliably restart an application ) as far as I can tell is to introduce something like pre restart check which tries to start another instance of the service in an isolated application container, returns true if successful, is enabled per service, perhaps could be extended per container as well and only executed when systemctl restart/reload ( or implemented in try-restart ) $foo is run. Providing patches for anything less then what I mention here above is a waste of time from my point of view since it wont solve the underlying problem. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] right way to log to rsyslog/syslog only?
On 08/07/2014 12:06 PM, Frantisek Hanzlik wrote: Hi, I just install Fedora 20 (with systemd 208) and want log, if possible, without journald, only to rsyslog. It's not possible. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] right way to log to rsyslog/syslog only?
On 08/07/2014 04:12 PM, Leonid Isaev wrote:
Perhaps understanding why you're allergic to the journal would help in
figuring out solutions to the actual underlying problem.
There is nothing wrong with the journald per se, but it's not a replacement for
the classic syslog
Yes it is.
And there is a very much difference in using one of the traditional
message printing APIs like syslog for logging as in doing this
#include syslog.h
int main(int argc, char *argv[])
{ syslog(LOG_NOTICE, Hello World);
return 0;
}
Vs using the journal's native APIs as in this.
#include systemd/sd-journal.h
int main(int argc, char *argv[])
{ sd_journal_print(LOG_NOTICE, Hello World);
return 0;
}
Arguably one of journals major/only shortcoming compared to what's out
there is it's lack the ability to send syslog messages over the syslog
network protocol but I think it's just a matter of time until it does,
since it's arguably unavoidable ( think for example containers here and
I would be amazed if submitted patches would be rejected that would add
that )
But I guess you can hack yourself around that shortcoming by turning off
persistent storage ( that is if you dont want to store logs as well on
the host ) and run something like
journalctl -o short -f | nc ip -u 514 -w 1
that avoids the problem having two loggers running on the same host (
like using syslog-ng or rsyslog alongside journal ) to solve that
particular problem.
JBG
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] right way to log to rsyslog/syslog only?
On 08/07/2014 07:44 PM, Leonid Isaev wrote: Hi, On Thu, Aug 07, 2014 at 06:11:39PM +, Jóhann B. Guðmundsson wrote: On 08/07/2014 04:12 PM, Leonid Isaev wrote: Perhaps understanding why you're allergic to the journal would help in figuring out solutions to the actual underlying problem. There is nothing wrong with the journald per se, but it's not a replacement for the classic syslog Yes it is. Hmm, reading my message above, I can see that it wasn't clear enough -- sorry. Perhaps an example can clarify things. Take dnsmasq which under normal operation logs _lots_ of DHCP-related messages, even on a tiny network of ~20 (crappy Android) devices. These messages fall into 2 categories: routine (log_level info -- DHCPREQUEST, DHCPACK, etc.) and security-related (log_level warn -- DNS rebind attacks e.g.). I want the former to be volatile (stored in /run/log), while the latter on-disk (in /var/log). While there are many ways to accomplish this with rsyslog/syslog-ng filters, Give me an actual working example how this is solved using rsyslog/syslog-ng filters JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] right way to log to rsyslog/syslog only?
On 08/07/2014 07:32 PM, Mantas Mikulėnas wrote: On Aug 7, 2014 9:11 PM, Jóhann B. Guðmundsson johan...@gmail.com mailto:johan...@gmail.com wrote: Arguably one of journals major/only shortcoming compared to what's out there is it's lack the ability to send syslog messages over the syslog network protocol but I think it's just a matter of time until it does, since it's arguably unavoidable ( think for example containers here and I would be amazed if submitted patches would be rejected that would add that ) Yes, it has been mentioned a couple of times that dealing with the various syslog protocols is the job of a syslogd, not the journal. (That said, there already are some tools to push raw journal messages over the network...) Raw journals or journal only solution is not acceptable in large environment using mixed OS and or even just mixed Linux distributions and their releases ( think debian stable and centos7 for example ) so it's necessary for journal to be able to forward the logs over the syslog network protocol But I guess you can hack yourself around that shortcoming by turning off persistent storage ( that is if you dont want to store logs as well on the host ) and run something like journalctl -o short -f | nc ip -u 514 -w 1 that avoids the problem having two loggers running on the same host ( like using syslog-ng or rsyslog alongside journal ) to solve that particular problem. I don't understand why running two programs that provide distinct functions is called a problem. Host resources I also don't understand why running *three* programs (journald, journalctl, netcat) that only do a halfassed job compared to rsyslog *isn't* a problem anymore... You do realize what I proposed was a workaround right? JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] right way to log to rsyslog/syslog only?
On 08/07/2014 08:41 PM, Leonid Isaev wrote: Sorry for a long reply... No problem I needed to see how you were thinking/doing this. So basically you want to log everything to /run ( volatile ) and filter out everything above a certain log-level and store that persistent in it's own journal ( basically store the output from this journalctl -p err persistently ) Or you want to log everything to /run ( volatile ) and filter out everything above a certain log-level for a specific user,unit,command whatever and store that persistent in it's own journal. ( using your example store the output from this journalctl -p err _SYSTEMD_UNIT=dnsmasq.service persistently ) One of the Samsung guys proposed something similar to the former a while back ( and I think he signed himself up to it ) but as far as I can tell his work has not landed yet. ( afaikt requires changes to journald-server.c|||introduce something like SplitMode=priority-err |etc ). I would not expect anything like this soon since Andy NAK their SCM_PROCINFO stuff and they are probably to busy re-writing/re-implementing it as SCM_IDENTY together with him but one of the Samsung guys can comment if they had started working on or had otherwise looked into this but as things stand now this cannot be done afaikt. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] right way to log to rsyslog/syslog only?
On 08/07/2014 10:42 PM, Leonid Isaev wrote: Thanks for letting me know aboout this work, but from the above description it seems rather limited. I brought up the log-levels only as an example. In practice one needs to be able to filter using_any_ message attribute. I just used the example to reply to your own so they are equally limited in that manner see systemd.journal-fields(7) For instance, message body (iptables traffic, output of frequently-run systemd timers -- drop the useless Start/Stop-type messages, HostAp logs) and facility (kernel/daemon/...). And you have configured syslog-ng and rsyslog to do that for you and how much time did it take? I can understand the need for very powerful filter capabilities which can be used when needed and the journalctl already possesses those. In the sample you showed me how you are doing things you did so in three steps 1 configure syslog-ng 2 parse through files with log level lower then error, parse through files with error But I myself am a lazy old fat admin that has been administrating server for what 10 years now and prefer to use this journalctl -p err _SYSTEMD_UNIT=dnsmasq.service which yields the same result in one step ( for each log level ) and I dont have to worry about installing or setting up anything basically I prefer I simply asking the journal to give me the information I need when I need it. But why do you need to log all of this into their own persistent journal files, what practical problem are you hoping to solve,achieve or gain by that? JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] runtime directories for services vs. tmpfiles
On 07/16/2013 04:53 PM, Lennart Poettering wrote: On my (pretty much fully converted) Fedora I currently have 20 tmpfiles snippets around. I doubt on an everage Debian machine this would grow much larger. May 40 or so, but that's still not much. Well we have only migrated what 400 components out of ca 550 Debian has twice that much ( around 1100 - 1200 I think ) but yes that number seems to fairly accurate which means it might actually be better pay off to simple fix those 20 daemons that require the tmpfiles in the first place. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] runtime directories for services vs. tmpfiles
On 07/16/2013 06:26 PM, Lennart Poettering wrote: I discussed this a bit more with Kay on the phone. Here's what we'd propose: I'd be very conservative regarding adding full tmpfiles support into unit files directly. Instead, I'd suggest adding two very minimal, very specific new unit file settings: RuntimeDirectory= RuntimeDirectoyMode= What exactly are we trying to solve here which should not be fixed upstream in the daemons themselves? JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] runtime directories for services vs. tmpfiles
On 07/16/2013 07:34 PM, Kay Sievers wrote: On Tue, Jul 16, 2013 at 9:28 PM, Jóhann B. Guðmundsson johan...@gmail.com wrote: On 07/16/2013 06:26 PM, Lennart Poettering wrote: I discussed this a bit more with Kay on the phone. Here's what we'd propose: I'd be very conservative regarding adding full tmpfiles support into unit files directly. Instead, I'd suggest adding two very minimal, very specific new unit file settings: RuntimeDirectory= RuntimeDirectoyMode= What exactly are we trying to solve here which should not be fixed upstream in the daemons themselves? Stuff that uses User= cannot be fixed in the daemon itself, at the time it runs, systemd itself has already taken away the privileges to create these directories. We increase unit complexity with each option we add so I would suggest unless it's absolutely necessary to just stick with just tmpfiles to handle this. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] runtime directories for services vs. tmpfiles
On 07/18/2013 12:51 AM, Lennart Poettering wrote:
Fedora is not completely converted, but here are some stats.
$ repoquery --whatprovides '/etc/rc.d/init.d/*' --qf %{name} | sort -u |
egrep -v '(-sysvinit|-initscript|-sysv)$' | wc -l
139
Well even that number is not accurate since we have several migrated
components being stuck in bugzilla and not being packaged and shipped
which is the biggest problem we are faced with in the migration process
( and have been faced with from the start ) as in not the actual
migration but to get maintainers of those components, package and ship
the units ( and quite few of those remaining ones seem to unmaintained ).
If everything goes as planned we should finish migrating those this
release cycle ( F20 ).
JBG
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] units: disable kmod-static-nodes.service in containers
On 08/21/2013 11:00 AM, Tom Gundersen wrote: Hi Zbyszek, Regarding http://cgit.freedesktop.org/systemd/systemd/commit/?id=219061dc524368179b2e65cfe91d4d6b23396ba8: Would it make sense to use ConditionCapability=CAP_MKNOD instead? This would match what is done in systemd-tmpfiles-setup-dev.service. The effect is currently the same (I think), but might as well be consistent in case things change in the future. Adding ConditionCapability=CAP_MKNO to the kmod-static-nodes.service in the test container I got here running does not trigger kmod-static-nodes.service: main process exited, code=exited, status=203/EXEC [FAILED] Failed to start Create list of required static device nodes for the current kernel. See 'systemctl status kmod-static-nodes.service' for details. Unit kmod-static-nodes.service entered failed state. Error at bootup. So this indeed works to fix that JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] units: disable kmod-static-nodes.service in containers
On 08/21/2013 02:02 PM, Zbigniew Jędrzejewski-Szmek wrote: Hm, Jóhann, are you saying that my ConditionCapability=CAP_MKNOD does not work, or that ConditionVirtualization=!container that I added does not work? Or that it works? I'm was confirming adding ConditionCapability=CAP_MKNOD to the kmod-static-nodes.service worked to fix this. I also agree with Tom that we should use that instead for consistency ;) JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] F19 network device naming
On 10/23/2013 07:02 PM, Nicholas Majeran wrote: I would expect to see enp65s0f0 and enp65s0f1, like the e1000e. Read the source luke [1]... JBG 1. http://cgit.freedesktop.org/systemd/systemd/tree/src/udev/udev-builtin-net_id.c#n20 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Power aware units
On 11/03/2013 02:36 PM, Bastien Nocera wrote: In addition to that, would it make sense for distributions to start porting their cron jobs to use systemd? in Fedora we already have started that migration process for relevant units ( not all packages that contain ron jobs should be/will be migrated ). I've just been waiting ( since July/August ) for the first step of that migration to be completed as in those packages that will not be migrated fix their dependency on crontabs. Ones those packagers apply the patches I sent them in that regard I will start the actual cron to timer units migration. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC][PATCH] networkd: add a basic network daemon
On 11/06/2013 03:00 PM, Lennart Poettering wrote: On Wed, 06.11.13 14:14, Mantas Mikulėnas (graw...@gmail.com) wrote: On Wed, Nov 6, 2013 at 1:32 PM, Lennart Poettering lenn...@poettering.net wrote: I have my suspicions that that won't work out since there already are quite a few properties for addresses, no? There's scope, flags, label. For Point-To-Point stuff the address needs to be paired with a local one, and in other cases with a broadcast address. We should at least try to normalize this into different sections, no? Hmm, when is explicitly setting the broadcast address ever necessary? There are some cases like that in hosting setups where people play games with this so that they can use tiny subnets while packing hosts as close as they can wihouting losing one (or two) adresses in each subnet for broadcast (and as network address)... Interesting first time I hear of this and I assume these games became unnecessary with ipv6 thus no need to keep Broadcast around no? JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC][PATCH] networkd: add a basic network daemon
On 11/06/2013 12:33 AM, Tom Gundersen wrote: [Match] MACAddress= Path= Driver= Type= Name= [Network] Description= [IP] Gateway=192.168.1.1 Address=label@192.168.1.23/24 Address=fe80::9aee:94ff:fe3f:c618/64 Hmm.. Cant we try to follow the same construct as the other units? Something like this perhaps ( I think these for case cover more less the most common parts )... The default device present spawn *when link is detected* unit Type=dhcp network@network device.network [Unit] Description=Network device %I [Service] Type=|dhcp Rest provided by dhcp |The administrator configurable unit Type=Static em1.network [Unit] Description=Network device em1 [Service] Type=static Address=192.168.0.1/24 [Install] WantedBy=multi-user.target The administrator configurable unit Type=bridge bridge0.network [Unit] Description=Network device bridge 0 Master=em1 Slave=em2 [Service] Type=bridge [Install] WantedBy=multi-user.target The administrator configurable unit Type=bridge bond0.network [Unit] Description=Network device bonding 0 Master=bond0 Slave=em1,em2 [Service] Type=bonding Address=192.168.0.1/24 [Install] WantedBy=multi-user.target ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC][PATCH] conf-parser: allow instanced sections
On 11/19/2013 09:20 PM, Tom Gundersen wrote: On Tue, Nov 19, 2013 at 7:07 PM, Colin Guthriegm...@colin.guthr.ie wrote: What I have in mind (though it is not dictated by this patch) is something different (first proposed by Lennart in an earlier thread): [Network] Address=192.168.0.1/24 Address=192.168.0.2/24 Gateway=192.168.1.1 [Address:oneaddress] Address=192.168.0.3/24 Label=three Peer=192.168.1.1 [Address:anotheraddress] Address=192.168.0.4/24 Label=four In this case we'll configure four addresses. The two first ones could also have been expressed as: [Address:foo] Address=192.168.0.1/24 [Address:bar] Address=192.168.0.2/24, but we allow putting them directly in the [Network] section rather than in a named [Address] section as a shorthand. Notice that if we simply did [Address] Address=192.168.0.3/24 Label=three Peer=192.168.1.1 [Address] Address=192.168.0.4/24 Label=four, that wouldn't work as it is (at least currently) equivalent to [Address] Address=192.168.0.3/24 Label=three Peer=192.168.1.1 Address=192.168.0.4/24 Label=four, which is why we need to give the secitons unique names. Arent's we sacrificing significant part of simplicity in units going down this path as opposed to have users use per unit interface instances units and templating/instances ? JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd unit review requested
On 12/05/2013 06:50 AM, Peter Hutterer wrote: ExecStartPre=/usr/sbin/modprobe wacom_w8001 Add a configuration file called wacom-w8001.conf to /etc/modules-load.d directory with the following content to load the module ( /etc/modules-load.d/wacom-w8001.conf ) # Load wacom_w8001 at boot wacom_w8001 If necessary add any additional module options to same named file under /etc/modprobe.d directory if necessary as in... ( /etc/modprobe.d/wacom-w8001.conf ) #Wacom w8001 module options options foo bar Never use a systemd unit to call modprobe. Each time you do so someone's beer goes flat... JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd unit review requested
On 12/05/2013 12:28 PM, Michael Biebl wrote:
2013/12/5 Jóhann B. Guðmundssonjohan...@gmail.com:
On 12/05/2013 06:50 AM, Peter Hutterer wrote:
ExecStartPre=/usr/sbin/modprobe wacom_w8001
Add a configuration file called wacom-w8001.conf to /etc/modules-load.d
directory with the following content to load the module
( /etc/modules-load.d/wacom-w8001.conf )
# Load wacom_w8001 at boot
wacom_w8001
Well, this loads the kernel module unconditionally, though. Even for
users which don't have that hardware. So this approach isn't that
great.
It also depends on the wacom_w8001 and how it reacts when it's loaded
and no hardware is present.
Peter, couldn't this module be autoloaded?
I'm not that familiar with udev policy regarding rules rule but I would
think that if you autoload module you tie the startup of the systemd
unit to the module being loaded ( if the intent is to trigger a unit )
So we need an udev wacom-serial-driver rule that might look like this
for the wacom serial devices
ACTION==remove, GOTO=drivers_end
ENV{MODALIAS}==?*, RUN{builtin}=kmod load $env{MODALIAS}
SUBSYSTEM==tty|pnp, SUBSYSTEMS==pnp, ATTRS{id}==WACf*,
ENV{ID_MODEL}=Serial Wacom Tablet $attr{id}, ENV{ID_INPUT}=1,
ENV{ID_INPUT_TABLET}=1, ENV{NAME}=Serial Wacom Tablet $attr{id}
,RUN{builtin}=kmod load wacom_w8001
SUBSYSTEM==tty|pnp, SUBSYSTEMS==pnp, ATTRS{id}==FUJ*,
ENV{ID_MODEL}=Serial Wacom Tablet $attr{id}, ENV{ID_INPUT}=1,
ENV{ID_INPUT_TABLET}=1, ENV{NAME}=Serial Wacom Tablet $attr{id}
,RUN{builtin}=kmod load wacom_w8001
LABEL=drivers_end
Followed by an systemd rule that looks something like this
SUBSYSTEM==module, KERNEL==wacom*, TAG+=systemd,
ENV{SYSTEMD_WANTS}+=wacom-inputattach@%k.service
And the modprobe would be dropped from that unit file but as I say I'm
not all that familiar with udev policy rules and I personally had not
planned on mastering udev until I started the cleanup process in Fedora
which might never happen today thanks to the that WG process.
JBG
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd unit review requested
On 12/05/2013 01:57 PM, David Timothy Strauss wrote: On Thu, Dec 5, 2013 at 3:53 AM, Jóhann B. Guðmundsson johan...@gmail.com wrote: Never use a systemd unit to call modprobe. And, even if you did, modprobe would be Type=oneshot (maybe also with RemainAfterExit=true), definitely not Type=simple. You never and I mean never should load or unload modules in systemd units so it's irrelevant what those type should be. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Is there any way to stop services in cgroup?
On 01/02/2014 02:02 PM, Tony Seo wrote: Hello. I wonder that systemd has a method to stop all services in specific cgroup. Actually, I have looked for a method to stop all services as the same time. I have searched many manual in systemd site. I couldn't find any method to stop all services which I want to stop. I need some advices for solving this problem. You would create a custom target and have all services bind to that target then you can simply run systemctl stop my-custom.target which would stop a.service b.service c.service that are bound to that target as opposed to having to run systemctl stop a.service b.service c.service JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Add SELinuxContext configuration item
On 12/28/2013 01:30 PM, Lennart Poettering wrote: On Fri, 27.12.13 23:26,m...@zarb.org (m...@zarb.org) wrote: From: Michael Schererm...@zarb.org This permit to let system administrators decide of the domain of a service. This can be used with templated units to have each service in a différent domain ( for example, a per customer database, using MLS or anything ), or can be used to force a non selinux enabled system (jvm, erlang, etc) to start in a different domain for each service. Hmm, so far (as I understood it) the SELinux guys always wanted to make sure that label configuration stays in the the selinux database and nowhere else. Right and if you add this you need to add something for the other security solutions as well ( apparmor etc ). This introduces yet another place for administrators to look at while debugging problems so the question to ask here is. Is adding this ability to unit files the right way to solve what's trying to be solved here? JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Add SELinuxContext configuration item
On 01/03/2014 10:56 AM, Michael Scherer wrote: Le vendredi 03 janvier 2014 à 00:58 +, Jóhann B. Guðmundsson a écrit : On 12/28/2013 01:30 PM, Lennart Poettering wrote: On Fri, 27.12.13 23:26,m...@zarb.org (m...@zarb.org) wrote: From: Michael Schererm...@zarb.org This permit to let system administrators decide of the domain of a service. This can be used with templated units to have each service in a différent domain ( for example, a per customer database, using MLS or anything ), or can be used to force a non selinux enabled system (jvm, erlang, etc) to start in a different domain for each service. Hmm, so far (as I understood it) the SELinux guys always wanted to make sure that label configuration stays in the the selinux database and nowhere else. Right and if you add this you need to add something for the other security solutions as well ( apparmor etc ). I do not see why we need to equally support all MAC frameworks for each change we do. Because people will start to expect being able to configure that there. And while I am familiar enough with apparmor to create a equivalent setting ( and plan to do ), I have no idea on how to translate the concept for smack, ima and tomoyo. In fact, the mere fact that tomoyo is not handled at all already show that we do treat all security framework as equal. How do you suppose we deal with man pages if selinux is not installed but still refer to this. Wont users also need to check if selinux is enabled or not in the unit file? Should systemd warn users if selinux is not installed,enabled and fail or? This introduces yet another place for administrators to look at while debugging problems so the question to ask here is. Is adding this ability to unit files the right way to solve what's trying to be solved here? As Dan said, yes. I would prefer if app writers do not start hard coding SELinux contexts into the unit file I hardly call that solid yes and this is what will start taking place if this is introduced into the unit files. However, as said, there is some case where the approach of making the transition based on the executed filename is not sufficient. For example, the erlang vm, the jvm, etc, because each software will run in the same domain, in different processes, because that's always the same jvm being used. See the bug I mentioned before. Now, if you have a more precise feedback and/or a better proposal, Add this to the daemon startup itself ( the confile or the code ) and or use runcon in an exec start pre section to set this up. In anycase Lennart decides this to me this seems like a workaround being put in systemd for a limitation in selinux or the concept there of with the added complexity for administrators. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Cannot see the whole picture
On 01/26/2014 09:16 AM, Roelof Wobben wrote: In some of my earlier mails I have said that I try to port a modular live slackware based distro (Porteus) to systemd as a personal project. Dropline an Gnome based slackware distribution [1] keeps a page [2] with what's needed for systemd integration on top of the traditional Slackware system which you should be able to go through to achieve just that. You can just contact them if that page is not enough since they have most likely solved all your problems already. JBG 1..http://www.droplinegnome.org/ 2. http://sourceforge.net/apps/trac/dropline-gnome/wiki/DroplineGnome3_10_Systemd ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] udev: Adding zram to inappropriate block device
---
rules/60-persistent-storage.rules | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/rules/60-persistent-storage.rules
b/rules/60-persistent-storage.rules
index a4d009a..154ffd9 100644
--- a/rules/60-persistent-storage.rules
+++ b/rules/60-persistent-storage.rules
@@ -14,7 +14,7 @@ ACTION==add, SUBSYSTEM==module, KERNEL==block,
ATTR{parameters/events_dfl_
SUBSYSTEM!=block, GOTO=persistent_storage_end
# skip rules for inappropriate block devices
-KERNEL==fd*|mtd*|nbd*|gnbd*|btibm*|dm-*|md*, GOTO=persistent_storage_end
+KERNEL==fd*|mtd*|nbd*|gnbd*|btibm*|dm-*|md*|zram*,
GOTO=persistent_storage_end
# ignore partitions that span the entire disk
TEST==whole_disk, GOTO=persistent_storage_end
--
1.8.5.3
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] udev: Adding zram to inappropriate block device
On 02/02/2014 01:39 PM, Alexander E. Patrakov wrote: The patch is obviously harmless. However, I am not convinced that it is needed, because in my setup (without this patch) there are no links in /dev/disk pointing to any zram device. You can change my opinion by providing configuration files that do result in such links being created by systemd. udev seems to have a race condition with swapon to see which can open /dev/zram0 first, causing swapon to fail. ( seems to be most noticeable on arm devices one out of every 7 times or something ) and this patches udev's persistent storage rules to avoid probing any zram devices. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] udev: Adding zram to inappropriate block device
On 02/02/2014 02:27 PM, Alexander E. Patrakov wrote: 02.02.2014 20:18, Jóhann B. Guðmundsson wrote: On 02/02/2014 01:39 PM, Alexander E. Patrakov wrote: The patch is obviously harmless. However, I am not convinced that it is needed, because in my setup (without this patch) there are no links in /dev/disk pointing to any zram device. You can change my opinion by providing configuration files that do result in such links being created by systemd. udev seems to have a race condition with swapon to see which can open /dev/zram0 first, causing swapon to fail. ( seems to be most noticeable on arm devices one out of every 7 times or something ) and this patches udev's persistent storage rules to avoid probing any zram devices. Thanks, this explains why the patch is needed. But this should really be in the commit message :) Regarding the future of zram support in systemd should that not be added to fstab-generator and swap, with unit type ending in .zswap? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] udev: Adding zram to inappropriate block device
On 02/03/2014 09:36 AM, Holger Schurig wrote: with unit type ending in .zswap No, not another unit type. Instead better amend .swap unit types to also know about ZRAM. However, isn't this a bit early? Shouldn't move ZRAM first move out of staging? Ofcourse but when it does move out of staging we could have sorted this implementation detail out which basically boils down to where to set the partition sizes for the zram partitions ( tmpfiles.d/zram-conf or /etc/zram.d/zram-conf ) Do we want a script that basically just set this size based on available memory per core in the udev rule. factor=25 num_cpus=$(grep -c processor /proc/cpuinfo) memtotal=$(grep MemTotal /proc/meminfo | sed 's/[^0-9]\+//g') mem_by_cpu=$(($memtotal/$num_cpus*$factor/100*1024)) echo $mem_by_cpu There are bunch of things to consider JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] https://bugzilla.redhat.com/show_bug.cgi?id=1047614
On 02/12/2014 07:37 PM, Reindl Harald wrote: these are all regressions from F19 to F20 https://bugzilla.redhat.com/show_bug.cgi?id=1023820 https://bugzilla.redhat.com/show_bug.cgi?id=1010572 https://bugzilla.redhat.com/show_bug.cgi?id=1057811 https://bugzilla.redhat.com/show_bug.cgi?id=1057618 https://bugzilla.redhat.com/show_bug.cgi?id=1023788 sometimes it feels like systemd-upstrearm has a release-and-forget-strategy and don't care about the downstream distributions and issues there nor how bad the impact of them for how long is I'm not so sure you are aware of this but the major part of systemd maintenance in Fedora is and has been handled by Zbyszek for the past year which is doing that on his own free time and before him it was Michal who is a Red Hat employee but working on completely different thing then systemd and he was also doing systemd downstream distribution maintenance on his own free time. Both of them have been doing good job of maintaining systemd in the distribution and been extremely conservative in their maintainership so I suggest you keep your tone down towards people contributing their own free time to the project. With regards to those RHEL bugs I suggest you follow Red Hat's official procedure dealing with those and file a support case after all that's what you are paying them for. Ranting on upstream mailinglist will get you nowhere regardless if that upstream is partially on Red Hat's payroll or not... JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [HEADS-UP] It's release time!
On 02/18/2014 05:03 AM, Zbigniew Jędrzejewski-Szmek wrote: A related question is wheter Fedora should get this release in rawhide: I think yes, but with --disable-kdbus --enable-compat-libs. It's nice thathttps://bugzilla.redhat.com/show_bug.cgi?id=1065572 got fixed just in time. Rawhide is the place for breakage and we want to catch any related bugs sooner rather then later so why disable kdbus? JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Not sure if I am doing something wrong or if this is a bug.
On 07/30/2012 09:13 PM, Daniel J Walsh wrote: Is this failing to see the /etc/systemd/system/httpd.service file? Or is the include failing? Include might failing since there is currently no way to replace existing entry with another one. You can easily confirm or deny if that's the case by simply copy the existing unit and set PrivateTmp to false JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] List all available units
On 08/07/2012 02:35 PM, Václav Pavlín wrote: https://bugzilla.redhat.com/show_bug.cgi?id=790768 I thought Harald had already fixed this one but perhaps Lennart never committed it. See [1]. JBG 1.http://lists.freedesktop.org/archives/systemd-devel/2012-February/004573.html ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] service: allow service to inhibit respawn with special return code
On 08/08/2012 05:30 PM, Lennart Poettering wrote: On Tue, 07.08.12 16:01, David Strauss (da...@davidstrauss.net) wrote: On Sat, Aug 4, 2012 at 4:46 AM, Lennart Poettering lenn...@poettering.net wrote: (But please, don't implement this bit just yet, let's wait for somebody actually needing this. Note though, that Upstart actually does have functionality like this). There are broken daemons like the cluster support in node.js that return non-zero on clean shutdowns. While this is broken behavior, it seems the systemd standard is to support broken/non-standard behavior with optional settings. (That is, the default in systemd is a well-behaved application.) Hmm, I was kinda waiting for use cases like this. i.e. before we add an option to reconfigure what clean exits are I wanted an explicit request for it, so that we don't end up adding something that is actually unncessary. Added this to the TODO list now. Should not this be fixed in the daemon instead of worked around in systemd? JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Question about After/Before of services
On 08/09/2012 04:28 AM, WANG Chao wrote: Hi, list As you see in the subject, this question comes from a lazy guy like me, who doesn't read the systemd source code at all :P The silly question is if A is configured to 'Wants:B' and 'After:B', will A start exactly after B is finished or after B is started? Yes If A.service unit has Wants=B.service and After=B.service it will be start after B.service has finished starting *unless* B.service unit is Type=oneshot service then it will be started immediately after B.service is has been started not when B.service has finished starting... JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC] logind lid switch inhibitors
On 09/18/2012 05:17 PM, Lennart Poettering wrote: Comments, suggestions? Dont forget the use cases where users simply want to close the lid but still have the machine running with all network connections and what not still running... JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Have timers fire after boot is complete
On 09/27/2012 08:33 AM, Christian Seiler wrote: one of the most-requested features that is not present in systemd currently is a true rc.local-type functionality that runs after all other services. Any particular reason why those user just dont create type oneshot unit then order it as they see fit with after and or before? JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Have timers fire after boot is complete
On 09/27/2012 11:17 AM, Frederic Crozat wrote: Le jeudi 27 septembre 2012 à 11:07 +, Jóhann B. Guðmundsson a écrit : On 09/27/2012 08:33 AM, Christian Seiler wrote: one of the most-requested features that is not present in systemd currently is a true rc.local-type functionality that runs after all other services. Any particular reason why those user just dont create type oneshot unit then order it as they see fit with after and or before? Mostly because many users have no idea after which units they should schedule their target. And they are used to having a run as last script in their distribution Ordering it after the default target should suffice. In Fedora we still support rc.local we just dont ship it by default so if you want/prefer the old behavior. you only need to create it and set it up correctly as in # echo '#!/bin/sh' /etc/rc.d/rc.local chmod 755 /etc/rc.d/rc.local and systemd will pick it but it wont give you the same flexibility as native systemd units can do. (see https://bugzilla.novell.com/show_bug.cgi?id=778715 which links to openSUSE forum on this topic). Out of the four forum samples in comment 2 on this bug, 3 of the forum post ( from the look of it ) are workarounds for genuine bugs and one should belong in a rule-*/route-* files under /etc/sysconfig/network which would be picked up by networking scripts ( given that suse networking scripts support that ) . JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] when will mount / df get fixed?
On 10/01/2012 01:10 PM, Reindl Harald wrote: and how they should do this after the change that there is no flag? dispaly a RANDOM line? Is that not something you should be discussing with them? JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Launching a unit in response to a D-Bus signal
On 10/01/2012 10:53 PM, Mirco Tischler wrote: Systemd isn't really the right place to do network related stuff, imo. Such things are better dealt with in the network connection manager, where the information is already available. NetworkManager has a mechanism to execute custom scripts in /etc/NetworkManager/dispatcher.d on network events. For details take a look at the man page, support for explicit actions on vpn-up/down is mentioned there. Arguably systemd is the correct place under CoreOS to unite and manage network connections JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Launching a unit in response to a D-Bus signal
On 10/02/2012 12:47 PM, Mirco Tischler wrote: How do you do that? systemd doesn't have any support to manage network connections. It lacks information about the state of the network devices and cannot configure them as well. Today systemd cant but in the future it might depending on how things progress. From my point of view an single network management application should be integrated into the init system in this case systemd/CoreOS. It just begs the question to what extent as to complexity. In the end the solution what ever it might be needs to be something that can be light enough to be on embedded but flexible enough to handle complex server environment with the desktop falling somewhere between those two. I'm very well that a lot of people think forking is fun but I just dont tend to agree with that for something that is fundamental part of the underlying OS as network management is and should be from my pov. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] Journal File Format Documentation
On 10/23/2012 06:40 PM, Lennart Poettering wrote: The journal currently cannot do this for you, but what it already can is split up the journal per-user. This is done by default only for login users, (i.e. actual human users), but with the SplitMode= setting in journald.conf can be enabled for system users as well, or turned off entirely. We could extend this switch to allow other split-up schemes. But note that the price you pay for interleaving files on display grows with the more you split things up (O(n) being n number of files to interleave), hence we are a bit conservative here, we don't want to push people towards splitting up things too much, unless they have a really good reason to. If I'm understanding this correctly would it not better simply/suffician support splitting the journal up via cli instead of doing it real time ? JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] Journal File Format Documentation
On 10/23/2012 09:19 PM, Lennart Poettering wrote: Related to the tool you are suggesting I think a tool to merge split off files might be very useful too, to counter the scalability issues of interleaving too many separate files on display. Yeah an extension to the journalctl and probably users would like to do as the part of the process when the journal files get rotated on disk ( rotate -- split ) JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Verbose output option when starting daemons manually
On 11/09/2012 12:23 AM, William Giokas wrote: All, I have been using systemd for a few months now, and I must say, it is a great init system. I myself am no coder, else I would attempt to write something to do just this. One not-dealbreaking thing that I do find lacking is a verbose option for `systemctl start unit`, essentially running `journalctl -f -u unit` (and possibly for multiple dependent units as well). For most services, I feel like this would be a line or two of output just saying It worked! or It broke! but for services like netcfg@, or services that start dependencies, it could be useful to see what's getting started and how it's getting started. Again, feel free to ignore me, I don't know how feasible or practical this would be, but it seems like it would be useful. Again, sorry that I cannot put something together myself to at least show you. Thank you for your time. Not the first and probably not the last that expected that behavior and proposed this. What's lacking is the status to be shown when units are manually started/reloaded/restart/stopped there is just one slight problem implementing that which is you dont want that output when the service is started at boot time or shutdown... perhaps that could be solved by introducing specific boot-start and shutdown-stop switches which would only be used to start unit or shut down units at boot-up/shutdown JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] I have switched libvirt-sandbox containers to use multi-user.target
On 11/20/2012 12:41 AM, Lennart Poettering wrote: On Fri, 16.11.12 15:06, Daniel J Walsh (dwa...@redhat.com) wrote: Isn't there a way to shut off systemV init scripts altogether, it just so happens that we hit one on my machine. But in the field a customer could have an init script and then setup containers and systemd will attempt to start it. I want a way to say don't run SysV Init scripts altogether. Hmm, there is currently no option for that. A semi-dirty trick might be to over-bind-mount /etc/rc.d with something empty? Or he can just simply apply and test the diff for iscsi in [1] and walk around the office and ask all those RH maintainers that maintain iscsi what the freaking hold up is. JBG 1. https://bugzilla.redhat.com/show_bug.cgi?id=714688 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC/PATCH] journal over the network
On 11/20/2012 09:02 AM, Adam Spragg wrote: On Tuesday 20 Nov 2012 01:21:54 Lennart Poettering wrote: My intention was to speak only HTTP for all of this, so that we can nicely work through firewalls. Wait, I thought one of the guiding principles of systemd was to do things The Right Way, and not use ugly workarounds for other people's brokenness. If admins want to send network traffic over a port, and their firewall is preventing them, surely the problem is in the firewall, and the firewall should be fixed? Making everything HTTP-friendly to get around broken firewall policies is an ugly workaround which just helps perpetuate the problem. Agreed + you dont want to use ssh to do this ether Not to mention the fact that HTTP is a horrible protocol for almost anything except serving up web pages. It's effectively implements a basic request/response datagram protocol (albeit with arbitrarily large packets), which can only be initiated from one side, but with the overhead of HTTP headers and the creation of a TCP connection. Agreed I somehow always imagined remote systemd and systemd journal integration being handle in similar manner as func [1] and certmaster[2] are doing. 1. https://fedorahosted.org/func/ 2. https://fedorahosted.org/certmaster/ JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] ExecRestart
On 11/29/2012 04:41 AM, Brandon Black wrote: Hi all, I'm trying to write a systemd.service unit file for an existing well-behaved daemon that's used to managing itself. The daemon binary doubles as its own controller for sysvinit-like command. For example foo start launches a new daemon. foo stop stops an existing instance of the daemon. Similarly for restart, condrestart, status, etc. This makes things very simple in the world of sysv-like init systems. The initscript just execs the daemon binary and passes on the user action argument, and all of the tricky bits are well-managed within the daemon's own code (pidfiles, sockets, logging, strange corner cases, timing issues, etc). I can't simply convert the daemon to expect all of systemd's nice features and gut all of its self-management code, as it must still be portable to non-systemd platforms where these features are handy. For the most part I've been able to successfully work around things, but lack of an ExecRestart is one of my remaining hangups. I certainly can publish a unit file without this, and restart would be performed by ExecStop - ExecStart. However, the daemon has a bunch of nice code to do a better restart than that, and I'd need an ExecRestart to allow users to continue to take advantage of that. The daemon's fast restart code does all of the expensive startup operations in the new daemon first (e.g. parsing large data input), then signals the existing daemon to shut itself down, waits for it to release its critical resources (e.g. sockets, pidfile), and finally takes over those resources and finishes starting itself. Basically it's using the overlap to avoid long service downtimes during that initial parsing phase (and if that parsing fails, it leaves the old daemon running to boot). Is there some design reason that we can't have an ExecRestart command? Successful exit of that command would mean the old instance was killed (which systemd could confirm), and that the restart command has launched a new instance (which systemd can also figure out via PIDFile or guessing/cgroup). Failure exit of that command would mean the existing daemon instance was left alone (and again, systemd could confirm that state). Which daemon is this ? JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Added support for EnvironmentDir
snip ... /snip What's the usecase for environment directory? JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC] iscsid / systemd / dracut integration effort
On 12/10/2012 10:08 PM, Chris Leech wrote: Sorry about the cross-posting, but I think that in order to get this right I'm going to need as much feedback as I can get. I think I've got this working pretty well now (at least for my iBFT configured iSCSI root test case), although the dracut module still needs work. This is based on the iscsid socket activation patch from Tomasz Torcz and the unit files from Tomasz and Jóhann B. Guðmundsson. Attempting to start iscsid using systemd unit files (socket activated or not) was impacting my iscsi-root test setup. Rather than try to preserve the old logic that used the _netdev mount flag to determine when iscsid could be safely shutdown, I've been working on following the guidelines for root storage daemons http://www.freedesktop.org/wiki/Software/systemd/RootStorageDaemons. 1) I patched iscsid to set argv[0][0] = '@' if a new --initrd flag is passed on the command line. It's simple, it works, we don't kill iscsid before the root filesystem is unmounted. 2) When starting iscsid from the initrd, I then ran into issues of iscsid not functioning properly after the switch_root. It's not mentioned in the RootStorageDaemons documentation, but if a process left running from the initrd needs further filesystem access at runtime it will need to be able to chroot itself before the switch_root. I patched iscsid and iscsiadm with a newroot command (using plymouth as an example), and used a dracut clenaup hook to call iscsiadm --newroot /sysroot. 3) Related to #2, launching iscsid as a Type=simple service from the initrd (I'm testing this with Fedora 18 beta, where dracut uses systemd in the initrd) results in STDOUT/STDERR access after the switch_root failing with EPIPE. It seems that the connection to the journal process is dead once the initrd instantiated systemd-journald is replaced with the runtime process. I can at least keep iscsid functioning if I run it as Type=forking, but I'm not sure if I'm losing runtime logging or not. I may be able to do something with the StandardOutput and StandardError options in the service file. You should be using Type=forking here 4) None of this helps if the sessions are shutdown when we still need them. Rather than the all-or-nothing _netdev mount option checks that have been used in the past, I'm attempting to use the fact that iscsiadm will skip over session that match a node with startup=onboot set when doing a logoutall. The iscsi_mark_root_nodes script is borrowed from the SUSE init scripts in the open-iscsi repos written by Hannes Reinecke. I've made minor changes to export the list of sessions activated in the initramfs, and then mark those as onboot when starting iscsi.service. Things that still need looking into. 1) Command line configured iSCSI parameters. If iscsistart is to be fully removed something needs to setup the node from the command line. Or iscsistart needs to be able to run alongside iscsid. 2) Proper ordering of the iscsi.service for non-root filesystems. Any and all feedback and/or help welcome. Looking the unit file for iscsid I do believe I missed this ( basically the same as multipath unit ) since you know it's early boot special, root and all that ;) [Unit] # Before or After lvm2-activation-early.service DefaultDependencies=no Conflicts=shutdown.target [Install] WantedBy=sysinit.target JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
