Send SunRay-Users mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://www.filibeto.org/mailman/listinfo/sunray-users
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of SunRay-Users digest..."
Today's Topics:
1. Sunray server 4.0 strangeness (CJ Keist)
2. Re: Sunray server 4.0 strangeness (Bob Doolittle)
3. Re: Sunray server 4.0 strangeness (CJ Keist)
4. VPN + RSA? (Quayle, Bill)
5. RE: How to make JDS lock screen lock the screen and not
utdetach with NSCM (William Yang)
----------------------------------------------------------------------
Message: 1
Date: Thu, 12 Feb 2009 11:51:22 -0700
From: CJ Keist <[email protected]>
Subject: [SunRay-Users] Sunray server 4.0 strangeness
To: SunRay-Users mailing list <[email protected]>
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Skipped content of type multipart/mixed-------------- next
part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3287 bytes
Desc: S/MIME Cryptographic Signature
Url :
http://www.filibeto.org/pipermail/sunray-users/attachments/20090212/f8563daa/smime-0001.bin
------------------------------
Message: 2
Date: Thu, 12 Feb 2009 14:05:57 -0500
From: Bob Doolittle <[email protected]>
Subject: Re: [SunRay-Users] Sunray server 4.0 strangeness
To: SunRay-Users mailing list <[email protected]>
Message-ID: <[email protected]>
Content-Type: text/plain; format=flowed; charset=ISO-8859-1
What OS, what version of SRSS?
We've seen this in the past with OS bugs.
In the case in question (an old version of Solaris - maybe S8?), you
could do an "ls /proc/*" and ls would hang on a particular process PID.
Sorry I don't recall the bug.
-Bob
CJ Keist wrote:
All,
I have experienced this twice now in two days. One server in my
FOG gets in a strange state. Connections to the server are working
but applications will consistently freeze up. The Sunray web gui will
freeze if you try to look at that the problem server. The other
oddity is that if you try and run a "ps -ef" command on the problem
server it will hang and not complete the command?!?!
/var/adm/messages is not showing any memory errors that I can see.
Doing a utrestart doesn't fix the problem either.
Yesterday when I tried to just reboot this server it caused my
entire FOG to fail! I then and to restart each of my servers in the
FOG. utgstatus shows all is well on all servers. Any ideas on what
to look for?
------------------------------------------------------------------------
_______________________________________________
SunRay-Users mailing list
[email protected]
http://www.filibeto.org/mailman/listinfo/sunray-users
------------------------------
Message: 3
Date: Thu, 12 Feb 2009 12:16:08 -0700
From: CJ Keist <[email protected]>
Subject: Re: [SunRay-Users] Sunray server 4.0 strangeness
To: SunRay-Users mailing list <[email protected]>
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Running SRSS 4.0, patches 127553-05 installed. OS is Solaris 10:
SunOS sunfire4 5.10 Generic_137137-09 sun4v sparc SUNW,Sun-Fire-T200
ls /proc/* listed everything without hanging.
Bob Doolittle wrote:
What OS, what version of SRSS?
We've seen this in the past with OS bugs.
In the case in question (an old version of Solaris - maybe S8?), you
could do an "ls /proc/*" and ls would hang on a particular process PID.
Sorry I don't recall the bug.
-Bob
CJ Keist wrote:
All,
I have experienced this twice now in two days. One server in my
FOG gets in a strange state. Connections to the server are working
but applications will consistently freeze up. The Sunray web gui will
freeze if you try to look at that the problem server. The other
oddity is that if you try and run a "ps -ef" command on the problem
server it will hang and not complete the command?!?!
/var/adm/messages is not showing any memory errors that I can see.
Doing a utrestart doesn't fix the problem either.
Yesterday when I tried to just reboot this server it caused my
entire FOG to fail! I then and to restart each of my servers in the
FOG. utgstatus shows all is well on all servers. Any ideas on what
to look for?
------------------------------------------------------------------------
_______________________________________________
SunRay-Users mailing list
[email protected]
http://www.filibeto.org/mailman/listinfo/sunray-users
_______________________________________________
SunRay-Users mailing list
[email protected]
http://www.filibeto.org/mailman/listinfo/sunray-users
--
C. J. Keist Email: [email protected]
UNIX/Network Manager Phone: 970-491-0630
Engineering Network Services Fax: 970-491-5569
College of Engineering, CSU
Ft. Collins, CO 80523-1301
All I want is a chance to prove 'Money can't buy happiness'
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3287 bytes
Desc: S/MIME Cryptographic Signature
Url :
http://www.filibeto.org/pipermail/sunray-users/attachments/20090212/add910dd/smime-0001.bin
------------------------------
Message: 4
Date: Thu, 12 Feb 2009 14:17:05 -0600
From: "Quayle, Bill" <[email protected]>
Subject: [SunRay-Users] VPN + RSA?
To: "[email protected]" <[email protected]>
Message-ID:
<664fe4dff50e87498e150abc537236a6238b08c...@smapexmbx1.prod.ad.merc.chicago.cme.com>
Content-Type: text/plain; charset="us-ascii"
We have a requirement to use an RSA token for remote access. Our internal
deployment requires token card authentication, which would not change.
I envision something like:
1. User turns on their at-home Sun Ray, which has been pre-configured to
attach to the company VPN. The connection is established.
2. User inserts their token card.
3. Server software recognizes the DTU as an at-home device, and splashes
an RSA challenge screen up for the user to complete.
4. Successful completion of the RSA splash screen results in a connection
to their internal session.
5. Unsuccessful completion of the RSA challenge results in the DTU being
locked out. Details of the event sent to INFOSEC....
Or am I dreaming?
Thanks,
Bill
------------------------------
Message: 5
Date: Thu, 12 Feb 2009 17:57:39 -0500
From: "William Yang" <[email protected]>
Subject: RE: [SunRay-Users] How to make JDS lock screen lock the
screen and not utdetach with NSCM
To: "'SunRay-Users mailing list'" <[email protected]>
Message-ID: <00cc01c98d65$4e3884f0$eaa98e...@edu>
Content-Type: text/plain; charset="iso-8859-1"
Yes. But, we use our own compiled xscreensaver since the Sun-shipped one
had issues interacting with the pam_krb5 we use (slightly patched version
of
Russ Allbery's pam-krb5). So RHA is not triggered by the screensaver,
although it is still invoked on a smart card hotdesk event.
So I know our setup isn't supported, but I can come up with a
theoretically
supported situation which should be equivalently impacted:
Site uses NFSv4 with Kerberos for home directories. User's tickets expire
while detached, RHA does not refresh tickets on attaching, and user has
lost
access to home directory (the same thing basically happens with our AFS
setup).
The same resolution for that setup should be applicable to our AFS setup.
Any ideas?
Thanks,
William Yang
-----Original Message-----
From: [email protected] [mailto:sunray-users-
[email protected]] On Behalf Of Bob Doolittle
Sent: Monday, February 02, 2009 5:46 PM
To: SunRay-Users mailing list
Subject: Re: [SunRay-Users] How to make JDS lock screen lock the screen
and not utdetach with NSCM
William Yang wrote:
> 4.1 on S10U6. I don't know if this is possible because of the way AFS
does
> PAGs.
>
And pam_sunray is on the xscreensaver (or dtsession-Sunray if CDE) stack
in /etc/pam.conf?
I'm afraid I don't know anything about AFS and we don't support it :(
-Bob
> William Yang
>
>
>> -----Original Message-----
>> From: [email protected] [mailto:sunray-users-
>> [email protected]] On Behalf Of Bob Doolittle
>> Sent: Monday, February 02, 2009 11:12 AM
>> To: SunRay-Users mailing list
>> Subject: Re: [SunRay-Users] How to make JDS lock screen lock the
>> screen
>> and not utdetach with NSCM
>>
>> William Yang wrote:
>>
>>> Regarding RHA security...
>>>
>>> Does anyone else on the list deploy Sun Rays in a Kerberos 5 and AFS
>>>
>> setup?
>>
>>> We seem to be stuck with forcing users to unlock twice since
>>>
>> unfortunately
>>
>>> we need the screensaver to refresh a user's tickets and tokens.
>>> Since
>>>
>> the
>>
>>> RHA dialog creates a temporary session, the tickets and tokens for
>>> the
>>> user's session aren't refreshed when it is used, so for the time
>>> being
>>>
>> we
>>
>>> use RHA and screensaver lock to achieve better security and still
>>>
>> maintain
>>
>>> the ability to refresh session creds. Any ideas?
>>>
>>>
>> What version of SRSS?
>>
>> What OS platform are you using? If it's Linux, then we may have an
issue
>> here since gnome-screensaver doesn't handle PAM properly so we can't
>> utilize pam_sunray (which refreshes creds on the screensaver stack)
>> and
>> use utxunlock instead. utxunlock has no way of directly refreshing
creds.
>>
>> -Bob
>>
>>
>>> William Yang
>>>
>>>
>>>
>>>> -----Original Message-----
>>>> From: [email protected] [mailto:sunray-users-
>>>> [email protected]] On Behalf Of Joerg Barfurth
>>>> Sent: Monday, February 02, 2009 6:39 AM
>>>> To: SunRay-Users mailing list
>>>> Subject: Re: [SunRay-Users] How to make JDS lock screen lock the
screen
>>>> and not utdetach with NSCM
>>>>
>>>> You can do much of what you desire by editing /etc/pam.conf. But the
>>>> result is an unsupported configuration.
>>>>
>>>> David Markey schrieb:
>>>>
>>>>
>>>>> They could manually detach the session using shift+pause, its just
>>>>> complicated for our users and id like to disable it. i see its hard
>>>>> coded into xscreensaver. Any way to disable it even unsupported?
>>>>>
>>>>>
>>>>>
>>>> You could remove or turn into a comment the
>>>> xscreensaver auth sufficient pam_sunray.so syncondisplay
>>>> line in /etc/pam.conf.
>>>>
>>>> The price you have to pay for that is that when hotdesking to a
>>>> different DTU with your NSCM session or after the session has been
>>>> detached in whatever other way (e.g. by rebooting the DTU), you'll
have
>>>> to enter your password twice - first for NSCM, then for the
>>>>
> screensaver.
>
>>>> You also lower security for your session, as explained by Bob.
>>>>
>>>>
>>>>
>>>>> Also, when i do a utswitch -h <hostname> the previous user name
>>>>> gets
>>>>> entered into the new sunray servers login, any way to disable that
>>>>>
>> also?
>>
>>>>>
>>>> For NSCM users: To get rid of the name you can use the startover
>>>>
> button.
>
>>>> To never get that name in the first place, you could try to remove
the
>>>> utgulogin auth requisite sunray_get_user.so property=username
>>>> line in /etc/pam.conf.
>>>>
>>>> To achieve the same effect for smartcard users, you'd need to also
>>>> remove the
>>>> dtlogin-SunRay auth requisite sunray_get_user.so
property=username
>>>> line. Beware: This might be incompatible with NSCM (though I haven't
>>>> tried). In any case you enter unsupported territory here.
>>>>
>>>> Do not remove the analogous line for utsclogin!
>>>>
>>>> HTH
>>>>
>>>> - Jörg
>>>>
>>>> _______________________________________________
>>>> SunRay-Users mailing list
>>>> [email protected]
>>>> http://www.filibeto.org/mailman/listinfo/sunray-users
>>>>
>>>>
>>> _______________________________________________
>>> SunRay-Users mailing list
>>> [email protected]
>>> http://www.filibeto.org/mailman/listinfo/sunray-users
>>>
>>>
>> _______________________________________________
>> SunRay-Users mailing list
>> [email protected]
>> http://www.filibeto.org/mailman/listinfo/sunray-users
>>
>
> _______________________________________________
> SunRay-Users mailing list
> [email protected]
> http://www.filibeto.org/mailman/listinfo/sunray-users
>
_______________________________________________
SunRay-Users mailing list
[email protected]
http://www.filibeto.org/mailman/listinfo/sunray-users
------------------------------
_______________________________________________
SunRay-Users mailing list
[email protected]
http://www.filibeto.org/mailman/listinfo/sunray-users
End of SunRay-Users Digest, Vol 61, Issue 37
********************************************
