umhau.github.io

Network Interface Madness

2022-10-01T00:00:00+00:00

Well, this was fun to write. I’m trying to do some server automation; part of the process is automatically figuring out which network interfaces are available, and on which networks. I have a machine with 4+ ports: I really don’t want to go plugging and unplugging each one just to figure out which one is connected where.

You might say, “that’s easy! just run ifconfig, get the subnet associated with each interface, and parse the results. Bing, bang, boom, done.” But there’s a few problems with that approach. First among them is that we aren’t assuming the existence of any kind of L3 network. In that case, how do you know which of your interfaces are on the same switch? What if the machine is on multiple L2 networks? What if you only care about VPN interfaces, or want to ignore wifi? What if there’s no subnet?

Anyway, that’s what I had to deal with.

To solve the problem, I wrote a very ugly script. If you don’t like it….well, constructive analysis always welcome. Pull requests better still. To use it, specify the “types” of interfaces you want to analyze and about how much time it should take.

iface-groups -i eth -t 3

The output is a little strange. The problem with the data involved is that it’s inherently 2-dimensional; I want to know which interfaces are grouped together. That doesn’t lend itself well to a linear output. So, on every line sent to STDOUT, I’m printing a space-separated list of all interfaces that are connected on the same L2 network. For example:

$ iface-groups -i eth -t 3

eth0 eth2
eth1 eth3 eth4

You can parse this pretty well in a while read loop, like so:

iface-groups -i eth -t 3 | while read group
do

    echo "these interfaces can see only each other: $group"

done

Finally, you may be wondering about the available interface types. Well, you can read the script, or I’ll just list them out below. You can guess which is which, because I really don’t feel like specifying them right now. I just wrote this whole thing, gosh darn it!

Available interface types:
  eth, wlan, bridge, vlan, bond, tap, dummy, ib, ibchild, ppp
  tipip, ip6tnl, lo, sit, gre, irda, wlan_aux, tun, isdn, mip6mnha

Anyway, that’s all a nice little prelude to actually dumping the script here. I got no idea what the license is; the type identification was pulled from stack overflow and the original source link is dead. So whatever. If you want an updated version, you’ll have to hunt through my github repos: I probably won’t update this post, and the project it’s for is still under wraps. You’ll have to check back in a few years when it’s finally presentable.

#!/bin/bash
# written by me on October 1, 2022. Do what you will, for I have already won.

# enumerates the properties of each network interface
# eventually, it may be possible to assign rules on a per-network basis
# i.e., all ifaces on 10.111.13/24 should request DHCP
# unless, that's better done as a set of logic outside this program

# we need to know:
# - which interfaces are wired
# - which interfaces are connected
# - which interfaces are on the same L2 network

# ASSUMPTION: one interface is NOT connected to multiple L2 switches

set -e

help () {

    echo -e "usage:"
    echo -e "\t-i , --ifacetype=[TYPE]"
    echo -e "\t-t , --timelimit=[seconds]"
    echo -e "Multiple interface types may be specified, like so:"
    echo -e "\tiface-groups -i eth -i tun -t 5"
    echo -e "Available interface types:"
    echo -e "\teth, wlan, bridge, vlan, bond, tap, dummy, ib, ibchild, ppp,"
    echo -e "\tipip, ip6tnl, lo, sit, gre, irda, wlan_aux, tun, isdn, mip6mnha"

}

timelimit="$1" ; [ -z "$timelimit" ] && timelimit='4'

arp_period='1'

ip_address_prefix='203.0.113'

#         +----------------------+----------------------------+
#         | Attribute            | Value                      |
#         +----------------------+----------------------------+
#         | Address Block        | 203.0.113.0/24             |
#         | Name                 | Documentation (TEST-NET-3) |
#         | RFC                  | [RFC5737]                  |
#         | Allocation Date      | January 2010               |
#         | Termination Date     | N/A                        |
#         | Source               | False                      |
#         | Destination          | False                      |
#         | Forwardable          | False                      |
#         | Global               | False                      |
#         | Reserved-by-Protocol | False                      |
#         +----------------------+----------------------------+
# 
#         Table 14: TEST-NET-3

ifacetype=eth timelimit=3 lopts=ifacetype:,timelimit: sopts=i:t:

PARSED=$(getopt --options=$sopts --longoptions=$lopts --name "$0" -- "$@")

eval set -- "$PARSED"

while true; do case "$1" in

    -i|--ifacetype) 

        allowed_iface_types="${allowed_iface_types:+$allowed_iface_types } $2"
        shift 2
        ;;

    -t|--timelimit) timelimit="$2"  ; shift 2 ;;

    --) shift ; break ;;
    *)  help ; exit 1 ;;

esac done

[ -z "$allowed_iface_types" ] && help && exit 1

tempfile=/tmp/iface_enumeration
groupingfolder=/tmp/iface_enumeration_groups

rm -rf $tempfile $groupingfolder
mkdir -p $tempfile
mkdir -p $groupingfolder

if ! command -v tcpdump &>/dev/null ; then echo "tcpdump required" ; exit 2 ; fi

sudo -v

get_iface_type () {
    
    # function came from a dead link via stackoverflow
    # http://gitorious.org/opensuse/sysconfig/blobs/master/scripts/functions

    local IF=$1 TYPE
    test -n "$IF" || return 1
    test -d /sys/class/net/$IF || return 2
    case "`cat /sys/class/net/$IF/type`" in
            1)
                TYPE=eth
                # Ethernet, may also be wireless, ...
                if test -d /sys/class/net/$IF/wireless -o \
                        -L /sys/class/net/$IF/phy80211 ; then
                    TYPE=wlan
                elif test -d /sys/class/net/$IF/bridge ; then
                    TYPE=bridge
                elif test -f /proc/net/vlan/$IF ; then
                    TYPE=vlan
                elif test -d /sys/class/net/$IF/bonding ; then
                    TYPE=bond
                elif test -f /sys/class/net/$IF/tun_flags ; then
                    TYPE=tap
                elif test -d /sys/devices/virtual/net/$IF ; then
                    case $IF in
                      (dummy*) TYPE=dummy ;;
                    esac
                fi
                ;;
           24)  TYPE=eth ;; # firewire ;; # IEEE 1394 IPv4 - RFC 2734
           32)  # InfiniBand
            if test -d /sys/class/net/$IF/bonding ; then
                TYPE=bond
            elif test -d /sys/class/net/$IF/create_child ; then
                TYPE=ib
            else
                TYPE=ibchild
            fi
                ;;
          512)  TYPE=ppp ;;
          768)  TYPE=ipip ;; # IPIP tunnel
          769)  TYPE=ip6tnl ;; # IP6IP6 tunnel
          772)  TYPE=lo ;;
          776)  TYPE=sit ;; # sit0 device - IPv6-in-IPv4
          778)  TYPE=gre ;; # GRE over IP
          783)  TYPE=irda ;; # Linux-IrDA
          801)  TYPE=wlan_aux ;;
        65534)  TYPE=tun ;;
    esac
    # The following case statement still has to be replaced by something
    # which does not rely on the interface names.
    case $IF in
        ippp*|isdn*) TYPE=isdn;;
        mip6mnha*)   TYPE=mip6mnha;;
    esac
    test -n "$TYPE" && echo $TYPE && return 0
    return 3
}

# for every interface on the system
for interface in /sys/class/net/*
do

    interface=$(basename $interface)

    # figure out what it is: wifi? ethernet? virtual bridge? infiniband?
    iface_type=$(get_iface_type $interface)

    # for each of the useful interface types, specified above (or in an arg)
    for allowed_iface_type in ${allowed_iface_types[@]}
    do

        # if the interface we're looking at is one of those allowed
        if [ "$iface_type" == "$allowed_iface_type" ]
        then

            # if the interface is connected to something: switch, router, etc
            if tcpdump --list-interfaces | grep $interface | grep -q 'Running'
            then

                # add it do the list of viable interfaces
                viable_ifaces="${viable_ifaces:+$viable_ifaces } $interface"

            fi

            # don't check more types after a match: "there can be only one"
            break

        fi

    done

done

[ -z "${viable_ifaces[@]}" ] && echo "no viable interfaces discovered" && exit 1

ip_iterator=0

declare -A iface_ip

starttime=$(date +%s)

# for each viable interface we found
for interface in ${viable_ifaces[@]}
do

    # create a unique, unused ip address (taken from TEST-NET-3, RFC 6890)
    ip_iterator=$((ip_iterator+1))
    ip_address="$ip_address_prefix.$ip_iterator"

    # associate that ip address with the current interface
    iface_ip+=(["$ip_address"]="$interface")

    # start listening on that interface for ARP requests
    sudo timeout $timelimit tcpdump --immediate-mode -i $interface arp > $tempfile/$interface 2>/dev/null &

    # start sending ARP requests for the unique IP address on that interface
    sudo arping -I $interface -w $timelimit $ip_address &>/dev/null &

done

# total time it took to start the listeners and senders
endtime=$(date +%s)
initializationtime=$(( $endtime - $starttime ))

# wait for the listeners and senders to finish
sleep $(($timelimit + $initializationtime + 1))

# for each viable interface, get the file with the results from the listener
for ifacefile in $tempfile/*
do

    ifacename=$(basename $ifacefile)

    # if the iface is not already in a group of ifaces that can see each other
    if ! grep -q $ifacename $groupingfolder/* 2>/dev/null
    then

        # create a new group with just that interface
        echo $ifacename > $groupingfolder/$(date +%s%N)

    fi

    # for each ARP request seen by this interface, get the IP address requested
    grep $ip_address_prefix $ifacefile | cut -d ' ' -f 5 | while read ipaddress
    do

        # get the group file of the interface that saw the request
        groupfile=$(grep -l $ifacename $groupingfolder/* 2>/dev/null)

        # convert the ip address to the sender interface and add it to the group
        echo ${iface_ip[$ipaddress]} >> $groupfile

    done

done

# for each group of interfaces that we collected
for group in $groupingfolder/*
do 

    # filter out duplicate interfaces within the group and print to stdout 
    echo $(sort $group | uniq | xargs)

done

Set up Xen on Alpine Linux

2022-09-23T00:00:00+00:00

So I’m starting out on this new project. The first iteration is just VMs on a box - but they’re Xen VMs, and they’re on an Alpine box. Later iterations shall be revealed, all in good time. Much work has been done behind the scenes, and much work is yet to be done.

session 1: the host

Anyway, Xen vms on Alpine. Start with a clean alpine installation, then enable the community repository. Note that I used this source for most of the content here, but as written, that source has a couple bugs. i.e., my walkthrough works, and theirs doesn’t - quite.

First become root. You should remain root for the duration of this walkthrough.

su

cat /etc/os-release

repository_server="dl-cdn.alpinelinux.org"
alpine_version="v3.16"

echo "https://$repository_server/alpine/$alpine_version/main" > /etc/apk/repositories

Install the hypervisor, and related packages.

apk add xen xen-hypervisor seabios xen-qemu # ovmf
apk add grub grub-bios

Load the necessary kernel modules.

echo "xen-netback" >> /etc/modules
echo "xen-blkback" >> /etc/modules
echo "tun" >> /etc/modules

And add the xen daemons.

rc-update add xenconsoled
rc-update add xendomains
rc-update add xenqemu
rc-update add xenstored

Then reboot; because kernel mods don’t immediately take effect, and those daemons haven’t autostarted yet.

reboot

Now we get to do the tricky stuff: GRUB modifications. If you recall your Xen, you’ll remember that it’s got a special Dom0 that manages the other VMs on the host. We need to specify some configs for that VM, and the place to do that is in GRUB, before things like “RAM size” are determined.

Add the following to the bottom of the grub config. Note that you may want to increase the size of the dom0 RAM; just change 1024M to some larger number.

vim /etc/default/grub

# You need to set the amount of RAM to allocate to the Dom0 Alpine install so that
# our future virtual machines will have enough memory.
GRUB_CMDLINE_XEN_DEFAULT="dom0_mem=1024M,max:1024M"

GRUB_DEFAULT="saved"
GRUB_SAVEDEFAULT="true"

Then apply the new config.

grub-mkconfig -o /boot/grub/grub.cfg
grub-set-default "$(grep ^menuentry /boot/grub/grub.cfg | grep Xen | cut -d \' -f 2 | head -1)"

That sets the default entry in GRUB to the first entry containing ‘Xen’. Run this every time you upgrade Alpine or Xen.

One last thing. Do you plan to use more than 8 VMs? Probably. If so, be sure to increase the maximum number of loop devices.

In Alpine Linux, you will need to add the max_loop option to the loop module, then add the loop module to your initramfs.

touch /etc/modprobe.d/loop.conf
echo "options loop max_loop=32" > /etc/modprobe.d/loop.conf

Then update the modules list and reboot.

mkinitfs
reboot

If you want to confirm that the dom0 management vm is running, execute this:

xl list

session 2: the guests

Alpine docs won’t help so much here. I’m working from the xenproject now.

Notes Regarding the Installation of Linux on a mid-2012 Macbook Air

2022-08-25T00:00:00+00:00

Bought a macbook air recently. It’s an old one, but the hardware’s cheap and with a decent linux install you don’t really notice (except when you’re using firefox).

FreeBSD couldn’t handle the wifi card. I had to compile the kernel with special GPL code, enable specific kernel modules, and even then it only worked randomly. And we all know that random success is far worse than failure.

So back to the loving arms of Void.

When booting, hold the option/alt key down until the boot menu shows up. This lets you pick a USB boot device.

The installation went smoothly - since there’s no ethernet port, you’ll have to either install the full graphical desktop environment, or learn to enable the wifi via the command line. It’s not too hard. But it can be intellectually scary. Create the file below.

cli wifi

# /etc/wpa_supplicant.conf
ctrl_interface=/run/wpa_supplicant
ctrl_interface_group=wheel
update_config=1

network={
    ssid="name of wifi network"
    psk="wifi password"
}

Then figure out what your wifi interface is. Run this:

find /sys/class/net -mindepth 1 -maxdepth 1 -lname '*virtual*' -prune -o -printf '%f\n' |
while read iface ; do
    echo interface: $iface
done

That will output all the network interfaces on your computer. If you’re using a macbook air 2012, and you don’t have a usb ethernet port plugged in, there will be just one output. It’ll probably look like this:

wlp2s0b1

Then run the following command to connect to your wifi network. Notice the wif interface. Make sure it matches. Ping google when you’re done, to see if it all worked.

wpa_supplicant -B -i wlp2s0b1 -c /etc/wpa_supplicant.conf

I installed the i3 window manager. Needed a bunch of extra packages. But that’s all easy, and contained in the install script. The problem I had was with the touchpad - the cursor would only move vertically, and only if I swiped side-to-side. Hunted for an hour; finally found the solution. Turns out the kernel was loading the hardware in the wrong order. This is the bug; looks like they just figured ignoring it would make it go away.

All you gotta do is reload the kernel modules and we’re golden. I wrapped it up in a script and run it on boot from /etc/rc.local.

modprobe -r usbmouse
modprobe -r bcm5974
modprobe bcm5974

Also, if you want to modify the behavior of the mouse, this link should help: https://blog.inagaki.in/en/post/macbook-air-linux-3/

After that it’s easy sailing. The keyboard is correctly mapped, so if you have a half-decent i3 config file a lot of things should “just work”.

Syncthings

2022-08-14T00:00:00+00:00

Syncthing is this cool program that is basically Dropbox Unlimited (tm): everything is only on your own server (except the NAT punching and where-are-you stuff), and your space is limited only by the storage on your devices.

I want to set up a syncthing NAS. But, I want to make it available to two separate people, each with their own accounts. And I want to do it on FreeBSD. And I want to manage it remotely.

That means we’re also using a program called zerotier. You know how it’s easier to talk to machines that are connected to the local network? This is a tiny program you install on machines around the world, you share a key with each, and then they can all see each other as if they’re on the same local network.

I need to put that on the FreeBSD machine as well, so that I can access the management GUI without fragile port forwarding. The goal is that this machine can be plugged in anywhere, turned on, attached to an ethernet cable, and get right down to business.

We’re doing this from a fresh FreeBSD installation.

installations

The trick to multple syncthing users on a single machine is, literally, multiple users. I thought I’d need jails or some such, but as it turns out, all we need are to create new users. Here, I’m using usr1 and usr2.

I did that during the install process, so I won’t document the manual user creation process here. Go google it if you don’t know how.

Become root, if you aren’t already.

su

Perform the initial system updates. This will take a while.

freebsd-update fetch
freebsd-update install

Install the packages we need.

pkg install syncthing zerotier nano tmux vim htop

Do you have a zerotier account? Because you’ll need one. Unless you want to selfhost the sync servers; but that’s a project for another day. Go get one, and set up a network. Then come back.

configurations

cron

Use cron to start two separate instances of syncthing on boot: one owned by user usr1, and the other owned by user usr2. Also start zerotier as the root user (which is default, since we’re using the root cron account).

su
crontab -e

@reboot su - usr1 -c /usr/local/bin/syncthing
@reboot su - usr2 -c /usr/local/bin/syncthing
@reboot zerotier-one -d

After we (eventually) reboot, we can use top (or htop) to see the two syncthing instances running.

zerotier

Start zerotier.

zerotier-one -d

Go get the id for the network you want to join this machine to. If you got yourself a zerotier account, you’ll know what I’m talking about.

zerotier-cli join 012d30m32bkjqqewr

pf

Enable the pf firewall: we need to manually adjust what we’re allowing through the system.

sysrc pf_enable=yes
sysrc pflog_enable=yes

Then create a new firewall config file. 

```shell
nano /etc/pf.conf

ex_if = "em0"
zt_if = "zta098fdas123ij"

set skip on lo0
scrub in

block in
pass out

pass in on $ex_if proto tcp from any to ($ex_if) port { ssh, domain, http, https, 22001, 22002, 8385, 8386 }
pass in on $zt_if proto tcp from any to ($zt_if) port { ssh, domain, http, https, 22001, 22002, 8385, 8386 }

pass in on $ex_if proto udp to ($ex_if) port { domain, 22001, 22002, 8385, 8386 }
pass in on $zt_if proto udp to ($zt_if) port { domain, 22001, 22002, 8385, 8386 }

pass in on $ex_if proto udp to any port { mdns, 21028, 21029 }
pass in on $zt_if proto udp to any port { mdns, 21028, 21029 }

pass in on $ex_if inet proto icmp to ($ex_if) icmp-type { unreach, redir, timex, echoreq }
pass in on $zt_if inet proto icmp to ($zt_if) icmp-type { unreach, redir, timex, echoreq }

Note that the zt_if variable will be different for you - you’ll have to get it by running ifconfig and seeing what the zerotier interface actually is.

syncthing

Note that in both examples above, we have opened several custom ports. By default, syncthing wants to use port 8384 to host the GUI and uses port 22000 for everything else (TCP and UDP, in case you know what that means). We need to adjust these, and we’ll have to use the command line.

Summary of changes:

usr1
port 22001
port 8385
port 21028

usr2
port 22002
port 8386
port 21029

GUI
0.0.0.0

So. Become the user.

su usr1

Start syncthing, let it initialize, and then kill it with CTRL-C.

syncthing

Open the syncthing config file.

cd
nano .config/syncthing/config.xml

Now you’ll have to modify several points in this (rather long) file. They will look similar to the sections below. Since we are usr1, the following are the changes we must make.

usr1
port 22001
port 8385
port 21028

<gui enabled="true" tls="true" debugging="false">
    <address>127.0.0.1:8384</address>
    <user>usr1</user>
    ⋮
</gui>

<options>
    <listenAddress>default</listenAddress>
    ⋮
    <localAnnouncePort>21027</localAnnouncePort>
    <localAnnounceMCAddr>[ff12::8384]:21027</localAnnounceMCAddr>
    ⋮
</options>

Alter the above to match the below.

<gui enabled="true" tls="true" debugging="false">
    <address>0.0.0.0:8385</address>
    <user>usr1</user>
    ⋮
</gui>

The 0.0.0.0 indicates that we want to access the GUI from the rest of the local network; otherwise, we’d have to physically log into that machine running syncthing in order to get to the GUI.

<options>
    <listenAddress>22001</listenAddress>
    ⋮
    <localAnnouncePort>21028</localAnnouncePort>
    <localAnnounceMCAddr>[ff12::8385]:21028</localAnnounceMCAddr>
    ⋮
</options>

Now exit from usr1, become usr2, and perform the simlilar set of substitutions with the usr2 settings.

usr2
port 22002
port 8386
port 21029

cleanup

Get the ip address of the syncthing host.

ifconfig

And reboot. If you did everything correctly, syncthing will automatically startup with the machine. You can access the GUI for each of the syncthing users with the IP address you just obtained, and the GUI port appended:

http://123.456.789.000:8385
http://123.456.789.000:8386

Not only that, but you can also use the IP address of the machine that’s available through zerotier. That gives you global, secure access. From there you can connect each instance to whatever accounts you want.

Uglify Your Windows Server

2022-08-11T00:00:00+00:00

Sometimes I get confused. It’s not much, very often; a misplaced coffee cup here, a bit of code forgotten there. But sometimes it’s Important, and sometimes there’s a chance to head the chaos off. This is one of those latter things.

I have to administer some Windows Servers, and I’ll often do that via remote desktop from my office computer. The problem is, windows is very good at making the experience seamless - which means that on two specific occasions, I’ve forgotten that I’m within the RDP session. I make a quick test, or (worse, much, worse) run a powershell command, and suddenly – the wrong machine is newly different.

So what’s the best way to solve human error? Blood. Red blood.

Or, lacking that, blood red aesthetics: change the theme of the windows server to be all-red. That way, I’ll never forget where I am. Problem is, you can’t do that in Windows Server:

So, we have to modify the registry directly.

(What’s the registry? It’s this giant, semi-centralized place where windows stores all the little miscellaneous bits of information that it needs to know about itself. One of those is, ‘what-color-to-make-the-window-borders’.)

regedit

Go to the subsection here:

HKEY_CURRENT_USER\Software\Microsoft\Windows\DWM

Then modify the entry redundantly titled

ColorizationColor

Colors are in HEX format, including alpha channel which is represented by c0. Go here to find a new color.

Note that the format includes transparency, so you have to modify the format a little bit, by sticking a c0 to the front. In other words, the color cd0404 you got from the color picker site becomes c0cd0404. Paste that into the registry entry, hit Ok, and you’re all set.

If you’re using a remote desktop session, just quit and come back. If you’re local, I think you can just log out and in again.

Behold the insanity:

The Zig Language, Session 1: Hello, World

2022-08-01T00:00:00+00:00

I’ve been watching the Zig language for a while now. Like some other things I’m interested in, the phrase “good engineering” seems appropriate. The syntax hasn’t stabilized yet, so this session focuses on the 0.9.1 version of the project. Far as I know, anything is subject to change.

manual installation

First things first. Let’s get ourselves downloaded and installed. Download a copy of Zig from their downloads page and extract it.

mkdir ~/zig
cd ~/zig
wget https://ziglang.org/download/0.9.1/zig-linux-x86_64-0.9.1.tar.xz
tar -xf zig-linux-x86_64-0.9.1.tar.xz

Now you can either add that location to your PATH, or you can just put the binary somewhere already on your PATH.

What’s your PATH? It’s the road of life laid before you, which you, oh weary traveler, must trod until the end of your days. May it bring you peace.

Actually, it’s how you’re able to run programs directly from the commandline without specifying their location. Ever think about how you can do cd ~/zig without having to say where the cd program is located? And no, it’s not some builtin thing that just “comes with” your terminal program. Try whereis cd sometime. It’s fun.

Now that we’ve extracted zig, we’re just going to skip adding it to our path. That’s annoying, because it’s another folder we have to remember not to move, and we have to manually edit files. Let’s just dump zig into /usr/local/bin and add a line to our system install script to do the whole thing automatically next time.

You have a system install script, don’t you? A little script that you run when you set up a new machine, that gets everything set up just the way you like it? I love it. Doesn’t require a lot of maintanence if you do it right, and it doesn’t ever have to be totally manual either. Just enough automation that it holds your hand while you get it all running. (I guess, in a sense, it’s your younger self holding your older self’s hand. Now there’s a strange thought.)

sudo install ~/zig/zig-linux-x86_64-0.9.1/zig /usr/local/bin/zig

Then we can just run zig from anywhere: zig build

I don’t think we need the lib folder that goes with the binary. If we do, there’s two options: dump the entire ~/zig/zig-linux-x86_64-0.9.1 folder into /usr/local/bin, or add the folder to the PATH; or just install from the OS package manager.

package manager installation

What OS are you on? I use Void Linux, though I’m working on transitioning to FreeBSD.

# void
sudo xbps-install zig

# freebsd
doas pkg install -y xorg

hello world

Verify the version of zig you installed. Note that Void seems to be running behind; might be this is a good time to be jumping off that ship. I think in the future Alping and FreeBSD might be my go-tos…a nice minimal linux, and a longstanding BSD.

zig version

Now let’s make our first zig program. Create a file called main.zig and put the following inside:

const std = @import("std");

pub fn main() void {
    std.debug.print("Hello, {s}!\n", .{"World"});
}

Then build and run it.

zig run main.zig

Intro to Lisp: Session 1

2022-06-01T00:00:00+00:00

I’ve been wanting to figure out lisp for a while. So, this is my rubber ducking session to figure it out. I’m working from the Scheme variation, rather than the (apparently) kitchen-sink common lisp variation…though they both seem pretty awesome.

setup

We’re using femtolisp, because I think it’s cool.

This is my foray into learning lisp. Rather than attempting to learn some part of the greater whole of Common Lisp, I’m using a smaller variation called (femtolisp)[https://github.com/JeffBezanson/femtolisp]. This is considered a dialect of Scheme, and a “lisp-1 with lexical scope,” (which means that)[https://stackoverflow.com/a/4578888] you cannot have a function and a variable that share the same name. I think it’s a neat version of lisp because it’s small and fast and claims to have among its focii “to keep the code concise and interesting.” Also, I think it was used in the development of the Julia language – and a similar lisp can be accessed through the Julia interface.

There’s a number of concepts that seem based on lisp, that I haven’t run into before, including “tail recursion” and “gensyms.” I’ll include sections to try and cover the strange concepts. Also this should include documentation of the available functions, and how to use them.

Installation & a ‘Hello World’

This is one of the simpler compilations I’ve encountered.

git clone https://github.com/JeffBezanson/femtolisp.git
cd femtolisp
make

I think you need a couple compiler-related dependencies, but femto is already set up on all my available machines, so I don’t have an easy way to check what those deps are.

To run the program while in the ./femtolisp directory, just do

./flisp

the ten commandments

When recurring on a list of atoms, lat, ask two questions about it: (null? lat) and else. When recurring on a number, n, ask two questions about it: (zero? n) and else. When recurring on a list of S-expressions, l, ask three question about it: (null? l), (atom? (car l)), and else.
Use cons to build lists.
When building a list, describe the first typical element, and the cons to it onto the natural recursion.
Always change at least one argument while recurring. When recurring on a list of atoms, lat, use (cdr lat). When recurring on a number, n, use (sub1 n). And when recurring on a list of S-expressions, l, use (car l) and (cdr l) if neither (null? l) nor (atom? (car l)) are true. It must be changed to be closer to termination. The changing argument must be tested in the terminaion condition: when using cdr, test termination with null? and when using sub1, test termination with zero?.
When building a value with +, always use 0 for the value of the terminating line, for adding 0 does not change the value of an addition. When building a value with ×, always use 1 for the value of the terminating line, for multiplying by 1 does not change the value of a multiplication. When building a value with cons, always consider () for the value of the terminating line.
Simplify only after the function is correct.
Recur on the subparts that are of the same nature:
- On the sublists of a list.
- On the subexpressions of an arithmetic expression.
Use help functions to abstract from representations.
Abstract common patterns with a new function.
Build functions to collect more than one value at a time.

The Five Rules

The Law of Car The primitive car is defined only for non-empty lists.
The Law of Cdr The primitive cdr is defined only for non-empty lists. The cdr of any non-empty list is always another list.
The Law of Cons The primitive cons takes two arguments. The second argument to cons must be a list. The result is a list.
The Law of Null? The primitive null? is defined only for lists.
The Law of Eq? The primitive eq? takes two arguments. Each must be a non-numeric atom. There doesn’t seem to be a way to run make install, so you’ll have to do that manually, by trial and error. I’m content to just leave the stuff where it was compiled.

You can run it interactively (is that what’s known as a Read-Eval-Print Loop (REPL) ?), by running

./flisp

from inside the directory. Print to the command line with

(print "Hello World")

though, this will append a #t to the string. Don’t know why. Get out with

(exit)

The Impatient Schemer

Now we’re gonna do a crash course in Lisp, because why not. It’s probably been written only a thousand times before. However: it’s never been written by me, and that means I’ve never had the chance to learn by teaching. So here goes.

Testing Internal Network Access

2022-05-01T00:00:00+00:00

This is cool for testing external access to a network:

torsocks ssh example.net

Source.

mount anything with an ssh server

2022-02-10T00:00:00+00:00

Quick note, this is the favored incantation to prevent too many instances of lost connections.

mkdir /local/mount/point
sshfs -o allow_root,reconnect,ServerAliveInterval=15,ServerAliveCountMax=3  user@remotelocation:/path/to/folder /local/mount/point

The extra arguments are the real magic here. If you notice, some of those help reestablish the connection - in practice, this means that sometimes it will come back after putting your laptop to sleep. I tend to put specific commands for specific mounts into scripts. However, you can also just put the first part with the ‘incantations’ into a bash alias.

nano ~/.bashrc

Add this to the end:

alias shfs='sshfs -o allow_root,reconnect,ServerAliveInterval=15,ServerAliveCountMax=3 '

Then you can simplify mounting, and make it very similar to scp and ssh:

mkdir /local/mount/point
shfs user@remotelocation:/path/to/folder /local/mount/point

Expand the netmask of a Windows DHCP Scope

2022-02-03T00:00:00+00:00

I used to wonder why “Micro$oft” was so disliked in the opensource community. Naively, I supposed it had to do with the great evil of demanding money in return for services; or possibly the greater horror of refusing access to source code. But I have learned wisdom before my time, for I have met Active Directory. What was it Aeschylus said?

Even in our sleep, pain which we cannot forget falls drop by drop upon the heart until, in our own despair, against our will, comes wisdom through the awful grace of God.

I need to change the netmask on the dhcp server. My organization has outgrown the /24 allocation it was born with. Easy, right? Just backup a few config files, change a number in a dhcp.conf-style textfile and do whatever the windows equivalent of sh /etc/netstart is. Oh, my sweet summer child.

We’re dealing with scopes and superscopes: not subnets. We have to export the scope configuration, including DNS and WINS servers, as a semi-executable script. Then we modify the script to use the new netmask. Then we delete the old scope, along with all our DHCP leases and reservations. Then we create a new scope using our exported script.

Before we go any further, backup the DHCP database. Do this by right-clicking on the root node of the tree in the left-hand bar of the DHCP manager, and select backup, and choose where you want the backup to go. Don’t lose this.

alternatives

Since I’m just trying to change the netmask, it’s also possible to create a superscope and add the current scope. However, this will create two distinct subnets that can’t talk to each other, and the gateway will have to have separate ip addresses for each scope. Then you create firewall rules to let the scopes talk to each other.

It could work, but the communication between the subnets seems like too much complexity and I need to make sure whoever comes after me can understand what’s going on. I’d rather just redo the main subnet and keep it dead simple.

doit

Export the current scope. We’re using netsh instead of Export-DhcpServer, because I’ve had situations in the past where I exported to both, but the import failed on the latter and succeeded on the former. Open powershell as an administrator.

netsh.exe dhcp server \\DOMAIN_NAME scope 192.168.1.0 dump > C:\scope.txt

This gets you a more-or-less executible script that you can modify and then reinsert. Broadly speaking you have to change two things: the scope and the netmask. Just use Ctrl-F and be done with it.

In this example, I’m changing the subnet from 192.168.1.1/24 to 192.168.1.1/20.

# any octet that varies (determined by the netmask) is set to 0
192.168.1.0 -> 192.168.0.0

# set the netmask to the new value
255.255.255.0 -> 255.255.240.0

# Also look for the command that sets the ip address range.
Add iprange 192.168.1.1 192.168.1.254 -> Add iprange 192.168.1.1 192.168.15.254

Once those changes are made, delete the scope from the DHCP manager. (Yes, I know. But there’s no way to back it up besides the export you just made, and at least turning off DHCP doesn’t break too many things too quickly.)

Then add the new scope by inserting the modified backup. The fun thing is, we can just execute it as a series of netsh commands. (and BTW, that is a weird rabbithole of a program) You probably had to save the modified script somewhere else, so change directories inside the cmd prompt first and then execute.

cd C:\Users\admin\Documents\
netsh.exe exec scope-modified.txt

And activate the scope.