The other day I got my geeky hands on two old SuperMicro X8STI-F 1U servers. I plan to use them as build and embedded target emulation servers for my open source projects as well as Minecraft server for my kids :)
This is a very brief writeup of how to upgrade the BIOS on a X1 Carbon (G1) from Linux. For more information on this topic there is always the excellent ThinkWiki.
OK, this post is more about creating the bootable USB stick needed, was too much of a chicken to try Flashrom …
Recently I needed a simple TCP/UDP port redirector and stumbled upon
this Stackoverflow post. As usual I wasn’t first wanting to this
without using iptables.
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
complement 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 uredir into redir. We’ll see, right now though
I have several other projects to attend to :-)
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 /var/run/daemon.pid, or /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
properly on SIGHUP (if they support SIGHUP that is). When I send
SIGHUP to a daemon I expect it to re-read its /etc/daemon.conf and
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.
Days like these inconspicuously start out just like any other day,
except on days like these you accidentally manage to erase $HOME and
have no real backup to rely on … Maundy Thursday will forever be Black
Thursday for me, from now on.
Best thing your can do, after cursing at yourself constantly for a couple of hours, is to:
BUT FIRST – QUICK – UNMOUNT OR POWER-OFF YOUR COMPUTER – PULL OUT THE BATTERY – AND STEP AWAY FROM THE COMPUTER! Must protect the partition from being accidentally written to – I completely fumbled this step, so take heed young people!
Recently issue #70 was
reported to pimd. That number of
issues reported is cool in itself, but this was a question about
Docker and pimd.
Up until that point I had only read about this new fad, and played around with it a bit at work for use as a stable build environment for cross-compiling. I had no idea people would want to use a Docker container as a multicast sink. Basically I was baffled.
The reporter used a Java based tool but simply couldn’t get things to
work properly with pimd running on the host:
eth0
MC sender ---> [ Server host ] <--- router running pimd
|
________|________
/ docker0 \ <--- bridge ______
/ | \ | | <--- MC receiver
__________/ | \_______________|______|_____
\ | / /
\ `------------------>-------' /
\________________________________________________________/
Container ship
For the better part of the last ten years I have been working with
multicast in one way or another. I’ve used many different tools for
testing, but on most systems I usually resort to ping(1) and
tcpdump(1), which are quite sufficient. However, you often need to
tell bridges (switches) to open up multicast in your general direction
for your pings to get through, so you need to send an IGMP “join” first.
Way back in 2006 I stumbled upon a neat tool called mcjoin, written by
David Stevens and announced in
this posting to LKML. I started
improving and adding features to it over the years.
Had an interesting conversation with a buddy last night. It started out as a shift-reduce problem with Bison and ended up a ping-pong of useful UNIX API:s. We concluded that despite having worked professionally with UNIX for over two decades, it is still very satisfying finding gems like these.
Most people are completely unaware they exist and end up rolling their
own (buggy) implementations. For instance, string manipulation and
various forms of linked lists. Which is why I many years ago extracted
the frog DNA from Finit to a
separate library called libite,
or -lite for short. It imports the OpenBSD strlcpy() family of API:s,
up-to-date queue.h with the _SAFE iterators, and more. Some people
like libbsd for this, but I’ve
found many of the ports incomplete and unsafe and prefer to stay closer
to the upstream *BSD versions.
Update: This post was originally written Nov 14, 2015. It was a Saturday and I remember being extremely inspired when I wrote it. I’ve continued adding to it over the years, and still do. So, as of Jul 2, 2017 I’m bumping the modification date each time I add something new :-)