Samba and Windows 98

 I've got a Windows 98 host here (yes, really, in 2020!) that I use to read and write floppy disks for my various vintage systems. For those who are curious, it is (at the moment):

Compaq Deskpro EN (chassis only)
Gigabyte GA-6VEM Socket 370 mainboard
Pentium 3 1.4 GHz
1 GB RAM
60 GB SATA2 SSD with IDE/SATA bridge
1.44 MB and 360 kB floppy drives

 I was having issues with the machine being unable to connect to my Fedora-based NAS, receiving the error:

The solution was suggested here, but I needed to add one more configuration item:

[global]
server min protocol = NT1
lanman auth = yes
ntlm auth = yes

That solved the problem and allowed my 98 host to connect and mount my shares. Of course, enabling LANMAN auth is a significant security hole, but on my internal network, I'm not too worried.

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.

Red Hat Container Development Kit 3.5 - Installation Issue with Libvirt (KVM) Group Membership

If you follow the installation instructions for Red Hat's Container Development Kit 3.5, on RHEL 7.5, most everything works well, until you get to the point of starting the virtualized minishift host:



You get a failure when trying to connect to Docker on the VM.  The problem is that, if you strictly follow the instructions, your user is not a member of the 'libvirt' group.  This is easy to rectify, though.  All you need to do is:

1) Remove the existing minishift VM:



2) Add yourself to the requisite group:



3) And relaunch minishift:



Hopefully I can get the docs updated, so this isn't necessary, in the near future.

Suspend Issues with the Lenovo ThinkPad X1 Carbon 6th Generation

UPDATE 2018/09/12:
And the final solution seems to be at hand!  Lenovo has released 0.1.30, and that apparently re-adds S3 sleep to the ACPI tables:

https://brauner.github.io/2018/09/08/thinkpad-6en-s3.html

UPDATE 2018/09/07:
So, it appears that there is a new firmware version available from Lenovo, 0.1.28, the patch no longer cleanly applies, and Adrian has re-rolled it:

https://lisas.de/~adrian/?p=1328

Thanks, Adrian, that's a much easier way to reliably patch the ACPI tables!

I'll update this post, later, with an updated step-by-step guide.

ORIGINAL POST:
Those of you who have the new (and very nicely built!) Lenovo ThinkPad X1 Carbon 6th generation, and who run Linux, may have noticed that suspend doesn't work properly.  I'm running Fedora 28, but this problem has been reported on Arch and Ubuntu, as well.  The issue seems to be that the X1 is using a new suspend technology called "Windows Modern Standby," or S0i3, and has removed classic S3 sleep.  S0i3 technology was added to the mainline Linux kernel with v4.13, but there is apparently a BIOS bug preventing this from working properly.

To work around this problem, we need to patch the ACPI DSDT tables, created by the BIOS, to re-add S3 sleep.  There's a fantastic guide here, which was written by Erik Sonnleitner of the University of Applied Sciences of Upper Austria.

To summarize his excellent directions:

• In the BIOS, set "Thunderbolt BIOS Assist Mode" to Enabled, and disable secure boot.
• Install "iasl" and "cpio"
• Once the system has booted whichever Linux distribution that you use, dump the DSDT table

sudo cat /sys/firmware/acpi/tables/DSDT > dsdt.aml

• Reverse compile the DSDT table

iasl -d dsdt.aml

• Download the patch, and patch your decompiled code
• I had to hand-patch hunk #7, by hand, but this wasn't a big deal

patch --verbose < X1C6_S3_DSDT.patch

• Compile your updated DSDT code

iasl -ve -tc dsdt.dsl

• Create a new ACPI override package

mkdir -p kernel/firmware/acpi
cp dsdt.aml kernel/firmware/acpi
find kernel | cpio -H newc --create > acpi_override
sudo cp acpi_override /boot

• Now, you need to update your grub.cfg

sudo sed -i 's/quiet"/quiet mem_sleep_default=deep"/' /etc/default/grub

echo GRUB_EARLY_INITRD_LINUX_CUSTOM=acpi_override | sudo tee -a /etc/default/grub

sudo grub2-mkconfig -o /boot/grub2/grub.cfg

• The second change won't work immediately, on Fedora, as GRUB_EARLY_INITRD_LINUX_CUSTOM isn't yet supported
• Please see https://bugzilla.redhat.com/show_bug.cgi?id=1600414
• So, we need to update the grub boot config, and then manually update the initrd entries to add the new ACPI overlay, before booting the initial ramdisk

sudo sed -i 's/initrd16 \/initramfs/initrd16 \/acpi_override \/initramfs/' /boot/grub2/grub.cfg

• Upon reboot, suspend should work properly.