Up all night with Linux 2

Well this is turning into a regular series: and the journalist in me couldn't resist trying to sell it to the nearest editor: Trevor Parsons of LinuxUser magazine, since you ask...

And the disturbing thing is I started at 3pm this afternoon, and thought I could comfortably get it done, watch a bit of TV, chill with my partner... O no. It was only partly to be. Read on if you like gory technical detail...

Slackware 8.1 CD set arrives

My Slackware 8.1 disks arrived in the post from the excellent linuxemporium today. I did a few stupid things on the way to installing it: hosed my tomsrtbt 1.7.259 disk in a moment of carelessness... It took me a while to discover that color.gz has been replaced by a series of 5 install disks (install.1 through install.5) and they were on the 3rd CD of the 3 CD set. I suppose it's only people like me that don't have machines with bootable CDROMs... Still, had a pleasant time while /dev/fd0 whirred and chunked away (that's the floppy disk drive to you ordinary mortals), neatly labelling floppy disks with my coloured pen collection. Thought a little bit about the reliability of the medium (not very, seems to be the answer) but couldn't locate any useful consumer review information. I mostly use the Imation colour unformatted 2.0MB disks, but they're expensive.

A few false starts on the install: partitioning did not happen as I expected, and one of the flaws of the Slackware install process is that there is no way back; and if you have to reboot having loaded a 6-floppy set... well, you have to reload a 6 floppy set, which is a lot of whirring and chunking, though not so much that you can actually do anything useful while you wait for each one to load. Ho hum.

But the packages I've selected install smoothly. The new slack gives you a lilo splashscreen with a default 1200 tick delay before it actually boots (not good on a production server). Editing lilo.conf doesn't seem to do anything to this. Hang on, I didn't re-run lilo... I'll do it now and reboot... aah that's better.

at least the apache default install is smooth

Apache is there, 1.3.26: nice recent version (bit early for 2.0.40? for me, anyway). Should be secure; yup, there it is.

So I think to myself, well how am I actually going to get files from my development machines on the green network to the webserver on the orange network? (I've an ipcop firewall installed.)

Ideally I'd like to use netatalk and just pull up the server on the Mac. But it was not to be. At least not easily anyway I can see it.I don't know what ports I'd need to open up on the firewall for netatalk to talk from the green to the orange network, and, though I had a look in the usual places, there is no obvious answer to this question. [Tip from trevor: examine /etc/services and looksee which ports are open.] Along the way I did find a fix for something that's been bugging me for several months in the configuration of my netatalk box "a common configuration error" apparently. See http://www.umich.edu/~rsug/netatalk/faq.html#2.2)

So I sigh, and think, well, at least I know I can use GNU/Linux to replicate the functionality Demon homepages gave me; namely to open up ftp ports between the green and the orange, and use Fetch to pull things back and forth (the CLI for ftp requires more manual reading than is practicable in day to day life, or at least tonight.)

(as yet) insoluble problem

But this has proved insoluble so far. Slackware 8.1 has "upgraded" from wu-ftpd to proftpd, which is said to have all kinds of advantages-- an apache-like configuration file, a single binary, more security features etc etc. And it runs all kinds of high volume anonymous ftp sites like debian for example.

Unfortunately, almost immediately there were problems. To get the proftpd daemon running involves uncommenting a line in the inetd.conf file: the one that begins ftp, and restarting inetd. There were two problems: firstly, the line was uncommented, and despite my best efforts, proftpd was not running (which it should have been). It performs some basic authentication using tcpd (tcp wrappers) which I don't know much about, but even altering that line in the config file so that it pointed straight at the proftpd binary that lives in /usr/sbin didn't help.

The proftpd config files supplied with the distro all seem to assume that you want to set up an anonymous ftp server, which I don't. Anonymous ftp assumes read only privileges for the remote user, and I want to be able (obviously) to write and read. I only want users on my machines, on my network (i.e. me) to be able to login. Furthermore, making a public ftp server uploadable is asking for all kinds of warez dudez to come along and sap your disk space and bandwidth, so all kinds of elaborate (for which read "time-consuming") security precautions are necessary.

I diddle away with the config files, find several helpful pages on the net:

http://hints.linuxfromscratch.org/hints/ftp.txt
http://www.numenor.demon.co.uk/ccfaq/sample.htm
http://www.freebsddiary.org/proftpd.php
http://www.redhat.com/support/resources/tips/FTP-Setup-Tips/FTP-Setup-Tips-3.html
http://www.mandrakeuser.org/docs/connect/cftp2.html
http://www.va.pubnix.com/man/proftpd/FAQ-config.html

(all rather distro specific, but I give them a go, no luck)

So I've handrolled a heap of proftpd.conf files, and they sit there laughing at me, but still the damn thing won't launch at all, and it all assumes very high level understanding of all the concepts. There is really a glaring need for a HOWTO and sample config file to do what I want to do (I can't be the first to want to do this surely? Just about every ISP offering free webspace must need something like this, no?) without me actually having to do it :-) (One of the virtues of the hacker is said to be laziness after all). NB: this link is close but not quite precise. Anyone who's got time to browser the jargon files and find the bit about laziness should mail me.

And to make it worse, kill -HUP doesn't seem to be working at all though kill -kill is, and I then launch it as /usr/sbin/inetd as a workaround. This may be where things are going wrong, as there are inetd and standalone options in the proftpd.conf file...

And the proftpd docs don't exactly inspire confidence: massive lists of "directives," many of which are commented with the words FIXME... (http://www.proftpd.org/docs/directives/linked/by-name.html)

I tire of proftpd configuration attempts

Anyway, I think maybe I'll go down the bazaar and have a look at wu-ftpd which, afterall, has a more illustrious and mature pedigree than this f***ing thing that is f***ing refusing to work.

So I download it, untar it, read the docs (configuration, both before and after compilation is "not trivial" say the docs, rather primly), do all that make stuff (lucky I've got all me manuals eh?).

Sod it. Go with the defaults and see what happens...

Ulp. I see why the world is switching to proftp: about 8 files with non-obvious names and functions pop out of the build process, and it's really time to read the docs. But it's 12 hours in, it's past 3 in the morning, and it really is time to write up another tale of woe and head for bed.

at least ssh works out of the box

On my way out the door I see if I can ssh in to the box and I can, which is nice, so I'm back at the Mac, which is where I'm happiest.

Hmm... wonder if there's a way to use ssh to upload files easily...

A question for the morrow...

Oh yeah. sftp. Would be a workaround:

use sage as Appletalk host, then sftp stuff from there to dill.

But Fetch 3.0.1 has proved such a trusty ftp servant... so... Mac-like...

Must try to crack it.

Good night world.

DC
0425hrs
16/8/02

Comments to dougie@carnall.org


Update

1300hrs 26 September 2002

Just got a nice email out of the blue in response to this page from TJ Saunders, the author and maintainer of (amongst other things) a series of proftp howtos. Definitely worth a look the next time I return to this issue.

And a thread on the ipcop-user mailing list confirms that trying to AppleShare over AppleTalk between the orange and green networks is never going to work; but that AppleShare over IP should work nice and easily. However, this requires buying an AppleShare IP license for the Mac on the orange network.

And I should add that Trevor (very nicely) rejected this intermittent series as a goer for LinuxUser. Lucky we don't **need** editors to publish our thoughts these days isn't it ;-)