Nicolás: Did you select the 'Desktop' group of packages during Linux installation? I think that's one of the most important requirements.
Lucas El 29/05/2014 17:48, "Nicolás" <[email protected]> escribió: > Hi Christian and thanks for replying, > > Let's see: > > 1) I can ping the client from the server side, also as I said it's under > the same VLAN and any firewall (iptables) is disabled, so I'd discard a > network problem. > 2) Running the 'utwho' command produces this result: > > [root@srs ~]# /opt/SUNWut/bin/utwho -ca > 11.0 pseudo.00144f574400 root 192.168.1.203 > P8.00144f574400 > > In the /var/opt/SUNWut/displays directory there's just one file (seems > logic, as I'm just testing with one client): > > [root@srs ~]# cat /var/opt/SUNWut/displays/11 > SESSION=srs.mysite.es:7007:5362229792637346934 > TOKEN=pseudo.00144f574400 > SESSION_TYPE=default > TOKEN_SET=pseudo.00144f574400 > CALLBACK_COOKIE=5843968652673758964 > DISPLAY=11 > INSERT_TOKEN=pseudo.00144f574400 > > There's no 'Xnewt' process running at any time. I know this has to be > launched from a client session, so I cannot test it from the server side. > However, regarding to this, I've noticed something weird. In the > '/tmp/SUNWut/config/xconfig/Xservers' file I see this line: > > :11 SunRay local /usr/X11R6/bin/Xnewt :11 > > However, this path doesn't exist on my machine. The Xnewt file is located > at /opt/SUNWut/lib/Xnewt. I tried to add a symbolic link to this path but > it doesn't seem to help. Could this be related? > > 3) There's no log file under /var/log/gdm, it's an empty directory. > > 4) No way there's no space at /tmp or some kind of cron that would erase > files there. I've more than 10GB of free space on that partition and it's a > 'clean' distro, so no crons of that kind are being run. > > 5) Regarding to your other mail: The server is a HP ProLiant DL360. > However, I'm now trying to do the same running the server on a VMWare > virtual machine and the same happens. And no, there's no monitor connected > to the server side (we use iLO to manage it). > > Thanks for any help, this is starting to be quite frustrating... > > Regards, > > Nicolás > > El 29/05/2014 20:55, Christian Montero Hernández escribió: > > Did you check the options on this link? > http://www.filibeto.org/pipermail/sunray-users/2011-January/017008.html > > Regards, > > > Christian Montero H. > > > > On Thursday, May 29, 2014 6:42 AM, Nicolás <[email protected]> > <[email protected]> wrote: > > > > Unfortunately, even installing the OL 6.3 version, I get exactly the > same result. I was wondering this could be a hardware problem, but I also > tried another Sun Ray 2 and it produces the same behavior. So I'm really > befuddled now. > > I tried following the guide to debug a kiosk session, but no additional > logging is being generated so I assume the kiosk session isn't even being > started. > > Any other idea? Something I could be missing? > > Thanks. > > El 28/05/2014 19:40, Nicolás escribió: > > Thanks for the answer, Lucas. > > I'll make a try tomorrow with RHEL 6.3 and I'll provide some feedback > afterwards. > > Regards, > > Nicolás > > El 28/05/2014 19:12, Lucas Migueles escribió: > > 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 > [email protected]http://www.filibeto.org/mailman/listinfo/sunray-users > > > > > _______________________________________________ > SunRay-Users mailing > [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 > [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
