Mar 302022
 

Just set up a UDM pro to replace a really old Cisco 881W and had some initial thoughts on it :-

  1. The firewall configuration is more than a little clunky; the version I was using still seems to require the legacy interface to configure IPv6 firewall rules. Plus configuring a set of IPv4 rules and a seperate set of IPv6 rules added to the clunkiness – why not allow tcp any to ${addresses} eq ssh rather than repeat the same rule with different address types? Anything to keep firewall rule sets simple is good (but I deal with another firewall that has over 200 rules).
  2. Whilst we’re on the subject of the firewall, it would be nice if the firewall supported the “apps” identified in the traffic management; not really an easy thing to do, but a firewall relying on port numbers is a bit 1990s to those of us used to next-generation firewalls.
  3. Device identification is just a little bit rough; to be fair I’m using a separate DHCP server. But to identify a Linux container as a Windows PC is more than a little off! I had to check that my virtual Windows 10 machine wasn’t actually running when I first saw this.
  4. The topology diagram is all very well but very boring if you’re not using all Ubiquiti gear. Not everyone is going to replace all their switches just to get this to work straight away – I have three switches not counting the ethernet-over-power devices that also count as switches. It would be handy if the UDM would at least go to some effort to identify third-party network devices.
  5. Oh, and ssh access to the command-line is … confusing. The gooey implies that you set up a password and a username, but it seems that whatever the username you use it really only works with the user root. And the username you supply isn’t contained within /etc/passwd on the device.

Oh! And requiring access to the cloud to generate the first admin (“owner”) account could well be problematic. Apart from the obvious problem of allowing the Cloud admin-level access to a firewall – something the more paranoid may regard as a killer misfeature, what happens if something goes wrong during the creation of a cloud-based account?

And having SNMP mentioned within the gooey but requiring command-line “bodges” (from here) to actually get it running is not acceptable. Strange that such a feature isn’t supported on a network device!

The Bench
Nov 112021
 

If you follow a certain Linux on Youtube, you may well be aware of an incident where Linus was trying to install Steam on a newly installed copy of Pop_OS! and managed to produce a bit of a mess without a desktop environment. What happened?

I think that when he encountered a problem installing Steam with the gooey, he then obtained a command-line “recipe” for installing Steam – potentially for a different distribution (it certainly mentioned removing lots of “stuff” including gnome-desktop).

Is this a problem with Linus being a bit of an idiot or Linux being a bit broken? A bit of both perhaps.

Linus’ idiocy is perhaps an example of a little knowledge being a dangerous thing – he mentioned being comfortable with using the command-line, but would admit that he doesn’t understand everything that goes on within it (to be fair, nobody understands everything even those who’ve been using the Linux command-line for over 20 years). And certainly when apt said “To install this package, I’m going to remove this long list of other packages”, the appropriately cautious should be saying “No” (and yes there is a prompt to allow you to do that).

The Linux command-line follows the principle that if the human wielding it wants to do something dumb, it may warn you but it will let you do whatever you want. That’s handy but scary and dangerous.

Now most users will likely veer away from the command-line – this is where Linus was a bit of an idiot – at least until they have a bit more experience. But perhaps those who make distributions should make the danger a bit more dangerous by adding a warning when opening the terminal (added to ~/.profile so we can remove an unnecessary warning) :-

WARNING !!!!

The command-line can be dangerous if you are not careful. Pasting in "recipes" found on the Internet for solutions to issues can result in serious damage to your Linux installation requiring re-installation.

In particular a recipe should be specific to your distribution and the version of the distribution you are running. 

When looking for solutions on the Internet, always bear in mind that there are idiots out there who will publish “solutions” that are anything but. As mentioned in my hypothetical warning, recipes are very often (especially when dealing with software installation) specific to a particular distribution and version – use it inappropriately and you may well run into serious trouble.

On the subject of gooeys, it would be handy to include a “Solutions” link when an error occurs in a software package manager that takes you to a web page specific to the package you are trying to install. Encounter trouble installing “Steam 6.23”? The solutions link might take you to a page saying “This package is out of date; please run Update”. This would allow links to be specific to the distribution and version in use – a lot more helpful than simply expecting the user to search the Internet for a solution.

King Alfred Looking Down At The Runners
Nov 062021
 

Someone asked me about this – a zsh function which I use to generate random passwords :-

✓ mike@pica» rpass noise
oOg6vsM+V0It4he6US4Xk6DuZPja9okyOpQyUCfW6NQ=
✓ mike@pica» rpass words
patternmaker+meio+tubicolous+misbelievingly

It’s too small and simple for me to classify as “open source” but there’s no harm in sharing the function :-

✓ mike@pica» which rpass
rpass () {
	case "$1" in
		("noise") dd if=/dev/random bs=1 count=32 status=none | base64 -i ;;
		("words") punct=("," "." "<" ">" "/" ";" ":" "-" "+" "=") 
			onep=${punct[$(($RANDOM % ${#punct[@]} + 1 ))]} 
			w1=$(shuf -n 1 /usr/share/dict/words | sed -e "s/'.*$//") 
			w2=$(shuf -n 1 /usr/share/dict/words | sed -e "s/'.*$//") 
			w3=$(shuf -n 1 /usr/share/dict/words | sed -e "s/'.*$//") 
			w4=$(shuf -n 1 /usr/share/dict/words | sed -e "s/'.*$//") 
			echo "${w1}${onep}${w2}${onep}${w3}${onep}${w4}" ;;
		("*") echo $1 not understood ;;
	esac
}

This is just a simple zsh function with all sorts of little “issues” – not least is that it could at least say “$1 not understood – try ‘words’ or ‘noise'”.

Oct 302021
 

Steam under Linux (and probably other environments too but I’ve never run it elsewhere) has a nice feature to enlarge text on high dpi displays. Unfortunately when I enable it, the pop-up windows (such as the settings window) will scroll down the screen repeatedly disappearing from view.

Which is very inconvenient and makes it quite tricky to turn the feature back off again. Now this could be a problem with the Awesome window manager or with the settings that I use (although Steam seems to be the only application with this issue), but I’m not interested enough to try and fix the problem.

I just want to change the setting back to something that may be small and squashed but at least works.

  1. Find the ~/.steam/registry.vdf file.
  2. Edit with a text editor and search for “DPIScaling” :-
» grep DPIScaling registry.vdf 
					"DPIScaling"		"1"

And change the “1” to a “0”, and restart Steam.

About To Break
Oct 302021
 

Ever since adding a couple of additional network interfaces to my workstation I have had a problem with reboots – the systemd-networkd-wait-online.service service “lingers” as it waits for all of the NICs to come online (and fails). Not especially problematic as everything works fine after the boot process has finished, but it slows down reboots (which are slow enough on this rather complicated desktop) and gives me an amber ✗ in my window manager’s status bar.

After spending some time re-jigging my storage (which consisted of far too many reboots), I finally decided to fix it.

Which basically consisted of making the relevant NICs “optional” in netplan. :-

    enp9s0f1:
      dhcp4: false
      accept-ra: false
      addresses: [172.16.76.0/24]
      optional: true

This isn’t one of the NICs that I actually use – I added the NIC configuration in an earlier attempt at making things work … unsuccessfully. The key part is the “optional: true” bit.

And whilst you’re in there, replacing the gatewayv4 and gatewayv6 specifications with the “new style” is worth doing too :-

      routes:
        - to: default
          via: 192.0.2.1
        - to: default
          via: 2001:db8:9c2:dead::1

(No those aren’t the real addresses)

This can be activated in the usual way – with a netplan apply (in my case a netplan try isn’t effective because of the use of bridges), although in this particular case a full reboot is called for.

The Round Table