SRS5 / SRSS 4.2 FOG on SLES 10: utdevmgr does not update /tmp/SUNWut/units

Question

We are running SRSS 4.2 with Patch 140995-01 on SLES 10 SP3 32-bit with 3 hosts in a FOG and 49 SunRay2-P8-DTUs, FW 4.2_140993-01_2010.01.21.17.35 on a dedicated interconnect.
We do not use kiosk-functionality, all sessions (smartcard and non-smartcard) are default UNIX sessions on the SunRay-server.
Since our recent upgrade to SRSS 4.2 we observe the following problem:
when a DTU moves to a new server (by load-balance policy or after a user logout) the corresponding device-directory IEEE802.<mac-address> is not moved by the utdevmgr to the /tmp/SUNWut/units-directory of the new host, but stays on the host which first got in contact with this specific DTU.
So every single DTU has a correct device directory on one of the servers in the FOG, but unfortunately not necessarily on the particular one the DTU-session is currently connected to.
This leads to at least the following bad behaviour:
- $UTDEVROOT is invalid due to missing link target.
- DTU-Hardware, especially USB-Thumbdrives cannot be used.
- utdiskadm -l gives: utdiskadm: Cannot locate device root directory
When explicitly using utswitch/utselect, the device directory DOES get moved to the target host and everything works fine, but logging out from this switched session does not move the directory back to the original host.
When we stop Core Services on a host via /etc/init.d/utsvc stop, all DTU-device-dirs are immediately redistributed and new greeter sessions are started on the other two FOG-hosts.
Since SRSS 4.2 we also notice a different load-balance behaviour:
load-balance redirection now sometimes occurs at user-login-time, eventually disconnecting a running idle-session on a DTU and choosing a new lower loaded host; the disconnected idle-sessions get discarded after a timeout (~15 minutes) if not reused.
This is presumably intended behaviour to make the balancer more accurate, but may be related to our problem.
The issue may be similar to what is observed here:
http://www.mail-archive.com/[email protected]/msg15431.html
but we made sure that it is not a permission problem on /tmp, neither on /tmp/SUNWut (we removed /tmp/SUNWut on all hosts and restarted the farm,
thus creating the tree by scratch).
We don't have any sort of firewall or packetfilter running between the hosts, utgstatus permanently reports TN/UAM for all servers on the interconnect.
We also tried running the utdevmgrd with the -d(ebug) option but were unable to spot any errors in the output due to missing in-depth knowledge.
It's also notable that this problem did not exist when using SRSS 4.1.
One very strange side-observation (which may cause the problem):
as mentioned above, we have a dedicated interconnect setup with registered IPs for Sunray-traffic, so each of our FOG-hosts has two NICs called eth0 and eth3, eth0 for normal lan traffic (with shared lan interconnect turned off) and eth3 for Sunray-Traffic.
Let's assume the following addresses:
primary server:
eth0: x.y.z.151
eth3: a.b.c.1
secondary server 1:
eth0: x.y.z.152
eth3: a.b.c.2
secondary server 2:
eth0: x.y.z.153
eth3: a.b.c.3
tcpdump on the primary server now shows various connection attempts of the local utdevmgrd to 2.c.b.a:7011 and 3.c.b.a:7011, the secondary server 1 tries to reach 1.c.b.a:7011 and 3.c.b.a:7011, finally secondary server 2 pumps out connection attempts to 1.c.b.a:7011 and 2.c.b.a:7011.
So every machine tries to connect to the utdevmgr of the other two peers but uses a target IP with REVERSED byte order.
Of course this traffic leaves on the wrong interface via default route and bothers helpless machines somewhere in the world, but never reaches the intended target (in fact, it doesn't do so any longer, we blocked it on our GW).
Fixing this bug is beyond our capability (little-big-endian-problem during SPARC-to-linux-port?), so I'd like to file a bug report, but http://bugreport.sun.com seems to only be related to JAVA-stuff and tells me to "review ... paid support options below".
How do I properly submit this problem to someone able to help?
Any hints or ideas are strongly appreciated,
thanks in advance,
Nico

Answer 1

yes...exactly same here...already posted about it..
our reseller already told sun about 6 months ago..and then...silence
we use the utdevmgrd from srss4.1...so far (6 months now) no problems
Tjeerd