Bug 630755

Summary:

Web-based cluster administration luci don't start

Product:

[Fedora] Fedora

Reporter:

Michael Hagmann <michael.hagmann>

Component:

luci

Assignee:

Ryan McCabe <rmccabe>

Status:

CLOSED WONTFIX

QA Contact:

Fedora Extras Quality Assurance <extras-qa>

Severity:

medium

Docs Contact:

Priority:

low

Version:

CC:

cfeist, fdinitto, rmccabe

Target Milestone:

---

Target Release:

---

Hardware:

x86_64

OS:

Linux

Whiteboard:

Fixed In Version:

Doc Type:

Bug Fix

Doc Text:

Story Points:

---

Clone Of:

Environment:

Last Closed:

2011-06-28 13:19:34 UTC

Type:

---

Regression:

---

Mount Type:

---

Documentation:

---

CRM:

Verified Versions:

Category:

---

oVirt Team:

---

RHEL 7.3 requirements from Atomic Host:

Cloudforms Team:

---

Target Upstream Version:

Embargoed:

Bug Depends On:

631016

Bug Blocks:

Attachments:

Description	Flags
new clean guest	none

Description Michael Hagmann 2010-09-06 19:19:32 UTC

Description of problem:

I just want build a simple Cluster with Fedora.

Version-Release number of selected component (if applicable):


How reproducible:

try to start luci

Steps to Reproduce:
1.
2.
3.
  

[root@scheat sysconfig]# service luci status
No PID file /var/lib/luci/data/luci.pid
[root@scheat sysconfig]# service luci start
Point your web browser to https://scheat:8084 to access luci
[root@scheat sysconfig]# 
                                  
Actual results:

Traceback (most recent call last):
  File "/usr/bin/paster", line 8, in <module>
    load_entry_point('PasteScript==1.7.3', 'console_scripts', 'paster')()
  File "/usr/lib/python2.6/site-packages/paste/script/command.py", line 84, in run
    invoke(command, command_name, options, args[1:])
  File "/usr/lib/python2.6/site-packages/paste/script/command.py", line 123, in invoke
    exit_code = runner.run(args)
  File "/usr/lib/python2.6/site-packages/paste/script/command.py", line 218, in run
    result = self.command()
  File "/usr/lib/python2.6/site-packages/paste/script/serve.py", line 276, in command
    relative_to=base, global_conf=vars)
  File "/usr/lib/python2.6/site-packages/paste/script/serve.py", line 313, in loadapp
    **kw)
  File "/usr/lib/python2.6/site-packages/paste/deploy/loadwsgi.py", line 204, in loadapp
    return loadobj(APP, uri, name=name, **kw)
  File "/usr/lib/python2.6/site-packages/paste/deploy/loadwsgi.py", line 225, in loadobj
    return context.create()
  File "/usr/lib/python2.6/site-packages/paste/deploy/loadwsgi.py", line 625, in create
    return self.object_type.invoke(self)
  File "/usr/lib/python2.6/site-packages/paste/deploy/loadwsgi.py", line 110, in invoke
    return fix_call(context.object, context.global_conf, **context.local_conf)
  File "/usr/lib/python2.6/site-packages/paste/deploy/util/fixtypeerror.py", line 57, in fix_call
    val = callable(*args, **kw)
  File "/usr/lib/python2.6/site-packages/luci/config/middleware.py", line 44, in make_app
    app_conf.get('who.log_level','debug')
  File "/usr/lib/python2.6/site-packages/repoze/who/config.py", line 138, in make_middleware_with_config
    parser.parse(open(config_file))
IOError: [Errno 2] No such file or directory: 'who.ini'
Removing PID file /var/lib/luci/data/luci.pid


Expected results:

start the luci Webserver

Additional info:

Comment 1 Michael Hagmann 2010-09-06 19:21:33 UTC

FYI

SElinux is in permissiv mode

[root@scheat sysconfig]# sestatus 
SELinux status:                 enabled
SELinuxfs mount:                /selinux
Current mode:                   permissive
Mode from config file:          permissive
Policy version:                 24
Policy from config file:        targeted
[root@scheat sysconfig]# 

system is up to date

[root@scheat sysconfig]# date
Mon Sep  6 21:20:49 CEST 2010
[root@scheat sysconfig]# yum update
updates/metalink                                                                                                                                  |  26 kB     00:00     
Setting up Update Process
No Packages marked for Update
[root@scheat sysconfig]# 

thanks for your Help Michael

Comment 2 Michael Hagmann 2010-09-06 20:34:21 UTC

just try it on a fresh system Fedora13 luci starts here but I can't connect.

Also try to add the ip to the luci.ini file.

Unable to connect


Firefox can't establish a connection to the server at 192.168.1.6:8084.

    *   The site could be temporarily unavailable or too busy. Try again in a few
          moments.Unable to connect

root@leo ~]# tail -f /var/log/luci/luci.log
  File "/usr/lib/python2.6/site-packages/paste/deploy/loadwsgi.py", line 151, in server_wrapper
    **context.local_conf)
  File "/usr/lib/python2.6/site-packages/paste/deploy/util/fixtypeerror.py", line 57, in fix_call
    val = callable(*args, **kw)
  File "/usr/lib/python2.6/site-packages/paste/httpserver.py", line 1342, in server_runner
    serve(wsgi_app, **kwargs)
  File "/usr/lib/python2.6/site-packages/paste/httpserver.py", line 1255, in serve
    assert SSL, "pyOpenSSL is not installed"
AssertionError: pyOpenSSL is not installed
Removing PID file /var/lib/luci/data/luci.pid




Starting server in PID 1405.
serving on 0.0.0.0:8084 view at https://127.0.0.1:8084

Starting server in PID 1591.
serving on 0.0.0.0:8084 view at https://127.0.0.1:8084

Starting server in PID 1634.
serving on https://192.168.1.6:8084



yum install ricci luci

have to add also yum install pyOpenSSL

but no success at the end.

thanks Michael

Comment 3 Michael Hagmann 2010-09-06 20:36:51 UTC

Created attachment 443362 [details]
new clean guest

Comment 4 Michael Hagmann 2010-09-07 18:29:13 UTC

on the second node Leo i forgot to adjust the Firewall

[root@leo ~]# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere            state RELATED,ESTABLISHED 
ACCEPT     icmp --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     tcp  --  anywhere             anywhere            state NEW tcp dpt:ssh 
REJECT     all  --  anywhere             anywhere            reject-with icmp-host-prohibited 

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         
REJECT     all  --  anywhere             anywhere            reject-with icmp-host-prohibited 

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
[root@leo ~]#

now it works

anyway no Idea why it don't work on the first node Scheat

Michael

Comment 5 Michael Hagmann 2010-09-07 19:59:37 UTC

Cluster works fine, I was able to configure the Cluster with one failover IP

[root@scheat conf]# clustat
Cluster Status for gecco @ Tue Sep  7 21:56:32 2010
Member Status: Quorate

 Member Name                                                     ID   Status
 ------ ----                                                     ---- ------
 scheat                                                              1 Online, Local, rgmanager
 leo                                                                 2 Online, rgmanager

 Service Name                                                     Owner (Last)                                                     State
 ------- ----                                                     ----- ------                                                     -----
 service:Webserver                                                scheat                                                           started
[root@scheat conf]# clus
clustat    clusvcadm
[root@scheat conf]# clusvcadm -r Webserver
Trying to relocate service:Webserver...Success
service:Webserver is now running on leo
[root@scheat conf]# clustat
Cluster Status for gecco @ Tue Sep  7 21:57:24 2010
Member Status: Quorate

 Member Name                                                     ID   Status
 ------ ----                                                     ---- ------
 scheat                                                              1 Online, Local, rgmanager
 leo                                                                 2 Online, rgmanager

 Service Name                                                     Owner (Last)                                                     State         
 ------- ----                                                     ----- ------                                                     -----         
 service:Webserver                                                leo                                                              started       
[root@scheat conf]#

Comment 6 Bug Zapper 2011-05-31 14:18:55 UTC

This message is a reminder that Fedora 13 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 13.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '13'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 13's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 13 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 7 Bug Zapper 2011-06-28 13:19:34 UTC

Fedora 13 changed to end-of-life (EOL) status on 2011-06-25. Fedora 13 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.