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
Why does this cookbook write kernel.hostname to sysctl.conf? It seems that any value set here overrides the normal locally configured host name.
Running this before kernel.hostname was added to sysctl.conf would return the FQDN.
python -c 'import socket ; print socket.gethostname()'
After kernel.hostname added to sysctl.conf, then above command would return only what was set in kernel.hostname, which was the short name. As a result, many applications like python, php and splunk would get the short host name instead of the long host name.
To make matters worse, it appears you can't unset this kernel setting. If you try an write an empty value with the sysctl command:
Indeed. It's definitely an unexpected approach. I've been doing this for a long time, and I've never come across using kernel/sysctl parameters to set the hostname.
Having a hard time getting this cookbook to properly set the domain name (FQDN), and I suspect it's related to this issue.
Edit: there's a native chef resource, hostname, that should eliminate the need for this cookbook.
Why does this cookbook write kernel.hostname to sysctl.conf? It seems that any value set here overrides the normal locally configured host name.
Running this before kernel.hostname was added to sysctl.conf would return the FQDN.
python -c 'import socket ; print socket.gethostname()'
After kernel.hostname added to sysctl.conf, then above command would return only what was set in kernel.hostname, which was the short name. As a result, many applications like python, php and splunk would get the short host name instead of the long host name.
To make matters worse, it appears you can't unset this kernel setting. If you try an write an empty value with the sysctl command:
if you write an empty value to /proc/sys/kernel/hostname, it mucks up the whole system.
sysctl -p for a reload doesn't work either. If you remove the entry from /etc/sysctl.conf, and then run sysctl -p, then it's still there!
It looks like we may to reboot ALL our servers because of this.
The text was updated successfully, but these errors were encountered: