Conference gyro::internet_server

        Well, I finally removed IAS V2.0 (using its cleanup.sh) prior
        to upgrading to Enterprise and IAS V3.1.  The removal went
        well.  However, I now find that rsh/rexec access (which I use
        from eXcursion as well as from other workstations) no longer
        works.

        I had previously had access for them enabled using the
        Electronic Locker interface, but of course now that's gone,
        and the rsh/rexec access that was working has stopped
        working.

        Apparently, installing then removing IAS V2.0 doesn't leave
        the system as it was before.

        Another problem:  I figured that it might be possible to
        install Enterprise as part of the IAS V3.1 installation, but
        I was wrong.  It appears to want to mount a CD -- I found no
        way to tell it that I already had an image of the Netscape
        installation available (from the internal network kit).  As
        it turned out, it was probably good that that didn't happen,
        since I wouldn't then have been able to run the Netscape
        upgrade script at the right time (to migrate the
        Communications server settings to the Enterprise).

        So, I haven't yet installed IAS V3.1, but I do have what
        appears to be a fully functional Enterprise server (although
        I have read in a Netscape newsgroup that the upgrade script
        may have failed to configure some of the new functionality of
        the Enterprise server).

        I may still install IAS V3.1, but first I'd like to know how
        to get rsh/rexec access back on the system after removing IAS
        V2.0.

        Bob

re 203.3:

The daemon.log file under /var/adm/syslog.dated/<date>/ includes
multiple copies of the following:

REXECD FAILURE:SIA init

Perhaps it really isn't possible to remove IAS once installed?

Bob
[Posted by WWW Notes gateway]

I would check /etc/inetd.conf for abnormalities like /usr/bin/tcpd (tcpwrapper) 
left in.  Version 2.0 was a very early implimentation of tcpwrapper and it may 
not have been removed properly.

re Note 203.5 by ZEKE::ranger.zko.dec.com::dilsworth:

>                       -< Any tcpwrapper relics in /etc/inetd.conf >-
> 
> I would check /etc/inetd.conf for abnormalities like /usr/bin/tcpd (tcpwrapper) 
> left in.  Version 2.0 was a very early implimentation of tcpwrapper and it may 
> not have been removed properly.
  
        Well, never mind....

        Probable user error (nay, certain user error!).

        Actually, I was ahead of you.  I checked /etc/inetd.conf
        after the removal to see if there were any relics, and there
        were:

> #
> #
> #   The following were added by the DIGITAL Internet AlphaServer software
> #   Version 200 on Thu Jan 11 14:27:59 EST 1996
> #
> #
> dtspc stream tcp nowait root /usr/dt/bin/dtspcd dtspcd
> rpc.cmsd/2-4 dgram rpc/udp wait root /usr/dt/bin/rpc.cmsd rpc.cmsd
> rpc.ttdbserverd stream rpc/tcp wait root /usr/dt/bin/rpc.ttdbserverd rpc.ttdbserverd

        So, logically, I commented out the lines following the comment!

        Just a few minutes ago I compared this /etc/inetd.conf with
        that of a similar system that had never had IAS installed
        and, guess what, the comment was missing but the lines after
        it were there!

        It's my fault, but that comment surely is misleading.

        rexec and rsh access now work.

        Bob

        I'm still having one problem which coincidentally appeared
        right after removing IAS V2.0.

        Certain Pathworks For Digital UNIX Advanced Server (V6.0
        ECO1) users can no longer connect to their shares after
        removing IAS V2.0 -- but other users can connect.

        I admit to being woefully inexperienced in managing
        Pathworks, but I have made no changes lately.  There appear
        to be two main differences between the users that can access
        the server and the users that can't.  First, the users that
        can are using NT Workstation, the users that can't are using
        Windows 95.  Second, the users that can access use accounts
        that were established a year ago;  the users that can't use
        accounts that were set up earlier this month.

        Thanks,
        Bob

I haven't got a clue about pathworks.

I would try having a user that can login from NT try it on a WIN95 machine.

If he can still login I would compair his groups to a user that can't login.  After that check 
for any pathworks access list.

re Note 203.8 by ZEKE::ranger.zko.dec.com::dilsworth:

> I haven't got a clue about pathworks.
  
        Yes, but you probably do have an idea of what files
        cleanup.sh (from IAS V2.0) touches, modifies, or rolls back
        to a backed-up version.

        It's that kind of information I'm looking for now.

        Bob

IAS created accounts in /data/Lkr_Usr.  The ownership of Lkr_Use is root:Lkr_Usr_ and is 
accessable only to root and members of Lkr_Usr_ group.  If these are the users that can't access 
there files you may need to change ownership and protections of the parrent directory to be like 
the parent directory of the users that work.

If you were using SAMBA you might also need to place an entry in the nmbd.conf file to export 
/data/Lkr_Usr_.  You would definantly need an entry to export HOMEDIRS.  Can't tell you how 
pathworks configures exporting directories.

If some users can get in/access there files and not others then look at the differences in the 
/etc/passwd entries for those users.  Are they in different parent directories (i.e 
/usr/users/joe who works and /data/Lkr_Usr_/jim who doesn't work).  Make the parent directories 
the same owner and protections.  Make the users home directories the same protections for a bad 
user as a good user.  Make sure ls -ld ~joe/ shows joe as the owner and his primary group as the 
group (not a number for either).

If you post the passwd entries for a working and non working user along with a copy of /etc/group 
I might be able to point you to an area that could be the problem.