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!
/Bofcusm/2637.html copyright 1997-2004 (various authors) All Rights Reserved
Have you tried Searching this site?
Unix/Linux/Mac OS X support by phone, email or on-site: Support Rates
This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more. We appreciate comments and article submissions.
Many of the products and books I review are things I purchased for my own use. Some were given to me specifically for the purpose of reviewing them. I resell or can earn commissions from the sale of some of these items. Links within these pages may be affiliate links that pay me for referring you to them. That's mostly insignificant amounts of money; whenever it is not I have made my relationship plain. I also may own stock in companies mentioned here. If you have any question, please do feel free to contact me.
Specific links that take you to pages that allow you to purchase the item I reviewed are very likely to pay me a commission. Many of the books I review were given to me by the publishers specifically for the purpose of writing a review. These gifts and referral fees do not affect my opinions; I often give bad reviews anyway.
We use Google third-party advertising companies to serve ads when you visit our website. These companies may use information (not including your name, address, email address, or telephone number) about your visits to this and other websites in order to provide advertisements about goods and services of interest to you. If you would like more information about this practice and to know your choices about not having this information used by these companies, click here.
Click here to add your comments
Don't miss responses! Subscribe to Comments by RSS or by Email
Click here to add your comments
If you want a picture to show with your comment, go get a Gravatar