You can add the chattr command as a postscript do new nodes will get it or
use the following command to set it across the entire cluster: psh <node
range/group> chattr +i /etc/resolv.conf
On Friday, March 7, 2014, Josh Nielsen <jniel...@hudsonalpha.org> wrote:
> Thank you Dennis and Jonathan. Setting PEERDNS=no was part of my "fix" to
> the ifcfg-eth* files, and I guess that's the best way to prevent
> revolv.conf from being overwritten then. I also saw the suggestion for
> chatt +i but would only like to use it as a last resort, since I might
> loose track of which nodes I have and haven't done that one, especially if
> it is a newly deployed node from xcat.
>
> So on to named.conf then. What would be resetting it? Does the slave
> configuration have something to do with it? I don't even know if it is a
> remotely initiated change or whether it originates locally for some reason.
> Is there any config I can post here that would help determine that?
>
> Thanks,
> Josh
>
>
> On Fri, Mar 7, 2014 at 11:50 AM, Jonathan Mills <jonmi...@renci.org>wrote:
>
> What Dennis says should work. However, I think the accepted "Redhat"
> way of doing it is to put
>
> PEERDNS="no"
>
> in you /etc/sysconfig/network-scripts/ifcfg-ethX script.
>
> On 03/07/2014 12:48 PM, Dennis Zheleznyak wrote:
> > You can lock the file by entering the following command chattr +i
> > /etc/resolv.conf. This will lock the file even for root.
> >
> > Dennis.
> >
> > On Friday, March 7, 2014, Josh Nielsen <jniel...@hudsonalpha.org
> > <mailto:jniel...@hudsonalpha.org>> wrote:
> >
> > I have noticed that with my recent restructuring of my cluster's DNS
> > hierarchy by creating two Service Nodes to stand in between the
> > compute nodes and the Management Node that I am having two separate
> > problems with files being overwritten once I modify them.
> >
> > Firstly, I configured the SNs to act as actual slave DNS servers
> > instead of just forwarding to the MN (that feature it looks like
> > will be officially supported in the next xcat release but is not
> > supported in the current one), so I had to edit /etc/named.conf to
> > facilitate that. Before I edited that file on both SNs it simply had
> > an options { } block ending with "forward only" and a "forwarders {
> > }" block with the IP of the MN, but I removed the "forward only"
> > statement, added zone definitions, and made each zone a slave to the
> > MN. It worked perfectly. The only problem is that every couple days
> > (and it happened again this morning) all my changes get erased
> > somehow and named.conf is regenerated to the default file with only
> > an options { } block. How can I prevent that from happening?
> >
> > Secondly, for compute nodes and storage nodes which were dhcp
> > enabled instead of statically assigned in their
> > /etc/sysconfig/network-scripts/ifcfg-eth* files, when I manually
> > edited the /etc/resolv.conf (though a postscript would do the same)
> > it too would get overwritten fairly soon after I made the change,
> > back to only pointing to the MN for DNS. I changed the resolv.conf
> > to point not just to the MN (as they did originally) but created
> > three "nameserver" entries to look for DNS name servers in the
> > following order: SN1, SN2, MN.
> >
> > I "fixed" this by statically assigning IPs in the ifcfg-eth* files,
> > but I am wondering if there is a better way. DHCP has the ability to
> > push out DNS server names for resolv.conf and so I looked to see if
> > it was the culprit and I changed the "option domain-name-servers"
> > line to include SN1, SN2, and the MN (does the "nameservers" value
> > in the xCAT 'site' table set this line?), but I'm not sure if that
> > is the line for DHCP responsible for changing the values in
> > /etc/resolv.conf, or how often the DHCP changes were pushed out
> > (this is happening for machines which are not being rebooted or
> > reinitialized in any way - just running as normal - and they
> > suddenly change their resolv.conf).
> >
> > Are any of the suggestions on this page good options:
> > http://www.cyberciti.biz/faq/dhclient-etcresolvconf-hooks/? I don't
> > have a dhclient.conf file on my RHEL/CentOS servers though. Anyway,
> > any suggestions would be much appreciated!
> >
> > Thanks,
> > Josh
> >
>
> --
> Jonathan Mills
> Systems Administrator
> Renaissance Computing Institute
> UNC-Chapel Hill
>
>
> ------------------------------------------------------------------------------
> Subversion Kills Productivity. Get off Subversion & Make the Move to
> Perforce.
> With Perforce, you get hassle-free workflows. Merge that actually works.
> Faster operations. Version large binaries. Built-in WAN optimization and
> the
> freedom to use Git, Perforce or both. Make the move to Perforce.
> <http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk>
>
>
------------------------------------------------------------------------------
Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
With Perforce, you get hassle-free workflows. Merge that actually works.
Faster operations. Version large binaries. Built-in WAN optimization and the
freedom to use Git, Perforce or both. Make the move to Perforce.
http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
_______________________________________________
xCAT-user mailing list
xCAT-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xcat-user
