You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I firstly noticed that after bootstrapping, the boot process of provisioned FreeBSD machine takes relatively long time and after some investigation, I noticed it is pending on sendmail.
The reason it is pending there is that sendmail tries to resolve DNS entries / hostnames / IP addresses and it fails do to it, in logs, it looks like this:
Aug 19 11:49:10 myhost sm-mta[696]: gethostbyaddr(192.168.56.100) failed: 2
Aug 19 11:49:25 myhost sm-mta[696]: gethostbyaddr(10.0.3.15) failed: 2
You see that it takes like 15 - 20 seconds to resolve it and it makes boot of the machine very very long.
In order to resolve this, you have to put valid stuff to /etc/hosts, I did it like this:
What is quite interesting is that without this change in /etc/hosts, the invocation of some Ansible playbook via ploy playbook path/to/playbook.yml takes very long time to execute as well because I think that Ansible internally on FreeBSD machine (that script in /root/.ansible) does some host resolution as well and it can not resolve it and it causes delays as in case of sendmail.
The solution would be to be able to specify custom /etc/hosts file while bootstrapping and be able to say what hostnames will be assigned to what IP addresses and this should be quite configurable so it adds them all there.
I would be satisfied with the ability to provide my custom /etc/hosts file where I hardcode these values but in the current state I do not see any way to do it becase in bootstrapping process, you are taking into consideration a lot of files but /etc/hosts.
The text was updated successfully, but these errors were encountered:
smiklosovic
changed the title
Ansible task and start of VM is very slow because of FreeBSD hostname - IP resolution making bsdploy unusable
Ansible task and start of VM is very slow because of FreeBSD hostname - IP resolution
Aug 19, 2015
I just used bootstrap-files for my master guest it etc/ploy.conf, I pointed it to ../bootstrap-files-master, there I put files.yml with my custom hosts file which gets copied to /etc/hosts while bootstrapping.
yes, you just found the reason for the existence of files.yml, congratulations! (seriously, that's a good find IMHO)
i'm still not sure, though, how to fix this properly... i'm pretty sure that it would be worth it, though, as ansible ususally runs a whole lot faster, if dns is properly configured.
@tomster @fschulze
I firstly noticed that after bootstrapping, the boot process of provisioned FreeBSD machine takes relatively long time and after some investigation, I noticed it is pending on sendmail.
The reason it is pending there is that sendmail tries to resolve DNS entries / hostnames / IP addresses and it fails do to it, in logs, it looks like this:
You see that it takes like 15 - 20 seconds to resolve it and it makes boot of the machine very very long.
In order to resolve this, you have to put valid stuff to
/etc/hosts
, I did it like this:These IPv6 records have to be there as well.
What is quite interesting is that without this change in
/etc/hosts
, the invocation of some Ansible playbook viaploy playbook path/to/playbook.yml
takes very long time to execute as well because I think that Ansible internally on FreeBSD machine (that script in/root/.ansible
) does some host resolution as well and it can not resolve it and it causes delays as in case of sendmail.The solution would be to be able to specify custom
/etc/hosts
file while bootstrapping and be able to say what hostnames will be assigned to what IP addresses and this should be quite configurable so it adds them all there.I would be satisfied with the ability to provide my custom
/etc/hosts
file where I hardcode these values but in the current state I do not see any way to do it becase in bootstrapping process, you are taking into consideration a lot of files but/etc/hosts
.The text was updated successfully, but these errors were encountered: