>Heh, yeah. Not knowing it's "not supposed to" work, I tried, and I got
>tickets for both realms to show up in the viewer. True, klist will
>only show one (whichever was acquired last), but once I have the
>tickets, I can map Samba shares and work in AFS simultaneously,
>without any apparent proble
>Apparently when upgrading some macport program, it decided to
>install kerberos too, which hadn't been installed (as a macport) before.
You should file a bug; one of the macports developers started this whole
mess by creating a dependency on Kerberos for cyrus-sasl (even though the
macports docum
>Isn't one of the issues there that Apple pretty well broke Kerberos on Lion
>by replacing it with an eviscerated Heimdal missing most of the useful
>stuff?
That's a completely different problem, but not relevant here.
--Ken
___
OpenAFS-info mailing lis
>/vicepa/AFSIDat/j/
>
>which contains 316G of "something"
>
>Is it safe to delete this directory to bring the server back into service?
>(As opposed to a re-install) Or all the directories under /vicepa/AFSIDat/ ?
Did you try salvaging that partition?
--Ken
___
>bos salvage -server engr-f-200.eos.ncsu.edu -partition /vicepa -cell
>eos.ncsu.edu
>This is a demand attach fileserver. Are you sure you want to proceed with
>a manual salvage?
>must specify -forceDAFS flag in order to proceed.
I mean, you said you moved all of the volumes off, right? Should b
>The one concern with -orphans remove when salvaging the entire partition
>is if there were orphans that belonged volumes other than the one that
>was deleted. If such files existed they are now lost.
Yeah, that's certainly something to be aware of. I only suggested
that because Gary said he had
>We are working on the upgrading of Openafs Kerberos 4 to KDC 5. We
>checked some documents to know we have to use afs2k5db tool to convert
>users in K4 to KDC 5. But it's really a pain to compile it with
>Openafs-1.4.14-1 and krb5-server-1.10.3-65.el6.x86-64 due to the
>incompitable of the higher
>is there an easy way to check in C (under linux) whether a directory
>entry is a mount point for an afs volume and maybe also obtain the name
>of the volume mounted?
Assuming vanilla AFS ... the absolute easiest way to check to see if a
directory entry is a mount point is stat() the directory.
>I'm not sure that the application will have the ability to stat the
>mount point object. The OpenAFS cache manager will always provide the
>details of the target volume root directory unless the target volume
>cannot be located or accessed.
I can only say that this technique has worked for sever
>We at MIT CSAIL stoped using crowdstrike partly becuase they refused
>to fix this despite us providing a patch to falcon-sensor (whcih is
>just a tarred pile of shell scripts).
>
>The need to excluse /afs from their scans there's several ways to do
>this (they use "find" internally).
>
>We found t
>if [ ! $guard-against-system-accounts ]; then
>export KRB5CCNAME=/path/to/cache-depending-on-$(id -u)
I understand that with newer version of systemd this is becoming more
common ... but can I offer up a cautionary tale?
We have been using Kerberos for a LONG time; over 20 years. We are
by
>So why is storage in files so much more dangrous than storage in
>memory? If one happens to get a process which can read the files in
>local /tmp, why could that process not modify any of /proc//mem
>on the same computer to get at the ticket cache anyway?
A fair question. I mean, conceptually,
>Anyway, I checked the krb5 sources, and it is defined in
>lib/krb5/ccache/cc_keyring.c:
>
>/*
> * Keyring name prefix and length of random name part
> */
>#define KRCC_NAME_PREFIX "krb_ccache_"
>#define KRCC_NAME_RAND_CHARS 8
My reading of the code is that random cache name is
>In general, it is not safe to have ticket caches in a world-writable
>location, but KEYRING also had security troubles in the past.
Care to elaborate? I have not heard of any security troubles with KEYRING
but I would like to understand the pros and cons of all available ticket
caches.
--Ken
__
>Hi, lately I've been encountering a lot of situations where a process
>seems to block for a really long time trying to access something in
>/afs; it usually succeeds, but only after several minutes. This seems
>to happen only on MacOS (1.4.11, although I saw it with 1.4.10 too).
If it matters at
>In my krb5.conf I have (among others):
>
>[libdefaults]
>default_tgs_enctypes = aes256-cts des3-hmac-sha1 des3-cbc-sha1 des-cbc-md5
>des-cbc-crc
>default_tkt_enctypes = aes256-cts des3-hmac-sha1 des3-cbc-sha1 des-cbc-md5
>des-cbc-crc
Just some advice (although I don't think it has anything to d
>Just as another data point, when I try to su from a local account,
>I experience no delay but /var/log/debug gives exactly the same output.
Humor me for a minute.
There should be in one of your pam config files a module called "pam_xauth"
or something similar. Try commenting it out and see if t
>Ok, one other data point- I should have mentioned in the very beginning that
>I'm actually logging into the machine in question remotely, then issuing
>the su command. This seems to make a difference. While I THOUGHT the
>problem occurred either way, now I'm finding that if I actually sit down
>
>No, I do not.
So, let me understand you _completely_.
When pam_xauth.so is in /etc/pam.d/su, and when you log in on the console:
- "tokens" shows AFS tokens _before_ you su.
- There is no delay for "su".
- "tokens" shows no AFS tokens _after_ you su.
When pam_xauth.so is in /etc/pam.d/su, and
>You are correct in your assumptions. Regarding XAUTHORITY (with pam_xauth
>in su):
>
>logging in at the machine, this is what I find:
>
>before su:
>
>[emat...@aerogold ~]$ echo $XAUTHORITY
>/var/run/gdm/auth-for-ematlis-s3Q2Bx/database
Ah-HA!
Okay, that explains it. When you log in locally (I
>Are you using pam_afs_session? We've just discovered that when that is
>enabled in the su stack, becoming root takes a very long time, whether
>or not you have set the minimum_uid or not. The simple solution is to
>not run pam_afs_session in the 'su' stack.
I ran into this a while ago. The
We've recently got some MacOS Lion systems in, and we've noticed that OpenAFS
seems to perform rather poorly on then.
Specifically, we've noticed this when using nmh on these systems. Here's
an example of what I mean. On an older iMac running 10.6.8/OpenAFS 1.4.11:
% /usr/bin/time scan +kerbero
>Can anyone point me at the docs where quorum election, IP
>address numbering as it pertains to election, etc... lives?
>I can't find what I am looking for on openafs.org
>
>I seem to recall that the "highest IP is sync site" (if I
>have that right) nonsense was addressed, but again, cannot
>find t
>The "lowest IP address" favoritism decision is totally arbitrary, no?
Absolutely, yes. I think ... looking at the source code, the comparison
is done in 3 places in vote.c. You could replace that with anything else.
I've always thought that an explicit ordering would make more sense, but
I neve
>I would object. A quorum requirement is that all servers are in
>agreement with the server configuration and the quorum algorithm. Any
>change to the quorum algorithm needs to be exposed as part of the
>negotiation in order for servers to not get into a state where a
>misconfigured server or a s
>I thought there was some bug preventing this from working in the
>specific case where the lowest IP was a clone. I remember reading a bug
>report somewhere about it... but I can't find a ticket matching that
>description. Anyone have any idea what I'm talking about, or am I just
>making stuff up?
>While probably not the case I can only hope that the exclusion of the tools
>is because they want to do a better job of inter operating with the KDC.
>In my opinion that would mean dropping the need for aklog and asetkey.
>After all aklog is basically a second authentication.
You are incorrect.
>I could do this.. But.. Is there any reason we need to do this at
>all? Where does the code even _use_ res_search? Maybe KenH can pipe
>up here about why he's searching for res_search in the configure
>script? Is there some API that's needed on some platforms that's
>shipped with res_search?
>> U ... what? I'm sorry, I wasn't paying attention to this discussion.
>> I don't recall ever adding anything to any OpenAFS configure.in script
>> that checks for res_search.
>
>No, not openafs.. afs-krb5
Ah. Ummm that's probably there because we had a dependency on linking
all Kerbe
>I would suggest you do the same thing. The only annoying thing about the
>OpenAFS aklog is that it seems to use 2b always; so if you are running
>servers that don't support it then it gives you bad tokens unless you
>explicitly specify -524.
I had a conversation about this with the "other" Der
>I've been testing 1.4. It seems like aklog still needs port on
>the Kerberos server opened. My Kerberos v5 server is on a different
>computer than the OpenAFS server. Some of the docs I'm reading seem
>to indicate that port is only needed to convert between v5 and v4
>tokens. Thanks
>If it would work, I would enable Kerberos 4 for the time being, but I'd
>really rather not. Does anyone have any aklog source that builds on
>10.4 that supports Kerberos 5 tickets? Or if it is in CVS and it just
>didn't get built, instructions on how to do that would be great as well.
Did yo
>(3) The aklog directory is not built on MacOS X because it is part of
>the "login" build group and the "login" build group is not built
>on MacOS X. Changes to the makefile dependencies will have to be
>made.
Is this a change? Because OS X (under 10.3) was one of my test platforms
f
>It build for me once I specified --with-krb5 and set KRB5LIBS and
>KRB5CFLAGS building 1.4.0-RC6 under panther about 3 days ago.
But we were talking about Tiger, weren't we?
FYI: Since Tiger includes krb5-config, you can use --with-krb5-conf instead
of setting KRB5LIBS and KRB5CFLAGS. Assuming
>I don't speak autoconf particularly well, but I can try to patch this
>change in if somebody's got a handy beginner's guide to hacking autof00.
The documentation that comes with autoconf is actually pretty good. The
only problem is that currently openafs uses some ancient-ass version of
autoconf
>I can confirm that on Tiger aklog will be built when --with-krb5-config
>is specified.
>
>I think the test simply needs to be:
>
> if "krb5-config" can be located in the path
> then --with-krb5-config should default to "on" unless an explicit
> --with-krb5 is specified.
>
>This should work
>The krb_524_convert_creds() function is new to MIT Kerberos 1.4.x.
>Therefore, it is present in Tiger but not in previous versions.
Assuming you're talking about krb5_524_convert_creds(), it was definately
in MIT Kerberos 1.3, and I see it prototyped in /usr/include/krb5.h on
a Panther system her
>configure:13395: checking for krb5_524_convert_creds
>configure:13445: cc -o conftest -g -O2 -I/usr/include conftest.c
>-L/usr/lib -Wl,-rpath -Wl,/usr/lib -lkrb5 -lk5crypto -lkrb5support
>-lcom_err -lresolv >&5
>ld: unknown flag: -rpath
Dumb question time: where the heck did -Wl,-rpath come
>It would be a Good Thing if encryption were a per directory thing like
>an ACL, enforced by the server, so you could make sure your sensitive
>information was never passed in the clear. I have no idea how hard it
>would be to implement an "encrypted directory" flag, but I suspect it
>would me
>Here, we are debating about a couple of ways to transition:
>[...]
>I'd really like some feedback, either in the appropriate forum or
>personally, on experiences or thoughts. There isn't a lot publicly out
>there on a big transition like this.
I think enough people have weighed in on how easy
>1. OpenAFS 1.4 should be capable of using MIT Kerberos V, When creating
>the the keytab (for use with asetkey) I do "ktadd -e des-cbc-crc:v4
>afs/linet.dk", when using aklog it fails if krb524d is not running. Is
>that the way to create the keytab ? Should'nt I be able to use aklog
>without krb524
>So we are moving out of DCE/DFS and I need to be able to run them side
>by side for a bit. Obviously I can't run krb542d on the DCE cell. But
>I can get a krb5 ticket out and that works fine, I thought there was now
>support for converting krb5 tickets into tokens without the need of a
>524d
>Ken I have followed your directions as usual and gave the afs key the
>principal "afs". Although I did make a afs/umiacs.umd.edu principal as
>well. There doesn't seem to be a switch for just trying krb5 in aklog
>or is that choice made for you?
_assuming_ you're using the aklog from the 1.4
>Nope, this is the "old" aklog from the afs-krb5 migration.
>The 1.4.1 packages will have the "openafs" aklog.
So, um ... what happened? Was this intentional? I ask because this is
probably the second or third person who posted on the list saying, "Hey,
this damn aklog doesn't work as advertised
>> So, um ... what happened? Was this intentional? I ask because this is
>> probably the second or third person who posted on the list saying, "Hey,
>> this damn aklog doesn't work as advertised".
>
>For the record the aklog that's built by 1.4.0 and the 1.4.1-RC line works
>for me on both Solari
>Yes and no. I was already building from the migration kit
>and just didn't change over. It was unclear at the time I
>was working on the 1.2->1.4 SPEC file changes that the aklog
>in openafs was significantly different than what was in the
>migration kit. I know now that was incorrect. I've al
>I mean, it seems to me to be such an obvious thing to do that I don't even
>know why it would surprise you.
"What he said".
--Ken
___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info
>Does there exist any *concise* documentation for
>migrating to Kerberos 5 from the built-in OpenAFS Kerberos?
I can only say that every migration I've known about has been a little
bit different than every other one. Some are a LOT different. This
seems to be related that every installation tre
>You need to set KRB5LIBS and KRB5CFLAGS when doing a ./configure.
only if your system doesn't provide a krb5-config script. 10.3
does not, 10.4 does.
--Ken
___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman
>Its a notebook and "just for one user".
>I tested it right now with another userID.
>First with user admin, the same error.
>aklog -d told me he tries to get a token for ID 1, but then there was
>the same error.
>As my user, schimmer, I got the same error, to.
>aklog: unable to obtain tokens for c
>The OpenAFS Gatekeepers announce the availability of OpenAFS version
>1.4.1 Release Candidate 2. Source files and available binaries can be
>accessed via the web at:
>
> http://www.openafs.org/dl/openafs/candidate/1.4.1-rc1/
^^^
Shouldn'
>On Thu, 1 Dec 2005, Ken Hornstein wrote:
>
>> Ewww. Is it possible that somehow you're running the "wrong" aklog?
>> (I sure wish translate_et was shipped by default).
>
>/Library/OpenAFS/Tools/bin/translate_et 11862788
Well, what do you know. I didn&
>I've got the same problem so I post my ktrace-dump:
>
> 616 aklogCALL poll(0x14,0,0x800c5603)
> 616 aklogRET poll -1 errno 22 Invalid argument
> 616 aklogCALL write(0x2,0x32550,0x5e)
> 616 aklogGIO fd 2 wrote 94 bytes
> "aklog: unable to obtain tokens for cell c
>Just to add to this, when I did just create /afs, then re-ran afsd,
>everything worked. I've never had to do this before, so that's why I
>posted the question.
I've always thought that since the Dawn Of Time you had to create /afs.
Certainly I remember forgetting to do that and having the Tran
>In file included from /usr/local/include/krb5.h:2550,
> from aklog_main.c:62:
>/sources/openafs-1.4.0/include/afs/com_err.h:15: error: parse error before
>"afs_int32"
I know about the problem; I don't know what to do about it.
The basic problem is that OpenAFS & Kerberos 5 both
>The right thing to do, I think, would be to add an option to AFS to build
>with the system com_err library rather than its own. That way it can
>either reuse the Kerberos com_err library or both it and Kerberos can use
>some other system library (like the one from e2fsprogs that most Linux
>distr
>Does Kerberos have to be installed for openAFS to compile? Could you
>compile AFS and THEN compile Kerberos?
>Perhaps you could temporarily rename the offending Kerberos libraries so
>that they are not an option, just when you build those particular make
>targets that require com_err?
I suppo
>I think at this point every com_err library has diverged from every other
>com_err library. I'm not at all sure which com_err library out there is
>"best" at this point; the one in e2fsprogs is probably the most reliable
>in terms of backward compatibility,
... and no doubt is the least commonly
Russ has provided a good answer to you email; I only have a few things
to add:
I only can test on systems I have easy access to; for various political
reasons here, I only have easy access to Solaris and MacOS X, and I only
use MIT Kerberos (I installed Heimdal on a Solaris box here just so I coul
>I think I'm most concerned that the lowest IP address machine says "I am
>a clone and never can become sync site", but the other machine are often
>voting for it, and it doesn't seem to let them know it's not campaining
>(so to speak). Can anyone tell me why it's a clone, if this is the
>probl
>broudy.net AFSDB 1 noah.broudy.net
>broudy.net AFSDB 1 minerva.broudy.net
>broudy.net AFSDB 1 goliath.broudy.net
>
>Hmm... is that only for clients?
Um, yeah, at least I've never heard of anyone using that for servers
as well.
>With empty CellServDB (
>are your kerberos kdcs running on the afs database servers? If not, are you =
>
>sure you shut down your kaservers?
>
>if a unix client uses kerberos v4 (kinit -4; aklog), does it fail also?
Did someone add v4 support to aklog when I wasn't looking? :-) (I'm talking
about the one shipped with Op
>>> if a unix client uses kerberos v4 (kinit -4; aklog), does it fail also?
>>
>> Did someone add v4 support to aklog when I wasn't looking? :-) (I'm talking
>> about the one shipped with OpenAFS, of course).
>>
>> --Ken
>
>The Windows version of aklog.exe supports Kerberos 5, krb524, and
>Kerbe
>I've installed OpenAFS 1.4.0 on two RHEL AS 3 machines for testing. They
>both use Kerberos 5, aklog, and all that good stuff. They seem to be
>working perfectly, except if I do a second `aklog` after logging in and
>getting my ticket from pam_krb5afs, it breaks:
Technically, isn't this the first
>> Sorry, I misread the 1.2.7 above as being the OpenAFS version.
>> The OpenAFS 1.4.0 you have installed should handle Kerberos 5 tokens
>> just fine.
>
>Unfortunately you are incorrect.. The 1.4.0 RPMS do not. They still
>ship the old krb5-afs (migration kit) aklog. This will be fixed
>in the
>It's not true that "aklog doesn't work". It's only true that "aklog
>doesn't work with pure krb5 tickets/tokens without using krb524". Again,
>this will all be fixed in 1.4.1 which was due out last month.
(Note that in my original email, I said "probably won't work" - I stand
by that statement,
>I noted this conversation in the archives:
>
>http://www.mail-archive.com/openafs-info@openafs.org/msg18512.html
>aklog_main.c:198:2: error: #error "Must have either keyblock or
>session member of krb5_creds"
>aklog_main.c:204:2: error: #error "You must have one of
>krb5_524_convert_creds or k
>I noted this conversation in the archives:
>
>http://www.mail-archive.com/openafs-info@openafs.org/msg18512.html
>
>...which leads me to believe that the I have to build my own aklog,
>regardless of which rpm's I use.
One final note: I realized that you were the guy who had the "Can't get
infor
>doh.. I assumed configure would look for krb out of box.. calling --
>with-krb5-conf fixed things right up.
So, you didn't give it any Kerberos options _at all_ to configure? I ask
because in that case, make is not supposed to try to build aklog, and if
it did, then that's a bug in the Makefil
> When /i/ first
> started playing with it I assumed that when I used --enable-krb5 it would
> perform an AM_PATH_PROG(KRB5_CONFIG, krb5-config) and search in my path..
>
>That wouldn't work for me. I've got a /usr/local/bin/krb5-config for MIT,
>but I normally use Heimdal and it has no krb5-co
>krb5-config is not needed on OpenBSD because Heimdal is installed in a
>standard place. All that's needed is to avoid running the MIT krb5-config.
Urrrk. Explain to me, as a software distributor, how exactly I'm
supposed to determine _which_ Kerberos libraries to link against on
OpenBSD? I am
>aklog came from athena, where cells were all in the ATHENA.MIT.EDU realm.
>It's using the krb5 "realm of host" function on,probably, the server.
Actually ... I believe the code that does the mapping from the cell to
the realm was introduced in the first round of k5-ification of aklog,
but I'm no
> perform kerberos server discovery (RFC2052) on server.bar.com
> -> usually something.bar.com (depends on DNS entries)
Be careful ... aklog doesn't know anything about RFC2052; it just calls
a Kerberos library function. What that does depends on your Kerberos
implementation.
--Ken
__
>BTW, I think understanding and valuing this sort of scenario -- where
>the AFS admin does not control the client machines and users are
>unsophisticated -- is an important hurdle that the OpenAFS community
>still needs to get over. Afsdb/dynroot were a big step in this
>direction, though!
Sigh,
My $0.02 on this subject:
While zeroconf is an admirable goal (one I've pushed for a long time),
zeroauth (for lack of a better term) is a completely different matter.
Authentication is tied up a whole bunch of site-specific policies, and
every site I've ever encountered has a vastly different mi
>At this point RX (the rpc system AFS uses) is only UDP. There's
>been a specification for RX-tcp, but I've not seen an implementation.
I have a implementation of RxTcp that's not useful yet, but it's slowly
becoming more useful. Probably I will commit it to the OpenqAFS tree
in the near future
>Ken Hornstein <[EMAIL PROTECTED]> writes:
>> Maybe it's me, but I've never really seen the difference between a junk
>> certificate and a Kerberos ticket;
>
>Somebody with no prior trust relationship can check the validity of a
>junk certificate.
Can th
>> In theory you don't need to encrypt the CA certificate, but you should
>> verify it's integrity somehow. This is one of the places where PKI
>> tends to cheat; it works great in the usual case where web browsers have
>> a standard list of CAs that they accept.
>
>For values of great equal to "t
>Yes, I'm happy with a krb524d-style solution (where the OpenAFS client
>transparently handles the additional hoop-jumping incurred by the
>layering) rather than a solution like gssklogd in its current state
>(where the user has to download and compile some separate utility and
>generally expend a
Maybe it's me, but I've never really seen the difference between a junk
certificate and a Kerberos ticket;
>
>>> Somebody with no prior trust relationship can check the validity of a
>>> junk certificate.
>
>> Not nessesarily. Only if the CA certificate used to sign the "junk
>> certificate
>Ken Hornstein <[EMAIL PROTECTED]> writes:
>> Be careful; in one sense, krb524d and gssklogd are basically the same
>> program, especially in terms of client transparency. It's just that
>> the utilities to use one of them are much more widespread.
>
>Ah yes
>With AFS we have to decide whether to allow the world to read the entire top
>level of a home directory, or to always require the username and password for
>each login. At the moment I've chosen the latter, since the former requires
>vigilance on the part of the user that I'm not comfortable wi
>Most of our users will place files in their home directory, even in the top
>level, expecting them to be secure. Additionally, I fully expect that most
>users will leave permissions with the default settings. In this case, when a
>user creates a directory it inherits the ACL privileges of its p
>This appears to be a security decision based primarily on a technical
>limitation in AFS.
Sure was; I never said otherwise. I fully admit it's not ideal, but I
have to work with the tools that I have, not the ones that I wish I
had. Certainly everybody makes those kinds of decisions every day.
>I just got a test setup of cross-realm (v5) afs working between two
>"toy" realms. Pretty nifty, especially since aklog does all the hard
>work for the user.
I think 70% of the hard work is done by the Kerberos library (the actual
cross-realm magic); the remaining 30% is done by aklog in terms o
>Hrm, can somebody tell me what the final word is on which of these the
>AFS principal for a cell should be?
>
> afs/REALM
> afs/@REALM
> afs/[EMAIL PROTECTED]
>
>It seems that aklog isn't consistent about which principal it chooses
>to try to get tickets for...
As long as we're talking about t
> $ pts creategroup project.sbp system:administrators -cell
> research.cs.berkeley.ed
>u
> pts: Permission denied ; unable to create group project.sbp with id 0 owned
> by 's
>ystem:administrators'
>
>Are there some powers that are withheld from administrators using a
>cross-realm pts id? The
>Also, the use of TXT records to determine which realm a service
>belongs to is insecure and is disabled by default in MIT Kerberos.
>You would need to explicitly enable this functionality in your
>krb5.ini file in order to use it.
I will note that NO ONE has EVER explained to me how this is more
>For the record, the most recent candidate (1.4.1rc5) still has this problem.
>
>By accident I found out that if I compile the aklog rpm (openafs-krb5)
>with my locally built gcc 4.0.2 I don't get the segfault. If I compile
>aklog with RH's gcc 3.4.4 (required for the kernel module to work) it
>... but I'm using MIT Kerberos on all three machines (Win32, Linux,
>and MacOS). Why do I see different behavior on MacOS?
You're using the Apple-supplied Kerberos library on OS X, right? Did
you look at /Library/Preferences/edu.mit.Kerberos? (Which is the real
config file for Kerberos on OS X
>Indeed, it should. What Russ is alluding to here is the fact that most
>aklog's determine what realm to use by applying the normal Kerberos
>host-to-realm mapping on the hostname of one of the DB servers. Of course,
>this introduces all sorts of security issues related to trusting the names
>I'm truly baffled by why this is working on some machines and not
>others.
I'm surprised as well. The anamoly is that the TXT record lookup is
being performed without changes to the config file. Are you sure that
the aklog you're using is linked with the system-supplied Kerberos
framework? (Yo
>I may be abandoning this because there doesn't seem to be any reliable
>way for clients to figure out that the cell is its own realm (without
>requiring end-users to manually edit or replace their krb5.conf, which
>is way beyond the abilities of many people, sad as that fact may be).
>
>Basically,
>My real concern with an approach such as you describe (which has been
>suggested before) is that it would end up being blindly deployed in
>situations where it is _not_ safe, which I suspect is a lot of them, and it
>would encourage people to rely on "easier" insecure configurations even
>when
>This is the strange part: no such power exists here.
>
>Maybe it's "a Berkeley thing". My personal interpretation is that
>people act as if "nothing is any more official than the number of
>people you've persuaded to rely on it". The majority of the people in
>the department retain exclusive adm
>> Is this on some roadmap i.e. planned for a release ?
>> We have quite some problems because of poor udp support in adsl routers
>> and blocked ports in firewalls.
>
>There is code on a branch in CVS now, but there is no date yet targeted
>for them to be in a release.
To elaborate a bit more ..
>My personal experience is that most places blocking UDP are also
>blocking TCP and forcing users to use an HTTP proxy for all internet
>access. I'm actually interested in knowing about the prevalence of
>anything that falls in-between (NATted TCP but no UDP). I know it's
>possible, of course; ar
>I'm a little confused as to the current state of the world.
>
>I'm not expecting any long answers. Grunts will do.
>I can dig further on my own after the grunts :)
>
>Kerb5 with OpenAFS: Is "The Migration Kit" necessary?
No (except maybe you should read the documentation if you want to understan
>It's not a bad idea to rekey one's services from time to time. It's just
>temporarily disruptive if one doesn't go through the steps in the right order
>(which for AFS would be to distribute the new key to the AFS servers
>*before* the KDC starts issuing tickets with it).
I agree in theory you sh
>Is there any way to make sure that the cache manager never waits for
>more than (say) 5 seconds for a response? By which I mean that if the
>server fails to respond after 5 seconds, assume it's never coming back
>and return EIO to the caller or something like that.
In the interests of solving th
1 - 100 of 266 matches
Mail list logo
