| 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 |
Archives