Build Docker container two times on different machines (Linux host and macOS host) ... no problems detected. closing this.

Can't reproduce the issue using commit 217aa6afaeb of vyos-build repo

Hi yun, please open a new ticket with your issue, and make a reference to this case :)

Sorry comment on a resolved ticket, but i'm having the issue that is described in this issue. And i'm not sure how to fix it.

Also, there appear to be some leftovers from before 1.2 in dhclient-script@Line45, where vyatta-dns-forwarding.pl was removed in favour of dns_forwarding.py.

PR has been created.

@joshua Can you please create a PR in github for this please, then you can post the reference here. thanks.

This is resolvable via the following two fixes. Once they are implemented GCP should work as expected.

In order to fully fix cloud-init issues this patch needs to be applied so that /etc/resolv.conf can be updated by cloud-init before host_name.py generates final resolv.conf. Since cloud-init fires before VyOS scripts this is required so that GCE metadata can be retried by cloud-init on 1st boot.

Sorry I can't merge it, no write access for me.

@hagbard @UnicronNL, please make a new one PR. This is correct patch:

diff -Naur origin/dhclient-script pull2/dhclient-script
--- origin/dhclient-script	2019-05-15 19:32:59.001598203 +0300
+++ pull2/dhclient-script	2019-05-15 19:33:47.533181873 +0300
@@ -39,7 +39,6 @@
         echo " " > $new_resolv_conf
     fi

I don't have write access, I created a PR and assign the task to @UnicronNL to review and either merge or reject.

It's causing a few cloudinit log errors on GCP during 1st boot. We speculate that might be the cause of some of the issues getting an image running correctly on the 1st boot.

Does it cause issues? I'm about to remove it from the code, juts want to find out if it is something urgent.

Hi, @rob
It works! Thanks a lot. This case can be closed now.

We are closer to a resolution here, however, some legacy code references are causing issues with the 1st boot before our dhcp patches are effective. This code reference is in the dhclient-script being called by cloud-init on the 1st boot. With this failure cloud-init cannot hit the GCE data-source on the 1st boot causing some issues. This will require more work tomorrow, however, I feel a resolution is rather close.

can you describe your problem a little bit more.
I do something like this in some cases maybe it match on your use case:

Made some more progress, however, well either need to use the workaround for GCE images or come up with something more elegant that resolves the cloud-init behavior.

I made some progress here using the debug image, however, it looks like cloud-init is still starting a dhclient process that doesn't need to exist as part of it's fallback networking.

Changing squid_ldap_auth to basic_ldap_auth should be enough to fix the ldap part.

So you used /usr/lib/squid3/basic_ldap_auth? Then I‘m going to correct the scripts

this config worked as expected with Microsoft AD.

Once you verify if the module works I‘m happy to fix it.

yesterday i give up with it, i will try it again later and report it here.

Does it work as expected?

Will be in the next rolling available.

As a work around do either:

So is it considered a bug or works as intented?

Already fixed by @hagbard and deployed into current rolling release.

As per request from dmbaturin on slack:

Only when you create an address, can be via dhcp or manually.

If that is the only point, race conditions can occur. I assume this is only called when comitting or loading the config.

https://github.com/vyos/vyatta-cfg-system/blob/current/templates/interfaces/ethernet/node.tag/address/node.def#L10

When is host_name.py called? Maybe my dhcp server just responds slow and host_name.py is called before dhcp server responds? Is that possible?

I can't reproduce, tested live and installed.

https://github.com/vyos/vyos-1x/commit/dcb9f521f9f6dbb98df8f644009c05342f596b5a

Looks like a race condition, since it is now being started by systemd as well, which was previously not the case.

But there was before a fully working one, anyway curl will work as well. Let's close this ticket then, was just bad communication I guess. I have found a few other issues, I'm currently looking into. Looks like netlink in the kernel changed, breaks netplug and pppoe-server. Thanks for pointing me into the right direction.,

Ah, now I see - yes this is correct, there is no "real" wget installed instead the BusyBox version is used. BusyBox is a multi-call binary (a lot of tiny helper programs shipped in one binary, program snipped is determined using argv[0] that's why every BusyBox binary is a symlink to /bin/busybox

wget https://downloads.vyos.net results in 'not an ftp or http url'

wget https://...
or if you check with ldd you'll see that it is only compiled against libc and that's it.

I can not reproduce the issue.

added not on old-style cfg-mode templates

Added a sidenote about switching on router and routing on switch

First commit on implementing this: https://github.com/runborg/vyatta-cfg-system/commit/15f6f2e06cc3e7d4e25f9cd381e70b8d978717f6

I'm not a fan of cluttering the OS too much, there are two much better ways

Relevant config: