[systemd-devel] Understanding DHCP, DNS and IPMasquerade
My host obtains an IP address and DNS server via DHCP from upstream via Ethernet like this (systemd 219, Arch Linux) [Match] Name=en* [Network] DHCP=ipv4 It has the resolv.conf symlink to /run/systemd/resolve/resolv.conf, and the DNS server from DHCP shows up there. It also has this test.network file: [Match] Name=ve-* [Network] Address=0.0.0.0/28 IPMasquerade=yes IPv4LL=yes DHCPServer=yes IPForward=yes My host runs a container like this: (systemd 219, UBOS (just like Arch Linux)) systemd-nspawn -b -D test -n The container does not have any networkd configuration. It has the resolv.conf symlink, and runs systemd-networkd I was expecting: * container gets an IP address from host in some new subnet: WORKS, e.g 10.0.0.2 * container can route to upstream via IPMasquerade: WORKS, after manual 'modprobe iptable_nat' * container gets the DNS server from the host: FAILS: /etc/resolv.conf points to Google name servers instead (8.8.8.8 etc) * host and container can ping test (if test is the name of the container machine per machinectl): FAILS, neither can What am I misunderstanding or doing wrong? If somebody educates me, I’ll put the insights on a wiki somewhere (e.g. Arch) Thanks, Johannes. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [survey] BTRFS_IOC_DEVICES_READY return status
В Fri, 12 Jun 2015 21:16:30 +0800 Anand Jain пишет: > > > BTRFS_IOC_DEVICES_READY is to check if all the required devices > are known by the btrfs kernel, so that admin/system-application > could mount the FS. It is checked against a device in the argument. > > However the actual implementation is bit more than just that, > in the way that it would also scan and register the device > provided in the argument (same as btrfs device scan subcommand > or BTRFS_IOC_SCAN_DEV ioctl). > > So BTRFS_IOC_DEVICES_READY ioctl isn't a read/view only ioctl, > but its a write command as well. > > Next, since in the kernel we only check if total_devices > (read from SB) is equal to num_devices (counted in the list) > to state the status as 0 (ready) or 1 (not ready). But this > does not work in rest of the device pool state like missing, > seeding, replacing since total_devices is actually not equal > to num_devices in these state but device pool is ready for > the mount and its a bug which is not part of this discussions. > > > Questions: > > - Do we want BTRFS_IOC_DEVICES_READY ioctl to also scan and > register the device provided (same as btrfs device scan > command or the BTRFS_IOC_SCAN_DEV ioctl) > OR can BTRFS_IOC_DEVICES_READY be read-only ioctl interface > to check the state of the device pool. ? > udev is using it to incrementally assemble multi-device btrfs, so in this case I think it should. Are there any other users? > - If the the device in the argument is already mounted, > can it straightaway return 0 (ready) ? (as of now it would > again independently read the SB determine total_devices > and check against num_devices. > I think yes; obvious use case is btrfs mounted in initrd and later coldplug. There is no point to wait for anything as filesystem is obviously there. > - What should be the expected return when the FS is mounted > and there is a missing device. > This is similar to problem mdadm had to solve. mdadm starts timer as soon as enough raid devices are present; if timer expires before raid is complete, raid is started in degraded mode. This avoids spurious rebuilds. So it would be good if btrfs could distinguish between enough devices to mount and all devices. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Help needed for optimizing my boot time
On 06/12/2015 06:26 PM, Andrei Borzenkov wrote: > В Fri, 12 Jun 2015 16:56:08 +0200 > Francis Moreau пишет: > >> On 06/11/2015 06:23 PM, Dan Williams wrote: >>> On Thu, 2015-06-11 at 15:15 +0200, Francis Moreau wrote: >> [...] Does ntpd service really need 'After=network.target', not sure. >>> >>> The 'network online' targets are really just there for ignorant services >>> that don't respond to network events themselves, that expect the network >>> to be up and running before they start. Of course, those services don't >>> have any way to say *which* network interface they care about, so if you >>> have more than one interface in your system they still get it wrong. >> >> Do such services exist actually ? >> > > Until recently ntpd required working name resolution (i.e. often DNS) > to find its peers. If you mount something over network on boot you want > to have reasonable confidence that network is up. > >> I can't see how such service can work if they can't handle the offline >> case properly... >> > > Please explain how filesystem on iSCSI target is supposed to handle > offline case properly. > I was talking about ntpd, I dont know for you specific case. >> BTW 'network online' target doesn't seem to mean the network is up >> because if I boot my computer offline, this target is still reached and >> passed. >> > > Yes, network-online.target is not there to make boot impossible; it is > there to delay boot until network is considered to be up. It makes > little sense in pure dynamic environment; it is quite useful in static > server environment where network is expected to be always present but > may take some time to be configured. > Then if it's not reliable in some cases how can it be used by some generic services such as ntpd if ntpd is not prepared to handle the offline case ? >>> >>> But anyway, if ntpd or autofs can respond to network events using >>> netlink or listening on D-Bus to NetworkManager/connman/etc or getting >>> triggered by eg NetworkManager dispatcher scripts, then they probably >>> don't need to block on network-online. But if they can't, and they >>> expect the network to be up and running before they start, then yes they >>> will block startup until some kind of networking is running. >> >> Well I must be missing something but I can't see why ntpd or autofs >> would rely and have any deps on NM whereas they need to deal with the >> generic case, i.e. the one where NM is not installed and used. >> > > Where do you see any deps on NM? network-online.target is generic > target which will be used with any underlying networking implementation. I was refering to "if ntpd or autofs can respond to network events using netlink or listening on D-Bus to NetworkManager/connman/etc" >> >> IOW, any services having "After: network-online.target" look odd to me. >> > > Welcome to real world :) > No, real world is not "wait for ntpd, autofs to be activated before I can login" or at least not in my world ;) I don't really understand your opinion, are you saying that ntpd should used "After: network-online.target" ? Thanks ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Help needed for optimizing my boot time
В Fri, 12 Jun 2015 16:56:08 +0200 Francis Moreau пишет: > On 06/11/2015 06:23 PM, Dan Williams wrote: > > On Thu, 2015-06-11 at 15:15 +0200, Francis Moreau wrote: > [...] > >> > >> Does ntpd service really need 'After=network.target', not sure. > > > > The 'network online' targets are really just there for ignorant services > > that don't respond to network events themselves, that expect the network > > to be up and running before they start. Of course, those services don't > > have any way to say *which* network interface they care about, so if you > > have more than one interface in your system they still get it wrong. > > Do such services exist actually ? > Until recently ntpd required working name resolution (i.e. often DNS) to find its peers. If you mount something over network on boot you want to have reasonable confidence that network is up. > I can't see how such service can work if they can't handle the offline > case properly... > Please explain how filesystem on iSCSI target is supposed to handle offline case properly. > BTW 'network online' target doesn't seem to mean the network is up > because if I boot my computer offline, this target is still reached and > passed. > Yes, network-online.target is not there to make boot impossible; it is there to delay boot until network is considered to be up. It makes little sense in pure dynamic environment; it is quite useful in static server environment where network is expected to be always present but may take some time to be configured. > > > > But anyway, if ntpd or autofs can respond to network events using > > netlink or listening on D-Bus to NetworkManager/connman/etc or getting > > triggered by eg NetworkManager dispatcher scripts, then they probably > > don't need to block on network-online. But if they can't, and they > > expect the network to be up and running before they start, then yes they > > will block startup until some kind of networking is running. > > Well I must be missing something but I can't see why ntpd or autofs > would rely and have any deps on NM whereas they need to deal with the > generic case, i.e. the one where NM is not installed and used. > Where do you see any deps on NM? network-online.target is generic target which will be used with any underlying networking implementation. > > IOW, any services having "After: network-online.target" look odd to me. > Welcome to real world :) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Pass environment variables down to systemd-service in container
Hi there, is there a chance to pass (the given) environment variables down to `unicorn` and `delayed_job-worker`? systemd (host) | - docker-app.service Environment="RAILS_ENV=production" Environment="DATABASE_URL=postgresql://localhost/app_development" | - docker | - systemd (container) | - unicorn (ruby) | - delayed_job-worker (ruby) Background: I need to wrap a rails application within CentOS-image. To make the image re-usable I decided to use the DATABASE_URL-environment variable to configure the database. I also need to switch the RAILS_ENV. I'm using this image here https://registry.hub.docker.com/u/feduxorg/centos/dockerfile/. It's based on the official docker image which uses the `systemd-container`-package from CentOS. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Shutting down service using systemd-nspawn
> Not sure I follow: why do this indirectly by killing nspawn? > Why not send this to the container init directly? > > Note that if you know the nspawn PID, you can derive the external PID > of the init process easily by reading > /proc/$PID/task/$PID/children. It will only container one PID, and > that's init. That's an easy one. I didn't know how to get that pid. Thanks a lot ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] fstab-generator: Do less sanity checking
On 25.03.2015 00:05, Tobias Hunger wrote:
> Mount whatever the user asked to be mounted on / and /usr on the
> kernel command line. Do less sanity check and do *not* bail out
> when the mount device looks strange or does not exist.
>
> This basically makes the changes for deviceless filesystems
> from yesterday unnecessary and is in line with what we do for
> filesystems set up in fstab.
>
> Remove some code that is now dead.
> ---
> src/fstab-generator/fstab-generator.c | 34 +++---
> src/shared/generator.c| 5 -
> src/shared/util.c | 29 -
> src/shared/util.h | 1 -
> 4 files changed, 15 insertions(+), 54 deletions(-)
>
> diff --git a/src/fstab-generator/fstab-generator.c
> b/src/fstab-generator/fstab-generator.c
> index 77c97fd..5bd800e 100644
> --- a/src/fstab-generator/fstab-generator.c
> +++ b/src/fstab-generator/fstab-generator.c
> @@ -397,20 +397,18 @@ static int add_root_mount(void) {
> _cleanup_free_ char *what = NULL;
> const char *opts;
>
> -if (fstype_is_deviceless(arg_root_fstype)) {
> -if (free_and_strdup(&what, arg_root_what) < 0)
> -return log_oom();
> -} else {
> -if (isempty(arg_root_what)) {
> -log_debug("Could not find a root= entry on the
> kernel command line.");
> -return 0;
> -}
> +if (isempty(arg_root_what)) {
> +log_debug("Could not find a root= entry on the kernel
> command line.");
> +return 0;
> +}
>
> -what = fstab_node_to_udev_node(arg_root_what);
> -if (!path_is_absolute(what)) {
> -log_debug("Skipping entry what=%s where=/sysroot
> type=%s", what, strna(arg_root_fstype));
> -return 0;
> -}
> +what = fstab_node_to_udev_node(arg_root_what);
> +if (!what)
> +log_oom();
> +
> +if (is_device_path(what) && path_is_read_only_fs("sys") > 0) {
> +log_info("Running in a container, ignoring kernel command
> line configuration for %s.", what);
> +return 0;
> }
>
> if (!arg_root_options)
> @@ -426,7 +424,7 @@ static int add_root_mount(void) {
> "/sysroot",
> arg_root_fstype,
> opts,
> - 1,
> + is_device_path(what) ? 1 : 0,
> false,
> false,
> false,
> @@ -466,10 +464,8 @@ static int add_usr_mount(void) {
> return 0;
>
> what = fstab_node_to_udev_node(arg_usr_what);
> -if (!path_is_absolute(what)) {
> -log_debug("Skipping entry what=%s where=/sysroot/usr
> type=%s", what, strna(arg_usr_fstype));
> -return -1;
> -}
> +if (!what)
> +log_oom();
>
> if (!arg_usr_options)
> opts = arg_root_rw > 0 ? "rw" : "ro";
> @@ -483,7 +479,7 @@ static int add_usr_mount(void) {
> "/sysroot/usr",
> arg_usr_fstype,
> opts,
> - 1,
> + is_device_path(what) ? 1 : 0,
> false,
> false,
> false,
> diff --git a/src/shared/generator.c b/src/shared/generator.c
> index c348ca2..569b25b 100644
> --- a/src/shared/generator.c
> +++ b/src/shared/generator.c
> @@ -42,11 +42,6 @@ int generator_write_fsck_deps(
> assert(what);
> assert(where);
>
> -if (fstype_is_deviceless(fstype)) {
> -log_debug("Not checking deviceless filesystem \"%s\".",
> fstype);
> -return 0;
> -}
> -
> if (!is_device_path(what)) {
> log_warning("Checking was requested for \"%s\", but it is
> not a device.", what);
> return 0;
> diff --git a/src/shared/util.c b/src/shared/util.c
> index 2d50f73..ad548da 100644
> --- a/src/shared/util.c
> +++ b/src/shared/util.c
> @@ -1713,35 +1713,6 @@ bool fstype_is_network(const char *fstype) {
> return nulstr_contains(table, fstype);
> }
>
> -bool fstype_is_deviceless(const char *fstype) {
> -static const char table[] =
> -"autofs\0"
> -"bdev\0"
> -"cgroup\0"
> -"configfs\0"
> -"cpuset\0"
> -"debugfs\0"
> -"devpts\0"
> -"devtmpfs\0"
> -"efivarfs\0"
> -"hugetlbfs\0"
> -"mqueue\0"
> -"overlayfs\0"
> -"pipefs\0"
> -"proc\0"
> -
Re: [systemd-devel] Help needed for optimizing my boot time
On 06/11/2015 06:23 PM, Dan Williams wrote: > On Thu, 2015-06-11 at 15:15 +0200, Francis Moreau wrote: [...] >> >> Does ntpd service really need 'After=network.target', not sure. > > The 'network online' targets are really just there for ignorant services > that don't respond to network events themselves, that expect the network > to be up and running before they start. Of course, those services don't > have any way to say *which* network interface they care about, so if you > have more than one interface in your system they still get it wrong. Do such services exist actually ? I can't see how such service can work if they can't handle the offline case properly... BTW 'network online' target doesn't seem to mean the network is up because if I boot my computer offline, this target is still reached and passed. > > But anyway, if ntpd or autofs can respond to network events using > netlink or listening on D-Bus to NetworkManager/connman/etc or getting > triggered by eg NetworkManager dispatcher scripts, then they probably > don't need to block on network-online. But if they can't, and they > expect the network to be up and running before they start, then yes they > will block startup until some kind of networking is running. Well I must be missing something but I can't see why ntpd or autofs would rely and have any deps on NM whereas they need to deal with the generic case, i.e. the one where NM is not installed and used. In my understanding, they would either use netlink or simply retry later. I just checked ntpd source code and it seems to use netlink. I can't find any ntpd script installed in /etc/NetworkManager/dispatcher.d but ntpd get informed when an network interface is added/removed. IOW, any services having "After: network-online.target" look odd to me. Thanks ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [survey] BTRFS_IOC_DEVICES_READY return status
BTRFS_IOC_DEVICES_READY is to check if all the required devices are known by the btrfs kernel, so that admin/system-application could mount the FS. It is checked against a device in the argument. However the actual implementation is bit more than just that, in the way that it would also scan and register the device provided in the argument (same as btrfs device scan subcommand or BTRFS_IOC_SCAN_DEV ioctl). So BTRFS_IOC_DEVICES_READY ioctl isn't a read/view only ioctl, but its a write command as well. Next, since in the kernel we only check if total_devices (read from SB) is equal to num_devices (counted in the list) to state the status as 0 (ready) or 1 (not ready). But this does not work in rest of the device pool state like missing, seeding, replacing since total_devices is actually not equal to num_devices in these state but device pool is ready for the mount and its a bug which is not part of this discussions. Questions: - Do we want BTRFS_IOC_DEVICES_READY ioctl to also scan and register the device provided (same as btrfs device scan command or the BTRFS_IOC_SCAN_DEV ioctl) OR can BTRFS_IOC_DEVICES_READY be read-only ioctl interface to check the state of the device pool. ? - If the the device in the argument is already mounted, can it straightaway return 0 (ready) ? (as of now it would again independently read the SB determine total_devices and check against num_devices. - What should be the expected return when the FS is mounted and there is a missing device. Thanks, Anand ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] core: if PR_SET_CHILD_SUBREAPER fails, log_error instead of warning
On Sat, 23.05.15 13:04, Cristian Rodríguez (crrodrig...@opensuse.org) wrote: > It was a warning when we still supported kernel < 3.4. current > minimum version is 3.7. For the sake of the archives: this has been merged now as PR #76. 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] [ANNOUNCE] Git development moved to github
On Fri, Jun 12, 2015 at 5:30 AM, Filipe Brandenburger
wrote:
> On Thu, Jun 11, 2015 at 12:31 PM, Ronny Chevalier
> wrote:
>> On Thu, Jun 11, 2015 at 6:31 PM, Filipe Brandenburger
>> wrote:
>>> Another downside of adding comments to the commits is that e-mail
>>> notifications are not sent for them (I just noticed that while lurking
>>> on #164, I got e-mails for the main thread but not for Lennart's
>>> comments on commit 5f33680.)
>>
>> Yes you need to specify for each PR you are interested in that you
>> want to receive mail notifications for the PR... (I think it's the
>> subscribe button at the bottom)
>
> Sorry I should have explained myself better...
No I understood, but what I meant is that in addition of "watching", I
think you have to subscribe to a particular PR to receive mail
notifications for the comments on the commits, or maybe I'm wrong and
there is no way to get mail notifications for this, which is weird I
think...
>
> I "watch" systemd/systemd as a whole, so I get all notifications
> without having to ask for them individually...
>
> On #164, I *did* get an e-mail for @zonque's comment ("Also, you
> forgot to add the new files to Makefile.am and po/LINGUAS...") but I
> did *not* get e-mails for @poettering's comments on commit 5f33680
> ("Hmm, can you please change the commit msg to say this is the catalog
> translation? ...") and the replies on that thread (@s8321414 replied
> "@poettering How can I do this using git?" etc.)
>
> I think that's one more symptom of the fact that, for GitHub, the
> commit itself doesn't directly belong to the PR, and so does not
> belong to the project either...
>
> The e-mail notifications are not really a great big deal (still, they
> are annoying), but I think it's just one more sign that adding
> comments to the commits will end up causing trouble in the future...
>
> Cheers,
> Filipe
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
