Gentoo Archives: gentoo-user

From: James <wireless@×××××××××××.com>
To: gentoo-user@l.g.o
Subject: [gentoo-user] GLEP:64
Date: Sun, 15 Feb 2015 18:15:36
1 Hello,
3 Ok, so Gelp_64 could be very useful to me for reasons
4 above and beyond the administrative vision of the devs.
6 For example, is there a way (scripts or xml wise) to
7 expand /var/db/pkg to include codes I install via
8 /usr/local/ or via some subset of rpm or dpkg installed codes
9 as discussed in a recent thread?
12 I'm working on setting up ansible to install (clone?) new gentoo
13 systems, where pretty much the identical system to one
14 that exists would be an excellent starting point. Is there a way to
15 parse /var/db/pkg, or use a "directed graph" as blueness
16 has suggested to populate Ansible with the necessary details
17 to build a clone (gentoo) system?
20 And then there are security audits, such as a fully characterized
21 list of files and the dir hierarchy of a system. Sure some of these exist
22 in current security tools, but the complete mapping, via
23 /var/db/pkg does seem like an excellent idea, and if nothing else
24 an excellent checking (redundant) mechanism for security audits
25 or to determine if something is misses via SeLinux configurations.
27 Also, as I grab codes and install them ( particularly without using
28 an ebuild to perform the installation) how do I track all of those created
29 files, with a mechanism independent of the mechanism inherent
30 to the code. Trust is great but the best rule is to 'trust but verify'. ymmv.
33 Then there is the new repo.conf and epatch_user files that should be
34 tracked. I'm quite sure there are still many other ways outside files find
35 there way onto our systems (not even addressing the web side of things)
36 besides what I have partially listed in this post.
38 If folks have similar concerns, what mechanisms do you currently employ
39 for any of these aforementioned needs?
43 James