[SunRay-Users] SRSS 4.1 SPARC Abnormal Behavior

Sat May 2 07:33:20 EEST 2009

How is that you are running/patching SRWC 2.0 with SRSS 4.1?  SRSS 4.1 
requires SRWC 2.1

There's also a whole other matrix of patches that have a relationship to 
SRSS such as dtlogin, kernel patches, network stack patches, etc.

This system does not appear to have been set up in a supported manner. 
For 50 users, I'd start from scratch in a known good supported setup. 
The admin guide fully explains what is supported.  A common subnet 
shared between each server, 32 bit Java, Full Install of Solaris, etc.

What is the output of crontab -l?

There's nothing in Solaris that is going to delete /tmp/SUNWut.  That 
sounds like a custom script or perhaps the wrong permission on /tmp. 
Any chance that someone has tried to harden this box?

Joseph Chiong wrote:
> Hi,
> 
> I do not have the explorer file with me. I can attach it once I get it 
> from the customer. If you can bear with me for the discussion, we have 
> installed Solaris u6 10/08 SPARC on the servers.
> 
> By latest patches, I mean:
> 
> SRSS 4.1    Solaris SPARC     139548-01    Sun Ray Core Services Patch
> uttsc 2.0    Solaris SPARC     127556-03    2.0 Patch Update
> 
> +
> 
> Solaris Recommended Patches from Sun EIS DVD Feb 2009 (which was the 
> latest when we started to deploy the servers). There is no cron job 
> created to clean /tmp unless there is one in Solaris u6 which we are not 
> aware of.
> 
> 
> 
> Thanks.
> 
> Craig Bender wrote:
>> "All the latest patches" tell me nothing.
>>
>> Exact Solaris release.  uname -a and 'cat /etc/release'
>>
>> All the latest patches?  For what?
>>
>> To me, it sounds like you have a cron job cleaning up /tmp which would 
>> explain   That's the most reasonable explanation why 
>> /tmp/SUNWut/units/dev is going a way.
>>
>>
>>
>> Joseph Chiong wrote:
>>> Hi,
>>>
>>>  > Perhaps telling us a little bit about your environment would help. 
>>> How many NIC's do you have active, what's your topology?
>>> OK. We have two Sun Fire T1000 running SRSS 4.1 with all latest 
>>> patches. Initially, the servers are running in FOG. After having 
>>> difficulties with the stability, we break the FOG and run in 
>>> standalone mode. We have three NICs as follow:
>>>
>>> bge0: Sun Ray public network 192.x.x.0/24
>>> bge1: (originally configured for IPMP but currently unplumbed and 
>>> disconnected physically)
>>> bge2: Sun Ray shared interconnect 10.x.10.0/24
>>> bge3: Sun Ray shared interconnect 10.x.20.0/24
>>>
>>>  >Are your switches blocking multicast?
>>> The switches are a Cisco 2960s. AFAIK, there is no configuration that 
>>> blocks multicast. There are two VLANs, one for shared interconnect 
>>> and one for public network. There is no routing between the VLANs.
>>>
>>>  >IPMP not being a supported configuration has nothing to do with UDP.
>>> We want to rule out the possibility that having IPMP configured and 
>>> unconfigured initially and running for a few days would cause the 
>>> stability issues. Do we need to cleanly install the SRSS servers again?
>>>
>>>  > /dev just doesn't disappear.
>>> Well, this is what we observe. Whenever there are errors in auth_log 
>>> as follow:
>>>
>>> 05/01/2009 21:53:15 unable to join multicast group on bge0
>>> 05/01/2009 21:53:15 unable to join multicast group on bge2
>>> 05/01/2009 21:53:15 unable to join multicast group on bge3
>>>
>>> The /tmp/SUNWut/units/dev completely vanishes even though the DTU or 
>>> the devices connected to it such as a printer is turned on. We 
>>> believe this is due to communication problems between DTU and Sun Ray 
>>> servers. We are clueless what may cause this.
>>>
>>>  >What does authd being written in Java have to do with anything?
>>> We see quite often authd crashes and dumps out Java error. All 
>>> problems so far seem to point to authd.
>>>
>>>  >Have you opened a support call with Sun?  This forum is not a 
>>> substitute for a support contract. If I were you, I'd open a call up 
>>> with Sun support.
>>> We understand that this forum is not a substitute for a support 
>>> contract. However, our management does not think alike. We have a 
>>> management that has a third world mentality and first world 
>>> requirements. Therefore, we have no choice but to try to get answer 
>>> out of any publicly available resource. Thanks for your understanding 
>>> and support.
>>>
>>>
>>>
>>> Thanks.
>>>
>>> Craig Bender wrote:
>>>> Perhaps telling us a little bit about your environment would help.  
>>>> Have you opened a support call with Sun?  What does authd being 
>>>> written in Java have to do with anything?  How many NIC's do you 
>>>> have active, what's your topology?  Are your switches blocking 
>>>> multicast?  IPMP not being a supported configuration has nothing to 
>>>> do with UDP.
>>>>
>>>> If I were you, I'd open a call up with Sun support.  /dev just 
>>>> doesn't disappear.  This forum is not a substitute for a support 
>>>> contract.
>>>>
>>>>
>>>>
>>>> Joseph Chiong wrote:
>>>>>   Hi all,
>>>>>
>>>>> We setup two Sun Ray servers for a customer with about 50 users. 
>>>>> There has been lots of problem since it went live. I posted many 
>>>>> questions on this forum and got critical replies that had helped us 
>>>>> to move ahead. I will need help more than anytime.
>>>>>
>>>>> Initially, our inexperience engineer setup the servers with IPMP on 
>>>>> Sun Ray public network. After knowing IPMP is not compatible with 
>>>>> Sun Ray probably due to the use of UDP multicast on multiple NICs 
>>>>> in the Sun Ray interconnect, we unconfigured Sun Ray and removed 
>>>>> the IPMP configuration. We reconfigured back the Sun Ray after 
>>>>> that. Things went smoothly for about a week and the servers (then 
>>>>> in FOG) started to run unstably. We suspected it was due to FOG 
>>>>> after reading bug CR 6788938. We decided to switch to standalone 
>>>>> server and wait for the patch to try again.
>>>>>
>>>>> The standalone server went smoothly for about a week and problem 
>>>>> started to surface. There is once again intermittent stability 
>>>>> problem primarily on utauthd. I do not have the utauth log for 
>>>>> every crash but it seems to point to the following error:
>>>>>
>>>>> 05/01/2009 21:53:15 unable to join multicast group on bge0
>>>>> 05/01/2009 21:53:15 unable to join multicast group on bge2
>>>>> 05/01/2009 21:53:15 unable to join multicast group on bge3
>>>>>
>>>>> Once that happens the device path (/dev) directory vanishes and 
>>>>> everything that relies on the path stop functioning. Can anyone 
>>>>> help to save my confidence in Sun Ray? I do not understand why the 
>>>>> critical piece of component utauthd is written in Java as well.
>>>>>
>>>>>
>>>>>
>>>>> Thanks.
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------ 
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> SunRay-Users mailing list
>>>>> SunRay-Users at filibeto.org
>>>>> http://www.filibeto.org/mailman/listinfo/sunray-users
>>>> _______________________________________________
>>>> SunRay-Users mailing list
>>>> SunRay-Users at filibeto.org
>>>> http://www.filibeto.org/mailman/listinfo/sunray-users
>>>>
>>>> __________ Information from ESET NOD32 Antivirus, version of virus 
>>>> signature database 4049 (20090501) __________
>>>>
>>>> The message was checked by ESET NOD32 Antivirus.
>>>>
>>>> http://www.eset.com
>>>>
>>>>
>>>>
>>>>
>>>
>>> -- 
>>> Joseph Chiong
>>> eSuria Mentari Systems Sdn Bhd
>>> Unit 9, 1st Floor, Block A
>>> Kiarong Complex
>>> Bandar Seri Begawan BE1318
>>> Brunei Darussalam
>>> Ph: 673-2423721
>>> Mobile: 673-8145285
>>> Email: joseph at esuria.com.bn
>>> Web: http://www.esuria.com.bn
>>>
>>> This email and any files transmitted with it are confidential and 
>>> intended solely for the use of individual or entity to whom they are 
>>> addressed. If you are not the named addressee you should not 
>>> disseminate, distribute or copy this e-mail. Please notify the sender 
>>> immediately by e-mail if you have received this email by mistake and 
>>> delete this e-mail from your system.
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> SunRay-Users mailing list
>>> SunRay-Users at filibeto.org
>>> http://www.filibeto.org/mailman/listinfo/sunray-users
>> _______________________________________________
>> SunRay-Users mailing list
>> SunRay-Users at filibeto.org
>> http://www.filibeto.org/mailman/listinfo/sunray-users
>>
>> __________ Information from ESET NOD32 Antivirus, version of virus 
>> signature database 4049 (20090501) __________
>>
>> The message was checked by ESET NOD32 Antivirus.
>>
>> http://www.eset.com
>>
>>
>>
>>
> 
> -- 
> Joseph Chiong
> eSuria Mentari Systems Sdn Bhd
> Unit 9, 1st Floor, Block A
> Kiarong Complex
> Bandar Seri Begawan BE1318
> Brunei Darussalam
> Ph: 673-2423721
> Mobile: 673-8145285
> Email: joseph at esuria.com.bn
> Web: http://www.esuria.com.bn
> 
> This email and any files transmitted with it are confidential and intended solely for the use of individual or entity to whom they are addressed. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this email by mistake and delete this e-mail from your system.
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> SunRay-Users mailing list
> SunRay-Users at filibeto.org
> http://www.filibeto.org/mailman/listinfo/sunray-users