HDTenEightyP/NetNews huggingface dataset:
From: gemoe@proximus.north.de (Gerhard Moeller)
Subject: Re: /etc/mtab permissions
Organization: Gerhard Moeller, German NeXT User Group, Oldenburg.
Date: Mon, 25 Jan 1993 06:22:36 GMT

In article <C1A5Ep.6nI@mentor.cc.purdue.edu> davisre@sage.cc.purdue.edu (Robert  
Davis) writes:
> 
> 	This may have been mentioned before (I recently upgraded to
> 3.0), but is there a workaround or fix for this:  ejecting a mounted
> floppy changes the permissions of /etc/mtab so that you can't do a df.
> 
> % df
> Filesystem            kbytes    used   avail capacity  Mounted on
> df: /etc/mtab: Permission denied

Yes,  I had  the  same  problem.  And  it doesn't  help  to  change  the
permissions again. (Except you do it with a cron job. But this is ugly!)
Especially bad is the problem if you use cnews...

What  I did: I simply set the suid bit  of df. But setting a suid always
worries me... Any better solutions out there?

Also  strange: Since I  installed the  MOTD.app multi-volume  disk copys
don't work anymore!! Neither in a net nor at a single user station. 

When will 3.1 be out?

	Gerhard.
--
+---------------------------< principiis obsta! >---------------------------+
N  Gerhard Moeller, Teichstrasse 12, 2900 Oldenburg (FRG) [*: 02/21/1968]   N
e  Private: gemoe@proximus.north.de          Phone (voice): +49-441-75520   e
X  Uni:     Gerhard.Moeller@arbi.Informatik.Uni-Oldenburg.DE      NeXTmail  X
T  Z-Net:   Gerhard.Moeller@uniol.zer                          encouraged!  T
+-> NoGeNUG - Northern German NeXT User Group:  NoGeNUG@proximus.north.DE <-+
Newsgroups: comp.sys.next.bugs
From: gcolello@biosphere.Stanford.EDU (Greg Colello)
Subject: Re: Wherefore this group?
Organization: DSO, Stanford University
Date: Wed, 27 Jan 93 18:52:19 GMT

In article <1993Jan27.155027.9777@midway.uchicago.edu>  
colin@agincourt.bsd.uchicago.edu (& Garrett) writes:
> If someone is not sure that a problem they are encountering is caused by  
a  
> bug or not, it would seem most appropriate to place the note in a  
> newsgroup dedicated to the subject (c.s.n.sysadmin, programmer, misc).   
> And since 'bug' is a catch-all category for any unexplained  
unsatisfactory  
> behavior, until the problem is resolved, almost anything is a bug  
> candidate.  (What percentage of those "I think there's a bug in gcc..."  
> notes pan out?)
> On the other hand, if something has been proved to be a bug, the most  
> suitable place for a note explaining it is probably a static locus like  
a   
> FAQ (preferably archived), rather than a forum for dynamic discussion  
like  
> a newsgroup.
> Maybe that's why posts in here have been dwindling?
> 
> colin

I'm afraid you're right. At the beginning of this group I wrote to the  
creator of it asking that some posting rules be established. I thought  
threads should be disallowed and instead a moderator ought to post  
confirmed bugs (with solutions) as determined by discourse in the other  
Next newsgroups. Your idea of a FAQ would also be required. Still I would  
like to see the bug and solution posted once. I think the problem here  
appears to be the lack of a moderator.

-----------------------------------------------------------------
Greg Colello
Carnegie Institution, Department of Plant Biology
Stanford University
gcolello@biosphere.stanford.edu (NeXT mail OK)
Newsgroups: comp.sys.next.bugs
From: davisre@sage.cc.purdue.edu (Robert Davis)
Subject: Re: /etc/mtab permissions
Organization: Purdue University Computing Center
Date: Mon, 25 Jan 1993 19:09:45 GMT

In article <RHESS.93Jan25093544@consilium.COM> rhess@consilium.COM (Richard L. Hess) writes:
>
>  I had the same problem.  It took me a while to figure it out, but I'd bet
>that you have very tight permissions set on your "File Creation Mask".  If
>you just use "Expert Preferences" (Unix) in the Preferences tool to open up
>your permissions to allow "Group" & "Others" Read access, then you won't have
>any problems with the permissions changing on /etc/mtab.  Evidently when the
>eject script/program executes it runs as root and uses your default
>permissions and so if your permissions are too "tight" you can't read
>/etc/mtab after the floppy get's ejected.  Hope this helps,
>

	Thanks, that seems to be a good workaround.  I had trouble
	with NeXT disks as well as DOS and Mac disks.


Rob
-- 
| Robert Davis                                    davis@sonata.cc.purdue.edu
| "Look up, Hannah.  Look up."                            NeXT Mail accepted
--
Newsgroups: comp.sys.next.bugs
From: ravn@imada.ou.dk (Thorbjoern Ravn Andersen)
Subject: NFS mounts -- time stamp problems?
Organization: Dept. of Math. & Computer Science, Odense University, Denmark
Distribution: comp
Date: Mon, 25 Jan 1993 19:17:25 GMT


We have a Unix network with Sun's and NeXT machines mixed together, with
home directories on the NeXT hard disks.

Apparently, date stamping works incorrectly when setting  stamps
explicitly, instead of inheriting the dates from the file system.

Touching a file yields a date of January 1 1970, which is somewhat
incorrect.   I *think* this is date Zero, but why should that be?

Anybody got any suggestions for circumventing this problem?
-- 
Thorbj{\o}rn Andersen 
ravn@imada.ou.dk      
 
                       
Newsgroups: comp.sys.next.bugs
From: lemson@ux1.cso.uiuc.edu (David Lemson)
Subject: Re: NFS mounts -- time stamp problems?
Organization: University of Illinois at Urbana
Distribution: comp
Date: Thu, 28 Jan 1993 06:53:40 GMT

ravn@imada.ou.dk (Thorbjoern Ravn Andersen) writes:


>We have a Unix network with Sun's and NeXT machines mixed together, with
>home directories on the NeXT hard disks.

>Apparently, date stamping works incorrectly when setting  stamps
>explicitly, instead of inheriting the dates from the file system.

>Touching a file yields a date of January 1 1970, which is somewhat
>incorrect.   I *think* this is date Zero, but why should that be?

Is this under 2.x or 3.0?
I have seen similar time-related problems when 'touch'ing files that
are actually on a Sun exported via nfs to a NeXT under 2.1.  It was
acknowledged as a known bug and fixed in 3.0 when they supposedly
re-wrote much of the nfs code.
-- 
David Lemson                                                (217) 244-1205
University of Illinois NeXT Campus Consultant / CCSO NeXT Lab System Admin
Internet : lemson@uiuc.edu                UUCP :...!uiucuxc!uiucux1!lemson 
NeXTMail & MIME accepted                           BITNET : LEMSON@UIUCVMD
From: rhess@consilium.COM (Richard L. Hess)
Newsgroups: comp.sys.next.bugs
Subject: Re: /etc/mtab permissions
Date: 25 Jan 93 17:35:44 GMT
Organization: Consilium Inc., Mountain View, California.
In-reply-to: davisre@sage.cc.purdue.edu's message of 23 Jan 93 00:01:36 GMT
X-UserAgent: GNUS 3.13  [ NNTP-based News Reader for GNU Emacs ]

>>>>> "Robert" == Robert Davis <davisre@sage.cc.purdue.edu> writes:

Robert>         This may have been mentioned before (I recently upgraded to
Robert> 3.0), but is there a workaround or fix for this: ejecting a mounted
Robert> floppy changes the permissions of /etc/mtab so that you can't do a df.

  I had the same problem.  It took me a while to figure it out, but I'd bet
that you have very tight permissions set on your "File Creation Mask".  If
you just use "Expert Preferences" (Unix) in the Preferences tool to open up
your permissions to allow "Group" & "Others" Read access, then you won't have
any problems with the permissions changing on /etc/mtab.  Evidently when the
eject script/program executes it runs as root and uses your default
permissions and so if your permissions are too "tight" you can't read
/etc/mtab after the floppy get's ejected.  Hope this helps,

Dick...

ps.  I don't remember whether it was ejecting Macintosh or DOS format floppies
     that caused this problem, but one worked and the other didn't and I never
     had problems with the NeXT (Unix) format floppies...
  
+----------------------------------------------------------
WHO:	Richard Hess	[ Staff Engineer ]
CORP:	Consilium Inc,	640 Clyde Court, Mtn View, CA 94043
VOICE:	[415] 691-6342
EMAIL:	rhess@consilium.COM  <-----------------[ NeXTmail ]
+
Newsgroups: comp.sys.next.bugs
From: colin@agincourt.bsd.uchicago.edu (& Garrett)
Subject: Wherefore this group?
Organization: University of Chicago Computing Organizations
Date: Wed, 27 Jan 1993 15:50:27 GMT

If someone is not sure that a problem they are encountering is caused by a  
bug or not, it would seem most appropriate to place the note in a  
newsgroup dedicated to the subject (c.s.n.sysadmin, programmer, misc).   
And since 'bug' is a catch-all category for any unexplained unsatisfactory  
behavior, until the problem is resolved, almost anything is a bug  
candidate.  (What percentage of those "I think there's a bug in gcc..."  
notes pan out?)
On the other hand, if something has been proved to be a bug, the most  
suitable place for a note explaining it is probably a static locus like a   
FAQ (preferably archived), rather than a forum for dynamic discussion like  
a newsgroup.
Maybe that's why posts in here have been dwindling?

colin
Newsgroups: comp.sys.next.bugs
From: davisre@sage.cc.purdue.edu (Robert Davis)
Subject: /etc/mtab permissions
Organization: Purdue University Computing Center
Date: Sat, 23 Jan 1993 00:01:36 GMT


	This may have been mentioned before (I recently upgraded to
3.0), but is there a workaround or fix for this:  ejecting a mounted
floppy changes the permissions of /etc/mtab so that you can't do a df.

% df
Filesystem            kbytes    used   avail capacity  Mounted on
df: /etc/mtab: Permission denied


Rob
-- 
| Robert Davis                                    davis@sonata.cc.purdue.edu
| "Look up, Hannah.  Look up."                            NeXT Mail accepted
--
From: infidel+@CMU.EDU (Charles William Swiger)
Newsgroups: comp.sys.next.bugs
Subject: Re: NFS mounts -- time stamp problems?
Date: 26 Jan 93 14:53:43 GMT
Article-I.D.: andrew.QfNRoLC00YUnJYCTBk
Distribution: comp
Organization: Senior, Chemistry, Carnegie Mellon, Pittsburgh, PA

Excerpts from netnews.comp.sys.next.bugs: 25-Jan-93 NFS mounts -- time
stamp pr.. by Thorbjoern Andersen@imad 
> Apparently, date stamping works incorrectly when setting  stamps
> explicitly, instead of inheriting the dates from the file system.
>  
> Touching a file yields a date of January 1 1970, which is somewhat
> incorrect.   I *think* this is date Zero, but why should that be?

1/1/70 was chosen to be the "epoch" for Unix filesystems.  All of the
timestamps used count in seconds from epoch to the current time.

(Some trivia: the values are stored in 4-byte longs, meaning that the
time system will break in the year 2038.)

> Anybody got any suggestions for circumventing this problem?

I suspect that one or more machines on your network are having problems
with their clocks.  Make sure that you are using the Network Time
Protocol on all of the machines on the network.  NTP was explicitly
designed to help keep distributed filesystem's timestamps correct
between machines sharing files.

Consult your System's Administration manuals....

-Chuck



Charles William Swiger -- CMU...*crunch*! | "Foosh.  Aaughh!!"
------------------------------------------+ "Foosh.  Aauuggghh!!"
AMS & normal mail:        infidel@cmu.edu | "Cold spray deodorant...."
Failing that:        cs4w+@andrew.cmu.edu |
NeXTmail:   chuck@mon.slip.andrew.cmu.edu |  -- Opus, Bloom County [RIP]
Newsgroups: comp.sys.next.bugs
From: gemoe@proximus.north.de (Gerhard Moeller)
Subject: FontPanel select...
Organization: Gerhard Moeller, German NeXT User Group, Oldenburg.
Date: Tue, 26 Jan 1993 20:44:32 GMT

Hi,

either I'm stupid or...

It says in the 3.0 release notes:

 o The  FontPanel, when key,  will select  in the Family  scrolling list
   when you type the first few characters of a family name. 

But when I type letters they appear in the size field. No way to get the
damn thing working. 

	Any hints?
		Gerhard.

--
+---------------------------< principiis obsta! >---------------------------+
N  Gerhard Moeller, Teichstrasse 12, 2900 Oldenburg (FRG) [*: 02/21/1968]   N
e  Private: gemoe@proximus.north.de          Phone (voice): +49-441-75520   e
X  Uni:     Gerhard.Moeller@arbi.Informatik.Uni-Oldenburg.DE      NeXTmail  X
T  Z-Net:   Gerhard.Moeller@uniol.zer                          encouraged!  T
+-> NoGeNUG - Northern German NeXT User Group:  NoGeNUG@proximus.north.DE <-+
From: louie@sayshell.umd.edu (Louis A. Mamakos)
Newsgroups: comp.sys.next.bugs
Subject: Re: Group Problems w/3.0
Date: 28 Jan 1993 01:59:35 GMT
Organization: The University of Maryland, College Park
NNTP-Posting-Host: sayshell.umd.edu
Keywords: Group Netinfo Problems

In article <1993Jan27.135357.3950@nic.csu.net> vqueved@nextlab.calstatela.edu writes:
>Is there any on that is running into the Limit of:
>
>	A single user cannot belong to more than 14 groups.
>
>I send out some email about this and responses indicated that it was
>a problem with NetInfo only allowing 14 groups per user.

It is not a problem with NetInfo.  It is a compiled in limit of the
UNIX kernel.  If you look at /NextDeveloper/Headers/bsd/sys/param.h
(otherwise found in /usr/include/sys/param.h on sane computers),
you'll find:

#define NGROUPS 16              /* max number groups */

If you RTFM 'man 2 getgroups':

NAME
     setgroups - set group access list

DESCRIPTION
     Setgroups sets the group access list of the current user
     process according to the array gidset.  The parameter
     ngroups indicates the number of entries in the array and
     must be no more than NGROUPS, as defined in <sys/param.h>.


>Is there anyway to modify a file/profile/"sys_rc" file to allow up to 35  
>groups?

Nope.  You'd have to rebuild the UNIX kernel.  I'm very surprised that
16 groups isn't enough; perhaps you're not using them very
effectively?

Louis Mamakos
Newsgroups: comp.sys.isis
From: ken@cs.cornell.edu (Ken Birman)
Subject: Re: Purchase of Isis
Organization: Cornell Univ. CS Dept, Ithaca NY 14853
Date: Tue, 26 Jan 1993 13:59:37 GMT

In article <1993Jan26.041128.18221@bilby.cs.uwa.edu.au> kim@kowari.uwa.oz.au writes:
>  Could some one mail me the address for enquiries about
>  the purchase of the education version of Isis, I guess
>  it is version 2.7?
>

Main offices:
	Isis Distributed Systems Inc.
	111 South Cayuga Street
	Ithaca, New York 14850
	phone: 607-272-6327
	fax:   607-277-2611
	email: sla@isis.com (Sue Allen, Administrative assistant)

New York City:
	Isis Distributed Systems Inc.
	Cable Building
	611 Broadway, Suite 822
	New York, NY 10012
	
	phone: 212-979-7729 / 7809
	fax:   212-979-6880
	email: rjm@isis.com (Rick Moran, VP Marketing)

-- 
Kenneth P. Birman                              E-mail:  ken@cs.cornell.edu
4105 Upson Hall, Dept. of Computer Science     TEL:     607 255-9199 (office)
Cornell University Ithaca, NY 14853 (USA)      FAX:     607 255-4428
Newsgroups: comp.sys.isis
From: M.C.Little@newcastle.ac.uk (Mark Little)
Newsgroups: comp.sys.isis
Subject: Re: Challenges?
Keywords: client groups
Date: 26 Jan 93 13:50:14 GMT
Organization: Computing Laboratory, U of Newcastle upon Tyne, UK NE17RU


>>
>>... proposal for an idea in which a "group" can be a "client" ...
>>

>I really like this idea, and have not seen it in the literature.

I'm not sure if Ken means he has not seen this in the context of ISIS, but in case
that is NOT what he means (i.e., is being more general) I can say that here at Newcastle
we have been doing work on this for several years, and if anyone is interested I can
probably dig up a few references (and maybe some postscript papers).
I hope this is of some help,
Cheers,
Mark.
From: ken@cs.cornell.edu (Ken Birman)
Newsgroups: comp.sys.isis
Subject: Re: Challenges?
Keywords: client groups
Date: 25 Jan 93 16:05:56 GMT
Organization: Cornell Univ. CS Dept, Ithaca NY 14853

In article <1993Jan22.141440.14520@aplcen.apl.jhu.edu> jmp@ddsdx2.jhuapl.edu (Jim Pierce) writes:
>
>... proposal for an idea in which a "group" can be a "client" ...
>

I really like this idea, and have not seen it in the literature.
Offhand, I am not sure how hard it would be to support -- a pretty
substantial change to Isis V3.0, but perhaps something that would be
easier in Horus, which is more flexible and supports clients in a 
totally different way.

OK, so now we have requests for n-n communication support, and a
suggestion that this extend to allowing groups to be clients of
other groups.  Ae there other ideas in the same framework?  Discussion
on these ideas?

Basically, I am open to looking closely at this issue.  The main
problem is just the time needed to implement protocols supporting these
sorts of abstractions.  (Can they be supported efficiently OVER
the current scheme, for example?)

-- 
Kenneth P. Birman                              E-mail:  ken@cs.cornell.edu
4105 Upson Hall, Dept. of Computer Science     TEL:     607 255-9199 (office)
Cornell University Ithaca, NY 14853 (USA)      FAX:     607 255-4428
Newsgroups: comp.sys.isis
From: ken@cs.cornell.edu (Ken Birman)
Subject: Re: Challenges?
Organization: Cornell Univ. CS Dept, Ithaca NY 14853
Date: Fri, 22 Jan 1993 15:44:02 GMT

In article <8140004@otter.hpl.hp.com> pdh@otter.hpl.hp.com (Paul Harry) writes:
>(discussion of n-n communication issues)

Paul, this is an interesting issue.

First, having looked a bit at the problem, I am convinced that we could
support a fairly efficient n-n communication tool, using abcast to
send messages into each group, introducing a coallator for the 
duplicate messages coming in and the duplicate replies back to the
origin group, and using a multicast to send the reply to the origin
group instead of the current scheme, which sends to only the origin
process.  None of this would be hard.

However, two observations.  First, the cost of such a scheme will be
high.  Second, there may be a cheaper alternative with the same reliability
-- for example, the scheme that Robert Cooper, Barry Gleeson and I
wrote up in the TR on "process group semantics" (unpublished).  So, I
can see merit in supporting n-version programming and hence n-n
communications, but I am not 100% convinced that the need extends to
other fault-tolerance situations.

Question: can people point to applications in which response time is
so critical that detecting the failure and then restarting the
computation is too slow, and hence you need to use an n-n scheme
instead of a primary-backup scheme?  I know of a few such things,
but my theory is that you can localize them to servers, so you get
(single) client programs talking to replicated computations in the
server.  This is a 1-n pattern which you can easily solve in Isis,
so the n-n issue isn't really seen...

Comments?  I think we should probably add n-n programming tools anyhow,
but I am just curious to understand how commonly they would be needed!

-- 
Kenneth P. Birman                              E-mail:  ken@cs.cornell.edu
4105 Upson Hall, Dept. of Computer Science     TEL:     607 255-9199 (office)
Cornell University Ithaca, NY 14853 (USA)      FAX:     607 255-4428
Newsgroups: comp.sys.isis
From: ken@cs.cornell.edu (Ken Birman)
Subject: Misc. errata
Organization: Cornell Univ. CS Dept, Ithaca NY 14853
Date: Sun, 24 Jan 1993 19:01:50 GMT

Some errata:

  First, Pat Stephenson has pointed out that by posting the names of
  some of the Cornell graduates in the systems area, but not all, I
  could be putting the unlisted students at a disadvantage.  This
  is not what I intended, of course -- I just don't know exactly who
  is finishing up and when, outside the immediate area in which I work.
  Pat mentioned that Navin Budhiraja (fault-tolerance through primary/
  backup mechanisms; navin@cs.cornell.edu) and Wei Li (parallel compilation,
  wei@cs.cornell.edu) are finishing, but the best thing to do, if you
  want a full list, it to email to
	gfr@cs.cornell.edu (Sam Toueg)
  and request a list of graduating students, indicating whether you are
  doing a search for an academic position, an industrial position, or if
  you are a "head-hunter".

  NB: if people want to post job offerings here, I have no problem with
  the idea as long as it is not too common and the positions are in the
  distributed systems area.

Second:

  I should have mentioned the Manetho system in discussing the n-n programming
  model; Manetho is certainly relevant prior work.  This was done at Rice
  University; email to motaz@cs.rice.edu for a pointer to papers.

Last comment:

  I estimate that I am getting an average of 10-20 messages a day and that
  my group gets 30 or more per day, perhaps half of which are technical 
  questions about Isis or related software that might interest this group.
  These range from performance problems people have run into, to questions
  like the ones about how Isis compares with Lazy Replication, to questions
  about why we don't support one feature or another.  Some are bug reports
  but even these might interest readers of the newsgroup.

  Now, I repost some of these, but I really do want to urge people to
  post to comp.sys.isis rather than email to me if the question might be
  one others would find interesting.  This way, I don't get asked the same
  thing by 3 different people, and the newsgroup would be more interesting,
  too.

  I, for one, would also like to hear more about other systems, like the
  recent work on adding group mechanisms to Orca/Amoeba, the Transis project,
  and the Inesc activities, to name just a few.

  Since we have this newsgroup, and there really isn't a better place to
  just discuss distributed computing issues, we might as well use it!
  
-- 
Kenneth P. Birman                              E-mail:  ken@cs.cornell.edu
4105 Upson Hall, Dept. of Computer Science     TEL:     607 255-9199 (office)
Cornell University Ithaca, NY 14853 (USA)      FAX:     607 255-4428
Newsgroups: comp.sys.isis