Lewis' Blog Tales from the trenches of information technology

Configuring Squid Proxy on OS/2: Path adjustments

Following onto my post concerning web privacy, I wanted to produce some pointers concerning Squid configuration for web blocking. To do that, of course, I needed a working Squid configuration. Mine was sorely in need of an update. I'd been running 2.6 stable 14(?) for a long time, then upgraded to 3.0 stable 13. I recall that took me some time to get working, but still I suffered repeated crashes under heavy load, so as a result, I did what any other normal user would do: I turned it off.

Well, that's no solution, now is it? It's especially no solution if the goal is to be able to tell other people how to use it!

I downloaded Paul Smedley's latest build (more on my good friend Paul in another post), to wit, 3.0 stable 25, and set about upgrading. Normally, this isn't too bad:

1. kill the running Squid process;
2. rename the existing Squid directory;
3. unzip the new Squid distro to the root of the chosen drive;
4. move the var\cache directory tree to the "new" Squid;
5. adjust etc\squid.conf as necessary;
6. adjust the WPS objects (if any - I have a couple) as necessary;
7. start the new Squid

(Backslashes intentional.)

However, I was having some real trouble in a couple of respects. First off, every request was getting denied (I watched the access.log in my log viewer). This wasn't too difficult to figure out: I just needed to adjust my ACLs to allow localhost (beside the manager process) to get out. (I'll have more on this in a subsequent installment, so don't worry if you presently have no idea to what I refer.)

Once I got the ACLs out of the way, I found that I wasn't resolving any hostnames. This got interesting, as I surely don't recall having to make this change before.

Squid provides for a few options here. If you're not going to use Squid's own DNS server (which I do recommend using, if your port has it available - mine...Paul's...does not, at this point), Squid will look to /etc/resolv.conf (on *nix) or to the Windows registry (on Windows platforms), or one may make manual entries via the dns_nameservers tag in squid.conf.

Hmmm...

Those of you unfamiliar with OS/2 will wonder what my issue was. Those who are familiar will probably get a chuckle. To clue the rest of you into what my problem was, OS/2 by convention uses \MPTN\ETC\RESOLV2 as its resolver file for OS/2 applications, and \TCPIP\dos\etc\RESOLV as its resolver for DOS applications (which is normally just mirrored over by the TCP/IP stack from RESOLV2. For non-*nix-ported apps, this arrangement works just fine. However, for an app expecting to find /etc/resolv.conf (slashes and backslashes are of no consequence when running these applications, as our libraries hand off the correct path delimiter to the shell, and also know how to deal with drive letters and colons), this just ain't gonna work.

Paul's build looks for %UNIXROOT%/etc/resolv.conf, adding a further complication, but giving me a brainstorm at the same time. (The UNIXROOT variable is used with more recent ports - hey, we even have rpm and yum on OS/2, now - to set the root path where we normally have a *nix-like directory structure.) On my ThinkPad, UNIXROOT is set to J:, and I do indeed have J:\etc. Okay, so half the battle is done. The question then, is how to keep a copy of a file which may change from time to time while the system is booted up to date with the live copy being handled by the DHCP client daemon?

The answer was simpler than one might expect.

With OS/2 Warp 4, IBM ported their JFS (Journalling File System) from AIX to OS/2. This port was actually based on JFS2, not the original JFS. Since then, IBM open sourced the JFS code, and the OS/2 builds have steadily improved to the point where unless there is some reason to use HPFS (servers which boot from SCSI subsystems often must use HPFS, as the minifs driver in the kernel can't boot from a JFS volume on such SCSI subsystems), there is no reason *not* to use JFS for everything. (There is another caveat to that: HPFS386 still supports more finely-grained security than JFS, so I suppose there may very well be some other places where HPFS386 - not the 16-bit HPFS, but the fully 32-bit one - would be desirable.)

In addition to gaining the major speed and size enhancements of JFS, we also gained native filesystem support for symlinks. This, of course, is quite humorous, as OS/2 applications have no built-in support for such things. However, support is there for applications - such as *nix-ported apps - which can and do support symlinks.

So, I solved the problem the way I would on a Linux box: I used my installed port of ln to create a softlink, as in:

ln -s C:\MPTN\ETC\RESOLV2 J:\etc\resolv.conf <Enter>

Sure enough, I have a working symlink. Starting Squid in an OS/2 window, I get:

2011/12/08 00:18:00| Processing Configuration File: /squid/etc/squid.conf (depth 0)
2011/12/08 00:18:00| Initializing https proxy context
2011/12/08 00:18:00| DNS Socket created at 0.0.0.0, port 49351, FD 10
2011/12/08 00:18:00| Adding domain randr from /@unixroot/etc/resolv.conf
2011/12/08 00:18:00| Adding nameserver 192.168.100.1 from /@unixroot/etc/resolv.conf
2011/12/08 00:18:00| Adding nameserver 4.2.2.2 from /@unixroot/etc/resolv.conf
2011/12/08 00:18:00| Adding nameserver 4.2.2.1 from /@unixroot/etc/resolv.conf
2011/12/08 00:18:00| Accepting  HTTP connections at 0.0.0.0, port 3128, FD 11.
2011/12/08 00:18:00| Accepting ICP messages at 0.0.0.0, port 3130, FD 13.
2011/12/08 00:18:00| HTCP Disabled.
2011/12/08 00:18:00| Loaded Icons.
2011/12/08 00:18:00| Ready to serve requests.

which does pick up changes to C:\MPTN\ETC\resolv2, which I proved by editing the file and then issuing:

C:\> \squid\sbin\squid -k reconfigure <Enter>

whereupon I was immediately greeted with the change I made, as read from the symlink.

I should add that for ages I've wanted to get symlinks working on my OS/2 (eCS 1.2R) web server, as there is so much common code between web directories (i.e., a generic "under construction" image), but I have never been able to get such things to work. I guess I should try with the updated JFS.IFS and current coreutils.

Next time, I promise to have more generally-useful info about Squid and its configuration. For now, I'm satisfied that I have a working testbed (again).

Last Updated on December 8th, 2011 by LewisR