Nicolás: RHEL 6.5 is not even supported on SRS 5.4.2. Maybe that's the problem. I would try the same but with RHEL 6.3.
Here is the platform support list for you version of SRS: http://docs.oracle.com/cd/E35310_01/E35308/html/SRS-5.4-Whats-New.html#Whats-New-Platforms Hope that helps. Lucas 2014-05-28 14:03 GMT-03:00 Nicolás <[email protected]>: > Hi people, > > I'm writing this mail as my last resource because currently I'm in a > deadlock, so I hope someone could shed some light on this problem. I'm > trying to run SRS v. 5.4.0.0.44 together with SROS v. 11.1.3.0.26 on a > RHEL6 64b distribution. I've followed these steps: > > * Removed the ::1 entry from /etc/hosts, and added a line with the actual > host with the corresponding static IP of the server. > * Disabled SELinux and iptables (plus I removed it from the init via > chkconfig iptables off) > * Downloaded the public Oracle repo from http://public-yum.oracle.com/ > public-yum-ol6.repo, disabled all repositories except ol6_u5_base, > ol6_UEK_base and ol6_gdm_multiseat. I also run 'yum update' after the > changes and installed any proposed package. > > Before installing SRS & SROS, I run 'utpkgcheck' and 'utpkgcheck -i', any > package is installed successfully so then I could see: > > [root@srs ~]# /opt/SUNWut/sbin/utpkgcheck > Checking required dependent packages > All dependent packages are installed > > At this point I installed both the SROS and SRS packages, this latter via > the 'utsetup' command. Everything goes smoothly, no errors. I also > configured the kiosk mode as this is my aim. As proposed, I rebooted. > > Once restarted, I run these 3 commands: > > /opt/SUNWut/sbin/utadm -L on > /opt/SUNWut/sbin/utstart > /etc/init.d/utsyscfg start > > No errors shown in the '/var/opt/SUNWut/log/messages' file. Well, and now > comes the problem: I turn on the Sun-Ray client, it downloads the latest > firmware from the server, and gets stuck at the '26D' screen. No matter > what I do, really, I can't get through that step. I connected to the Web > Administration and chose the kiosk mode, also tried with mobile sessions. > In this latter case, I'm asked for the user and password, once entered, the > same happens. > > I'm aware this is related to the fact it can't init a graphic session, but > there's no error in the log, so I can't find out what else to do to know > what's going wrong. All I can see in the log is this: > > May 28 14:37:00 srs xinetd[1789]: START: tftp pid=2905 from=10.107.19.56 > May 28 14:37:02 srs utauthd: Worker7 NOTICE: whichServer > pseudo.00144f574400: > May 28 14:37:02 srs utauthd: Worker7 NOTICE: CLAIMED by StartSession.m5 > NAME: pseudo.00144f574400 PARAMETERS: {stealProtected=true, > terminalIPA=10.107.19.56, type=pseudo, fw=11.1.3.0_26_2013.10.28.09. > 53,Boot:MfgPkg_4.15_2006.07.20.16.57; 2006.07.20-17:04:56-PDT, > state=disconnected, cause=insert, doamgh=true, barrierLevel=451, > lockaction=disconnect, rawId=00144f574400, terminalCID=IEEE802.00144f574400, > MTU=1500, tokenSeq=1, firstServer=0a6b130f, namespace=IEEE802, > keyTypes=dsa-sha1-x1,dsa-sha1, ddcconfig=1, clientRand=2hIW/ > 4MZB5u9pK8eb09E5Atg5zRPbLE1BVS4hOPinwm, id=00144f574400, realIP=0a6b1338, > startRes=1280x1024:1280x1024, useReal=true, event=insert, sn=00144f574400, > rawType=pseudo, hw=SunRayP8, initState=1, usersession=false, _=1} > May 28 14:37:02 srs utauthd: Worker7 NOTICE: CONNECT IEEE802.00144f574400, > pseudo.00144f574400, all connections allowed > May 28 14:37:02 srs utauthd: Worker7 NOTICE: MTU = 1500 > May 28 14:37:02 srs utauthd: Worker7 NOTICE: SessionManager.getSessionManager: > Initiate callback to utsessiond at localhost:7007 > May 28 14:37:02 srs utauthd: Worker7 NOTICE: SessionManager.initiateCallback > localhost:7010 established communication > May 28 14:37:02 srs utdtsession: Add (11,pseudo.00144f574400,normal) > > And that's all. The DNS records are configured properly, as can be seen in > the 'utquery' output (being 10.107.19.15 the SRS server's IP address): > > [root@srs ~]# /opt/SUNWut/sbin/utquery -d 10.107.19.56 > terminalID=00144f574400 > terminalIPA=10.107.19.56 > model=SunRayP8 > currentAuth=10.107.19.15 > currentFW=11.1.3.0_26_2013.10.28.09.53 > currentBarrier=451 > currentBarrierLevel=451 > currentMTU=1500 > currentLease=17755 > Subnet=255.255.255.0 > Router=10.107.19.1 > LeaseTim=18000 > DHCPServer=10.1.3.194 > AuthSrvr=10.107.19.15 > FwSrvr=10.107.19.15 > tftpSrvr=10.107.19.15 > FWservType=FWSrvr > speed=100F > parmsVersion=11.1.3.0_26_2013.10.28.09.53 > parmsBarrier=451 > configMTU=1500 > AltAuth=10.107.19.15 > dnsList=10.1.3.130,10.1.5.130,10.1.4.130 > dname=dns.myplace.es > confEnabled=0 > stopqon=0 > bandwidth=7500000 > cmdcachesize=0 > > I doubt this is a network related problem, as both the server and the > client are under the same VLAN. it just seems to not start the X session, > but I can't diagnoze why. I also tried the 'utcapture' utility and no > packets are being lost or dropped. > > I neither think this is caused by the java version, as I'm using the > package's 1.6 jre version: > > [root@srs ~]# /opt/jre1.6.0_41/bin/java -version > java version "1.6.0_41" > Java(TM) SE Runtime Environment (build 1.6.0_41-b02) > Java HotSpot(TM) Server VM (build 20.14-b01, mixed mode) > > There's no 'gdm' process when the clients try to establish the session, > nor 'Xnewt'. > > I'd be really grateful if someone could provide some additional tests or > ideas on how to debug this, as I've been really stucked with this for 5 > days and don't know what else to try. If I missed any information just ask > for it. > > Thanks so much in advance. > > Nicolas > _______________________________________________ > 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
