On Dec 19, 2005, at 8:16 PM, ted creedon wrote:
remove openafs, & recompile 1.4.0 from scratch
There are 3 SuSE 10.0 boxes here running fine with KrbV etc.
done..
now:
[EMAIL PROTECTED] ~]# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: [EMAIL PROTECTED]
Valid starting Expi
Quoting Jeffrey Altman <[EMAIL PROTECTED]>:
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)
Jeffrey Altman wrote:
> Sean Kelly wrote:
>> How would I tell?
>>
>> [smkelly@ smkelly]$ rpm -qa|egrep 'openafs-server|krb'
>> krb5-libs-1.2.7-47
>> krbafs-1.1.1-11
>> krbafs-utils-1.1.1-11
>> pam_krb5-1.77-1
>> krb5-server-1.2.7-47
>> openafs-krb5-1.4.0-rhel3.1
>> krb5-workstation-1.2.7-47
>> open
Derrick J Brashear <[EMAIL PROTECTED]> writes:
> I bet you have dynroot enabled on the client, don't you...
>
> Derrick
The RPMS have dynroot turned on by default because openafs.org
has no root.afs volume... Or at least the systems were hanging
on startup and failing to mount root.afs from open
Ahh.. So you have no clue about whether what I said is correct
or not (about rebuilding the OpenAFS-distributed SRPM).. Got it.
-derek
ted creedon <[EMAIL PROTECTED]> writes:
> Source code tarball. The SuSE srpm is v 1.3.78 (not 1.3.87 as prev
> mentioned) and shouldn't be used.
>
> AFS revi
On Tue, Dec 20, 2005 at 03:25:19PM -0500, Jeffrey Altman wrote:
> Just a guess but perhaps you have two different versions of aklog on
> your machine and the first one use krb524 and the second one uses raw
> Kerberos 5?
All I have is a /usr/bin/aklog that came with the OpenAFS RPM
(openafs-krb5-1
Sean Kelly wrote:
> How would I tell?
>
> [smkelly@ smkelly]$ rpm -qa|egrep 'openafs-server|krb'
> krb5-libs-1.2.7-47
> krbafs-1.1.1-11
> krbafs-utils-1.1.1-11
> pam_krb5-1.77-1
> krb5-server-1.2.7-47
> openafs-krb5-1.4.0-rhel3.1
> krb5-workstation-1.2.7-47
> openafs-server-1.4.0-rhel3.1
> krb5-de
You want to use asetkey to add the new key but you should not remove
the old key until after all of the Kerberos service tickets using the
old key have expired.
Restarting the afs clients is unimportant. What is important is
obtaining a Kerberos 5 service ticket with the new key. If you already
>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
Just a guess but perhaps you have two different versions of aklog on
your machine and the first one use krb524 and the second one uses raw
Kerberos 5?
Perhaps your servers are old enough that they cannot support raw
Kerberos 5 based tokens?
Jeffrey Altman
Sean Kelly wrote:
> I've installed Open
This isn't limited to windows clients as far as I can tell. I updated the
keys for my servers yesterday. When I aklog'd I would get an error close
to "unknown key". I don't remember the exact message.
Once I restart afs on the client machine, everything is fine for some
reason.
For reference, I
Renata Maria Dart wrote:
> Yes.
I bet that if you installed KFW on the clients they would
begin to work.
The problem at this point is most likely that the salt you
are using for your keys in the KDC are not compatible with
Kerberos 4.
My guess is that if you were to obtain a token on Unix with
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:
g4:~ smkelly$ ssh .creighton.edu
smke
On Tue, 20 Dec 2005, Chaskiel M Grundman wrote:
>are your kerberos kdcs running on the afs database servers?
Yes.
>If not, are you
>sure you shut down your kaservers?
>
>if a unix client uses kerberos v4 (kinit -4; aklog), does it fail also?
Hmmm, don't know about that...will look into it.
Tha
On Tue, 20 Dec 2005, Jeffrey Altman wrote:
>Renata Maria Dart wrote:
>> Thanks for your response Jeff. Our windows clients do not run
>> kerberos. And the problem exists not only for users who were already
>> logged in, but on windows boxes that have just been rebooted, and on a
>> windows box t
>>> 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
Ken Hornstein wrote:
>> 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 talk
I bet you have dynroot enabled on the client, don't you...
Derrick
On Tue, 20 Dec 2005, Christophe BERNARD wrote:
Hello.
I installed a long awaited RPM openafs distro on a 64 bit fedora core 4
client. The server is still running 1.2.13 on a fedora core 1.
Works mostly well (krb5/aklog/afs
>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
Renata Maria Dart wrote:
> Thanks for your response Jeff. Our windows clients do not run
> kerberos. And the problem exists not only for users who were already
> logged in, but on windows boxes that have just been rebooted, and on a
> windows box that got a brand new install of OpenAFS this morni
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?
p7sPK95sGh5A4.p7s
Description: S/MIME cryptographic signature
kvno.exe is a part of a KFW 2.6.5 and KFW 3.0 and perhaps earlier
versions. I don't know what version you have on your machines.
Use klist -e to report the enc-types in use for the tickets
on Windows.
Jeffrey Altman
Renata Maria Dart wrote:
> Thanks for your response Jeff. Our windows clien
Thanks for your response Jeff. Our windows clients do not run
kerberos. And the problem exists not only for users who were already
logged in, but on windows boxes that have just been rebooted, and on a
windows box that got a brand new install of OpenAFS this morning, so
existing tokens weren't ev
Renata Maria Dart wrote:
> Hi, we upgraded our AFS server keys this morning and things went
> smoothly for our unix clients, but we are seeing some problems with
> authentication on our windows clientswindows users login to their
> windows systems (some running OpenAFS 1.4.0, not sure what othe
Hi, we upgraded our AFS server keys this morning and things went
smoothly for our unix clients, but we are seeing some problems with
authentication on our windows clientswindows users login to their
windows systems (some running OpenAFS 1.4.0, not sure what others are
running), the system says
Source code tarball. The SuSE srpm is v 1.3.78 (not 1.3.87 as prev
mentioned) and shouldn't be used.
AFS revisions are moving too fast for SuSe to support. Their policy is
to release the latest stable release that is in effect at their release
time and not update to later stable releases.
t
OK. Sorry for bothering. This is the dynroot feature which ignores the
root.afs volume contents cf. Email dated 27 Feb 2003 by Derek Atkins, and
which is turned on by default on the rpm distro.
I removed -dynroot from the /etc/sysconfig/openafs config file, and
everything now works like before
Christophe BERNARD <[EMAIL PROTECTED]> writes:
> The cell name is (say) abc.com, and I used to put a symbolic link abc ->
> abc.com in /afs:
> /afs/abc -> /afs/abc.com
> Bad luck, the abc symbolic link does not show up any more on the latest
> fedora core 4 / openafs 1.4.0 client.
The current
Hello.
I installed a long awaited RPM openafs distro on a 64 bit fedora core 4
client. The server is still running 1.2.13 on a fedora core 1.
Works mostly well (krb5/aklog/afs access). Just one problem I do not how
to solve:
The cell name is (say) abc.com, and I used to put a symbolic link
Tony D'Amato <[EMAIL PROTECTED]> writes:
> Just a thought, but one thing the person may want to try is to make sure
> they're using the same gcc to compile the OpenAFS modules that was used
> to compile the GNU/Linux kernel... I just ran into the "#error Not sure
> what to do about rlim" message o
> Derek Atkins <[EMAIL PROTECTED]> writes:
> > Russ Allbery <[EMAIL PROTECTED]> writes:
>
> >> As I mentioned in private e-mail, you're barking up the wrong tree
> >> here. Your kernel headers won't compile *period*, which is why rlim
> >> isn't found. Every configure check that attempts to use
ted creedon <[EMAIL PROTECTED]> writes:
> Recompile always works on SuSE. 10.0 ships with 1.3.87 which is obsolete.
When you say "recompile always works on SuSE" do you mean recompiling
the OpenAFS-distributed SRPM or do you mean recompiling the source
code tarball?
-derek
--
Derek Atki
On Tue, 20 Dec 2005, ted creedon wrote:
Recompile always works on SuSE. 10.0 ships with 1.3.87 which is obsolete.
Derek Atkins wrote:
Leroy Tennison <[EMAIL PROTECTED]> writes:
I have installed OpenAFS on Linux using the following:
openafs-1.4.0-fc3.1.i386.rpmI assume this is a
Hi,
When testing largefile support of 1.4.0, we have found a strange problem:
- created a 10GB vicepb partition of type ext3 (using lvm2)
- we had a volume dump file of 3 GB with one large file of 3 GB
- I issue 4 times "vos restore $HOST vicepb bigvol[1,2,3,4]
/voldump/3gb_vol.dump", the last on
Recompile always works on SuSE. 10.0 ships with 1.3.87 which is obsolete.
Derek Atkins wrote:
Leroy Tennison <[EMAIL PROTECTED]> writes:
I have installed OpenAFS on Linux using the following:
openafs-1.4.0-fc3.1.i386.rpmI assume this is a 'base' rpm
openafs-client-1.4.0-fc3.1.i386
Leroy Tennison <[EMAIL PROTECTED]> writes:
> I have installed OpenAFS on Linux using the following:
>
> openafs-1.4.0-fc3.1.i386.rpmI assume this is a 'base' rpm
> openafs-client-1.4.0-fc3.1.i386.rpmI assume this is client functionality
> openafs-docs-1.4.0-fc3.1.i386.rpmDocume
Derrick J Brashear <[EMAIL PROTECTED]> writes:
> I ran IBM AFS patched to do inode fileserver on Linux 2.0.30 or so, but I
> don't know that I ever passed those patches back to Derek (this was in the
> Linux-AFS days)
I... don't recall. I think I just failed to support "fileserver"
on Linux.
In message <[EMAIL PROTECTED]>,Frank Burkhardt writes:
>My guess: The openafs-client doesn't seem to enforce the r-permission
>correctly when the stat-data of the examined file is cached.
you are right. its not enforced. its not difficult to fix this. there
are a couple issues. dentry lookup ge
Hi,
On Mon, Dec 19, 2005 at 04:19:01PM -0500, Jeffrey Altman wrote:
> Lars Schimmer wrote:
> > Hi!
> >
> > Today I had a strange problem.
> > 1.4 server, 1.4 clients on win and linux.
> > A user could went down a path to a directory and there were just 0 byte
> > files in it.
>
> a directory lis
39 matches
Mail list logo
