Gentoo Archives: gentoo-dev

From: Alan McKinnon <alan.mckinnon@×××××.com>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Managing etc/* in an embbeded system
Date: Wed, 22 Jul 2015 12:16:16
Message-Id: 55AF897F.2040002@gmail.com
In Reply to: Re: [gentoo-dev] Managing etc/* in an embbeded system by Joakim Tjernlund
1 On 22/07/2015 14:05, Joakim Tjernlund wrote:
2 > On Wed, 2015-07-22 at 07:14 -0400, Rich Freeman wrote:
3 >> On Wed, Jul 22, 2015 at 6:17 AM, Panagiotis Christopoulos
4 >> <pchrist@g.o> wrote:
5 >>>
6 >>> you can subscribe to gentoo-embedded mailing list and ask there, as your product
7 >>> is embedded. Also, man make.conf and search for CONFIG_PROTECT. If I understood
8 >>> you correctly, it may be what you need.
9 >>>
10 >>
11 >> That list is certainly a a good place if it is active, but I get the
12 >> impression that he wants to package/manage his config files in some
13 >> way. That is, install package foo, and then automatically get his
14 >> config files for foo.
15 >
16 > Yes, I need to be able to change my own config files too over time.
17 >
18 >>
19 >> Short of going to a true config management system, I'd consider just
20 >> having a tarball/etc full of config files that you unpack after you've
21 >> set up your system (or clone it from a git repo or whatever). If you
22 >> have config files for packages you didn't install it isn't a big deal
23 >> - they just use up a few inodes, and if you install the packages later
24 >> the CONFIG_PROTECT settings will prevent them from being overwritten.
25 >>
26 >> A portage-based alternative is to stick them all in a package(s)
27 >> (which will generate collision warnings, and since it would respect
28 >> config protect it would mean you have to merge in all the changes), or
29 >> fork all the ebuilds. I just don't think portage is really meant as a
30 >> full-fleged configuration management tool.
31 >
32 > There can not be any manual merges after an SW update here.
33 >
34 > I started to look at INSTALL_MASK, what if I set INSTALL_MASK
35 > to point to all conf files I want to manage myself.
36 > Then /etc/inittab etc. will not be touched when updating init
37 >
38 > Then I add my own ebuild containing my modified conf files but how to
39 > manage INSTALL_MASK, CONFIG_PROTECT etc.?
40 > Is it possible from within the ebuild change INSTALL_MASK, CONFIG_PROTECT?
41 > Then I could just zap INSTALL_MASK before installing my files.
42 >
43 >
44 >> Also, if you're doing lots of these installs you might want to look at
45 >> a true config management tool like ansible or puppet/chef. That could
46 >> take care of all the installation as well as the configuration, and
47 >> could be tied into portage.
48 >
49 > sound complicated for what I want to do
50 >
51
52 You could take the approach FreeNAS uses: /etc is a tmpfs mount.
53
54 If I read you correctly, upgrades are done with the appliance off-line
55 in the style of flashing a DSL router? In that case, upgrades will be
56 done in maintenance mode, with /etc not mounted. So *MASK* and *CONFIG*
57 don't even feature at all, just let emerge do it's thing as normal and
58 your customizations are not even in the picture. Your ebuild containg
59 config files should install copies somewhere appropriate, like /var/mystuff/
60
61 Last step of the install is to mount the /etc tmpfs, copy the existing
62 on-disk /etc to it then copy /var/mystuff to /etc. They will overwrite
63 portage's versions but so what? You know you want them changed and you
64 have persistent pristine original copies of portage's versions and your
65 mods. Finally, reboot.
66
67 This whole last step must also happen after reboot, so make it a custom
68 init script in an appropriate runlevel where you can launch it as needed
69 during upgrade and reboot.
70
71
72 --
73 Alan McKinnon
74 alan.mckinnon@×××××.com