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 <nico...@devels.es
<mailto:nico...@devels.es>>:
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 <http://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
SunRay-Users@filibeto.org <mailto:SunRay-Users@filibeto.org>
http://www.filibeto.org/mailman/listinfo/sunray-users
_______________________________________________
SunRay-Users mailing list
SunRay-Users@filibeto.org
http://www.filibeto.org/mailman/listinfo/sunray-users
_______________________________________________
SunRay-Users mailing list
SunRay-Users@filibeto.org
http://www.filibeto.org/mailman/listinfo/sunray-users
