1 |
On Fri, Aug 06, 2004 at 03:00:31PM -0400, Chris Gianelloni wrote: |
2 |
> On Fri, 2004-08-06 at 14:06, Joshua J. Berry wrote: |
3 |
> > - Automated setup and install (a la Solaris' Jumpstart). This involves several |
4 |
> > aspects, such as the creation of a custom profile, precompiling binaries, |
5 |
> > automatic partitioning/formatting, automatic configuration, tying into |
6 |
> > Catalyst to create an appropriate boot CD to run the install, ... |
7 |
> |
8 |
> In most cases, a profile is not needed. The profile only specifies the |
9 |
> "system" portion and default virtuals. While I can see how some would |
10 |
> want it, I don't think it would be a requirement. |
11 |
|
12 |
No, a profile a la Gentoo's Portage profile probably isn't ... I just used the |
13 |
term "profile" to mean a specific set of installed packages and configuration |
14 |
options (e.g. have a "mailserver" profile, a "webserver" profile and perhaps a |
15 |
"workstation" profile). |
16 |
|
17 |
You could certainly use Portage profiles for that purpose though, and I think it |
18 |
might be a good place to start, at least until requirements dictate we find |
19 |
something better. |
20 |
|
21 |
> The pre-compiled |
22 |
> binaries are a must. I could see this working in many ways, all of |
23 |
> which would need to be discussed. A proper "rollout" tool would not |
24 |
> require a CD, so there would be no need to involve catalyst for such a |
25 |
> task, though there's no reason to not allow it. I would instead see |
26 |
> catalyst taking the role of creating the binaries. |
27 |
|
28 |
I guess I don't quite understand what Catalyst's purpose is then. Is it not to |
29 |
create boot CDs for installation? |
30 |
|
31 |
> Installing new |
32 |
> machines would be carried out using industry standard methods, such as |
33 |
> PXE to boot an image that downloads from TFTP and loads up a NFS root |
34 |
> with an installer image. |
35 |
|
36 |
I like this idea better than a boot CD, but never having tried it myself, I |
37 |
don't know how it would be setup or how practical it would be for users that are |
38 |
just interested in setting up, say, a few machines at their small business in |
39 |
this way. |
40 |
|
41 |
... |
42 |
|
43 |
> > - Allow users to create and maintain a custom Portage tree (derived from our own |
44 |
> > base tree) which they can use to administer their other machines. |
45 |
> |
46 |
> This is too simple. We already provide everything a user would want to |
47 |
> be able to do this. Perhaps I am missing something. Could you |
48 |
> enlighten us a bit more on this? |
49 |
|
50 |
Some admins may wish to perform their own QA on the Portage tree before pushing |
51 |
things out to their userbase, or perhaps create custom ebuilds for proprietary |
52 |
software they have purchased and want to run on Gentoo. |
53 |
|
54 |
Some people have also requested the ability to deliver a stripped-down version |
55 |
of the tree (e.g. removing server-ish ebuilds from trees that will only be used |
56 |
with workstations), so that it's harder for those of their end users who have |
57 |
root to do something silly like install a DHCP server on a workstation. |
58 |
|
59 |
Also, stripped down Portage trees are easier for them to distribute internally, |
60 |
especially if the distribution is happening over a WAN as it might in larger |
61 |
companies. |
62 |
|
63 |
> |
64 |
> > - Probably something else I forgot. ;) |
65 |
> |
66 |
> A stable portage tree for each release would be a requirement. |
67 |
|
68 |
By "stable", are you talking about the snapshots a la Gentoo Enterprise? (i.e. |
69 |
Take a stable snapshot every N months and release it.) I think we would |
70 |
probably be OK without this, at least for those admins who choose to do their |
71 |
own QA. After all, staying fairly consistently up-to-date is another advantage |
72 |
to Gentoo which some may wish to take advantage of. |
73 |
|
74 |
> |
75 |
> > While most of these are possible with shell scripts and the like, there are no |
76 |
> > official Gentoo tools to do this. I think it would be great for Gentoo to |
77 |
> > create some, because I think this is one area in which we can really shine. |
78 |
> |
79 |
> I agree. At the same time, I realize that Gentoo is still very young, |
80 |
> and we have a long way to go and a lot of growing up to do. The main |
81 |
> thing I notice about a lot of people is they want to take Gentoo and to |
82 |
> turn it into some huge enterprise solution, but they don't want to |
83 |
> invest the money nor manpower to do so. |
84 |
|
85 |
I have no money, but I do have time (at least during the summer), and I have a |
86 |
certain amount of personal interest. (I'd like my school to start using Gentoo, |
87 |
and I think having a tool like this might convince them.) |
88 |
|
89 |
If enough people are willing to work on this, we should start (yet) a(nother) |
90 |
project. |
91 |
|
92 |
> Red Hat has capital. They have |
93 |
> employees. Every single one of us are volunteers, and honestly, until |
94 |
> that changes, there is no way we will ever be able to meet the needs of |
95 |
> the enterprise, simply because corporate customers will want things from |
96 |
> us that are not fun nor interesting, which means they will not be things |
97 |
> we will want to do. |
98 |
|
99 |
This means--and this has been brought up repeatedly before--there needs to be |
100 |
some sort of for-profit company, separate from the non-profit, that has at least |
101 |
a few full-time Gentoo devs on its staff. Or so it seems to me. |
102 |
|
103 |
There may even be (and probably are) a set of people out there offering Gentoo |
104 |
to their clients as part of their business. Perhaps we should start keeping a |
105 |
list of these people. |
106 |
|
107 |
> |
108 |
> I believe that to achieve these goals, we have to start by taking baby |
109 |
> steps. Perhaps we should bring up some things at the next manager's |
110 |
> meeting? To be honest, it looks like the first steps are going to be |
111 |
> the easiest, and at the same time the hardest. We have to decide where |
112 |
> we want to go and lay out a plan. The hardest part is we have to stick |
113 |
> to that plan and not falter. |
114 |
|
115 |
The first step is always to figure out where you want to go ... I think we're |
116 |
doing that now. Then we just need to break the problem down into small pieces. |
117 |
|
118 |
If anyone is interested, I can perhaps draft up some thoughts/the beginnings of |
119 |
a raodmap for getting this done. |
120 |
|
121 |
> > So ... what are your thoughts on this? |
122 |
> |
123 |
> We need to move on it, and not talk about it, then let the topic die off |
124 |
> and forget about it as has been going on for months now. |
125 |
|
126 |
OK. Let's go. :) |
127 |
|
128 |
> |
129 |
> > On a related note, avenj did mention the Installer project to me, and gave me a |
130 |
> > link to their CVS, but it hasn't been touched in a few months. Anyone know what |
131 |
> > their status is, and what specifically they're trying to accomplish? |
132 |
> |
133 |
> I believe their charter was to create a nice installer that could be |
134 |
> used to install Gentoo in various fashion, using GRP as a base and |
135 |
> allowing for rapid deployment of servers and workstations based on |
136 |
> pre-defined criteria. |
137 |
|
138 |
That sounds like it's the first (big) step then. Let's get an installer |
139 |
working. |
140 |
|
141 |
-- |
142 |
|
143 |
----------------------------------------- |
144 |
Joshua J. Berry |
145 |
|
146 |
"I haven't lost my mind -- it's backed up on tape somewhere." |
147 |
-- /usr/games/fortune |
148 |
|
149 |
NOTE: Please do not submit this email address to any mailing |
150 |
lists or websites without prior permission. Thank you. |