1 |
You could pin packages in the world file (/var/cache/edb/world). |
2 |
|
3 |
<apache-2 |
4 |
<courier-0.42.3 |
5 |
<mysql-4.0.5 |
6 |
|
7 |
etc. etc. Then copy that file to each server, and tada, you've got a standard |
8 |
profile type thing. |
9 |
|
10 |
--Brian Jackson |
11 |
|
12 |
|
13 |
|
14 |
On Sunday 17 August 2003 05:09 pm, Ron O'Hara wrote: |
15 |
> Hi, |
16 |
> |
17 |
> I may have missed something in all the docs, but as far as I can see |
18 |
> there is what should be a fairly simple enhancement to portage that |
19 |
> would help considerably in making Gentoo more practical in larger |
20 |
> deployments. |
21 |
> |
22 |
> I came to gentoo to get the advantages of being able to tailor my |
23 |
> system(s) and still have a simple, consistent upgrade path for all the |
24 |
> component software - portage is great for that. From the developer and |
25 |
> tinkerer point of view it is hard to see improvements in the overall |
26 |
> strategy behind portage. |
27 |
> |
28 |
> BUT - for larger deployments, there are extra needs which are not |
29 |
> currently handled by portage - but should be a snap to implement. |
30 |
> |
31 |
> In large deployments, it is critical to maintain strong change control |
32 |
> and have predictable environments that you can validate application |
33 |
> performance in. Many places use a strategy like: "All production |
34 |
> servers are RedHat 7.1 (or Solaris 2.7, or Windows 2000 +SP5 ... etc)" |
35 |
> |
36 |
> At present I cant see a way to easily do that with gentoo. Eg. Gentoo |
37 |
> 1.4 final is really just a starting point - the minute you do an 'emerge |
38 |
> sync', you have an unknown mix of software. And worse, if you do it an |
39 |
> hour later on a different machine, it could be a slight different mix |
40 |
> again - different from the first box. |
41 |
> It is relatively easy to compare the portage trees and work out what the |
42 |
> differences are, but thats not much help |
43 |
> |
44 |
> If it were possible to 'tag' the portage tree with labels at regular |
45 |
> intervals, and and do an 'emerge sync' with a nominated 'tag' - then you |
46 |
> would have the equivelant of the fixed points that other distributions |
47 |
> have when they cut a release CD. |
48 |
> |
49 |
> |
50 |
> |
51 |
> |
52 |
> As an example scenario for someone building deployment images in a huge |
53 |
> telco. |
54 |
> |
55 |
> After some experimentation, they decide that their basic gentoo system |
56 |
> will be 'gentoo with rsync tag gentoo-1.4-Aug-2003' |
57 |
> |
58 |
> They take the first box and do a standard gentoo install, but at the |
59 |
> 'emerge sync' point in the instructions, they do 'emerge sync |
60 |
> tag=gentoo-1.4-Aug-2003'. |
61 |
> They then complete all the package installations and tweaking that they |
62 |
> want - site specific choices. |
63 |
> |
64 |
> |
65 |
> This is a repeatable process!! - critical for duplicating an environment. |
66 |
> |
67 |
> As each of the systems is deployed - they are in a known state. Even |
68 |
> nicer is that deployed systems can be easily upgraded to some other |
69 |
> 'known environment' by doing an 'emerge sync tag=xxxx' to some later tag. |
70 |
> |
71 |
> For 'hotfixes', deployed boxes probably need the normal 'emerge sync' |
72 |
> which will give them acvcess to the latest and greatest bug fix - but |
73 |
> you would probably not do an 'emerge -u world' on these boxes unless |
74 |
> moving it from one 'tag level' to another. |
75 |
> |
76 |
> Now the only question is - did I miss something and this already exists? |
77 |
> |
78 |
> Regards |
79 |
> Ron O'Hara |
80 |
> |
81 |
> |
82 |
> |
83 |
> |
84 |
> |
85 |
> |
86 |
> |
87 |
> |
88 |
> . |
89 |
> |
90 |
> |
91 |
> -- |
92 |
> gentoo-dev@g.o mailing list |
93 |
|
94 |
-- |
95 |
Home -- http://www.brianandsara.net |
96 |
Gentoo -- http://gentoo.brianandsara.net |
97 |
|
98 |
-- |
99 |
gentoo-dev@g.o mailing list |