[Search for users]
[Overall Top Noters]
[List of all Conferences]
[Download this site]
Title: | USG buildhelp questions/answers |
|
Moderator: | SMURF::FILTER |
|
Created: | Mon Apr 26 1993 |
Last Modified: | Mon Jan 20 1997 |
Last Successful Update: | Fri Jun 06 1997 |
Number of topics: | 2763 |
Total number of notes: | 5802 |
1804.0. "Mark, can you help Farrell" by AOSG::FILTER (Automatic Posting Software - mail to flume::puck) Mon Sep 11 1995 16:59
Date Of Receipt: 11-SEP-1995 14:48:53.12
From: SMURF::FLUME::"[email protected]"
To: flume::ftw, flume::glidden
CC: anderson@DEC:.zko.flume, flume::odehelp, flume::jmf
Subj: Mark, can you help Farrell
Could you change your kinit to go out
to labrea? If necessary labrea could
be a slave. Mark Glidden could set this
up for you. I know this isn't the real
solution to the multi-homed problem, but
a possible workaround for the immediate.
I don't understand why you didn't have this
problem in v2.2. Since the change in v3.0
was to just move the kerberos sendauth() to
workon instead of the "b" commands. The
problem is kerberos, and kerberos did not change.
The imbedded address of your machine in the
kinit ticket needs to be the same address
on the socket connect to the server
Your kinit: uses buffer
Your server connect: uses labrea (I believe)
Your machine is going out a different IP address
to labrea then it is using for buffer.
Thus the 2 address's don't match. The ticket has
imbedded an address, and the socket also has the
address.
ODE_SERVER: Receiveing kerberos authentication
ODE_SERVER: kerberos authentication error:
Incorrect network address (krb_rd_req)
Could Mark Glidden get involved in
helping with these routing problems in the
interim. It is a goal to look into the next
release of kerberos, which we are told will
solve this problem.
Tina
------- Forwarded Message
Return-Path: [email protected]
Received: from decvax.zk3.dec.com by rust.zso.dec.com
(5.65/DECwest-CLUSTRIX-cjf-30Jun93)
id AA09096; Mon, 11 Sep 1995 10:14:35 -0700
Received: from marvin.zk3.dec.com by decvax.dec.com
(5.65/DEC-ULTRIX-8/19/92)
id AA08427; Mon, 11 Sep 1995 13:14:30 -0400
Received: from localhost by marvin.zk3.dec.com;
(5.65/1.1.8.2/21Mar95-0329PM)
id AA11840; Mon, 11 Sep 1995 13:14:25 -0400
Message-Id: <[email protected]>
X-Mailer: exmh version 1.6.2 7/18/95
To: [email protected]
Cc: [email protected]
Subject: you've GOT to fix support for multi-homed
systems!
Reply-To: [email protected]
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 11 Sep 95 13:14:25 -0400
From: Farrell Woods <[email protected]>
X-Mts: smtp
This used to work. Now it doesn't. This should be a
show-stopper for
ODE!
.10 marvin:ftw> workon
cd'ing to sandbox source directory:
/x3/sandboxes/newatm/src.
starting new shell: /bin/tcsh.
To access your ODE server you must:
o kinit $PRINCIPAL (then input your kerberos
password)
o Enter workon -sb sandbox name or default.
Please obtain kerberos ticket and try again.
Check: environment $BCSPORT, and ode_server daemon @
labrea.zk3.dec.com
Please exit workon, do a kinit and enter workon.
1.6 marvin:ftw> cd kernel/conf/alpha
1.7 marvin:ftw> bco -u FLAMINGO
[ ./kernel/conf/alpha/FLAMINGO ]
ODE_SERVER: DECode client is not authorized!
ODE_SERVER: Are you in a workon?
bco: The following rcs command failed:
ode_client exists ./kernel/conf/alpha/FLAMINGO,v
[ unable to access source control information in file:
"./kernel/conf/alpha/FLAMINGO,v" ]
1.8 marvin:ftw>
-- Farrell
------- End of Forwarded Message
T.R | Title | User | Personal Name | Date | Lines |
---|
1804.1 | Re: Mark, can you help Farrell | AOSG::FILTER | Automatic Posting Software - mail to flume::puck | Mon Sep 11 1995 18:19 | 28 |
| Date Of Receipt: 11-SEP-1995 16:49:41.47
From: SMURF::QUARRY::"[email protected]" "11-Sep-1995 1648"
To: anderson@dec:.zso.decwet (Tina Anderson), [email protected]
CC: [email protected], [email protected]
Subj: Re: Mark, can you help Farrell
> I don't understand why you didn't have this
> problem in v2.2.
I did but only with bsubmit. workon, bco, etc. all were fine.
I fail to understand why someone can't fix kerberos... conjuring up
routes such that talking to red-net is not an acceptable solution since
it defeats the purpose of having an interface there. I do need this
extra interface for some of the work I'm doing, and I can't have routing
table entries that bypass it. I could put up with this before since
I could bco/bci and such and get most of my work done. Then I'd edit
/etc/rc.config and reboot when I had to submit. This wasn't fun and
now the current situation is much less acceptable.
I will try to cobble up a host route to labrea that bypasses the fddi...
If I can do this then I can still talk to the rest of red-net directly.
-- Farrell
|