Closed Bug 239193 Opened 16 years ago Closed 13 years ago
.pl doesn't know where it lives
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0) Build Identifier: In the new version of Bugzilla(tip) , updated today(03/30/2004), an error ocurs: " No value for param loginmethod (try running checksetup.pl again) at /usr/local/bugzilla/Bugzilla/Config.pm line 161. BEGIN failed--compilation aborted at /usr/local/bugzilla/Bugzilla/Auth.pm line 42. Compilation failed in require at /usr/local/bugzilla/Bugzilla.pm line 27. BEGIN failed--compilation aborted at /usr/local/bugzilla/Bugzilla.pm line 27. Compilation failed in require at /usr/local/bugzilla/importxml.pl line 62. BEGIN failed--compilation aborted at /usr/local/bugzilla/importxml.pl line 62. " Reproducible: Always Steps to Reproduce: 1. 2. 3.
Have you actually tried to do what the message suggests? :-) >> try running checksetup.pl again It still doesn't work after re-running it? Does checksetup.pl give any errors? Thanks!
(In reply to comment #1) > Have you actually tried to do what the message suggests? :-) > >> try running checksetup.pl again Yes, i have tried to do what the messages sugest, but nothing changed > It still doesn't work after re-running it? Does checksetup.pl give any errors? > Thanks! No.checksetup does not give any error. I think there is some problem with new implemtations, because i have a Bugzilla version 2.17.4 running perfect is the same machine. Thanks for the help.
The file permissions on your data/params file are not loose enough that they can be accessed from the sendmail user. You have to make additional permissions changes to make sure both sendmail and apache can access the necessary files on the system. *** This bug has been marked as a duplicate of 127818 ***
Status: UNCONFIRMED → RESOLVED
Closed: 16 years ago
Resolution: --- → DUPLICATE
And if you're using a $webservergroup in localconfig, then checksetup.pl will screw up those permissions. Running with $webservergroup being blank should work, but is less secure. If you don't have end users with access to the shell on that box it probably won't be a big deal though.
The problem is that i am runing the same command "/usr/bin/perl /usr/local/bugzilla/importxml.pl" on th shell with root account and 777 permision for the whole directory and it keep with the same error.
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
I fixed the problem by putting this on my /etc/aliases on sendmail: bugzilla-import_new: "| cd /usr/local/bugzilla/ && /usr/bin/perl /usr/local/bugzilla/importxml.pl" With the "cd" work so greate but without .... I think this is a bug... Thanks for your notes....
Ahh, yes, I remember having to do that last time I set it up (I opted for hardcoding a use lib qw(/path/to/bugzilla) at the top of the file in my case). Yeah, this is something that needs to be thought about... normally I'd say it's a docs issue, but as much of the related stuff is probably getting rewritten soon, I'll leave this around to make sure we don't forget about it.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Linux → All
Hardware: PC → All
Summary: Error while using importxml.pl while running from sendmail → importxml.pl doesn't know where it lives
Reassigning bugs that I'm not actively working on to the default component owner in order to try to make some sanity out of my personal buglist. This doesn't mean the bug isn't being dealt with, just that I'm not the one doing it. If you are dealing with this bug, please assign it to yourself.
Assignee: justdave → import-export
QA Contact: mattyt-bugzilla → default-qa
(In reply to comment #6) > I fixed the problem by putting this on my /etc/aliases on sendmail: > bugzilla-import_new: "| cd /usr/local/bugzilla/ > && /usr/bin/perl /usr/local/bugzilla/importxml.pl" > > With the "cd" work so greate but without .... > I think this is a bug... > Thanks for your notes.... I don't think this solution would work with sendmail running smrsh - it would refuse to run /usr/bin/perl for a start (and it's a BAD idea to place a symlink to perl in /etc/smrsh!!). The suggested way to call perl scripts is to symlink from /etc/smrsh/script.pl to the perl script location, defining the perl executable in "#!" on line 1 of the script. However, the BEGIN statement at the start of importxml.pl will set the path as being /etc/smrsh rather than being in the correct place - and the script will fall over when it fails to find Bugzilla.pm. Need to be able to fix the path to the target of the symlink if this is the case (and chdir in BEGIN) to allow the script to run in these circumstances.
Greg, is this bug fixed by bug 285614 now?
I have not changed any of the path handling in importxml.pl but I have not been able to reproduce this error. I do not use sendmail to move bugs however so I am not sure that it isn't still a problem.
I think the anormal behavior described was because a problem in Config.pm described in bug 365035 which is fixed. I think this bug should be marked as duplicate of it.
Status: NEW → RESOLVED
Closed: 16 years ago → 13 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 365035
You need to log in before you can comment on or make changes to this bug.