ARM Toolchain r1
Finit3: Almost there ...
Today the new logo for Finit3 was added to the GitHub repo and the homepage
Gorgeous, isn’t it?! 😎
This fancy artwork means we’re nearing the end of a long and agonizing release cycle where a lot of the internals of Finit have been rewritten and new exciting features have been added! More on this in an upcoming post 😃
The General Idea
Live KVM migration with virt-manager
With the new servers and my server room shaping up, I’ve been working on setting up ALL THE THINGS! I just managed to set up live migration of the KVM virtual machines I use for testing my FLOSS projects. Here is a short writeup of that, just as a reminder for myself.
- Make sure the libvirt versions are the same. I tried setting up migration between CentOS 7.2 and and Ubuntu LTS 16.04 which turned out to be a mess of insurmountable incompatibilities. I’ve now gone back to run Ubuntu on everything and it all works fine.
- Set up NFS for the backend store of
/var/lib/libvirt/images. Make sure to export the share properly, I tried first with my ReadyNAS, but couldn’t set up root access (defaulted to nobody).
- Set up VM disk caching=none
- Set up VM processor model=default
Good Luck! :)[Read More]
Fake RAID Adventures
Upgrade X1 Carbon BIOS from Linux
Redirecting Ports For Fun and Profit
Recently I needed a simple TCP/UDP port redirector and stumbled upon
this Stackoverflow post. As usual I wasn’t first wanting to this
There were several alternatives, but since my target was embedded with
limited amount of RAM and flash I wanted something really small. So the
best fit turned out to be redir, which unfortunately only could
handle TCP connections. This is what led me to write uredir to
redir. Eventually I ended up adoptiing
redir as well,
which meant giving it a bit of a facelift and to give them both the same
look and feel.
Currently they are two separate applications, which in some use-cases
can be beneficial (small size), but I may in the future transplant the
UDP functionality of
redir. We’ll see, right now though
I have several other projects to attend to :-)
Using netcat to test your Internet daemon
The key to successful boot
How do you know when your UNIX service (daemon) is ready? Simple, it
has created a PID file, signalling to you how to reach it. Usually this
file is created as
/run/daemon.pid, and has
the PID of
daemon as the first and only data in the file. This data
may or may not have a UNIX line ending.
Only trouble is: most UNIX daemons do not re-assert that PID file
SIGHUP (if they support
SIGHUP that is). When I send
SIGHUP to a daemon I expect it to re-read its
resume operation, basically a quicker way than stop/start.
Annoyingly however, most daemons do not signal us back to tell us when
they’re done with the
SIGHUP. Naturally a new movement has risen that
says we should all instrument our daemons with D-bus … I say no.
Simply touch the PID file instead.