(OLDER) <- More Stuff -> (NEWER) (NEWEST)
Printer Friendly Version



Best of the Newsgroups: using install server for sco installs

Main Index

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!




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



/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.

Publishing your articles here

Jump to Comments



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.



More:
       - OSR5
       - Bofcusm


Unix/Linux Consultants

Skills Tests

Guest Post Here











My Favorites

Change Congress