160422 - Can't locate data/versioncache in @INC

Status: RESOLVED FIXED

(Bugzilla :: Installation & Upgrading, defect)

Description

[David Yerger]

Got this error after adding a version and a component to two products.

Full message was:

Software error:
Can't locate data/versioncache in @INC (@INC contains: .
/usr/lib/perl5/5.6.0/i586-linux /usr/lib/perl5/5.6.0
/usr/lib/perl5/site_perl/5.6.0/i586-linux /usr/lib/perl5/site_perl/5.6.0
/usr/lib/perl5/site_perl) at globals.pl line 627.

For help, please send mail to the webmaster ([no address given]), giving this
error message and the time and date of the error. 

I renamed versioncache to badversioncache and clicked New from the actions in the 
page footer.  Worked.  Noticed that the new versioncache file was exactly like
the old one, but the new versioncache had the right permissions - the old was
owned by root, group root.

Can't rememeber what else I could have done to trigger this.

Comment 1

[Bradley Baetz (:bbaetz)]

Hmm. Which user/group does the webserver run as? Do you have the webservergroup
option set in localconfig?

Comment 2

[David Yerger]

Webserver runs as wwwrun/nogroup (it's a SuSE 7.1 box)

It is set in localconfig as "nogroup" but one time I ran checksetup.pl it was still
at the default ("nobody") 

Upon unpacking there were some directories set to 501/20, right now there are
just

CVS 
contrib
docs
t

Not sure if that's related.

Thanks

Comment 3

[Ian Young]

I just had the same symptom, which I traced back in my case to the 
contrib/bug_email_append.pl script having run recently, thus creating the 
data/versioncache file owned by the user that runs under.

The data/versioncache file is generated periodically and implicitly by things 
that use globals.pl, so unless everything runs as the same user, sometimes this 
will happen.  I fixed it (for now) by chown'ing the file back again, but 
obviously that's not a long-term solution.

If this isn't your problem, let me know as I'd like to log this one as a 
separate bug if so.  Maybe it is just a documentation problem, but the docs for 
the email append script do imply that you should set it up as a separate user, 
and obviously just adding that user to the web server group (or using root) 
doesn't suffice.

Comment 4

[Ian Young]

Forgot to mention that my comment above refers to 2.16.1, which I recently 
upgraded to.  I didn't see the problem in 2.16, but that could just be 
coincidence as I've only had the email integration stuff working for a week or 
so.

Comment 5

[Bradley Baetz (:bbaetz)]

The email stuff sucks in general :) The long term plan is to remove the reliance
on the versioncache file, which needs to be done for other reasons anyway.

Comment 6

[Robert White]

I am having a pathologically similar problem with core functionality.

First, some details:
Linux, slackware, stock kernel 2.4.18
Apache 2.0.something (but no matter, you will see... 8-)
Bugzilla 2.16.1 ("cvs checkout -rBugzilla_Stable bugzilla" 10/30/2002)
Coppied from /opt/buzilla/mozilla/webtools/bugzilla to /usr/local/bugzilla and
remove the CVS directory)

./checksetup.pl completed fine (both invocations)  Files are either
owned/grouped as "bugzilla/nobody" or "bugzilla/bugzilla", he database is up and
working, and so on.

my web server error_log gives, for any page but index.cgi, a similar burst:
(reffers removed)
 Uncaught exception from user code:
     Uncaught exception from user code:
     Can't locate data/params in @INC (@INC contains: .
/usr/lib/perl5/i386-linux /usr/lib/perl5 /usr/lib/perl5/site_perl/i386-linux
/usr/lib/perl5/site_perl) at globals.pl line 1445.
main::Param('shutdownhtml') called at CGI.pl line 61
     require CGI.pl called at /usr/local/bugzilla/createaccount.cgi line 32
Compilation failed in require at /usr/local/bugzilla/createaccount.cgi line 32.

The bugzilla directory is owned by user "bugzilla" uid=50000(bugzilla)
gid=50000(bugzilla) groups=50000(bugzilla),98(nobody)
and as bugzilla; the command "cd /usr/local/bugzilla ; ./reports.cgi" produces
the expected html.

So I added my core user id "rwhite" to the nobody group [uid=201(rwhite)
gid=100(users)groups=100(users),4(adm),10(wheel),95(serial),98(nobody),201(staff)]
and "cd /usr/local/bugzilla; ./reports.cgi" results in:

Uncaught exception from user code:
        Uncaught exception from user code:
        Can't locate data/params in @INC (@INC contains: .
/usr/lib/perl5/i386-linux /usr/lib/perl5 /usr/lib/perl5/site_perl/i386-linux
/usr/lib/perl5/site_perl) at globals.pl line 1445.
        main::Param('shutdownhtml') called at CGI.pl line 61
        require CGI.pl called at ./reports.cgi line 51
Compilation failed in require at ./reports.cgi line 51.

So clearly, something critical is no longer being properly set in checksetup.pl
or there is some pathing loss.  Either that or one of the modules is doing some
third-estate user/group id change.

I know that if I chage the ownership of the whole directory tree to "nobody" as
a the owner, then the web interface will start working, but that is *very* not
secure.

Comment 7

[Robert White]

BONUS DATA:

The main screen always worked "kind of" by doing a logout/forget saved user and
then logging back in, "data/versioncache" was created (nobody/nobody) and then
the os-level user actions  (su - rwhite -c "cd /usr/local/bugzilla;
./reports.cgi") began working.

I think checksetup needs to create this file (possibly with suitably empty values).

Comment 8

[Steef de Bruijn]

I tracked it down to the cronjob collectstats.pl. It runs as root (trying to run
it as apache/apache is bouncing on file/dir permissions). This cronjob leaves
the versioncache file with owner root/root instead of apache/apache (when the
webpages create this file periodically, the versioncache file *is* created as
apoache/apache).

So, for now, i chown the versioncache file from the cronjob after the
collectstats.pl has run...

Comment 9

[Jason Pyeron]

from comment 8, shouldn't you run the cron job from user apache?
if there is no login shell for apache, then atleast su before.

this just seems to be simple security sense.

Comment 10

[Dave Miller [:justdave]]

I just ran into this on Bugscape...

Since the data directory is writable by the webserver and not sticky, the
webserver can delete files from it.  So the easy fix is to check whether
versioncache is readable or not, and if we can't read it, then treat it like
it's expired and rebuild it.  Tested this on Bugscape and it works just dandy
there. :)

Comment 11

[Dave Miller [:justdave]]

Attachment: Patch

Comment 12

[Myk Melez [:myk] [@mykmelez]]

Comment on attachment 126454 [details] [diff] [review]
Patch

Urk, I don't know how I missed notating my review on this.  I reviewed it a
while ago.  Sorry Dave.  r=myk

Comment 13

[Dave Miller [:justdave]]

Checking in globals.pl;
/cvsroot/mozilla/webtools/bugzilla/globals.pl,v  <--  globals.pl
new revision: 1.246; previous revision: 1.245
done

Comment 14

[Dave Miller [:justdave]]

Checked in on 2.16 branch.  Low risk, high impact fix.

Checking in globals.pl;
/cvsroot/mozilla/webtools/bugzilla/globals.pl,v  <--  globals.pl
new revision: 1.169.2.16; previous revision: 1.169.2.15
done