1 |
Hi There, |
2 |
|
3 |
I've been lurking on this list for quite some time. However I've been |
4 |
following the Gentoo Server project and I have to say it's getting more |
5 |
and more interesting. Just a quick introduction. I work at a small / |
6 |
medium webhosting and colocation company in tHe Netherlands, |
7 |
administrating about 50 machine, most of them Cobalt (uhrg) and Redhat. |
8 |
I've been using Gentoo since 1.0pre2 and I've been very satisfied, it |
9 |
has slowly spread through my homenetwork and servers and now that I'm |
10 |
building a new platform to replace the cobalts it's time to deploy it on |
11 |
a bigger scale at work. There are a few things that really need to be |
12 |
resolved before i can do this _properly_. It's crossed the list a few |
13 |
times: |
14 |
|
15 |
1. Easy deployment (as in redhat kickstart) |
16 |
2. Easy package management (security updates) |
17 |
|
18 |
I intentionally left configuration management out of this because my |
19 |
ideas on the above topics are more refined. To start with the second |
20 |
point, my basic theory is that: Package Management should be left to |
21 |
Portage. This sounds logical on 1 computer, but what if you have a |
22 |
network ? Should portage be made network aware ? I think so. Package |
23 |
management on a network should be as easy as: |
24 |
|
25 |
emerge --target="host.domain.tld" emerge apache |
26 |
|
27 |
Anything other is just workaround on the fact that emerge is not network |
28 |
aware. However this does lead to one thing, this setup will not let you |
29 |
interoperate with other systems. This is not a requirement for me as I |
30 |
have existing tools to do just that. I suspect that others will probably |
31 |
think differently on this matter and I would really be interested to |
32 |
hear their view of the requirements of this project. |
33 |
|
34 |
As these are changes in the portage codebase it's mainly left to the |
35 |
portage developers/managers to include this functionality is they think |
36 |
it's the way to go. As a sidenote, if portage does gets network aware |
37 |
there won't be any need for gcc or even portage on your clients, also |
38 |
you get remote tripwire support as the md5sums are on the master host. |
39 |
|
40 |
The deployment part is more interesting as it's easier to start working |
41 |
on, basically this project should bring a host to a known working system |
42 |
based on an configuration file (more about this later). My ideal |
43 |
installation would work like this: |
44 |
|
45 |
1 Machine boots from PXE enabled network card |
46 |
2 It gets its ip from dhcp |
47 |
3 Pxeloader is started with a kernel and a gentoo bootfloppy implementation |
48 |
4 The "boofloppy" loads a cloop image from the server |
49 |
5 The cloop contains the standard livecd tools + python |
50 |
6 A script like glis, reads the master configfile (think kickstartfile) |
51 |
from a server and installs the host. |
52 |
7 Server is rebooted, the machine can now be administed by portage (remotely!) |
53 |
|
54 |
As I'd like to take the above as a starting point for a discussion I |
55 |
posted[1] the details about the configuration file on the projects wiki |
56 |
(hint, the network is mapped as a tree in an xml file, much like the |
57 |
documents on infrastructure.org). As you will see both projects are |
58 |
tightly integrated, and hopefully if people think this is the way to go |
59 |
than we can get started on getting our hands dirty with some code, at |
60 |
least I know I will :-) |
61 |
|
62 |
Be sure to check the wiki so you can see some more implementation |
63 |
details, especially the configuration file. I'm very much looking |
64 |
forward to your comments. |
65 |
|
66 |
Regards, |
67 |
|
68 |
-- Frido Ferdinand (Pyretic on OPN) |
69 |
|
70 |
|
71 |
[1] http://www.subverted.net/wakka/wakka.php?wakka=GoldServerTheory |
72 |
(message and GSPImplementation) |