Fun with cs.

Fun with cs.

[Dave]

that's what our cpurc has these days.

------ forwarded message follows ------

>From cse.psu.edu!9fans-outgoing-owner Thu Dec 14 09:41:27 EST 1995
Received: from psuvax1.cse.psu.edu by plan9; Thu Dec 14 09:41:27 EST 1995
Received: by psuvax1.cse.psu.edu id <34033>; Thu, 14 Dec 1995 09:04:54 -0500
Received: from cegelecproj.co.uk ([159.245.72.6]) by psuvax1.cse.psu.edu with SMTP id <34030>; Thu, 14 Dec 1995 09:04:34 -0500
Received: from vampire.cegelecproj.co.uk (cerberus.cegelecproj.co.uk) by cegelecproj.co.uk (4.1/SMI-4.1)
	id AA01087; Thu, 14 Dec 95 14:04:16 GMT
Received: from phantom.cegelecproj.co.uk (phantom.limbo.cegelecproj.co.uk) by vampire.cegelecproj.co.uk (5.0/SMI-SVR4)
	id AA09592; Thu, 14 Dec 1995 14:04:09 GMT
Received: by phantom.cegelecproj.co.uk (5.0/SMI-SVR4)
	id AA03988; Thu, 14 Dec 1995 14:04:05 GMT
Date:	Thu, 14 Dec 1995 09:04:05 -0500
From:	cegelecproj.co.uk!Steve_Kilbane (Steve_Kilbane)
Message-Id: <9512141404.AA03988@phantom.cegelecproj.co.uk>
To:	cse.psu.edu!9fans
Subject: Re: Fun with cs.
Content-Length: 463
Sender: cse.psu.edu!owner-9fans
Precedence: bulk
Reply-To: cse.psu.edu!9fans

Waaaay back in August, Vadim mentioned a workaround in /rc/bin/cpurc
for ndb/cs not handling net!$auth!ticket lookups. Is this workaround still
valid, and if so, can someone give me a more complete description? I'm
encountering this problem now.

It sounds to me like cpurc (and, I guess, termrc) should have

ndb/cs -n
sysname=`{cat /dev/sysname}
switch ($sysname) {
case myhost
	...
}
date >>/$cputype/log/$sysname
ndb/cs -n

Does this sound reasonable?

steve

Fun with cs.

[Steve_Kilbane]

Waaaay back in August, Vadim mentioned a workaround in /rc/bin/cpurc
for ndb/cs not handling net!$auth!ticket lookups. Is this workaround still
valid, and if so, can someone give me a more complete description? I'm
encountering this problem now.

It sounds to me like cpurc (and, I guess, termrc) should have

ndb/cs -n
sysname=`{cat /dev/sysname}
switch ($sysname) {
case myhost
	...
}
date >>/$cputype/log/$sysname
ndb/cs -n

Does this sound reasonable?

steve

Fun with cs.

[Vadim]

Last call to ndb/cs should be w/o -n.

--vadim

>From 9fans-outgoing-owner@cse.psu.edu Thu Dec 14 06:44 PST 1995
Return-Path: <9fans-outgoing-owner@cse.psu.edu>
Received: from postman.ncube.com by butler.ncube.com (5.0/SMI-SVR4)
	id AA28792; Thu, 14 Dec 1995 06:44:13 +0800
Received: from psuvax1.cse.psu.edu by postman.ncube.com (4.1/SMI-4.1)
	id AA04670; Thu, 14 Dec 95 06:44:12 PST
Received: by psuvax1.cse.psu.edu id <34033>; Thu, 14 Dec 1995 09:04:54 -0500
Received: from cegelecproj.co.uk ([159.245.72.6]) by psuvax1.cse.psu.edu with SMTP id <34030>; Thu, 14 Dec 1995 09:04:34 -0500
Received: from vampire.cegelecproj.co.uk (cerberus.cegelecproj.co.uk) by cegelecproj.co.uk (4.1/SMI-4.1)
	id AA01087; Thu, 14 Dec 95 14:04:16 GMT
Received: from phantom.cegelecproj.co.uk (phantom.limbo.cegelecproj.co.uk) by vampire.cegelecproj.co.uk (5.0/SMI-SVR4)
	id AA09592; Thu, 14 Dec 1995 14:04:09 GMT
Received: by phantom.cegelecproj.co.uk (5.0/SMI-SVR4)
	id AA03988; Thu, 14 Dec 1995 14:04:05 GMT
Date: 	Thu, 14 Dec 1995 09:04:05 -0500
From: Steve_Kilbane@cegelecproj.co.uk (Steve_Kilbane)
Message-Id: <9512141404.AA03988@phantom.cegelecproj.co.uk>
To: 9fans@cse.psu.edu
Subject: Re: Fun with cs.
Sender: owner-9fans@cse.psu.edu
Precedence: bulk
Reply-To: 9fans@cse.psu.edu
Content-Type: text
Content-Length: 464
Status: R

Waaaay back in August, Vadim mentioned a workaround in /rc/bin/cpurc
for ndb/cs not handling net!$auth!ticket lookups. Is this workaround still
valid, and if so, can someone give me a more complete description? I'm
encountering this problem now.

It sounds to me like cpurc (and, I guess, termrc) should have

ndb/cs -n
sysname=`{cat /dev/sysname}
switch ($sysname) {
case myhost
	...
}
date >>/$cputype/log/$sysname
ndb/cs -n

Does this sound reasonable?

steve

Fun with cs.

[Vadim]

In my setup ndb/cs refused to handle strings like
net!$auth!ticket.  The fix is to change /rc/bin/cpurc
to call ndb/cs -n before using sysname *and* call it
once again (instead of sending "add il tcp udp" to /net/cs)
after network initialization is complete.

I guess "add" command is broken somehow but have no wish
to investigate as the workaround is straightforward.

--vadim