1 |
On 29/09/2013 20:31, Grant wrote: |
2 |
|
3 |
[snip] |
4 |
|
5 |
>> There's one thing that we haven't touched on, and that's the hardware. |
6 |
>> Are they all identical hardware items, or at least compatible? Kernel |
7 |
>> builds and hardware-sensitive apps like mplayer are the top reasons |
8 |
>> you'd want to centralize things, but those are the very apps that will |
9 |
>> make sure life miserable trying to fins commonality that works in all |
10 |
>> cases. So do keep hardware needs in mind when making purchases. |
11 |
> |
12 |
> Keeping all of the laptops 100% identical as far as hardware is |
13 |
> central to this plan. I know I'm setting myself up for big problems |
14 |
> otherwise. |
15 |
|
16 |
OK |
17 |
|
18 |
|
19 |
> |
20 |
>> Personally, I wouldn't do the building and pushing on my own laptop, |
21 |
>> that turns me inot the central server and updates only happen when I'm |
22 |
>> in the office. I'd use a central build host and my laptop is just |
23 |
>> another client. Not all that important really, the build host is just an |
24 |
>> address from the client's point of view |
25 |
> |
26 |
> I don't think I'm making the connection here. The central server |
27 |
> can't do any unattended building and pushing, correct? So I would |
28 |
> need to be around either way I think. |
29 |
> |
30 |
> I'm hoping I can emerge every package on my laptop that every other |
31 |
> laptop needs. That way I can fix any build problems and update any |
32 |
> config files right on my own system. Then I would push config file |
33 |
> differences to all of the other laptops. Then each laptop could |
34 |
> emerge its own stuff unattended. |
35 |
|
36 |
I see what you desire now - essentially you want to clone your laptop |
37 |
(or big chunks of it) over to your other workstations. |
38 |
|
39 |
No problem, just share your laptop's stuff with the workstations. Either |
40 |
share it directly, or upload your laptops configs and buildpks to a |
41 |
central fileserver where the workstations can access them (it comes down |
42 |
to the same thing really) |
43 |
|
44 |
> |
45 |
>>> OK, I'm thinking over how much variation there would be from laptop to |
46 |
>>> laptop: |
47 |
>>> |
48 |
>>> 1. /etc/runlevels/default/* would vary of course. |
49 |
>>> 2. /etc/conf.d/net would vary for the routers and my laptop which I |
50 |
>>> sometimes use as a router. |
51 |
>>> 3. /etc/hostapd/hostapd.conf under the same conditions as #2. |
52 |
>>> 4. Users and /home would vary but the office workstations could all be |
53 |
>>> identical in this regard. |
54 |
>>> |
55 |
>>> Am I missing anything? I can imagine everything else being totally |
56 |
>>> identical. |
57 |
>>> |
58 |
>>> What could I use to manage these differences? |
59 |
>> |
60 |
>> I'm sure there are numerous files in /etc/ with small niggling |
61 |
>> differences, you will find these as you go along. |
62 |
>> |
63 |
>> In a Linux world, these files actually do not subject themselves to |
64 |
>> centralization very well, they really do need a human with clue to make |
65 |
>> a decision whilst having access to the laptop in question. Every time |
66 |
>> we've brain-stormed this at work, we end up with only two realistic |
67 |
>> options: go to every machine and configure it there directly, or put |
68 |
>> individual per-host configs into puppet and push. It comes down to the |
69 |
>> same thing, the only difference is the location where stuff is stored. |
70 |
> |
71 |
> I'm sure I will need to carefully define those config differences. |
72 |
> Can I set up puppet (or similar) on my laptop and use it to push |
73 |
> config updates to all of the other laptops? That way the package I'm |
74 |
> using to push will be aware of config differences per system and push |
75 |
> everything correctly. You said not to use puppet, but does that apply |
76 |
> in this scenario? |
77 |
|
78 |
My warning about using Puppet on Gentoo should have come with a |
79 |
disclaimer: don't use puppet to make a Gentoo machine to emerge packages |
80 |
from source. |
81 |
|
82 |
You intend to push binary packages always, where the workstation doesn't |
83 |
have a choice in what it gets (you already decided that earlier). That |
84 |
will work well and from your workstation's POV is almost identical to |
85 |
how binary distros work. |
86 |
|
87 |
> |
88 |
>> I'm slowly coming to conclsuion that you are trying to solve a problem |
89 |
>> with Gentoo that binary distros already solved a very long time ago. You |
90 |
>> are forcing yourself to become the sole maintainer of GrantOS and do all |
91 |
>> the heavy lifting of packaging. But, Mint and friends already did all |
92 |
>> that work already and frankly, they are much better at it than you or I. |
93 |
> |
94 |
> Interesting. When I switched from Windows about 10 years ago I had |
95 |
> only a very brief run with Mandrake before I settled on Gentoo so I |
96 |
> don't *really* know what a binary distro is about. How would this |
97 |
> workflow be different on a binary distro? |
98 |
|
99 |
A binary distro would be the same as I described above. How those |
100 |
distros work is quite simple - their packages are archives like |
101 |
quickpkgs with pre- and post- install/uninstall scripts. These script do |
102 |
exactly the same thing as the various phase functions in portage - they |
103 |
define where to move files to, ownerships and permissions of them, and |
104 |
maybe a migration script if needed. |
105 |
|
106 |
The distro's package manager deals with all the details - you just tell |
107 |
it what you want installed and it goes ahead and does it. |
108 |
|
109 |
What the Puppet server does is tell the workstation it needs to install |
110 |
package XYZ. Code on the workstation then runs the package manager to do |
111 |
just that. |
112 |
|
113 |
For config files, there are numerous methods. You can simply drop a new |
114 |
config file to overwrite the old one, or add a new user by having |
115 |
useradd be run, or even change an existing config with sed. Whatever you |
116 |
need to happen within reason, Puppet has a way to do it from a central |
117 |
piece of software. |
118 |
|
119 |
|
120 |
To get a feel for how it works, visit puppet's web site and download |
121 |
some of the test appliances they have there and run them in vm software. |
122 |
Set up a server and a few clients, and start experimenting in that |
123 |
sandbox. You'll quickly get a feel for how it all hangs together (it's |
124 |
hard to describe in text how puppet gets the job done, so much easier to |
125 |
do it for real and watch the results) |
126 |
|
127 |
|
128 |
|
129 |
|
130 |
|
131 |
-- |
132 |
Alan McKinnon |
133 |
alan.mckinnon@×××××.com |