<ARCHIVE> Wilmer's stuff

As part of upgrading my machines from Jessie to Stretch, I finally had to pick up Puppet 4. My hosts running testing were trying to do so for a while already, but since Puppet requires the master to be newer than the agents, I've always just had a pinning rule in place to stick all machines to Puppet 3.x.

It's been quite the operation and I'm not done yet, but let me write down some of my findings for others to maybe use. As always, there are many different ways to achieve this goal, there are existing docs, but they're all outdated in one way or another. (As surely this one will be in a year.)

Continue reading "Puppet 4 on Debian 9 Stretch with nginx (with Puppet 3 agents if needed)"

So I have this fun hobby for a while already, flying.. I have around 50 hours logged by now in the US + Ireland, which means I can more or less land safely now, on my own. In fact I had my first solo in October last year which was an absolutely amazing experience. But sometimes weather just doesn't work with me here in Ireland (either too windy or too cloudy) and instead I go "flying" with X-Plane on my machine at home.

Now X-Plane is a pretty neat simulator, and as long as you use it with a real yoke/stick and not keyboard/mouse, it seems like a useful way to practice. But there's one way in which a flight simulation projected on a single screen, no matter its size, just doesn't beat sitting in a cockpit: the inability to look around in any direction by, you know, just turning your head. Instead, joysticks often have this hat switch on the top to look around. Unfortunately in Linux, the joystick driver gets told that the hat switch is a mini-joystick that the user can move up/down, left/right. Instead of just representing it as four separate buttons (which is what they really are anyway, hardware-wise). X-Plane and apparently other flight simulators can't use this, they need buttons.

This week I wrote uhat to solve this problem. It'll listen to joystick events and if you move the hat switch axes, it will generate button events on a separate virtual joystick device. There's a similar tool called jhat, which generates keyboard events instead, but I never really liked the idea of my joystick pretending to be a keyboard and hoped there were a better way to do this. A week ago I found my answer in uinput. It's poorly documented, but fortunately very simple to figure out. It looks like uinput is just a fairly 1:1 translation of the input subsystem kernel interface into a character device.

It works like a charm for me, with the udev rule I don't even have to think about it, udev will just start it for me when I plug in my joystick. Hugely enjoying X-Plane 10 again. :-D

Spent an hour or so this morning wondering how to get my Debian initramfs to activate my LUKS-encrypted partition with --allow-discards. I know it's less secure, but as long as wrenches are still cheap I'm fine with sub-standard security if it means my hardware will perform better for longer. :-)

The trick is to add a flag "discard" to your crypttab, like this:



And then of course rebuild your initramfs (update-initramfs -u) and reboot, etc.

You do need cryptsetup 1.4 or higher for this to work. I had to manually install that package (only twenty or so days old) from sid on my testing laptop.

Because Intel on-board video isn't quite good enough at 3D and my somewhat old laptop with built-in NVIDIA chip wasn't doing all that well at X-Plane either, I bought an NVIDIA GT240 card. Mostly because it seemed to be a good performer without doubling the power consumption of my PC. Stuff wasn't working all that well though and I got pretty frustrated:



was all X-Plane could tell me. Google Earth also didn't work and seemed more like Google Black hole to me. Both are 32-bit apps. A 64-bit binary of Flightgear did work. Sigh.

After some poking I noticed the nvidia-glx package replaces /usr/lib{64,}/libGL* with its own versions, but didn't touch /usr/lib32. A-ha!

The fix: Get a 32-bit version of nvidia-glx, extract it somewhere (dpkg -X) and copy all the files in its usr/lib to /usr/lib32, overwriting the libGL symlink that is currently there.

Or, hmm, as I just found out: apt-get install nvidia-glx-ia32. I'm glad someone thought of it already.

Now X-Plane works perfectly (with maybe even ten times the frame rate I had with Intel on-board) and Google Earth can show me my house again.

Just blogging this since so far a Google search for any part of the error above didn't give useful results.

Now, I just have to find out if I can get a TV signal out of this thing somehow, since my TV was made long before HDMI was invented. :-/

So for about a year I have a DSL modem and a separate router (running OpenWRT) here. Simply because the average DSL router has crappy software (no decent CLI, connection tracking for nothing more complicated than TCP and for only a few hundred of them, crappy wireless ... well, you get the point). So I decided to buy a Linux-powered DSL router, the Netgear DG834G. I hoped for one with an AR7 board, because that one seems very well supported, but I received a v4 which has a Broadcom board instead. :-(

Anyway, Netgear is still pretty decent. The stock firmware comes with a telnetd (must be activated via the webserver though), and (well, forced by the GPL) they put tools on-line which I can use to rebuild firmware images, which I already abused to remove the multi-lingual web interface and use those precious kilobytes for a tcpdump binary instead. :-) Adding a kernel with IPv6 support is going to be more complicated though.

Anyway, I should first focus on making the thing actually wortk with my IPoA ADSL2+ connection.... sigh

But after bricking the thing once I did manage to write up a tool (based on a half-finished tool written by someone on the OpenWRT forum) to fix that very problem. These routers can be reflashed without any serial cable or whatever these days, using the power of raw Ethernet frames (R). It's a gross hack, but it works and is reasonably convenient. It's up for download for anyone who needs it. Be careful, only use it when things can't get any worse anyway!

Now that my (and pretty much every other) machine uses UTF-8 by default, I was pretty much forced to ditch rxvt in favour of rxvt-unicode. Unfortunately the rxvt-unicode authors think attaching some keycap picture insert mode to the Ctrl-Shift key combination (which is easy to hit by accident) would be HANDY. Even handier, it can only be disabled at compile time.

Thanks for nothing guys, I really hope there's at least one person on this planet who agrees that this is handy ... I'm afraid most people who accidentally hit Ctrl-Shift every few minutes don't agree.

So, behold:


For all you Debian+rxvt-unicode users out there waiting for this bug to be fixed... :-)

[edit]Added dch command to make sure apt-get doesn't reinstall the original package every time.[/edit]

Got a little bit confused by this bug report while trying to get the TV-out on my mainboard working properly. As any European TV, mine wants PAL signals, not NTSC. The bug report gave me the impression that there should be separate PAL/NTSC mode definitions. But in the current driver, this isn't the case anymore.

Instead, they now use RandR properties to maintain this setting. And RandR, at least for properties, seems to be read-only .... soooo, how does it work then???

Well, try something like this:


Took me a whole weekend to find this, but at least it works now, in full colour! This didn't seem to be very well-documented to me, so I hope this post will help. If it doesn't work for you, maybe your TV doesn't understand S-Video. There's a very simple hack to solve that issue too. All you need is two wires, no need to solder anything. :-)

Thanks for making Linux drivers for the on-board graphics stuff on my mainboard. Next year, could you please not publish them as a .... .EXE file???