There is also an ebuild included in the git repo. To use it, simply add it to your local portage repository, e.g. /usr/local/portage or similar. I suggest putting it into app-admin. Don't forget to run ebuild update-conf-9999.ebuild digest on it. You should then be able to use it by running emerge app-admin/update-conf.

------

Hi!

In January 2008 I wrote a very simple script to manage fstab entries in the way like environment variables in /etc/env.d are managed. For this I created separated fstab files in /etc/fstab.d and wrote the following update-fstab script (that I would recommend going into /usr/local/bin).

If you find this script useful – use it.

If you want to comment on my script (and my deriative idea for /etc/fstab.d) – I welcome it!

If you want to enhance my script – go ahead.

I'd like to hereby release it in the terms of the GPL-2 or later. But I don't really know it this is actually possible for such a simple thing like this shell script. Anyway, this is what I want.

## SETUP
# fstabdpath sets the path where the individual fstab file are located, this should normaly be /etc/fstab.d.
fstabdpath="/etc/fstab.d"
# fstabdverbose sets the verbosity level. Default is 1 (no messages). If you want verbose output set this to 2.
fstabdverbose="1"

But for these mostly static enties I didn't create the script. I used to have temporary entries like changing NFS shares or USB media that needed special options, so I had to change my /etc/fstab file very often.
I found this script and the /etc/fstab.d directory very handy and useful for this type of usage.

Also, now I can try experimental options and temporary fstab entries in my /etc/fstab that are deleted (reverted, reset) to the /etc/fstab.d entries once I re-run update-fstab.

It is intended that the output includes only lines that don't start with # (comments) and empty lines. The previous /etc/fstab is backed up to /etc/fstab.d.bak.

I RECOMMEND BACKING UP YOUR ORIGINAL /etc/fstab! DON'T USE /etc/fstab.d.bak FOR YOUR BACKUP!

If this is useful for anyone, feel free to use it or enhance it. I'd like it to be GPL-2 or later licensed.

Thanks.

Last edited by Atha on Sun Sep 15, 2013 10:40 pm; edited 5 times in total

It now refuses to work if /etc/fstab.d/fstab is present (since this file may have been added by a user, and we don't want to overwrite it without pointing it out).

Errors are now on stderr (>&2)

The check for /etc/fstab.d/fstab isn't really required, since the script just created this file (that's its main purpose!) – so why bother looking for it? We know it's there!

So this is the new script:

Code:

#!/bin/sh

## SETUP
# fstabdpath sets the path where the individual fstab file are located, this should normaly be /etc/fstab.d.
fstabdpath="/etc/fstab.d"
# fstabdverbose sets the verbosity level. Default is 1 (no messages). If you want verbose output (i.e. to debug) set this to 2.
fstabdverbose="2"

if [ -e ${fstabdpath}/fstab ] ; then
echo "update-fstab: please remove ${fstabdpath}/fstab before you run this script.
update-fstab: NOTE: It may have been left by a previously run update-fstab, but you should check anyway." >&2
exit 1
fi

cat<<'EOT' > ${fstabdpath}/fstab && message "Header added"
# /etc/fstab
# automatically generated by the update-fstab script
#
# Please change the according lines in /etc/fstab.d/* if you want them to be permanent,
# otherwise they will not survive the next invocation of update-fstab!
#
EOT

This should be it then. I added some useful information and made all the improvements that truc came up with. I hope it now is conform to standards so it will run on a lot of Unix-based systems. (But who would want to manage their fstab entries manually except for Gentoo Linux people?) It sure is faster than it was before – so again, big big thanks to truc.

I learned a lot about shell scripts any maybe my next script (if any) will be better right away.

So, here the (up to this point) final version:

Code:

#!/bin/sh
# Script for flexible /etc/fstab.d configuration
# From Atha, with a lot of improvements from truc - thanks!
#
# You can find information on how to use this script at
# http://forums.gentoo.org/viewtopic.php?p=6364143
#
# This script idealy goes into /usr/local/bin and is called update-fstab -
# you need to configure your fstab entries in separate files in /etc/fstab.d;
# only filenames starting with two digits are included!
# Examples: /etc/fstab.d/01base or /etc/fstab.d/61nfs-dm8000, to name just two.
#
# Copyright 2008 Atha
# Distributed under the terms of the GNU General Public License v2 or later

## SETUP
# fstabdpath sets the path where the individual fstab file are located, this should normaly be /etc/fstab.d.
fstabdpath="/etc/fstab.d"
# fstabdverbose sets the verbosity level. Default is 0 (no messages). If you want verbose output (i.e. to debug) set this to 1.
fstabdverbose="1"

if [ -e ${fstabdpath}/fstab ] ; then
echo "update-fstab: please remove ${fstabdpath}/fstab before you run this script.
update-fstab: NOTE: It may have been left by a previously run update-fstab, but you should check anyway." >&2
exit 1
fi

cat << 'EOT' > ${fstabdpath}/fstab && message "${fstabdpath}/fstab created, header added"
# /etc/fstab
# automatically generated by the update-fstab script
#
# Please change the according lines in /etc/fstab.d/* if you want them to be permanent,
# otherwise they will not survive the next invocation of update-fstab!
#
EOT

Hi,
I wonder if you have any elegant solution to overcome modifications made by the system to /etc/fstab (might be rare, but still possible).

As far as I understand, one might move original /etc/fstab into /etc/fstab.d/01base (and edit it to remove non-system/base mounting points to place them in other /etc/fstab.d/* files) before using update-fstab script.
Hence, it'll be possible to add extra functionality to apply any modifications made to /etc/fstab by the system, by patching /etc/fstab.d/01base.
It would require to store a copy of the latest generated fstab somewhere in /etc/fstab.d to perform diff & patch, etc.

Maybe I can implement this.
Any remark on this idea before I go forward?

If I bring modifications to this script, I surely will create a git repository... or maybe a repo already exists?
A public repo is often better to review modifications and send patches.

Hi,
I wonder if you have any elegant solution to overcome modifications made by the system to /etc/fstab (might be rare, but still possible).

As far as I understand, one might move original /etc/fstab into /etc/fstab.d/01base (and edit it to remove non-system/base mounting points to place them in other /etc/fstab.d/* files) before using update-fstab script.
Hence, it'll be possible to add extra functionality to apply any modifications made to /etc/fstab by the system, by patching /etc/fstab.d/01base.
It would require to store a copy of the latest generated fstab somewhere in /etc/fstab.d to perform diff & patch, etc.

I like this idea. Only, I've originally seperated Gentoo's “vanilla” /etc/fstab into [/etc/fstab.d/]01base and 02pseudo (and additionally 10media for the /dev/cdrom and /dev/fd0 examples, if they're still available on a fresh Gentoo installation). We could of course reunite them into, say, 01gentoo or so. 01base is also okay.

NicoLarve wrote:

Maybe I can implement this.
Any remark on this idea before I go forward?

I'm not really an expert, but does the system actually update /etc/fstab at all? I'm a Gentoo user since release 1.2 (was it 2002?) and I don't remember it ever happening. I've always had the impression that /etc/fstab is purely user controlled. (The Gentoo way.)

NicoLarve wrote:

If I bring modifications to this script, I surely will create a git repository... or maybe a repo already exists?
A public repo is often better to review modifications and send patches.

Please, go ahead. I'd be happy if you improve my script.
No repo currently exists, as I didn't think it would be necessary for such a tiny script. But, if you think this is the best way: go ahead.

To be honest, I'm quite surprised that someone other than me actually uses this script. It sure does make he happy though. So I can only say: Thanks for using it! Thanks for improving it! Thanks for participating!

Maybe I can implement this.
Any remark on this idea before I go forward?

I'm not really an expert, but does the system actually update /etc/fstab at all? I'm a Gentoo user since release 1.2 (was it 2002?) and I don't remember it ever happening. I've always had the impression that /etc/fstab is purely user controlled. (The Gentoo way.)

Actually, it rarely happens but, for example under Debian, when the system wants to ensure it will boot the good device (e.g. on some systems SAS & SATA disks might have different device files after a reboot) it modifies fstab to use UUIDs instead of a device path such as /dev/sda1.

Atha wrote:

To be honest, I'm quite surprised that someone other than me actually uses this script. It sure does make he happy though. So I can only say: Thanks for using it! Thanks for improving it! Thanks for participating!

It's been a couple of month (years?) that I regularly google for "/etc/hosts.d" (I don't use LDAP but I like to automate things) or "/etc/fstab.d".
Your script seems good and have been polished thanks to users ont his thread!
Moreover, maybe I will consider to port it to /etc/hosts and a few other config files that aren't '.ded' yet.

Your script is already installed on two of my machines!
And will be on 3 others really soon!
Indeed, I use svn to version some system config files and I share them, as appropriate, on multiple machines. I already created an fstab.d file to define standard mount points for my main usb mass storage device (using LABEL=...), then I will share this file on multiple machines where I often plug these devices. This is powerful for many reason incliding the fact that any device will be mounted to the same path on any machine, giving you opportunity to run scripts on them, etc.

It'll may take some time, but yes, I'll go ahead!

And, finally: a repo (even private) is always a good thing when people comes to give you feedback.

Actually, it rarely happens but, for example under Debian, when the system wants to ensure it will boot the good device (e.g. on some systems SAS & SATA disks might have different device files after a reboot) it modifies fstab to use UUIDs instead of a device path such as /dev/sda1.

This would happen in /etc/fstab, so you would have to check what acutally was changed and “back-adpot” the corresponding entries in /etc/fstab.d/* – which will have to go between the comments and empty lines. If you could really modify the script to make this possible – wow! I couldn't think of a way of doing this…

NicoLarve wrote:

It's been a couple of month (years?) that I regularly google for "/etc/hosts.d" (I don't use LDAP but I like to automate things) or "/etc/fstab.d".
Your script seems good and have been polished thanks to users ont his thread!
Moreover, maybe I will consider to port it to /etc/hosts and a few other config files that aren't '.ded' yet.

Your script is already installed on two of my machines!
And will be on 3 others really soon!

I'm very happy this idea of mine was of good use. This is more than I had ever hoped. Simply because I figured: if it had been a good idea, someone else would have made such a script already. At least so was my thinking…

NicoLarve wrote:

It'll may take some time, but yes, I'll go ahead!

And, finally: a repo (even private) is always a good thing when people comes to give you feedback.

Yes, please do. Please link your enhancements here, be it the modified script entirely or a cvs repo or … any other possibility.

Like I mentioned above I was interested in extending your script to support for /etc/*.d/ and I did it a couple of month ago. I tested it a lot (on about 12 machines on 3 different networks). Because it is generic, it is called update-conf.d.

So, one can consider spliting its /etc/lambda entries into /etc/lambda.d/*.

In order to reduce risks, the script first looks for a config file (/etc/update-conf.d.conf) to check if it is authorized to rebuild a particular /etc/lambda file on the basis of /etc/lambda.d/* files. The config file just consist in one confg file name per line (e.g. fstab, hosts, etc.).

Note that in /etc/lambda.d/*, as in the original script, '*' must be a file whose name begins with [0-9][0-9].

This version adds a little more verbosity both on stdout (what is done) and in the resulting file (where config lines come from, really helpful).

For the moment, this code is a part of a really big repo of mine, so it hasn't its own repo, maybe I'll do it one day (with its full history). I also have other nice ideas such as protecting /etc/lamba against manual edition and if that still happen, to automatically move such "illegal config" from /etc/lamba to a "lost+found" file (e.g. in /etc/lambda.d/lost+found) to finally warn the user (admin).

Here it is:
(view the patch related to the current version (2011-06-12) on this thread)

Code:

#!/bin/sh
#
# Script for flexible /etc/*.d configuration
# From Atha, with a lot of improvements from truc - thanks!
# Generalized for /etc/*.d by Nicolas Bercher nbercher@yahoo.fr
#
# This script ideally goes into /usr/local/sbin and is called update-conf.d -
# you need to configure your <conf> entries in separate files in /etc/<conf>.d;
# only filenames starting with two digits are included!

# Examples: /etc/fstab.d/01base or /etc/hosts.d/61nfs-dm8000, to name just two.
#
# Copyright 2011 Nicolas Bercher
# Copyright 2008 Atha
# Distributed under the terms of the GNU General Public License v2 or later
#
# You can find information on how to use this script at
# http://forums.gentoo.org/viewtopic.php?p=6364143
#

if [ -e "${dconfpath}" ] ; then
echo "${0}: please remove ${dconfpath} before you run this script.
${0}: NOTE: It may have been left by a previously run ${0}, but you should check anyway." >&2
exit 1
fi

cat << 'EOT' > "${dconfpath}" && message "${dconfpath} created, header added"
# Configuration file automatically generated by the update-conf.d
# script.
#
# Please change the according lines in /etc/<conf.d>/* if you want
# them to be permanent, otherwise they will not survive the next
# invocation of update-conf.d!
#
EOT

Okay, I've added update-conf.d to the repository at GitHub. I also added a Makefile for easier installation.

@NicoLarve: I hope it was okay to upload your script to the repository.

Everybody, you're welcome to test it and give feedback:
Edit Makefile and set PREFIX=/tmp or any other directory you have write access to as a regular user. Copy your system fstab (as a test subject) to the PREFIX directory, like so: mkdir /tmp/etc ; cp /etc/fstab /tmp/etc/fstab – it will be used by the Makefile to install an initial /tmp/etc/fstab.d/00fstab. Then install it with make build ; make install and run the script (with the full path, because of the PREFIX=/tmp: /tmp/usr/local/sbin/update-conf.d) as you would normally do as root. You can also test the make uninstall on that PREFIX.

One thing may be a problematic approach: the automatic creation of /etc/fstab.d/00fstab and /etc/update-conf.d.conf. Because it will overwrite (without asking) any existing files. As I said: feedback please!

Create your SSH key pair (password is really importaint to remember/write down somewhere!). Send me your public SSH key so I can add you to this GitHub repository. Then you’ll have full access and can correct/modify/improve/change/add whatever you see fit.

src_prepare() {
echo "patching the makefile with s:^PREFIX=:PREFIX=${D}: (required to prevent make to write outside the sandbox)"
sed -i "s:^PREFIX=:PREFIX=${D}:" Makefile
echo "patching the configuration to ensure it looks in /etc instead of in the sandbox"
sed -i 's%@CONFIGDIR@%/etc%' update-conf.d.in