>>> I have a network of very nearly identical Dell XPS 13 laptops that I
>>> manage with a script.  The master pushes the contents of its
>>> filesystem to the others so I only have to manage one system.  It's
>>> worked really well over several years.  I just got a new Dell XPS 13
>>> to serve as the master and there have been some changes that were
>>> difficult to integrate with the network (high-res screen, /dev/sda
>>> replaced with /dev/nvme0n0) but those problems are fixed thanks to you
>>> guys.
>>>
>>> Now I'm running into "trap invalid opcode" errors on the older
>>> systems.  Can I disable some of the newer CPU instruction sets on the
>>> master laptop when compiling to hopefully generate binaries that will
>>> work on the older systems?  If so, could anyone point me in the right
>>> direction?  I don't want to use distcc please.
>>>
>>> CHOST="x86_64-pc-linux-gnu"
>>> CFLAGS="-march=native -O2 -pipe -fomit-frame-pointer"
>>
>>
>> Switching to -mtune=native seems to work.  Time for an emerge -e world.
>
> Also time for ansible. Why you managing a fleet of machines with a
> script that won't actually differentiate properly between machines? It
> will sorts mostly do it right, except when you forget something.


Well I designed it around the principle that I would have the luxury
of using sufficiently identical hardware across each system so that it
wouldn't need to differentiate.  It's simple, it's one file.  I just
execute the file with certain parameters based on whether I'm cloning
the running system to a USB stick, cloning the running USB stick to
its host system, pushing the master system to another system, or
updating the running system based on the last push to it.  Worked
great until the latest iteration of XPS 13.  Even now the only
hardware differentiation it needs to make is /dev/sda or /dev/nvme0n1.
DisplaySize in xorg.conf and -mtune=native in make.conf are sufficient
to handle different screen resolutions and CPUs.


> This is exactly the use-case ansible was designed for: declarative,
> idempotent, predictable management of a fleet of machines that may or
> may not be around when you feel like updating something (so it catches
> up later), and needs only sshd and python to do it's magic :-)


ansible does sound pretty cool.  I'll check it out if I outgrow my
script but as long as I can keep using Dell XPS 13 laptops I don't
think it will have any trouble scaling.

- Grant

Reply via email to