1 |
On Thu, 2005-08-04 at 14:37 -0500, Brian D. Harring wrote: |
2 |
> Elaborate on what you explicitly want out of portage please- the |
3 |
> domain concept (aside from being useful design wise) *should* allow |
4 |
> groupping of boxes (groupping of domains really) behind it, so you can |
5 |
> effectively have a set of boxes, pushing changes to each. |
6 |
> |
7 |
> Mind you no code written, but current design is intended to allow |
8 |
> remote chunks to be swapped in/out of portagelib on the fly |
9 |
> (including the actual portage configuration). |
10 |
|
11 |
The only things I could see being needed out of portage itself is the |
12 |
ability to control "emerge" commands remotely, such as forcing an update |
13 |
of apache to $version to resolve a vulnerability. |
14 |
|
15 |
Besides the back-end portage pieces, there would need to be a front-end |
16 |
interface for performing these tasks. |
17 |
|
18 |
> Better angle of discussion rather then "we aren't there yet" is the |
19 |
> specifics of what is needed to *get* there in peoples opinion. |
20 |
|
21 |
Agreed completely. |
22 |
|
23 |
Some things I could see as needed: |
24 |
|
25 |
1. applying updates on any file that is under CONFIG_PROTECT where the |
26 |
md5/file-size matches that in /var/db for the file without user |
27 |
interaction |
28 |
2. automatic removal of files under CONFIG_PROTECT where the |
29 |
md5/file-size matches that in /var/db during unmerge |
30 |
|
31 |
> It's not an overnight thing, glep19 (stable portage tree) addresses a |
32 |
> chunk of concerns when/if it's implemented, but I'm a bit more |
33 |
> interested in the the other tools people desire alongside. |
34 |
|
35 |
As am I. The Installer is one such project. We do not have any project |
36 |
that I am aware of that is designed to resolve the problem of remotely |
37 |
managing a server. There is nothing for pushing config changes/package |
38 |
updates/new packages. There would need to be some interface for doing |
39 |
these things. Stop by any trade show, such as LWE, and you'll see guys |
40 |
pushing their wares on remotely managing Linux. We should provide |
41 |
something like this ourselves. |
42 |
|
43 |
eg. If I want to change the subnet mask or default router on 50 machines |
44 |
on my network, I should be able to do so via a simple interface and have |
45 |
the work done automatically. |
46 |
|
47 |
> Re: a drop-in solution, considering that gentoo is effectively all |
48 |
> over the map (seriously, look at the tree), define the profile for the |
49 |
> drop-in; drop-in ftp, drop-in web server, drop-in mosix node... etc. |
50 |
|
51 |
I meant a drop-in management solution, not a specific set of server |
52 |
profiles, though those could be created with the Installer. In fact, I |
53 |
see the Installer as one of the first pieces of the framework necessary |
54 |
for deployment and management of a large number of servers. Once the |
55 |
netfe interface is completed with the Installer, you will be able to PXE |
56 |
boot your server and have it load a specific installer profile, and it |
57 |
will install Gentoo to those specifications. Beyond that, we lose |
58 |
control of the server and must manually perform all other actions. |
59 |
|
60 |
> Specifics... |
61 |
> |
62 |
> Hell, I have yet to see what I would define as a proper solution for |
63 |
> config manamagent for N gentoo boxes. NFS solution possibly, but that |
64 |
> seems a bit hackish to me. |
65 |
|
66 |
There isn't a proper solution yet. Honestly, something like a |
67 |
repository holding configuration information with revision control would |
68 |
probably be best, so you can revert changes. There are quite a few |
69 |
systems like this out for Red Hat and others, but nothing that is |
70 |
Gentoo-specific, or even Gentoo-capable, as far as I know. We should |
71 |
beat people to the punch and design one ourselves. |
72 |
|
73 |
The main things we need to provide are: |
74 |
|
75 |
Provisioning - building a server from bare metal to some pre-determined |
76 |
state |
77 |
Management - being able to make changes to existing servers without |
78 |
manually logging into each to make the changes |
79 |
Updates - this somewhat goes with management, but a facility for |
80 |
disseminating patches or updated packages to servers |
81 |
|
82 |
> Moot point frankly, considering we're all volunteers; someone |
83 |
> *could* get off their butts and start up an attempt to provide hand |
84 |
> holding (effectively what you're coloring the management arg as) |
85 |
> services, but even if they did, the followup arg would be that you |
86 |
> can't yet trust this new support company, because they're new. |
87 |
> Etc. |
88 |
|
89 |
Not entirely moot, as a company could be formed in cooperation with the |
90 |
Foundation, as I stated earlier in the thread. This symbiotic |
91 |
relationship would give the new company a bit more credit, as it will be |
92 |
supported by the Foundation. This could be a Foundation-owned company, |
93 |
or a completely separate entity. Anyway, this isn't so much my point, |
94 |
as many people *are* willing to forgo having a human voice on the end of |
95 |
a phone. |
96 |
|
97 |
> Basically, we don't have control over that portion, so... what |
98 |
> can be mangled that we *do* have control over, and has an effect? |
99 |
|
100 |
Our tools. Currently, we have very few "Gentoo tools" used for managing |
101 |
a system. We would need to define the requirements for these tools, and |
102 |
then work on ways of getting them built. It's like I said, I think the |
103 |
primary weakness in Gentoo's enterprise adoption is the need for each |
104 |
company to reinvent the wheel on their own deployment. If we had a set |
105 |
of extensible tools for managing Gentoo machines, then companies would |
106 |
have a framework for building upon to meet their own needs. Why does |
107 |
everyone, for example, need to invent their own way of adding users to |
108 |
their network? Why can't we provide some method and allow them to |
109 |
customize it and extend it? |
110 |
|
111 |
> Mentioned management tools, well, get into specifics; pxe network |
112 |
> installs/imaging? Single tree/cache for N servers? Ability to push |
113 |
> updates out to a specific box, or set of servers? Integration of |
114 |
> portage contents db with IDS tools? |
115 |
|
116 |
PXE installs is on its way. Being able to share the tree/caches would |
117 |
definitely be of benefit. I already discussed updates. I hadn't even |
118 |
considered the IDS integration, but that is an awesome idea. How about |
119 |
configuration file management? Asset management? Inventory database? |
120 |
How about a "remote assistance" feature? Since Gentoo is not only used |
121 |
on servers, but could also be deployed on the workstation, we should |
122 |
also provide tools for managing and supporting them, too. What about |
123 |
some form of policy enforcement? Things like turning on Remote Desktop |
124 |
Sharing in KDE/Gnome, so IT staff can assist users with issues. |
125 |
|
126 |
> > Portage really has nothing to do with deployment or management. In |
127 |
> > fact, the only thing it really does is package management, which is |
128 |
> > probably why it is called a package management tool, and not an |
129 |
> > enterprise resource manager. |
130 |
> |
131 |
> Any enterprise resource manager is going to have to fool with pkgs at |
132 |
> some point- that's my line of interest in this. |
133 |
|
134 |
Correct. I think my meaning was that we need to look at things |
135 |
*besides* package management. You guys seem to already have a good idea |
136 |
of the things we need and I've seen progress towards making portage more |
137 |
enterprise-friendly with some of the features planned for the future. |
138 |
|
139 |
The main thing we need is a powerful portage API that allows complete |
140 |
control of portage without using "emerge" at the command line. |
141 |
|
142 |
> > Gentoo is currently unmaintainable at this scale without a significant |
143 |
> > investment in infrastructure and development to make the system |
144 |
> > manageable. Think of it this way, if I can pay 4 developers to work on |
145 |
> > this project for 6 months, and each developer makes $50,000 a year, or I |
146 |
> > can pay Novell $100,000 and have the system in place in 2 weeks, which |
147 |
> > do you think I would do? This is the exact reason why Gentoo is not |
148 |
> > used in the enterprise more. There is simply too high a barrier of |
149 |
> > entry into making a usable and manageable Gentoo deployment. |
150 |
|
151 |
> Or, you find a collection of trained coder monkeys who are oddballs |
152 |
> who might have an interest in implementing this stuff on their own |
153 |
> time, and try to nudge them in the correct direction; no, this isn't a |
154 |
> solution, but again, having an ent. solution (going by your statement) |
155 |
> isn't going to be funded by anyone. |
156 |
|
157 |
I meant this to mean $company pays developers to implement this for |
158 |
themselves, whereas Novell/Red Hat have already paid for most of this |
159 |
work on their own distributions. The idea being that we are much more |
160 |
likely to get enterprise adoption if we have some tools in place, even |
161 |
if rudimentary in comparison, where currently we have nothing. |
162 |
|
163 |
> Ok, fine. So it goes. |
164 |
> |
165 |
> Meanwhile, reiterating my point, I'd rather see a discussion of what |
166 |
> people *want* in the way of tools, then "we aren't there yet". |
167 |
> Generally known that you have to roll your own somewhat for tools, |
168 |
> well, would rather know what people want then see then another round |
169 |
> of kicking the dead horse. |
170 |
|
171 |
Quite simply: |
172 |
|
173 |
Some form of GUI (and console) tools capable of controlling every aspect |
174 |
of any given set of Gentoo servers within an enterprise, from birth |
175 |
until death. |
176 |
|
177 |
-- |
178 |
Chris Gianelloni |
179 |
Release Engineering - Strategic Lead/QA Manager |
180 |
Games - Developer |
181 |
Gentoo Linux |