Bug#683138: [Pkg-nagios-devel] Bug#683138: Bug#683138: pnp4nagios-web:, crashes immediately due to debian/patches/adjust-template-path
Hi Sebastian, in August, you wrote: Anyway, since the patch is fairly trivial, I'll try to get it into Wheezy -- after all, there might be other architectures / setups that would cause this problem as well. Judging from the current state of the bug report, nothing has happened since. As this is a release-critical bug, is there any way we can help you to get the bug fixed and closed? Kind Regards, Stefan Baur (speaking as part of the Debian Bug Squashing Party taking place at the Linuxhotel, Essen, Germany this weekend) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#683138: [Pkg-nagios-devel] Bug#683138: Bug#683138: pnp4nagios-web: crashes immediately due to debian/patches/adjust-template-path
On Fri, 03 Aug 2012 10:34:08 +0200, Sebastian Harl wrote:
> > So I did some debugging:
> > If the dir has no subdirs:
> > php -r 'var_dump(glob("/etc/pnp4nagios/templates.d/*", GLOB_ONLYDIR));'
> > PHP Warning: PHP Startup: Unable to load dynamic library
> > '/usr/lib/php5/20100525/suhosin.so' - /usr/lib/php5/20100525/suhosin.so:
> > cannot open shared object file: No such file or directory in Unknown on
> > line 0
> > bool(false)
As expected, this works fine on a (pure) wheezy system:
% mkdir /tmp/foo
% php -r 'var_dump(glob("/tmp/foo/*", GLOB_ONLYDIR));'
array(0) {
}
> > So I guess the problem is that my PHP doesn't return an empty array but
> > false, which is also documented to be the case on "some systems":
> > http://php.net/manual/en/function.glob.php
> Right. I suppose PHP uses the glob(3) function from libc, so you're
> "mixed" setup might cause that problem. I fully agree that this should
> be fixed, but the question is if this bug is to be considered RC.
I'm a bit skeptical, too ...
> Anyway, since the patch is fairly trivial, I'll try to get it into
> Wheezy -- after all, there might be other architectures / setups that
> would cause this problem as well.
Doesn't seem to have happened yet :)
Cheers,
gregor
--
.''`. Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
: :' : Debian GNU/Linux user, admin, and developer - http://www.debian.org/
`. `' Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
`- NP: Didier Squiban: Suite de gavottes des montagnes
signature.asc
Description: Digital signature
Bug#683138: [Pkg-nagios-devel] Bug#683138: Bug#683138: pnp4nagios-web: crashes immediately due to debian/patches/adjust-template-path
Hi Sebastian. I just came to wonder,... what is the template.d actually good for? Isn't it the same what we already have with /etc/template ? And even if you planned /etc/template.d as "for use by other packages only", we have some issues left: - we'd need the same for the check_commands dir, and the special templates dir - nothing actually prevents users from using /etc/template.d nevertheless, which means one could still get into troubles, when other packages actually put something there e.g. the apache packages have similar directories (e.g. sites-available, mods-available, etc.), where packages (but also users) put their snippets into. They do not specially try to avoid conflicts between a users personal files and name-collision by files from other debian packages. If that's your concern, than this is actually a much bigger problem in Debian, which affects not only config files of so many packages, but also things like user/group names. Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Bug#683138: [Pkg-nagios-devel] Bug#683138: Bug#683138: pnp4nagios-web: crashes immediately due to debian/patches/adjust-template-path
On Fri, 2012-08-03 at 10:34 +0200, Sebastian Harl wrote: > >> I cannot reproduce this behavior. > > Hmm... and you had a clean fresh installation? > No. But your template.d dir was empty? > So, I suppose, you're still using libc from Squeeze, right? Yes... I can't tell easily if this changes the behaviour of PHP's glob()... that's a production system and I simply upgrade libc for a test... > > But the open_basedir includes /etc/pnp4nagios so that shouldn't be > > aproblem. > Well, I suppose that it would not work either way if that was the > problem ;-) Yep. > Right. I suppose PHP uses the glob(3) function from libc, so you're > "mixed" setup might cause that problem. I fully agree that this should > be fixed, but the question is if this bug is to be considered RC. No I guess not... I'm not even sure whether this justifies the need for a breaks or something like this. I mean I'm fully aware that this mixed setup is not officially supported ... but it may reveal problem with dependencies that could hit people during ugpgrades... not in that case it's not really problematic... because it would be only a short "failure" of PNP4nagios-web during the upgrade. > Anyway, since the patch is fairly trivial, I'll try to get it into > Wheezy -- after all, there might be other architectures / setups that > would cause this problem as well. Great! Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Bug#683138: [Pkg-nagios-devel] Bug#683138: Bug#683138: pnp4nagios-web: crashes immediately due to debian/patches/adjust-template-path
Hi,
On Thu, Aug 02, 2012 at 03:24:23AM +0200, Christoph Anton Mitterer wrote:
> Am 01.08.2012 13:50, schrieb Sebastian Harl:
>> I cannot reproduce this behavior.
> Hmm... and you had a clean fresh installation?
No.
>> Which version of PHP do you use?
> 5.4.4-2
That's the same I used for testing this.
>> What
>> architecture are you on?
> amd64
>
>> I've tested on amd64 Sid … any other ideas how
>> your system might be different from mine?
> Well the base system is stable, but anything pnp4nagios depends on
> (especially PHP) is from testing.
So, I suppose, you're still using libc from Squeeze, right?
> I run PHP as CGI have some limitations in place, well actually just
> open_basedir ... as suhosin is non-functiona ATM.
> But the open_basedir includes /etc/pnp4nagios so that shouldn't be
> aproblem.
Well, I suppose that it would not work either way if that was the
problem ;-)
> So I did some debugging:
> If the dir has no subdirs:
> php -r 'var_dump(glob("/etc/pnp4nagios/templates.d/*", GLOB_ONLYDIR));'
> PHP Warning: PHP Startup: Unable to load dynamic library
> '/usr/lib/php5/20100525/suhosin.so' - /usr/lib/php5/20100525/suhosin.so:
> cannot open shared object file: No such file or directory in Unknown on
> line 0
> bool(false)
>
>
> If it has:
> php -r 'var_dump(glob("/etc/pnp4nagios/templates.d/*", GLOB_ONLYDIR));'
> PHP Warning: PHP Startup: Unable to load dynamic library
> '/usr/lib/php5/20100525/suhosin.so' - /usr/lib/php5/20100525/suhosin.so:
> cannot open shared object file: No such file or directory in Unknown on
> line 0
> array(3) {
> [0]=>
> string(29) "/etc/pnp4nagios/templates.d/a"
> [1]=>
> string(29) "/etc/pnp4nagios/templates.d/b"
> [2]=>
> string(29) "/etc/pnp4nagios/templates.d/c"
> }
>
>
> You can ignore the Suhosin missing warning.
>
> So I guess the problem is that my PHP doesn't return an empty array but
> false, which is also documented to be the case on "some systems":
> http://php.net/manual/en/function.glob.php
Right. I suppose PHP uses the glob(3) function from libc, so you're
"mixed" setup might cause that problem. I fully agree that this should
be fixed, but the question is if this bug is to be considered RC.
Anyway, since the patch is fairly trivial, I'll try to get it into
Wheezy -- after all, there might be other architectures / setups that
would cause this problem as well.
Cheers,
Sebastian
--
Sebastian "tokkee" Harl +++ GnuPG-ID: 0x8501C7FC +++ http://tokkee.org/
Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin
signature.asc
Description: Digital signature
