[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: FW: slightly-OT: centralized user management



On Fri, Jul 29, 2005 at 08:57:12PM -0700, David Christensen wrote:
> Roberto C. Sanchez wrote:
> > But there was nothing about getting a "roaming profile" type of setup.
> 
> Roaming Profiles and Offline Folders are different Windows features.  You need
> domain networking and Windows Server (2003, maybe 2k) to enable the former, but
> only Workgroup networking and a workstation Windows (XP Pro, XP Home?, Win2k?)
> to do the later (also works with Domain networking).
> 
Right.  I am looking for something more cross platform.  At least to
cover Windows and Linux and maybe Mac OS X.  I am not familiar with
Windows networking, so I don't know what all the correct terminology is.
I just recall that at one place I worked everyone had laptops in docking
stations.  If you logged into the Windows domain at least once a
particular machine, it would cache your login credentials and your
Windows equivalent of $HOME.

> 
> I've heard of Unix implementations of the equivalent of Roaming Profiles (Sun?
> HP?), and may have used such on an HP graphics terminal, but I never roamed.
> There's probably an open-source equivalent out there.
> 
I spent several hours searching Google last night and came up empty.
The closest thing I found was a SourceForge project called huddleserver
that was registered in mid 2002 and is still in Planning stage (or
basically abandoned).  I think that simply mounting $HOME from an NFS
provides a fairly close approximation.  The problem comes with offline
support.

> 
> The closed *nix thing to Offline Folders that I've heard of is rsync.  CVS can
> provide similar functionality, and is more robust/ careful in the face of
> collisions.  I've used Offline Folders and administered laptops with it, and I
> don't like it.
> 
Last night I was thinking that it's not to difficult to create a mount
point (or even just use /home) where, when a user logs in under Linux,
rsync is used to copy the $HOME contents from the server.  After that,
logging out would trigger an rsync back to the server.  If the machine
was offline, then the rsync would delay until the machine was back on
the network.  However, there are a couple of issues with this approach:

- How would login credentials be stored/cached?  I know that Windows
  NT/2k/XP do this, but I know Linux does not.  It would require hacking
  together some sort of PAM module that con do this and be able to
  enforce the associated account policies as well.
- User 1 logs in at machine A, which is offline, and makes changes in
  $HOME.  He then logs in to machine B, which is online, and makes
  changes in $HOME.  The changes from B will immediately be sync'd to
  the server, but the changes from A will not.  When A is next on the
  network, the changed files in A will overwrite the more recent changes
  from B.  A CVS-type approach may help here.  This may also happens if
  the user logs into machine A (online) and then into machine B (online)
  and then makes different changes in both.  The changes of whichever
  machine is logged out last will be the ones preserved while the others
  are lost.

I think that is possible to solve the first problem with a PAM-based
approach, as I mentioned.  I think that the second approach could be
solved by two things:

- Disallow more than one login session on machines that are
  authenticating against the central authority (Samba/LDAP).
- (Not foolproof) Check timestamps on modified files.  If there are
  files on the server that have more recent timestamps than those on the
  local machine (i.e., changes from a previous login session were
  committed from a different machine), force the user to choose what to
  do.  This would require some interactive console and/or X-based dialog
  to prompt the user about which files have been changed and what to do
  about them.

> 
> My $0.02,
> 
> David
> 

I think I am approaching about $0.05 worth :-)

-Roberto

-- 
Roberto C. Sanchez
http://familiasanchez.net/~sanchezr

Attachment: pgptu5vqPg9zM.pgp
Description: PGP signature


Reply to: