Re: Setting up sfssd on Linux: Success!, what about dhcp hosts?

Hi David,

> > Date: Tue, 25 Mar 2003 23:31:46 +0100 (CET)
> > From: Wout Mertens <wmertens@xxxxxxxxx>
> >
> > I just tested this by setting SFS_HOSTNAME to my ip address, and it works.
> > Is there a reason for this? I would think that anything that resolves to
> > the correct host would be okay, as long as the public key matches?
> >
> > If there is a reason, could it please be documented, and if there is no
> > reason, could it please be fixed? :)
>
> There are two reasons.  First is that you might want to host multiple
> virtual SFS servers on a machine.  In that case, you would have
> multiple CNAME (or A) records pointing to the same machine.  sfssd
> can be configured to pass different connections to different instances
> of sfsrwsd.

And now that I reread the sfssd documentation, I see how it is done. Nice!

> The second reason is that we want each file system to have only one
> name.  Otherwise, on the client, the same file system might look like
> two different mount points.  This has some potentially bad effects,
> like wasting cache space, or worse yet losing people's data if they
> ever try to copy a file onto itself.

Ok, I follow this argument. But couldn't this be fixed as follows:
- If you login on a cname of a hostid, and it doesn't have a server
running for that cname, it will create the usual link, but it is a symlink
to the real hostid.
- If you try to follow a link of the form /sfs/@cname,hash, and you
don't have a server running specifically for that cname, it will create
the real /sfs/@hostid,hash and make the former a symlink to it.
- If you try the above with a multihosting server, and the cname is not
exactly matched, it creates the symlink to the first hostid specified.

The fact that it is a symlink makes the copy problem go away, the os
should complain that it's the same file.

So suppose that I have a laptop called unseen. Each time my ip address
changes, I restart sfssd with the SFS_HOSTNAME set to my ip, and the
sfsauthd is part of the realm 'unseen'. I change a dyndns hostname,
unseen.dyndns.org (not my hostname), to that ip address. I have unseen
pointing to 127.0.0.1 in my hosts file.

Now I can access my laptop, using sfskey login @unseen.dyndns.org, or if
I'm logged in locally with sfskey login @unseen or whatever way, I can
expect the name or ip I used to be existing under /sfs:
/sfs/unseen.dyndns.org -> @<my ip>,<hash>
/sfs/@unseen,<hash> -> @<my ip>,<hash>
/sfs/@<my ip>,<hash> -> .mnt/foo/bar

On my fixed host, foo.bar.com, cname fluffy, /sfs/ could look like:
/sfs/fluffy -> @foo.bar.com,<hash>
/sfs/@fluffy,<hash> -> @foo.bar.com.<hash>
/sfs/@foo.bar.com.<hash> -> .mnt/....

I think this could be easily implemented (tall statement, not having read
the source), and generally makes sense. In fact, I guess that the code for
sfskey hostid already does the decision in the third point above.

> Note that "sfskey login" definitely should work with CNAMES.  Thus,
> really the right way of doing things is to set things up so users
> don't ever worry about self-certifying pathnames--they just run
> "sfskey login host", and it works whichever alias they use for host.

Yup, but then it creates a name different from the one that they gave. You
have to parse the output of login, or even use sfskey hostid, to be able
to script things.

Wout.