Tuesday February 8th, 2022 NCLUG Meeting

Sean Reifschneider jafo00 at gmail.com
Wed Feb 9 15:51:24 MST 2022


First, Re: "htop", give btop a try.  It's pretty slick!  It's not only
pretty, it's pretty useful.

https://github.com/aristocratos/btop

On the topic of Salt vs Ansible, baby steps in Ansible are definitely
possible by using limited playbooks and tags.  I won't go into a full
example right here, as it can get lengthy, but in Ansible you have, at the
most basic:

- Tasks: The individual units of work, for example: Create a user, add this
line to a file, install this package, create this config file using this
template...
- Roles: A collection of tasks into a logical work unit, for example:
Install and configure Mariadb, install my web app and all the packages,
apache configs, configurations, cron jobs ,etc...
- Playbooks: Specifying what hosts get what roles or tasks applied to them.

It is common in Ansible to have a "site.yml" playbook that specifies all
your hosts and roles, but it's also very doable to have some playbooks that
do some subset of roles.  For example, I'm currently working on setting up
a Mariadb Galera cluster, and so I have a playbook like the following:

    - name: MariaDB Galera Cluster
      hosts: mail_db
      tasks:
        - name: Include MariaDB Role
          include_role:
            name: mariadb-galera

While I'm working on this role, I use this playbook, after I have run my
full site playbook against the host.

Additionally, you can use "tags" on tasks so that you can further refine
what is run.  For instance, I will often tag tasks with:

- The name of the role they are in.
- Their general class of thing they do (packages, configs, firewall)

So then I can do things like run the whole site playbook, but only have it
run that specific role, or install all the packages needed by all the
roles, or update configs on all roles.

I haven't looked at Salt in probably 5-6 years, but it was very close to
being the system I chose.  I selected Ansible for a variety of reasons,
including that Salt had some fairly serious recent (at the time) security
issues, and that I personally knew some of the Ansible developers.  I'm not
saying Salt isn't a good choice, just wanted to give some alternatives for
taking baby steps.  I think Salt is a pretty good choice, having not used
it.

Sean

On Tue, Feb 8, 2022 at 7:46 PM Bob Proulx <bob at proulx.com> wrote:

> j dewitt wrote:
> > What: Tuesday February 8th, 2022 NCLUG Meeting
>
> We were having a good time chatting over the top of laptops.  This
> week pretty much everyone brought a laptop.  It was a good social fun
> chat geeking out about stuff.
>
> There was eventually a lull.  We decided we should get more organized
> and have something that might be confused with a meeting.
>
> Bob started with a short rant about in Windows Hell this last week.
> Working trying to get a classroom setup of Garmin G1000 aircraft
> avionics simulators for CAP training sessions.
>
> Aaron Learning about Salt.  Salt is a python based infrastructure
> management system.  Aaron's group uses Salt for managing some 1500
> systems with everything that a system might need.  Updates passwords.
> Updates packaging.  When using an infrastructure management system one
> doesn't manage a single machine but a networked collection of systems.
>
>     https://docs.saltproject.io/en/getstarted/system/python.html
>
> Says Salt is better than Ansible for doing incremental baby steps at
> admin.  Such as changing one password across all systems.  Or updating
> GRUB timeouts across the set.  Or whatever!
>
> Stephen guesses he is Stephen but has been mostly working on hardware
> and Creator Hub stuff this last week.
>
> Phil is trying to pull drawings into an electromagnetic simulator.  If
> you have transmission lines it will compute the impedance.
>
> James says he has been doing a terrible job of re-installing his
> previous install of his new well equipped laptop.  Mostly with
> problems trying to use the corporate closed source nVidia driver.
> Mainly has complaints about controlling the brightness rather than
> performance.  (All eyes and fingers point toward Stephen!  Who at one
> time worked on that driver.)  At which point I jumped in because I had
> exactly the same problem on my Thinkpad X220.  And even better I have
> documented what I did to get those buttons working!
>
>
> https://www.proulx.com/~bob/doc/thinkpad-x220-laptop-keys/thinkpad-x220-laptop-keys.html
>
> I am using the Radeon driver but since it is in the Linux kernel this
> seems like it should work on an nVidea driver too.
>
> Meanwhile...  He has mostly been working on his work machine.  And
> then he related that he was happy that he missed out on the MS Surface
> Pro purchases.  Various problems.  He was glad he dodged the problems
> his co-workers have experienced.
>
> Brian has a Surface Go and there was conversation about it but at that
> moment I was getting a direct link from Alex for a LAN riot server he
> was running for a shared video session.
>
> Brian then talked about the main thing he came prepared to talk about
> tonight!  Brian says, "I intend to talk briefly about open source watches.
> One of the links is rather long, so I thought I'd email it to you for your
> notes..."  Excellent! :-)
>
>     Numerous links to open source watches:
>
> https://www.cnx-software.com/2022/02/08/mutantw-v1-an-open-source-esp32-smartwatch-designed-with-autodesk-fusion-360-and-eagle/
>
>     PineTime Watch: https://www.pine64.org/
>
> Those are a summary of "good" open source watches.  Brian calls out
> "Paul's 3D Things Open-Smartwatch".  It's a form of Arduino and has
> built in WiFi.  Really liked the resources for open source watches on
> this page.
>
>     https://shop.espruino.com/banglejs2
>
> Bangle.js 2.  A watch that runs Node.js.  Cautioned that the v2 is
> replacing the v1 and much more desirable than the v1.  I'll quote from
> Brian, "If I can get it to work then this is going to be great."  Now
> that is quite the endorsement! :-) Some assembly required at this
> point.  But it does look like it has great potential.
>
> Eric was having a problem with input lag for games running on Steam on
> his Pop! OS system.  Which was actually one of the reasons he showed
> up tonight.  He was hoping to share the problem and see if group think
> of the people had any solution.  But then at the point of trying to
> reproduce things it was all working just fine.  So just the threat of
> getting the group mind of NCLUG members onto the problem seems to have
> been enough to solve the problem.
>
> Alex suggested various Steam related debugging tips.  Bob suggested
> simple things.  "htop" to see cpu use.  "sudo iotop" to look at
> storage I/O bandwidth.  If bus I/O bandwidth is max'd out then that
> will really cause the machine to bog.  Someone mentioned overheating.
> If the cpu gets too hot then the cpu will throttle and slow to reduce
> overheating.  That will cause the appearance of system freezing.
>
> Alex then gave a demo of the riot server on the LAN.  We just passed a
> 10.* address URL around.  He was the server and I grabbed the display
> for my laptop to show the use across the net.  Since we often struggle
> with having the right display adaptor to hook to the projector.  The
> project is HDMI natively.  Many laptops have that.  Many have Display
> port.  Aaron's machine couldn't display today because he has the
> smaller Mini-DisplayPort and we didn't have an adaptor for it.  (Note
> to self, acrquire a Mini-DP to HDMI (or DP) adaptor.
>
> Brian, Alex, Bob, others then had a discussion about hardware KVM
> switchers.  The problem with 4K monitors is that once you start
> upgrading then everything needs to be upgraded!
>
> And that completed the round table and brought us to 7:30pm.  At which
> point all organization was lost and we had a half dozen separate
> conversations denoting the end of the organized part of the meeting.
> But it may have been the best part of it.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.nclug.org/pipermail/nclug/attachments/20220209/5035d2ea/attachment.htm>


More information about the NCLUG mailing list