| 1 |
This isn't meant to shoot stuff down, but more to suggest other places that |
| 2 |
filtering is probably going to be needed, based on some "advanced" [1] usage of |
| 3 |
Gentoo. |
| 4 |
|
| 5 |
On Sun, Jun 21, 2009 at 03:26:56AM +0200, Sebastian Pipping wrote: |
| 6 |
> What do I mean by auto-filtering? Auto-filtering works to protect the |
| 7 |
> user's privacy. It's the process of comparing his local settings |
| 8 |
> against the knowledge base of the Gentoo system: Every part of his |
| 9 |
> config that's outside of that larger set is stripped away, because |
| 10 |
> publishing that information could hurt his privacy. To make this more |
| 11 |
> concrete: |
| 12 |
I really need to get around to publishing one of my sekrit projects, |
| 13 |
"managed-portage", which I might as well start to describe here, as it's nearly |
| 14 |
ready. It's not so much a direct codebase for use, but a guideline on how to |
| 15 |
manage sets of machines that may match in certain dimensions only: location, |
| 16 |
purpose, hardware type [2] |
| 17 |
|
| 18 |
The entire managed-portage system works with stacked profiles, and |
| 19 |
various degrees of partial inheritance, so machines can end up with very |
| 20 |
different views of the package trees. |
| 21 |
|
| 22 |
Relevant to this, I might not want to disclose my profile inheritance |
| 23 |
tree. Here's one of them for you: |
| 24 |
/etc/make.profile |
| 25 |
/etc/managed-portage/hosts/build_webdb/make.profile |
| 26 |
/etc/managed-portage/common/post/make.profile |
| 27 |
/etc/managed-portage/class/webdb/make.profile |
| 28 |
/etc/managed-portage/class/db/make.profile |
| 29 |
/etc/managed-portage/class/web/make.profile |
| 30 |
/etc/managed-portage/common/pre/make.profile |
| 31 |
/etc/managed-portage/location/surrey/make.profile |
| 32 |
/etc/managed-portage/hwtype/nehalem/make.profile |
| 33 |
/usr/portage/profiles/default/linux/amd64/2008.0 |
| 34 |
|
| 35 |
> For Overlays .. |
| 36 |
> we filter out overlays not located below /usr/local/portage/layman/. |
| 37 |
This is going to be fail. |
| 38 |
1. That's not the only location used for layman. |
| 39 |
- At home: /code/gentoo/layman/ |
| 40 |
- At work: /usr/local/portage-layman/ |
| 41 |
- Gentoo Infra: /usr/portage/local/layman/ |
| 42 |
|
| 43 |
2. Just because an overlay is distributed by layman does NOT mean that |
| 44 |
it's safe to disclose the existence of, within Gentoo infra, we do |
| 45 |
this in layman.cfg: |
| 46 |
overlays : http://www.gentoo.org/proj/en/overlays/layman-global.txt |
| 47 |
file:///etc/layman/infra-overlays.xml |
| 48 |
|
| 49 |
While I don't mind disclosing the list of overlays we have in infra, |
| 50 |
other large-scale use of layman might not be happy to disclose it. |
| 51 |
If it came from the layman-global.txt, sure, it might be ok, but see if there's |
| 52 |
a way to filter out others. |
| 53 |
|
| 54 |
3. For one of my work overlays, we have a custom category called |
| 55 |
'ih-int', for our internal ebuilds (some just meta ebuild, others |
| 56 |
full applications). I might not want to disclose just those package names. |
| 57 |
|
| 58 |
Footnotes: |
| 59 |
[1] |
| 60 |
By "advanced", I mean stuff that I haven't seen used by many users, but have |
| 61 |
seen in large-scale business usage of Gentoo. |
| 62 |
|
| 63 |
[2] |
| 64 |
Hardware type is very fined grained for my use: |
| 65 |
- Usually pairs of motherboard+cpu combinations. |
| 66 |
- Multiple generations of Opterons. |
| 67 |
- Multiple generations of Xeons. |
| 68 |
|
| 69 |
-- |
| 70 |
Robin Hugh Johnson |
| 71 |
Gentoo Linux Developer & Infra Guy |
| 72 |
E-Mail : robbat2@g.o |
| 73 |
GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 |
Archives