Brief Review: Sharp 900W Standard Flatbed Microwave R360SLM

Very briefly, it’s a microwave, it works. Flatbed is convenient, and it has rubber suction feet which help keep it firmly planted where you place it, and it looks pretty good. However, using it is frustrating because:

  • The buttons are supposedly touch-sensitive, but require a slightly disconcerting amount of pressure to activate, unless you’re lucky and hit a very tiny special spot on the button.
  • Setting the cooking time is frustratingly tedious because the designers for some reason felt that once you start cooking, the only way to add time should be to cancel the program and start all over again with the newly desired time.

I’m baffled by how it’s possible that the people who bought and use this Microwave could give it such glowing reviews at Argos. I would personally rate it 2 stars for this reason, and I won’t buy it again given the chance.

Ubuntu 18.04 Chronicles: Creating a dnsmasq service

In Ubuntu Bionic, I found that the dnsmasq package no longer creates a service for dnsmasq that you can control with service or systemctl. After a fair amount of experimenting and some help from the friendly folk at #systemd on , I ended up with a dnsmasq service file that does the right things, namely:

  • wait for the LAN interface to be online (since my dnsmasq listens only on LAN), and then start the dnsmasq service.

Here goes the systemd unit file which you can place in /etc/systemd/system/dnsmasq.service :

Description = Self-created DNSMasq service unit file

ExecStartPre=/lib/systemd/systemd-networkd-wait-online -i enp4s0


Once you have created the service file, you must enable it with sudo systemctl enable dnsmasq.service . You of course need to make sure to use the correct device names for your system (my network device is listed by systemctl as sys-subsystem-net-devices-enp4s0.device). You can list all the devices systemd knows on your machine using systemctl -t device. Use grep to filter for your specific device (interface) name if you know what it’s called. Mine was called “enp4s0”.

The short summary of the above systemd unit file is that:

  • It is wanted by my LAN ethernet device, so it is launched when the device has been registered by udevd (or whatever subsystem handles this).
  • It’s of type “forking” because dnsmasq is a daemon which forks itself and you need this configuration for systemd to track it correctly.
  • In order to wait until the LAN is actually routable, I had to use the ExecStartPre (thanks #systemd) to use the systemd-networkd-wait-online application.
    • ExecStartPre just executes specified binary or script before it actually launches your desired process.
    • this application basically blocks until the specified interface is routable (which means it has an IP address).
    • You must use the full path to the executable.
    • Once it’s routable, then dnsmasq is executed (ExecStart), and dnsmasq by default will load the config file in /etc/dnsmasq.conf

Ubuntu 18.04 Chronicles: Applying firewall rules on startup, Pre-network

Another installment in this series. If you are used to dropping scripts in /etc/network/if-pre-up.d/ and seeing them get executed just before the network subsystem is up that’s another thing that doesn’t work in ubuntu Bionic, and you get no feedback that it doesnt.

Don’t panic though, because here I show you how to accomplish partially similar results. I say partially because my proposal here executes only on system boot, but that should suffice, because the firewall rules don’t disappear and need to be reapplied due to network status changes, and you will probably have other mechanisms in pace to deal with events that are related to network anyway.

The straightforward answer is that you now need to create a systemd service, which executes the script you would normally place in /etc/network/if-pre-up.d/. As a digression, despite the fact that systemd renders much of my previously acquired know-how useless, I actually like the logic of it’s design and so I hope that the new knowledge I’m acquiring and sharing here will be useful for long into the future.

Here’s my firewall rules script that I shamelessly adapted from Ars Technica: (the rules continue to be relevant to ubuntu Bionic, but the methods aren’t).

root@sol:/home/nucc1# cat /etc/network/iptables 
echo "Loading Firewall Rules..."


logger "ROUTER: WAN: $WAN, LAN: $LAN"

logger "setting up base iptables rules"

/sbin/iptables-restore <<-EOF





#global accept rules
-A INPUT -s -d -i lo -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -m state --state ESTABLISHED -j ACCEPT

#enable traceroute rejections to be sent.

You need to create a systemd unit file in /etc/systemd/system/ with the contents below (give it any name of your choice dot service, I call mine ‘router-rules.service‘):

Description = Apply base firewall rules for router functionality



It’s pretty easy to understand I think. Type=oneshot means, execute the script and don’t try to daemonise it or something. is the systemd way of saying to execute something just before the network is configured, which is Pre-Network.

Once this systemd service has been created, you need to enable it (otherwise, it won’t run at startup).

sudo systemctl enable router-rules.service

Et voilà! Next time your system reboots, the script will be executed, and your firewall will contain the rules it set. Notice that I designed my script to write messages to /var/log/syslog so that there is some record of it’s activity in syslog for me to review on this headless machine.

Ubuntu 18.04 Chronicles: Static DNS settings without Stub Resolver

The “new” way to configure your network in Ubuntu 18.04 Bionic Beaver is to use netplan files in /etc/netplan/ instead of the age-old /etc/network/ .

For some reason, /etc/network still exists and you get no warning that whatever you specify there will be ineffective.

Personally, I renamed the single file in /etc/netplan/ to something that has no bearing with “cloud” and then specified my preferred network configuration. I even removed cloud-init . Here is an example:

root@sol:/etc# cat /etc/netplan/55-network-interfaces.yaml 
            dhcp4: true

            addresses: []
            dhcp4: false
                addresses: [,]
    version: 2
    renderer: networkd

That sets one interface to DHCP, and the other one to a static IP address (there are two interfaces on this machine called enp3s0 and enp4s0).

Then you need to execute sudo netplan apply and that should apply your new configuration. It does apply except that there’s one potential catch: If you’re not using the built-in systemd stub resolver, then things don’t quite work (/etc/systemd/resolve.conf with DNSStubListener=No) since the /etc/resolv.conf file is a symlink to:


To fix this, I modified the symlink to point instead to the file that netplan automatically updates: /run/systemd/resolve/resolv.conf

sudo mv /etc/resolv.conf /etc/resolv.conf.orig
sudo ln -s /run/systemd/resolve/resolv.conf /etc/resolv.conf

Then the correct dns servers will be fetched from netplan whenever you execute netplan apply.



Ubuntu 18.04 Chronicles: removing cloud-init

You just deployed yourself a fresh copy of Ubuntu Server 18.04 Bionic Beaver. It should be the latest and greatest, and you just need a virtual machine to do some web development or perhaps you just want to enable IP forwarding and use this machine as a router. That’s great, except the latest Ubuntu assumes that you are part of the current trend to put everything in the cloud, and so ships with something called cloud-init.

No harm normally, but this wastes valuable seconds doing something you don’t need if you’re not in the cloud. It’s easy to remove this package by following the (modified) instructions here: :

  1. dpkg-reconfigure cloud-init
    1. Then deselect all the options except None
  2. sudo apt-get purge cloud-init
  3. sudo mv /etc/cloud/ ~/; sudo mv /var/lib/cloud/ ~/cloud-lib
    1. I prefer to move, rather than delete, in case something goes wrong and you wish to restore the files.

When you remove cloud-init following those steps, your machine stops booting and there is apparently a service that is waiting for network to be up. This would normally be just an inconvenience, but the boot hangs indefinitely waiting for said network. Odd choice of configuration out of the box, but anyway, you can fix this by:

  1. List the services which depend on network being online.
    • sudo systemctl show -p WantedBy
  2. This will list the culprits as some iscsi services that you probably don’t need.
  3. Disable the services
    • systemctl disable <service name

That should do to get the system booting without some service waiting endlessly for a network connection.