RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 750474 - luci didn't start
Summary: luci didn't start
Keywords:
Status: CLOSED DUPLICATE of bug 741324
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: luci
Version: 6.1
Hardware: x86_64
OS: Unspecified
unspecified
high
Target Milestone: rc
: ---
Assignee: Jan Pokorný [poki]
QA Contact: Cluster QE
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-11-01 09:15 UTC by Timm Stamer
Modified: 2018-11-29 19:59 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-11-02 21:07:03 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 741324 0 unspecified CLOSED python-repoze-who-friendlyform from epel overwrites RHEL version 2021-02-22 00:41:40 UTC
Red Hat Bugzilla 750931 0 unspecified CLOSED Inconsistency between EPEL's RPM and Python's packaging system metadata -- requires 2021-02-22 00:41:40 UTC

Internal Links: 741324 750931

Description Timm Stamer 2011-11-01 09:15:40 UTC
Description of problem:

I've just installed luci on RHEL6 as discribed in RHEL6 Cluster Administration Guide at chapter 3.2.

When I start luci by "service luci start" I got an error:

Unable to create the luci base configuration file (`/var/lib/luci/etc/luci.ini').
Start luci...                                              [FAILED]

SELinux: disabled

After touching luci.ini and chown to luci:luci, service luci start produces next error:

Unable to create the luci database file (`/var/lib/luci/data/luci.db').
Start luci...                                              [FAILED]

After touching /var/lib/luci/data/luci.db and chown luci:luci /var/lib/luci/data/luci.db luci starts.


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

luci-0.23.0-13.el6


How reproducible:


Steps to Reproduce:
1. yum install luci
2. service luci start
  
Actual results:

Workaround:
touch /var/lib/luci/etc/luci.ini
touch /var/lib/luci/data/luci.db
chown luci:luci /var/lib/luci/etc/luci.ini
chown luci:luci /var/lib/luci/data/luci.db

service luci start

Expected results:

no workaround needed after installing luci.

Comment 1 Timm Stamer 2011-11-01 09:19:20 UTC
Sorry, workaround only fixes service luci start, but luci isn't running after it.


cat /var/log/luci/luci.log:

Traceback (most recent call last):
  File "/usr/bin/paster", line 9, 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 274, in command
    relative_to=base, global_conf=vars)
  File "/usr/lib/python2.6/site-packages/paste/script/serve.py", line 308, in loadserver
    relative_to=relative_to, **kw)
  File "/usr/lib/python2.6/site-packages/paste/deploy/loadwsgi.py", line 210, in loadserver
    return loadobj(SERVER, uri, name=name, **kw)
  File "/usr/lib/python2.6/site-packages/paste/deploy/loadwsgi.py", line 224, in loadobj
    global_conf=global_conf)
  File "/usr/lib/python2.6/site-packages/paste/deploy/loadwsgi.py", line 248, in loadcontext
    global_conf=global_conf)
  File "/usr/lib/python2.6/site-packages/paste/deploy/loadwsgi.py", line 278, in _loadconfig
    return loader.get_context(object_type, name, global_conf)
  File "/usr/lib/python2.6/site-packages/paste/deploy/loadwsgi.py", line 363, in get_context
    object_type, name=name)
  File "/usr/lib/python2.6/site-packages/paste/deploy/loadwsgi.py", line 528, in find_config_section
    self.filename))
LookupError: No section 'init' (prefixed by 'server') found in config /var/lib/luci/etc/luci.ini
Removing PID file /var/run/luci/luci.pid

Comment 2 Timm Stamer 2011-11-01 09:28:27 UTC
luci-0.22.2-14.el6_0.1 works fine. (yum downgrade luci)

Updating luci to 0.23.0-13.el6 again moves the running config to luci.ini.rpmsave and doesn't create a new one. luci.db is fine after upgrading.

Comment 4 Jan Pokorný [poki] 2011-11-02 16:22:31 UTC
I cannot reproduce your issue.

Answering following questions would help me to understand the problem:
1/ You have encountered it with fresh installation of luci, have you?
2/ Do you use any external yum repository such as EPEL?
3/ What output do you get running following command:

# rpm -q -- luci TurboGears2 pyOpenSSL python python-babel python-beaker \
python-cheetah python-decorator python-decoratortools python-formencode \
python-genshi python-mako python-markdown python-markupsafe python-myghty \
python-nose python-paste python-paste-deploy python-paste-script \
python-peak-rules python-peak-util-addons python-peak-util-assembler \
python-peak-util-extremes python-peak-util-symbols \
python-prioritized-methods python-pygments python-pylons python-repoze-tm2 \
python-repoze-what python-repoze-what-pylons python-repoze-who \
python-repoze-who-friendlyform python-repoze-who-testutil python-routes \
python-setuptools python-simplejson python-sqlalchemy python-tempita \
python-toscawidgets python-transaction python-turbojson python-tw-forms \
python-weberror python-webflash python-webhelpers python-webob \
python-webtest python-zope-filesystem python-zope-interface \
python-zope-sqlalchemy

Comment 5 Timm Stamer 2011-11-02 17:42:25 UTC
Yes, it is a fresh installation.

Yes, I use EPEL.

- Installed EPEL packages:

jabberpy.noarch                   0.5-0.21.el6        @epel-x86_64-server-6/6.1 
python-repoze-who-friendlyform.noarch 1.0.8-2.el6     @prod-epel-x86_64-server-6
python-tw-forms.noarch            0.9.9-3.el6         @prod-epel-x86_64-server-6


rpm -q --...:

luci-0.23.0-13.el6.x86_64
TurboGears2-2.0.3-4.el6.noarch
pyOpenSSL-0.10-2.el6.x86_64
python-2.6.6-20.el6.x86_64
python-babel-0.9.4-5.1.el6.noarch
python-beaker-1.3.1-6.el6.noarch
python-cheetah-2.4.1-1.el6.x86_64
python-decorator-3.0.1-3.1.el6.noarch
python-decoratortools-1.7-4.1.el6.noarch
python-formencode-1.2.2-2.1.el6.noarch
python-genshi-0.5.1-7.1.el6.x86_64
python-mako-0.3.4-1.el6.noarch
python-markdown-2.0.1-3.1.el6.noarch
python-markupsafe-0.9.2-4.el6.x86_64
python-myghty-1.1-11.el6.noarch
python-nose-0.10.4-3.1.el6.noarch
python-paste-1.7.4-1.el6.noarch
python-paste-deploy-1.3.3-2.1.el6.noarch
python-paste-script-1.7.3-4.el6.noarch
python-peak-rules-0.5a1.dev-9.2582.1.el6.noarch
python-peak-util-addons-0.6-4.1.el6.noarch
python-peak-util-assembler-0.5.1-1.el6.noarch
python-peak-util-extremes-1.1-4.1.el6.noarch
python-peak-util-symbols-1.0-4.1.el6.noarch
python-prioritized-methods-0.2.1-5.1.el6.noarch
python-pygments-1.1.1-1.el6.noarch
python-pylons-0.9.7-2.el6.noarch
python-repoze-tm2-1.0-0.5.a4.el6.noarch
python-repoze-what-1.0.8-6.el6.noarch
python-repoze-what-pylons-1.0-4.el6.noarch
python-repoze-who-1.0.13-2.el6.noarch
python-repoze-who-friendlyform-1.0.8-2.el6.noarch
python-repoze-who-testutil-1.0-0.4.rc1.el6.noarch
python-routes-1.10.3-2.el6.noarch
python-setuptools-0.6.10-3.el6.noarch
python-simplejson-2.0.9-3.1.el6.x86_64
python-sqlalchemy-0.5.5-2.1.el6.noarch
python-tempita-0.4-2.el6.noarch
python-toscawidgets-0.9.8-1.el6.noarch
python-transaction-1.0.1-1.el6.noarch
python-turbojson-1.2.1-8.1.el6.noarch
python-tw-forms-0.9.9-3.el6.noarch
python-weberror-0.10.2-1.el6.noarch
python-webflash-0.1-0.2.a9.el6.noarch
python-webhelpers-0.6.4-4.el6.noarch
python-webob-0.9.6.1-3.el6.noarch
python-webtest-1.2-2.el6.noarch
python-zope-filesystem-1-5.el6.x86_64
python-zope-interface-3.5.2-2.1.el6.x86_64
python-zope-sqlalchemy-0.4-3.el6.noarch



Without packages from EPEL it works!

# yum erase jabberpy.noarch python-repoze-who-friendlyform.noarch python-tw-forms.noarch
# yum install luci --disablerepo=*epel*

# service luci start
Adding following auto-detected host IDs (IP addresses/domain names), corresponding to `foo.bar.tld' address, to the configuration of self-managed certificate `/var/lib/luci/etc/cacert.config' (you can change them by editing `/var/lib/luci/etc/cacert.config', removing the generated certificate `/var/lib/luci/certs/host.pem' and restarting luci):
	(none suitable found, you can still do it manually as mentioned above)

Generating a 2048 bit RSA private key
writing new private key to '/var/lib/luci/certs/host.pem'
Start luci...                                              [  OK  ]


Thanks and sorry! My fault...

Comment 6 Jan Pokorný [poki] 2011-11-02 21:07:03 UTC
Based on my experience, I actually suspected EPEL.

I have to state that there is no guarantee that luci will work properly
when unsupported packages (mostly those mentioned above) collide with
luci's runtime environment.

When external yum repository is needed and the respective packages tend
to supersede the distribution's ones -- as just observed with EPEL offering
newer python-repoze-who-friendlyform and python-tw-forms -- it is advisable
to edit respective repository definition (e.g., /etc/yum.repos.d/epel.repo
added with installation of epel-release package) and exclude colliding
packages.

In this case, line like this might help (be aware of "python-*" impact):
---
exclude=python-* TurboGears2 pyOpenSSL
---

This is also suggested in related bug 741324 comment 5.  Also,
I am going to close this bug as a clone to that one.


Side note:
But to be honest, what is the real problem in this particular case
(at least from what I have seen) is broken consistency between EPEL's RPM
and contained Python package metadata, more specifically package
dependencies.  I have filled bug 750931 to address this.
Still and once again, luci + EPEL packages combination is discouraged.

*** This bug has been marked as a duplicate of bug 741324 ***

Comment 7 Jan Pokorný [poki] 2011-11-03 21:04:46 UTC
I wanted to add a diff of that "rpm -q" command results between that
in comment 5 and what I got on an updated RHEL 6.1 box without EPEL:

> -python-repoze-who-friendlyform-1.0.8-2.el6.noarch
> +python-repoze-who-friendlyform-1.0-0.3.b3.el6.noarch
> [...]
> -python-tw-forms-0.9.9-3.el6.noarch
> +python-tw-forms-0.9.9-1.el6.noarch

In other words, these are exactly the packages obtained from EPEL
(first of which is the problematic one as described in bug 750931).


Note You need to log in before you can comment on or make changes to this bug.