darkness

Check out this article on Windows 2000 authentication under “Basic SNTP operation.”

Started to move OpenLDAP and my LDAP DB to OpenBSD today… and I think I may have basically finished. The directions in this OpenBSD/Cyrus IMAP HOWTO for installing OpenLDAP were pretty much what I was interested in. Particularly the slapcat and slapadd commands worked wonders. A lot of tests in the LDAPv3 HOWTO don’t work since they assume SASL madness, and I’m not sure the OpenLDAP distributed in 3.3 packages includes this functionality.

I don’t particularly care. SSL seems to work. I can bind to it with GQ. I need to test to make sure my Red Hat clients can use it for name services like they have been. After that, we’re good.

BTW, if you’re looking for the list of symbolic names for ICMP types in pfctl, you apparently need to go to the sources: sbin/pfctl/pfctl_parser.c.

I’ve decided to move a few of my security-conscious services over to an OpenBSD box. Today I moved my Kerberos domain.

A quick note. OpenBSD is fun. It’s kind of nice to get back to not feeling like your system might be laden with cruft you won’t use. Of course, I got annoyed that I didn’t have a simple ntp.conf, for example, to start with. I also hate the way init is laid out; give me SysV-style init any day.

So Red Hat 8.0 ships with MIT Kerberos V 1.2.5. OpenBSD 3.3 ships with Heimdal. I followed the instructions for setting up a Kerberos V server in the Red Hat 8.0 manual when I did this originally. All the paths I give pretty much depend on you configuring things like they’re described there.

First, kdb5_util dump -b7 -verbose krb5-dump as root on the Linux box. This gives you a krb5-dump file. This, combined with /var/kerberos/krb5kdc/.k5.YOUR.REALM (where YOUR.REALM is really your Kerberos realm name) will need to be copied to the OpenBSD box. krb5-dump is a dump of all your principals, and the .k5… file is your “master key stash.” I think. If you don’t use -b7 to dump in what appears to be a slightly older format, the Heimdal tools won’t understand the dump.

Now hop on over to your OpenBSD box and create /var/heimdal, root:wheel, 0640. Next, /usr/libexec/hprop -m the-stash-file -d krb5-dump --source=mit-dump -n | /usr/libexec/hpropd -n on the OpenBSD box. Note that hpropd needs to be run as root as it’s going to write out your database, so if you’re a fan of running as a regular user and using sudo, tack sudo in front of hpropd. Now move the stash file to /var/heimdal/m-key and make sure that file is 0640 root:wheel. By now you hopefully have /var/heimdal/heimdal.db from hpropd.

You’re pretty much done at this point. You need to configure /etc/kerberosV/krb5.conf; there’s a sample file in that directory as well. Don’t forget to create a host principal for your KDC if you need one. Instructions for doing that are in info heimdal and krb5.conf(5). You can run verify_krb5_conf and get a little help making sure your krb5.conf is at least possibly OK. You probably want a /var/heimdal/kadmind.acl file, also described in the Heimdal info pages. You also probably want krb5_master_kdc=YES in /etc/rc.conf.local.

One more note about OpenBSD, unrelated to Kerberos. Here’s information on the stable branch of OpenBSD, packages fixed in 3.3-stable, OpenBSD anonymous CVS instructions, and if you want to know what’s changed in -stable you need (I think) the OpenBSD errata. (Honestly, this is more for my future benefit than yours. Sorry you had to sit through it.)

I was checking out the paranoia option for CDRDAO earlier today and I found that it actually uses cdparanoia-lib or some such. In other words, CDRDAO uses some, if not all, of the same code for ripping audio as cdparanoia. Just an interesting note. I’m still not ripping my audio CDs to one big assed FLAC file.

I was kind of tired tonight after seeing Terminator 3: Rise of the Machines but I had eaten too recently so I didn’t want to go to bed. I played a bit of UQM but that got kind of boring — especially since I can’t play my saved games on PPC. Then I remembered all the fun I used to have with an old game I played on my PC. You were given a graphical arena, and you had to program a bot using a Pascal-like language. (I’m not sure if this was PRobots or not.) I went looking for something similar that would run in Linux/PPC, was graphical, and preferably gave me my choice of language.

My first choice of language was Python, and I found pRobots. P.S.: this name is already taken by Pascal Robots, I think. There’s also war, another Python robots game; I’m just not sure how complete/working it is. Both of these projects don’t look like they’re still being developed to me, but who knows? Maybe they don’t need to have continuous attention.

Next I did a bunch of searching. I found the Programming Games category on Google. Lots of dead programs, lots of programs for Windows only, or Linux/x86 (implicitly) at best. Even a few commercial programs, which kind of surprised me: I didn’t think there was enough of a market for this kind of game, really. In the end, I came down to about three more candidates.

The first is GNU Robots. GNU robots uses Guile for programming the robots, I think, so not exactly your choice of programming language. Still, I’m OK with Scheme – even interested in it, really. I think it has a graphical interfaces, xrobots, but I didn’t look too hard — and I especially didn’t try to build it. Hasn’t been touched in a while, I think.

Next up is RealTimeBattle. This game lets you use any programming language you want, I believe; robots communicate with the server via stdin/stdout. Hasn’t been touched in a while I think. Looks promising, though.

Last is Cadaver. I’m not entirely certain, but I think the idea is that you’re a Cyborg race and you have to procreate. This one sounds interesting because it’s not the usual blowing-shit-up kind of thing. Communication is done with the server via TCP/IP, so any programming language. Graphical interface indeed, if perhaps a bit ugly. No turns: your commands are issued as soon as they’re received, supposedly. Makes me wonder if one bot could monopolize the entire server.

There were a few other candidates. There was RoboCom which might work on Linux/PPC, if I can get all the Java stuff pulled together. It’s got its own language, though, kind of assembly-like. C++Robots might be neat… if it had a graphical environment. XPilot++ mentioned something about robots, but I’m really not sure if this is related or not; I just put this here because I seem to recall XPilot being cool.

I think my first try will be with RealTimeBattle. If I ever get around to giving this a whirl I’ll post.

Monkey’s Audio beats FLAC, sometimes marginally, on compression while maintaining relatively close encoding time. Other lossless codecs might compress better, but have much higher times. At least, this is what I learned by looking at the FLAC comparison to other lossless codecs at the FLAC site.

NeroPlugins.cd-rw.org has lots of audio plug-ins for Nero, including a FLAC plug-in. Now I can burn straight from Nero, and I don’t have to worry about the quality of its MP3 decoder. (Hopefully the decoder provided at that page is making straightforward calls to FLAC’s code, and was compiled with a decent compiler. … Suddenly I’m not feeling so confident.) The people at the Hydrogen Audio forums seem to think that APE 2.0 tags are better than ID3v2, or at least that’s my impression after doing some reading.

Another thread on Hydrogen Audio where people talk about archiving with FLAC to CD-R they mention (a) storing PAR information with the files, and (b) storing cue sheets. (Or is that CUE sheets?) The idea with PAR sounds kind of neat, assuming it won’t be that much overhead. However, the CUE sheet idea made me look in to it.

If you want to make an accurate copy of an audio CD, even those ones with nasty hidden tracks in the pregap or whatever, you need a cue sheet for that CD apparently. I thought I could make such a cue sheet with CDRDAO, but it looks like it has to actually step through the whole CD — augh! It doesn’t seem to do it too speedily either. Then I found out that CDRDAO doesn’t actually make a cue sheet, but its own format (TOC). Indeed I can’t find a program to make a cue sheet by reading a CD in Linux. Moreover, it seems most of the people that do this actually archive their entire audio CD into one big WAV/FLAC file. Though apparently foobar2000 and WinAMP with the WinAMP mp3cue plug-in or something similar might be able to play from this format, it seems kind of unacceptable to me. (Aside: a similar plug-in for XMMS may exist, from a glance at some Google results.) This WinAMP plug-in (for example) looks like it makes a separate playlist, and I bet the UI on that isn’t as nice as the built-in playlist. I kind of like having tracks in separate files anyway. It might be possible that cdparanoia is going to rip the whole CD, pregaps and all, and I could still rebuild the CD if I had the cue sheet. Until I find a better way to make the cue sheet, though, no cue sheet for me. I hope I don’t regret that choice in the future.

I really went to Hydrogen Audio for some discussion on optimum FLAC flags, since Abcde is using a whole bunch of flags I’m not familiar with. I didn’t find any of this discussion. However, I did find information on the --super-secret-totally-impractical-compression-level flag for FLAC. So maybe the night wasn’t a total waste.

…

Random page with lots of links to specifications for various CD and related stuff.