Set "Defaults !fqdn" in sudoers file

[abbbi]

hi,

the current debian/ubuntu based images do have hardcoded dns servers set, that has been discussed various times before. While provisioning the images works without problem, i have noticed that in certain circumstances, executing elevated commands within the guests takes quite some time.

The reason for this is that sudo by default trys to resolve the fqdn of the system. This might not work because of the hardcoded DNS servers, if the hostname assigned to the system is an internal one, example:

 INFO ssh: Execute: echo '#VAGRANT-BEGIN
# The contents below are automatically generated by Vagrant. Do not modify.
#VAGRANT-END' >> /etc/fstab (sudo=true)
DEBUG ssh: Sending SSH keep-alive...

DEBUG ssh: Sending SSH keep-alive...
DEBUG ssh: Sending SSH keep-alive...
DEBUG ssh: Sending SSH keep-alive...
DEBUG ssh: Sending SSH keep-alive...
DEBUG ssh: Sending SSH keep-alive...
DEBUG ssh: Sending SSH keep-alive...
DEBUG ssh: Sending SSH keep-alive...
DEBUG ssh: stderr: sudo: unable to resolve host foo.bar.internal.de: Name or service not known

Maybe it would make sense to set

Defaults !fqdn

in /etc/sudoers for those images. Would save quite some time during provisioning.

Thanks for your hard work on those images, btw!

[timschumi]

Resolving the local hostname or fqdn should already be handled by the 127.0.0.1 entry in /etc/hosts, shouldn't it?

Do you have a Vagrantfile that replicates that behaviour?

[abbbi]

Resolving the local hostname or fqdn should already be handled by the 127.0.0.1 entry in /etc/hosts, shouldn't it?

Not if the virtual machine receives its hostname via DHCP too. This can for example be accomplished by setting the hostname to "localhost" via:

config.vm.hostname = "localhost"

Hostname will then be set during system boot via DHCP and is not existant in /etc/hosts.

[ladar]

@abbbi I'm not opposed to adding this. Almost all of the box configs already setup configure sshd with UseDNS no to avoid a similar problem when connecting via SSH. I guess the only real question mark is should it apply just the vagrant user, or be a default? And which boxes to add the change to?

[abbbi]

@abbbi I'm not opposed to adding this. Almost all of the box configs already setup configure sshd with UseDNS no to avoid a similar problem when connecting via SSH. I guess the only real question mark is should it apply just the vagrant user, or be a default? And which boxes to add the change to?

i think its fine for the vagrant user, thats the one that is used for provisioning by default and root doesnt need sudo, if enabled via ssh.. Probably makes sense for the common generic images such as centos/rhel/debian.

[ladar]

@abbbi I updated the sudo configuration for 64 of the 68 distro configs. I didn't apply the changes to NetBSD or OpenBSD. I also limited the change to just the vagrant user, so we deviate from the system defaults as little as necessary.

I'm a little worried about this change causing problems. The non GNU/Linux boxes are the most likely to have a problem, aka Alpine, and the BSDs. @timschumi if you have time, can you test/check my work?

[timschumi]

@timschumi if you have time, can you test/check my work?

I'll put it on my TODO-list, but it will likely take a few days until I can get to it. My backlog is a bit full at the moment.

[ladar]

@timschumi I uploaded most of the 3.6.2 boxes, but haven't released them yet. There was an error pushing the Parallels files, and I didn't realize it before leaving town. And there are issues with OpenSUSE 15 on Virtualbox and Devuan on Hyper-V, that I need to fix.

Bottom line is the rest are online, so if you notice any issues please let me know.

[timschumi]

@ladar I've tested a few images, every one of those that previously had issues now doesn't anymore. The remaining changes also look sane, and I haven't spotted any additional breakage. fqdn is apparently only useful anyways when using hostnames to configure sudo, which I don't think anybody does in a Vagrant setting (that said, there are evidently people that configure their Vagrant hostnames via DHCP :P).

Notably, I wasn't able to replicate the faulty behavior on Alpine or the BSDs, maybe there is a difference in default options there. But disabling that option explicitly is probably a good idea anyways.

The only thing I noticed is that OpenBSD apparently wasn't modified during your commit. I don't think that there is any practical difference (since, as I said, the BSDs seemingly disable that option by default anyways), just wondering if that was an oversight or intentional.

[ladar]

The only thing I noticed is that OpenBSD apparently wasn't modified during your commit. I don't think that there is any practical difference (since, as I said, the BSDs seemingly disable that option by default anyways), just wondering if that was an oversight or intentional.

I think it was an intentional oversight. As I recall, I didn't make the change to a couple of the configs because they used slightly different sudoers options, and based on the commit history, I was worried that making a change w/o testing it first might break things. So I didn't make the change to those config modules. In theory I'd boot the image first, and test the change before adding it to the config, just to make sure it doesn't introduce a syntax or other such error. I think OpenBSD uses an older version of sudo, a different implementation, or a customized set of rules for sudo to improve security that I vaguely recall having an issue with in the past. And unfortunately a broken sudoers config doesn't cause any problems when the box is built, but can make a box relatively useless to downstrea. That's because if Vagrant can't sudo during vagrant up then it can't update the system config during provisioning. So I tried to stick with making the change only to distros I thought would be comparatively safe without invidually testing each one.