Tuesday April 11th, 2023 NCLUG Meeting

[Bob Proulx]

j dewitt wrote:
> What: Tuesday April 11th, 2023 NCLUG Meeting

It was so nice of weather that I road my bicycle to the meeting for
the first time this year.  Yay!  The usual hobknobbing at the start of
the meeting occurred.  Sy's and Alex's graphics extraction project was
a hot topic of that time.

There was a discussion of how to run RHEL/CentOS software on an Ubuntu
system.  How do you do this?  The idea was to run the odd-one out
software in a chroot.  Which was being called a jail but a jail really
implies more namespacing than just the chroot which namespaces the
file system only.

A little discussion about cameras and manufacturing overseas.  How do
you prevent piracy?  Split the design into parts.  Have the different
parts manufactured by different vendors and then assemble the parts
along with the firmware at the last step.

Robert reported his mountain was stolen from his back yard from a
fenced in area!  Plus a dog.  Dog failed to deter.  It was suggested
that thieves apparently are working areas with an enclosed truck,
grabbing as many bikes as possible, and then taking them either out of
state or across state.

Aaron is always doing fun stuff and has a dual ISP network
configuration going now.  That's a tricky thing!  So of course I
prodded him to say more.  On goes the projector and we get a
demonstration of the configuration.

Linux Policy Routing.  Two WAN connections.  Comcast along with Allo
fiber.  Bought a "multi-gig" dual NIC network card.  Multi-gig is the
new-ish standard of 2.5 Gig or 5 Gig rated protocols that is now
becoming available.  Has both public IP addresses connected to the
public DNS name.  Review one of the problems.  The outbound must come
back from the IP address that makes sense.  Can't exit a default route
out on Allo for Comcast addresses, and not the reverse either.  Enter
Linux Policy Routing.  Both modems being in bridge mode so the default
routes are the ISP routers.  A little diversion down the Comcast
support rants which we have all experienced ourselves too.

Enter HAProxy. It is running on the same system with the dual NICs.
Usually HAProxy would be used for one network in and multiple networks
on the LAN side.  In this case it has multiple WAN networks.  But
HAProxy has some advantages of being in the middle either way.  And
Aaron has multiple LAN backends too.

    https://www.haproxy.org/

To get the network packets that came in back out to the correct WAN
port some magic is occurring.  I only partially followed this but
there are multiple routing tables.  There was some glue that is
extracting the default route from the DHCP and inserting that into
each particular individual route table.

Enter Linux Network Bonding.  That's a technique where Linux
networking will bond or "trunk" two network devices together.  There
are various bandwidth sharing and fallover modes.

Honestly I think there is some magic happening in there somewhere.
But we had the demonstration that showed the redundant link operating!
Can't argue with the results!

Stephen took over and talked a little bit about his development
environment.  Demonstrated "gitk" which is a graphical browsing
interface to git.  Which works perfectly if you have a local clone of
the git repository.  Which your company might not want you to be doing
and might instead want you to be working across the planet in a remote
data center on a remote VM in which case it does not work very speedy
at all.  Enter Visual Studio Code.  It has capability to run local and
then connect to the remote files.  This can work very much like gitk
but over a remote explorer.

Additionally there is tig (git spelled backwards) which is a curses
based git repository browser.  And tig can run inside vscode.  That
combination makes working on a remote system over the WAN half way
around the planet workable without a lot of latency.  (Bob: It's funny
that we have come back to the beginning.  In 1980 there was huge
serial port use.  In 1990 everything became graphical.  In 2020
everything became remote and remote graphics is frustratingly slow so
there is a return to serial interfaces such as curses in order to have
acceptable interactive performance.)  Working with remote mode in
vscode makes working remotely acceptable again.

Kyle mentioned sshfs which can also work well when working remotely.
For example I can play a video over sshfs no problem.  But sshfs still
has the latency round trip when stat(2) is called to get the timestamp
of a file.  Many things do a lot of stat() calls and sshfs will be
latency bottlenecked in the presence of a lot of stat()s.  sshfs works
through bastion hosts excellently though because ssh does.  Mosh on
the other hand does not work through bastion hosts without a custom
UDP proxy solution.  Mosh is another tool for high latency WAN
situations.  Works great for interactive stuff.  But does not work at
all for the rest of the things we need remotely.

Sy has an old iMac that is now long out of Apple support and has been
trying to get it to boot a Linux kernel.  Then at least the machine
would have a second life.  This machine has a 64-bit CPU but a 32-bit
bootloader.  Endlessly problematic.  Only supports 32-bit EFI booting.
But has a 64-bit CPU.  Obviously booting a 32-bit kernel has problems
with newer operating systems has problems because for example Ubuntu
no longer supports 32-bit systems.  Was able to get Debian's 32-bit
i386 system booted.  And that was able to drive the AMD GPU okay.
After much hassle Sy was able to bodge the 32-bit EFI to boot a 64-bit
Linux kernel.  Woot!  But the 64-bit system is not currently able to
drive the AMD GPU so no graphics at this moment.  That's the current
snag.  It's booting a 64-bit Linux kernel but the AMD GPU is not
working yet for graphics.  But the character vt virtual terminal
console works so that is something.  On to figure out the graphics.
If it isn't one thing it is another thing!