Re: [systemd-devel] networkd slaac and radv
2014-04-11 2:36 GMT+04:00 Vasiliy Tolstov : > Hello. How can i via networkd can configure network interface to use > radv provided prefixes? > For example after boot interface is up and have SLAAC generated > address (link local) after its receives ra it have global prefix. Anybody knowns? Does it possible and how it possible? -- Vasiliy Tolstov, e-mail: v.tols...@selfip.ru jabber: v...@selfip.ru ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] doc: fix items' names in PORTING-DBUS1
On Thu, Apr 10, 2014 at 02:50:23PM +0200, Lukasz Skalski wrote: > --- > src/libsystemd/sd-bus/PORTING-DBUS1 | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/src/libsystemd/sd-bus/PORTING-DBUS1 > b/src/libsystemd/sd-bus/PORTING-DBUS1 > index f2ebcd7..6205e32 100644 > --- a/src/libsystemd/sd-bus/PORTING-DBUS1 > +++ b/src/libsystemd/sd-bus/PORTING-DBUS1 > @@ -342,7 +342,7 @@ items of the same type as the kernel messages include, > i.e. KDBUS_ITEM_NAME_ADD, KDBUS_ITEM_NAME_REMOVE, > KDBUS_ITEM_NAME_CHANGE, KDBUS_ITEM_ID_ADD, KDBUS_ITEM_ID_REMOVE and > fill them out. Note however, that you have some wildcards in this > -case, for example the .id field of KDBUS_ITEM_ADD/KDBUS_ITEM_REMOVE > +case, for example the .id field of KDBUS_ITEM_ID_ADD/KDBUS_ITEM_ID_REMOVE > structures may be set to 0 to match against any id addition/removal. > Applied. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/2] implement a union to pad out file_handle
On Sat, Apr 19, 2014 at 01:33:29PM -0400, Dave Reisner wrote:
> Cases where name_to_handle_at is used allocated the full struct to be
> MAX_HANDLE_SZ, and assigned this size to handle_bytes. This is wrong
> since handle_bytes should describe the length of the flexible array
> member and not the whole struct.
>
> Define a union type which includes sufficient padding to allow
> assignment of MAX_HANDLE_SZ to be correct.
Yikes. Patch looks good.
Zbyszek
> ---
> src/libudev/libudev-monitor.c| 6 ++
> src/readahead/readahead-common.c | 6 ++
> src/shared/util.h| 6 ++
> src/tmpfiles/tmpfiles.c | 11 ---
> 4 files changed, 14 insertions(+), 15 deletions(-)
>
> diff --git a/src/libudev/libudev-monitor.c b/src/libudev/libudev-monitor.c
> index 3f7436b..0a2ab82 100644
> --- a/src/libudev/libudev-monitor.c
> +++ b/src/libudev/libudev-monitor.c
> @@ -108,15 +108,13 @@ static struct udev_monitor *udev_monitor_new(struct
> udev *udev)
>
> /* we consider udev running when /dev is on devtmpfs */
> static bool udev_has_devtmpfs(struct udev *udev) {
> -struct file_handle *h;
> +union file_handle_union h = { .handle.handle_bytes = MAX_HANDLE_SZ,
> };
> int mount_id;
> _cleanup_fclose_ FILE *f = NULL;
> char line[LINE_MAX], *e;
> int r;
>
> -h = alloca(MAX_HANDLE_SZ);
> -h->handle_bytes = MAX_HANDLE_SZ;
> -r = name_to_handle_at(AT_FDCWD, "/dev", h, &mount_id, 0);
> +r = name_to_handle_at(AT_FDCWD, "/dev", &h.handle, &mount_id, 0);
> if (r < 0)
> return false;
>
> diff --git a/src/readahead/readahead-common.c
> b/src/readahead/readahead-common.c
> index 5ffa88b..49679fc 100644
> --- a/src/readahead/readahead-common.c
> +++ b/src/readahead/readahead-common.c
> @@ -75,7 +75,7 @@ int fs_on_ssd(const char *p) {
> if (major(st.st_dev) == 0) {
> _cleanup_fclose_ FILE *f = NULL;
> int mount_id;
> -struct file_handle *h;
> +union file_handle_union h = { .handle.handle_bytes =
> MAX_HANDLE_SZ, };
>
> /* Might be btrfs, which exposes "ssd" as mount flag if it
> is on ssd.
> *
> @@ -83,9 +83,7 @@ int fs_on_ssd(const char *p) {
> * and then lookup the mount ID in mountinfo to find
> * the mount options. */
>
> -h = alloca(MAX_HANDLE_SZ);
> -h->handle_bytes = MAX_HANDLE_SZ;
> -r = name_to_handle_at(AT_FDCWD, p, h, &mount_id,
> AT_SYMLINK_FOLLOW);
> +r = name_to_handle_at(AT_FDCWD, p, &h.handle, &mount_id,
> AT_SYMLINK_FOLLOW);
> if (r < 0)
> return false;
>
> diff --git a/src/shared/util.h b/src/shared/util.h
> index 900f1cf..891848a 100644
> --- a/src/shared/util.h
> +++ b/src/shared/util.h
> @@ -22,6 +22,7 @@
> ***/
>
> #include
> +#include
> #include
> #include
> #include
> @@ -914,3 +915,8 @@ uint64_t physical_memory(void);
> char* mount_test_option(const char *haystack, const char *needle);
>
> void hexdump(FILE *f, const void *p, size_t s);
> +
> +union file_handle_union {
> + struct file_handle handle;
> + char padding[sizeof(struct file_handle) + MAX_HANDLE_SZ];
> +};
> diff --git a/src/tmpfiles/tmpfiles.c b/src/tmpfiles/tmpfiles.c
> index 33e7cbc..04b472d 100644
> --- a/src/tmpfiles/tmpfiles.c
> +++ b/src/tmpfiles/tmpfiles.c
> @@ -217,19 +217,16 @@ static bool unix_socket_alive(const char *fn) {
> }
>
> static int dir_is_mount_point(DIR *d, const char *subdir) {
> -struct file_handle *h;
> +union file_handle_union h = { .handle.handle_bytes = MAX_HANDLE_SZ };
> int mount_id_parent, mount_id;
> int r_p, r;
>
> -h = alloca(MAX_HANDLE_SZ);
> -
> -h->handle_bytes = MAX_HANDLE_SZ;
> -r_p = name_to_handle_at(dirfd(d), ".", h, &mount_id_parent, 0);
> +r_p = name_to_handle_at(dirfd(d), ".", &h.handle, &mount_id_parent,
> 0);
> if (r_p < 0)
> r_p = -errno;
>
> -h->handle_bytes = MAX_HANDLE_SZ;
> -r = name_to_handle_at(dirfd(d), subdir, h, &mount_id, 0);
> +h.handle.handle_bytes = MAX_HANDLE_SZ;
> +r = name_to_handle_at(dirfd(d), subdir, &h.handle, &mount_id, 0);
> if (r < 0)
> r = -errno;
>
> --
> 1.9.2
>
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/2] condense assignment and path_kill_slashes calls
On Sat, Apr 19, 2014 at 01:33:28PM -0400, Dave Reisner wrote:
> ---
> Some of these are cases where the output variable is being modified,
> but since path_kill_slashes can't fail, I didn't see this as being
> controversial.
Looks OK.
Zbyszek
> src/shared/cgroup-util.c | 10 +++---
> src/shared/path-util.c | 3 +--
> 2 files changed, 4 insertions(+), 9 deletions(-)
>
> diff --git a/src/shared/cgroup-util.c b/src/shared/cgroup-util.c
> index 9d50890..139888c 100644
> --- a/src/shared/cgroup-util.c
> +++ b/src/shared/cgroup-util.c
> @@ -472,9 +472,7 @@ static int join_path(const char *controller, const char
> *path, const char *suffi
> if (!t)
> return -ENOMEM;
>
> -path_kill_slashes(t);
> -
> -*fs = t;
> +*fs = path_kill_slashes(t);
> return 0;
> }
>
> @@ -957,8 +955,7 @@ int cg_split_spec(const char *spec, char **controller,
> char **path) {
> if (!t)
> return -ENOMEM;
>
> -path_kill_slashes(t);
> -*path = t;
> +*path = path_kill_slashes(t);
> }
>
> if (controller)
> @@ -1048,8 +1045,7 @@ int cg_mangle_path(const char *path, char **result) {
> if (!t)
> return -ENOMEM;
>
> -path_kill_slashes(t);
> -*result = t;
> +*result = path_kill_slashes(t);
> return 0;
> }
>
> diff --git a/src/shared/path-util.c b/src/shared/path-util.c
> index e35d7f8..373dd7a 100644
> --- a/src/shared/path-util.c
> +++ b/src/shared/path-util.c
> @@ -464,8 +464,7 @@ int find_binary(const char *name, char **filename) {
> continue;
>
> if (filename) {
> -path_kill_slashes(p);
> -*filename = p;
> +*filename = path_kill_slashes(p);
> p = NULL;
> }
>
> --
> 1.9.2
>
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Removed duplicate includes
On Tue, Apr 08, 2014 at 11:14:16AM +0200, Bas van den Berg wrote: > Signed-off-by: Bas van den Berg > --- > src/journal/journal-remote.c |1 - > src/shared/util.c|1 - > 2 files changed, 2 deletions(-) Applied. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Cache passphrase for cryptsetup?
Matthew Monaco writes: > On 04/19/2014 02:49 PM, Nikolaus Rath wrote: >> I have several LUKS encrypted volumes that use the same >> passphrase. Before switching to systemd, I have used the decrypt_keyctl >> keyscript to cache the passphrase, so that I have to enter it only once. >> >> As far as I can tell, the systemd cryptsetup generator is ignoring the >> keyscript option in /etc/crypttab when creating units. >> >> Is there another way to achieve passphrase caching with systemd? > > No, 'keyscript' is not (currently) supported. IMHO, you're not reducing your > security any by e.g. unlocking /root and storing keys for the other volumes > there. Agreed, but it doesn't help much. You have to unlock swap first or it will break hibernation, which means you still need to enter the password at least twice. > However, you could probably cook up some units that take your > password, write it to /run and then point all of your volumes their. Good idea (though it wouldn't be units but initramfs hooks), thanks! Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.« ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-commits] 3 commits - src/libsystemd src/network src/udev
On Sun, Apr 20, 2014 at 3:16 PM, Zbigniew Jędrzejewski-Szmek
wrote:
> On Sun, Apr 20, 2014 at 05:45:18AM -0700, Tom Gundersen wrote:
>> commit 6190b9f9d2574428d560458a99f2838041cfdaac
>> Author: Tom Gundersen
>> Date: Sun Apr 20 07:51:28 2014 +0200
>>
>> sd-rtnl: log when queues are exhausted
>>
>> diff --git a/src/libsystemd/sd-rtnl/sd-rtnl.c
>> b/src/libsystemd/sd-rtnl/sd-rtnl.c
>> index 8650f55..543bad9 100644
>> --- a/src/libsystemd/sd-rtnl/sd-rtnl.c
>> +++ b/src/libsystemd/sd-rtnl/sd-rtnl.c
>> @@ -203,8 +203,10 @@ int sd_rtnl_send(sd_rtnl *nl,
>> }
>> } else {
>> /* append to queue */
>> -if (nl->wqueue_size >= RTNL_WQUEUE_MAX)
>> +if (nl->wqueue_size >= RTNL_WQUEUE_MAX) {
>> +log_debug("rtnl: exhausted the write queue size
>> (%d)", RTNL_WQUEUE_MAX);
>> return -ENOBUFS;
>> +}
> Is there a risk of this condition happenning often? Maybe this should be
> protected
> by a condition to be printed just once, and then it could be at warning level?
This is extremely unlikely to happen, and if it does surely very bad
things will result from it (best case the program would fail
gracefully I suppose). I added this here simply to easily rule out
this as a source of bugs when debugging similar/related issues.
The reason I didn't make this a higher priority log message is that we
so far only ever use log_debug from libraries. I don't know if we want
to start making exceptions to that? Kay, Lennart?
Cheers,
Tom
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Cache passphrase for cryptsetup?
On 2014-04-20 21:45, Matthew Monaco wrote: > And of course, the third option would be to submit a patch. The src/cryptsetup > stuff is pretty straightforward. Wasn't one submitted just a month ago? -- Mantas Mikulėnas ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Cache passphrase for cryptsetup?
On 04/19/2014 02:49 PM, Nikolaus Rath wrote: > Hello, > > I have several LUKS encrypted volumes that use the same > passphrase. Before switching to systemd, I have used the decrypt_keyctl > keyscript to cache the passphrase, so that I have to enter it only once. > > As far as I can tell, the systemd cryptsetup generator is ignoring the > keyscript option in /etc/crypttab when creating units. > > Is there another way to achieve passphrase caching with systemd? > > > Thanks, > -Nikolaus > No, 'keyscript' is not (currently) supported. IMHO, you're not reducing your security any by e.g. unlocking /root and storing keys for the other volumes there. If you did this, you might want to use a separate keyslot for the task with a longer key that you don't/can't remember, just for kicks. However, you could probably cook up some units that take your password, write it to /run and then point all of your volumes their. And of course, the third option would be to submit a patch. The src/cryptsetup stuff is pretty straightforward. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] libudev: replace name_to_handle_at with normal sscanf
On Sun, Apr 20, 2014 at 03:53:05PM +0200, Kay Sievers wrote:
> On Sun, Apr 20, 2014 at 5:36 AM, Zbigniew Jędrzejewski-Szmek
> wrote:
>
> > Hi Kay,
> > it seems that handles are not crucial, and the simplified version below
> > works too. Is there something I'm missing?
>
> The name_to_handle API works properly with bind mounts, it's the more
> reliable API.
>
> It also was intentional to support any filesystem with the prefix
> devtmpfs*, like "devtmpfs2" or whatever it might be named in the
> future.
>
> What actual problem are we trying to solve here with not requiring a
> common kernel config option? We want/need it in other places too, and
> the current fallback logic to figure out the mount point is really not
> that great with bind mounts. We just need the fallback for filesystems
> which do not support the API, but most common and tmpfs/devtmpfs do.
>
> I don't necessarily see the point in supporting the idea of the
> kernel's uber-configurability and the massive pain it causes for tools
> to make things work.
Yeah, I'm just trying to reduce the confusion that people experience
on kernels without CONFIG_FHANDLE.
What about this:
8<-
Subject: [PATCH] udev: assume /dev is devtmpfs if name_to_handle_at is not
implemented
We have a bunch of reports from people who have a custom kernel and
are confused why udev is not running. This raises the possibility of a
false positive when running on a kernel without CONFIG_FHANDLE but in a
container. Nevertheless, this caes should be easier to diagnose than
the opposite of running on bare metal with the same kernel.
https://bugzilla.redhat.com/show_bug.cgi?id=1072966
Also, if we find a mountpoint with a matching id, and it doesn't have
devtmpfs mounted, return false.
---
src/libudev/libudev-monitor.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/src/libudev/libudev-monitor.c b/src/libudev/libudev-monitor.c
index 3f7436b..dd5f862 100644
--- a/src/libudev/libudev-monitor.c
+++ b/src/libudev/libudev-monitor.c
@@ -117,9 +117,16 @@ static bool udev_has_devtmpfs(struct udev *udev) {
h = alloca(MAX_HANDLE_SZ);
h->handle_bytes = MAX_HANDLE_SZ;
r = name_to_handle_at(AT_FDCWD, "/dev", h, &mount_id, 0);
-if (r < 0)
-return false;
+if (r < 0) {
+if (errno == ENOSYS || errno == ENOTSUP) {
+/* This kernel or file system does not support
+ * name_to_handle_at(). */
+log_warning("name_to_handle_at syscall failed,
assuming /dev is volatile.");
+return true;
+}
+return false;
+}
f = fopen("/proc/self/mountinfo", "re");
if (!f)
@@ -139,8 +146,7 @@ static bool udev_has_devtmpfs(struct udev *udev) {
continue;
/* accept any name that starts with the currently expected
type */
-if (startswith(e + 3, "devtmpfs"))
-return true;
+return startswith(e + 3, "devtmpfs");
}
return false;
--
1.8.5.2
8<-
?
Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] libudev: replace name_to_handle_at with normal sscanf
El 20/04/14 10:53, Kay Sievers escribió: On Sun, Apr 20, 2014 at 5:36 AM, Zbigniew Jędrzejewski-Szmek wrote: Hi Kay, it seems that handles are not crucial, and the simplified version below works too. Is there something I'm missing? The real problem here is that kernel developers took the questionable decision of allowing system calls to be disabled or enabled at compile time. -- Cristian "I don't know the key to success, but the key to failure is trying to please everybody." ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] libudev: replace name_to_handle_at with normal sscanf
On Sun, Apr 20, 2014 at 5:36 AM, Zbigniew Jędrzejewski-Szmek wrote: > Hi Kay, > it seems that handles are not crucial, and the simplified version below > works too. Is there something I'm missing? The name_to_handle API works properly with bind mounts, it's the more reliable API. It also was intentional to support any filesystem with the prefix devtmpfs*, like "devtmpfs2" or whatever it might be named in the future. What actual problem are we trying to solve here with not requiring a common kernel config option? We want/need it in other places too, and the current fallback logic to figure out the mount point is really not that great with bind mounts. We just need the fallback for filesystems which do not support the API, but most common and tmpfs/devtmpfs do. I don't necessarily see the point in supporting the idea of the kernel's uber-configurability and the massive pain it causes for tools to make things work. Looking into the not-to-far future, we will hard-require a specific kernel version to provide us with the new cgroups logic and kdbus functionality to boot up properly; I think we should just document and explain what we need, and fail to boot with a proper error, and not try to work around insufficient kernel configs and compiled-out features we rely on. We should turn the current failure into a real error message though, instead of patching things back to less reliable APIs. Btw, the same applies to the !cgroups config, that code should just be removed and we error out with a proper explanation, instead of booting (or even segfault at the moment) a half-working system and pretend systemd would magically find a way to make it work without cgroups. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-commits] 3 commits - src/libsystemd src/network src/udev
On Sun, Apr 20, 2014 at 05:45:18AM -0700, Tom Gundersen wrote:
> commit 6190b9f9d2574428d560458a99f2838041cfdaac
> Author: Tom Gundersen
> Date: Sun Apr 20 07:51:28 2014 +0200
>
> sd-rtnl: log when queues are exhausted
>
> diff --git a/src/libsystemd/sd-rtnl/sd-rtnl.c
> b/src/libsystemd/sd-rtnl/sd-rtnl.c
> index 8650f55..543bad9 100644
> --- a/src/libsystemd/sd-rtnl/sd-rtnl.c
> +++ b/src/libsystemd/sd-rtnl/sd-rtnl.c
> @@ -203,8 +203,10 @@ int sd_rtnl_send(sd_rtnl *nl,
> }
> } else {
> /* append to queue */
> -if (nl->wqueue_size >= RTNL_WQUEUE_MAX)
> +if (nl->wqueue_size >= RTNL_WQUEUE_MAX) {
> +log_debug("rtnl: exhausted the write queue size
> (%d)", RTNL_WQUEUE_MAX);
> return -ENOBUFS;
> +}
Is there a risk of this condition happenning often? Maybe this should be
protected
by a condition to be printed just once, and then it could be at warning level?
Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
