[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: generic (cloud) image problems



Am Fr., 27. Dez. 2019 um 22:04 Uhr schrieb Thomas Goirand <zigo@debian.org>:
> Probably the ip command can be used to setup vlan, though to my
> understanding, the vlan package is needed for ifupdown to understand
> interfaces of type vlan<ID>, and the same way, bridge-utils is needed
> for bridges, and ifenslave for bonding. I do believe that Christian
> request is very much valid, and that the above 3 packages should be
> installed, together with gnupg2.

Right, both bridge-utils and vlan are required to setup a bridge or
vlan from *within* /etc/network/interfaces.
ifupdown2 or iproute2 don't help here. Also, if the network can't be
setup initially there will be no network connection to load additional
packages (chicken and egg problem)

> >> and gnupg2 is required to add 3rd party repos (otherwise
> >> "apt-key add" won't work). Both - network access and 3rd party repos -
> >> may be required for further steps of an deployment (i.e. to install
> >> automation tools like salt, chef or puppet).
>
> Though I do understand that gnupg2 is better there by default, I have a
> few remarks that may help as workarounds.
>
> I don't see why you'd like to install puppet from upstream. The puppet
> package in Debian is very well maintained, and probably better than the
> one from upstream.

In my case I need to install Saltstack salt-minion form a third party
repo. Maybe puppet was a bad example, but at least chef would have a
similar issue.

> Also, if you're installing stuff through metadata, why can't you first
> install gnupg2, then install 3rd party repos?

The order in cloud-init is fixed (as per /etc/cloud/cloud.cfg).
"apt-configure" (which sets up repositories) is run in the config
stage while "package-update-upgrade-install" is invoked in the final
stage. There is no back and forth between stages. This is also the
reason why core packages need to be in the base image. If they are
only installed in the final stage, modules requiring them in earlier
phases can't take advantage of the install. I'm not sure if the config
stage would be invoked a second time on reboot, but at least the
network setup isn't performed again (after installing packages).



Best regards,
   Christian


Reply to: