On 05/04/2012 02:35 PM, Daniel Molina wrote:
Hi Robert,
On 4 May 2012 20:11, Robert Schweikert <[email protected]
<mailto:[email protected]>> wrote:
On 05/04/2012 01:58 PM, Robert Schweikert wrote:
Hi,
Trying to run sunstone I get the following error ins the log file:
------------------------------__--------
Server configuration
------------------------------__--------
{:vnc_proxy_cert=>nil,
:auth=>"sunstone",
:vnc_proxy_path=>nil,
:vnc_proxy_key=>nil,
:vnc_proxy_support_wss=>false,
:debug_level=>3,
:one_xmlrpc=>"http://__localhost:2633/RPC2
<http://localhost:2633/RPC2>",
:host=>"127.0.0.1",
:vnc_proxy_base_port=>29876,
:core_auth=>"cipher",
:port=>9869,
:lang=>"en_US"}
Fri May 04 13:06:04 2012 [E]: Error initializing authentication
system
Fri May 04 13:06:04 2012 [E]: [UserPoolInfo] User couldn't be
authenticated, aborting call.
Any idea whats going on?
The server is suppossde to be launched via systemd, using the
following
service file:
[Unit]
Description=OpenNebula Web UI Server
After=syslog.target
After=network.target
After=one.service
After=one_scheduler.service
BindTo=one.service
!ConditionFileExists=/var/__lock/one/.sunstone.lock
[Service]
ExecStart=/bin/bash -c "/usr/bin/ruby
/usr/lib/one/sunstone/__sunstone-server.rb >
/var/log/one/sunstone.log 2>&1"
ExecStop=/bin/kill -INT $MAINPID
PIDFile=/var/run/one/sunstone.__pid
Type=simple
Group=cloud
User=oneadmin
[Install]
WantedBy=multi-user.target
This worked in 3.2.1 but is now broken with 3.4.1. I am testing
and am
trying to get the 3.4.1 packages out of the :Testing project and
into
the main (Virtualization:Cloud:__OpenNebula) project in OBS.
Help is appreciated.
Follow up question. Does sunstone now need the ONE_AUTH variable set?
Sunstone does not require ONE_AUTH variable set.
When Sunstone starts it will use the credentials specified in the
"/var/lib/one/.one/sunstone_auth" file. This file contains the
serveradmin credentials ("serveradmin:password" where password is the
plain version of the serveradmin pass) This file is generated in the
first OpenNebula deployment, if Sunstone is running in a different
machine this file has to be manually created.
Well sunstone is running on the same machine, and
/var/lib/one/.one/sunstone_auth exists.
Could it be that there is some kind of race condition?
When I manually start the sunstone service (systemctl start
sunstone.service) it starts. But when this is suppossed to happen
automatically it appears to fail consistently.
I take it sunstone does communicate with oned somehow? If this is the
case I suspect sunstone finds the port it is looking for to be
unresponsive and just exits. It would be great to have a timeout and
retry feature. If sunstone cannot connect to oned, wait 5 seconds then
try again. Maybe 5 times for a total of 25 second delay before potential
failure.
Thoughts?
Thanks,
Robert
--
Robert Schweikert MAY THE SOURCE BE WITH YOU
SUSE-IBM Software Integration Center LINUX
Tech Lead
[email protected]
[email protected]
781-464-8147
_______________________________________________
Users mailing list
[email protected]
http://lists.opennebula.org/listinfo.cgi/users-opennebula.org
