Get APLawrence.com by RSSWidgetBucks - Trend Watch - WidgetBucks.com
Best of the Newsgroups: using install server for sco installs
Probably a good indication of SCO's waning popularity is the fact that this capability got broken somewhere and never fixed. This is just one part of a long post on this subject.
From: "Brian K. White" <brian@aljex.com> Subject: Re: more custom, install server Date: 24 Nov 2005 03:32:27 -0500 Message-ID: <018601c5f0d1$892c7370$6600000a@venti> References: <013901c5f0b3$90173760$6600000a@venti> <200511232110.aa29987@deepthought.armory.com> ----- Original Message ----- From: "Bela Lubkin" <filbo@armory.com> Newsgroups: comp.unix.sco.misc To: <distro@jpr.com> Sent: Thursday, November 24, 2005 12:10 AM Subject: Re: more custom, install server
> Brian K. White wrote: > >> Nov 23 23:43:20 unixa0 ftpd[15048]: <--- 220 unixa0 FTP server (Version >> wu-2.6.1(1) Mon Feb 26 23:48:24 PST 2001) ready. >> Nov 23 23:43:20 unixa0 ftpd[15048]: command: HELP SITE EXEC >> Nov 23 23:43:20 unixa0 ftpd[15048]: cmd failure - not logged in >> Nov 23 23:43:20 unixa0 ftpd[15048]: <--- 530 Please login with USER and >> PASS. > >> Aha! Now we are getting somewhere. > > Indeed. I vaguely remember that this got broken somewhere along the > way, and may not ever have been fixed. Do you have an older > OSR5-supplied wuftpd sitting around somewhere? Very likely you do, > somewhere under /opt/K/SCO/tcp/... Look for older binaries and try > temporarily promoting them to /etc/ftpd. e.g. move aside /etc/ftpd to > /etc/ftpd.current, then symlink /opt/K/SCO/...old-ftpd to /etc/ftpd. > (You'll probably also have to chmod it to match the one you're currently > running.) > > Seems to me ftpd was updated to correct some security issues, and this > broke at the same time. The ftpd shipping in 506 should be OK, but > you're running one from a SCOSA or MP or something. So the old one will > probably be down in the SSO, chmod'd to 0. Actually, I seem to remember being in a discussion (with you then too I think) where I was spinning my wheels and it turned out to be the man page for ftpd simply being backwards about the default behaviour of one of the command line arguments (-a or -A maybe?) I think, due to rs506a replacing ftpd but not updating the man page. So right off the bat both these boxes have rs506a. > Security issues in ftpd aren't a problem as long as you're only > connected to your LAN. Surely you aren't routing FTP service in from > the Internet to this machine that's in the middle of being built... I am routing ftp in to unixa0, that is the old box that has all the stuff already installed, which is also the box I assume I should try testing an old ftpd on. I am not routing ftp into the new box no, but neither does anything care about ftpd on that box yet does it?
I'm not overly concerned anyways, at least not for the purpose of a short test. If I was more worried, I can probably just play a little smoke & mirrors with ipnat on "unixa0" easy: * add a line or two to /etc/ipnat.conf to take ftp traffic coming in from the lan and shift it to some other tcp port * add a line for that port in /etc/services * add a line to /etc/inetd.conf to have inetd service that port with the old ftpd, leaving the existing ftpd line alone so it keeps on servicing ftp traffic that reaches inetd via the normal ftp port. When ipfnat isn't up, things are normal for all parties. When ipfnat is up, external traffic keeps using the normal ftpd, lan traffic uses the alternate ftpd. In all cases clients use normal ports like always. Hmm, Seeing as it's just that easy, I may try it that way after all, just to see if the idea works. > Just be sure to put back the original symlink when you're done. > > And remember that ftpd is executed by inetd each time someone FTP's in, > there's no persistent daemon, so you don't need to reboot to activate > the symlink change. Thanks a lot. I'll try it. I have access to other boxes too going back as far as 5.0.4 so I can try even older binaries but that rs506a note makes it smell like I won't actually have to look very far for the working binary after all. And if the pre-rs506a ftpd works, and if the ipfnat trick for using it works, then this is a reasonable "official" answer to this question since it only uses things that already exist on all 506 boxes. # find /opt -name ftpd |xargs ls -lWv -r-------- 1 bin bin 142848 Nov 21 2004 /opt/K/SCO/tcp/2.1.1Ga/.softmgmt/patchBackup/2.1.1Ga/etc/ftpd -rwx--x--x 1 bin bin 242756 Nov 21 2004 /opt/K/SCO/tcp/2.1.1Ga/etc/ftpd -rwx--x--x 1 bin bin 242756 Nov 21 2004 /opt/K/SCO/tcp/rs506a.tcp211.1.0a/etc/ftpd /opt/K/SCO/tcp/2.1.1Ga/.softmgmt/var/var/ftpd: total 0 # # ls -lWv /etc/ftpd -rwx--x--x 1 bin bin 242756 Nov 21 2004 /etc/ftpd -> /opt/K/SCO/tcp/2.1.1Ga/etc/ftpd # hm... [...time passes...] Wow It works!!!! OK so here's the nice easy recipe: cp /opt/K/SCO/tcp/2.1.1Ga/.softmgmt/patchBackup/2.1.1Ga/etc/ftpd /etc/cftpd chmod 744 /etc/cftpd chown bin:bin /etc/cftpd echo "cftp 921/tcp # pre rs506a ftpd for custom" >>/etc/services echo "cftp stream tcp nowait root /etc/cftpd ftpd -a -d -i -l -L -o" >>/etc/inetd.conf touch /etc/ipnat.conf echo "rdr net0 10.0.0.0/24 port 21 -> 10.0.0.200 port 921 tcp" >>/etc/ipnat.conf tcp stop ; tcp start /etc/init.d/ipfnat stop ; /etc/init.d/ipfnat start Obviously there is some site-specific stuff in there like the path to the old ftpd and most of the nat rule. The choice of 921 is probably fine for anyone. Also this article on Tony's site mentions changing a couple values in /etc/defaults/inet from 0 to 1. http://aplawrence.com/Security/ipfilter.html I did not have to do this and I verified mine are both 0 right now. Whatever those do, maybe it's another site-specific quirk and maybe someone else will need to do it. Now, from outside the lan I still get the normal, current, ftpd: 220 unixa0 FTP server (Version wu-2.6.1(1) Mon Feb 26 23:48:24 PST 2001) ready. And from inside the lan I get the new, old ftpd: # ftp unixa0 Connected to unixa0. 220- 220 unixa0 FTP server (Version 2.1WU(1)+SCO-2.6.1+-sec) ready. Name (unixa0:root): swadmin 331 Password required for swadmin. Password: 230 User swadmin logged in. Remote system type is UNIX. Using binary mode to transfer files. ftp> And the final result, custom on the new box works! You select install, from other, enter the address and password, then select "Hard Disk" and wham bam, a list of all the stuff installed on the other box. I just used it to install oss642a ! Pretty snappy too over gigabit. :) So there it is. You only need things that already exist on every box that might have the problem, and you don't have to give up security, and you don't need any extarnal support such as in the router, and you don't break any automated ftp scripts that outside entities might have in place that access your box, and you don't have to reboot, and networking services are disrupted only for a fraction of a second and it's only the ability to make a new connection then that is even touched, no existing connections break. Sweet. Thanks a ton Bela. Now I can finally try that thing we were curious about a couple years ago when I was talking about how I installed AutoCAD for Xenix386 on a 5.0.4 or 5.0.5 box and wondering if that amazing example of backwards compatibility still carries through to 5.0.6 and 5.0.7 but I didn't think the install media could be found or that it would still be viable. You suggested trying a "vampiric" install. Which I never got around to trying. I still have that box though it hasn't known electricity in a few years. What's amazing about that install is, not only did it work by simply following the decade or however old directions verbatim right from the sticker on the floppy, but that this is not ordinary software. It includes drivers that get linked into the kernel for non-X based graphics hardware access and possibly for other output like plotters and input like mice/tablets/pucks as well. It's just stupendous that something like kernel drivers for xenix (granted, at least it was xenix386 vs 286) to drop right into osr 5.0.4/5. Not only do the drivers still interoperate with the kernel, but even all the assumptions the install script must make, commands it must run, directories and files it expects, system files it might have to edit in-place,.. a zillion things that all could easily have changed over time. Perhaps Autodesk deserve some of the credit for that though too. Maybe they took pains to make the installer and the software more likely to keep working across os changes by avoiding assumptions where possible. Brian K. White -- brian@aljex.com -- http://www.aljex.com/bkw/ +++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++. filePro BBx Linux SCO FreeBSD #callahans Satriani Filk!
Add your comments