1 |
On Thu, Aug 04, 2005 at 05:31:43PM -0400, Chris Gianelloni wrote: |
2 |
> The only things I could see being needed out of portage itself is the |
3 |
> ability to control "emerge" commands remotely, such as forcing an update |
4 |
> of apache to $version to resolve a vulnerability. |
5 |
|
6 |
The requirements of portage, or whatever component supplies |
7 |
(essentially) pkg management of remote boxes is going to be a bit more |
8 |
complex then just pushing emerge commands out; aside from config data, |
9 |
it'll probably centralize the vdb type contents somewhere, let alone |
10 |
avoiding N copies of the ebuild tree on each server. |
11 |
|
12 |
Basically, whatever daemon is running clientside for all of this will |
13 |
have to support a good bit of handing off commands to portage, hence |
14 |
the interest (since from my point of view, it's a starting point). |
15 |
|
16 |
|
17 |
> Some things I could see as needed: |
18 |
> |
19 |
> 1. applying updates on any file that is under CONFIG_PROTECT where the |
20 |
> md5/file-size matches that in /var/db for the file without user |
21 |
> interactio |
22 |
|
23 |
That would have to be determined prior to starting the update push. |
24 |
I'd think basically a CONFIG_PROTECT limited scan of boxes to be |
25 |
updated, verifying things are in order according to the vdb (whether |
26 |
remote or local to that box) probably would fly. |
27 |
|
28 |
|
29 |
> 2. automatic removal of files under CONFIG_PROTECT where the |
30 |
> md5/file-size matches that in /var/db during unmerge |
31 |
|
32 |
current vdb implementation relies on md5/file-size, future should rely |
33 |
on refcount, and be a good bit more configurable. |
34 |
|
35 |
|
36 |
> > It's not an overnight thing, glep19 (stable portage tree) addresses a |
37 |
> > chunk of concerns when/if it's implemented, but I'm a bit more |
38 |
> > interested in the the other tools people desire alongside. |
39 |
Offhand, responding to my own snippet, I'd love to know what's going |
40 |
on with glep19... |
41 |
|
42 |
> |
43 |
> As am I. The Installer is one such project. We do not have any project |
44 |
> that I am aware of that is designed to resolve the problem of remotely |
45 |
> managing a server. There is nothing for pushing config changes/package |
46 |
> updates/new packages. There would need to be some interface for doing |
47 |
> these things. Stop by any trade show, such as LWE, and you'll see guys |
48 |
> pushing their wares on remotely managing Linux. We should provide |
49 |
> something like this ourselves. |
50 |
> |
51 |
> eg. If I want to change the subnet mask or default router on 50 machines |
52 |
> on my network, I should be able to do so via a simple interface and have |
53 |
> the work done automatically. |
54 |
|
55 |
Approach I've been thinking about (that fits semi-neatly exempting |
56 |
collision-protect) is essentially config pkgs, binding them on the fly |
57 |
to pkgs being pushed out. Essentially, base apache pkg (that out of |
58 |
an ebuild tree), with it's depend tweaked automatically to pull in a |
59 |
matching configuration pkg. |
60 |
|
61 |
Pushing out config updates wouldn't be too hard if handled in this |
62 |
manner, although generation of the config pkgs themselves would be a |
63 |
bit tricky. |
64 |
|
65 |
|
66 |
> > Re: a drop-in solution, considering that gentoo is effectively all |
67 |
> > over the map (seriously, look at the tree), define the profile for the |
68 |
> > drop-in; drop-in ftp, drop-in web server, drop-in mosix node... etc. |
69 |
> |
70 |
> I meant a drop-in management solution, not a specific set of server |
71 |
> profiles, though those could be created with the Installer. In fact, I |
72 |
> see the Installer as one of the first pieces of the framework necessary |
73 |
> for deployment and management of a large number of servers. Once the |
74 |
> netfe interface is completed with the Installer, you will be able to PXE |
75 |
> boot your server and have it load a specific installer profile, and it |
76 |
> will install Gentoo to those specifications. Beyond that, we lose |
77 |
> control of the server and must manually perform all other actions. |
78 |
Niete. |
79 |
|
80 |
> > Specifics... |
81 |
> > |
82 |
> > Hell, I have yet to see what I would define as a proper solution for |
83 |
> > config manamagent for N gentoo boxes. NFS solution possibly, but that |
84 |
> > seems a bit hackish to me. |
85 |
> |
86 |
> There isn't a proper solution yet. Honestly, something like a |
87 |
> repository holding configuration information with revision control would |
88 |
> probably be best, so you can revert changes. There are quite a few |
89 |
> systems like this out for Red Hat and others, but nothing that is |
90 |
> Gentoo-specific, or even Gentoo-capable, as far as I know. We should |
91 |
> beat people to the punch and design one ourselves. |
92 |
> |
93 |
> The main things we need to provide are: |
94 |
> |
95 |
> Provisioning - building a server from bare metal to some pre-determined |
96 |
> state |
97 |
Installer... |
98 |
|
99 |
> Management - being able to make changes to existing servers without |
100 |
> manually logging into each to make the changes |
101 |
Domain class should provide for it |
102 |
> Updates - this somewhat goes with management, but a facility for |
103 |
> disseminating patches or updated packages to servers |
104 |
Same as above |
105 |
|
106 |
|
107 |
> Our tools. Currently, we have very few "Gentoo tools" used for managing |
108 |
> a system. We would need to define the requirements for these tools, and |
109 |
> then work on ways of getting them built. It's like I said, I think the |
110 |
> primary weakness in Gentoo's enterprise adoption is the need for each |
111 |
> company to reinvent the wheel on their own deployment. If we had a set |
112 |
> of extensible tools for managing Gentoo machines, then companies would |
113 |
> have a framework for building upon to meet their own needs. Why does |
114 |
> everyone, for example, need to invent their own way of adding users to |
115 |
> their network? Why can't we provide some method and allow them to |
116 |
> customize it and extend it? |
117 |
glep27 comes to mind re: users, although that's not management of |
118 |
samba users (fex). |
119 |
|
120 |
|
121 |
> > Mentioned management tools, well, get into specifics; pxe network |
122 |
> > installs/imaging? Single tree/cache for N servers? Ability to push |
123 |
> > updates out to a specific box, or set of servers? Integration of |
124 |
> > portage contents db with IDS tools? |
125 |
> |
126 |
> PXE installs is on its way. Being able to share the tree/caches would |
127 |
> definitely be of benefit. I already discussed updates. I hadn't even |
128 |
> considered the IDS integration, but that is an awesome idea. How about |
129 |
> configuration file management? |
130 |
|
131 |
Configuration file management, as long as it's centralized, can be |
132 |
slightly bastardized as pkgs for pushing/updating. If that's the |
133 |
case, it should be possible to avoid reinventing the wheel for |
134 |
handling it- hence the IDS comment. Verification of config's prior to |
135 |
stomping them on an upgrade. |
136 |
|
137 |
> Asset management? Inventory database? |
138 |
No good answer on that one, since it's outside the ken of what my area |
139 |
of interest (portage) :) |
140 |
Offhand, I'd expect whatever method is used to push commands down via |
141 |
the domain class, probably can be extended to add these additional |
142 |
knobs. It really depends on what you're trying to query though, |
143 |
cpuinfo/df, or license management... |
144 |
|
145 |
|
146 |
> > > Portage really has nothing to do with deployment or management. In |
147 |
> > > fact, the only thing it really does is package management, which is |
148 |
> > > probably why it is called a package management tool, and not an |
149 |
> > > enterprise resource manager. |
150 |
> > |
151 |
> > Any enterprise resource manager is going to have to fool with pkgs at |
152 |
> > some point- that's my line of interest in this. |
153 |
> |
154 |
> Correct. I think my meaning was that we need to look at things |
155 |
> *besides* package management. You guys seem to already have a good idea |
156 |
> of the things we need and I've seen progress towards making portage more |
157 |
> enterprise-friendly with some of the features planned for the future. |
158 |
> |
159 |
> The main thing we need is a powerful portage API that allows complete |
160 |
> control of portage without using "emerge" at the command line. |
161 |
|
162 |
Heh, what, current api isn't usable? :) |
163 |
Yeah, api is an area needing improvement. |
164 |
|
165 |
|
166 |
> Some form of GUI (and console) tools capable of controlling every aspect |
167 |
> of any given set of Gentoo servers within an enterprise, from birth |
168 |
> until death. |
169 |
Oh... just that. 'k. :) |
170 |
|
171 |
re: the remote assist/control of a box, I'd wonder what could be |
172 |
handled via ldap (auth) and use flag... |
173 |
~harring |