Re: Thoughts on roaming laptop setup for Debian Edu
Petter Reinholdtsen wrote:
> For some years now, I have wondered how we should handle laptops in
> Debian Edu. The Debian Edu infrastructure is mostly designed to handle
> stationary computers, and less suited for computers that come and go.
For some years, I've implemented various solutions for this, and all
have their pitfalls.
The first setups was a rather normal installation, where the user
created during installation was a normal user.
Also we've set up installations with a common username ("bruker"), and
where the connection to the homedirecotory was done through a script,
where the user was asked for their username, before the connection was
done either through sshfs or smbfs/cifs
We've then tried a solution using pam-ccreds and nss-update together
with sshfs connection during login. This also worked from home, using a
special variant of ppp over ssh. Although it now seems to work most of
the time, we've stopped using that method. The problem was caused by
connections that was disconnected. These disconnections is caused by
using wlan as the carrier, and often home-targeted wlan routers to be
used in offices where there are several teachers.
The main problem was connection to shared folders. These folders are
used by several users (teachers), and although it's not a problem with
the disk-space, there would soon be a problem with lock-files, and
question on how often one should synchronize.
Unison each 5 minute or so could maybe be used, but it would need to run
as root user on the laptop and on the server, and I don't like that.
What we've ended up with the latest version is a version that tests
during startup if there is a local user created. If not, kdm automaticly
logs in a system user, which asks for a username and a password. Then
the scripts tries to authenticate against the ldap server. If
successful, a local user user is created, and then it returns back to
the kdm login screen. It also sets the name of the laptop to the
"owners" name, and gives the user sudo access to the machine. The system
disk is mounted read only, but during creation of a local user, tit's
remounted read-write.
When there is a user (either just created, or created previously), a
local login is done. Then there is a script to connect to some shared
folder, and the user homedirectory using cifs. Cifs is chosen because in
real life, I feel it's more robust than sshfs. it's better at handling
disconnections. When connection is done, the user is prompted for a
password.
The main reason is that most connections are done using wireless, and
most often, this connection is done after the user has logged in.
There is still a task to get the passwords synchronized whenever the
user changes passwords.
So to summarize the pitfalls.
- Network connections usually happens after the user has logged in, so
during authentication, the user to be authenticated locally
- Simple wlan leads to drop in the connection , causing sshfs to hang,
cifs/smbfs is somewhat better (according to real life experience)
- pam-ccreds and nss-update is not stable enough on Lenny
Reply to: