Entries from January 2005.
Firewalled off from NTP? HTP to the rescue!
HTP is not really a protocol, but uses a feature from HTTP, aka web traffic. According the specifications of HTTP (RFC 2616) a web server needs to put a timestamp in a response to a web browser request. In web browsers you don't see the HTTP headers, but these headers contain a timestamp in Greenwich Mean Time (GMT), accurate in seconds.
Available in Perl or C. My compliments to Eddy Vervest.
I found a link on Gecko's blog to Project Honeypot. Turns out it's a project to watch for, and attempt to track, spammer-run robots that scrape pages for email. I was intrigued, but a little put off by the terms of use. I did a big more digging around, and found I wasn't the only person who thought that way. However, there were some strong rebuttals from the SpamCop forums, discussion on SURBL mailing list, and from one of the principals (who also replied here).
Reassured, I signed up. It's still in the early stages, so there hasn't been a lot of spam received yet (350-odd pieces, according to the stats page on the site). Still, I'm hopeful it'll be a Good Thing.
Another approach: a Java SMTP honeypot. Huh.
We're going to switch from CVS to Subversion at work. I don't make a whole lot of use of CVS, so the finer points of change management are more academic to me than anything else. But authentication...ah, that's a different story. Right now, Unix clients access the CVS repository by NFS; Windows users use the pserver protocol/authentication. NFS access does cause some problems for CVS, but it's completely out of the question for Subversion if you use their Berkely DB filesystem. It's okay for read-only access if you use their FSFS (actual real filesystem files filesystem; the equivalent of CVS' bunch of directories and files). This leads to questions about how we'll allow access over the network, and how we'll authenticate users. Here's my thinking so far.
I think I can do Daemon + FSFS, but I need to reread the Subversion book (truly excellent, BTW). This might be the best way to get things going quickly. And of course, any insights or hints are welcome.
Okay, so as I mentioned I'm trying to get a Subversion repository working in a way that a) keeps the repository safely on an NFS-exported, mirrored set of drives, and b) does not require YAFPF. Today I've been banging my head against Apache2 + mod_auth_pam. The problem is that while passwords are successfully checked (hurray! one less FPF!), group membership is not. this does not work:
AuthPAM_Enabled on
AuthPAM_FallThrough on
AuthGROUP_Enabled on
AuthGROUP_FallThrough on
AuthType Basic
AuthGroupFile /etc/group
AuthName "secure area"
Require group subversion
(For one brief, spastic moment I thought Satisfy any was the missing
magic. Then I tried it without typing in a password. Sigh.) We're
using FreeBSD and NIS; from what I've been able to find so far, that
might be problematic. OTOH, I might have the entirely wrong idea about
PAM and its ability to check group membership.
UPDATE: Logical as it seems, AuthGroupFile has no place in the modern kitchen. Removing that directive allowed everything to work. Whee!
Sat down tonight to create a firewall for a new OpenBSD web server I'm
setting up, and holy crap is pf ever good. I got to test the
firewall syntax before loading it, and as a result I had a working
firewall the first fucking time I loaded it. That's never happened
before; I full expected that this time, as every other time with a new
firewall (let alone a new firewall language!), I'd have to reboot or
log in with a keyboard or serial cable, or something.
But no: not only did I not lock myself out, not only was this the first time (well, nearly) that I'd read the FAQ, the firewall does everything I wanted it to: no extra packets in, no extra packets out. Wow.
Alioth was right: pf just rocks.
So I went out today and got a MAX 232CPE and a MAX 232N, plus assorted wires and whatnot, in an attempt to get a serial port connection to the NWR04B. Got a couple wires soldered to the board, hooked up a CPE to a breadboard with some capacitors, distressed a null modem cable, and....
Well, results were decidedly mixed; minicom eventually showed some chatter, but nothing intelligible, and only when I rubbed two wires together. (Cue jokes here.) At least I know the level shifter is working (I was worried I'd picked up the wrong size/value/faradicitousness of capacitor), but it's frustrating not to see anything I can recognise (like, you know, some ASCII, or "press 1 to boot Linux"). Plus, I suspect I'm only seeing static coming from the connection, rather than anything from the damn board.
Argh. Hints more than welcome, but dumb them down; this is about the sixth time I've soldered anything.
Had an interesting couple of problems at work this week.
First thing was a FreeBSD system where, suddenly, ipfw didn't work anymore. Only "suddenly"'s not exactly true: this happened after a kernel upgrade. And "didn't work" is a bit inaccurate too: it would list firewall rules -- it just couldn't add them. (Good thing this machine had "default accept" as its firewall policy...) So, like, WTF?
First I tried adding a very simple rule: /sbin/ipfw add 100 allow
all from any to any Nope, didn't work: ipfw:
getsockopt(IP_FW_ADD): Invalid argument I tried that rule on another
machine to make sure my syntax was okay -- no problems. Well, what
about the command itself? The MD5 checksum of /sbin/ipfw on both
machines was the same. I considered briefly blaming the problems on
3133+ cR5><0rZ who'd found an MD5 collision in ipfw, but decided not
to try that on my boss. (I did copy the command from the working
machine to the stupid machine just to be sure...yep, same result. So
much for superstition.)
Hey, wait a minute -- hadn't we patched the kernel on the stupid machine? Sure we had! So that means...well, I don't know what. I had a look at the patches (very simple stuff, so I was able to follow along), and couldn't see what might be causing the problem. I mean, yes they did change the firewall functionality, but...well, maybe we should chase that up, yes? Yes.
And here I fell down a rabbit hole: I started to wonder if maybe the fact that FreeBSD compiled modules for everything (sure seems that way) despite the functionality being included in your KERNCONF file maybe meant that said functionality might still actually reside in the modules -- that the kernel wasn't being statically compiled at all, or at least for this particular bit, but there were Secret! Invisible! Modules! that actually had the bit of code we were looking for. Oh sure, kldstat doesn't show them, but that just shows how tricky those damn FreeBSD kernel developers are, right? And yeah.
Since the stupid machine'd had its kernel copied over by hand -- ie,
we did scp foo@bar:/kernel / (I KNOW, I KNOW) and rebooted,
and didn't copy all those Secret! Invisible! Modules! over along
with /kernel, why, sure we were gonna run into problems! Of course!
It all makes sense now! It was the Freemasons all along!
Lemme tell you, I was yea close to copying over /modules/ipfw.ko and
trying that (I did go so far as to try ldd /kernel
(I KNOW, I KNOW), but it turns out that ldd actually tries to
execute a file in order to figure out what libraries it uses, so
it just gave me a smack for being such an idiot), but for some reason
had another look at the patches we'd made. Okay, yep, that bit in
here, that bit over there, and not one bloody file in
/usr/src/sbin/ipfw/ipfw.c, so why the...
Oh. Header files.
/sbin/ipfw's compilationWell, crap. But hey, easy to test and easy to fix: patch the header
file, recompile ipfw, and ha! Working! All I had to do was compose a
suitably superior-sounding email about the dangers of passing
/kernel files around willy-nilly, and all was well again.
Coming up next: Gentoo on a dual G5. Woohoo!
You know it's a good day when you're demonstrating Unix pipes to someone, and suddenly you can see the light dawning, and they say, "Oh man, I've been wasting my time with Windows." Score one for the good guys.
I've put in a few hours tonight working on the Network Everywhere NWR04B, with mixed results. (The NWRO04B is the 802.11b router I picked up for $18 on sale; I'm trying to duplicate this guy's luck getting Linux to work on the thing.
I took the time tonight to get a slightly more permanent version of the RS232 adapter put together. Previously I've been putting stuff together on a breadboard, with wires all over the place; tonight I soldered things together and put wires all over the place. I tried to be careful, and all the connections seemed good, but I still had no luck: I saw absolutely nothing over the serial port at all, and from what I've read it should be pretty damned obvious. I'll have to ask some people at work about this.
One thing I'm still trying to figure out is how to treat all the different ground connections; I'm assuming that they all get connected together, and together with pin 5 on the DB9 connector, but I'm not sure. (If anyone's got any hints, please chip in.) That was about two hours tonight, and if that was it I'd chalk it up to experience and go to bed. But I did manage to find this page, which had a Perl script which extracts GZip archives from files. And guess what? It works on the NWR04B firmware! Woohoo!
It's embarrassing how simple this script is; I've been trying to
figure out some way of doing exactly this, once I'd figured out that
there was an archive in there. I want to understand how this
works, but in the meantime it's exciting (hoo, what a life) to see all
the stuff in there. strings | fmt | less shows tons of stuff going
on: HTML, a reference to /dev/uart0, clitask (some kind of
command-line interface, or just a dirty joke?), an XML UPNP
description of the device...all sorts of information. And that's
enough for now. I've got just enough energy to eat something, then go
to bed.
Problem: You are behind a FreeBSD firewall using natd. You are
listening to an Internet radio station with a limited number of
streams. It has taken you six tries to get in, but at last you're
there. Suddenly it's time for lunch, though, and you want to take
your laptop (which you've been using to listen) with you. When you
come back, you'll need to try connecting all over again.
Solution: natd is just a userland program. Hack it so that, upon
receiving a certain signal (USR1, say, or maybe something sent over a
listening Unix or TCP socket), it will remap a certain connection to
another incoming point. End effect: instead of the radio stream being
directed to your laptop, it'll be redirected to your workstation
where you'll have netcat or something similar to grab the stream
and keep things going. Switch back once you're back from lunch.
Well, sweet. I brought the iBook to work today, and at last I've found a place to get wireless access: turns out that [Trees Organic Coffee][1], in beautiful downtown Vancouver, not only offers free wireless access to its customers but! also allows SSH. I'm able to check my email from home and post this. Good thing I set up https for my site last night...too bad I've not generated my own certificate yet.
And advice for those who follow: the tables against the front window are really, really cute but they're up high enough to make my wrists cry out in pain. People are staring. And the signal's not great here either, though I'm sure it's better elsewhere in the shop.
Finally got the dual G5 box at work set up with Gentoo. Nice OS, I gotta say. I cheated and went with the stage 3 install on the assumption I wouldn't have enough time to play around, so I can't tell you how fast it was at compiling. But as an OS, it's nice. Very minimal; I felt like I was back in the days before I'd automated the workstation installs, doing minimal FreeBSD installs by hand and wondering how to fix the nine things that weren't working.
Emerge is cool; I definitely like the idea of using shell script functions for the various stages of adding a port (download, unpack, compile and so on). I've always thought that the FreeBSD set of Makefiles was needlessly obscure...but then, I'm probably betraying my complete and utter lack of 133+ by saying that. I want a Mister Muffin t-shirt. Piro, are you listening?
[1]: http ://vancouver.wifimug.org/index.cgi?TreesOrganicCoffee
I'm still having no luck getting a serial port going on this thing. I thought it might be because I was using a MAX 232 chip, instead of a MAX 3232 ("...and an extra 3 cubits for Linus, whose kernel this is...").
I also took the time to try to make a more permanent assembly by doing it up on a bit of perfboard -- so now I've got yellow wires (distinguishable connectors are for the weak!) poking out from perfboard instead of from breadboard. And still, nothing...not a goddamned peep, excep for a weird y-plus-umlaut character that pops up every now and then in Minicom and I'm blaming on either noise or acid flashbacks.
I'm at a loss here. As far as I can tell the connections are good (my three bits of electronics equipment are a soldering iron, a plastic box with many subdivisions, and a multimeter), and the circuit looks more or less like the circuit listed at the HRI site. That leaves connecting at the wrong place on the board, or maybe grounding. Not sure.
But hey! I got an offer to collaborate from pck; his electronic skills would be nice. And I'm going to shoot off an email to the guy who got it running in the first place to see if, a year later, he can help out.
