If you have now have "stand-alone" servers, what multicast group do you
expect them to join?
Joseph Chiong wrote:
My worry is still with the following error messages in auth_log:
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
Thanks.
Craig Bender wrote:
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
[email protected] <mailto:[email protected]>
http://www.filibeto.org/mailman/listinfo/sunray-users
_______________________________________________
SunRay-Users mailing list
[email protected] <mailto:[email protected]>
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: [email protected] <mailto:[email protected]>
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
[email protected] <mailto:[email protected]>
http://www.filibeto.org/mailman/listinfo/sunray-users
_______________________________________________
SunRay-Users mailing list
[email protected] <mailto:[email protected]>
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: [email protected] <mailto:[email protected]>
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
[email protected] <mailto:[email protected]>
http://www.filibeto.org/mailman/listinfo/sunray-users
_______________________________________________
SunRay-Users mailing list
[email protected] <mailto:[email protected]>
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: [email protected] <mailto:[email protected]>
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
[email protected]
http://www.filibeto.org/mailman/listinfo/sunray-users
_______________________________________________
SunRay-Users mailing list
[email protected]
http://www.filibeto.org/mailman/listinfo/sunray-users
