Beta Testing the Engravinator, Part 2

Just a quick update on the Engravinator...I completed printing the parts to build, early this morning, and I was really happy with how they came out:

A lot of that goes down to how Adam (the creator) laid these parts out, for printing.  For those who are unaware, the orientation of a part on the build plate, has a lot to do with how strong it is, under torsion, compression, tension, and shear on the X, Y, and Z axes.  This is especially a b.g deal, due to the additive nature of the plastic 3D printing process.

I also assembled the aluminum extrusion frame of the engraver.  Again, I can't say enough positive about the quality of the kit, and the thoughtfulness of the engineering.  Instead of the usual hammer nuts, or t-nuts, Adam included sprung post-insertion nuts, which can be added after assembly of the extrusions, and also don't slide around, or fall out, when you rotate the item being built.  These cost a bit more, but are really helpful!

Here is the completed frame, which is as far as I have completed, so far:

I'll continue to post here, as I build the kit, and give my thoughts on it.

Beta Testing the Engravinator, Part 1

Anyone who knows me is aware that I'm an extremely (if not completely consistent!) backer of Open Source and Free Software.  That's one of the major reasons why I work for Red Hat.  Given this, I'm a frequent contributor to the Electronic Frontier Foundation (and you should be, too!), to Wikipedia, and I just signed up for a monthly contribution to the Internet Archive.  What all of these things have in common is that they are part of the larger Free Culture movement.  I'm also a passionate maker-of-things, and a heavy user of 3D printing, and occasionally of CNC wood and metal cutting.

All of that is a rather long-winded way of explaining my significant interest in the Engravinator.  The Engravinator is an Open Source hardware project that was started, in 2018, by my fellow Red Hatter, Adam Haile.  You can read his blog here, where he discusses the various other projects that he has created.  I met Adam at the second East Coast RepRap Fesival (ERRF), back in October.  He was showing his prototype laser engraver, and I was immediately impressed with the quality and thoughtful engineering that had clearly gone into the device.

View this post on Instagram

So. Freaking. Excited. Nearly a year of work and the not-so-secret project is ready for launch! Say hello to @TheEngravinator! The most orange and compact diode-laser engraver around. Come check it out at #ERRF2019 ⠀ https://buff.ly/2ocEcaa⠀ #laser #3Dprinted #engraver #cnc

A post shared by Maniacal Labs (@maniacallabs) on Oct 1, 2019 at 7:31am PDT

So, when Adam told me that there was a beta test group being set up, to test out the process for building the machine, I jumped at the opportunity.  After an amazingly quick kitting process, where Adam was inundated with parts, he finished the kits over the Thanksgiving holiday.  Mine arrived on December 3rd, and I quickly realized that I had forgotten to print the required 3D-printed parts!  I finished the first set (the core components) early this morning (in Prusament Galaxy Black, perfect for a Baltimore Orioles fan!), and I think that they came out amazingly well:

I'm now running the print for the electronics enclosure, on my Prusa i3 Mk2.5, and am hoping to finish all the prints by late, tonight:

If you're as excited as I am about this project, join the forum, and discuss this amazing project with the rest of us!

Fedora, Ansible and vSphere

I'm working on testing OpenShift 4.2 on vSphere, in my home lab.  Eventually, this will lead to an OCP 4.2 workshop, but I need to be able to do repeated builds, easily, first.

There is a really nice Ansible-based deployer already available, that uses Terraform, here.  However, I wanted to use pure Ansible, so I, as usual, made more work for myself.

I started going through the Ansible/vSphere configuration document, here.  I quickly discovered that the instructions, while complete, didn't seem to work on Fedora 30 or 31.  The issue turned out to be that the built-in Ansible didn't find the vSphere automation SDK, even when built into an activated virtualenv.

To work around this, I installed Ansible, itself, in the virtualenv.  So the completed steps to a working Ansible/vSphere integration are:

$ virtualenv ansible
$ source ansible/bin/activate
$ pip install ansible
$ git clone https://github.com/vmware/vsphere-automation-sdk-python.git
$ cd vsphere-automation-sdk-python/
$ pip install --upgrade --force-reinstall -r requirements.txt --extra-index-url file:///~/vsphere-automation-sdk-python/lib

Once that is complete, you can use the vSphere dynamic inventory plugin, by doing the following:

$ cat << EOF > ansible.cfg
[inventory]
enable_plugins = vmware_vm_inventory
EOF
$ cat << EOF > inventory.vmware.yml
plugin: vmware_vm_inventory
strict: False
hostname: vcenter
username: <vCenter admin user>
password: <vCenter admin password>
validate_certs: False
with_tags: True

Then, you can run an inventory query against your vCenter server:

$ ansible-inventory -i inventory.vmware.yml --list
{
    "_meta": {
        "hostvars": {
            "Fedora 31 (64-bit)_420ce9bb-dce1-05c6-33f5-6f2072436499": {
                "ansible_host": "10.0.1.66",
                "config.cpuHotAddEnabled": false,
                "config.cpuHotRemoveEnabled": false,
                "config.hardware.numCPU": 1,
                "config.instanceUuid": "500c0fdc-f1a7-1d79-d0a3-642e8e26642c",
                "config.name": "Fedora 31 (64-bit)",
                "config.template": false,
                "guest.guestId": "fedora64Guest",
                "guest.guestState": "running",
                "guest.hostName": "fedora31.jajcs.loc",
                "guest.ipAddress": "10.0.1.66",
                "name": "Fedora 31 (64-bit)",
                "runtime.maxMemoryUsage": 2048
            },
            "VMware vCenter Server Appliance_564d4d0f-52f6-5d7d-bfc1-6641b464586b": {
                "ansible_host": "10.0.1.15",
                "config.cpuHotAddEnabled": true,
                "config.cpuHotRemoveEnabled": true,
                "config.hardware.numCPU": 4,
                "config.instanceUuid": "524f8660-11e1-df20-ab50-049c484fa387",
                "config.name": "VMware vCenter Server Appliance",
                "config.template": false,
                "guest.guestId": "vmwarePhoton64Guest",
                "guest.guestState": "running",
                "guest.hostName": "vcenter.jajcs.loc",
                "guest.ipAddress": "10.0.1.15",
                "name": "VMware vCenter Server Appliance",
                "runtime.maxMemoryUsage": 16384
            }
        }
    },
    "all": {
        "children": [
            "fedora64Guest",
            "other3xLinux64Guest",
            "poweredOn",
            "ungrouped"
        ]
    },
    "fedora64Guest": {
        "hosts": [
            "Fedora 31 (64-bit)_420ce9bb-dce1-05c6-33f5-6f2072436499",
        ]
    },
    "other3xLinux64Guest": {
        "hosts": [
            "VMware vCenter Server Appliance_564d4d0f-52f6-5d7d-bfc1-6641b464586b"
        ]
    },
    "poweredOn": {
        "hosts": [
            "Fedora 31 (64-bit)_420ce9bb-dce1-05c6-33f5-6f2072436499",
            "VMware vCenter Server Appliance_564d4d0f-52f6-5d7d-bfc1-6641b464586b",

        ]
    },
}

Good luck!

Fedora and Ubiquiti USG L2TP VPN

[UPDATED 2019/11/01]
With some recent updates to the Ubiquiti firmware, it seems that the restrictive algorithms list, in the IPsec config, are no longer required.  Now, you can use the "Prevalent Algortihms" button, in NetworkManager, and the connection works.

For documentation purposes, the algorithms in the dialog are:

Phase 1 Algorithms: aes256-sha2_256-modp2048,aes256-sha2_256-modp1536,aes256-sha2_256-modp1024,aes256-sha1-modp2048,aes256-sha1-modp1536,aes256-sha1-modp1024,aes256-sha1-ecp_384,aes128-sha1-modp1024,aes128-sha1-ecp_256,3des-sha1-modp2048,3des-sha1-modp1024
Phase 2 Algorithms: aes256-sha1,aes128-sha1,3des-sha1

[ORIGINAL POST]
I've been using Ubiquiti network gear at home, for a few years now, and I really love it.  The combination of strong hardware and really good after-sale support, and quick security updates is still really compelling.  I especially like that I can run the management interface on a Raspberry Pi, in a container, for extreme ease of maintenance.

About 4 years ago, an attacker managed to exploit my old firewall (a Netgear router/firewall of some unmemorable type) and caused a significant amount of cleanup work, for me.  After that experience, I decided that my old method of remote access (SSH on a high port) wasn't going to continue to work.  After some research and testing, I settled on Ubiquiti, with the UniFi Security Gateway, for my access control device.  For most purposes, it has been excellent, even reporting detailed statistics on all associated connections.  The one issue that I had was in getting VPN access working.  My Windows and Mac (very few!) clients were easy to setup, based on the guide here, and iOS and Android were similarly easy.

Fedora (my choice for general desktop use) was a different matter.  I spent quite a few hours in trying to troubleshoot why the VPN wouldn't associate, giving up in disgust each time.  I truly do not enjoy troubleshooting VPN connections, and this was just one more reminder why.  Just today, though, I finally figured out the solution.

I am using Fedora 30, and the default GNOME desktop.  Here are the steps that I took to get the software installed.  I chose strongswan, based on the recommendations here.

$ sudo dnf install strongswan
$ sudo dnf search l2tp
$ sudo dnf install NetworkManager-l2tp-gnome
$ sudo dnf remove libreswan

Once that was complete, I configured the VPN connection, from the GUI.  My final config looks like this:

With those settings, especially the "Phase1" and "Phase2" algorithms, everything works great.