[comp.unix.microport] Microport Status, Net Buyout

tvf@cci632.UUCP (Tom Frauenhofer) (04/10/89)

I see several (there are doubtless more) issues with the Micrport OS's:

1) Kernel Maintenance: how are fixes to the kernel done?  Who does them?
   (This is as much a legal issue regarding AT&T and access to the kernel source
    as well as a question as to how the support operation works)
2) Drivers:  Same as kernel, plus new drivers for new hardware devices.
3) Documentation: Maintenance, writing.
4) Utilities: Microport has tried (at least) to upgrade the tools using source
   from newer revs of UNIX System V from AT&T (by the way, this is addressed
   mostly to V/AT users).  How do we get access to these?
5) System V Release 4: Will this company attempt a port to the 386?  Or will it
   simply maintain the releases and let other companies (Bell Tech, Interactive)
   handle this market?

None of this addresses communications with the existing user communities.

All in all, I think the best bets for us users are eiter (A) get some company
to buy Microport and promise support for their products (and include
enhancments and upgrades for V/AT), or (B) try to eliminate our dependence
on Microport-written code and get some businesses that use V/AT to form a
corporation to maintain the kernel.

I favor option (B).  It would be quite an effort (probably similar to the
Berkeley port to the AT that has been underway for several years), but it also
has the advantage that we could chuck the V/AT serial port driver in favor
of our own - that might cut down some of the bandwidth in this newsgroup
vis-a-vis Micrport's serial driver.  I would be willing to establish
my home machine as a V/AT hub to make the drivers (with their source code)
available to other users.

Comments?

Thomas V. Frauenhofer	...!rutgers!rochester!cci632!ccird7!tvf
*or* ...!rochester!cci632!ccird7!frau!tvf *or* ...!rochester!rit!anna!ma!tvf1477
BLOOM: You can't shoot the actors!  They're human beings!
BIALYSTOCK: Oh Yeah?  You ever eat with one?

root@spdyne.UUCP (04/18/89)

plocher%sally@Sun.COM Writes:
> +---- In article <1700020@spdyne> Chert Pellett writes: (ME..)
> |   I'd like to pick up the text prep tools from interactive, but I don't care
> | for the rest of the system.  [A wonderful example is the way that 'su' is
> | broke: if you su [to any user or root], from any tty other than the console,
> | it will log you off!
> +----
> 
> In the directory /etc/default there are several text files which you might
> want to look at.  One of them is called login, another good one is called su.
> Edit these and Delete the "CONSOLE=/dev/console" line in each file.  This
> will allow root logins anywhere (/etc/default/login) and allow anyone to su
> from anywhere (/etc/default/su)  (as long as they know the correct passwords!)
> 
> You must be root to edit these files.
> 
> Don't blame ISC for this, it is a Good Thing to have!  Can you spell
> S E C U R I T Y ?  Yes, I knew you could. :-)
> 
>   -John Plocher

    Hummm... Can you spell D O C U M E N T A T I O N ?  Didn't think so..:-)
{Directed toward AT&T - Not John..)
Just try to find at least one line of documentation on this...

Sigh, I noticed that on Uport, the directory doesn't exist at all!  No wonder
things are working like I would expect..  Yes, it is more secure to have
get_passwd (3S?) only work on the console, but let's be real, Rogue7 uses it!
[For Wizard mode...]
[Someone else posted that it was the code in get_passwd(3S) that did this
checking.]

As well as a BUNCH of other similar programs!! That could be used on any port.
I would prefer to have Su return an error status and issue the message
"Sorry." like it does when you get the password wrong.

Logging someone off because they attempted to Su to uucp [or some other
user], is just plain stupid.  At least having it do it by default is...


    -Chert Pellett
     chert@spdyne

egs@spdyne.UUCP (04/18/89)

Written 3:43p Apr 13, 1989 by plocher%sally@Sun.COM in spdyne:uport
|+---- In article <1700020@spdyne> Chert Pellett writes:
||   I'd like to pick up the text prep tools from interactive, but I don't care
||for the rest of the system.  [A wonderful example is the way that 'su' is
||broke: if you su [to any user or root], from any tty other than the console,
||it will log you off!
|+----
| 
| In the directory /etc/default there are several text files which you might
| want to look at.  One of them is called login, another good one is called su.
| Edit these and Delete the "CONSOLE=/dev/console" line in each file.  This
| will allow root logins anywhere (/etc/default/login) and allow anyone to su
| from anywhere (/etc/default/su)  (as long as they know the correct passwords!)
| 
| You must be root to edit these files.
| 
| Don't blame ISC for this, it is a Good Thing to have!  Can you spell
| S E C U R I T Y ?  Yes, I knew you could. :-)
| 
|   -John Plocher

Yes, John, Security is a good thing, but so is Documentation.  Having
gotten the full ISC 1.0.6 release, complete with VP/ix and ISC
documentation, and having read all of the documentation before
setting it up ( it was this system that root@spdyne(Chert Pellett) used )
I have not seen any mention of the /etc/defaults/{login,su} in
any of the system administration manuals.  And I just checked
again to verify this after reading the above.

These are the standard System V/386 manuals that AT&T,
Prentice-Hall, Bell Tech, and Interactive sell with their
systems.  I am not impressed by the documentation.

Just my $.02 worth.

---------------------------------------------------------------------------
Eric Schnoebelen	 John W. Bridges & Associates, Inc., Lewisville, Tx.
egs@u-word.dallas.tx.us	...!killer!u-word!egs	...!texbell!egsner!eric

plocher%sally@Sun.COM (John Plocher) (04/19/89)

>Written 3:43p Apr 13, 1989 by plocher%sally@Sun.COM (ME)
>| Don't blame ISC for this, it is a Good Thing to have!  Can you spell
>| S E C U R I T Y ?  Yes, I knew you could. :-)

After rereading this I realized I sounded rather snotty.   Sorry, I didn't
mean it that way.  :-(

I also did some more looking into this and it seems that  my off the
cuff answer was a bit off base.  The /etc/default stuff shouldn't be
causing the problem of the password routines logging you off, as it
is program specific. 

(BTW - this idea of defaults came from (Gasp) Xenix :-)

Sorry again for such a low quality article.

   -John Plocher

Some days it doesn't pay to get out of bed