Conference smurf::buildhelp

Date Of Receipt: 	29-MAR-1996 14:51:53.25
From: 	SMURF::WASTED::"[email protected]" "29-Mar-1996 1148"
To: 	[email protected]
CC: 	[email protected], [email protected], [email protected]
Subj: 	Re: Need Help with Shared Sandbox

=========================================================================
I'm trying to set up a new shared sandbox using ODE 3.0.  The instructions
are rather confusing, but I've got it to a point where I can build, bci,
and bco.  However, I can't bsubmit.  When I try I get the following error.
Can someone tell me what I've missed in my setup?

Thanks,

 --- pete

-----------------------------------------------------------------
Outdate files if successful submission? [Y]es, [N]o, [Q]uery later]: [Yes] n
[ ./kernel/atm/cmm/cmm_subr.c Rev 1.1.8.2 checked out ]
        ODE_SERVER: DECode client is not authorized!

        ODE_SERVER: Are you in a workon?


Please take appropriate steps and re-submit.

*** RE-SUBMISSION REQUIRED ***

- Source control information is in an intermediate state.
- Re-submit using -resub 15:21 [ -date 3/27/96 ]
-------------------------------------------------------------------

Pete,

This message suggests that you have a kerberos problem of some sort.
Let's start easy and go up from there.

Do you have a ticket on the subit server? Do a kinit -d
it will tell you which node it's going to for the ticket.

Verify the name of the shared sandbox server node and ip address.
Find out if the client or the server has more than one network interface
therefore 2 ip addresses most likely on different subnets. This was a 
common problem at zk aome time ago...

What does the /etc/krb.conf on the client look like?

Date Of Receipt: 	 1-APR-1996 13:13:02.40
From: 	SMURF::ALPHA::"[email protected]" "01-Apr-1996 1309"
To: 	[email protected]
CC: 	[email protected], [email protected], [email protected]
Subj: 	Re: Need Help with Shared Sandbox

Did you receive the information I sent on Friday?  Is there any more
information you need?  Any ideas on what's going on?

Thanks,

 --- pete

Date Of Receipt: 	 2-APR-1996 15:58:03.27
From: 	SMURF::ALPHA::"[email protected]" "02-Apr-1996 1255"
To: 	[email protected], [email protected]
CC: 	[email protected]
Subj: 	re: Need Help with Shared Sandbox

hi,

since i don't have access to buffer,
would someone check the kerberos.log on buffer
and look for entries for principal name
Peter_Schulter.

he's having problems submitting from
dogfish.zk3.dec.com to a shared
sandbox served by alphanzo.zk3.dec.com.

so far, haven't found anything wrong but it
looks like a possible kerberos problem.

thanks.
jo

Date Of Receipt: 	 5-APR-1996 11:37:52.64
From: 	SMURF::FLUME::jmf "Joshua M. Friedman OSF/UNIX SDE  05-Apr-1996 1135"
To: 	[email protected]
CC: 	odehelp@DEC:.zko.flume, [email protected], [email protected]
Subj: 	re: Need Help with Shared Sandbox

Pete, can you check to see if 
	rc_files/local.sharedsandbox  (or one of the others) defines

	replace source_host alphanzo

And also check that <sharedsb>/.sandboxrc exists and has a line like
	sb  sbname  local.sharedsandbox

If these settings don't exist, they should;  if they do exist, then the 
value that Jo reported,
		source_host	secret
is 1st defined from the global.rc_files, but then gets reset within the 
shared sandbox during the submit process.  If the variable is defined
in local.sharedsandbox, which I think is where it usually goes, a
user backed by the shared sb will not see this definition with "sbinfo";
the only way to see it is to workon the shared sandbox directly using
the switch  -sb_rc <path to local.sharedsandbox>.

-josh

------- Forwarded Message

To: [email protected], [email protected]
Cc: [email protected]
Subject: re: Need Help with Shared Sandbox 
Date: Wed, 03 Apr 96 17:13:14 -0800
From: [email protected]
X-Mts: smtp


hi,

can someone help Pete with the setup of their shared sandbox.

first it looked like it could be a Kerberos problem but it's not.

the shared sandbox has the following

	rcs_host	buffer
	submit_host	alphanzo
	source_host	secret

the src server and the submit server should be the same node.

the bsubmit was failing because his workon session is only authenticated to 
use 
the rcs server and the submit server.  when the submit got to the step to 
write 
to the log file, it was going to secret where he did not have authentication 
therefore the "not authenticated" error message.

jo


------- End of Forwarded Message