Sun thin clients -- Leopard Server

[Rick Davis]

A bit of a long shot, probably off topic, but hoping for some help.

Our school district has decided to test a Sun Ray thin client project  
at one of our Mac schools and the Sun guys are trying to bind the Sun  
server to the current OS X server to authenticate the users on the  
Sun Rays and provide network storage that can be accessed from both  
the Sun Rays and the Mac clients.  But they're not having much luck.  
Anybody out there had any luck doing something like this? So far I  
can only find information about binding an OS X client to a Sun  
server, not much help.

Any suggestions greatly appreciated.

Rick Davis
_______________________________________________
MacOSX-admin mailing list
MacOSX-admin@...
http://www.omnigroup.com/mailman/listinfo/macosx-admin

[paul kölle]

Rick Davis schrieb:

> A bit of a long shot, probably off topic, but hoping for some help.
>
> Our school district has decided to test a Sun Ray thin client project at
> one of our Mac schools and the Sun guys are trying to bind the Sun
> server to the current OS X server to authenticate the users on the Sun
> Rays and provide network storage that can be accessed from both the Sun
> Rays and the Mac clients.  But they're not having much luck.  Anybody
> out there had any luck doing something like this? So far I can only find
> information about binding an OS X client to a Sun server, not much help.
>
> Any suggestions greatly appreciated.

Hi,

can you be a bit more specific what you mean by "binding"? Are they
trying to authenticate users via LDAP against the OSX server?

cheers
  Paul

_______________________________________________
MacOSX-admin mailing list
MacOSX-admin@...
http://www.omnigroup.com/mailman/listinfo/macosx-admin

[Neil Laubenthal]

You need to convince the Leopard Server to be the NIS+ master for the  
Suns . . . on the Solaris side this is just a matter of plugging in  
the IP IIRC. Don't know for sure what you have to do on the Leopard  
side; perhaps set it up in Directory Services maybe? You'll also have  
to (I think) either set up the Leopard shares (for homedirs and such)  
as either SMB or NFS as I don't think the Sunray server will use AFP  
shares for this.

What are you going to run for apps on the SunRays? It comes up with  
the default Solaris desktop which includes Netscape . . .and I think  
you can also load Firefox on it. However, for any word processing, etc  
. . . you'll either to load Star Office (or whatever Sun calls their  
version of it) on the SunRay servers and share the apps . . . or  
you'll need to set up Citrix to provide Windows applications.

Using Star Office or whatever it is makes the easiest/cheapest setup .  
. . but then you're stuck with the Sun like UI instead of something a  
little more user friendly. The new Solaris 10 UI is better; but still  
not as easy to navigate as Leopard.



Quoting paul <paul@...>:

> Rick Davis schrieb:
>> A bit of a long shot, probably off topic, but hoping for some help.
>>
>> Our school district has decided to test a Sun Ray thin client  
>> project at one of our Mac schools and the Sun guys are trying to  
>> bind the Sun server to the current OS X server to authenticate the  
>> users on the Sun Rays and provide network storage that can be  
>> accessed from both the Sun Rays and the Mac clients.  But they're  
>> not having much luck.  Anybody out there had any luck doing  
>> something like this? So far I can only find information about  
>> binding an OS X client to a Sun server, not much help.
>>
>> Any suggestions greatly appreciated.
> Hi,
>
> can you be a bit more specific what you mean by "binding"? Are they
> trying to authenticate users via LDAP against the OSX server?
>
> cheers
>  Paul
>
> _______________________________________________
> MacOSX-admin mailing list
> MacOSX-admin@...
> http://www.omnigroup.com/mailman/listinfo/macosx-admin

--

There are only three kinds of stress . . .your basic nuclear stress, cooking
stress, and A$$ho1e stress. The key to relating them is . . . Jello.

neil

_______________________________________________
MacOSX-admin mailing list
MacOSX-admin@...
http://www.omnigroup.com/mailman/listinfo/macosx-admin

[paul kölle]

Neil Laubenthal schrieb:
> You need to convince the Leopard Server to be the NIS+ master for the
> Suns . . .
Really? I thought NIS(+) is pretty much a dead technology. I haven't
seen any traces of it on OSX Server (and with good reasons IMO).

>
> What are you going to run for apps on the SunRays? It comes up with the
> default Solaris desktop which includes Netscape . . .and I think you can
> also load Firefox on it. However, for any word processing, etc . . .
> you'll either to load Star Office (or whatever Sun calls their version
> of it) on the SunRay servers and share the apps . . . or you'll need to
> set up Citrix to provide Windows applications.
SunRays are mostly used as terminals (no hd). Look at the specs, you
wouldn't want to run Office on this client No? With something like "Sun
Secure Global Desktop" (formerly tarantella) you can have X Sessions or
RDP for Apps.

cheers
  Paul

_______________________________________________
MacOSX-admin mailing list
MacOSX-admin@...
http://www.omnigroup.com/mailman/listinfo/macosx-admin

[Neil Laubenthal]

On Aug 8, 2008, at 17:49, paul wrote:

> Neil Laubenthal schrieb:
>> You need to convince the Leopard Server to be the NIS+ master for  
>> the Suns . . .
> Really? I thought NIS(+) is pretty much a dead technology. I haven't  
> seen any traces of it on OSX Server (and with good reasons IMO).

Could be . . . but that's what Solaris uses.

>
>
>> What are you going to run for apps on the SunRays? It comes up with  
>> the default Solaris desktop which includes Netscape . . .and I  
>> think you can also load Firefox on it. However, for any word  
>> processing, etc . . . you'll either to load Star Office (or  
>> whatever Sun calls their version of it) on the SunRay servers and  
>> share the apps . . . or you'll need to set up Citrix to provide  
>> Windows applications.
> SunRays are mostly used as terminals (no hd). Look at the specs, you  
> wouldn't want to run Office on this client No? With something like  
> "Sun Secure Global Desktop" (formerly tarantella) you can have X  
> Sessions or RDP for Apps.

Yup . . . they're thin clients. They need a Solaris server on the back  
end to make them work; the Solaris server provides authentication, IP  
and all that other connectivity stuff allong with the applications  
that are seen on the SunRay. You still need some sort of applications  
to run. X Sessions work and are available . . .and will let you run  
Star Office but as I said that isn't a very user friendly desktop. You  
can run RDP to connect to Windows application servers; but then you  
end up needing Citrix to host the windows apps. You're not running  
apps on the client; just the Citrix RDP client to connect to Citrix  
(or directly to a Windows server using Terminal Services only although  
there are some drawbacks to doing it this way from the user standpoint).

We installed a SunRay system at DoD where I used to work . . . but the  
users really want Microsoft Office. They don't want Star Office or  
Open Office or any of that stuff . . . most users want the full  
fledged Microsoft Office to do their real work and the only way to get  
this is to run Windows on the back end. OTOH, if the IT staff can get  
enough support from management to force the users to use Open Office  
or something that will run on the SunRay session server instead; then  
it's a reasonably decent setup.

Out of the box . . . the SunRay system gives you a browser, a terminal  
window, and a text editor. Under Solaris 9 (which was the last version  
of it I used) the "office automation" package that ran on the SunRay  
session server to actually do real work still pretty much sucked  
rocks. Maybe things have improved Solaris application wise in the past  
2 years . . . but it still won't be MS Office and hence will displease  
most users (and hence upper management who then tells IT to use Office).



>
>
> cheers
> Paul
>
> _______________________________________________
> MacOSX-admin mailing list
> MacOSX-admin@...
> http://www.omnigroup.com/mailman/listinfo/macosx-admin

_______________________________________________
MacOSX-admin mailing list
MacOSX-admin@...
http://www.omnigroup.com/mailman/listinfo/macosx-admin

[Rick Davis]

On Aug 8, 2008, at 2:59 PM, Paul wrote:

> can you be a bit more specific what you mean by "binding"? Are they
> trying to authenticate users via LDAP against the OSX server?

Sorry perhaps bind is not the correct term. The two goals are to  
authenticate the users via LDAP against the OS X Server and provide  
network home directories to the users that can be accessed from both  
the Sun clients and OS X clients.

Thanks.

Rick Davis
_______________________________________________
MacOSX-admin mailing list
MacOSX-admin@...
http://www.omnigroup.com/mailman/listinfo/macosx-admin

[Rick Davis]

On Aug 8, 2008, at 2:59 PM, Neil wrote:

> You need to convince the Leopard Server to be the NIS+ master for the
> Suns . . . on the Solaris side this is just a matter of plugging in
> the IP IIRC.

That was my thought and suggestion. I asked the Sun guy if we took  
the OS X server out of the picture how would he present a login  
window to the users for authentication. His reply was that a local  
password file would be used and it would be a pita to enter the 600+  
currents users and new students as they enroll in the future. And  
that he had never had to setup user accounts. ????

> Don't know for sure what you have to do on the Leopard
> side; perhaps set it up in Directory Services maybe? You'll also have
> to (I think) either set up the Leopard shares (for homedirs and such)
> as either SMB or NFS as I don't think the Sunray server will use AFP
> shares for this.

This was basically my second suggestion.  Just have the users sign on  
to the Sun clients as a generic student user then mount the leopard  
server share point for document storage. I figured NFS would be the  
logical choice. Not exactly what the district wants though, they want  
the users to have to authenticate before having access to internet  
apps, etc.


> What are you going to run for apps on the SunRays? It comes up with
> the default Solaris desktop which includes Netscape . . .and I think
> you can also load Firefox on it. However, for any word processing, etc
> . . . you'll either to load Star Office (or whatever Sun calls their
> version of it) on the SunRay servers and share the apps . . . or
> you'll need to set up Citrix to provide Windows applications.

StarOffice and Firefox will be the basic apps. Provided the slew of  
web based apps will work. Study Island, Accelerated Reader,  
Riverdeep, etc.  We are also considering a K12LTSP desktop solution  
with built-in education apps. There was mention of using AquaConnect  
to provide a Mac desktop environment, but they would rather not go  
with a solution that requires additional licenses. So I am also  
looking at trying to put together an OpenSource VNC solution.

They are also setting up a Sun lab in a windows school and will be  
using windows terminal services to provide a windows desktop and  
applications. They are working with the Novell guy to provide  
authentication there, not sure if that is going any better.

> Using Star Office or whatever it is makes the easiest/cheapest setup .
> . . but then you're stuck with the Sun like UI instead of something a
> little more user friendly. The new Solaris 10 UI is better; but still
> not as easy to navigate as Leopard.

This may the way to go, by just providing as many desktop shortcuts  
as possible. This school was still using a panels environment with  
Macintosh Manager on OS 9 machines last year.

Thanks and have a great day.

Rick Davis
_______________________________________________
MacOSX-admin mailing list
MacOSX-admin@...
http://www.omnigroup.com/mailman/listinfo/macosx-admin

[paul kölle]

Rick Davis schrieb:

>
> On Aug 8, 2008, at 2:59 PM, Paul wrote:
>
>> can you be a bit more specific what you mean by "binding"? Are they
>> trying to authenticate users via LDAP against the OSX server?
>
> Sorry perhaps bind is not the correct term. The two goals are to
> authenticate the users via LDAP against the OS X Server and provide
> network home directories to the users that can be accessed from both the
> Sun clients and OS X clients.

There are several ways to to this.

1. The easiest is to configure the sun server to get it's users from OS
X by configuring NSS (on the Sun server) to use LDAP. The OS X needs to
be configured to use OpenDirectory, not NetInfo. The drawback is, OS X
becomes single point of failure and group membership might be a problem
due to the way how OpenDirectory implements nested groups.

2. Setup OpenLDAP on the sun box and configure replication with OD. I've
done this for Tiger and it was tricky as OD doens't store the
userPassword if password type is set to "open directory". This way users
are still available on the Sun server when OS X goes down but the group
problem remains (you could hire someone from Symas (the OpenLDAP guys)
to write a custom overlay to unroll the groups).

3. Write your own replication script script to fetch information from OD
and import into an LDAP server on the sun box. Depends on your
requirements how close info on both sides must match.

Note that in 2. 3. you will have problems getting the passwords across
as they are not stored in OpenDirectory if the password type is set to
"Open directory".

WRT file storage, I'm not sure what the sunRays are capable of in terms
of network filesystem support. Remember that Apple has a custom
propritary ACL model which will most likely not work with NFS(v3). You
could try to mount the shares on the Sun server from OSX via CIFS and
re-export via NFS but I have no idea how that's going to work
performance wise and locks and acls etc.

cheers
  Paul


_______________________________________________
MacOSX-admin mailing list
MacOSX-admin@...
http://www.omnigroup.com/mailman/listinfo/macosx-admin

[Neil Laubenthal]

Each SunRay user has a little smart card that has his/her username  
encrypted on it but not the password. Each user also has an NIS+  
account on the Solaris server. The user pops his card in and then gets  
the login prompt where he puts in his username and password; each card  
typically only works for one username (i.e., you can't use person 1's  
card and person 2's username) although I think you can not use the  
cards if you prefer. The username/password is then passed to the NIS+  
Master for authentication; what you need to do is convince the NIS+  
master that it should talk either to the Leopard NIS+ database (or  
more likely convert it to LDAP and then ask the Leopard box).  Once  
the authentication is complete; the NIS+ master passes along to the  
SunRay session server that the user is OK and here are his  
privileges . . . LDAP doesn't understand the Solaris permissions so  
you may end up having to key in NIS+ accounts to set the permissions  
and just have the password part come from LDAP/Leopard.

The SunRay session server starts up a session and presents a desktop  
to the user at his SunRay. He launches apps and does whatever but all  
the actual work is done on the session server with only video passed  
over to the terminal. This allows the user to pop his card out, go to  
another terminal and reconnect to the existing session if he likes  
instead of logging out when he is done.

Once the session is running; you still need applications though. There  
are Sun provided and other open source apps that run on the session  
server. They work fine but are visually not as nice as Leopard . . .  
may have some compatibility issues with real Microsoft Office  
(particularly the latest version of Office . . . and just aren't as  
easy to use (X-Windows commands, funky buttons and mice that don't  
work quite the same in Solaris as they do in either Windows or MacOS.

Alternatively; the apps can be provided by Microsoft servers running  
either Terminal Services or Citrix so that you can use RDP to connect  
and run the Windows apps.

SunRays are used a lot in scientific situations where the apps you  
want to run are either Solaris apps or PERL apps and you just need  
lots of cpu cycles to do whatever analysis is being done. I haven't  
seen them used all that much in office type situations for the simple  
reason of cost. The Solaris hardware to make the system work is pretty  
expensive and if you're going to provide Windows servers on the back  
end so that users can use Microsoft Office you still need domain  
controllers, file servers, mail servers, etc . . . so you really don't  
save any money. The DoD does use them for this because if the session  
servers are running a special version called Trusted Solaris you can  
essentially connect multiple networks of different security  
classifications to the session servers. This allows a user to have a  
single terminal at his desktop but get multiple different networks on  
it. The session server and NIS+ server have been validated and  
certified by DoD to keep the different classifications separated and  
to allow each user access to only those things his security clearance  
authorizes. In this situation, particularly where you have 8 or 10  
different classified networks you can save some money by not having  
multiple networks running through the building and multiple computers  
at each desktop.


On Aug 8, 2008, at 23:15, Rick Davis wrote:

>
> On Aug 8, 2008, at 2:59 PM, Neil wrote:
>
>> You need to convince the Leopard Server to be the NIS+ master for the
>> Suns . . . on the Solaris side this is just a matter of plugging in
>> the IP IIRC.
>
> That was my thought and suggestion. I asked the Sun guy if we took  
> the OS X server out of the picture how would he present a login  
> window to the users for authentication. His reply was that a local  
> password file would be used and it would be a pita to enter the 600+  
> currents users and new students as they enroll in the future. And  
> that he had never had to setup user accounts. ????

_______________________________________________
MacOSX-admin mailing list
MacOSX-admin@...
http://www.omnigroup.com/mailman/listinfo/macosx-admin