| 1 |
>>> I have a network of very nearly identical Dell XPS 13 laptops that I |
| 2 |
>>> manage with a script. The master pushes the contents of its |
| 3 |
>>> filesystem to the others so I only have to manage one system. It's |
| 4 |
>>> worked really well over several years. I just got a new Dell XPS 13 |
| 5 |
>>> to serve as the master and there have been some changes that were |
| 6 |
>>> difficult to integrate with the network (high-res screen, /dev/sda |
| 7 |
>>> replaced with /dev/nvme0n0) but those problems are fixed thanks to you |
| 8 |
>>> guys. |
| 9 |
>>> |
| 10 |
>>> Now I'm running into "trap invalid opcode" errors on the older |
| 11 |
>>> systems. Can I disable some of the newer CPU instruction sets on the |
| 12 |
>>> master laptop when compiling to hopefully generate binaries that will |
| 13 |
>>> work on the older systems? If so, could anyone point me in the right |
| 14 |
>>> direction? I don't want to use distcc please. |
| 15 |
>>> |
| 16 |
>>> CHOST="x86_64-pc-linux-gnu" |
| 17 |
>>> CFLAGS="-march=native -O2 -pipe -fomit-frame-pointer" |
| 18 |
>> |
| 19 |
>> |
| 20 |
>> Switching to -mtune=native seems to work. Time for an emerge -e world. |
| 21 |
> |
| 22 |
> Also time for ansible. Why you managing a fleet of machines with a |
| 23 |
> script that won't actually differentiate properly between machines? It |
| 24 |
> will sorts mostly do it right, except when you forget something. |
| 25 |
|
| 26 |
|
| 27 |
Well I designed it around the principle that I would have the luxury |
| 28 |
of using sufficiently identical hardware across each system so that it |
| 29 |
wouldn't need to differentiate. It's simple, it's one file. I just |
| 30 |
execute the file with certain parameters based on whether I'm cloning |
| 31 |
the running system to a USB stick, cloning the running USB stick to |
| 32 |
its host system, pushing the master system to another system, or |
| 33 |
updating the running system based on the last push to it. Worked |
| 34 |
great until the latest iteration of XPS 13. Even now the only |
| 35 |
hardware differentiation it needs to make is /dev/sda or /dev/nvme0n1. |
| 36 |
DisplaySize in xorg.conf and -mtune=native in make.conf are sufficient |
| 37 |
to handle different screen resolutions and CPUs. |
| 38 |
|
| 39 |
|
| 40 |
> This is exactly the use-case ansible was designed for: declarative, |
| 41 |
> idempotent, predictable management of a fleet of machines that may or |
| 42 |
> may not be around when you feel like updating something (so it catches |
| 43 |
> up later), and needs only sshd and python to do it's magic :-) |
| 44 |
|
| 45 |
|
| 46 |
ansible does sound pretty cool. I'll check it out if I outgrow my |
| 47 |
script but as long as I can keep using Dell XPS 13 laptops I don't |
| 48 |
think it will have any trouble scaling. |
| 49 |
|
| 50 |
- Grant |
Archives