Gregory Shaw wrote:
On Mon, 2006-03-20 at 10:25, Darren J Moffat wrote:
Gregory Shaw wrote:
Actually, what NWAM is talking about it network roaming profiles.
NWAM is more than just roaming profiles it is a complete redesign
of how we bring up networking and core network services.
What I'm talking about is providing the work environment regardless of
network connection (wired, wireless and most importantly, disconnected):
- automounts
nsswitch.conf already supports this quite well.
So, nsswitch.conf supports cached automounter information?
No nsswitch supports creating a config that can recover from the
network not being there.
I don't see the point in having the automounter work if the network
file server isn't there.
However if you are using cachefs to back the NFS file system then
that will work via the automounter if the maps are local.
- email address lookups
Thats a function of your mail program and I know that some of them
support lookup using a cached copy of the LDAP directory.
They do. However, they only cache account information that you've
already accessed. They do not, for example, allow you to look up an
email address for a user that you've never sent email to.
Thats not true. Some of them, for example Thunderbird/Mozilla,
allow you do download the whole directory (or a subset of it you
specify) for offline use (see the advanced tab in the address
book properties).
- login to the machine via directory services with cached directory
information
Hmn I'm not sure this is actually a good idea.
If we do not do this, you must provide local acocunts, which is far
worse, security wise, than cached directory information. This is what
I'm trying to avoid -- I believe that we should be able to leverage the
directory service for user information rather than building individual
local accounts.
Why do you think local accounts are any worse than a persistent cache ?
And, beyond that:
- Access to automounted data on the local machine (/usr/dist or a
software development area, for example).
You mean while not connected ?
Yes. It would learn what you access and provide access. Obviously, if
you access something that you've never accessed before, it won't have
that information. However, the working-set of information you do access
should be available locally.
cachefs, and cachefspack to populate the cache in advance if you wish.
If so cachefs is what you want.
I'll look into the latest cachefs. Historically, cachefs has some ugly
features which has made ongoing use difficult.
Ugly features or bugs that may have been fixed ?
- automated sync (and re-sync) of the data on any one particular machine
to a central server.
cachefs with disconnected mode can support some of this.
Filesync or rsync represent a communications mechanism. I'm looking for
something that a salesperson can use ongoing to allow them to work in
the field and in the office. Using filesync or rsync is an
administrator (or power user) activity, and far too difficult for the
average person to configure and use.
So if filesync had a GUI that you dragged files you wanted kept in sync
on to a little briefcase icon ? BTW filesync was written in response
to the briefcase functionality in windows.
Rather than dragging things, I'd much rather have it be driven from the
OS level. If you have to drag and drop, you, as a user, has to
understand everything that has been accessed. Most non-technical users
don't understand this, which decreases the usefulness of the briefcase
solution.
So have it setup just to sync the whole user home directory. Or just
use cachefs for the home directory with disconnected mode.
tuning to download the entire directory service (such as ou=people), but
that could be driven externally.
Some mail clients already support that.
Yes, but if you could count on the service being available across the
board, you wouldn't limit the user's choice of email client.
Thats an interesting idea, but might not be that easy to implement
due to how the LDAP protocol works. Particularly since you may need
to actively authenticate to get access to some LDAP data due to the ACL
entries on individual objects. This could mean that you need to
replicate the whole data ACL model into the client - but that won't be
trust worthy and how can you ensure that cached data isn't just read by
other means ? What you end doing is making the client a full Directory
Server replica and therefore a trusted host (not what you want in a
laptop!). Now if you assume that you only cache data the user could
normally read that might be easier to implement.
This of course would assume that all clients used the same LDAP library,
thats not actually true today and isn't the fault of the OS but of the
application developers who choose to include their own rather than use
the one already in the OS (you know who you are!!).
--
Darren J Moffat
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
