[ale] Fstab fails
Wolf Halton
wolf.halton at gmail.com
Mon Aug 29 10:04:00 EDT 2011
I have been trying to get my nfs thing to work, but it has proven so
fragile that I am giving up on it.
So would it make sense to have the configs in a separate place from
the spot on the local server where they are used, right
/root/configs # git repo
and push them to
server-00:/configs # home server
server-01:/configs # 1st remote server
and so on.
I don't know how to do it with git and/or puppet. I have been looking
at autofs, which is more reminiscent of nfs (but nfs-style mount lines
fail). The autofs solution is more aimed at what I think of as
focus-clusters - 3-server groups that are linked in in their focus -
for instance, to deliver a specific application suite.
I like the "update every five minutes" of puppet.
Does it make the most sense to have a central puppet server that
pushes to all the other servers in the network segment, or would it be
better to have a puppet server on each focus-cluster?
Wolf
On Tue, Aug 9, 2011 at 10:20 AM, Avery Ceo <avery.ceo at gmail.com> wrote:
> None of which is a reason to avoid Puppet. It is a good way of doing push.
> Actually, the two can work well together. Keeping your Puppet configs in a
> local Git repository is a Good Idea™.
>
> On Aug 8, 2011 5:35 PM, "Jim Kinney" <jim.kinney at gmail.com> wrote:
>> With configs in version control it easy to roll back from a mistake.
>> Pushing from central repo is required for fast config change : for
>> servname
>> in $list do pushconfig&rehup; done
>> For pull, each must have a key on central or use same key (BAD!). Push
>> just
>> needs central key installed by default.
>> Other reasons to complicated for thumb typing on cell :-)
>> On Aug 8, 2011 3:49 PM, "Wolf Halton" <wolf.halton at gmail.com> wrote:
>>> Jim..
>>>
>>> I am almost sure that a pull from the clients makes more sense than a
>> push,
>>> but as usual I am open to suggestions.
>>> Why put the config files into a git or svn repo? Why not serve them
>> directly
>>> fro the actual files. I have been reading about puppet for a couple of
>>> hours and sorting out what would be useful here. It seems hugely useful,
>>> especially if I am pushing out configurations on a larger scale than I
>>> currently am doing.
>>>
>>> I have a test script that uses rsync to pull the files off the server,
>>> now
>>> that I am using crontab better, I can use cron to set the script to run
>> once
>>> an hour. I could use puppet to call the cron job that runs that on the
>>> client side, but rsync requires ssh password for the user. I do not
>>> understand how to set up puppet to pull the file-structure directly, but
>>> I
>>> think it would mean I didn't need the rsync script or the cron job, which
>>> would save a lot of lash-up, and wouldn't have to use an rsync daemon on
>> the
>>> server.
>>>
>>> -Wolf
>>>
>>> On Thu, Aug 4, 2011 at 2:30 PM, Jim Kinney <jim.kinney at gmail.com> wrote:
>>>
>>>> I would look at putting the config files in a subversion or git repo and
>>>> pushing out with repo sync or rsync or using puppet or cfengine to
>>>> handle
>>>> this.
>>>> On Aug 4, 2011 1:49 PM, "Wolf Halton" <wolf.halton at gmail.com> wrote:
>>>> > Oh, ok.. Thanks,
>>>> > I have not used automount before. Would you feel safe mounting a
>> critical
>>>> > directory with it - not necessarily a remote /home directory?
>>>> > The nfs share I have up is holding the config files for a web app.
>>>> > This
>>>> was
>>>> > our solution to having to update the config files on several servers
>>>> > in
>>>> the
>>>> > event that they needed to be edited. Without it, my test box has a
>>>> > copy
>>>> of
>>>> > the source on it, but it is plain that this failsafe didn't work all
>> that
>>>> > well.
>>>> >
>>>> > On Thu, Aug 4, 2011 at 12:57 PM, Lightner, Jeff <JLightner at water.com>
>>>> wrote:
>>>> >
>>>> >> Right – Avery’s email was saying you could use automount rather than
>>>> >> fstab. With automount the filesystem doesn’t mount at boot time but
>> does
>>>> >> mount the first time something tries to use it which should be long
>>>> after
>>>> >> boot.****
>>>> >>
>>>> >> ** **
>>>> >>
>>>> >> Automount also means the filesystem gets unmounted automatically when
>>>> not
>>>> >> in use and remounted when used later. One nice side to this is that
>>>> >> if
>>>> the
>>>> >> exporting server goes down and it isn’t currently NFS mounted on your
>>>> server
>>>> >> it doesn’t cause problems like hard NFS mounts do. ****
>>>> >>
>>>> >> ** **
>>>> >> ------------------------------
>>>> >>
>>>> >> *From:* ale-bounces at ale.org [mailto:ale-bounces at ale.org] *On Behalf
>>>> >> Of
>>>> *Wolf
>>>> >> Halton
>>>> >> *Sent:* Thursday, August 04, 2011 12:23 PM
>>>> >> *To:* Atlanta Linux Enthusiasts
>>>> >>
>>>> >> *Subject:* Re: [ale] Fstab fails
>>>> >> ****
>>>> >>
>>>> >> ** **
>>>> >>
>>>> >> In my case, the system is coming up but just without the nfs
>>>> >> directory
>>>> >> mounted. ****
>>>> >>
>>>> >> On Aug 4, 2011 9:03 AM, "Lightner, Jeff" <JLightner at water.com> wrote:
>>>> >> > Good idea.
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> > ________________________________
>>>> >> > From: ale-bounces at ale.org [mailto:ale-bounces at ale.org] On Behalf Of
>>>> >> Avery Ceo
>>>> >> > Sent: Wednesday, August 03, 2011 7:42 PM
>>>> >> > To: Atlanta Linux Enthusiasts; transam at verysecurelinux.com
>>>> >> > Subject: Re: [ale] Fstab fails
>>>> >> >
>>>> >> >
>>>> >> > Have you considered the automounter? By waiting until the first
>>>> attempt
>>>> >> to read a file before mounting the share, you might avoid your
>>>> >> startup
>>>> >> issue, and you would get remounts after a lost connection for free if
>>>> there
>>>> >> is a network blip.
>>>> >> > On Aug 3, 2011 6:47 PM, "Bob Toxen" <transam at verysecurelinux.com
>>>> <mailto:
>>>> >> transam at verysecurelinux.com>> wrote:
>>>> >> >> This still will hang in startup (though you'll probably be in
>>>> >> >> multiuser).
>>>> >> >>
>>>> >> >> Specify timeouts in case NFS cannot start, e.g., the server is
>> down.
>>>> >> >>
>>>> >> >> Bob Toxen
>>>> >> >>
>>>> >> >> On Wed, Aug 03, 2011 at 04:21:47PM -0400, Andrew Wade wrote:
>>>> >> >>> With NFS, I set fstab
>>>> >> >>>
>>>> >> >>> server:/ifs/fs02 /ifs/fs02 nfs bg,noauto,rsize=8192,wsize=8192 0
>>>> >> >>> 0
>>>> >> >>>
>>>> >> >>> *note the noauto, this tells it to not automount. If it tries to
>>>> >> automount
>>>> >> >>> and is unable, your server will stall in startup. So you put this
>>>> entry
>>>> >> in
>>>> >> >>> /etc/rc.local:
>>>> >> >>>
>>>> >> >>> mount /ifs/fs02
>>>> >> >>>
>>>> >> >>> Also check to make sure that nfs and portmap services are started
>>>> upon
>>>> >> boot
>>>> >> >>> time.
>>>> >> >>>
>>>> >> >>> That way, the server starts up and then mounts the nfs under
>>>> rc.local
>>>> >> (where
>>>> >> >>> if the nfs share hangs, it would not affect the normal system
>>>> startup).
>>>> >> >>>
>>>> >> >>>
>>>> >> >>>
>>>> >> >>> Andrew
>>>> >> >>> RHCE
>>>> >> >>>
>>>> >> >>> On Tue, Aug 2, 2011 at 5:50 PM, planas
>>>> >> >>> <jslozier at gmail.com<mailto:
>>>> >> jslozier at gmail.com>> wrote:
>>>> >> >>>
>>>> >> >>> > **
>>>> >> >>> > Wolf
>>>> >> >>> >
>>>> >> >>> > Could configuration be faulty, I asked about setting an
>>>> >> >>> > internal
>>>> ntfs
>>>> >> drive
>>>> >> >>> > awhile ago and I got this link from Ubuntu:
>>>> >> >>> >
>>>> >> >>> > https://help.ubuntu.com/community/Fstab
>>>> >> >>> >
>>>> >> >>> > It has links to more network configuration.
>>>> >> >>> >
>>>> >> >>> >
>>>> >> >>> > On Tue, 2011-08-02 at 14:27 -0400, Wolf Halton wrote:
>>>> >> >>> >
>>>> >> >>> > Can you think of any reason why fstab would not be read on
>> reboot.
>>>> >> Ubuntu
>>>> >> >>> > lucid have an nfs share that was not mounted automagically when
>> I
>>>> >> rebooted
>>>> >> >>> > the client machine. Broke a bunch of stuff.
>>>> >> >>> > Wolf
>>>> >> >>> > PS mount -a picked up and mounted the nfs directory.
>>>> >> >>> >
--
This Apt Has Super Cow Powers - http://sourcefreedom.com
More information about the Ale
mailing list