HDTenEightyP/NetNews huggingface dataset:
From: glen@Cayman.COM (Glen B. Glater)
Newsgroups: comp.protocols.appletalk
Subject: Re: Monitoring Appletalk File Sharing activity
Date: 25 Jan 93 23:21:30 GMT
Organization: Cayman Systems Inc., Cambridge, MA
In-reply-to: jbaxter@leland.Stanford.EDU's message of 24 Jan 93 05:28:18 GMT

In article <1993Jan24.052818.27263@leland.Stanford.EDU> jbaxter@leland.Stanford.EDU (Joel Kent Baxter) writes:

  >
  >This is a simple question about available Appletalk monitoring programs.  From
  >what I know about Appletalk, it should be no big deal for a Mac with file
  >sharing on to determine
  >
  >	- Which computers, from which zones, are accessing it
  >	- Which items on the shared disk/folder/whatever are in use
  >
  >In other words, info above and beyond the Guest/Owner/Registered User name
  >list in the File Sharing Monitor.  Has someone already written up an application
  >to make this info available on some sort of dynamic display, or failing that,
  >in a log file?  Surely I'm not the first person to be curious about this sort
  >of thing...

You are talking about Nok Nok from Trik.  Very cool product.

Glen
--
     **************************************************************
     _/_/_/_/  _/_/_/_/  _/      _/  _/      _/  _/_/_/_/  _/    _/ 
     _/        _/    _/    _/  _/    _/_/  _/_/  _/    _/  _/    _/ 
     _/        _/_/_/_/      _/      _/  _/  _/  _/_/_/_/  _/_/  _/ 
     _/        _/    _/      _/      _/      _/  _/    _/  _/  _/_/ 
     _/        _/    _/      _/      _/      _/  _/    _/  _/    _/ 
     _/_/_/_/  _/    _/      _/      _/      _/  _/    _/  _/    _/ 
     Cayman Systems, Inc. * 26 Landsdowne St * Cambridge, MA  02139 
     Glen B. Glater                      Technical Support Engineer
     Phone: (617) 494-1999                    Fax:   (617) 494-5167         
     Internet: glen@cayman.com              AppleLink:  CAYMAN.TECH	      
Xref: sparky comp.protocols.appletalk:4542 comp.sys.mac.comm:13522
From: lums@hooper.cse.nd.edu (Andrew Lumsdaine)
Newsgroups: comp.protocols.appletalk,comp.sys.mac.comm
Subject: Answer: Apple Remote Access ?
Date: 27 Jan 93 15:23:35 GMT
Reply-To: lums@hooper.cse.nd.edu (Andrew Lumsdaine)
Organization: University of Notre Dame, Notre Dame

David Hornsby <djh@cs.mu.oz.au> and Mats Wikstr|m <gucmw@gd.du.se>
both pointed me to the ARNS package, available via FTP from 
munnari.oz.au as mac/arns.tar.Z.  Using the IPRemoteAT client
in conjunction with MacTCP/MacPPP, I can dial into my unix box 
and transparently access our appletalk network -- including our 
AUFS directories.  What's really nice about this solution is that
first, it's free (ARA is $199), second, since I have the MacTCP
connection, I am also transparently connected to the internet.

All the information you need comes with the ARNS distribution.

Naturally, because of the serial connection, it is somewhat slow.
Copying a 50k file from an AUFS directory to my local mac disk
took 60 seconds, about .9k bytes/sec.  That's not bad throughput
(the modem connection was 14.4k), considering how many layers 
are involved.

-- 

--------------------------------------------------------------------
 Andrew Lumsdaine
 Dept. Comp. Sci. & Engr.            email: Andrew.Lumsdaine@nd.edu
 353 Fitzpatrick Hall                phone: (219) 631-8716
 University of Notre Dame              fax: (219) 631-8007
 Notre Dame, IN  46556
--------------------------------------------------------------------
Newsgroups: comp.protocols.appletalk
From: mannemel@CS.ColoState.EDU (devakumar mannemela)
Subject: CAP6.0 patch level 125 and  SGI IRIX 4.0.5
Date: Thu, 21 Jan 1993 19:20:13 GMT
Organization: Colorado State University, Computer Science Department

Hi !

We are trying to install CAP 6.0 on our SGIs here and have been facing some
problems. If some one has recently done this successfully,  we  would like
to talk to you.

The problem has been isolated to UAB6.0 and the problem is that
AARP module  doesn't recognize the two macintoshes on the network.
Previously UAB5.0 was able to recognize the macs, but for some reason
UAB6.0 is not able to do the same. 

So  if some  one  has installed  CAP6.0 ( and UAB 6.0) successfully,
we would like to talk to them ( or please post your impressions
on the problem ). 

Thanks,
Dev

-- 
1109 Justin Avenue			Tel: (213)-255-0900 (O)
Glendale CA 91201			     (818)-500-7006 (R)
Newsgroups: comp.protocols.appletalk
From: adam@research.nj.nec.com (Adam Porter)
Subject: Multiple Interfaces for CAP???
Originator: adam@acapella
Reply-To: adam@research.nj.nec.com
Organization: NEC Research Institute
Date: Mon, 25 Jan 93 19:20:00 GMT


Hi everybody,

I'm currently running CAP, v. 6.0, pl125, on a SparcServer.  This
machine has 2 ethernet interfaces.  I'm running CAP on interface ie1,
but I'd also like to run it on ie0.  What do I need to do?  Which
programs have to have 2 copies running and which can be shared?  How
do I set it up?  MANY THANKS!

-- 
--								-Adam
==========================================================================
Adam Porter, Assistant System Administrator       adam@research.nj.nec.com  
NEC Research Institute:609/951-2568  4 Independence Way,Princeton,NJ,08540
Newsgroups: comp.protocols.appletalk
From: poorman@convex.com (Peter Poorman)
Subject: Re: NFS for Macintosh
Organization: CONVEX Computer Corporation, Richardson, Tx., USA
Date: Sun, 24 Jan 1993 16:07:32 GMT
X-Disclaimer: This message was written by a user at CONVEX Computer
              Corp. The opinions expressed are those of the user and
              not necessarily those of CONVEX.


>In <1993Jan23.032758.7492@netcom.com> proact@netcom.com (Proactive Software) writes:

> Is there a NFS
>product for the Macintosh that uses the MacTCP drivers and etherTalk?

I recently purchased the Wollongong product.  I'm happy with it, however my
usage is only for binary data.  

They offer a 30-day no-charge evaluation -- give 'em a call.  (415)962-7100.

-- Pete Poorman
   poorman@convex.com
Newsgroups: comp.protocols.appletalk
From: mosedale@yeahbut.stanford.edu (Dan Mosedale)
Subject: Re: Need info about setting a Unix Appleshare server
Organization: Stanford Yeast Genome Project
Date: Tue, 26 Jan 93 23:12:30 GMT

henrik@uk.locus.com (Henrik Kristensen) writes:
>
>Locus Computing has currently no plans to port PC-Interface for
>Macintosh to IRIX.

How about DEC Ultrix on a MIPS chip, and/or OSF/1 on an Alpha?

-Dan Mosedale
mosedale@genome.stanford.edu
Newsgroups: comp.protocols.appletalk
From: traurig@ncavax.decnet.lockheed.com (Scott Traurig)
Subject: Novell Appletalk Printer Queues and Papif
Followup-To: comp.protocols.appletalk
Date: Fri, 22 Jan 93 14:00:37 GMT

    Is anyone using, or know how to make work, papif with Novell Netware
3.xx AppleTalk printer queues? My Mac's can't tell them apart from actual
AppleTalk printer entities, but papif always gives an idle timeout.

    I tried setting the watchtime environment variable to zero, but then
papif just hangs instead of timing out.

    My environment is CAP 6.0 patchlevel 126 under SunOs 4.1.2.

                    Thanks,
                            Scott (traurig@ncavax.decnet.lockheed.com)
From: dstine@cisco.com (David Stine)
Newsgroups: comp.protocols.appletalk
Subject: Re: AppleTalk phase 2 & cisco routers
Date: 22 Jan 1993 01:15:19 GMT
Organization: 9th Flying Pig Combat Squadron
NNTP-Posting-Host: glare.cisco.com

In article <1993Jan21.201913.15722@gordian.com> johnk@gordian.com (John Kalucki) writes:
>In article <93020.123807P88038@BARILVM.BITNET>, Noam G. Nudelman <P88038@BARILVM.BITNET> writes:
>>
>>   Are there any known routing problems with cisco routers and
>>Appletalk Phase 2 ?
>>
>I would not recommend version 8.2(6) as we've found a few Appletalk
>bugs in it. We're upgrading to the latest version. Hopefully
>all will go well.

Indeed, there were some problems with the 8.2 release with respect to
AppleTalk.

We're no longer shipping 8.2(anything), as it is long since obsolete.

Current shipping versions of router software are 8.3, 9.0 and 9.1. Note
that 8.3 is the last release to support the CSC/2 processor and 9.1 is the
last release to support the CSC/3 processor.

dsa
AppleTalk Enginerd
From: km@mathcs.emory.edu (Ken Mandelberg)
Newsgroups: comp.protocols.appletalk
Subject: High Performance Mac NFS fileservice?
Date: 24 Jan 1993 18:36:03 GMT
Organization: Emory University, Dept of Math and CS
Distribution: world
Reply-To: km@mathcs.emory.edu
NNTP-Posting-Host: km-sl.cc.emory.edu

Do any of the appleshare fileservice via NFS compete in speed with
native appleshare service over ethertalk? Our only experience is with

		MAC->(ethertalk)->gatorbox->(nfs)->Sun

which the Mac intensive people say is much slower that fileservice from
a native appleshare server. Our gatorbox is rather old so this may not
be a state of the art comparision.

We don't have any experience at all with nfs running on the Mac
itself.



---
Ken Mandelberg      | km@mathcs.emory.edu          PREFERRED
Emory University    | {rutgers,gatech}!emory!km    UUCP 
Dept of Math and CS | km@emory.bitnet              NON-DOMAIN BITNET  
Atlanta, GA 30322   | Phone: Voice (404) 727-7963, FAX 727-5611


Newsgroups: comp.protocols.appletalk
From: djh@cs.mu.OZ.AU (David Hornsby)
Subject: Re: Why does atis burn so much CPU time ??
Organization: Computer Science, University of Melbourne, Australia
Date: Thu, 28 Jan 1993 15:50:57 GMT

e-sink@uiuc.edu (Eric W. Sink) writes:
>According to ps, on our RS/6000 system, atis is using tremendous
>amounts of cpu cycles, even when no one is using the system.

The atis process handles ECHO and NBP packets for the CAP node. When
using CAP in Native EtherTalk mode it also sees every RTMP packet.

The amount of cpu consumed by atis will vary widely depending on how
busy your network is and how many NBP names are registered on the host.
In an attempt to quantify "tremendous amounts of cpu cycles" the two
closest RS/6000s have used 3 and 11 cpu minutes per month for a 20-30
user zone. These figures are the same order of magnitude as 'init' ...

 - David.
Newsgroups: comp.protocols.appletalk
From: epeisach@athena.mit.edu (Ezra Peisach)
Subject: Re: Papif (CAP 6.0/126) problems *almost* solved! (Q)
Organization: Massachusetts Institute of Technology
Date: Wed, 27 Jan 1993 02:52:42 GMT

I am working out patches to such programs as papif, lwpr, etc. that will
allow one to safely install them setuid root. In my opinion, changing 
the device permissions and setgid the program is the wrong solution as
it still might compromise security.

lwpr was easy, papif has to deal with all the forking etc. Essentially
after the PapOpen, you are free to setuid to the normal user and still
access the device.

Solution with patch available sometime next week.

	Ezra Peisach

Newsgroups: comp.protocols.appletalk
From: smb@pern.cc.purdue.edu (Scott M. Ballew)
Subject: When do I need an IPTalk network?
Organization: Purdue University
Date: Thu, 21 Jan 1993 19:53:06 GMT

I have been given responsibility for many of our FastPaths here and,
after RTFM'ing as much as I can find, I have a question (or maybe
two).  I know that I need an IPTalk network port (N or H line)
configured in my atalkatab file for each FastPath that supports an
IPTalk-based CAP host.  This is clear and obvious.  I _think_ I do
_not_ need one for the FastPaths that will be doing IP encapsulation
across our IP-only backbone if they are not supporting CAP hosts.  Is
this correct?  For example, consider the following two FastPaths on a
subnetted class B network:

1.1 K	128.210.1.1 "PUCC-Local1"	# LocalTalk port
2.1 E	128.210.1.1 "PUCC-Ether1"   	# EtherTalk phase 1 port
    	<miscellaneous configuration details for this box>

1.2 K	128.210.2.1 "PUCC-Local2"   	# LocalTalk port on box 2
2.2 E	128.210.2.1 "PUCC-Ether2"   	# EtherTalk phase 1 port, box2
    	<miscellaneous configuration details for this box>

Assuming an IP-only network connects these two subnets, can Macs on
each network communicate with all others Macs on other networks or do
I need to add lines like:

3.1 H	128.210.1.1 "PUCC-IP1"	    	# IPTalk port
3.2 H	128.210.2.1 "PUCC-IP2"	    	# IPTalk port, box 2

Any help would be appreciated.

Thanks,
Scott M. Ballew
PUCC Networking
From: henrik@uk.locus.com (Henrik Kristensen)
Newsgroups: comp.protocols.appletalk
Subject: Re: Need info about setting a Unix Appleshare server
Date: 21 Jan 93 10:53:50 GMT
Organization: The Internet


[Tero Siili writes:]
> 
> A couple of questions to Henrik Kristensen:
> 
> - When will PC-Interface be available for SGi/IRIX?

Locus Computing has currently no plans to port PC-Interface for
Macintosh to IRIX.

However, I seem to recall that SGI has licenced an AppleTalk stack with
the intent of providing an AppleShare server for IRIX.

> - Does PC-Interface fully support system 7 aliases (CAP does not)

Yes.

> - What is the technical solution on the unix side to data fork/resource 
> fork division and retention of Finder information?  Similar to CAP
> (separate, parallel directories) perhaps?

I am not that familiar with CAP, but PC-Interface for Macintosh will store
the Finder information and resource fork in a subdirectory to the
folder-directory (where the data fork is stored).

> 
> Tero Siili

-- 
Henrik Kristensen                         henrik@uk.locus.com

Locus Computing Corporation ltd, 2 The Waterhouse,
Waterhouse Street, Hemel Hempstead, Hertfordshire HP1 1ES, UK
Tel: +44 442 236111, fax: +44 442 236453
Send support questions to: uk-support@uk.locus.com
From: srp@cgl.ucsf.edu (Scott R. Presnell)
Newsgroups: comp.protocols.appletalk
Subject: Re: Why does atis burn so much CPU time ??
Date: 28 Jan 93 16:44:08 GMT
Organization: UCSF Computer Graphics Lab

caywood@teb.larc.nasa.gov (John Caywood) writes:

>In article <C1807v.KpC@news.cso.uiuc.edu>, e-sink@uiuc.edu (Eric W. Sink) writes:
>|> According to ps, on our RS/6000 system, atis is using tremendous
>|> amounts of cpu cycles, even when no one is using the system.
>|> Is this normal ?
>|> 
>Must be normal -- I see the same behavior on Sun Sparc 2.

No. I don't see atis gain much time at all on our Iris 4D.  It's a quiet
zone with two to seven local registrants.  We are served by a rebroadcast
from a second class B network (where the FastPath resides).

-- 

	- Scott Presnell (srp@cgl.ucsf.edu)
Newsgroups: comp.protocols.appletalk
From: kjetilo@bilbo.uio.no (Kjetil Otter Olsen)
Subject: AppleTalk/PC
Organization: University of Oslo
Date: Fri, 22 Jan 1993 01:17:23 GMT



Does anyone get Apple's AppleTalk/PC card and NCSA Telnet (or other
PD TCP/IP variants like KA9Q or MS-Kermit) to work together ??

Any clues or examples are VERY velcome!

Thanks in advance.

Answers in mail, please.

Best regards,

   Kjetil

-----
Kjetil Otter Olsen                            kjetilo@usit.uio.no
Senior Communication Engineer,     M.Sc.,   C.Sc.
Center for Information Technology Services (USIT), University of Oslo
-----
Newsgroups: comp.protocols.appletalk
Subject: How to rebuild desktop database on a CAP volume?
From: rsilverman@eagle.wesleyan.edu (Richard E. Silverman)
Date: 28 Jan 93 17:13:18 EDT
Distribution: world
Keywords: desktop database file CAP

Didn't find an FAQ, so here goes: How do I go about rebuilding
the desktop database on a CAP volume?  Can't find it in the 
documentation... thanks for any help!

                                                Richard Silverman

Internet:  rsilverman@eagle.wesleyan.edu        CS grad student
Bitnet:    rsilverman@wesleyan.bitnet           Wesleyan University
phone:     346-3432 ext. 3291                   Middletown, CT 06457

Newsgroups: comp.protocols.appletalk
From: jbaxter@leland.Stanford.EDU (Joel Kent Baxter)
Subject: Re: Monitoring Appletalk File Sharing activity
Organization: DSG, Stanford University, CA 94305, USA
Date: Tue, 26 Jan 93 01:38:45 GMT

In article <GLEN.93Jan25182130@midway.Cayman.COM> glen@Cayman.COM (Glen B. Glater) writes:
>In article <1993Jan24.052818.27263@leland.Stanford.EDU> jbaxter@leland.Stanford.EDU (Joel Kent Baxter) writes:
>
>  >
>  >This is a simple question about available Appletalk monitoring programs.  From
>  >what I know about Appletalk, it should be no big deal for a Mac with file
>  >sharing on to determine

etc., etc...

>You are talking about Nok Nok from Trik.  Very cool product.
>
>Glen
>--
>     **************************************************************
>     _/_/_/_/  _/_/_/_/  _/      _/  _/      _/  _/_/_/_/  _/    _/ 
>     _/        _/    _/    _/  _/    _/_/  _/_/  _/    _/  _/    _/ 
>     _/        _/_/_/_/      _/      _/  _/  _/  _/_/_/_/  _/_/  _/ 
>     _/        _/    _/      _/      _/      _/  _/    _/  _/  _/_/ 
>     _/        _/    _/      _/      _/      _/  _/    _/  _/    _/ 
>     _/_/_/_/  _/    _/      _/      _/      _/  _/    _/  _/    _/ 
>     Cayman Systems, Inc. * 26 Landsdowne St * Cambridge, MA  02139 
>     Glen B. Glater                      Technical Support Engineer
>     Phone: (617) 494-1999                    Fax:   (617) 494-5167         
>     Internet: glen@cayman.com              AppleLink:  CAYMAN.TECH	      

Well, it seems to be unanimous!  Thanks for all the email responses and
postings.

                   JB

Newsgroups: comp.protocols.kerberos
From: john@iastate.edu (John Hascall)
Subject: Re: Scalability issues with Kerberos
Organization: Iowa State University, Ames, IA
Date: Sun, 24 Jan 1993 03:41:19 GMT

I wrote:
> Although the load isn't constant over 24 hours, it doesn't vary as much
> as you might think:

Marc Horowitz <marc@MIT.EDU> writes:
}I see a peak when 9-5'ers get in in the morning, and another peak when
}students get out of class.  And the fact that students have no
}discernible daily cycle accounts of the 1000+ requests at every hour
}of the day.  I doubt intel would have such a distribution.

Well, I did a little more work -- I added code in our Kerberos server to
measure the time from request-arrival to reply-departure.  I'll let
it run Monday for some real data, but here's what the first 6 minutes
of running it this evening gave (yes, another gruesome ascii chart):

     90+             *               Time from Request to Reply
       |             *                 (in 256ths of a second)
     80+             *
       |             *
     70+             *
       |             *
 C   60+             *
 o     |             *
 u   50+             *
 n     |             *
 t   40+             *
       |           * *
     30+           * *
       |           * *
     20+           * * *
       |           * * *
     10+           * * *
       |           * * *           * * *   * * *
      0+-*-*-*-*-*-+-+-+-*-*-*-*-*-+-+-+-*-+-+-+-*-*-*-*-*-*-*-*-*-*-*-*-*-
         0 1 2 3 4 5 6 7 8 9 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 3
                             0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2

As you can see, it generally takes our server (an 8MB DS2100 [~8 Specmarks]
with a not-very-fast RZ55 disk) about 6/256 (0.023) sec to service a request.
One might hypothesize that using a modern workstation as a Kserver you should
be able to handle more than 100 requests per second.  I suppose if you needed
more oomph, you could rewrite the server to be multi-threaded (*shudder*).

John
-- 
John Hascall                   ``An ill-chosen word is the fool's messenger.''
Systems Software Engineer
Project Vincent
Iowa State University Computation Center  +  Ames, IA  50011  +  515/294-9551
Newsgroups: comp.protocols.kerberos
From: HEEMSTRA@RC.RUG.NL ("Mente H. Heemstra")
Subject: Re: What's the use of .klogin ?? (Conclusion)
Reply-To: M.H.Heemstra@RC.RUG.NL
Organization: Internet-USENET Gateway at Stanford University
Date: Wed, 20 Jan 1993 08:55:29 GMT

Thanks for all your reactions; they set me thinking, and I found out at last
how it works:

    1) for services in local realm:

        - go to host2
        - run ext_srvtab host2
        - install host2-new-srvtab in /etc/athena/srvtab

    2) for services in remote realm:

        - go to host1
        - create rcmd.host2
        - run ext_srvtab host2
        - transfer the host2-new-srvtab to host2
        - go to host 2
        - concatenate /etc/athena/srvtab with the host2-new-srvtab from host1

    3) to connect:

        - go to host1
        - run kinit (local realm)
        - run rlogin host2 -k realm_of_host1 and there you are logged in to
          host2 using your local authentication.

What I wished for really was cross-realm authentication and that doesn't seem
to be working.
What eventually appears to work is installing two keys (from different realms)
onto a host.
Of course, this shouldn't be the way to go ....: imagine the size and
complexity of the srvtabs if you wish to communicate mainly on the basis of
kerberos security at a university where there is a lot of inter-faculty
traffic and each faculty runs its own kerberos server ....
This will, I expect, undermine security severely, and I pity the
administators ....

Mente H. Heemstra

P.S.: special thanks to Steve Dyer who pointed out to me what I wanted in
      the first place.

 _______________________________ ____________________________________________
|                               |                                            |
| Mente H. Heemstra             |    Email : M.H.HEEMSTRA@RC.RuG.NL          |
| State University Groningen    |    Bitnet: HEEMSTRA@HGRRUG5.BITNET         |
| Computing Centre              |    X.400 : C=NL; ADMD=400net; PRMD=SURF;   |
| Network Management            |            O=RuG; OU=RC; S=HEEMSTRA; I=MH; |
| P.O. Box 800                  |    Phone : + 31 50 633433/638080           |
| 9700 AV  Groningen            |    Fax   : + 31 50 633406                  |
| Netherlands                   |                                            |
|_______________________________|____________________________________________|
From: eliel@stanley.cis.Brown.EDU (Eliel Mamousette)
Newsgroups: comp.protocols.kerberos
Subject: v4 Kerberos DLL for windows?
Date: 21 Jan 1993 07:55:06 GMT
Organization: Brown University
Distribution: world
NNTP-Posting-Host: stanley.cis.brown.edu

Hello,

While I wait for the next batch of compilation errors, I was wondering
if anyone else had attempted (and, preferably, succeeded) in porting
the v4 kerberos client code to windows.  A dll is desired, but
.lib files are okay as well.

Thanks,
	eliel

--
Eliel Mamousette, Systems Development Group
Brown University Computing & Information Services
Email: Eliel_Mamousette@Brown.Edu
Post: CIS Box 1885 Brown University 115 Waterman St. Providence, RI 02906

Newsgroups: comp.protocols.kerberos