[comp.sys.sgi] appletalk on UNIX

doelz@urz.unibas.ch (Reinhard Doelz) (03/26/90)

Some time ago, this message has been posted: 

> From:       Jim Howard <KGJHH@ASUACAD.bitnet>
> Subject:    Columbia Appletalk Package

> Has anyone succesfully installed the Columbia Appletalk Package on
> a 4D series Iris? The package allows Mac users to view the Unix system
> as a file server and the Iris user the Laserwriters as Unix printers
> (via a Kinetics box).

Apparently no experience- at least no postings here so far. 
I'd like to do it myself, but I don't know where to get it from. 
Any help on ftp servers , mailbox adress etc. appreciated. 

- Reinhard 


************************************************************************
    Dr. Reinhard Doelz            *     EAN     doelz@urz.unibas.ch
      Biocomputing                *     DECNET  48130::doelz
Biozentrum der Universitaet       *     X25     psi%46211142::embnet
   Klingelbergstrasse 70          *     FAX     x41 61 256760
     CH 4056 Basel                *     TEL     x41 61 253880 ext 888
************************************************************************

root@sgzh.uucp (Bruno Pape) (03/27/90)

In article <253*doelz@urz.unibas.ch> doelz@urz.unibas.ch (Reinhard Doelz) writes:
>Some time ago, this message has been posted: 
>
>> From:       Jim Howard <KGJHH@ASUACAD.bitnet>
>> Subject:    Columbia Appletalk Package
>
>> Has anyone succesfully installed the Columbia Appletalk Package on
>> a 4D series Iris? The package allows Mac users to view the Unix system
>> as a file server and the Iris user the Laserwriters as Unix printers
>> (via a Kinetics box).
>

The problem of sharing LaserWriters on AppleTalk networks with UNIX workstations
can be solved rather cheaply and effectively by using one of the AppleTalk
Expanders available from:			Local Supplier:

		Inventab Products AB		WBS W. Buck
		Aldermansgatan 10		Bahnhofstr. 30, Postfach 253
		222 36 Lund			8157 Dielsdorf
		Sweden				Tel. 01/853-33-33

And to quote from the box,

"The LaserAccess is a high-speed interface allowing computers with a serial
interface to be connected to LaserWriters on LocalTalk.  LaserAccess allows
any computer with a RS-232 interface and a PostScript driver to use and
share LaserWriters on LocalTalk just like a Macintosh."

It might cost something like 1000 SFr.

I use one connected to a Sun as a network printer, and I'm a happy user.

BTW I would not wish a Unix filesystem on any normal Mac user.

Bruno

	-- If I don't have a quote for the day do I
	   have to sit in the back of the class again?

tim@merlin.bhpmrl.oz (Tim Monks) (03/28/90)

From article <253*doelz@urz.unibas.ch>, by doelz@urz.unibas.ch (Reinhard Doelz):
> Some time ago, this message has been posted: 
> 
>> From:       Jim Howard <KGJHH@ASUACAD.bitnet>
>> Subject:    Columbia Appletalk Package
> 
>> Has anyone succesfully installed the Columbia Appletalk Package on
>> a 4D series Iris? The package allows Mac users to view the Unix system
>> as a file server and the Iris user the Laserwriters as Unix printers
>> (via a Kinetics box).
> 

We have had CAP up and running for about 12 months now, and use it all the
time for printing (papif).  The following is my summary I regularly mail to
other users asking for guidance on building CAP. Note - we haven't bothered
building the file server part of CAP (aufs) because we find NCSA telnet
and ftp quite adequate. Secondly the configuration I mention is quite 
specific to our own small LAN, take those parts of the notes for guidance
only, and build in your own site addresses and node numbers.

Good luck,

Tim.

---------------------- NOTES ON BULDING CAP ON SG MACHINES ------------------


Here is some information on our SG + Kbox + KSTAR + CAP setup which may be
of help to you in getting papif up and running.


THE CONFIGURATION


    -	Class B ethernet with 0xfffff00 subnetting

    -	Various Apollos, VAXen, Silicon Graphics & Ethercard Macs hanging
	off this network (+ some other junk) together with a Kinetics
	FastPath 4 with rev 4.1 PROMS.

    -	A FastPath4 running KSTAR rev 4.1 with the following configuration:
	LocalTalk Side:
		Zone Name	IPADA group
		Net Number 	2
		Node Number	220
	Ethernet Side:
		Zone Name	BHP-ETH
		Net number	1
		Node Number	166
	UDP Side:
		Zone Name	BHP-ETH
		Net number	3
		Node Number	243
	IP Info:
		IP Address of KFP	134.18.1.243
		IP Subnet mask		255.255.255.0
		Broadcast Address	0.0.0.0
		IP address of router	0.0.0.0
		IP Address of admin	0.0.0.0
	No servers, routers, administrators
	No option flags set nor option parameters.

    -	atalk.local has the following :

		# /etc/atalk.local configuration file

		# host's appletalk network, node and zone (Ethernet side)
		3 240 BHP-ETH

		# bridge's appletalk network, node & IP address (UDP side)
		3 243 134.18.1.243

    -	cap.printers has the following :
		# These are all the same printer
		mozart=IPADA Laserwriter :LaserWriter@IPADA group
		PostScript=IPADA Laserwriter :LaserWriter@IPADA group
		ps=IPADA Laserwriter :LaserWriter@IPADA group

	
    -	/etc/services has the following UDP ports declared :
		rtmp	769/udp
		nbp	770/udp
		echo	772/udp
		zis	774/udp
	These are the old style mappings which the current KSTAR version
	supports.  Sometime in the future these may have to be changed to
	201, 202, 204 and 206 but I don't know when.


WHAT WE DON'T HAVE

We have not got the AppleTalk Adminstration Daemon atalkad running on
the SG (because we haven't got a copy of this :-(, but I believe that
this daemon is only required for KIP and not KSTAR.  I believe that 
atalkad serves two purposes. The first one is to let KIP-equipped Kboxes 
and all other gateways know where all the AppleTalk nets are - the AT to IP 
mapping. Secondly (and separately), when you're running IP-in-AT 
(CAP is AT-in-IP), i.e. running NCSA Telnet to log into the Unix machines 
from the Mac, every Kbox needs to know which IP addresses the other boxes 
are using or it stomps (claims) them. This is not a bug, but a result of 
the protocol.


WHAT I'VE DONE TO GET CAP COMPILED...

1.	Applied patch0004 in ./bugs as this seemed relevant to papif.c.
	There was also another patch that came across USENET News on papif.c
	from Jeff Stearns so I applied this as well.

2.	Changed cc def in conf.func.sh to include the flags 
		-I=/usr/include/bsd -lbsd

3.	Changed cc def in conf.sysv.sh to include the flags 
		-I=/usr/include/bsd -lbsd

4.	Changed defs of several things in the Configure script, namely :
	PNM=/bin/nm		---->	PNM=/usr/bin/nm
	/lib/libc.a		---->	/usr/lib/libc.a
	ETCDEST=/etc		---->	ETCDEST=/usr/local/lib/cap
	lpd="bsd"		---->	lpd="lp"
	[libspecial],[]		---->	[libspecial],[-lbsd]
	[sysvinstall],[]	---->	[sysvinstall],[yes]
					(had to edit all the Makefile.m4
					 scripts to remove the final
					 $(DESTDIR) from the install line.)
	[capprinters] now points to /usr/local/lib/cap/cap.printers
	[pstextlocal] now points to /usr/local/lib/ps/psrev
					(had to edit appli*/papif/Makefile.m4
					 to escape the quotes in the defn. of
					 WPSTEXT.)


5.	Added the following lines to netat/compat.h
		#define sigblock sighold
		#define sigsetmask sigrelse


6.	Because the SG is a BIGENDIAN machine had to remove the definition
	of SWAPBYTES in netat/abnbp.h

7.	In file lib/afp/afposlock.c undefined F_OK, X_OK, W_OK & R_OK
	before including the types.h file because otherwise these were
	redefined giving a compilation warning.

8.	Possibly a few other things I haven't remembered...

9.	Ran Configure with standard BSD and WITH output to LaserWriter 
	throttled.



THE RESULTS

Doing this I successfully compiled the libraries, all the sample programs 
and papif & lwsrv (aufs crashed with fsync & initgroups undefined on linking 
aufs...) I have been told the following ...

fsync() is the BSD system call for guaranteeing that all in-memory disk
buffers associated with a particular file is written out to disk.  There
is no System V  equivalent to it.  Generally, this call is not required
since Unix takes care of most of the disk/memory synchronization operations.
The only cases where programs explicitly calls fsync() is for reliability
purposes (e.g. sendmail uses it to make sure mail messages are on disk
before acknowledging receipt of it).  If you are willing to forego that
reliability (it really is only important if the system crashes during the
fsync() operation anyway), you can probably just comment it out.  If you
are willing to pay a fairly high price (performance-wise), you can use the
sync() function in System V, which flush *all* disk buffers for *all* files.

initgroups() is another BSD-specific feature.  In BSD Unix, a user can be
in several groups simultaneously.  For example, if there are two files A and
B, where A is protected to be readable only by group "staff" and B only by
group "operator", the user can access both these files if he belongs in both
groups.  In System V, a user can only be in one group at a time.  He can
access file A if he is in group "staff", but he must execute the "newgrp"
command before he can access file B.  initgroups() is the function which
adds group identifications to a process when it is activated (for example,
at login time or remote shell execution time).  Since System V does not
support multiple simultaneous group access, you can just comment that out.


PRINT SPOOLING

If you've got this far now you can get into the hairy bits of SYSV lp spooling.
But it will should give you what you want: the ability to spool output to a 
LaserWriter sitting on a localtalk net from your SGI machine thru a kbox.
Here is a sketch of what it takes.  

	-  You must have the TRANSCRIPT package by Adobe or something
	   similar (We have the SG laser support utility - however there
	   are PD progs around which do the same thing).  papif uses
	   routines from this package to wrap PS prologues around non-
	   PostScript ie. ASCII files.

	-  Use the mkPS script (which came with the SG Laser support util)
	   to make a spooled printer known to the lp spooler.  Then hack
	   the interface file so data is shunted out to the papif filter 
	   and not to some serial port.  If you get stuck here I can give
	   you the scripts I generated which work for us.


FINALLY...

Good luck - CAP was a cantankerous beast to get going, however its been 
working for us trouble-free (touchwood) for several months now.  If you 
need any help give me a yell.

------------------END OF NOTES ON BULDING CAP ON SG MACHINES ---------------



> Apparently no experience- at least no postings here so far. 
> I'd like to do it myself, but I don't know where to get it from. 
> Any help on ftp servers , mailbox adress etc. appreciated. 
> 
> - Reinhard 
> 
> 
> ************************************************************************
>     Dr. Reinhard Doelz            *     EAN     doelz@urz.unibas.ch
>       Biocomputing                *     DECNET  48130::doelz
> Biozentrum der Universitaet       *     X25     psi%46211142::embnet
>    Klingelbergstrasse 70          *     FAX     x41 61 256760
>      CH 4056 Basel                *     TEL     x41 61 253880 ext 888
> ************************************************************************


As a last resort I can mail uuencoded shar files of the original CAP 
listings, but I'd prefer not to clog up the network any more than I've done
already :-)


		Tim.



-- 
Dr. Tim Monks                                

Image Processing & Data Analysis Group   |   (direct) (+61-3)566-7448
BHP Melbourne Research Laboratories      |   (switch) (+61-3)560-7066
245 Wellington Rd, Mulgrave, 3170,       |   (fax)    (+61-3)561-6709
AUSTRALIA                                |   (EMAIL)  tim@merlin.bhpmrl.oz.au