> Here the cpu authentication is succeeding but then the > file server doesn't allow the mount because the user is unknown. > You have to add the user. This is unfortunate for 9grid purposes > but it's the way it is. I suspect you are also going to need > your cpu server's host id to be able to speak for the incoming users > in order to mount the root file system before there is a /mnt/factotum > for the user, which is also unfortunate. There are definitely still > issues to be resolved -- the hooks for cross-domain authentication > are there in factotum but the rest of the system will need some work.
Would it be out of the question to add an option to Fossil that constructs users on the fly? Or perhaps the type of utility used on sources to create new users, but limited to entries authenticated from a /lib/ndb/auth-listed authentication source? Something that is done preliminary to establishing a CPU connection so it is executed in an authoritative namespace and with sensible defaults? What strikes me is that if one delegates authentication to sources, one may as well accept its authority insofar as the existence of users is concerned. One may want to use a dedicated fileserver to the purpose, so as to protect one's own network, but that only mirrors what sources already does. What are the security implications here? ++L
