Re: Is it possible to make sure /etc/fstab mount points stay mounted with cfengine?

[Mark Burgess]

Sean, it is easy. You add the mountall, mountinfo to the action sequence in cf2.
In cf3 you don't have to do anything special if you verify a mountpoint.

At any rate you hardly need to write a script.

Sean Carolan wrote:
>> Is it possible to simply make sure that what is in /etc/fstab stays
>> mounted properly? I don't want to use addmounts to manage /etc/fstab.
>> We prefer to keep this file updated by hand.
>
> Maybe this is not possible to do with CFengine v2? Can it be done in
> cfengine v3? If making sure directories stay mounted properly is not
> possible I will write my own script to do it, or look into alternative
> configuration management systems.
> _______________________________________________
> Help-cfengine mailing list
> Help-c...@cfengine.org
> https://cfengine.org/mailman/listinfo/help-cfengine

--
Mark Burgess

-------------------------------------------------
Professor of Network and System Administration
Oslo University College, Norway

Personal Web: http://www.iu.hio.no/~mark
Office Telf : +47 22453272
-------------------------------------------------

[Mark Burgess]

Steve,

not to belittle your efforts, but you should definitely use storage promises to simplify this.

M

Steve Barnes wrote:
> Sean
>
> Here's a little something I finally got working at 2am last night. It
> ensures an slist of specific mount points always have the noatime flag
> (purely data folders in my case). If changes are made to the /etc/fstab
> file, a remount of the affected partitions is performed.
>
> Hopefully this can provide you with a basis to implement your specific
> requirements :)
>
> Steve
>
> PS, I'm new to CFEngine; feedback is always appreciated!
>
> ---
>
> bundle agent fb_fstab
> {
> vars:
>
> # our list of partitions to add the noatime flag to.
> "noatime_partitions" slist => {"/data1","/data2"};
>
> classes:
>
> # only for specific hosts that match this regex pattern.
> "do_it" or => { classmatch("qp.*"), classmatch("cr.*") };
>
> files:
>
> do_it::
>
> "/etc/fstab"
>
> edit_line => add_noatime_flag("noatime","4","$(noatime_partitions)"),
> classes => if_repaired("fstab_updated");
>
> commands:
>
> # if fstab was updated, we need to perform a remount of the affected
> partitions.
> fstab_updated::
>
> "/bin/mount -oremount" args => "$(noatime_partitions)";
> }
>
> bundle edit_line add_noatime_flag(flag,field_num,partition)
> {
> field_edits:
>
> "LABEL=$(partition).*"
>
> edit_field => col("[\s]+","$(field_num)","$(flag)","append");
> }
>
> ---
>
>> In the cfengine v2 reference the mountall directive is defined thus:
>>
>> mountall
>> mounts all filesystems defined in the hosts filesystem table. This
>> causes new NFS filesystems added by addmounts and mailcheck to be
>> actually mounted. This should probably be called both before mountinfo
>> and after addmounts etc. A short timeout is placed on this operation
>> to avoid hanging RPC connections when parsing NFS mounted file
>> systems.

>>
>> Is it possible to simply make sure that what is in /etc/fstab stays
>> mounted properly? I don't want to use addmounts to manage /etc/fstab.
>> We prefer to keep this file updated by hand.

[Steve Barnes]

[Steve Barnes]

Mark

I guess I have to experience the rough to appreciate the smooth! Thanks
for pointing out storage options, I'll update my configs to use them.

Steve

[Mark Burgess]

Steve, I don't know how well you float, but you are right that so far we've focused on
NFS. ;-) I also assumed that that was what you would be doing. It's pretty trivial to add
local mounts but I would have to look into it.

M

Steve Barnes wrote:
> Mark
>
> Please excuse my density, but I'm having a hard time getting storage
> promises to work correctly with purely local ext3 partition mounting. All
> of the documentation on storage promises, and the explored behaviour to
> date leans with a heavy bias towards NFS-only scenarios.
>
> Do storage promises actually cater for local ext3 partitions and mounting?
> ,
> Issues so far:
>
> - Inability to specify ext3 as a file system type.
> - The programmatic inclusion of ":" in the /etc/fstab device-name column.
> - Inability to specify `LABEL=<e2label>` for mount_source.
> - Inability to specify dump-freq/pass-num values for /etc/fstab.
>
> Perhaps I misunderstood the original question posted by Sean whom infact
> was asking about NFS management capabilities within CFEngine3?
>
> Thank you
>
> Steve

[Steve Barnes]

Mark

Please excuse my density, but I'm having a hard time getting storage
promises to work correctly with purely local ext3 partition mounting. All
of the documentation on storage promises, and the explored behaviour to
date leans with a heavy bias towards NFS-only scenarios.

Do storage promises actually cater for local ext3 partitions and mounting?

Issues so far:

- Inability to specify ext3 as a file system type.
- The programmatic inclusion of ":" in the /etc/fstab device-name column.
- Inability to specify `LABEL=<e2label>` for mount_source.
- Inability to specify dump-freq/pass-num values for /etc/fstab.

Perhaps I misunderstood the original question posted by Sean whom infact
was asking about NFS management capabilities within CFEngine3?

Thank you

Steve

>

[Sean Carolan]

> Is it possible to simply make sure that what is in /etc/fstab stays
> mounted properly?  I don't want to use addmounts to manage /etc/fstab.
>  We prefer to keep this file updated by hand.

[Les Mikesell]

The script command to do that, at least in linux, is just
mount -a

--
Les Mikesell
lesmi...@gmail.com

[Sean Carolan]

In the cfengine v2 reference the mountall directive is defined thus:

mountall
mounts all filesystems defined in the hosts filesystem table. This
causes new NFS filesystems added by addmounts and mailcheck to be
actually mounted. This should probably be called both before mountinfo
and after addmounts etc. A short timeout is placed on this operation
to avoid hanging RPC connections when parsing NFS mounted file
systems.