Date: Wed, 24 Feb 1999 19:25:17 +0100 From: Dermot McNally <derm@ibm.net> To: emulation@FreeBSD.ORG Subject: IBM ADSM Clients (Linux and SCO) Message-ID: <36D4440D.97FDD93@ibm.net>
next in thread | raw e-mail | index | archive | help
Folks, Apologies for such a long mail. Anyone who doesn't feel like reading the whole thing, please skip down to my suggestions relating to a change in the output of uname(3). ------------------- I've been trying for ages to get an ADSM backup client (_any_ client) working on FreeBSD, and now I have some progress, and some unanswered questions. Perhaps someone can elighten me. There are essentially three ADSM clients which, at first glance, look like they might run on FreeBSD. Two different versions (2 and 3) for SCO and a version 3 client for Linux. My first attempt was with the Linux client. At first, things looked good, but attempting a backup caused the ADSM server to crash (!). This turns out to be a buffer overflow (see below). Anyway, after this, I turned to the SCO version 3. It was initially non-obvious how the software was packaged, but once I got it extracted, the binaries proved to be ELF, which, of course, are not yet supported for SCO. Nothing more to try here. The SCO version 2 client is also (though differently) oddly packaged, and has old-style binaries, which are supported by the emulation, but which seg-faulted pretty much immediately once I ran the client. Only today, after making _some_ progress with the Linux client in the last week, did I get this client to work in close to a normal manner (with the aid of a customised-for-FreeBSD version of a Linux howto, which I'll be happy to pass onto anyone who wants it). The keys to making this work were: * Dropping a load of symlinks to null inside /dev under names that SCO wants to see there. * Creating a (presumably) SCO-format /etc/mnttab file from the contents of /etc/fstab (the howto included a perl script to do this). the mnttab file seemed to be the key to making the client believe that filesystems of a particular name existed (essential, if you expect the thing to back them up). So the V2 client now works, backing up to a V3 ADSM server on an RS/6000. I'm rather pleased, considering. There are a few niggles, however: * Although the backups work, and the server manager tools can see the results, none of the usual log entries (that report on success/failure, data transfer rate etc.) are made. Maybe this is a V2 -> V3 problem. * For each backed up FS, ADSM records the FS type (FAT, AIX JFS, NTFS, whatever). Backups from the SCO system contain garbage in this field (though I think it's always the same garbage). The FS type field from /etc/fstab is not copied into mnttab, which may be the cause. Does anyone know whether SCO's mnttab file format makes provision for this? * The V2 client's X interface really sucks compared to the one in V3. So, back to the Linux client - based on the progress I had already made before getting the SCO client to work, I had hoped it would be possible to get the same level of performance out of the Linux client, coupled with proper logging, a nicer UI and (maybe even) proper population of the FS type field. Here's what I had to do to make the Linux client work to at least some extent: Stopping the client from killing the server: An ADSM mailing list suggested this was related to a buffer overflow, and that it also happened with _some_ Linux kernels. What's happening is that either the version or release strings (or both) as reported by uname(3) are overflowing a buffer on the server, with fatal consequences, if longer than (I think) 7 characters. A Linux-compiled program to dump the output of uname(3) confirmed that both these fields were longer than 7 characters. It also demonstrated that most of the fields contained data extremely unlikely to come from any Linux kernel (the FreeBSD name, version numbers corresponding to FreeBSD kernel, not to some notional Linux one...). My solution to the immediate problem was to step on the version and release fields, and rebuild the linux module, but it struck me that perhaps there's a case for making the emulated uname(3) report either: * A fixed Linux-like set of data or * Whatever data the user has chosen in a .conf file somewhere I like the second idea, because, while the ADSM failure is the result of careless programming, stepping on the output of uname(3) is a nice way to fix the problem, and there is surely other software out there that uses these strings to infer whether they should try to run or not. Is this a bad idea? What would a reasonable set of default values look like? Anyway, after this Linux module hack, I can connect to the ADSM server without crashing it. I just can't specify any FSs to back up - the client rejects /usr (or any other valid FS) as an invalid "domain", even though it works for the SCO client. My best theory so far is that the Linux emulation also wants to see a Linuxish list of defined File systems. While I have no Linux box, the documentation I can find suggests that Linux uses the same format fstab as FreeBSD. However, copying fstab to /compat/linux/etc doesn't help here. This is as far as I've managed to get. I'd be grateful for any tips that other ADSM users can think of, and I'd also be happy to write the code for a configurable uname(3) output if people agree it's a good idea in the first place. I'm trying to fend off suggestions from colleauges that installing real Linux would be the simplest solution... Thanks for any thoughts, Dermot To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-emulation" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?36D4440D.97FDD93>