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 |