[K12OSN] Re: SMBLDAP question (David Trask)

[Matt Oquist]

> Date: Fri, 06 Oct 2006 00:03:53 -0400
> From: "David Trask" <dtrask at vcsvikings.org>
> Subject: Re: [K12OSN] SMBLDAP question
> >I have a really dumb question; I am hoping maybe David Trask or some
> >other kind soul can help me:
> >I have a lab set up with Edubuntu workstations and a Ubuntu server.  We
> >use SMBLDAP to authenticate student logins on the server. 
> >The guy who helped me set it up sent me some directions; the first thing
> >it tells me to do is mv /home/administrator /administrator and then
> >usermod -d /administrator.  We make "admin" a local login and
> >administrator a server login. 
> 
> Wow, this is the hard way....just log in as root or at least "sudo" ( you
> may need to tweak the sudoers file) and then just 'git 'er done....your
> scenario you describe above is just too cumbersome

Not to be contrarian or anything, but what you were advised to do
sounds exactly right, assuming that you're mounting /home from an NFS
server over /home on each workstation. In fact, failing to move
/administrator out of /home before mounting the NFS export will at
least cause you Very Bad Problems when you try to log in using Gnome.

> >When I do this, I can no longer run anything, particularly the users &
> >groups GUI or the Synaptic Package Manager.  
> >My question is, is there a way to make these things run without the
> >existence of the /home/administrator directory? 

That seems odd; the home directory shouldn't have anything to do with
this. (So the answer to your question is "yes, by doing just what
you've described.")

Keep in mind that if you're running Samba/LDAP you probably don't want
to use the Users & Groups GUI anyway, because it can't help you with
your LDAP users.

Is it still possible for you to run the 'sudo su -' command and become
root?

> Yeah....as root.  Just be careful.

Hmm. Not to be contrarian, but you can only run the GUI apps as root
if you do one of the following:
1) enable a graphical root login, which is definitely more trouble than it's worth
2) enable TCP connections to an Xserver, enable a remote host to
   connect to your X session (xhost), and set DISPLAY=<your X host>
   when you run the GUI apps from the command line as root
3) enable root logins via ssh and ssh -X into your box and then run
   the GUI apps from the command line

Of those options, the best by far is #3, which requires only that you
set a root password ('sudo passwd'), ssh -X root at localhost, and then
run 'synaptic' or whatever else.

But it would be preferable for you just to 'sudo synaptic' instead, in
which case you should just be able to run it from the menu like
usual...and since you can't do that, I wonder how far you'll be able
to get with any of the rest of this.

> >Any other ideas for ways to make these Edubuntu workstation logins
> >authenticate on teh server?  Any ideas for speeding up the computers that
> >authenticate really slowly?  I need to set up 2 workstations that puked
> >on me; I also have a couple of workstations that take 3+ minutes to log a
> >student in.  The other workstations log people in in under 30 sec's. 

LDAP is the best of the available alternatives, and with the caveat
that I know the author personally and am therefore biased, I must say
that the Samba/LDAP installer makes it pretty easy to set up LDAP,
even if you don't care about Samba.

Your authentication times do not sound at all happy; especially if
this is a small number of workstations in a single room with the
server right there, we should be talking about something <10 seconds
for the actual authentication part.

Just to double-check, it sounds like you're talking about regular fat
clients and an Ubuntu Samba/LDAP and file server, right?

--matt

--
Open Source Software Engineering Consultant
http://majen.net/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: Digital signature
URL: <http://listman.redhat.com/archives/k12osn/attachments/20061006/844f4960/attachment.sig>