[OpenAFS] VL_RegisterAddrs rpc failed (code=5376, err=22)

[Axel Reinhold]

>> [EMAIL PROTECTED] root]# udebug bongo 7003
>> Host's addresses are: 192.168.7.68 192.168.4.68 192.168.1.68 192.168.8.68
>> 192.168.9.68
>> Host's 192.168.7.68 time is Wed Sep 26 10:51:59 2007
>> Local time is Wed Sep 26 10:52:02 2007 (time differential 3 secs)
>> Last yes vote for 68.7.168.192 was 0 secs ago (sync site);
>
>Looks like an identity crisis. I bet you have a local hostname that binds to
>68.7.168.192 in dns or /etc/hosts and in CellServDB you're calling the host
>192.168.7.68 or somesuch?
>

see also: http://www.mail-archive.com/openafs-info@openafs.org/msg24691.html

i'm absolutely sure that my name-services are fine and consistent:

[EMAIL PROTECTED] root]# cat /etc/openafs/CellServDB
freakout.de #Cell name
192.168.7.68#bongo

[EMAIL PROTECTED] root]# cat /etc/hosts
# bongo:/etc/hosts

127.0.0.1   localhost loopback
192.168.7.68bongo.freakout.de bongo

[EMAIL PROTECTED] root]# nslookup bongo
Server: 127.0.0.1
Address:127.0.0.1#53

Name:   bongo.freakout.de
Address: 192.168.7.68

[EMAIL PROTECTED] root]# nslookup 192.168.7.68
Server: 127.0.0.1
Address:127.0.0.1#53

68.7.168.192.in-addr.arpa   name = bongo.freakout.de.

___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

Re: [OpenAFS] AES Support ?

[John Hascall]

> Ok, this picture confuses me a bit.  Actually, it confuses me a lot.

   Sorry, I was speaking in the abstract.
   It is obviously too late to change how existing implementations
   of rx work.  My whole point, if I had one, was that having a
   securityIndex field is made somewhat less useful by there being
   no secure way for the ends to negotiate it.

   Which, coming back full circle, is why we seem to be stuck with
   the icky extra-protocol hack of using afs-k5 vs afs.

John
___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

Re: [OpenAFS] AES Support ?

[Jeffrey Altman]

John Hascall wrote:
>> Ok, this picture confuses me a bit.  Actually, it confuses me a lot.
> 
>Sorry, I was speaking in the abstract.
>It is obviously too late to change how existing implementations
>of rx work.  My whole point, if I had one, was that having a
>securityIndex field is made somewhat less useful by there being
>no secure way for the ends to negotiate it.
> 
>Which, coming back full circle, is why we seem to be stuck with
>the icky extra-protocol hack of using afs-k5 vs afs.

This is a pointless discussion.  We aren't going to break existing
deployments of AFS.



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [OpenAFS] AES Support ?

[Todd M. Lewis]

Jeffrey Altman wrote:

John Hascall wrote:

   Which, coming back full circle, is why we seem to be stuck with
   the icky extra-protocol hack of using afs-k5 vs afs.


This is a pointless discussion.  We aren't going to break existing
deployments of AFS.


I found the discussion informative, in that it explains how certain design 
decisions move us forward while maintaining the edict you so succinctly 
state. The reasoning isn't always obvious to those of us who aren't deeply 
involved in the process, but such discussions tend to boost confidence in 
the OpenAFS project overall -- not insignificant considering some of us 
have bet the enterprise on OpenAFS. I appreciate the thoughtful 
contributions of the participants.

--
  +--+
 / [EMAIL PROTECTED]  919-445-9302  http://www.unc.edu/~utoddl /
+--+
___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

Re: [OpenAFS] AES Support ?

[John Hascall]

> This is a pointless discussion.  We aren't going to break existing
> deployments of AFS.

   So all future releases of OpenAFS forever will support rxkad
   and K4/DES-based tokens?  And there will be no way for a cell
   to turn that off?  Really?

John
___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

Re: [OpenAFS] AES Support ?

[Jeffrey Altman]

John Hascall wrote:
>> This is a pointless discussion.  We aren't going to break existing
>> deployments of AFS.
> 
>So all future releases of OpenAFS forever will support rxkad
>and K4/DES-based tokens?  And there will be no way for a cell
>to turn that off?  Really?
> 
> John

You will be able to turn it off as we described.  You remove the
afs/[EMAIL PROTECTED] key and it will no longer be used.  However, there must
be a smooth transition mechanism and that means no flag days.

Please do not confuse the deployment requirements with the distribution
requirements.

For the policy on DES, see

  http://www.openafs.org/no-more-des.html

Jeffrey Altman


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [OpenAFS] AES Support ?

[John Hascall]

> You will be able to turn it off as we described.  You remove the
> afs/[EMAIL PROTECTED] key and it will no longer be used.  However, there must
> be a smooth transition mechanism and that means no flag days.

Correct me if I am wrong, but if there is to be a smooth transition
then I have to wait until every single afs client worldwide who might
access our cell has upgraded (and how would I even know this).

The day I drop my afs/[EMAIL PROTECTED] key is the flag day.


John
___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

Re: [OpenAFS] AES Support ?

[Jeffrey Altman]

John Hascall wrote:
>> You will be able to turn it off as we described.  You remove the
>> afs/[EMAIL PROTECTED] key and it will no longer be used.  However, there must
>> be a smooth transition mechanism and that means no flag days.
> 
> Correct me if I am wrong, but if there is to be a smooth transition
> then I have to wait until every single afs client worldwide who might
> access our cell has upgraded (and how would I even know this).
> 
> The day I drop my afs/[EMAIL PROTECTED] key is the flag day.

The day you decide to make that change should not force others to make
that change as well.

Nor should clients that wish to talk to your cell and only support rxkad
be able to obtain tokens that do not work.

Jeffrey Altman

___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

Re: [OpenAFS] AES Support ?

[Ken Hornstein]

>Correct me if I am wrong, but if there is to be a smooth transition
>then I have to wait until every single afs client worldwide who might
>access our cell has upgraded (and how would I even know this).

Check your KDC logs?  When you stop seeing requests for afs/cell principals,
you can get rid of it.  Or at least track down the losers that haven't
upgraded yet and yell at them.

(If there is a period when you can use both principals for authentication,
I wouldn't classify that as a flag day.  To me a flag day is, "You have to
switch EXACTLY on date X").

--Ken
___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

Re: [OpenAFS] AES Support ?

[Derrick Brashear]

On 9/27/07, John Hascall <[EMAIL PROTECTED]> wrote:
>
>
> > This is a pointless discussion.  We aren't going to break existing
> > deployments of AFS.
>
>So all future releases of OpenAFS forever will support rxkad
>and K4/DES-based tokens?  And there will be no way for a cell
>to turn that off?  Really?


You have the source. You can always patch it. So that's obviously false.

But there's literally no one with AFS deployed now whose clients are ready
for this transition.

This really isn't that hard to grasp.

Re: [OpenAFS] AES Support ?

[John Hascall]

> > > We aren't going to break existing deployments of AFS.

> >So all future releases of OpenAFS forever will support rxkad
> >and K4/DES-based tokens?  And there will be no way for a cell
> >to turn that off?  Really?

> You have the source. You can always patch it. So that's obviously false.

  Well, that's a tautology isn't it.   You can always say "we aren't going
  to break it, you can always patch it yourself".

> But there's literally no one with AFS deployed now whose clients are ready
> for this transition.

  Today isn't the point.  Presumably, someday people *will* start to
  transition.  And, barring a worldwide flag-day, cells *will* make
  the transition at different times.  Somebody *will* be the first
  one to delete their "afs" principal.

  Previously in this discussion it was said you need to upgrade all
  your servers before you start upgrading your clients.  So if, (on
  that day that some other cell deletes "afs"), you haven't progressed
  far enough in your transition to where you can upgrade your clients,
  it sounds to me like you are in trouble.

  And, you have the ever-increasing weakness of DES keys which I presume
  will be pushing some cells to try to complete the transition as fast as
  possible.

  This, to me, seems to be the sort of thing people need to be aware of
  for planning purposes.

John
___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

Re: [OpenAFS] AES Support ?

[Russ Allbery]

John Hascall <[EMAIL PROTECTED]> writes:

>   Previously in this discussion it was said you need to upgrade all your
>   servers before you start upgrading your clients.  So if, (on that day
>   that some other cell deletes "afs"), you haven't progressed far enough
>   in your transition to where you can upgrade your clients, it sounds to
>   me like you are in trouble.

>   And, you have the ever-increasing weakness of DES keys which I presume
>   will be pushing some cells to try to complete the transition as fast as
>   possible.

>   This, to me, seems to be the sort of thing people need to be aware of
>   for planning purposes.

You cannot turn off use of DES keys for AFS in your cell without a flag
day.  You will be able to permit upgraded clients to use stronger
encryption types without a flag day.

This is fairly normal for transitions of this sort.  Turning something off
is almost always a flag day.  The same is true of disabling DES keys in
your Kerberos v5 realm (have you done that yet?).

-- 
Russ Allbery ([EMAIL PROTECTED]) 
___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

Re: [OpenAFS] AES Support ?

[Derrick Brashear]

On 9/27/07, John Hascall <[EMAIL PROTECTED]> wrote:
>
>
> > > > We aren't going to break existing deployments of AFS.
>
> > >So all future releases of OpenAFS forever will support rxkad
> > >and K4/DES-based tokens?  And there will be no way for a cell
> > >to turn that off?  Really?
>
> > You have the source. You can always patch it. So that's obviously false.
>
>   Well, that's a tautology isn't it.   You can always say "we aren't going
>   to break it, you can always patch it yourself".


We aren't going to break it is not you aren't going to break it.

I can't stop you from shooting yourself in the foot, but I'm not interested
in helping. I've made that point in those words before.

You have a point, but I don't think it's the point you've been presenting.

> But there's literally no one with AFS deployed now whose clients are ready
> > for this transition.
>
>   Today isn't the point.  Presumably, someday people *will* start to
>   transition.  And, barring a worldwide flag-day, cells *will* make
>   the transition at different times.  Somebody *will* be the first
>   one to delete their "afs" principal.


Yup. And then old clients get unauth access only.

  Previously in this discussion it was said you need to upgrade all
>   your servers before you start upgrading your clients.  So if, (on
>   that day that some other cell deletes "afs"), you haven't progressed
>   far enough in your transition to where you can upgrade your clients,
>   it sounds to me like you are in trouble.


Only if you want authenticated access.

Re: [OpenAFS] AES Support ?

[John Hascall]

> John Hascall <[EMAIL PROTECTED]> writes:
> >   This, to me, seems to be the sort of thing people need to be aware of
> >   for planning purposes.

> You cannot turn off use of DES keys for AFS in your cell without a flag
> day.  You will be able to permit upgraded clients to use stronger
> encryption types without a flag day.

> This is fairly normal for transitions of this sort.  Turning something off
> is almost always a flag day.

The difference here is that somebody else turning something off
can be the trigger.

>   The same is true of disabling DES keys in
> your Kerberos v5 realm (have you done that yet?).

Surely you jest, we're still struggling to get rid of K4.

John
___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

Re: [OpenAFS] multiple kerberos realms support.

[Matthew Andrews]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Christopher D. Clausen wrote:
> Matthew Andrews <[EMAIL PROTECTED]> wrote:
>> a few questions about the multiple kerberos realms support in the 1.5
>> series.
> 
> If you only need support for two realms, I believe that mostly works 
> with the current code.

by current code, do you mean openafs 1.4.4 without patches?

> 
>> Is there a concise set of patches that I could apply to a 1.4 series
>> release to get the multiple kerberos realms support?
> 
> Yes.  Look in the OpenAFS RT queue:
> http://rt.central.org/rt/Ticket/Display.html?id=58447

thanks, I'll look into this.
- -Matt

> 
>> Do these changes affect all of the servers, or only the ptserver?
> 
> The source code in the patch can probably tell you that.
> 
>> Is anyone currently running with this feature in production?
> 
> Yes, but only on a very small cell so I wouldn't consider the features 
> completely tested yet.
> 
> < 
> 
> ___
> OpenAFS-info mailing list
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info
> 
> 

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFG+/mxpLF3UzlwZVgRAuX2AKCvvFtDBBlJi3PVnBy32Q8JgIUBNgCfQBjq
ksdYpr9fn1iMxK6GcIlylGw=
=IBHn
-END PGP SIGNATURE-
___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

Re: [OpenAFS] AES Support ?

[Christopher D. Clausen]

Russ Allbery <[EMAIL PROTECTED]> wrote:
> John Hascall <[EMAIL PROTECTED]> writes:
>> The difference here is that somebody else turning something off can
>> be the trigger.
>
> Still not seeing your point.  This looks pretty much like every other
> "we're going to turn something off" transition I've been through in
> IT. Clear-text telnet, ftp, NFS, DCE, you name it.

Exactly.  Isn't the whole point of disabling less secure methods so that 
they cannot be used anymore?

Re: [OpenAFS] AES Support ?

[Russ Allbery]

John Hascall <[EMAIL PROTECTED]> writes:

> The difference here is that somebody else turning something off can be
> the trigger.

Still not seeing your point.  This looks pretty much like every other
"we're going to turn something off" transition I've been through in IT.
Clear-text telnet, ftp, NFS, DCE, you name it.

-- 
Russ Allbery ([EMAIL PROTECTED]) 
___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

Re: [OpenAFS] AES Support ?

[John Hascall]

> John Hascall <[EMAIL PROTECTED]> writes:
> > The difference here is that somebody else turning something off can be
> > the trigger.
> Still not seeing your point.  This looks pretty much like every other
> "we're going to turn something off" transition I've been through in IT.
> Clear-text telnet, ftp, NFS, DCE, you name it.

   Here's the difference as I see it.

   Lets say Stanford is in a big hurry to complete the transition.

   So they quickly upgrade their servers, then upgrade their clients
   and then think "well we should shut off that unsafe old stuff".

   Now lets further suppose that Very Important Professor at ISU
   accesses data in Stanford's cell via ACLs.

   If ISU hasn't yet completed their server upgraded, then we can't
   upgrade clients.  Now ISU VIP can't get at the data at Stanford.

   From the transitive sh*t rolls down hill theorom we can see that
   Unhappy VIP == Unhappy John.

   Unless, I am missing something here -- everybody is on the schedule
   of their most agressive peer who is in turn on the schedule of
   their agressive peer, etc, etc.

John
___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

Re: [OpenAFS] AES Support ?

[Russ Allbery]

John Hascall <[EMAIL PROTECTED]> writes:

>If ISU hasn't yet completed their server upgraded, then we can't
>upgrade clients.

Why not?

-- 
Russ Allbery ([EMAIL PROTECTED]) 
___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

Re: [OpenAFS] AES Support ?

[Derrick J Brashear]

On Thu, 27 Sep 2007, John Hascall wrote:


  So they quickly upgrade their servers, then upgrade their clients
  and then think "well we should shut off that unsafe old stuff".

  Now lets further suppose that Very Important Professor at ISU
  accesses data in Stanford's cell via ACLs.

  If ISU hasn't yet completed their server upgraded, then we can't
  upgrade clients.  Now ISU VIP can't get at the data at Stanford.


Why not? You didn't create k5-afs in your cell, so an upgraded client will 
work as before.

___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

Re: [OpenAFS] multiple kerberos realms support.

[Derrick J Brashear]

On Thu, 27 Sep 2007, Matthew Andrews wrote:


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Christopher D. Clausen wrote:

Matthew Andrews <[EMAIL PROTECTED]> wrote:

a few questions about the multiple kerberos realms support in the 1.5
series.


If you only need support for two realms, I believe that mostly works
with the current code.


by current code, do you mean openafs 1.4.4 without patches?


it does work there. just put the second realm name in 
/usr/afs/etc/krb.conf, and the second realm's afs key (with a different 
kvno from the first, please) in the KeyFile, and move on.

___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

Re: [OpenAFS] AES Support ?

[John Hascall]

> On Thu, 27 Sep 2007, John Hascall wrote:
> >   So they quickly upgrade their servers, then upgrade their clients
> >   and then think "well we should shut off that unsafe old stuff".
> >
> >   Now lets further suppose that Very Important Professor at ISU
> >   accesses data in Stanford's cell via ACLs.
> >
> >   If ISU hasn't yet completed their server upgraded, then we can't
> >   upgrade clients.  Now ISU VIP can't get at the data at Stanford.

> Why not? You didn't create k5-afs in your cell, so an upgraded client will 
> work as before.

   By "not yet completed" I meant started.  If I'm understanding
   the process as it was outlined many messages ago it was:

   1) create afs-k5 or (or is it k5-afs?) key
   2) upgrade all your servers
   3) upgrade all your clients
   4) remove the old afs key

   If, like us, you have a lot of servers and you upgrade them
   one-by-one by first vos moving all the data to other servers
   until they are empty and then vos moving it back afterwards
   then step 2 can take quite a long time.  And it seems to me
   that if you are in step 2, you can't talk (w/auth) to somebody
   who has finished step 4.

John
___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

Re: [OpenAFS] AES Support ?

[Derrick J Brashear]

On Thu, 27 Sep 2007, John Hascall wrote:


  By "not yet completed" I meant started.  If I'm understanding
  the process as it was outlined many messages ago it was:

  1) create afs-k5 or (or is it k5-afs?) key
  2) upgrade all your servers
  3) upgrade all your clients
  4) remove the old afs key


actually, i think i'd upgrade the servers, then add the key, then upgrade 
the clients, then remove the old key


for experimental deployment i'd use a 3rd key that clients needed to know 
about to use.

___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

Re: [OpenAFS] AES Support ?

[John Hascall]

> On Thu, 27 Sep 2007, John Hascall wrote:
> >   By "not yet completed" I meant started.  If I'm understanding
> >   the process as it was outlined many messages ago it was:
> >   1) create afs-k5 or (or is it k5-afs?) key
> >   2) upgrade all your servers
> >   3) upgrade all your clients
> >   4) remove the old afs key

> actually, i think i'd upgrade the servers, then add the key, then upgrade 
> the clients, then remove the old keyS

   Well, if that's doable, it would be a big win.  Thanks.

> for experimental deployment i'd use a 3rd key that clients needed to know 
> about to use.

   I can see how doing the servers first, then the key,
   basically switches the whole cell to the method at once.

   So, I'm not sure I'm following exactly, but I think you are
   suggesting this as a way to test before then (which would
   be a good thing).  You seem to imply that a clients can
   somehow be manually instructed to use an arbitrary keyname
   (say afs-k5-test) -- is this correct?   Then you could create
   this key that other clients would not know about, and then
   I am assuming you could also configure a test server in your
   cell with this key name too?

Thanks,
John
___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

Re: [OpenAFS] AES Support ?

[Derrick J Brashear]

On Thu, 27 Sep 2007, John Hascall wrote:


  So, I'm not sure I'm following exactly, but I think you are
  suggesting this as a way to test before then (which would
  be a good thing).  You seem to imply that a clients can
  somehow be manually instructed to use an arbitrary keyname
  (say afs-k5-test) -- is this correct?   Then you could create


Well, you have source, so yes, they always *can*.

But I think Marcus was using some (afsx?) principal for testing already, 
so he may have a switch.



  this key that other clients would not know about, and then
  I am assuming you could also configure a test server in your
  cell with this key name too?


Until this point servers didn't even care about key names, but, everything 
is doable. It may need some interface glue, but everything is doable.

___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

Re: [OpenAFS] AES Support ?

[Marcus Watts]

> Date:Thu, 27 Sep 2007 15:05:01 CDT
> To:  Derrick J Brashear <[EMAIL PROTECTED]>
> cc:  openafs-info@openafs.org
> From:John Hascall <[EMAIL PROTECTED]>
> Subject: Re: [OpenAFS] AES Support ? 
> 
> 
> > On Thu, 27 Sep 2007, John Hascall wrote:
> > >   By "not yet completed" I meant started.  If I'm understanding
> > >   the process as it was outlined many messages ago it was:
> > >   1) create afs-k5 or (or is it k5-afs?) key
> > >   2) upgrade all your servers
> > >   3) upgrade all your clients
> > >   4) remove the old afs key
> 
> > actually, i think i'd upgrade the servers, then add the key, then upgrade 
> > the clients, then remove the old keyS
> 
>Well, if that's doable, it would be a big win.  Thanks.
> 
> > for experimental deployment i'd use a 3rd key that clients needed to know 
> > about to use.
> 
>I can see how doing the servers first, then the key,
>basically switches the whole cell to the method at once.
> 
>So, I'm not sure I'm following exactly, but I think you are
>suggesting this as a way to test before then (which would
>be a good thing).  You seem to imply that a clients can
>somehow be manually instructed to use an arbitrary keyname
>(say afs-k5-test) -- is this correct?   Then you could create
>this key that other clients would not know about, and then
>I am assuming you could also configure a test server in your
>cell with this key name too?
> 
> Thanks,
> John

"The server" knows very little about the service name.  Whatever principals
are in /etc/openafs/server/keytab.afs are accepted without further 
qualification.

the 2 places where afs-k5 are known are:
/1/ klog/aklog
/2/ "-localauth" processing. (which includes ubik).

For /1/ if you wanted to specify a non-standard service principal you'd
have to hack various bits of logic.  This includes the calls to
get_afs_krb5_svc_princ and a bit of funny logic in aklog that only
gets DES if the service principal name is 3 characters long.

For /2/ you'd have to hack get_afs_krb5_localauth_svc_princ.  This
is ickier in that there are more commands that implement -localauth
and there are non-command interfaces (ubik) that do this as well.
It might be simplier to modify this logic to simply use the first
principal in the keytab as the "-localauth" principal.  Some of
the logic to do this is already there.

Having said that, I don't know why you would want to do this.
What would you learn with "a test server" in your production environment
that you could not better learn in a separate test cell?
What would you run on your test server anyways?  vlserver?  volserver?
How are you going to deal with all the interconnections of pt, vl,
vol, etc?  I'm sorry, but for some of things things (esp. ubik) I don't
see how you can avoid having a "flag" day inside your server environment,
and I don't see why you would want to avoid this either.

-Marcus Watts
___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

Re: [OpenAFS] AES Support ?

[John Hascall]

> Having said that, I don't know why you would want to do this.
> What would you learn with "a test server" in your production environment
> that you could not better learn in a separate test cell?
> What would you run on your test server anyways?  vlserver?  volserver?
> How are you going to deal with all the interconnections of pt, vl,
> vol, etc?  I'm sorry, but for some of things things (esp. ubik) I don't
> see how you can avoid having a "flag" day inside your server environment,
> and I don't see why you would want to avoid this either.

Well, a test-cell was my thought as well until Derrick
went hinting about... :)I'm inclined to agree with
you that that would be a whole lot of mucking about for
not much gain.

John
___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

Re: [OpenAFS] AES Support ?

[Marcus Watts]

John Hascall <[EMAIL PROTECTED]> writes:
>By "not yet completed" I meant started.  If I'm understanding
>the process as it was outlined many messages ago it was:
> 
>1) create afs-k5 or (or is it k5-afs?) key
>2) upgrade all your servers
>3) upgrade all your clients
>4) remove the old afs key

I think I must have received this out of order.  Nevertheless, the
steps are:

/0/ ahead of time, set up test cell.
Make sure test cell works correctly.
If desired, experiment with rxkad/rxk5 switchover.
Take all your supported client configurations.
Make sure those work.
Obviously, if you were doing this today, you'd want
to be particularly careful testing since you'd be a pioneer.
This is why we value pioneers.

/1/ upgrade server software.  This can happen one by one.
You can either replace server software in-place
or you can do data migration.
You can take as long as you like doing this.
Data migration won't cause any visible change,
server software upgrades may cause brief localized delays.
During this point, everything uses rxkad, but the rxk5 code
is getting installed server-side, as slowly as you like.

/2/ install afs-k5 keytab
make an afs-k5 principal & keytab.
At this point, any new clients will start breaking...
So you'll want to do this during a maintenance window...
So,
install that afs-k5 principal & keytab on all servers.
restart DB servers first.
restart fileservers.

After you complete /2/, all your ubik internal connections
will be rxk5 only.  Users will still be able to use rxkad
for all purposes - including administrative access, which
means your real increase in security is not that great.
This also means your risk isn't that great.  Your production
world after /2/ should behave just like your test environment
from /0/.

In parallel with /1/ and /2/ you can
/3/ upgrade clients
You can take as long as you like doing this.
upgraded clients done BEFORE /2/ happens will just use rxkad.
During /2/ upgraded clients may see more weirdness.
After /2/ ugpraded clients will work the new way
Non-upgraded clients will also see some weirdness during /2/.
After /2/ non-upgraded clients will continue to work the old way.

/4/ Remove the old afs key.
You can do this anytime after you don't see usage of the
afs key in your kdc logs with no visible impact.
If you still see afs key usage you have not completed /3/
or your users are using somebody else's clients...
In any case the choice to do /4/ is completely a question
of when you want to finish upgrading your security.

So here are some of the possible problems or risks I can think
of doing this:
/1/ server issues:
software build problems.
misconfiguration.
other administrative mistakes.

/2/ client issues:
software build problems.
misconfiguration.
generic client upgrade issues.
authentication problems.

-Marcus
___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

Re: [OpenAFS] Strange access problems on one client

[Dirk Heinrichs]

Am Mittwoch, 26. September 2007 schrieb ext Derrick Brashear:

> Ok, so it's just calling the access routines, meaning, nothing in OpenAFS
> changed. If you can tell us at which version of the kernel things start
> breaking it would be probably an easy fix for us from there.

Seems this laptop died a sudden death last night while compiling an older 
kernel for testing this issue. So I'm out of this for now :-(

Bye...

Dirk
-- 
Dirk Heinrichs  | Tel:  +49 (0)162 234 3408
Configuration Manager   | Fax:  +49 (0)211 47068 111
Capgemini Deutschland   | Mail: [EMAIL PROTECTED]
Wanheimerstraße 68  | Web:  http://www.capgemini.com
D-40468 Düsseldorf  | ICQ#: 110037733
GPG Public Key C2E467BB | Keyserver: www.keyserver.net


signature.asc
Description: This is a digitally signed message part.