| 1 |
On 2/3/06, Ian P. Christian <pookey@×××××××××.uk> wrote: |
| 2 |
> I've currently got about 30 gentoo servers that I need to maintain, and this |
| 3 |
> number will increase significnatly shortly. |
| 4 |
> |
| 5 |
> I would like to move to an automated way of keeping these servers up to date. |
| 6 |
> |
| 7 |
> Firstly, I would like to use binary packages. I initially thought about having |
| 8 |
> a repository pre architecture, and standardising on cflags and use flags - |
| 9 |
> however this isn't feasable if you need to alter the use flags on just one |
| 10 |
> server - installing from the binary package will result in the wrong package |
| 11 |
> being installed. |
| 12 |
> |
| 13 |
> Ideally, there would be a way to make emerge make a hash of the use flags and |
| 14 |
> cflags it's using to compile a package, and then look |
| 15 |
> for /repository/package-<hash> as the binary package - however I'm quite sure |
| 16 |
> this kind of feature doesnt' exist. Perhaps there is an alternative? |
| 17 |
> |
| 18 |
> Also, if I upgrade 30 servers, I certainly don't want to log into each one to |
| 19 |
> do an etc-update on 101 files which I've not ever modified in the first |
| 20 |
> place. |
| 21 |
> |
| 22 |
> How do you manage your servers effectivly? |
| 23 |
|
| 24 |
I've written and maintained and used since 2 years custom made |
| 25 |
software for this process. It;s called portki available on |
| 26 |
dev.gentoo.org/~radek/portki/ - unfortunately there is no good |
| 27 |
documentation to it. We can arrange an irc or skype session as I'm a |
| 28 |
quite busy person if You want me to describe it to You. |
| 29 |
|
| 30 |
In short: |
| 31 |
* designed to run in fully automated way |
| 32 |
* uses master/slave portage replication mode with separate _own_ |
| 33 |
master portage repo |
| 34 |
* additional own repos for home made software |
| 35 |
* allows different upgrade cycles per machine (weekly/monthly/yearly, glsa only) |
| 36 |
* allows automatic cfg upgrade _if_ file was not touched by human. |
| 37 |
* does all necessary cleaning |
| 38 |
* extensive logging |
| 39 |
* does revdep-rebuild and other necessary portage tricks |
| 40 |
* allows central configuration (useflags, make.conf etc.) |
| 41 |
* it used binpkg in early version but I discarded this idea because of: |
| 42 |
.. problems generated even on compatibile hosts |
| 43 |
.. necessity to have all the same cfg (which is often not the case) |
| 44 |
.. small gain (on todays servers compilation is fast) |
| 45 |
.. much harder individual changes to the machines |
| 46 |
* its just an integration work (mostly bash and python) around |
| 47 |
standard gentoo tools, although its in highly automated state. |
| 48 |
* easy to extend |
| 49 |
* many bugs :) and still in -home-made-specialized software. |
| 50 |
|
| 51 |
|
| 52 |
-- |
| 53 |
radoslaw. |
| 54 |
|
| 55 |
-- |
| 56 |
gentoo-server@g.o mailing list |
Archives