Re: [systemd-devel] Delaying (SSH) key generation until the urandom pool is initialized
On 05/05/2014 04:35 PM, Lennart Poettering wrote: On Wed, 30.04.14 17:06, Florian Weimer (fwei...@redhat.com) wrote: On 04/30/2014 02:28 PM, Daniel P. Berrange wrote: Interesting suggestion. I just used virt-manager to create the VM. I don't see any trace for rng or random in the domain XML file. If it is supported, I think it should be enabled by default. I'm told that it isn't turned on by default, but you can add it to a VM post-install. Since it feeds VMs from the host's /dev/random or /dev/hwrng, there was a question mark as to whether it was right to enable it by default or not, and if so what kind of rate limiting might be wanted by default. Ah, so it builds down to our distrust of hardware RNGs? How annoying. We should be able to trust Fedora-on-Fedora (or Debian-on-Debian or whatever) scenarios. But I get that in the general case, it's impossible to know what's on the other side of the virtio_rng side, so reservations remain. Hmm? Well, a virtualized OS has to trust the hypervisor, there's no way around that. I'm referring to this: * This function will use the architecture-specific hardware random * number generator if it is available. The arch-specific hw RNG will * almost certainly be faster than what we can do in software, but it * is impossible to verify that it is implemented securely (as * opposed, to, say, the AES encryption of a sequence number using a * key known by the NSA). So it's useful if we need the speed, but * only if we're willing to trust the hardware manufacturer not to * have put in a back door. I think this is the reason why the pool isn't considered initialized even if its contents has been randomized with RDRAND or similar instructions. I wouldn't be surprised if these minds have a similar concern about randomness coming from a hypervisor. -- Florian Weimer / Red Hat Product Security Team ___ 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 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. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Delaying (SSH) key generation until the urandom pool is initialized
Am 06.06.2014 11:50, schrieb Florian Weimer: On 05/05/2014 04:35 PM, Lennart Poettering wrote: Hmm? Well, a virtualized OS has to trust the hypervisor, there's no way around that. I'm referring to this: * This function will use the architecture-specific hardware random * number generator if it is available. The arch-specific hw RNG will * almost certainly be faster than what we can do in software, but it * is impossible to verify that it is implemented securely (as * opposed, to, say, the AES encryption of a sequence number using a * key known by the NSA). So it's useful if we need the speed, but * only if we're willing to trust the hardware manufacturer not to * have put in a back door. I think this is the reason why the pool isn't considered initialized even if its contents has been randomized with RDRAND or similar instructions. I wouldn't be surprised if these minds have a similar concern about randomness coming from a hypervisor if you don't trust the underlying hardware and hypervisor you are lost in any case, that's a battle you can't win and in that context the random numbers are your smallest problem at all signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Restart best practices
Am 06.06.2014 11:48, schrieb Jóhann B. Guðmundsson: 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 where do you see ignorance here? if there is running a service which should always run the only valid reason it's main process is stopped is a systemctop stop whatever.service for any long running service like web/mail/database servers Restart=always is what i expect as admin signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] Add a network-pre.target to avoid firewall leaks
https://bugs.freedesktop.org/show_bug.cgi?id=79600 --- Makefile.am | 1 + man/systemd.special.xml | 1 + units/network-pre.target | 11 +++ units/network.target | 2 ++ units/systemd-networkd.service.in | 3 ++- 5 files changed, 17 insertions(+), 1 deletion(-) create mode 100644 units/network-pre.target diff --git a/Makefile.am b/Makefile.am index a2a01d0..79adc34 100644 --- a/Makefile.am +++ b/Makefile.am @@ -413,6 +413,7 @@ dist_systemunit_DATA = \ units/remote-fs.target \ units/remote-fs-pre.target \ units/network.target \ + units/network-pre.target \ units/network-online.target \ units/nss-lookup.target \ units/nss-user-lookup.target \ diff --git a/man/systemd.special.xml b/man/systemd.special.xml index 8c2..7515cf8 100644 --- a/man/systemd.special.xml +++ b/man/systemd.special.xml @@ -71,6 +71,7 @@ filenamelocal-fs-pre.target/filename, filenamemulti-user.target/filename, filenamenetwork.target/filename, +filenamenetwork-pre.target/filename, filenamenetwork-online.target/filename, filenamenss-lookup.target/filename, filenamenss-user-lookup.target/filename, diff --git a/units/network-pre.target b/units/network-pre.target new file mode 100644 index 000..0c4a0ca --- /dev/null +++ b/units/network-pre.target @@ -0,0 +1,11 @@ +# This file is part of systemd. +# +# systemd is free software; you can redistribute it and/or modify it +# under the terms of the GNU Lesser General Public License as published by +# the Free Software Foundation; either version 2.1 of the License, or +# (at your option) any later version. + +[Unit] +Description=Network (Pre) +Documentation=man:systemd.special(7) +RefuseManualStart=yes diff --git a/units/network.target b/units/network.target index 65fc64b..6966035 100644 --- a/units/network.target +++ b/units/network.target @@ -9,3 +9,5 @@ Description=Network Documentation=man:systemd.special(7) Documentation=http://www.freedesktop.org/wiki/Software/systemd/NetworkTarget +Requires=network-pre.target +After=network-pre.target diff --git a/units/systemd-networkd.service.in b/units/systemd-networkd.service.in index 373ac4e..8e4d213 100644 --- a/units/systemd-networkd.service.in +++ b/units/systemd-networkd.service.in @@ -9,8 +9,9 @@ Description=Network Service Documentation=man:systemd-networkd.service(8) DefaultDependencies=no -After=dbus.service +After=dbus.service network-pre.target Before=network.target +Requires=network-pre.target Wants=network.target ConditionCapability=CAP_NET_ADMIN -- 2.0.0 signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] 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
Re: [systemd-devel] Setup autologin tty
On Tue, 03.06.14 13:15, Mateusz Malicki (m.malic...@samsung.com) wrote: Hello, I am working on system running in lxc container that use systemd. On host user session (uid=5000) starts automatically but in container I have following error message: May 12 00:18:15 localhost user-session-launch[110]: pam_systemd(login:session): Asking logind to create session: uid=5000 pid=110 service=login type=tty class=user seat=seat0 vtnr=1 tty=tty1 display= remote=no remote_user= remote_host= exposing the VT subsystem to a container makes little sense. logind only works if you have the full VT system, including files such as /sys/class/tty/tty0/active, /dev/vcs* together, with udev events, the right ioctls and whatnot. Just mounting some pty's to /dev/tty1 will not work. Some container managers set up an incomplete /dev/tty[1..6] setup, that's just bogus, and not supported in systemd. Also see: http://www.freedesktop.org/wiki/Software/systemd/ContainerInterface/ Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Systemd-networkd, default route and multiple interfaces
On Wed, 04.06.14 00:29, Mantas Mikulėnas (graw...@gmail.com) wrote: On Tue, Jun 3, 2014 at 9:58 PM, Lennart Poettering lenn...@poettering.net wrote: On Mon, 02.06.14 21:02, Tom Gundersen (t...@jklm.no) wrote: On Mon, Jun 2, 2014 at 8:47 PM, Reventlov contact+systemd...@volcanis.me wrote: Since network files are applied to links whenever the links appear, how do systemd manage the disappearance of a default route ? You can have several default routes, so we just configure them all and let the kernel handle it for us. We probably should improve the config options to make it possible to override the priority of the routes. Windows initializes the route metric value for each route from the speed of the interface. If there are multiple links and for one we know it's a gigabit ethernet link, and the other is a 54mbit wlan link, then the former would automatically get preference... it's a bit black magic, but kinda cool black magic i think... that said, i am not sure we even have a sane API to determine the speed of links... maybe ethtool reports it at least for wired ethernet? but for wlan? Both `iwconfig dev` and `iw dev link` report the link speed (one using the old wext and the other nl80211, I think?). No idea about all the other link types that Linux supports though. As long as we'd only have to check ethtool for wired ethernet and the wireless stack for wireless ethernet and can cover 70% of all devices with that, this sounds like the right thing to do for me... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v4 1/2] Move handling of sysv initscripts to a generator
On Sat, 31.05.14 23:29, Thomas H.P. Andersen (pho...@gmail.com) wrote:
Thanks! Awesome work! I am enjoying this!
A few comments:
+
+static int generate_unit_file(SysvStub *s) {
+char *unit;
+char **p;
+_cleanup_fclose_ FILE *f = NULL;
+_cleanup_free_ char *before = NULL;
+_cleanup_free_ char *after = NULL;
+_cleanup_free_ char *conflicts = NULL;
+int r;
+
+before = strv_join(s-before, );
+after = strv_join(s-after, );
+conflicts = strv_join(s-conflicts, );
misses OOM checks!
+
+unit = strjoin(arg_dest, /, s-name, NULL);
+if (!unit)
+return log_oom();
+
+f = fopen(unit, wxe);
+if (!f) {
+log_error(Failed to create unit file %s: %m, unit);
+return -errno;
+}
+
+fprintf(f,
+# Automatically generated by systemd-sysv-generator\n\n
+[Unit]\n
+SourcePath=%s\n
+Description=%s\n,
+s-path, s-description);
+
+if (!isempty(before))
+fprintf(f, Before=%s\n, before);
+if (!isempty(after))
+fprintf(f, After=%s\n, after);
+if (!isempty(conflicts))
+fprintf(f, Conflicts=%s\n, conflicts);
+
+fprintf(f,
+\n[Service]\n
+Type=forking\n
+Restart=no\n
+TimeoutSec=5min\n
+IgnoreSIGPIPE=no\n
+KillMode=process\n
+GuessMainPID=no\n
+RemainAfterExit=%s\n,
+s-pid_file ? no : yes);
Maybe use yes_no(!s-pid_file) for this? it's a macro that does
exactly this ternary operator check.
+
+if (s-sysv_start_priority 0)
+fprintf(f, SysVStartPriority=%d\n, s-sysv_start_priority);
+
+ if (s-pid_file)
+ fprintf(f, PidFile=%s\n, s-pid_file);
+
+ fprintf(f, ExecStart=%s start\n, s-path);
+ fprintf(f, ExecStop=%s stop\n, s-path);
Please merge these two lines in one fprintf() invocation, like we do it
for the other cases...
+ if (s-reload)
+ fprintf(f, ExecReload=%s reload\n, s-path);
+
+STRV_FOREACH(p, s-wants) {
Looks like a whitespace issue... Only spaces please.
+service = new0(SysvStub, 1);
+if (!service)
+return log_oom();
+
+service-sysv_start_priority = -1;
+service-name = name;
+service-path = fpath;
+
+hashmap_put(all_services, service-name,
service);
This can fail, due to OOM, we need to guard for this...
+r = lookup_paths_init(
+lp, SYSTEMD_SYSTEM, true,
+NULL, NULL, NULL, NULL);
Instead of making this a global variable, I'd prefer we could just pass
that through as arguments to the functions that need this.
Looks good otherwise!
Thanks!
Lennart
--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v4 2/2] Remove sysv parser from service.c
On Sat, 31.05.14 23:29, Thomas H.P. Andersen (pho...@gmail.com) wrote:
From: Thomas Hindoe Paaboel Andersen pho...@gmail.com
Parsing sysv files was moved to the sysv-generator in the previous commit.
This patch removes the sysv parsing from serivce.c.
To avoid introducing an extra compat option in .service fies for identifying
sysv services we instead add a check if the SourcePath is a path to
sysvinit.
Hmm, can't we get rid of this bit too? Do we still need to identify sysv
as such?
is_sysv is currently used for two things afaics: to avoid GC, which
becomes a non-issue, if we can load the units from the generated unit
files anyway. And to make it impossible to do socket activation for sysv
services, which is probably a check we can just drop...
+#ifdef HAVE_SYSV_COMPAT
+if (u-source_path) {
+char **p;
+
+STRV_FOREACH(p,
u-manager-lookup_paths.sysvinit_path)
+if (startswith(u-source_path, *p))
+s-is_sysv = true;
+}
+#endif
}
return service_verify(s);
@@ -1325,21 +547,10 @@ static void service_dump(Unit *u, FILE *f, const char
*prefix) {
}
#ifdef HAVE_SYSV_COMPAT
-if (s-is_sysv)
-fprintf(f,
-%sSysV Init Script has LSB Header: %s\n
-%sSysVEnabled: %s\n,
-prefix, yes_no(s-sysv_has_lsb),
-prefix, yes_no(s-sysv_enabled));
-
if (s-sysv_start_priority = 0)
fprintf(f,
%sSysVStartPriority: %i\n,
prefix, s-sysv_start_priority);
-
-if (s-sysv_runlevels)
-fprintf(f, %sSysVRunLevels: %s\n,
-prefix, s-sysv_runlevels);
#endif
if (s-status_text)
@@ -3469,176 +2680,6 @@ static int service_get_timeout(Unit *u, uint64_t
*timeout) {
return 1;
}
-#ifdef HAVE_SYSV_COMPAT
-
-static int service_enumerate(Manager *m) {
-char **p;
-unsigned i;
-_cleanup_closedir_ DIR *d = NULL;
-_cleanup_free_ char *path = NULL, *fpath = NULL, *name = NULL;
-Set *runlevel_services[ELEMENTSOF(rcnd_table)] = {};
-_cleanup_set_free_ Set *shutdown_services = NULL;
-Unit *service;
-Iterator j;
-int r;
-
-assert(m);
-
-if (m-running_as != SYSTEMD_SYSTEM)
-return 0;
-
-STRV_FOREACH(p, m-lookup_paths.sysvrcnd_path)
-for (i = 0; i ELEMENTSOF(rcnd_table); i ++) {
-struct dirent *de;
-
-free(path);
-path = strjoin(*p, /, rcnd_table[i].path, NULL);
-if (!path) {
-r = -ENOMEM;
-goto finish;
-}
-
-if (d)
-closedir(d);
-
-d = opendir(path);
-if (!d) {
-if (errno != ENOENT)
-log_warning(opendir(%s) failed:
%m, path);
-
-continue;
-}
-
-while ((de = readdir(d))) {
-int a, b;
-
-if (ignore_file(de-d_name))
-continue;
-
-if (de-d_name[0] != 'S' de-d_name[0] !=
'K')
-continue;
-
-if (strlen(de-d_name) 4)
-continue;
-
-a = undecchar(de-d_name[1]);
-b = undecchar(de-d_name[2]);
-
-if (a 0 || b 0)
-continue;
-
-free(fpath);
-fpath = strjoin(path, /, de-d_name, NULL);
-if (!fpath) {
-r = -ENOMEM;
-goto finish;
-}
-
-if (access(fpath, X_OK) 0) {
-
-if (errno != ENOENT)
-log_warning(access() failed
on %s: %m, fpath);
-
-continue;
-}
-
-free(name);
-name = sysv_translate_name(de-d_name + 3);
-if (!name) {
-r = log_oom();
-
Re: [systemd-devel] [PATCH] [RFC] Move handling of sysv initscripts to a generator
On Wed, 28.05.14 11:58, Thomas H.P. Andersen (pho...@gmail.com) wrote: On Wed, May 28, 2014 at 3:38 AM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: On Wed, May 28, 2014 at 01:12:23AM +0200, Thomas H.P. Andersen wrote: From: Thomas Hindoe Paaboel Andersen pho...@gmail.com Reuses logic from service.c and the rc-local generator. Note that this drops reading of chkconfig entirely. How likely is this to cause regressions in existing distributions? The start priority in chkconfig was already removed in 213 so the only thing was the runlevels. The runlevels were only used to determine if the runlevel was special (not 1-5). Since special runlevels was dropped way back I don't see any reason to read the chkconfig at all. I agree. chkconfig parsing should only be retained for description + pid file, as your patch already handles it. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v4 1/2] Move handling of sysv initscripts to a generator
On Sat, 31.05.14 23:29, Thomas H.P. Andersen (pho...@gmail.com) wrote: +const char *arg_dest = /tmp; + +static LookupPaths lp; +static Hashmap *all_services; Small addendum: we try to avoid static vars. WOuld be great to pass the latter *both* through as params. We just try though, sometimes we take the shortcut, but if it is easy we avoid static vars, and i think this one of those cases where it is easy... The arg_* vars can stay that way, they are kinda global process parameters anyway, and we have them static in pretty much all our tools like this... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Systemd-networkd, default route and multiple interfaces
Hi, On 06/06, Lennart Poettering wrote: Date: Fri, 6 Jun 2014 15:43:21 +0200 From: Lennart Poettering lenn...@poettering.net To: Mantas Mikulėnas graw...@gmail.com Cc: systemd Mailing List systemd-devel@lists.freedesktop.org Subject: Re: [systemd-devel] Systemd-networkd, default route and multiple interfaces User-Agent: Leviathan/19.8.0 [zh] (Cray 3; I; Solaris 4.711; Console) On Wed, 04.06.14 00:29, Mantas Mikulėnas (graw...@gmail.com) wrote: On Tue, Jun 3, 2014 at 9:58 PM, Lennart Poettering lenn...@poettering.net wrote: On Mon, 02.06.14 21:02, Tom Gundersen (t...@jklm.no) wrote: On Mon, Jun 2, 2014 at 8:47 PM, Reventlov contact+systemd...@volcanis.me wrote: Since network files are applied to links whenever the links appear, how do systemd manage the disappearance of a default route ? You can have several default routes, so we just configure them all and let the kernel handle it for us. We probably should improve the config options to make it possible to override the priority of the routes. Windows initializes the route metric value for each route from the speed of the interface. If there are multiple links and for one we know it's a gigabit ethernet link, and the other is a 54mbit wlan link, then the former would automatically get preference... it's a bit black magic, but kinda cool black magic i think... that said, i am not sure we even have a sane API to determine the speed of links... maybe ethtool reports it at least for wired ethernet? but for wlan? Both `iwconfig dev` and `iw dev link` report the link speed (one using the old wext and the other nl80211, I think?). No idea about all the other link types that Linux supports though. As long as we'd only have to check ethtool for wired ethernet and the wireless stack for wireless ethernet and can cover 70% of all devices with that, this sounds like the right thing to do for me... Note, however, that wlan link speed can fluctuate in time. At least that's what happens with eduroam at our university (mostly cisco APs). Also, when comparing wlan and eth link speeds, does one take into account the different overheads due to frames, encryption, etc., or just compare bare speeds? Cheers, Leonid. -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D pgpOvtKxyZwK3.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Systemd-networkd, default route and multiple interfaces
On Fri, 2014-06-06 at 10:52 -0400, Leonid Isaev wrote: Hi, On 06/06, Lennart Poettering wrote: Date: Fri, 6 Jun 2014 15:43:21 +0200 From: Lennart Poettering lenn...@poettering.net To: Mantas Mikulėnas graw...@gmail.com Cc: systemd Mailing List systemd-devel@lists.freedesktop.org Subject: Re: [systemd-devel] Systemd-networkd, default route and multiple interfaces User-Agent: Leviathan/19.8.0 [zh] (Cray 3; I; Solaris 4.711; Console) On Wed, 04.06.14 00:29, Mantas Mikulėnas (graw...@gmail.com) wrote: On Tue, Jun 3, 2014 at 9:58 PM, Lennart Poettering lenn...@poettering.net wrote: On Mon, 02.06.14 21:02, Tom Gundersen (t...@jklm.no) wrote: On Mon, Jun 2, 2014 at 8:47 PM, Reventlov contact+systemd...@volcanis.me wrote: Since network files are applied to links whenever the links appear, how do systemd manage the disappearance of a default route ? You can have several default routes, so we just configure them all and let the kernel handle it for us. We probably should improve the config options to make it possible to override the priority of the routes. Windows initializes the route metric value for each route from the speed of the interface. If there are multiple links and for one we know it's a gigabit ethernet link, and the other is a 54mbit wlan link, then the former would automatically get preference... it's a bit black magic, but kinda cool black magic i think... that said, i am not sure we even have a sane API to determine the speed of links... maybe ethtool reports it at least for wired ethernet? but for wlan? Both `iwconfig dev` and `iw dev link` report the link speed (one using the old wext and the other nl80211, I think?). No idea about all the other link types that Linux supports though. As long as we'd only have to check ethtool for wired ethernet and the wireless stack for wireless ethernet and can cover 70% of all devices with that, this sounds like the right thing to do for me... Note, however, that wlan link speed can fluctuate in time. At least that's what happens with eduroam at our university (mostly cisco APs). Wifi speeds are constantly recalculated by the driver/firmware based on the RF environment, no matter when moving or standing still. So the farther away from the AP you are, or the more interference there is, the slower your speed will be as your device attempts to increase reliability of data transfer against interference or faint signal. Dan ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] Fix spelling mistake, proces - process
From: Colin Ian King colin.k...@canonical.com
Signed-off-by: Colin Ian King colin.k...@canonical.com
---
src/core/busname.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/core/busname.c b/src/core/busname.c
index 6be1b8b..2752415 100644
--- a/src/core/busname.c
+++ b/src/core/busname.c
@@ -446,7 +446,7 @@ static void busname_enter_signal(BusName *n, BusNameState
state, BusNameResult f
n-control_pid,
false);
if (r 0) {
-log_warning_unit(UNIT(n)-id, %s failed to kill control
proces: %s, UNIT(n)-id, strerror(-r));
+log_warning_unit(UNIT(n)-id, %s failed to kill control
process: %s, UNIT(n)-id, strerror(-r));
goto fail;
}
--
2.0.0
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v4 1/2] Move handling of sysv initscripts to a generator
On Fri, Jun 6, 2014 at 4:09 PM, Lennart Poettering
lenn...@poettering.net wrote:
On Sat, 31.05.14 23:29, Thomas H.P. Andersen (pho...@gmail.com) wrote:
Thanks! Awesome work! I am enjoying this!
A few comments:
+
+static int generate_unit_file(SysvStub *s) {
+char *unit;
+char **p;
+_cleanup_fclose_ FILE *f = NULL;
+_cleanup_free_ char *before = NULL;
+_cleanup_free_ char *after = NULL;
+_cleanup_free_ char *conflicts = NULL;
+int r;
+
+before = strv_join(s-before, );
+after = strv_join(s-after, );
+conflicts = strv_join(s-conflicts, );
misses OOM checks!
+
+unit = strjoin(arg_dest, /, s-name, NULL);
+if (!unit)
+return log_oom();
+
+f = fopen(unit, wxe);
+if (!f) {
+log_error(Failed to create unit file %s: %m, unit);
+return -errno;
+}
+
+fprintf(f,
+# Automatically generated by systemd-sysv-generator\n\n
+[Unit]\n
+SourcePath=%s\n
+Description=%s\n,
+s-path, s-description);
+
+if (!isempty(before))
+fprintf(f, Before=%s\n, before);
+if (!isempty(after))
+fprintf(f, After=%s\n, after);
+if (!isempty(conflicts))
+fprintf(f, Conflicts=%s\n, conflicts);
+
+fprintf(f,
+\n[Service]\n
+Type=forking\n
+Restart=no\n
+TimeoutSec=5min\n
+IgnoreSIGPIPE=no\n
+KillMode=process\n
+GuessMainPID=no\n
+RemainAfterExit=%s\n,
+s-pid_file ? no : yes);
Maybe use yes_no(!s-pid_file) for this? it's a macro that does
exactly this ternary operator check.
+
+if (s-sysv_start_priority 0)
+fprintf(f, SysVStartPriority=%d\n,
s-sysv_start_priority);
+
+ if (s-pid_file)
+ fprintf(f, PidFile=%s\n, s-pid_file);
+
+ fprintf(f, ExecStart=%s start\n, s-path);
+ fprintf(f, ExecStop=%s stop\n, s-path);
Please merge these two lines in one fprintf() invocation, like we do it
for the other cases...
+ if (s-reload)
+ fprintf(f, ExecReload=%s reload\n, s-path);
+
+STRV_FOREACH(p, s-wants) {
Looks like a whitespace issue... Only spaces please.
+service = new0(SysvStub, 1);
+if (!service)
+return log_oom();
+
+service-sysv_start_priority = -1;
+service-name = name;
+service-path = fpath;
+
+hashmap_put(all_services, service-name,
service);
This can fail, due to OOM, we need to guard for this...
+r = lookup_paths_init(
+lp, SYSTEMD_SYSTEM, true,
+NULL, NULL, NULL, NULL);
Instead of making this a global variable, I'd prefer we could just pass
that through as arguments to the functions that need this.
Looks good otherwise!
Thanks. Pushed with fixes.
Thanks!
Lennart
--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Add a network-pre.target to avoid firewall leaks
В Fri, 06 Jun 2014 12:53:01 + Rusty Bird rustyb...@openmailbox.org пишет: https://bugs.freedesktop.org/show_bug.cgi?id=79600 --- Makefile.am | 1 + man/systemd.special.xml | 1 + units/network-pre.target | 11 +++ units/network.target | 2 ++ units/systemd-networkd.service.in | 3 ++- 5 files changed, 17 insertions(+), 1 deletion(-) create mode 100644 units/network-pre.target diff --git a/Makefile.am b/Makefile.am index a2a01d0..79adc34 100644 --- a/Makefile.am +++ b/Makefile.am @@ -413,6 +413,7 @@ dist_systemunit_DATA = \ units/remote-fs.target \ units/remote-fs-pre.target \ units/network.target \ + units/network-pre.target \ units/network-online.target \ units/nss-lookup.target \ units/nss-user-lookup.target \ diff --git a/man/systemd.special.xml b/man/systemd.special.xml index 8c2..7515cf8 100644 --- a/man/systemd.special.xml +++ b/man/systemd.special.xml @@ -71,6 +71,7 @@ filenamelocal-fs-pre.target/filename, filenamemulti-user.target/filename, filenamenetwork.target/filename, +filenamenetwork-pre.target/filename, filenamenetwork-online.target/filename, filenamenss-lookup.target/filename, filenamenss-user-lookup.target/filename, That's rather terse documentation :) diff --git a/units/network-pre.target b/units/network-pre.target new file mode 100644 index 000..0c4a0ca --- /dev/null +++ b/units/network-pre.target @@ -0,0 +1,11 @@ +# This file is part of systemd. +# +# systemd is free software; you can redistribute it and/or modify it +# under the terms of the GNU Lesser General Public License as published by +# the Free Software Foundation; either version 2.1 of the License, or +# (at your option) any later version. + +[Unit] +Description=Network (Pre) +Documentation=man:systemd.special(7) +RefuseManualStart=yes diff --git a/units/network.target b/units/network.target index 65fc64b..6966035 100644 --- a/units/network.target +++ b/units/network.target @@ -9,3 +9,5 @@ Description=Network Documentation=man:systemd.special(7) Documentation=http://www.freedesktop.org/wiki/Software/systemd/NetworkTarget +Requires=network-pre.target +After=network-pre.target diff --git a/units/systemd-networkd.service.in b/units/systemd-networkd.service.in index 373ac4e..8e4d213 100644 --- a/units/systemd-networkd.service.in +++ b/units/systemd-networkd.service.in @@ -9,8 +9,9 @@ Description=Network Service Documentation=man:systemd-networkd.service(8) DefaultDependencies=no -After=dbus.service +After=dbus.service network-pre.target Before=network.target +Requires=network-pre.target Wants=network.target ConditionCapability=CAP_NET_ADMIN signature.asc Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] FixMe need a coredump HOOK
Hi systemd developers, I am a newbie of systemd, and I only read some source code such as systemd-timedated for SetTime SetTimezone via dbus interface :) And at present I need to develop a bug reporter frontend named FixMe https://github.com/AOSC-Dev/FixMe So I read about systemd-journald for being familiar with it :) and I just print out dump_list thanks to SD_JOURNAL_FOREACH_XXX https://github.com/AOSC-Dev/FixMe/blob/master/test/qinotify/qinotify.cpp#L68 But I do NOT know how to hook coredump in user space... I simply cat /proc/sys/kernel/core_pattern |/usr/lib/systemd/systemd-coredump %p %u %g %s %t %e Then systemd-coredump collector will be called (HOOKed), for example, BANG ... segfault occured in user or kernel space. but there is NO dbus interface provided for other App such as bug reporter frontend. so I have to inotify /var/log/journal/SUBDIR https://github.com/AOSC-Dev/FixMe/blob/master/test/qinotify/qinotify.cpp#L99 Please someone give me some advice, how to hook coredump in user/kernel space based on systemd or other LIB, thanks a lot! PS: what a PITY!!! I missed Lennart Poettering speech in 2014 GNOME Asia, I would ask the (or some) question directly in the meeting! Welcome to Beijing for HAPPY HACKING :) Regards, Leslie Zhai xiang.z...@i-soft.com.cn ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
