Hi,
Recently I came across an issue where 'make install' which was installing
software to AFS was taking *much* more time on a Solaris client than on
Linux client. The issue turned out to be a lack of optimization on VFS layer
in Solaris, and VOP_MKDIR in AFS isn't optimized for it either (on
On 23 Jan 2014, at 11:37, mi...@task.gda.pl mi...@task.gda.pl wrote:
Recently I came across an issue where 'make install' which was installing
software to AFS was taking *much* more time on a Solaris client than on
Linux client. The issue turned out to be a lack of optimization on VFS layer
[ ... ] adding the new machines to the CellServDB before the
new server is up. You could bring up e.g. dbserver 4, and only
after you're sure it's up and available, then add it to the
client CellServDB. Then remove dbserver #3 from the client
CellServDB, and then turn off dbserver #3.
For
[ ... ]
At some point during this slow incremental plan there were 4
entries in both 'CellServDB's and the new one had not been
started up yet, and would not be for a couple days.
Oh also, I'm not sure why you're adding the new machines to
the CellServDB before the new server is up. You
On Thu, 23 Jan 2014 14:58:35 +
p...@afs.list.sabi.co.uk (Peter Grandi) wrote:
The issue is that with 'server/CellServDB' update there is
potentially a DB daemon (PT, VL) restart (even if the rekeying
instructions hint that when the mtime of 'server/CellServDB'
changes the DB daemons
On Thu, 23 Jan 2014 11:43:50 +
Simon Wilkinson simonxwilkin...@gmail.com wrote:
The real question here is how widely we should be applying the abort
threshold - should it apply to all aborts sent to a particular client,
or should we be more selective? There are a lot of competing views
I was reviewing in great detail the 'rxkad-{k5,kdf}' upgrade
instructions and in particular the rekeying HOWTO:
http://www.openafs.org/pages/security/how-to-rekey.txt
here in the MIT Kerberos section:
The default encryption types given by the KDC are probably
fine, as long as single-DES
Hi Peter,
On Thu, 23 Jan 2014, Peter Grandi wrote:
I was reviewing in great detail the 'rxkad-{k5,kdf}' upgrade
instructions and in particular the rekeying HOWTO:
http://www.openafs.org/pages/security/how-to-rekey.txt
I wrote the majority of both this document and the 'retiring des'
On Thu, 23 Jan 2014 16:36:18 +
p...@afs.list.sabi.co.uk (Peter Grandi) wrote:
The issue here is that at least in MIT kerberos 1.8 and 1.10 which I
tested this on this results in the loss of the existing single-DES key
from the KDB,
That is intentional and expected.
which probably
[ ... ]
The issue here is that at least in MIT kerberos 1.8 and 1.10
which I tested this on this results in the loss of the existing
single-DES key from the KDB, which probably results in existing
The loss of the existing single-DES key is expected and desired.
single-DES tokens and client
[ ... ] results in the loss of the existing single-DES key
from the KDB,
That is intentional and expected.
Perhaps it should be noted in the procedure then. I have noticed
that the language in the procedure is somewhat ambiguous on
keeping or removing the single DES keys from the principal,
On Thu, 2014-01-23 at 10:44 -0600, Andrew Deason wrote:
For example in an ideal world putting more or less DB servers in
the client 'CellServDB' should not matter, as long as one that
belongs to the cell is up; again if the logic were for all types
of client: scan quickly the list of
On 1/23/2014 2:18 PM, Peter Grandi wrote:
[ ... ] results in the loss of the existing single-DES key
from the KDB,
That is intentional and expected.
Perhaps it should be noted in the procedure then. I have noticed
that the language in the procedure is somewhat ambiguous on
keeping or
On Thu, 23 Jan 2014 18:35:40 +
p...@afs.list.sabi.co.uk (Peter Grandi) wrote:
Is there any _technical_ risk in using the avoid the loss of
the old keys procedure?
You apparently get a keytab that contains DES keys in it, and apparently
the DES entries have the wrong kvno. That can cause
On Thu, 2014-01-23 at 14:58 +, Peter Grandi wrote:
My real issue was 'server/CellServeDB' because we could not
prepare ahead of time all 3 new servers, but only one at a time.
The issue is that with 'server/CellServDB' update there is
potentially a DB daemon (PT, VL) restart (even if
On Thu, 23 Jan 2014 14:33:58 -0500
Jeffrey Hutzelman jh...@cmu.edu wrote:
The problem is that you the client to scan quickly to find a server
that is up, but because networks are not perfectly reliable and drop
packets all the time, it cannot know that a server is not up until that
server has
On Thu, 23 Jan 2014 15:39:03 +
p...@afs.list.sabi.co.uk (Peter Grandi) wrote:
Oh also, I'm not sure why you're adding the new machines to
the CellServDB before the new server is up. You could bring up
e.g. dbserver 4, and only after you're sure it's up and
available, then add it to
On 1/23/2014 11:53 AM, Andrew Deason wrote:
On Thu, 23 Jan 2014 11:43:50 +
Simon Wilkinson simonxwilkin...@gmail.com wrote:
The real question here is how widely we should be applying the abort
threshold - should it apply to all aborts sent to a particular client,
or should we be more
18 matches
Mail list logo
