One problem I have with custom CentOS 6 installation is that NIS auto.* maps are not available. According to boot.log, ypbind starts before autofs, but when I login to the machine, the maps are not available until I issue a service autofs restart.
Any pointers on what to check?
Lars Hecking writes:
One problem I have with custom CentOS 6 installation is that NIS auto.* maps are not available. According to boot.log, ypbind starts before autofs, but when I login to the machine, the maps are not available until I issue a service autofs restart.
Any pointers on what to check?
I guess CentOS doesn't use pid randomisation. autofs does start before ybind:
root 2107 1 0 16:40 ? 00:00:00 automount --pid-file /var/run/autofs.pid root 2517 1 0 16:41 ? 00:00:00 /usr/sbin/ypbind root 3009 2976 0 16:43 pts/0 00:00:00 egrep auto|ypb
Another machine I installed interactively (this one is kickstarted) works correctly.
Lars Hecking writes:
Lars Hecking writes:
One problem I have with custom CentOS 6 installation is that NIS auto.* maps are not available. According to boot.log, ypbind starts before autofs, but when I login to the machine, the maps are not available until I issue a service autofs restart.
Any pointers on what to check?
I guess CentOS doesn't use pid randomisation. autofs does start before ybind:
root 2107 1 0 16:40 ? 00:00:00 automount --pid-file /var/run/autofs.pid root 2517 1 0 16:41 ? 00:00:00 /usr/sbin/ypbind root 3009 2976 0 16:43 pts/0 00:00:00 egrep auto|ypb
Another machine I installed interactively (this one is kickstarted) works correctly.
Solved.
The other machine doesn't have NetworkManager installed. Removed it here and NIS/autofs started working correctly.
Why again did RH switch to NM?
----- Original Message ----- | Lars Hecking writes: | > Lars Hecking writes: | > > | > > One problem I have with custom CentOS 6 installation is that NIS | > > auto.* | > > maps are not available. According to boot.log, ypbind starts | > > before autofs, | > > but when I login to the machine, the maps are not available | > > until I issue | > > a service autofs restart. | > > | > > Any pointers on what to check? | > | > I guess CentOS doesn't use pid randomisation. autofs does start | > before | > ybind: | > | > root 2107 1 0 16:40 ? 00:00:00 automount | > --pid-file /var/run/autofs.pid | > root 2517 1 0 16:41 ? 00:00:00 /usr/sbin/ypbind | > root 3009 2976 0 16:43 pts/0 00:00:00 egrep auto|ypb | > | > Another machine I installed interactively (this one is | > kickstarted) works | > correctly. | | Solved. | | The other machine doesn't have NetworkManager installed. Removed it | here | and NIS/autofs started working correctly.
You don't have to remove NetworkManager you just need to tell the interface not to be managed by NM in order for it to work.
| Why again did RH switch to NM?
To better support mobile devices like laptops and to make network configuration easier for new GNU/Linux users.
| The other machine doesn't have NetworkManager installed. Removed it | here | and NIS/autofs started working correctly.
You don't have to remove NetworkManager you just need to tell the interface not to be managed by NM in order for it to work.
Won't help in this case, I think, as this behaviour already makes my kickstart %post fail.
| Why again did RH switch to NM?
To better support mobile devices like laptops and to make network configuration easier for new GNU/Linux users.
Well, I appreciate NM on laptops, but this is a distro geared towards enterprise. I can't imagine many enterprise users running a distro on laptops where most software components are already outdated upon release and support for newer hw may be sketchy.
----- Original Message ----- | | > | The other machine doesn't have NetworkManager installed. Removed | > | it | > | here | > | and NIS/autofs started working correctly. | > | > You don't have to remove NetworkManager you just need to tell the | > interface not to be managed by NM in order for it to work. | | Won't help in this case, I think, as this behaviour already makes my | kickstart | %post fail.
Once you make the network interface no longer NM managed you can then perform a service network restart in your post and all network functionality should then become available.
| Won't help in this case, I think, as this behaviour already makes my | kickstart | %post fail.
Correcting myself ... what fails is an init script generated at %post time.
Once you make the network interface no longer NM managed you can then perform a service network restart in your post and all network functionality should then become available.
I don't see the need for NM on racked servers and stationary workstations.
Once you make the network interface no longer NM managed you can then perform a service network restart in your post and all network functionality should then become available.
This may be desired or true in theory, but is not working.
I have NM_CONTROLLED="no" in ifcfg-eth0, and it works according to the logs ("Ignoring connection 'System eth0' and its device due to NM_CONTROLLED/BRIDGE/VLAN"), but NIS is not working. yp.conf is correct as created through dhcp, domainname returns the correct domain, and ypbind is running. Yet ypwhich returns cannot communicate with ypbind. Once I stop NetworkManager, it starts working.
Lars Hecking wrote:
Once you make the network interface no longer NM managed you can then perform a service network restart in your post and all network functionality should then become available.
This may be desired or true in theory, but is not working.
I have NM_CONTROLLED="no" in ifcfg-eth0, and it works according to the logs ("Ignoring connection 'System eth0' and its device due to NM_CONTROLLED/BRIDGE/VLAN"), but NIS is not working. yp.conf is correct as created through dhcp, domainname returns the correct domain, and ypbind is running. Yet ypwhich returns cannot communicate with ypbind. Once I stop NetworkManager, it starts working.
Yeah. Here, we do chkconfig NetworkManager off, and stop it. Then we have a lot fewer issues.
mark