I just installed mantis (mantis-1.0.8-1.fc7.noarch et al.). I turned my browser to http://localhost/mantis/ and got:
Forbidden
You don't have permission to access /mantis/ on this server. Apache/2.2.4 (Fedora) Server at localhost Port 80
And similarly for http://localhost/mantis.
So I go look at the configuration file, and it says to read a file called README.Fedora. When I finally tracked that down, it said to point your browser at https://localhost/mantis/admin/install.php. I did so. After some gabble about certificates, I got:
Forbidden
You don't have permission to access /mantis/admin/install.php on this server. Apache/2.2.4 (Fedora) Server at localhost Port 443
Now what?
On Thu, 2007-08-23 at 14:10 -0600, Charles Curley wrote:
I just installed mantis (mantis-1.0.8-1.fc7.noarch et al.). I turned my browser to http://localhost/mantis/ and got:
Forbidden
You don't have permission to access /mantis/ on this server. Apache/2.2.4 (Fedora) Server at localhost Port 80
And similarly for http://localhost/mantis.
So I go look at the configuration file, and it says to read a file called README.Fedora. When I finally tracked that down, it said to point your browser at https://localhost/mantis/admin/install.php. I did so. After some gabble about certificates, I got:
Forbidden
You don't have permission to access /mantis/admin/install.php on this server. Apache/2.2.4 (Fedora) Server at localhost Port 443
Now what?
You might want to look at the recent threads I've had with Scott over Apache and Drupal. It might be the same kinds of issues (symlinks to things in /usr/share/program-name, SELinux contexts, Linux permissions, Apache allow-from/deny rules, etc.).
On Fri, Aug 24, 2007 at 11:53:11AM +0930, Tim wrote:
On Thu, 2007-08-23 at 14:10 -0600, Charles Curley wrote:
I just installed mantis (mantis-1.0.8-1.fc7.noarch et al.). I turned
Now what?
You might want to look at the recent threads I've had with Scott over Apache and Drupal. It might be the same kinds of issues (symlinks to things in /usr/share/program-name, SELinux contexts, Linux permissions, Apache allow-from/deny rules, etc.).
No joy. SELinux is not an issue. File permissions all look good: files are readable by other, direcotries readable and executable by other. I set the perms to wide open:
Alias /mantis /usr/share/mantis
<Directory /usr/share/mantis> # As passwords will be sent over the line do not allow plaintext # communication SSLRequireSSL
Options None
# Do not change this unless the default administrator # login was removed; see documentation for details Order Allow,Deny Allow from all
php_flag "register_globals" "off" SetEnv MANTIS_CONFIG /etc/mantis/config_inc.php </Directory>
And I remembered to restart apache when I did so.
I did not muck with symlinks. Tha alias above should have done it without. I have a similar alias for local docs:
# Allow access to local system documentation from localhost Alias /doc/ /usr/share/doc/ <Location /doc> order deny,allow deny from all allow from foo bar localhost .localdomain Options Indexes FollowSymLinks </Location>
I tried copying the Options line into the mantis alias; no joy.
On Sat, Aug 25, 2007 at 01:49:51PM -0600, Charles Curley wrote:
On Fri, Aug 24, 2007 at 11:53:11AM +0930, Tim wrote:
On Thu, 2007-08-23 at 14:10 -0600, Charles Curley wrote:
I just installed mantis (mantis-1.0.8-1.fc7.noarch et al.). I turned
It took me under an hour to install from tarball and set up several accounts, projects, etc.
On Sat, Aug 25, 2007 at 03:06:08PM -0600, Charles Curley wrote:
On Sat, Aug 25, 2007 at 01:49:51PM -0600, Charles Curley wrote:
On Fri, Aug 24, 2007 at 11:53:11AM +0930, Tim wrote:
On Thu, 2007-08-23 at 14:10 -0600, Charles Curley wrote:
I just installed mantis (mantis-1.0.8-1.fc7.noarch et al.). I turned
It took me under an hour to install from tarball and set up several accounts, projects, etc.
Oh, and in the process of doing so I found out that the RPM is missing a dependency: php-mysql, which pulls in php-pdo.
Charles Curley wrote:
On Sat, Aug 25, 2007 at 03:06:08PM -0600, Charles Curley wrote:
On Sat, Aug 25, 2007 at 01:49:51PM -0600, Charles Curley wrote:
On Fri, Aug 24, 2007 at 11:53:11AM +0930, Tim wrote:
On Thu, 2007-08-23 at 14:10 -0600, Charles Curley wrote:
I just installed mantis (mantis-1.0.8-1.fc7.noarch et al.). I turned
It took me under an hour to install from tarball and set up several accounts, projects, etc.
Oh, and in the process of doing so I found out that the RPM is missing a dependency: php-mysql, which pulls in php-pdo.
Do file a bug report.
Rahul
On Sun, Aug 26, 2007 at 03:09:58AM +0530, Rahul Sundaram wrote:
Charles Curley wrote:
On Sat, Aug 25, 2007 at 03:06:08PM -0600, Charles Curley wrote:
On Sat, Aug 25, 2007 at 01:49:51PM -0600, Charles Curley wrote:
On Fri, Aug 24, 2007 at 11:53:11AM +0930, Tim wrote:
On Thu, 2007-08-23 at 14:10 -0600, Charles Curley wrote:
I just installed mantis (mantis-1.0.8-1.fc7.noarch et al.). I turned
It took me under an hour to install from tarball and set up several accounts, projects, etc.
Oh, and in the process of doing so I found out that the RPM is missing a dependency: php-mysql, which pulls in php-pdo.
Do file a bug report.
No, Rahul, I will not follow a bug report, for two reasons.
* If the maintainer is not already aware of the problem from reading this thread, then he doesn't give enough of a damn for me to spend any more time on it.
* The package is so pathetically broken (see earlier in this thread) that the lack of the php-mysql package is irrelevant, another reason to believe that the maintainer doesn't give a damn.
Charles Curley wrote:
No, Rahul, I will not follow a bug report, for two reasons.
- If the maintainer is not already aware of the problem from reading this thread, then he doesn't give enough of a damn for me to spend any more time on it.
You aren't expecting every maintainer to subscribe to user lists and follow all the threads here. Do you? Very very few people have the time to do this and mailing lists are not a good place to keep track of bugs which is why bugzilla exists.
- The package is so pathetically broken (see earlier in this thread) that the lack of the php-mysql package is irrelevant, another reason to believe that the maintainer doesn't give a damn.
Not everyone hits the same problems. I wouldn't assume anything without even sending any feedback.
Rahul
On Sun, Aug 26, 2007 at 04:55:31PM +0530, Rahul Sundaram wrote:
Charles Curley wrote:
No, Rahul, I will not follow a bug report, for two reasons.
- If the maintainer is not already aware of the problem from reading
this thread, then he doesn't give enough of a damn for me to spend any more time on it.
You aren't expecting every maintainer to subscribe to user lists and follow all the threads here. Do you? Very very few people have the time to do this and mailing lists are not a good place to keep track of bugs which is why bugzilla exists.
Yes, as a matter of fact, I do expect them to subscribe to this list. Not because they are maintainers per se, but because presumably they are users as well. It would be a bit difficult to maintain a package without using Fedora. Of course I could be wrong, which would explain the state of the Mantis package.
As for following every single thread, that's a straw man argument. It isn't hard to write a filter to make emails with certain key words (e.g. "mantis") jump out at you.
- The package is so pathetically broken (see earlier in this thread)
that the lack of the php-mysql package is irrelevant, another reason to believe that the maintainer doesn't give a damn.
Not everyone hits the same problems. I wouldn't assume anything without even sending any feedback.
The fact that I haven't seen any message to the effect of "Yeah, I saw that, try this" and only one general "try this list of things to look at" suggests that nobody has the RPM working.
Has anyone got the Mantis RPM working? Or have folks done what I did: give up on it and use the upstream tarball?
And another thought, Rahul: maintainers can ignore bugzilla entries same as they can emails. I've had one bug (189120) oustanding since 2006-04-17, and no-one has yet taken ownership, never mind actually done anything about it.
Charles Curley wrote:
Yes, as a matter of fact, I do expect them to subscribe to this list. Not because they are maintainers per se, but because presumably they are users as well. It would be a bit difficult to maintain a package without using Fedora.
So let me tell you. You have the wrong expectations. Many maintainers as well as end users are not going to subscribe to this list for various reasons. Lack of time. Preference to other ways of getting help like forums etc.
As for following every single thread, that's a straw man argument. It isn't hard to write a filter to make emails with certain key words (e.g. "mantis") jump out at you.
That assumes everyone chooses a good subject and sticks to the topic. Not happening in this list.
Has anyone got the Mantis RPM working? Or have folks done what I did: give up on it and use the upstream tarball?
If noone reports back any feedback, you can't expect anything to change.
And another thought, Rahul: maintainers can ignore bugzilla entries same as they can emails. I've had one bug (189120) oustanding since 2006-04-17, and no-one has yet taken ownership, never mind actually done anything about it.
This isn't a commercial product and there isn't any guarantee of response however the feedback on bugzilla does reach the maintainers directly and is way more easier to keep track of. File a bug report instead of expecting everyone to deal with bug reports in a end user's mailing list.
Rahul
Charles Curley wrote:
You aren't expecting every maintainer to subscribe to user lists and follow all the threads here. Do you? Very very few people have the time to do this and mailing lists are not a good place to keep track of bugs which is why bugzilla exists.
Yes, as a matter of fact, I do expect them to subscribe to this list. Not because they are maintainers per se, but because presumably they are users as well. It would be a bit difficult to maintain a package without using Fedora. Of course I could be wrong, which would explain the state of the Mantis package.
But not all users will gain from reading the messages on this list. Certainly most folks capable of maintaining packages would get bored reading the many questions by folks that are new users, especially if they don't have time to help out with answering those questions.
You may well know what the package to maintainer ratio is in Fedora. If not, it's rather large, with nearly 4700 source packages in the distro and a little other 400 maintainers. I don't think it's all that unreasonable to ask that users help out by reporting bugs to bugzilla.
I do understand your hesitation of the package seems so full of bugs that it's pointless. However, if that doesn't get bugzilla'd, then other maintainers may not find out for a while that something is horribly awry in the mantis package and that someone needs some help (or a smack with the cluestick). So, a bugzilla may be the most helpful thing you could do for a terribly broken package, even if it just says that there are numerous problems (listing them briefly) with the package and the whole things needs work.
As for following every single thread, that's a straw man argument. It isn't hard to write a filter to make emails with certain key words (e.g. "mantis") jump out at you.
Bugzilla has the advantage that it mails the maintain automatically and that the conversations there are more easily searchable on various fields.
I think you should view it as a plus that some maintainers do take the time to follow this list, not as a negative that all of them don't. And always keep in mind that since the OS and all the work to create it are given to you for free, it's not that much to ask for you to report problems in the place that's most accommodating to the maintainer. (And I'm not saying that you don't report things to bugzilla personally. I know from my own little travels in bugzilla that isn't true. :)
The fact that I haven't seen any message to the effect of "Yeah, I saw that, try this" and only one general "try this list of things to look at" suggests that nobody has the RPM working.
Or that no one on this list has tried to use it. How many users are installing bug trackers? I think that it's a low number of the folks on this list. I haven't seen anyone mentioning Trac here either, but that doesn't make me think it's broken too. :)
Has anyone got the Mantis RPM working? Or have folks done what I did: give up on it and use the upstream tarball?
I'd read your mails and thought about trying to take a look at getting the rpm to see what might be broken with it. I do detest mantis as a user. I've hated having to interact with it every time I've reported a bug to an upstream that used it. So I figured I'd wait and see if someone else helped you out before putting myself through some likely pain. ;-)
And another thought, Rahul: maintainers can ignore bugzilla entries same as they can emails. I've had one bug (189120) oustanding since 2006-04-17, and no-one has yet taken ownership, never mind actually done anything about it.
That is certainly true. Just because someone maintains a package doesn't mean that they do it well. Having things in bugzilla though makes it easier to find those lax maintainers and give them the help (or kick) that they need. Other folks can run reports on bugzilla to find which maintainers have been unresponsive to bugs. Then, if it's appropriate, there's the AWOL maintainer process for those folks that just stop responding to bugs/updates/needed changes in their packages.
(In the case of the above bug, it's also possible that it was fixed in a newer gnome release and it just didn't get closed properly. It may also have gotten lost in the forest of desktop bugs. It's assigned to Ray Strode who isn't someone I'd consider a lax maintainer. He does a lot of work with upstream gnome projects and within the Fedora desktop team. So I'd guess the lack of response there is due to the latter.)
On Sun, 2007-08-26 at 13:40 -0400, Todd Zullinger wrote:
Charles Curley wrote:
You aren't expecting every maintainer to subscribe to user lists and follow all the threads here. Do you? Very very few people have the time to do this and mailing lists are not a good place to keep track of bugs which is why bugzilla exists.
Yes, as a matter of fact, I do expect them to subscribe to this list. Not because they are maintainers per se, but because presumably they are users as well. It would be a bit difficult to maintain a package without using Fedora. Of course I could be wrong, which would explain the state of the Mantis package.
But not all users will gain from reading the messages on this list. Certainly most folks capable of maintaining packages would get bored reading the many questions by folks that are new users, especially if they don't have time to help out with answering those questions.
You may well know what the package to maintainer ratio is in Fedora. If not, it's rather large, with nearly 4700 source packages in the distro and a little other 400 maintainers. I don't think it's all that unreasonable to ask that users help out by reporting bugs to bugzilla.
I do understand your hesitation of the package seems so full of bugs that it's pointless. However, if that doesn't get bugzilla'd, then other maintainers may not find out for a while that something is horribly awry in the mantis package and that someone needs some help (or a smack with the cluestick). So, a bugzilla may be the most helpful thing you could do for a terribly broken package, even if it just says that there are numerous problems (listing them briefly) with the package and the whole things needs work.
I agree that bugzilla should work but it has never worked for me. I file bugzillas and nothing much happens. By the time we get through all the requests for further info a new distribution is out and it makes no difference.
I will admit some bugzilla reports are resolved but I have never been that lucky.
I will go further and explain in what situation it is useless to bugzilla. When you problem is more or less unique to your system. If a large fraction on users are having the same problem that your chances of getting an answer are better. -- ======================================================================= The world needs more people like us and fewer like them. ======================================================================= Aaron Konstam telephone: (210) 656-0355 e-mail: akonstam@sbcglobal.net
Aaron Konstam wrote:
I agree that bugzilla should work but it has never worked for me. I file bugzillas and nothing much happens. By the time we get through all the requests for further info a new distribution is out and it makes no difference.
Perhaps it doesn't end with an updated package for the version you reported the problem in, but it often means that the bug is fixed so future version won't have the same problem. That is making a difference and anything you do to help that process is surely appreciated by many users and maintainers (even if many of the users never notice the fixes to bugs they never had the joy of stumbling upon :).
I will admit some bugzilla reports are resolved but I have never been that lucky.
You must not have been clicking your heels the proper amount of times then. You do click your heels when you report a bug, don't you? ;-)
I will go further and explain in what situation it is useless to bugzilla. When you problem is more or less unique to your system. If a large fraction on users are having the same problem that your chances of getting an answer are better.
Yes, it's very difficult for an maintainer or developer to fix a bug that they cannot reproduce. There's nothing specific about bugzilla in that problem. It'd be just as difficult of the bug reports went to a mailing list. :)
On Sun, Aug 26, 2007 at 02:35:01PM -0400, Todd Zullinger wrote:
Aaron Konstam wrote:
I agree that bugzilla should work but it has never worked for me. I file bugzillas and nothing much happens. By the time we get through all the requests for further info a new distribution is out and it makes no difference.
Perhaps it doesn't end with an updated package for the version you reported the problem in, but it often means that the bug is fixed so future version won't have the same problem.
Then the maintainer should close the report and specify the resolution. That way the reporter knows what's happened. If Aaron's going to go to the effort of preparing a good bug report, answering questions, performing experiments, etc. he at least deserves that courtesy.
You and Rahul seem to want to make things as easy as possible for the maintainers. I think that's a fine idea. But it's a two way street: the maintainers can acknowledged reports, work with the reporters, and resolve the bugs. A "Won't fix" with an explanation of why is better than leaving it hanging.
I will go further and explain in what situation it is useless to bugzilla. When you problem is more or less unique to your system. If a large fraction on users are having the same problem that your chances of getting an answer are better.
Yes, it's very difficult for an maintainer or developer to fix a bug that they cannot reproduce. There's nothing specific about bugzilla in that problem. It'd be just as difficult of the bug reports went to a mailing list. :)
Then the maintainer should try to reproduce it, and if he can't, report that fact, and ask the reporter for help in reproducing it. If all else fails, put a sheepish expression on your face, resolve it as "can't reproduce", and close it. Then at least Aaron will know what happened to his problem.
Charles Curley wrote:
On Sun, Aug 26, 2007 at 02:35:01PM -0400, Todd Zullinger wrote:
Perhaps it doesn't end with an updated package for the version you reported the problem in, but it often means that the bug is fixed so future version won't have the same problem.
Then the maintainer should close the report and specify the resolution. That way the reporter knows what's happened. If Aaron's going to go to the effort of preparing a good bug report, answering questions, performing experiments, etc. he at least deserves that courtesy.
I don't know the details of the reports Aaron was talking about. He did say that there was a lengthy exchange asking for info, which leads me to believe that the maintainer tried to get the needed info.
But yes, I agree that bug reports should be acknowledged and closed with some reason, even it's "can't reproduce" or something.
You and Rahul seem to want to make things as easy as possible for the maintainers. I think that's a fine idea. But it's a two way street: the maintainers can acknowledged reports, work with the reporters, and resolve the bugs. A "Won't fix" with an explanation of why is better than leaving it hanging.
Of course. I hope I didn't give the impression that reports should be ignored. What I do think it worth noting is the sheer number of reports and the limit on hours per day. Most maintainers aren't paid to work on Fedora packages, so it seems quite reasonable to expect that a user wanting a bug fixed be patient and understanding if their bug doesn't get the attention they would like.
I only recently started to maintain a few packages so I don't have piles of bug reports to deal with as some maintainers do. I certainly intend to reply to every bug report that is filed on any of my packages, but I know that other maintainers with heavier workloads may not be able to do that. What can really help in those cases are volunteers to do some triaging of bugs to weed out duplicates and ask for more info from reports that lack enough detail to enable proper debugging[1].
Basically, since this is a mostly volunteer effort, I get a little defensive when anyone has too many expectations from the volunteers. (I'm not saying that you do, so please don't take that personally. :)
[1] http://fedoraproject.org/wiki/BugZappers
On Sun, Aug 26, 2007 at 04:50:17PM -0400, Todd Zullinger wrote:
Charles Curley wrote:
On Sun, Aug 26, 2007 at 02:35:01PM -0400, Todd Zullinger wrote:
I don't know the details of the reports Aaron was talking about. He did say that there was a lengthy exchange asking for info, which leads me to believe that the maintainer tried to get the needed info.
But yes, I agree that bug reports should be acknowledged and closed with some reason, even it's "can't reproduce" or something.
Fair enough.
You and Rahul seem to want to make things as easy as possible for the maintainers. I think that's a fine idea. But it's a two way street: the maintainers can acknowledged reports, work with the reporters, and resolve the bugs. A "Won't fix" with an explanation of why is better than leaving it hanging.
Of course. I hope I didn't give the impression that reports should be ignored. What I do think it worth noting is the sheer number of reports and the limit on hours per day. Most maintainers aren't paid to work on Fedora packages, so it seems quite reasonable to expect that a user wanting a bug fixed be patient and understanding if their bug doesn't get the attention they would like.
I only recently started to maintain a few packages so I don't have piles of bug reports to deal with as some maintainers do.
I have had such piles, although not with Fedora. My advice: learn how to triage them, and how to move them along. Do not get behind; it will kill you. It's also rude to the reporter.
I certainly intend to reply to every bug report that is filed on any of my packages,
I appreciate that; I hope the good intentions last. As you are a volunteer (so I take it), don't take on more than you can chew, and leave yourself some slack. That's advice I've been giving volunteers and paid employees for damn near half a century now, and its good advice.
but I know that other maintainers with heavier workloads may not be able to do that. What can really help in those cases are volunteers to do some triaging of bugs to weed out duplicates and ask for more info from reports that lack enough detail to enable proper debugging[1].
OK, I've worked as a paid professional on the receiving end of bug systems similar to bugzilla. Sorry, but from that experience I'm skeptical of the bug zappers. I think it is part of the maintainer's job to do that stuff. I'm glad to see it proposed and I hope it prospers. The work definitely needs to be done!
Is there a document anywhere that details what a maintainer should expect from bugzilla and reporters, how to go about using the system, etc. For example, a document that gives circumstances under which one would mark a bug as "will not fix", and steps to take prior to doing so. An ops manual, if you will, for bugzilla?
Yeah, I know: this is FOSS: Read the Source.
Basically, since this is a mostly volunteer effort, I get a little defensive when anyone has too many expectations from the volunteers. (I'm not saying that you do, so please don't take that personally. :)
Understandable, and not taken personally.
[1] http://fedoraproject.org/wiki/BugZappers
-- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
Things in our country run in spite of government, not by aid of it. -- Will Rogers
-- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Charles Curley wrote:
I only recently started to maintain a few packages so I don't have piles of bug reports to deal with as some maintainers do.
I have had such piles, although not with Fedora. My advice: learn how to triage them, and how to move them along. Do not get behind; it will kill you. It's also rude to the reporter.
Very true. Sometimes reality and other factors step in and keep that truth from being followed. :)
I certainly intend to reply to every bug report that is filed on any of my packages,
I appreciate that; I hope the good intentions last. As you are a volunteer (so I take it), don't take on more than you can chew, and leave yourself some slack. That's advice I've been giving volunteers and paid employees for damn near half a century now, and its good advice.
Indeed it's good advice. I've volunteered in a few places over the years and have watched many people join, push hard, burn out, and disappear. A lot of people can sprint, few can run marathons.
I'm particularly good at not taking on too much (some would say I'm a little too good at it ;).
OK, I've worked as a paid professional on the receiving end of bug systems similar to bugzilla. Sorry, but from that experience I'm skeptical of the bug zappers. I think it is part of the maintainer's job to do that stuff. I'm glad to see it proposed and I hope it prospers. The work definitely needs to be done!
I see it as much like a good secretary, who acts as a filter. That way the boss only has to deal with the important things without weeding out duplicate information and other useless info.
Is there a document anywhere that details what a maintainer should expect from bugzilla and reporters, how to go about using the system, etc. For example, a document that gives circumstances under which one would mark a bug as "will not fix", and steps to take prior to doing so. An ops manual, if you will, for bugzilla?
I'm sure there are various pieces of this on the Fedora wiki and in the mailing list archives. I don't have any links off the top of my head. In bugzilla itself, the various states a bug can be in are described at https://bugzilla.redhat.com/page.cgi?id=bug_status.html
I've seen discussion about a maintainer responsibility document, but I don't think anything solid exists yet.
To bring this discussion back to the topic of mantis a bit, I installed the package last night and got it working (in a little over the 20-30 minutes that the mantis docs say it should take). I don't think that the package is hopelessly broken, but there are a few things that could definitely be fixed up to provide a better user experience. Here are some notes of what I ran into, some of which I think are what bit you (mostly the Apache Allow/Deny rules):
1) php-mysql missing -- should this be required? It seems that technically it isn't, but it makes for an unusable default. At the least, the php-mysql package should be noted in the README.Fedora file. The package changelog indicates that the dependency was removed a long time ago (version 0.19.2-1) because the package can be used with PostgreSQL as well.
2) Apache rules use "Allow from localhost", but seem to fail with the default hosts file that specifies localhost.localdomain as the canonical hostname. Using allow from 127.0.0.1 worked out better for me, and seems to be what the other web app packages I have installed use.
3) mantis 1.0.8 has a bug that keeps the initial db creation from working. See http://www.mantisbt.org/bugs/view.php?id=8256 for a report and patch. This should get added to the Fedora package until a 1.0.9 release is made upstream.
4) SELinux generated an error when trying to send a password reminder:
type=AVC msg=audit(1188186921.311:669): avc: denied { read } for pid=3974 comm="sh" name="sendmail.postfix" dev=sda2 ino=216037 scontext=user_u:system_r:httpd_t:s0 tcontext=system_u:object_r:sendmail_exec_t:s0 tclass=file
I disabled SELinux before using the package much further, so I don't know if there are other SELinux issues lurking. It may only occur with Postfix, I don't know.
Aside from that, I had a seemingly usable[1] mantis install in a reasonable amount of time. With the Apache allow/deny rules setup it is probably a little more secure than just unpacking the upstream tarball in /var/www/html. But that security definitely caused me the most hassle in working out why I was getting access denied errors. I didn't think Apache was that strict with the hostnames used.
I reported these issues at:
https://bugzilla.redhat.com/show_bug.cgi?id=257561
Please feel free to add anything that I missed. :)
[1] For some definition of usable (I'm not a mantis lover myself.)
On Mon, 2007-08-27 at 14:20 -0400, Todd Zullinger wrote:
- Apache rules use "Allow from localhost", but seem to fail with the default hosts file that specifies localhost.localdomain as the canonical hostname. Using allow from 127.0.0.1 worked out better for me, and seems to be what the other web app packages I have installed use.
I'm not a user of Mantis, but I do use Apache a lot. I've never had any problems with it using "localhost". The normal /etc/hosts file lists the Linuxism "localhost.localdomain" and has the standard 'localhost" as an alias, that's good enough for Apache. You'd have to have some real name resolution problems for that to fail.
Having said that, using allow or deny with a hostname/domain-name does mean that every access has to have a name lookup done (results are cached, though). Whereas using an IP (with or without netmask wildcarding) avoids that step, but means you can't easily apply such rules to hosts that change IPs dynamically.
Tim wrote:
On Mon, 2007-08-27 at 14:20 -0400, Todd Zullinger wrote:
- Apache rules use "Allow from localhost", but seem to fail with
the default hosts file that specifies localhost.localdomain as the canonical hostname. Using allow from 127.0.0.1 worked out better for me, and seems to be what the other web app packages I have installed use.
I'm not a user of Mantis, but I do use Apache a lot. I've never had any problems with it using "localhost". The normal /etc/hosts file lists the Linuxism "localhost.localdomain" and has the standard 'localhost" as an alias, that's good enough for Apache. You'd have to have some real name resolution problems for that to fail.
I'm not sure what I've got wrong then. If I change /etc/hosts to:
127.0.0.1 localhost localhost.localdomain
it works. If localhost.localdomain is the canonical name in /etc/hosts, I get denied.
I added a localhost.localdomain zone to my local DNS and things still wouldn't work. (I'd previously only had a localhost zone.)
Commenting out the localhost entry in /etc/hosts didn't work either.
Care to test this out and let me know if it's just me (and Charles) with this problem? I created /etc/httpd/conf.d/test.conf with the following content:
Alias /tmp /tmp
<Directory /tmp> Options Indexes Order deny,allow Deny from all #Allow from 127.0.0.1 #Allow from localhost #Allow from localhost. #Allow from localhost.localdomain </Directory>
In /etc/hosts:
127.0.0.1 localhost.localdomain localhost
I am able to browse to http://localhost/tmp/ with either the 127.0.0.1 or localhost.localdomain allow lines uncommented. Neither the localhost nor localhost. allowed me to access the URL.
On Tue, 2007-08-28 at 00:47 -0400, Todd Zullinger wrote:
I'm not sure what I've got wrong then. If I change /etc/hosts to:
127.0.0.1 localhost localhost.localdomain
it works. If localhost.localdomain is the canonical name in /etc/hosts, I get denied.
Using your examples, I found the same. I've not done this with FC7's Apache before, but I've certainly used localhost without any problems, with Apache on prior Fedora releases. I keep forgetting that the server is still on FC4.
There's something screwy, here. With that line, if I try to find the IP for either name, I should be told it. And I am, either will resolve.
If I try to find the name for that IP, I'll be told the first one. Apache acts like it's doing a double lookup (names to IPs and back again).
The expected behaviour: Set Apache to allow from localhost. Try browsing http://localhost/ from localhost.localdomain. The check should find out the IP for the localhost.localdomain and see if it's the same IP for localhost.
I added a localhost.localdomain zone to my local DNS and things still wouldn't work. (I'd previously only had a localhost zone.)
I've got both, I've had them that way since my nameserver was set up on FC4.
I don't know if IPv6 muddies the waters...
[root@bigblack conf]# host localhost localhost has address 127.0.0.1 localhost has IPv6 address ::1 [root@bigblack conf]# host localhost.localdomain localhost.localdomain has address 127.0.0.1
Commenting out the localhost entry in /etc/hosts didn't work either.
Care to test this out and let me know if it's just me (and Charles) with this problem? I created /etc/httpd/conf.d/test.conf with the following content:
Alias /tmp /tmp
<Directory /tmp> Options Indexes Order deny,allow Deny from all #Allow from 127.0.0.1 #Allow from localhost #Allow from localhost. #Allow from localhost.localdomain
</Directory>
In /etc/hosts:
127.0.0.1 localhost.localdomain localhost
I am able to browse to http://localhost/tmp/ with either the 127.0.0.1 or localhost.localdomain allow lines uncommented. Neither the localhost nor localhost. allowed me to access the URL.
Confirmed.
Personally, I've always avoided using localhost. About the only time I do is when browsing the CUPS configuration server. Otherwise, I normally use the name of the machine to browse to, and IPs in the Apache restrictions.
Tim wrote:
On Tue, 2007-08-28 at 00:47 -0400, Todd Zullinger wrote:
I'm not sure what I've got wrong then. If I change /etc/hosts to:
127.0.0.1 localhost localhost.localdomain
it works. If localhost.localdomain is the canonical name in /etc/hosts, I get denied.
Using your examples, I found the same.
Thank you much for checking this. :)
I've not done this with FC7's Apache before, but I've certainly used localhost without any problems, with Apache on prior Fedora releases. I keep forgetting that the server is still on FC4.
Yeah, I don't use the "allow from" with a name anywhere that I can recall, so I'd never run into this. I'll have to try it on some older Apache servers to see if it behaves differently. It sure seems like a bug somewhere.
RFC1912 (the text of which can be found in the caching-nameserver rpm docs as rfc1912.txt, or at http://www.ietf.org/rfc/rfc1912.txt), says this about localhost:
The "localhost" address is a "special" address which always refers to the local host. It should contain the following line:
localhost. IN A 127.0.0.1
The "127.0" file should contain the line:
1 PTR localhost.
There has been some extensive discussion about whether or not to append the local domain to it. The conclusion is that "localhost." would be the best solution. The reasons given include:
"localhost" by itself is used and expected to work in some systems.
Translating 127.0.0.1 into "localhost.dom.ain" can cause some software to connect back to the loopback interface when it didn't want to because "localhost" is not equal to "localhost.dom.ain".
Now, I may very well be overlooking other relevant RFC's, but the above reads to me like the default /etc/hosts entry which sets 127.0.0.1 to localhost.localdomain is causing the sort of problems that they're warning about. I don't know. Maybe Apache tightened up some of the rules used to process names used in "allow from" directives.
I added a localhost.localdomain zone to my local DNS and things still wouldn't work. (I'd previously only had a localhost zone.)
I've got both, I've had them that way since my nameserver was set up on FC4.
I hadn't changed mine since sometime in 2001. So I figured times must have changed and I updated my zone info. :)
I don't know if IPv6 muddies the waters...
I have IPv6 disabled here, with neither any zones configured in DNS nor entries in /etc/hosts. Funny enough, one of the mantis maintainers wondered if that might have some affect on things as well.
Thanks again for taking the time to test this out and confirm that it breaks for you as well as it does for Charles and me.
On Sun, Aug 26, 2007 at 01:40:57PM -0400, Todd Zullinger wrote:
You may well know what the package to maintainer ratio is in Fedora. If not, it's rather large, with nearly 4700 source packages in the distro and a little other 400 maintainers. I don't think it's all that unreasonable to ask that users help out by reporting bugs to bugzilla.
I do understand your hesitation of the package seems so full of bugs that it's pointless. However, if that doesn't get bugzilla'd, then other maintainers may not find out for a while that something is horribly awry in the mantis package and that someone needs some help (or a smack with the cluestick). So, a bugzilla may be the most helpful thing you could do for a terribly broken package, even if it just says that there are numerous problems (listing them briefly) with the package and the whole things needs work.
Todd, the whole open source bazaar is a multi-lateral trade area, as the term bazaar suggests. Most of us are not in this out of the kindness or our hearts, but because we want to get something done. I went to install the Mantis RPM because I wanted to get something done. I hit a problem. Instead of tossing the RPM and installing the tarball, I asked on the list. I made a good faith effort to look at the suggestions I got, and none of those panned out. I decided I had done my due dilligence for the community, and have now installed the tarball.
It may not be unreasonable to ask, but I just determined that in this instance the answer was "no".
As for following every single thread, that's a straw man argument. It isn't hard to write a filter to make emails with certain key words (e.g. "mantis") jump out at you.
Bugzilla has the advantage that it mails the maintain automatically and that the conversations there are more easily searchable on various fields.
I think you should view it as a plus that some maintainers do take the time to follow this list, not as a negative that all of them don't. And always keep in mind that since the OS and all the work to create it are given to you for free, it's not that much to ask for you to report problems in the place that's most accommodating to the maintainer. (And I'm not saying that you don't report things to bugzilla personally. I know from my own little travels in bugzilla that isn't true. :)
Thanks for the parenthetical acknowledgement. Everyone has to determine for themselves what contributions they will make to the community. I doubt very much I know all of yours, and you may not know all of mine. Nor do we need any central Soviet telling us, "Comrade Zullinger, you haven't written enough lines of free software this week. Back to your terminal!" So if you don't mind, I will determine whether something is "that much to ask" of me.
I'd read your mails and thought about trying to take a look at getting the rpm to see what might be broken with it. I do detest mantis as a user. I've hated having to interact with it every time I've reported a bug to an upstream that used it. So I figured I'd wait and see if someone else helped you out before putting myself through some likely pain. ;-)
Thanks for the thought. No-one has to do anything on this list, except maybe the paid employees whose duties encompass such things.
And another thought, Rahul: maintainers can ignore bugzilla entries same as they can emails. I've had one bug (189120) oustanding since 2006-04-17, and no-one has yet taken ownership, never mind actually done anything about it.
That is certainly true. Just because someone maintains a package doesn't mean that they do it well. Having things in bugzilla though makes it easier to find those lax maintainers and give them the help (or kick) that they need. Other folks can run reports on bugzilla to find which maintainers have been unresponsive to bugs. Then, if it's appropriate, there's the AWOL maintainer process for those folks that just stop responding to bugs/updates/needed changes in their packages.
That's a good point.
(In the case of the above bug, it's also possible that it was fixed in a newer gnome release and it just didn't get closed properly.
Nope, hasn't been fixed as far as I know. Sorry, I thought that was implied when I described the bug as "outstanding" rather than "still open".
It may also have gotten lost in the forest of desktop bugs. It's assigned to Ray Strode who isn't someone I'd consider a lax maintainer. He does a lot of work with upstream gnome projects and within the Fedora desktop team. So I'd guess the lack of response there is due to the latter.
As you say, probably an upstream bug. Given the likely nature of the problem, I doubt it's a packaging issue. Speaking of "too much to ask", could Mr. Strode enter the upstream issue number or URL and mark the bug appropriately?
He hasn't even taken ownership, so I have no reason to believe he has reported it upstream.
)
Charles Curley wrote:
Todd, the whole open source bazaar is a multi-lateral trade area, as the term bazaar suggests. Most of us are not in this out of the kindness or our hearts, but because we want to get something done.
I'm immediately suspect of anyone that claims to do anything purely for altruistic reasons. I think there's always a benefit to the giver as well. But that's a bit of a philosophical tangent. :)
I went to install the Mantis RPM because I wanted to get something done. I hit a problem. Instead of tossing the RPM and installing the tarball, I asked on the list. I made a good faith effort to look at the suggestions I got, and none of those panned out. I decided I had done my due dilligence for the community, and have now installed the tarball.
It may not be unreasonable to ask, but I just determined that in this instance the answer was "no".
Fair enough.
I sincerely hope I didn't come across as shitting on you for not reporting it to bugzilla.
I think you should view it as a plus that some maintainers do take the time to follow this list, not as a negative that all of them don't. And always keep in mind that since the OS and all the work to create it are given to you for free, it's not that much to ask for you to report problems in the place that's most accommodating to the maintainer. (And I'm not saying that you don't report things to bugzilla personally. I know from my own little travels in bugzilla that isn't true. :)
Thanks for the parenthetical acknowledgement. Everyone has to determine for themselves what contributions they will make to the community. I doubt very much I know all of yours, and you may not know all of mine. Nor do we need any central Soviet telling us, "Comrade Zullinger, you haven't written enough lines of free software this week. Back to your terminal!"
Hehe. I try to bail quickly from places that bark orders at me.
So if you don't mind, I will determine whether something is "that much to ask" of me.
Nope, I don't mind at all (in fact, I'd prefer that you determine that). I hope I didn't give the wrong impression in my replies. The thing that spurred me to write is the part about expecting maintainers to be subscribed here. That's similar to expecting all users to report all bugs to bugzilla (perhaps a little worse IMHO, since the signal to noise ratio here is much lower than it is in bugzilla :).
And since there are more users than maintainers here, the side of the maintainers is in more need of stating now and again.
Thanks for the thought. No-one has to do anything on this list, except maybe the paid employees whose duties encompass such things.
Indeed. I'm curious about it now and if other tasks don't fill my time and distract me, I may well poke into the mantis package a bit. If it's really fubar'd, it should be fixed or removed. It'd be far better to have you not find the package than to find it and waste an hour or more before just installing the tarball.
I know nothing about mantis though, so I wonder if it could be the sort of package like mailman, where there is a lot that needs to be done after installing the package before it will work? If so, there should be a fedora specific readme somewhere that explains such steps.
(In the case of the above bug, it's also possible that it was fixed in a newer gnome release and it just didn't get closed properly.
Nope, hasn't been fixed as far as I know. Sorry, I thought that was implied when I described the bug as "outstanding" rather than "still open".
I just didn't guess that you were being so specific with your wording (you damn writers ;). If it's still an issue with new versions, then the report could be updated to note that it still applies to f7. Otherwise it may end up getting closed when someone comes along and auto-closes bugs from older releases*. And changing the release version along with a comment something like "Ping! This is still a problem, any news?" may reach Ray at a moment when he can reply or look into it. (And to be clear, that's just a suggestion, I'm not saying you need to do this. :)
* I do think that if and when such bugs are closed, they generate a message to the reporter (and others on the CC list) that if they still apply to a current release, to reopen and change the release.
As you say, probably an upstream bug. Given the likely nature of the problem, I doubt it's a packaging issue. Speaking of "too much to ask", could Mr. Strode enter the upstream issue number or URL and mark the bug appropriately?
Perhaps. It may already be in the gnome bugzilla. It'd just take someone to search there and tag the rh bugzilla appropriately. Ray may or may not have time to do that (I don't know him personally.)
I think that generally, if a bug is likely to be an upstream bug (not a distro-specific or packaging bug), that it should be reported upstream directly. That way it can be addressed and fixed upstream for all distros to pick up when an update occurs. Who knows, maybe the bug you reported has been fixed by another distro maintainer and no one has yet reported it upstream so we can all get the fix.
He hasn't even taken ownership, so I have no reason to believe he has reported it upstream.
Sometimes this can be caused by bugs getting reassigned as teams at RedHat change members. I'm not saying the bug shouldn't get acknowledged or anything, just offering a possibly reasonable explanation for why it's gone so long without even being assigned.
On Sun, Aug 26, 2007 at 05:36:10PM -0400, Todd Zullinger wrote:
Charles Curley wrote:
Fair enough.
I sincerely hope I didn't come across as shitting on you for not reporting it to bugzilla.
You didn't. Others in other fora have been less polite. I was reacting to them and took it out on you. Sorry about that.
"Comrade Zullinger, you haven't written enough lines of free software this week. Back to your terminal!"
Hehe. I try to bail quickly from places that bark orders at me.
Good. We need more people who will do that.
So if you don't mind, I will determine whether something is "that much to ask" of me.
Nope, I don't mind at all (in fact, I'd prefer that you determine that). I hope I didn't give the wrong impression in my replies. The thing that spurred me to write is the part about expecting maintainers to be subscribed here. That's similar to expecting all users to report all bugs to bugzilla (perhaps a little worse IMHO, since the signal to noise ratio here is much lower than it is in bugzilla :).
It didn't occur to me that someone who maintained one or more packages for Fedora wouldn't also use it, and so wouldn't be on this list. Really.
And since there are more users than maintainers here, the side of the maintainers is in more need of stating now and again.
Yup. Which side you are getting to learn.
Thanks for the thought. No-one has to do anything on this list, except maybe the paid employees whose duties encompass such things.
Indeed. I'm curious about it now and if other tasks don't fill my time and distract me, I may well poke into the mantis package a bit. If it's really fubar'd, it should be fixed or removed. It'd be far better to have you not find the package than to find it and waste an hour or more before just installing the tarball.
I know nothing about mantis though, so I wonder if it could be the sort of package like mailman, where there is a lot that needs to be done after installing the package before it will work? If so, there should be a fedora specific readme somewhere that explains such steps.
There is a Fedora specific README which outlines a short process to go through. I followed it, to no avail.
(Such documents should be mentioned in the description field of the spec so installers know they exist, but that's another tirade!)
(In the case of the above bug, it's also possible that it was fixed in a newer gnome release and it just didn't get closed properly.
Nope, hasn't been fixed as far as I know. Sorry, I thought that was implied when I described the bug as "outstanding" rather than "still open".
I just didn't guess that you were being so specific with your wording (you damn writers ;). If it's still an issue with new versions, then the report could be updated to note that it still applies to f7. Otherwise it may end up getting closed when someone comes along and auto-closes bugs from older releases*. And changing the release version along with a comment something like "Ping! This is still a problem, any news?" may reach Ray at a moment when he can reply or look into it. (And to be clear, that's just a suggestion, I'm not saying you need to do this. :)
Good point.
- I do think that if and when such bugs are closed, they generate a message to the reporter (and others on the CC list) that if they still apply to a current release, to reopen and change the release.
I believe bugzilla sends an email, but don't recall the contents. I have reopened bugs under such circumstances but don't remember if they were in RH's bugzilla or elsewhere.
As you say, probably an upstream bug. Given the likely nature of the problem, I doubt it's a packaging issue. Speaking of "too much to ask", could Mr. Strode enter the upstream issue number or URL and mark the bug appropriately?
Perhaps. It may already be in the gnome bugzilla. It'd just take someone to search there and tag the rh bugzilla appropriately. Ray may or may not have time to do that (I don't know him personally.)
Ah, I was assuming that if Ray decided it was an upstream bug he'd file in their bugzilla (and search prior to filing, etc.). In that case, he'd know the number.
I think that generally, if a bug is likely to be an upstream bug (not a distro-specific or packaging bug), that it should be reported upstream directly. That way it can be addressed and fixed upstream for all distros to pick up when an update occurs. Who knows, maybe the bug you reported has been fixed by another distro maintainer and no one has yet reported it upstream so we can all get the fix.
I had understood that Fedora preferred such bugs to be filed in RH's bugzilla and if necessary the maintainer would file upstream. I don't recall where I got that, and it may have changed since I did.
I would think the packager, especially a person who is both maintaining a package and actively contributing to the upstream project, would be in a better position to determine whether to report upstream than an end user.
He hasn't even taken ownership, so I have no reason to believe he has reported it upstream.
Sometimes this can be caused by bugs getting reassigned as teams at RedHat change members. I'm not saying the bug shouldn't get acknowledged or anything, just offering a possibly reasonable explanation for why it's gone so long without even being assigned.
When someone owning bugs leaves a team, he (or his manager) mass-assigns his bugs to a special management account specifically for the purpose. When someone new comes in or someone else is assigned a package to maintain, management then assigns that person bugs from the special account. Been there, done that.
I know there are other ways bugs can slip through the cracks. I've probably committed a few of them myself. Good management processes minimize that sort of thing.
Charles Curley:
And another thought, Rahul: maintainers can ignore bugzilla entries same as they can emails. I've had one bug (189120) oustanding since 2006-04-17, and no-one has yet taken ownership, never mind actually done anything about it.
Todd Zullinger:
That is certainly true. Just because someone maintains a package doesn't mean that they do it well. Having things in bugzilla though makes it easier to find those lax maintainers and give them the help (or kick) that they need. Other folks can run reports on bugzilla to find which maintainers have been unresponsive to bugs. Then, if it's appropriate, there's the AWOL maintainer process for those folks that just stop responding to bugs/updates/needed changes in their packages.
Third parties do read bugzilla entries, sometimes trying to solve their own problems, rather than use the mailing lists (full of other stuff, that they're not interested in). You'll even see patches supplied, from time to time, as well as other solutions.
On Sun, 2007-08-26 at 05:22 -0600, Charles Curley wrote:
On Sun, Aug 26, 2007 at 03:09:58AM +0530, Rahul Sundaram wrote:
Charles Curley wrote:
On Sat, Aug 25, 2007 at 03:06:08PM -0600, Charles Curley wrote:
On Sat, Aug 25, 2007 at 01:49:51PM -0600, Charles Curley wrote:
On Fri, Aug 24, 2007 at 11:53:11AM +0930, Tim wrote:
On Thu, 2007-08-23 at 14:10 -0600, Charles Curley wrote: >I just installed mantis (mantis-1.0.8-1.fc7.noarch et al.). I turned
It took me under an hour to install from tarball and set up several accounts, projects, etc.
Oh, and in the process of doing so I found out that the RPM is missing a dependency: php-mysql, which pulls in php-pdo.
Do file a bug report.
No, Rahul, I will not follow a bug report, for two reasons.
If the maintainer is not already aware of the problem from reading this thread, then he doesn't give enough of a damn for me to spend any more time on it.
The package is so pathetically broken (see earlier in this thread) that the lack of the php-mysql package is irrelevant, another reason to believe that the maintainer doesn't give a damn.
Your signature says that you do fine software and writing? I find this a bit hard to believe given your comments above.
Regards, Les H
On Sat, 2007-08-25 at 13:49 -0600, Charles Curley wrote:
<Directory /usr/share/mantis> # As passwords will be sent over the line do not allow plaintext # communication SSLRequireSSL
Have you got SSL set up? The above requirement refuses non HTTPS access to this directory (i.e. HTTP won't work, it'll have to be HTTPS). So you'll need to have HTTPS access working, which is a separate configuration.
e.g. Does https://localhost.localdomain/ work? (Ignoring Mantis, for the moment.)
You can expect a warning about the certificate not being trustworthy, as it's not signed by any endorsed body. But after that step (the warning, and temporarily accepting it), can you get a webpage?
-
Aaron Konstam -
Charles Curley -
Howard Howell -
Rahul Sundaram -
Tim -
Todd Zullinger