1 |
A few things that will help: |
2 |
|
3 |
1) Fork the Portage Tree. Have your build and binary systems working |
4 |
off a private Portage Tree, and only move updates to that tree if you |
5 |
want to update that package. |
6 |
|
7 |
2) emerge -B, should grab only the most recently updated binary that you |
8 |
created even if there is a newer ebuild (though #1 above will prevent |
9 |
the need). |
10 |
|
11 |
3) For each of your classes of servers (web, email, file, whatever) all |
12 |
of the servers should have the same packages installed. I do this by |
13 |
creating a list of all installed ebuilds on each server and diffing vs. |
14 |
a standard. I get an email daily of all diffs. |
15 |
|
16 |
To get the lists of packages installed, I have a cronjob running: |
17 |
|
18 |
/usr/bin/find /var/db/pkg -mindepth 2 -maxdepth 2 | /usr/bin/sed |
19 |
's/\/var\/db\/pkg\///' | sort > /etc/installed_ebuild |
20 |
|
21 |
jbw |
22 |
|
23 |
Sancho2k.net Lists wrote: |
24 |
> Greetz, |
25 |
> |
26 |
> For some time now (going on two years), our company has been using the |
27 |
> binary package server functionality of portage to maintain a build server. |
28 |
> We have 20+ Gentoo servers that have been built using binary packages from |
29 |
> the build server and have had relatively good success maintaining the |
30 |
> systems this way. The goals we were trying to meet under this architecture |
31 |
> were quick deployments and updates by using binary packages, and |
32 |
> consistent software configurations across all systems. |
33 |
> |
34 |
> Recently we've been having doubts as to the maintainability of this setup. |
35 |
> For example, new installations will synchronize with the Portage tree on |
36 |
> the build server (so they both have the same "view" of Portage and the |
37 |
> client can never jump ahead of the build server; that would be a Bad |
38 |
> Thing.) When a new installation takes place, the client will try to pull |
39 |
> the latest stable versions of any package from the build server. This |
40 |
> means that our build server must stay updated constantly, even for |
41 |
> packages that you would not normally be updating religously, such as |
42 |
> libraries that only serve as dependencies for mainstream applications. Due |
43 |
> to the architecture, this seems to be a neccesary evil. It's just hard to |
44 |
> identify the packages that need updated on build server before we see a |
45 |
> client try to install it and not find the latest package. Something we'd |
46 |
> considered was frequent 'emerge -uD' on the server to make sure packages |
47 |
> were updated. Any advice on this? |
48 |
> |
49 |
> The real meat of this posting is the problems we've had recently trying to |
50 |
> update mod_php on some of our web servers. There were a lot of broken |
51 |
> library links because of dependencies that were not being met once the new |
52 |
> binary package was merged into the system, since on the build server it |
53 |
> was built against new versions of dependencies (libraries) that were |
54 |
> present on the client; for example, the build server had mysql-4.1 which |
55 |
> is what mod_php was built against, but the client would only be running |
56 |
> mysql-4.0.x and would therefore have linker errors. We just couldn't catch |
57 |
> this beforehand because portage has no way of knowing to automatically |
58 |
> grab dependencies in this case... |
59 |
> |
60 |
> Is this matter one that we'll have to put more effort into managing? Is |
61 |
> there an easy solution? Maybe something that could be solved by emerging |
62 |
> packages using a deeper dependency tree, and if so, what would be safe for |
63 |
> long term use? |
64 |
> |
65 |
> DS |
66 |
> -- |
67 |
> gentoo-server@g.o mailing list |
68 |
> |
69 |
-- |
70 |
gentoo-server@g.o mailing list |