I have the following ports open :
omega:~# nmap -sU omega.domain.edu
Starting nmap 3.81 ( http://www.insecure.org/nmap/ ) at 2005-08-30 17:29 EDT
Interesting ports on omega (xy.xy.xy.xxx):
(The 1471 ports scanned but not shown below are in state: closed)
PORT STATE SERVICE
123/udp op
What are the ports needed for file server to be able to respond to clients ?
Our file server is up and working, users are able to login over ssh with
their kerberos credentials, but openafs clients seem to be unable to connect.
On Friday 26 August 2005 8:15 pm, Russ Allbery wrote:
> I think mo
FYI also, for when it makes it into a release - the byte range locking
support should work against ANY server version, it's only a change to
the client-side code.
-- Nathan
Nathan Neulinger EMail: [EMAIL PROTECTE
Windows 2003 does not use a kvno of 0 for all tickets.
If you force the kvno to 0 when exporting from ktpass, it won't work.
Jeffrey Altman
Davis, Adam wrote:
>
>
> upgraded to AFS_1.3.87 so that i can authenticate against Windows 2003
>
> Seem to be getting a key mismatch !!! I forced all kv
Title: ticket contained unknown key version number
upgraded to AFS_1.3.87 so that i can authenticate against Windows 2003
Seem to be getting a key mismatch !!! I forced all kvno to 0 and am using MD5
keytabs imported using ktutil and bos_util ok
anyone seen this "ticket contained unkno
No. Byte range locking is not in the 1.4 release.
Byte range locking exists on the CVS HEAD and will be released
in a future 1.4 release once it is stable.
Apparently the CVS HEAD version of the afs-changes file was
published instead of the 1.4 version.
The correct version is available at
/af
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi!
Just studied the release notes to the 1.4 release.
There is written:
Byte-range locking as described in cm_vnodeops.c has been implemented.
Does that mean, we can now safely edit MS Office Files IN AFS Space
while all servers/clients are 1.4 vers
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ok+
Forget my last post.
After a reboot and another vos release all is back to last state..
Thx so far.
Another day gone by...
Lars
- --
- -
TU Graz, Institut für ComputerGraphik & WissensVi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jeffrey Altman wrote:
> Lars:
>
> Your clients cannot read the contents of the krb.conf file
> on your AFS server. The clients must determine the Kerberos
> REALM name based upon the DNS name of the VLDB servers. If
> your VLDB servers have a DNS
As long as you are using a recent version of OpenAFS for your
clients and servers, 1.4 RC2 is current, then you can utilize
Active Directory as the realm associated with the cell.
You need to add a service principal of "afs/[EMAIL PROTECTED]"
to AD and set the account to "use DES only". Export t
Lars:
Your clients cannot read the contents of the krb.conf file
on your AFS server. The clients must determine the Kerberos
REALM name based upon the DNS name of the VLDB servers. If
your VLDB servers have a DNS name that is "cgv.tugraz.at" then
they will think the realm they belong to is "CG
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jeffrey Altman wrote:
> What does "aklog -d" report?
It tells me:
aklog -d
Authenticating to cell cgv.tugraz.at (server phobos.cgv.tugraz.at).
We've deduced that we need to authenticate to realm CGV.TUGRAZ.AT.
Getting tickets: afs/[EMAIL PROTECTED]
Ke
What does "aklog -d" report?
also, did you configure your Cell to accept the new REALM as the home
cell via the AFS krb.conf file?
Jeffrey Altman
Lars Schimmer wrote:
> Hi!
>
> My setup getting worse any day.
> Now I setup a new MIT krb5 REALM for me and setup the users new in that
> realm.
> B
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi!
It's me again...
Now I setup the old cell with a new key.
My steps:
kadmin.local -e des-cbc-crc:v4 -q "addprinc
afs/[EMAIL PROTECTED]"
admin.local -q "modprinc -kvno 0 afs/[EMAIL PROTECTED]"
kadmin.local -e des-cbc-crc:v4 -q "ktadd -k /etc/krb
Hm. Again in HashOutDCache. It's be nice if we could see where the other
processes were, backtrace-wise, at this time. Bleh.
I suspect, though, that GetDownD may need to hold another lock across the
call to HashOutDCache. I will look when I'm more awake.
Derrick
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi!
After all my ideas went wrong til yet, i need some advice.
I've got a subnet with about 40 PCs, some Windows, some Linux.
The Windows Clients should resist in a AD/Domain under win2003 server.
All clients should use kerberos5 and should obtain ti
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Lars Schimmer wrote:
> Lars Schimmer wrote:
> .
>
>>>But under windows with the MIT Leash manager while obtaining
>>>tickets/tokens, the leash manager hangs and after killing it, I've
>>>obtained tickets, no tokens.
>>>Any hints?
>
>
> Oh, its just
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Lars Schimmer wrote:
.
> But under windows with the MIT Leash manager while obtaining
> tickets/tokens, the leash manager hangs and after killing it, I've
> obtained tickets, no tokens.
> Any hints?
Oh, its just a lng time to obtain a token. Stran
touch /vicep?/AlwaysAttach will cause /vicep? to be considered a valid
container for volumes even if /vicep? is not a mount point.
-Matt Andrews
Russ Allbery wrote:
Madhusudan Singh <[EMAIL PROTECTED]> writes:
Ok. What if I add additional mass storage (say a bunch of USB hard
disks) whi
Got a new oops today , slightly different:
ksymoops 2.4.11 on i686 2.4.31. Options used
-V (default)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.4.31/ (default)
-m /usr/src/linux/System.map (default)
Warning: You did not tell me where
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi!
My setup getting worse any day.
Now I setup a new MIT krb5 REALM for me and setup the users new in that
realm.
But now the REALM is different from the AFS Cell.
So I added the principal afs/[EMAIL PROTECTED] and added the
key from krb5 to AFS.
Und
21 matches
Mail list logo
