[orris]

Sorry been out of town.

Zero,

Nope. Not the problem. I mean, this has been turned on.
I agree though, kinda silly.

Just a bit confused about where it’s failing in the key exchange.

[orris]

Sorry, out to lunch for the last several days…

Here’s more info

I’ve set up a cluster and want people to log into the head node and then spawn processes on the compute nodes as needed either through Xgrid or ssh or mpich2. I’d like to have the users kinit on there own machines and log into the head node with a forwardable ticket. The first time through the ticket is ok and the credential cache is set to something like API:krb5cc_ I haven’t a clue where this tmp file is located. Looked for it to no avail. But, when a user attempts to ssh into the compute nodes on the other side of the head node’s firewall they are asked for a password, instead of being properly authenticated. If at this point one goes back to the head node and asks to kinit the error

kinit: Unable to make ‘Initial default ccache’ the new system default cache

is returned and the previous forwardable tickets are destroyed. This seems to be a problem with the forwarding of tickets since a workaround I’ve found is to not ask for the initial ticket and to authenticate to the head node via ssh and not kerberos. After successfully logging into the head node one can then kinit and the initial default ccache works and is forwardable to the compute nodes.

It also works if you unsetenv KRB5CCNAME before kinit’ing on the head node! Indicating a problem with passing of the credential cache name.

Any clues?

Regards

[orris]

OK Folks….
Here’s the problem….

As Joel had pointed out in his article on LOM, you MUST install the Server Admin tools from the DVD’s.
DO NOT THINK THAT THE SERVER ADMIN TOOLS THAT WERE PRE-INSTALLED WILL WORK!!!!
Furthermore, you need to have a FQDN (which can be local) on the subnet for the LOM ethernet address.

Why does Apple like to waste our time?!?
One would think that at least a WORKING COPY would be installed at the factory!

Thanks again for the site

Regards

[orris]

Sorry to have missed all the chatter…Been busy and there are so many other problems

I cannot connect with the server monitor to a machine with a working DNS using anything other than 127.0.0.1.
I would assume that that machine would know who it was and had a FQDN with reverse lookup.
I’ll be honest, in my last 15 months experience with the Xserve, nothing has worked as advertised. This has been especially true of the GUI apps. Without web sites such as AFP548, and their help, everything would work about as well as the Server Monitor.

But I digress…

from
http://docs.info.apple.com/article.html?artnum=106830

“The reason for this is that Server Monitor requires either:
that the IP address of a server be resolved using a DNS name assigned to the server’s IP address,

or
that one of several other specific actions be taken, which include using “localhost” as the server’s hostname or making modifications to NetInfo.”

Are they claiming here that Netinfo needs to be modified? In my case, clearly the first of these claims did not work.

[orris]

Yep.

But I should also say that I’ve had it on a G5 and a G4 and it never worked there either…..

Curious….

[orris]

Seen the same problem several times.

My experience with this is that the you need to disable and re-enable the afp network mount in the sharing pane of the Workgroup Manager. For some reason, that reamains unclear to me, after this the choices of home directory will work properly again. Obvously, information on the exports is being lost somehow, even though the choices are present they are ignored.

[orris]

Thanks! I experimented with this some by creating a network user and modifying the local NetInfo database appropriately to match two different types of users. This essentially required the addition of several new fields
original_authentication_authority
authentication_authority
original_node_name
sharedDir
original_node_name
mcx_flags
preserved_attributes
mcx_settings
original_home_loc
original_home
original_passwd

Additionally the gnerateduid needed to be changed to match the network user generateduid.

This just seems like a heck of a complicated work around!
Anyway, Thanks for the help!

[orris]

Your suggestion works very well….For network managed users. In this case the afpticket is issued at the time of the login. If however, the user is authenticated locally, but has a network account as well, then they seem to be out of luck.

There is a command line program called mnthome that seems to be just the thing to use, but it returns
Error: There is no home_loc for

[orris]

At the outset, thanks for the site. Lots of little pieces of information not easily learned from manuals.

What I’d like to have happen is after a user logs onto their own computer, that the disks on the server could be mounted by accessing the mount point via command line or finder the way old NIS/NFS automount/autofs used to work under our old UNIX system. However, I’d like the signon authentication of a kerberized afp, but not the tunnel of ssh, since I don’t want the server encrypting/decrypting all packets.

On the server:
AFP: Guest acces enabled, kerberos enabled, Bonjour enabled, secure connections enabled, authentication Kerberos

I’d like to share a volume giving read privileges to several groups, and ownership of folders/directories therein to users. This would be to allow a rudimentary collaboration/backup Volume.

Sharing settings at the top level volume:
Share enabled, ACL enabled, Volume ownership root:staff, Volume permissions 755, AFP share enabled, AFP guest access enabled, network mounting enabled via AFP, Use for “User Home Directories”

In this volume are several folders/directories owned by users with specific entries in the LDAPv3 domain.

On the Client Machine side the Directory Access is set to the correct binding LDAP server, (however, I should point out an annoying bug, that it never lets me unbind from that server).

Once the user logs in with their password they are asked to choose a workgroup (choice seems irrelevant). The login finishes a finder window is initiated and one clicks on Network then Server then on the server name and a list folders appears
Groups
Users
Volumes
Shared

Further attempts at accessing any of these folders is met with no response. No challenge for authentication (which is what I’d like to have happen). If one obtains a kerberos ticket from the server, manually kills and starts the automount daemon in debug mode, and migrates over to the server folder again, then there is a tremendous list of failed attempts at mounting resulting in either error 5 IO Error, 80, 45 Operation not permitted, or 2, depending on the specifics of the files one is attempting to access. Next if one gets a kerberos ticket and manually connects to the server a new afpserver ticket appears under /usr/bin/klist. Now if you kill the automounter again and restart it, anything mounted as static (I know this is not strictly what I’m after) can be mounted successfully. But, I really can’t have my users go to this much trouble to access their backup/file server.

Any suggestions or hints would be much appreciated!

[orris]

Is there a way to use kerberos for a single signon to authenticate to a server that would allow clients to automount several shared network mounts from the same server on the fly? Everything I’ve read would seem to imply that this is the point of kerberized afp and automount, but I’ve yet to see it work as advertised.

[Author]

Posts