1 |
>>>> Keeping all of the laptops 100% identical as far as hardware is |
2 |
>>>> central to this plan. I know I'm setting myself up for big problems |
3 |
>>>> otherwise. |
4 |
>>>> |
5 |
>>>> I'm hoping I can emerge every package on my laptop that every other |
6 |
>>>> laptop needs. That way I can fix any build problems and update any |
7 |
>>>> config files right on my own system. Then I would push config file |
8 |
>>>> differences to all of the other laptops. Then each laptop could |
9 |
>>>> emerge its own stuff unattended. |
10 |
>>> |
11 |
>>> I see what you desire now - essentially you want to clone your laptop |
12 |
>>> (or big chunks of it) over to your other workstations. |
13 |
>> |
14 |
>> That sounds about right. |
15 |
>> |
16 |
>>> To get a feel for how it works, visit puppet's web site and download |
17 |
>>> some of the test appliances they have there and run them in vm software. |
18 |
>>> Set up a server and a few clients, and start experimenting in that |
19 |
>>> sandbox. You'll quickly get a feel for how it all hangs together (it's |
20 |
>>> hard to describe in text how puppet gets the job done, so much easier to |
21 |
>>> do it for real and watch the results) |
22 |
>> |
23 |
>> Puppet seems like overkill for what I need. I think all I really need |
24 |
>> is something to manage config file differences and user accounts. At |
25 |
>> this point I'm thinking I shouldn't push packages themselves, but |
26 |
>> portage config files and then let each laptop emerge unattended based |
27 |
>> on those portage configs. I'm going to bring this to the 'salt' |
28 |
>> mailing list to see if it might be a good fit. It seems like a much |
29 |
>> lighter weight application. |
30 |
> |
31 |
> Two general points I can add: |
32 |
> |
33 |
> 1. Sharing config files turns out to be really hard. By far the easiest |
34 |
> way is to just share /etc but that is an all or nothing approach, and |
35 |
> you just need one file to be different to break it. Like /etc/hostname |
36 |
> |
37 |
> You *could* create a "share" directory inside /etc and symlink common |
38 |
> files in there, but that gets very tedious quickly. |
39 |
> |
40 |
> Rather go for a centralized repo solution that pushes configs out, you |
41 |
> must just find the one that's right for you. |
42 |
|
43 |
Does using puppet or salt to push configs from my laptop qualify as a |
44 |
centralized repo solution? |
45 |
|
46 |
> 2. Binary packages are almost perfect for your needs IMHO, running |
47 |
> emerge gets very tedious quickly, and your spec is that all workstations |
48 |
> have the same USE. You'd be amazed how much time you save by doing this: |
49 |
> |
50 |
> emerge -b on your laptop and share your /var/packages |
51 |
> emerge -K on the workstations when your laptop is on the network |
52 |
> |
53 |
> step 2 goes amazingly quickly - eyeball the list to be emerged, they |
54 |
> should all be purple, press enter. About a minute or two per |
55 |
> workstation, as opposed to however many hours the build took. |
56 |
|
57 |
The thing is my laptop goes with me all over the place and is very |
58 |
rarely on the same network as the bulk of the laptop clients. Most of |
59 |
the time I'm on a tethered and metered cell phone connection |
60 |
somewhere. Build time itself really isn't a big deal. I can have the |
61 |
clients update overnight. Whether the clients emerge or emerge -K is |
62 |
the same amount of admnistrative work I would think. |
63 |
|
64 |
> 3. (OK, three points). Share your portage tree over the network. No |
65 |
> point in syncing multiple times when you actually just need to do it once. |
66 |
|
67 |
Yep, I figure each physical location should designate one system to |
68 |
host the portage tree and distfiles. |
69 |
|
70 |
- Grant |