update gnubee debian jessie to buster

thanx to https://feeding.cloud.geek.nz/posts/installing-debian-buster-on-gnubee2/

Upgrade to stretch and then buster

To upgrade to stretch, put this in /etc/apt/sources.list:

deb http://httpredir.debian.org/debian stretch main
deb http://httpredir.debian.org/debian stretch-updates main
deb http://security.debian.org/ stretch/updates main

Then upgrade the packages:

apt update
apt full-upgrade
apt autoremove
reboot

To upgrade to buster, put this in /etc/apt/sources.list:

deb http://httpredir.debian.org/debian buster main
deb http://httpredir.debian.org/debian buster-updates main
deb http://security.debian.org/debian-security buster/updates main

and upgrade the packages:

apt update
apt full-upgrade
apt autoremove
reboot

Configure Ubuntu 18.04 with grub2 to activate serial console

Thanks to hiroom2

1 /etc/default/grub

  • Change GRUB terminal to console and ttyS0. This will provide one GRUB to a monitor display and serial console.
  • Change linux kernel console to tty1 and ttyS0. This setting will be taken over to userland, and there will be two login prompt for tty1 and ttyS0.
GRUB_CMDLINE_LINUX="console=tty1 console=ttyS0,115200"
GRUB_TERMINAL="console serial"
GRUB_SERIAL_COMMAND="serial --speed=115200 --unit=0 --word=8 --parity=no --stop=1"

Wireguard scenario workstation -> vpn gateway -> private network

I’ve moved a rather hacky tinc mesh vpn solution to wireguard, all set up through an ansible playbook. the topology is rather classic:

my workstation (laptop, changing network situation) connects as a ‘client’ to two wireguard ‘servers’ as vpn gateways which are publicly accessible bastion hosts, and who also are members of a private subnet to which they ought to give access. the specific nodes are cloud instances of each Hetzner cloud and Vultr cloud.

Hetzner recently started to provide private interfaces to their cloud instances, currently the private addresses seem to be given randomly when using the cli tool, but can be specified also via their website interface. Vultr has that service already longer, however, the private ip cannot be specified and is assigned at random.

the above used terms ‘client’ and ‘server’ are a bit anachronistic, as Wireguard does not make such a difference. the ‘servers’ merely do not get endpoints to their peers in their interface configuration, as they do not initiate connections.

Generally, when running a linux vpn gateway that connects two interfaces into different subnets (here wg0 is the wireguard interface, ens10 is the interface to the cloud provider’s virtual router and a self configured private subnet) one only needs to set /proc/sys/net/ipv4/ip_forward to 1 and /proc/sys/net/ipv6/conf/all/forwarding to 1 and be done with it. The nodes in the private subnet possibly need some way of receiving the necessary route back to that vpn gateway, via some routing protocol or static routing.

I was not able to set this up neither on Hetzner, nor on Vultr, and had to instead set up NAT on the gateway via iptables, as advised here in this tutorial, by the way a good reference on how to set up Wireguard: https://angristan.xyz/how-to-setup-vpn-server-wireguard-nat-ipv6/

My theory is that the virtual routers of the cloud providers are filtering this kind of traffic, as i can see the packets running through both the wireguard interface and the private subnet interface on the vpn gateway, but cannot see them at the final node’s interface. But i could be entirely wrong.

subtle changes in key format of key pairs generated with `ssh-keygen` on linux

I just came across an unexpected ssh key subtlety you might want to consider while creating a drone ci deployment pipeline using drone’s ansible plugin.

Part of the pipeline includes deploying code to a remote host via ssh. I generated a new key pair with ssh-keygen. This created a key with openssh new format starting with:


-----BEGIN OPENSSH PRIVATE KEY-----

Apparently ansible does not like this format and on the “Gathering facts” step erred out with the message “Invalid key”. Googling that was not very successful, and I could not find that particular message in the ansible source, until i eventually found an unrelated closed issue on github which pointed me towards possible problems with key formats.

Eventually i generated a new key pair like so ssh-keygen -m PEM, the -m option setting the key format. The key then had the starting line


-----BEGIN RSA PRIVATE KEY-----

As far as i understand both keys are actually RSA keys, the latter’s PEM format being implied, whereas the former uses some new openssh format i was not previously aware of.

Earlier runs of ssh-keygen did produce keys in the PEM format and as i am running Archlinux with OpenSSH_8.0p1, OpenSSL 1.1.1c 28 May 2019

One of the rolling updates to my system probably brought along this unexpected change.

Hope that helps somebody.

Compile Go on MIPS/MIPS32

I’ve been trying to compile go programs on the gnubee which runs on a mips architecture.

Found this on github:

I have successfully cross compile go program into mips32 bin with below command, you may try this also.

GOARCH=mips32 is for ar71xx, change to GOARCH=mips32le if it is ramips.

cd
git clone https://github.com/gomini/go-mips32.git
cd go-mips32/src
export GOOS=linux
export GOARCH=mips32
sudo mkdir /opt/mipsgo
./make.bash
cd ..
sudo cp -R * /opt/mipsgo
export GOROOT=/opt/mipsgo
export PATH=/opt/mipsgo/bin:$PATH
vi helloworld.go
go build helloworld.go

 

thanks, bettermanbao

chroot and serial console to fix ubuntu distro upgrade gone wrong

I had to fix a do-distro-upgrade from 16.04 to 18.04 due to a severed ssh connection, and no screen running (apparently earlier distro upgrades used screen to prevent this kind of problem)

the machine as a PCengine apu2, so no video. also, the root file system is sitting on a miniPCI ssd.

eventually, my thinkpad x230i, and this chroot cheatsheet helped: https://aaronbonner.io/post/21103731114/chroot-into-a-broken-linux-install

mount the root filesystem device

$ mount -t ext4 /dev/<device> /mnt/

if there’s a different boot partition or anything else

$ mount -t ext2 /dev/<device> /mnt/boot

special devices mounts

$ mount -t proc none /mnt/proc
$ mount -o bind /dev /mnt/dev
$ mount -o bind /sys /mnt/sys

chroot

$ chroot /mnt /bin/bash
$ source /etc/profile

In order to help troubleshoot in the future, i followed this advice to get a systemd service unit for a constant shell on the serial port, but mine runs for some reason on S0:
http://0pointer.de/blog/projects/serial-console.html

# systemctl enable serial-getty@ttyS0.service
# systemctl start serial-getty@ttyS0.service

It won’t help if systemd does not start, but otherwise it is online really early.

Install and monitor skypool’s Nimiq client via ansible playbook, systemd and ruby & cron

INTRODUCTION

This is a short entry to document installation and monitoring of the skypool nimiq client. The Nimiq network is a decentralized payment network that runs in the browser and is installation-free.

Personally, i believe that the Litecoin and Ethereum projects have been so far able to generate a strong economy around them, however, projects like Nimiq definitely convince me in terms of usability and simplicity approach to the user.

CONTENT

I am considering Ubuntu 16.04 as base operating system.

The playbook does the following things:

  1. Install the necessary dependencies
    ruby-dev for ruby 2.3, ruby gem package manage
    unzip to handle the release file from github
  2. Create a specific user nimiq and a program directory /opt/nimiq
  3. Download and unpack the release file from github under a version-specific directory below the program directory
  4. Create skypool client configuration file according to your demands and with your wallet address
  5. Create a systemd unit file, start the skypool client as a service and enable restart on reboot
  6. Create a status checker that uses the skypool api to check the worker’s online/offline status
  7. Create a crontab entry for the root user to run the status checker every ten minutes

REMARKS

cron

The cron entry running every 10 minutes is a tradeoff on how brittle the online/offline check delay currently is experienced by me through the skypool site. Presumably skypool does not have a real heartbeat check towards the worker but assumes that the worker is online when it receives results from it, and subsequently assumes the worker to be offline if it does not (most pools in the cryptocurrency world work like that). That means in terms of perfect time period between checks, your mileage may vary.

systemd

The service runs currently under the user nimiq, hence a non-privileged user of the system. However, the systemd daemon used is the one from root. Hence only the root user can restart the nimiq service. For this reason, the cron entry is registered through the root user. If you want to be able to use the nimiq user to restart the nimiq service, you have to run a systemd daemon based on the nimiq user. I have successfully done that for another service playbook, and I might add this information in the future, if demand is voiced.

GIST

Find below the full gist as published on github. Full gist here.

Installing ubuntu per minimal image to PC engines APU2

This is the company: PCengines
This is the devices: APU2

nullmodem setup

using putty

Check which com port, mine was set to ‘com4’

Get a usb to serial converter, install drivers. Some of those converters seem to have timing problems, but i did not encounter that.

I once tried lowest baud rate 9600 and that produced some nice screen carnival, but nothing really legible.

prepping usb stick

Download usb prep tool ‘TinyCore USB Installer‘ and run it against on usb, i’ve used an 8GB stick, make sure it’s not the slowest

To try out you can now boot into TINYCORE. So put this into the APU2’s usb port and boot up having the serial nullmodem cable connected and the putty session open. Finished boot is indicated by an audible beep. This is good to check the serial connection which you should have established parallel to that.

If you want to keep the option of booting into TINYCORE open, backup the syslinux.config fom the USB’s root directory, as this one will be overwritten by the package content we are now downloading.

Download special ubuntu package from pcengines, unpack and move the three files into the usb root folder / or :/ depending on your system.

Now plug in the usb into the apu2 and boot having the serial nullmodem cable connected and the putty session open. You will see the setup menu, similar to this screen shot:

The terminal setup process seems daunting at first, but it essentially is really analogues to the graphical ubuntu installer. I found my way around by basically following the Easy Path(tm) of most of the suggestions of the installer, going automatically step by step through the menu. On some of the sub menus i was able to make some educated changes as i knew a bit of more details and i had a good idea where i want to go with this system, but this might not apply to you.

The one exception was the network configuration. running the automatic network detection seems to have got the dhcpd info , but when i dropped into the busy box ash shell environment (one menu option Execute a shell in the main hierarchy at the beginning of the installation process), i had to run dhclient directly on the interface again. Checking via ip addr i now could verify the indeed applied values, and could ping any public server. With exit i dropped back into the installation menu. On a later second setup run this problem did not occur again.

I chose no automatic updates as i can see the cronjob using quite some resources. I’d rather manually schedule that for this particular system at them moment. Part of the minimum running service policy of mine for this instance.

I followed some tip regarding the bootloader installation, and it apparently solved my problem of an unfinished installation before. I lost the link, but it boiled down to manually enter the first partition of the setup target (pcie flash device in my case), so that was /dev/sdb1 as opposed to /dev/sdb. Again, this might be different for you.

Once that was done, and with a bit more patience i rebooted and eventually login via ssh could be established. I then halted the machine, physically unplugged the usb key and the console, and replugged power.

After about 45 sec ping answered and after than ssh came back online.