| 1 |
On 25/09/2013 23:18, Grant wrote: |
| 2 |
> I'm trying to reduce the number of systems I spend time managing. My |
| 3 |
> previous plan was to set up multiseat on a small number of systems. |
| 4 |
> Now I'm wondering if it would be better to use multiple systems with |
| 5 |
> identical hardware and manage them in some sort of an optimized way so |
| 6 |
> that each set of identical hardware behaves as much like a single |
| 7 |
> machine as possible for management. I could use small SoC systems so |
| 8 |
> I don't have to worry about sourcing components later. Is there a |
| 9 |
> good tool or framework for this sort of thing? |
| 10 |
|
| 11 |
|
| 12 |
The solution you pick depends heavily on how many of these identical |
| 13 |
machines you have. |
| 14 |
|
| 15 |
For some small-ish number (gut feel tells me up to around 10 or so), you |
| 16 |
could do what I do for my development vms[2]: |
| 17 |
|
| 18 |
- have 1 decent spec'ed machine as the master and buildhost |
| 19 |
- share /etc/portage/, $PORTDIR, /var/packages and /var/distfiles to all |
| 20 |
clients from some central location (NFS works really well for this) |
| 21 |
- for each package you want to have on a client, emerge it on the |
| 22 |
buildhost with the -b option (create binary packages) |
| 23 |
- emerge stuff on the clients with the -k (or possibly -K) option to use |
| 24 |
binary packages. Everything should show up in purple. If anything is a |
| 25 |
different colour, emerge that package on the buildhost and remerge it on |
| 26 |
the client. |
| 27 |
- for awesome street cred geek-points, install clusterssh and do all |
| 28 |
your clients in parallel[1] |
| 29 |
|
| 30 |
As long as you share important directories to each client, things stay |
| 31 |
consistent. What you essentially achieve is "build once-install many times" |
| 32 |
|
| 33 |
|
| 34 |
However, and I'm likely to get shot down for this here, I think you |
| 35 |
*really* need to reconsider whether Gentoo is even what you should be |
| 36 |
using for this. Put aside emotional attachments to your fav distro and |
| 37 |
take a long hard critical look at your pain-gain ratio. If all you |
| 38 |
really need is standard user-type gui stuffs on each client, what is |
| 39 |
Gentoo really buying you (other than the thrill of watching gcc output |
| 40 |
scroll by over and over and over....) |
| 41 |
|
| 42 |
Use gentoo by all means on your central server to get exactly the |
| 43 |
features you want (Gentoo's strong point), but ona bunch of regular |
| 44 |
clients... I dunno, Ubuntu or Fedora are hard to beat for that... |
| 45 |
|
| 46 |
|
| 47 |
|
| 48 |
[1] if you haven't played with clusterssh do yourself a favour and do |
| 49 |
so. there's something hugely awe-inspiring about typing |
| 50 |
cssh host1 host2 host3 host4 host5 host6 ... |
| 51 |
and watching 6 xterms pop up and all 6 run the same commands that you |
| 52 |
type into the controller window. |
| 53 |
|
| 54 |
[2] this sounds like I should take my own advice... but oddly Gentoo is |
| 55 |
ideal for how I use them. I can upgrade and downgrade almost any app to |
| 56 |
whatever version the developer says is on prod, and enable/disable USE |
| 57 |
to get the same feature set, and do it all in 10 minutes. No binary |
| 58 |
distro lets me do that :-) |
| 59 |
|
| 60 |
-- |
| 61 |
Alan McKinnon |
| 62 |
alan.mckinnon@×××××.com |
Archives