Bug#954128: munin-node: timeout in init script too short

[Steve Schnepp]

On Wed, Mar 18, 2020 at 5:22 PM Holger Levsen  wrote:

> yes, sure, so let me rephrase: why not 5min for the default timeout?

That's a question that you should send to the systemd team, as simplicity
advocates we use theirs ;-)

-- 
Steve Schnepp
http://blog.pwkf.org/tag/munin

Bug#954128: munin-node: timeout in init script too short

[Steve Schnepp]

On Wed, Mar 18, 2020 at 3:39 PM Holger Levsen  wrote:
> why not 5min?

It is the delay for munin-node *startup*, not during runtime execution of
plugins.
Therefore, simplicity would be to just use the default timeout.

--
Steve Schnepp

Bug#921985: munin-node: df plugin fails to get data for /home

[Steve Schnepp]

On Wed, Feb 20, 2019 at 2:51 PM Marc Donges  wrote:

> So although I would change this on machines I run, simply because I need
> to know when /home is almost full, I understand that a default install
> would not allow that.
>

I might be naive, but I'm wondering if some debconf dialog to choose at
install time might be an option.
As your use case is a valid one indeed. But I would rather ship a
secure-by-default configuration.

I don't think a scenario of "evil plugins" is relevant, a sysadmin just
> should not use questionable software.


Protection against "evil plugins" isn't done easily, but we should aim to
fool-proof against "buggy" plugins.
I agree that we cannot do everything, but if it catches 80% of the
mistakes, it feels a good idea.

-- 
Steve Schnepp
http://blog.pwkf.org/tag/munin

Bug#921985: munin-node: df plugin fails to get data for /home

[Steve Schnepp]

On Sat, 16 Feb 2019 16:39 Marc Donges  However, a separate /home is a common configuration and this problem can
> easily be overlooked and is then not trivial to find, because there are no
> error messages anywhere, there is just this odd difference in reality
> between munin-node as a daemon and everything else the sysadmin does
> manually on the CLI.
>

Here the issue feels much more in munin-run not being the same as
munin-node.

That systemd configuration is new from stretch IMHO, but I think it is for
the better nowadays.

I think to make this less awkward two things would be nice:
>

That said, I agree that we should make it more obvious.

- a option to allow monitoring of /home without editing a non-conffile in
> /lib (How is this even done properly? I just edited the service file to
> find the cause of my problem, but I suppose it will be overwritten on every
> update. Is there a nice way to do this?)
>

You can always copy the file into /etc, it will then take precedence

- a way to alert the admin of the possibly unintended configuration:
> df-plugin activated + ProtectHome + Separate /home
>

This can be done inside the munin-run environment, and not only for the df
plugin.

Can the df* plugin itself detect the situation and then make a log entry?
> That would have severely cut down the time it took me to find this.
>

I have to see if the df plugin does know about it, as I'm not sure it can
detect it reliably.

-- 
Steve Schnepp

>

Bug#913481: Acknowledgement ("setup" produces unusable swapfiles)

[Steve Schnepp]

Seems that the issue is due to a Debian-specific patch:
https://sources.debian.org/src/dphys-swapfile/20100506-5/debian/patches/fallocate.patch/

That patch status is :
Forwarded: yes (but rejected)

--
Steve Schnepp

Bug#913481: "setup" produces unusable swapfiles

[Steve Schnepp]

Package: dphys-swapfile
Version: 20100506-3
Severity: important

The setup subcommand uses fallocate(1) which sometimes creates spare
files. Those cannot be used for swapfiles as "swapon" will fail with
"swapfile has holes".

Always using dd instead of fallocate seems better as it ensures the
generated swapfile is valid. The fact that it takes more time than
fallocate is also a good thing, since it done synchronously.

Offending part:

  # use fallocate if found to create swapfile, else use dd
  type fallocate > /dev/null
  if [ $? -eq 0 ]; then
fallocate -l "${CONF_SWAPSIZE}"M "${CONF_SWAPFILE}" 2> /dev/null
  else
dd if=/dev/zero of="${CONF_SWAPFILE}" bs=1048576 \
  count="${CONF_SWAPSIZE}" 2> /dev/null
  fi

Notes:
* this bug is subtly different from #906767.
* I'm using f2fs a the root fs
* There is enough space left

--
Steve Schnepp

"A man is not dead while his name is still spoken."
-- T. Pratchett - Going Postal, Chapter 4 prologue

Bug#863231: [Packaging] Bug#863231: munin-plugins-core: apt_all uses different statefiles for reading and writing

[Steve Schnepp]

On Sat, 23 Jun 2018 02:51 Lars Kruse,  wrote:

> Otherwise we will run apt_all as
> root (as suggested above).
>

That would be the obvious fix, as we do not mix statefiles from different
users in the same directory for security purposes.

It is much easier to secure a whole directory than individual files.

That said, the cronjob could also be tweaked to use the "nobody" directory
as it runs as root, but it might be counterintuitive as where the state is
written.

Steve Schnepp

Bug#860879: [Packaging] Bug#860879: munin-httpd needs libo-string-perl and libhttp-server-simple-cgi-prefork-perl

[Steve Schnepp]

Hi all,

Thanks for the bug report & its handling.

Note that I do maintain a rough dependency manager directly in the munin
code in the form of a shell script : dev_scripts/deps [1]

It has 2 main issues :
* It isn't complete (as it didn't contain
libhttp-server-simple-cgi-prefork-perl) but I can maintain it more
accurately if needed
* It is aimed at build dependencies of the master, and it therefore wider
than the binary package

[1] https://github.com/munin-monitoring/munin/blob/master/dev_scripts/deps

Bug#856455: munin: Zooming doesn't work

[Steve Schnepp]

On Mar 1, 2017 10:56 AM, "Steve Schnepp" <steve.schn...@gmail.com> wrote:

Hmmm... Seems the sec fix is faulty here.
The "if defined" should be replaced with a simple "if".


Actually that is not enough as introduces another, more subtle, bug :

you cannot force any value to 0 anymore.

I admit is it better than the 2 previous states but i cannot advocate to
deploy it.

Will emit a fix today :-(


Actually that still holds, as some more testing is being done.

Bug#856455: munin: Zooming doesn't work

[Steve Schnepp]

Hmmm... Seems the sec fix is faulty here.
The "if defined" should be replaced with a simple "if".

Will emit a fix today :-(


On Wed, Mar 1, 2017 at 9:30 AM Christian Marillat 
wrote:

Package: munin
Version: 2.0.31-1
Severity: important

Dear Maintainer,

I don't know since when but zooming in graph doesn't work.

Apparently the guilty in an empty value for --upper-limit

I see in /var/log/munin/munin-cgi-graph.log

2017/03/01 09:16:21 [WARNING] Could not draw graph
"/var/lib/munin/cgi-tmp/munin-cgi-graph/
marillat.net/karl.marillat.net/diskstats_iops/mmcblk0-pinpoint=1485504486,1488355686.png?_limit=_limit=_x=800_y=400":
/var/lib/munin/cgi-tmp/munin-cgi-graph/
marillat.net/karl.marillat.net/diskstats_iops/mmcblk0-pinpoint=1485504486,1488355686.png?_limit=_limit=_x=800_y=400
2017/03/01

09:20:23 [RRD ERROR] Unable to graph /var/lib/munin/cgi-tmp/munin-cgi-graph/
marillat.net/karl.marillat.net/diskstats_iops/mmcblk0-pinpoint=1488247686,1488355686.png?_limit=_limit=_x=800_y=400
: option -u - Cannot convert '' to float
2017/03/01 09:20:23 [RRD ERROR] rrdtool 'graph'
'/var/lib/munin/cgi-tmp/munin-cgi-graph/
marillat.net/karl.marillat.net/diskstats_iops/mmcblk0-pinpoint=1488247686,1488355686.png?_limit=_limit=_x=800_y=400'
\
'--title' \
'IOs for /dev/mmcblk0 - from Tue Feb 28 03:08:06 2017 to Wed Mar  1
09:08:06 2017' \
'--start' \
'1488247686' \
'--end' \
'1488355686' \
'--base' \
'1000' \
'--vertical-label' \
'Units read (-) / write (+)' \
'--slope-mode' \
'--height' \
'400' \
'--width' \
'800' \
'--rigid' \
'--imgformat' \
'PNG' \
'--font' \
'DEFAULT:0:DejaVuSans,DejaVu Sans,DejaVu LGC Sans,Bitstream Vera
Sans' \
'--font' \
'LEGEND:7:DejaVuSansMono,DejaVu Sans Mono,DejaVu LGC Sans
Mono,Bitstream Vera Sans Mono,monospace' \
'--color' \
'BACK#F0F0F0' \
'--color' \
'FRAME#F0F0F0' \
'--color' \
'CANVAS#FF' \
'--color' \
'FONT#66' \
'--color' \
'AXIS#CFD6F8' \
'--color' \
'ARROW#CFD6F8' \
'--border' \
'0' \
'-W' \
'Munin 2.0.31-1' \
'DEF:aavgwrrqsz=/var/lib/munin/
marillat.net/karl.marillat.net-diskstats_iops-mmcblk0-avgwrrqsz-g.rrd:42:MAX'
\
'DEF:iavgwrrqsz=/var/lib/munin/
marillat.net/karl.marillat.net-diskstats_iops-mmcblk0-avgwrrqsz-g.rrd:42:MIN'
\
'DEF:gavgwrrqsz=/var/lib/munin/
marillat.net/karl.marillat.net-diskstats_iops-mmcblk0-avgwrrqsz-g.rrd:42:AVERAGE'
\
'DEF:aavgrdrqsz=/var/lib/munin/
marillat.net/karl.marillat.net-diskstats_iops-mmcblk0-avgrdrqsz-g.rrd:42:MAX'
\
'DEF:iavgrdrqsz=/var/lib/munin/
marillat.net/karl.marillat.net-diskstats_iops-mmcblk0-avgrdrqsz-g.rrd:42:MIN'
\
'DEF:gavgrdrqsz=/var/lib/munin/
marillat.net/karl.marillat.net-diskstats_iops-mmcblk0-avgrdrqsz-g.rrd:42:AVERAGE'
\
'DEF:awrio=/var/lib/munin/
marillat.net/karl.marillat.net-diskstats_iops-mmcblk0-wrio-g.rrd:42:MAX' \
'DEF:iwrio=/var/lib/munin/
marillat.net/karl.marillat.net-diskstats_iops-mmcblk0-wrio-g.rrd:42:MIN' \
'DEF:gwrio=/var/lib/munin/
marillat.net/karl.marillat.net-diskstats_iops-mmcblk0-wrio-g.rrd:42:AVERAGE'
\
'DEF:ardio=/var/lib/munin/
marillat.net/karl.marillat.net-diskstats_iops-mmcblk0-rdio-g.rrd:42:MAX' \
'DEF:irdio=/var/lib/munin/
marillat.net/karl.marillat.net-diskstats_iops-mmcblk0-rdio-g.rrd:42:MIN' \
'DEF:grdio=/var/lib/munin/
marillat.net/karl.marillat.net-diskstats_iops-mmcblk0-rdio-g.rrd:42:AVERAGE'
\
'CDEF:crdio=grdio' \
'CDEF:cwrio=gwrio' \
'COMMENT: ' \
'COMMENT:Cur (-/+)' \
'COMMENT:Min (-/+)' \
'COMMENT:Avg (-/+)' \
'COMMENT:Max (-/+) \j' \
'LINE1:gwrio#00CC00:IO/sec' \
'GPRINT:crdio:LAST:%6.2lf%s/\g' \
'GPRINT:cwrio:LAST:%6.2lf%s' \
'GPRINT:irdio:MIN:%6.2lf%s/\g' \
'GPRINT:iwrio:MIN:%6.2lf%s' \
'GPRINT:grdio:AVERAGE:%6.2lf%s/\g' \
'GPRINT:gwrio:AVERAGE:%6.2lf%s' \
'GPRINT:ardio:MAX:%6.2lf%s/\g' \
'GPRINT:awrio:MAX:%6.2lf%s\j' \
'CDEF:cavgrdrqsz=gavgrdrqsz' \
'CDEF:cavgwrrqsz=gavgwrrqsz' \
'LINE1:gavgwrrqsz#0066B3:Req Size (KB) ' \
'GPRINT:cavgrdrqsz:LAST:%6.2lf%s/\g' \
'GPRINT:cavgwrrqsz:LAST:%6.2lf%s' \
'GPRINT:iavgrdrqsz:MIN:%6.2lf%s/\g' \
'GPRINT:iavgwrrqsz:MIN:%6.2lf%s' \
'GPRINT:gavgrdrqsz:AVERAGE:%6.2lf%s/\g' \
'GPRINT:gavgwrrqsz:AVERAGE:%6.2lf%s' \
'GPRINT:aavgrdrqsz:MAX:%6.2lf%s/\g' \
'GPRINT:aavgwrrqsz:MAX:%6.2lf%s\j' \
'CDEF:re_zero=grdio,UN,0,0,IF' \
'CDEF:ngrdio=grdio,-1,*' \

Bug#855705: [Packaging] Bug#855705: munin-cgi-graph local file write vulnerability

[Steve Schnepp]

On Feb 23, 2017 11:52 AM, "Holger Levsen"  wrote:


tomorrow, or at least until upstream (cc:ed) has confirmed this is the
right patch?


The patch is indeed quite minimal, and address the issue. It therefore
looks very ok to me.

Note that I did not plan to take it as is, but use the 2.999.x code snippet
instead which doesn't have the bug.

I'll plan to do a secfix upstream release tomorrow so you'll have the
choice of which patch you take ;-)

Thanks !
-- 
Steve

Bug#852350: RFP: libhttp-server-simple-cgi-prefork-perl -- SSL and Prefork for HTTP::Server::Simple::CGI

[Steve Schnepp]

Package: wnpp
Severity: wishlist

* Package name: libhttp-server-simple-cgi-prefork-perl
  Version : 6
  Upstream Author : Rene Schickbauer 
* URL :
http://search.cpan.org/~cavac/HTTP-Server-Simple-CGI-PreFork-6/
* License : Perl
  Programming Lang: Perl
  Description : SSL and Prefork for HTTP::Server::Simple::CGI


Are you using HTTP::Server::Simple::CGI (or are you planning to)? But you
want
to handle multiple connections at once and even try out this SSL thingy
everyone is using these days?

Fear not, the (brilliant) HTTP::Server::Simple::CGI is easy to extend and
this
(only modestly well-designed) module does it for you.

HTTP::Server::Simple::CGI::PreFork should be fully IPv6 compliant.

Bug#772277: [Packaging] Bug#772277: munin-async: bashism in /bin/sh script

[Steve Schnepp]

Hi Holger  Raphael,

On Sat, Dec 6, 2014 at 2:48 PM, Holger Levsen hol...@layer-acht.org wrote:
 it seems to me this is a bashism which is understood by dash

I do agree that it works with dash, but then one can (should) argue
that the check should not emit any warning if there is nothing wrong.

So, either :

1. update that check, since it isn't a real bashism in the sense of
not dash.
2. update the script to sleep a whole second
3. update the script to use /bin/sleep, of the coreutils package.

Option 1. is not very realistic IMHO, so either the 3. which would
conserve the feature asis, or 2. which would not introduce an extra
dependency.

That said, a dependency to coreutils might not be very demanding.

 do you agree we can thus downgrade this bug to normal?

In any case, I also really think it's a normal bug, not a serious
one : due to the fact that it does works with dash.

-- 
Steve Schnepp
http://blog.pwkf.org/


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#711465: merged but where is it?

[Steve Schnepp]

On Thu, Sep 18, 2014 at 1:39 PM, Holger Levsen hol...@layer-acht.org wrote:
 But I can neither find it in the devel nor stable-2.0 branch

According to git tag --contains, it is in 2.1.3+.

  I do think thats a nice candidate for 2.0.22

It just made it to stable-2.0 as 0d7505fb4fdf9f15a0815aa682f56de0ee1247e3
(cherry-picked from 91a9e62).

--
Steve Schnepp
http://blog.pwkf.org/tag/munin


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#762796: munin: Undefined subroutine main::header

[Steve Schnepp]

For easy reference, I just copy/paste here the reply of the thread here :

-
I will leave it to those more familiar with munin's codebase to respond
in full, but just a hunch: do you have the separate libcgi-pm-perl
package installed? CGI.pm, is deprecated from perl 5.20, and
we're now shipping libcgi-fast-perl from a different source package,
either of which change might have plausibly caused this change.

Cheers,
Dominic (Debian perl co-maintainer).
-

I do agree with Dominic, as we use several CGI.pm features as they
were automatically imported by CGI::Fast.
I'm still looking on how I should update upstream's code to be
natively compatible with perl5.20+.

@maintainers: You might need to add the libcgi-pm-perl package to Depends:

--
Steve Schnepp
http://blog.pwkf.org/tag/munin


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#761648: what should it do then?

[Steve Schnepp]

On Thu, Sep 18, 2014 at 9:40 PM, Joerg Jaspert jo...@debian.org wrote:

 Looks like failure is the sanest option.

 I don't think it's sanest. It's easiest, yes. But the failure here is

Holger, you might have misread the bug. To me, ignoring the faulty
file for static stuff seems a sane default indeed.

Besides, stopping meanwhile updating the generated files isn't good
either, as the end user has then not many clues of what was wrong. And
users do _not_ read log files. It's very sad, but it's a fact :-).

So, I guess for static stuff I could change the default to the good
old VB On Error Resume Next.
And for the templates stuff, I think any error could be written in the
output file, in a big fat red font. But in the expected place, so the
user has a change to see it.

That said, the way it works currently has also its adepts. Mostly
because a silent failure is sometimes better than a loudly one.
Specially for tech-sawy users, or for transient ones.

The last behavior should then be optional. The default is still to be
decided, but I usually favor ease-of-use for a newbie, so the red
warning has my personal preference.

--
Steve Schnepp
http://blog.pwkf.org/tag/munin


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#761190: apt_all and system wide APT configuration options

[Steve Schnepp]

On Thu, Sep 11, 2014 at 4:55 PM, I. Schrey s...@schreyben.de wrote:
 So, I'd like to request a new feature for apt_all:
 to mask potentially harmful system wide APT options like the ones above

I can add an extra_args config variable to the plugin as
https://github.com/munin-monitoring/munin/pull/252

Would that solve your issue ?

--
Steve Schnepp
http://blog.pwkf.org/tag/munin


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#696981: munin: Cron job warn about not a reference at /usr/share/perl5/Munin/Master/Utils.pm line 908

[Steve Schnepp]

Oh.

Looking at your config file, it seems the munin package fails to
automatically setup the local node.
Then, since there is no node that is successfully polled, it emits
this log message.

Is the Debian Edu configuration phase different from a vanilla
Debian install ?

Btw, I admit that the message could be much more user-friendly.

--
Steve Schnepp
http://blog.pwkf.org/tag/munin


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#696981: munin: Cron job warn about not a reference at /usr/share/perl5/Munin/Master/Utils.pm line 908

[Steve Schnepp]

This bug has popped up also seemingly randomly on fresh install of other
distrib.

It was always caused by no node being configured, or more exactly the
single node being incorrectly configured.

There was a mismatch between the naming config of the node in the master
and in the node (which usually are both on the same host when this triggers)

Could you check if that's the case in your install ?

-- 
Steve Schnepp
Le 20 août 2014 23:27, Petter Reinholdtsen p...@hungry.com a écrit :


 Control: found -1 2.0.21-2

 [Petter Reinholdtsen]
  Perhaps you can reproduce it using the Debian Edu Wheezy test
  installation?  I installed using Norwegian Bokmål and Main-Server +
  Workstation as the profile.  The ISO is available via rsync from
 
ftp.skolelinux.org:
 :cd-edu-testing-nolocal-netinst/debian-edu-amd64-i386-NETINST-1.iso

 I'm testing Debian Edu Jessie these days, and noticed that when
 installing the Main-Server profile, this munin issue is yet again
 filling up the mail box for root.  The trigger is probably that the
 sitesummary collector system is not yet working, so the machine itself
 is not registered in sitesummary and thus the munin configuration
 generated from sitesummary data is empty.

 Just mentioning it here in case you want to test it yourself.  Note that
 the Main Server installation is not yet without hickups.  See
 URL: https://lists.debian.org/debian-edu/2014/08/msg00061.html  for
 hints on how to work around them until we have weeded out the problems.

 Note, the current message is not a reference at
 /usr/share/perl5/Munin/Master/Utils.pm line 863. :)

 --
 Happy hacking
 Petter Reinholdtsen

Bug#742203: munin-cgi-graph stops using an non-default cgitmpdir after a while

[Steve Schnepp]

Package: munin
Version: 2.0.6-4+deb7u2
Control: forward -1 http://munin-monitoring.org/ticket/1289
Control: fixed -1 2.0.10-1
done

As helmut noted on IRC:

 is there possibly a bug in the handling of the cgitmpdir configuration for 
 fastcgi?
 it appears to reset to the default in some fastcgi worker proceses 
 occasionally.
 the problem vanishes on /etc/init.d/apache2 reload

The bug is already fixed upstream in
6d62e6b0782ecfa0f4e0c2bec14434d675734962, which is in 2.0.10.

--
Steve Schnepp
http://blog.pwkf.org/tag/munin


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#742203: Fix the issue for the 2.0.6 branch.

[Steve Schnepp]

Note that ac48315 does fix the issue for the 2.0.6 branch.

[ac48315] 
http://munin-monitoring.org/changeset/ac4831527d1bf3344936a4039b1fbf95337f0352/munin-dev

--
Steve Schnepp
http://blog.pwkf.org/


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#732462: munin-node: unowned directories after purge: /var/lib/munin-node/plugin-state/{munin, nobody, root}/

[Steve Schnepp]

Matthias,

On Wed, Dec 18, 2013 at 2:21 PM, Matthias Schmitz matth...@sigxcpu.org wrote:

 How should we deal with this data? When purging 'munin' we don't delete
 the rrd files. But the statefiles are not this important should we
 simply delete them at purge?

Yes, I recommend to take a similar policy to database packages :

- rrd  meta-data (/var/lib/munin/**) should be treated like DB data :
only removed manually
- munin  plugin configuration (/etc/munin/**) should be treated like
DB engine config : removed on purge
- plugin states (/var/lib/munin-node/plugin-state/**) should also be
treated like DB engine config : removed on purge
- anything else should be treated like DB engine : removed on remove.

The idea is to avoid removing data that has a value, and data that
remains should remains usable (ie: with its metadata).

Removing plugin state should not be automatic, but not retained at all
costs, as one expects a clean reinstall after purge, specially on a
node.

Regards,
--
Steve Schnepp
http://blog.pwkf.org/tag/munin


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#678430: the debian package does override the exclude environment var for the df* plugins

[Steve Schnepp]

Note that the debian package does override the exclude environment
var for the df* plugins.

The rootfs was added to the exclude list in
b5bfc55abf7e5bef61731f970164f5f7fa398402, due to upstream ticket #1120
[1].

The net effect of the override is that upstream changes in plugin
defaults are not correctly propagated.

[1] http://mm0.eu/1120

--
Steve Schnepp
http://blog.pwkf.org/tag/munin


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#728840: munin-plugins-extra: ipmi_sensor_ doesn't properly import os

[Steve Schnepp]

Le 6 nov. 2013 21:33, Gabriel Filion gabs...@lelutin.ca a écrit :
 that's quite okay to fix it that way. however, please note that
 environ was not imported from os before, so I would expect this to
 fail as well:

Ooops. Well it was handled by the commit fixing #686982, I guess I
rebased my patch a little too early.

Anyway, the code should be correct if you merge the patch in the debian
2.0.6 branch. If not, just also add the commit of the other bug.

(I'll try to check that later)

Bug#728840: munin-plugins-extra: ipmi_sensor_ doesn't properly import os

[Steve Schnepp]

tags 728840 + upstream fixed-upstream
done

On Wed, Nov 6, 2013 at 6:06 AM, Gabriel Filion gabs...@lelutin.ca wrote:
 simple fix would be to add a line import os before line 73 like this:

Thx.

Note that I just fixed [1] the offending call instead in
e9e9f6b63c08d6e8c98ed8d518fdfab5320c.

[1] http://mm0.eu/e9e9f6
-- 
Steve


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#715141: apt_all update cronjob creates error mails when testing and unstable are not in the apt sources

[Steve Schnepp]

Le 3 sept. 2013 03:15, DUVERGIER Claude claude@duvergier.fr a
écrit :

 But sadly munin-run don't push the extra 7200 and 12 parameters to
the apt_all

Looking closely, that was done specifically like that. But it sounds wrong
to me, and qualifies as a bug. Will be fixed in the next upstream stable
release.

The extra $ARGV will be transparently given to the plugin, as the config
or update is already.

which in turns only has update in it's $ARGV and sees it as an error and
display the helping usage text:

 I'm not sure how this could be easily solved.

Well, as it's an upstream issue, it will be solved upstream :)

Bug#720275: [Packaging] Bug#720275: Bug#720275: munin-plugins-core: crontab for apt and apt_all plugins missing MUNIN_PLUGSTATE=/var/lib/munin-node/plugin-state/root

[Steve Schnepp]

Le 24 août 2013 15:49, Stig Sandbeck Mathisen s...@debian.org a écrit :

 Holger Levsen hol...@layer-acht.org writes:

  Steve: I believe this fix is suboptimal, wouldnt it be better if the
  plugin used a sane default even if called directly? (without munin-run
  as the cronjob calls it, which might be another error.)

 I think the cronjob should use munin-run to run a plugin.

I cannot agree more. Noone shall run the plugins directly.

Thinking about it, maybe even disallow running outside munin-run, for core
plugins.

Particularly
 if it depends on environment variables being set

And state files, perms, 

Bug#717265: munin-plugins-extra - haproxy_ - Use of uninitialized value

[Steve Schnepp]

Fixed upstream in 57ed226762d57b13665f37e89610dfa6b5ac500d.

Steve
Le 18 juil. 2013 17:21, Stelio Plautz ste...@sphome.net a écrit :


 Package: munin-plugins-extra
 Version: 2.0.6-4+deb7u1  2.0.16-2~bpo70+1



 Dear Maintainer,



 I found the following error in my log file:

 2013/07/18-16:40:28 [14972] Name 
 Munin::Common::Defaults::**MUNIN_VERSION
 used only once: possible typo at /etc/munin/plugins/haproxy_**backend
 line 64.
 2013/07/18-16:40:28 [14972] Use of uninitialized value
 $Munin::Common::Defaults::**MUNIN_VERSION in sprintf at
 /etc/munin/plugins/haproxy_**backend line 63.
 2013/07/18-16:40:29 [14972] Error output from haproxy_backend:
 2013/07/18-16:40:29 [14972] Name 
 Munin::Common::Defaults::**MUNIN_VERSION
 used only once: possible typo at /etc/munin/plugins/haproxy_**backend
 line 64.
 2013/07/18-16:40:29 [14972] Use of uninitialized value
 $Munin::Common::Defaults::**MUNIN_VERSION in sprintf at
 /etc/munin/plugins/haproxy_**backend line 63.

 please add:
 use Munin::Common::Defaults;




 Regards ,

 stelio

Bug#712793: df_ abs lists some filesystems twice

[Steve Schnepp]

Package: munin-plugins-core
Version: 2.0.6-4+deb7u1

 weasel the df_ abs plugin doesn't work very well on wheezy
 weasel seems it lists some filesystems twice and counts them twice
for total too

See attached img.

--
Steve Schnepp
http://blog.pwkf.org/tag/munin
attachment: df_abs-month.png

Bug#711272: closed by Stig Sandbeck Mathisen s...@debian.org (Re: [Packaging] Bug#711272: Bug#711272: munin should depend libcgi-fast-perl)

[Steve Schnepp]

Le 7 juin 2013 01:08, raylu lur...@gmail.com a écrit :
 libapache2-mod-fcgid only works for apache2; those of us running some
 other httpd still need libcgi-fast-perl.

Actually, libcgi-fast-perl is a Perl CPAN lib to be inside a fastcgi
container. So it is needed for any httpd.

I recommend to have it as a Depends, as it should not depend on other
packages, and that enables to switch to CGI without installing more
packages (for munin).

An elegant possibility is the way EPEL did it : via a dedicated munin-cgi
package, that has the correct deps for CGI.

Steve

Bug#710899: tmpfs should be graph IMHO

[Steve Schnepp]

While I tend to agree on rootfs  devtmpfs, I don't on tmpfs.

Monitoring tmpfs is useful as it can  may be used heavily.

-- 
Steve Schnepp
http://blog.pwkf.org/tag/munin

Bug#710899: tmpfs should be graph IMHO

[Steve Schnepp]

Also, rootfs is even already excluded by default since 2.0.0rc2.

Therefore, I commited ab42e8bc77448bf6c1f78b69b8647bce222cd81a to remove
devtmpfs per default.


-- 
Steve Schnepp
http://blog.pwkf.org/tag/munin

Bug#710528: ip_1.2.3.4 behaves sometimes like a subgrouping plugin

[Steve Schnepp]

The bug doesn't appear on all the hosts, just some.

We can see on the screenshot 177 that gabrielli.d.o has the bug, but
geo1.d.o doesn't.
The screenshot 178 show us that it also appears on some host that only
have 1 ip.
--
Steve Schnepp
http://blog.pwkf.org/tag/munin


On Fri, May 31, 2013 at 6:25 PM, Steve Schnepp
steve.schn...@munin-monitoring.org wrote:
 Package: munin
 Version: 2.0.6-4
 Severity: important
 Tags: upstream

 ip_1.2.3.4 behaves sometimes like a subgrouping plugin

 (thx weasel)

 --
 Steve Schnepp
 http://blog.pwkf.org/tag/munin

attachment: screenshot.177.pngattachment: screenshot.178.png

Bug#710528: normal bug

[Steve Schnepp]

Btw, i forgot to add that the PNG that are wrongly classified as
subgrouping do not work.

That's why i opened it as severity important.
--
Steve Schnepp
http://blog.pwkf.org/tag/munin


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#710527: : isn't an accepted char in CGI graphs

[Steve Schnepp]

Package: munin
Version: 2.0.6-4
Severity: important
Tags: upstream

The : char is not accepted in the has_offending_chars() function.
Then the ip_ plugin with an IPv6 address does not work.

--
Steve Schnepp
http://blog.pwkf.org/tag/munin


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#710528: ip_1.2.3.4 behaves sometimes like a subgrouping plugin

[Steve Schnepp]

Package: munin
Version: 2.0.6-4
Severity: important
Tags: upstream

ip_1.2.3.4 behaves sometimes like a subgrouping plugin

(thx weasel)

--
Steve Schnepp
http://blog.pwkf.org/tag/munin


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#710529: Async is not a drop-in for some plugins (like ip_)

[Steve Schnepp]

Package: munin
Version: 2.0.6-4
Severity: important
Tags: upstream

When moving from direct TCP connection to async-based transport, the
rrd backend file changed from ip_2001_1234__1-in-d.rrd to
ip_2001:1234::1-in-d.rrd.

(thx weasel)
--
Steve Schnepp
http://blog.pwkf.org/tag/munin


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#706977: Bug in munin upgrade (aka: perl trigger)

[Steve Schnepp]

Package: munin
Version: 2.0.6-4

As seen on our IRC channel :

17:29 [Freenode]  pacop:#munin Hello, I get this when running munin-cron,
any idea please? Can't locate Log/Log4perl.pm in @INC (@INC contains:
/etc/perl
  /usr/local/lib/perl/5.14.2 /usr/local/share/perl/5.14.2 /usr/lib/perl5
/usr/share/perl5 /usr/lib/perl/5.14 /usr/share/perl/5.14
/usr/local/lib/site_perl .) at
  /usr/share/munin/munin-update line 12.
17:29 [Freenode]  pacop:#munin BEGIN failed--compilation aborted at
/usr/share/munin/munin-update line 12.
17:30 [Freenode]  pacop:#munin I have upgraded to debian wheezy,
17:30 [Freenode]  pacop:#munin but I kept all munin config untocuhed
17:31  Nilshar:#munin try installing liblog-log4perl-perl
17:32 [Freenode]  pacop:#munin solved! it was already install, but I have
solved it with dpkg -r munin liblog-log4perl-perl and then reinstalling them
17:32 [Freenode]  pacop:#munin *thank you!*
17:54  h01ger:#munin thats a hack but not a solutin
17:54  h01ger:#munin munin-cron, perl trigger, there was something
17:54  h01ger:#munin +please file bugs

h01ger, Wish granted.

-- 
Steve Schnepp

Bug#689291: Fixed upstream

[Steve Schnepp]

Fixed upstream in d20222a415d8cf68a922a4d9d23f0643803488ee.

-- 
Steve Schnepp
http://blog.pwkf.org/tag/munin

Bug#699803: Acknowledgement (munin: TLS not working with Munin master v2.0.x)

[Steve Schnepp]

Oh... That was it.

Big thanks on the debug !
Proper fix is on its way, and .12 will follow soonish.

-- 
Steve Schnepp
http://blog.pwkf.org/tag/munin
On Mon, Mar 18, 2013 at 10:28 AM, Eero Häkkinen eer...@bigfoot.com wrote:

 Steve Schnepp wrote on 2013-02-28 14:54:54 +0100:
  I'm looking further on what changed between 1.4  2.0.

 The fetch_service_config method in the file
 /usr/share/perl5/Munin/Master/Node.pm is changed to use the new
 _node_read_fast method which uses sysread for reading from a socket and
 bypasses the TLS layer completely.

 A simple work-a-round to revert the fetch_service_config method to use
 the _node_read method instead of the _node_read_fast method for reading,
 like in the attached patch.

 A proper fix whould probably be to make the _node_read_fast to work with
 TLS connections, too.

Bug#699803: Acknowledgement (munin: TLS not working with Munin master v2.0.x)

[Steve Schnepp]

tag + upstream fixed-upstream
done

It is fixed upstream in 71d0a86 [1].

Thanks guys !

[1]
http://munin-monitoring.org/changeset/71d0a86c2b6f549e265be1718db8b20c227c9235

Steve
Le 21 mars 2013 20:35, Steve Schnepp steve.schn...@munin-monitoring.org
a écrit :

 Oh... That was it.

 Big thanks on the debug !
 Proper fix is on its way, and .12 will follow soonish.

 --
 Steve Schnepp
 http://blog.pwkf.org/tag/munin
 On Mon, Mar 18, 2013 at 10:28 AM, Eero Häkkinen eer...@bigfoot.comwrote:

 Steve Schnepp wrote on 2013-02-28 14:54:54 +0100:
  I'm looking further on what changed between 1.4  2.0.

 The fetch_service_config method in the file
 /usr/share/perl5/Munin/Master/Node.pm is changed to use the new
 _node_read_fast method which uses sysread for reading from a socket and
 bypasses the TLS layer completely.

 A simple work-a-round to revert the fetch_service_config method to use
 the _node_read method instead of the _node_read_fast method for reading,
 like in the attached patch.

 A proper fix whould probably be to make the _node_read_fast to work with
 TLS connections, too.

Bug#699803: Acknowledgement (munin: TLS not working with Munin master v2.0.x)

[Steve Schnepp]

Le 6 févr. 2013 11:21, Christian Schroetter
c_schroet...@froonix.net a écrit :

 Just to confirm this bug on new systems ;-)

I did managed to reproduce the issue. It seems that it's the SSL
handshake (master - node) that is causing the issue... I'm looking
further on what changed between 1.4  2.0.

Did you also upgrade any SSL lib ?

Steve


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#700170: Domain name alias : snapshots.debian.org (plural)

[Steve Schnepp]

Package: snapshot.debian.org
Severity: wishlist

It would be convenient to have a other vhost at snapshots.debian.org than
statically does 301 to the same page at snapshot.debian.org so I don't need
to remember if it is plural or not :)

Steve

Bug#698302: munin_stats: wrong values for munin graph

[Steve Schnepp]

On Wed, Jan 16, 2013 at 5:14 PM, Uwe Storbeck u...@ibr.ch wrote:
 A graph which shows munin processing times before and after the
 upgrade to wheezy is attached.

Thx for the report,

Could you post the 2 following files ?
/var/lib/munin/munin-update.stats
/var/lib/munin/munin-graph.stats

--
Steve Schnepp
http://blog.pwkf.org/tag/munin


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#698079: [Packaging] Bug#698079: munin-plugins-core: Proposed update for check for disabled InnoDB engine in mysql_.in

[Steve Schnepp]

tags 698079 + fixed-upstream
thanks

On Mon, Jan 14, 2013 at 1:12 PM, Holger Levsen hol...@layer-acht.org wrote:
 so 2.0.9 is not affected?

I think it is, as his patch applies cleanly on stable-2.0.
[ Applied upstream as c5a18eb2dd253a437dd06437978d5b79f344db51 ]

Thx
--
Steve Schnepp
http://blog.pwkf.org/tag/munin


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#698078: [Packaging] Bug#698078: munin-plugins-core: missing dependency on libcache-cache-perl for mysql_ checks

[Steve Schnepp]

On Mon, Jan 14, 2013 at 1:13 PM, Holger Levsen hol...@layer-acht.org wrote:
 # as always...

Complete explanation is at #697861 .
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=697861#10

--
Steve Schnepp
http://blog.pwkf.org/tag/munin


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#697907: munin-plugins-core: slapd_ plugin does not autoconfigure

[Steve Schnepp]

tag 697907 + upstream fixed-upstream
thanks

 On Fri, Jan 11, 2013 at 10:50 AM, Ferenc Wagner wf...@niif.hu wrote:
 This seems to be caused by an API change in Net::LDAP, and possible to fix
 by explicitly using an array reference instead of a string as:

Yey !

It just got fixed upstream in c5cf4ad4b54983265a38554290414ab9af828bf5.

Thanks Ferenc.
--
Steve Schnepp
http://blog.pwkf.org/tag/munin


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#685457: nsca: potential offending commit

[Steve Schnepp]

# We'd like to be notified of this...
affects 685457 + munin
thanks

A quick search showed that it seems to originate in this upstream
commit (counting for 2.9):


r1824 | mikelindsey | 2011-10-10 05:56:21 +0200 (Mon, 10 Oct 2011) | 4 lines

Addition of configuration directive 'check_results_path' to allow bypass of
command pipe, and 4000 character multi-line output support.


--
Steve Schnepp
http://blog.pwkf.org/tag/munin


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#685457: nsca: potential offending commit

[Steve Schnepp]

On Wed, Jan 2, 2013 at 4:05 PM, Alexander Wirt formo...@debian.org wrote:

 munin should update to the new protocol.

Will the = 2.8 versions also understand correctly the new protocol ?

--
Steve Schnepp


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#685457: nsca: potential offending commit

[Steve Schnepp]

On Wed, Jan 2, 2013 at 4:21 PM, Alexander Wirt formo...@debian.org wrote:

 I am sorry but I can't do anything here, in my oppinion

Well... filing an upstream bug to notify them of the issue might help
munin  others packages that uses it.

Upstream might not even be aware of the whole situation here. Or
already are, and have a working workaround/fix/whatever.

 its not Debians job to fix upstream protocol decisions.

And, as upstream myself, I would not expect that from my fellow
packagers, either.

 either as all others distro would will carry an umodified nsca). If you give
 me a patch and a test description I can do some tests for you if that helps.

Sorry about that, but as I'm not a nsca user myself, I was just
alerted by some of our users that provided me the bug url.

--
Steve Schnepp


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#685457: nsca: potential offending commit

[Steve Schnepp]

forwarded 685457 http://tracker.nagios.org/view.php?id=382
thanks

On Wed, Jan 2, 2013 at 5:24 PM, Alexander Wirt formo...@debian.org wrote:

 This is probably http://tracker.nagios.org/view.php?id=382
 There were also some discussions on the mailinglist.

Great, thx !

--
Steve Schnepp


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#696981: munin: Cron job warn about not a reference at /usr/share/perl5/Munin/Master/Utils.pm line 908

[Steve Schnepp]

This message is currently my white whale... It seems to pops up on many
installs, yet I (upstream) still didn't manage to reproduce it accurately.
And every time I have it, it only appears on the first run on munin-html
via munin-cron.

So, I *know* the warning is here, and I'll fix it as soon as I have some
time for extensive testings.

On a side note, I think that sending email per default is a feature. The
fact that /var fills up is due to the previous bug and not from having too
much emails.

Big thx for the bug report (as it was previously reported only on rpm-based
distros)

Steve

Bug#694527: munin: version reported incorrectly

[Steve Schnepp]

Package: munin-common
Version: 2.0.6~git-1
Severity: important
Justification: it makes it very difficult to see which version is used
(have to use dpkg)

The naming is difficult to follow, with 2.0.6~git-1 having unknown:

2.0.6-1: $MUNIN_VERSION = q{2.0.6};
2.0.6-1~bpo60+1:  $MUNIN_VERSION = q{debian-bpo-2012-09-06-8b308d7c};
2.0.6~git-1: $MUNIN_VERSION= q{unknown};

This is due to the upstream getversion script customized for various
git branch builds. It doesn't know about debian namings specifics.

It'd be optimal if $MUNIN_VERSION would be the same as the debian
package version.
--
Steve Schnepp
http://blog.pwkf.org/tag/munin


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#683064: fixed in git

[Steve Schnepp]

Bah, Helmut, your patch was slightly better, as closer to the spirit of the
spec. Therefore the 2nd fix.

Steve
Le 8 août 2012 20:27, Helmut Grohne hel...@subdivi.de a écrit :

 On Wed, Aug 08, 2012 at 12:24:28PM +0200, Holger Levsen wrote:
  $ git show 29f4223
  commit 29f422377e710dfb19cff5a29af2344ae6203203
  Author: Christoph Biedl munin.i...@manchmal.in-ulm.de
  Date:   Tue Jul 3 17:44:04 2012 +0200
 
  fix bug that disabled gfx CGI caching
 
  Apache and lighttpd always set QUERY_STRING, even if it's empty.
  This makes proper caching work again as expected.
 
  diff --git a/master/_bin/munin-cgi-graph.in b/master/_bin/
 munin-cgi-graph.in
  index 95efbdd..754705d 100755
  --- a/master/_bin/munin-cgi-graph.in
  +++ b/master/_bin/munin-cgi-graph.in
  @@ -159,7 +159,7 @@ while (new CGI::Fast) {
   }
 
   # Having some QUERY_STRING disables the cache.
  -if (defined($ENV{QUERY_STRING})) {
  +if (defined($ENV{QUERY_STRING})  $ENV{QUERY_STRING}) {
 $no_cache = 1;
   }
 
 
 
  As I understand it, this is different than the patch from Helmut and
 won't
  work as expected. Helmut?

 I believe that both patches work. I only found the upstream fix after
 submitting my patch even though it was created earlier. Looking at
 upstream first would have saved me that work.

 Note that upstreams patch allowes QUERY_STRING=0 to be cached.

 Helmut

Bug#678928: [Packaging] Bug#678928: closed by Holger Levsen hol...@layer-acht.org (Re: Bug#678928: Squeeze safe-upgrade pulled munin 2.0.0-1~bpo60+1, graphs won't display)

[Steve Schnepp]

... Hoping onto the thread.

On Tue, Jun 26, 2012 at 9:40 AM, Kenyon Ralph ken...@kenyonralph.com wrote:

 CGI graphing was not the default in munin 1.4. So, for most
 installations, munin 2.0 is a significant change in this respect.

1.4 defaults to cron. 2.0 is mostly CGI-only.

I'm working on bringing back cron graphing in 2.0, since several users
reported issues
with CGI setup. Should land on 2.0.2.

 If this is not a bug, and a bug report isn't the proper place to receive
 troubleshooting assistance to get this working, where do you recommend I
 go for assistance?

A bug report is a perfect place to trace down things. So thanks to
have opened it.
That said, for proper/fast resolution, see below.

 Several munin developers and users use munin with lighttpd, so you
 might find help in the #munin channel on oftc.net IRC.

That's currently your best bet (IRC), as I do also use lighttpd.
Since I'm using a fairly dodgy setup on my dev box and I lack time to
write proper doc, well...

 In the process, with your help, we could improve the documentation
 and packaging of munin and its integration with lighttpd.

That's also in the process.

As kenyon suggested, if you even take part of it, many would be more
than glad to spend some time with you debugging.

Then once the doc is adequate on the matter, packaging integration
will happen quite quickly, for everyone's benefit.

So, sorry for the inconvenience, but a hop on IRC will show you that
we're not in our ivory tower. Just that we are unfortunately quite
busy...

--
Steve Schnepp
http://blog.pwkf.org/



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#678255: munin-node: The output of /usr/share/munin/plugins/cps_ suggest is incorrect

[Steve Schnepp]

fixed 678255 2.0~rc2-1
done

On Wed, Jun 20, 2012 at 12:55 PM,  ni...@moybella.net wrote:
 The following is all that's required to fix the problem:
 [...]

Yes, and this patch is even already included since 2.0~rc2-1 :-)

--
Steve Schnepp
http://blog.pwkf.org/



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#675593: Complement, actual state.

[Steve Schnepp]

Tag 675593 + upstream
Thx

The current perms are : u=rwx,go=rx

For plugins that don't exec as the correct uid, they cannot create their
state file there.

Creation of the state file is difficult to delegate correctly, so using the
proposed perms is a good compromise.

And this fix should happen upstream.

Bug#675593: Fix perms for plugin-state dir on munin-node

[Steve Schnepp]

package: munin-node

This bug is mostly for reminder about irc chat over perm issue

Perms should be like :

chown munin.munin /var/lib/munin/plugin-state
chmod u=rwx,g=rwxs,o=rx /var/lib/munin/plugin-state

Bug#675153: [Packaging] Bug#675153: munin: All Munin Graphs broken after upgrade to 2.0-rc6

[Steve Schnepp]

tag 675153 + pending
severity 675153 normal
thanks

Richard, I think you just didn't edit your munin.conf to add cgitmpdir
as described in a NEWS file.

Anyway, I also feel it should work out of the box, so i already fixed
it upstream.

So could your apply http://munin-monitoring.org/changeset/4896 ?

--
Steve Schnepp
http://blog.pwkf.org/


On Wed, May 30, 2012 at 12:26 PM, Stig Sandbeck Mathisen s...@debian.org 
wrote:
 Richard Scherping rich...@scherping.de writes:

 Please direct me how to make Munin working again.

 Could you please provide the contents of /etc/munin/munin.conf (and any
 files it includes?).

 You do not need to include the node definitions (hostnames and
 addresses)

 --
 Stig Sandbeck Mathisen s...@debian.org






-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#675152: munin regression in testing, files are searched in /munin-cgi-graph and wrong permissions

[Steve Schnepp]

tag 675152 + pending
thanks

This is the same bug as 675153, munin.conf needs a change as said in NEWS.

But try patch http://munin-monitoring.org/changeset/4896 to make the
default work again.

--
Steve Schnepp
http://blog.pwkf.org/


On Wed, May 30, 2012 at 10:50 AM, Patrick Matthäi pmatth...@debian.org wrote:
 Package: munin
 Version: 2.0~rc6-3
 Severity: grave

 Hello,

 after upgrading from munin 2.0~rc5-3 to 2.0~rc6-3 the whole graph generation
 is broken, also if we purge the whole package (also removing /var/lib/munin
 and /var/cache/munin/www).

 My steps to reproduce this issue:
 - fresh install of munin
 - adding a host to the tree
 - enable fastcgi apache module
 - set allow from... to the needed hosts
 - reload apache

 After this, the html page is correct generated, but if I want to see the
 graphs I get in the apache errorlog:

 [warn] FastCGI: (dynamic) server /usr/lib/cgi-bin/munin-cgi-graph started
 (pid 2341)
 FastCGI: server /usr/lib/cgi-bin/munin-cgi-graph stderr: Use of
 uninitialized value in concatenation (.) or string at
 /usr/lib/cgi-bin/munin-cgi-graph line 316., referer:
 http://munin/munin/ameusgmbh.intern/gateway.ameusgmbh.intern/index.html
 FastCGI: server /usr/lib/cgi-bin/munin-cgi-graph stderr: Use of
 uninitialized value $epoch in gmtime at /usr/lib/cgi-bin/munin-cgi-graph
 line 283., referer:
 http://munin/munin/ameusgmbh.intern/gateway.ameusgmbh.intern/index.html
 FastCGI: server /usr/lib/cgi-bin/munin-cgi-graph stderr: Use of
 uninitialized value $mtime_epoch in modulus (%) at
 /usr/lib/cgi-bin/munin-cgi-graph line 270., referer:
 http://munin/munin/ameusgmbh.intern/gateway.ameusgmbh.intern/index.html
 FastCGI: server /usr/lib/cgi-bin/munin-cgi-graph stderr: Use of
 uninitialized value $mtime_epoch in subtraction (-) at
 /usr/lib/cgi-bin/munin-cgi-graph line 270., referer:
 http://munin/munin/ameusgmbh.intern/gateway.ameusgmbh.intern/index.html
 FastCGI: server /usr/lib/cgi-bin/munin-cgi-graph stderr: Use of
 uninitialized value in concatenation (.) or string at
 /usr/lib/cgi-bin/munin-cgi-graph line 237., referer:
 http://munin/munin/ameusgmbh.intern/gateway.ameusgmbh.intern/index.html
 FastCGI: server /usr/lib/cgi-bin/munin-cgi-graph stderr: [Wed May 30
 10:10:55 2012] munin-cgi-graph: [FATAL] Could not open image file
 /munin-cgi-graph/ameusgmbh.intern/gateway.ameusgmbh.intern/diskstats_latency-day.png
 for reading: No such file or directory, referer:
 http://munin/munin/ameusgmbh.intern/gateway.ameusgmbh.intern/index.html
 FastCGI: server /usr/lib/cgi-bin/munin-cgi-graph stderr: [Wed May 30
 10:10:55 2012] munin-cgi-graph: [FATAL] Could not open image file
 /munin-cgi-graph/ameusgmbh.intern/gateway.ameusgmbh.intern/diskstats_latency-day.png
 for reading: No such file or directory, referer:
 http://munin/munin/ameusgmbh.intern/gateway.ameusgmbh.intern/index.html
 FastCGI: (dynamic) server /usr/lib/cgi-bin/munin-cgi-graph (pid 2341)
 terminated by calling exit with status '2'


 The /var/log/munin/munin-cgi-html.log shows:

 2012/05/30 10:21:10 Opened log file
 2012/05/30 10:21:10 Request path is
 /ameusgmbh.intern/gateway.ameusgmbh.intern/diskstats_throughput-week.png
 2012/05/30 10:21:10 asked for (ameusgmbh.intern, gateway.ameusgmbh.intern,
 diskstats_throughput, week)
 2012/05/30 10:21:10 Starting munin-graph
 2012/05/30 10:21:10 [INFO] Looking into drawing
 /munin-cgi-graph/ameusgmbh.intern/gateway.ameusgmbh.intern/diskstats_throughput-week.png
 2012/05/30 10:21:10 [RRD ERROR] Unable to graph
 /munin-cgi-graph/ameusgmbh.intern/gateway.ameusgmbh.intern/diskstats_throughput-week.png
 : Could not save png to
 '/munin-cgi-graph/ameusgmbh.intern/gateway.ameusgmbh.intern/diskstats_throughput-week.png'
 2012/05/30 10:21:10 [RRD ERROR] rrdtool 'graph'
 '/munin-cgi-graph/ameusgmbh.intern/gateway.ameusgmbh.intern/diskstats_throughput-week.png'
 \
        '--title' \
        'Disk throughput per device - by week' \
        '--start' \
        '-12000m' \
        '--base' \
        '1024' \
        '--vertical-label' \
        'Bytes/second read (-) / write (+)' \
        '--slope-mode' \
        '--height' \
        '175' \
        '--width' \
        '400' \
        '--imgformat' \
        'PNG' \
        '--font' \
        'DEFAULT:0:DejaVuSans,DejaVu Sans,DejaVu LGC Sans,Bitstream Vera
 Sans' \
        '--font' \
        'LEGEND:7:DejaVuSansMono,DejaVu Sans Mono,DejaVu LGC Sans
 Mono,Bitstream Vera Sans Mono,monospace' \
        '--color' \
        'BACK#F0F0F0' \
        '--color' \
        'FRAME#F0F0F0' \
        '--color' \
        'CANVAS#FF' \
        '--color' \
        'FONT#66' \
        '--color' \
        'AXIS#CFD6F8' \
        '--color' \
        'ARROW#CFD6F8' \
        '--border' \
        '0' \
        '-W' \
        'Munin 2.0-rc6' \
        'HRULE:2#FF8000' \

 'DEF:a3644073c3ef357f=/var/lib/munin/ameusgmbh.intern/gateway.ameusgmbh.intern-diskstats_throughput-gateway_swap_1_wrbytes-g.rrd:42:MAX'
 \

 'DEF:i3644073c3ef357f=/var/lib/munin

Bug#674148: Dynamic zooming doesn't work anymore

[Steve Schnepp]

Package: munin
Version: 2.0~rc6-2
Severity: important

As Alan Citterman alan.citter...@nexgenwireless.com noted :


The dynamic zooming stopped working for me between munin-2.0rc5 and
munin-2.0rc6.

I found the issue related to munin-cgi-graph rejecting the request
because ampersand characters occur in the QUERY_STRING (separating CGI
parameters).

Line 75 of master/_bin/munin-cgi-graph.in calls:
has_offending_chars($ENV{QUERY_STRING})
but this function doesn't approve  of ampersands.

My quick fix was to duplicate the function as has_offending_chars_qs()
adding ampersand to the list of allowed characters and to change line
75 to use it.


A fix has already been commited upstream in r4877  r4878.

This bug is mostly to track the issue

--
Steve Schnepp
http://blog.pwkf.org/



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#670428: [Packaging] Bug#670428: /usr/share/munin/plugins/spamstats: no license to redistribute plugin spamstats

[Steve Schnepp]

On Fri, Apr 27, 2012 at 12:59, Jimmy Olsen j...@redpill-linpro.com wrote:

Hi,

 unknown by the people adding the pod doc. The license is GPLv2.

Can we assume that all the code that seems attributed to you is GPLv2 ?

--
Steve Schnepp
http://blog.pwkf.org/



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#668667: [oss-security] CVE Request (minor) -- Two Munin graphing framework flaws

[Steve Schnepp]

On Wed, Apr 18, 2012 at 07:04, Kurt Seifried kseifr...@redhat.com wrote:
 In addition munin parses parts of the query string. You are allowed
 to modify the size of the image. By choosing a path
 png?size_x=2size_y=2uniquestuff you can do the
 same attack while simultaneously using a large image size. The raw
 image would be 381M (assuming 8bits/pixel) in this case. A png
 version will likely be smaller, say 4M? So now you have an
 amplification of 4M/request. Note that this query can get a node
 into swapping, because rrdtool needs to create the whole image in
 main memory.

 Ouch.

I believe I fixed the bug in r4825, since :
- url with query string aren't stored permanently anymore.
- /tmp isn't used anymore per default (to fix #668536)

Could you confirm that ?

OTOH, the issue about very big imgs that gets the cgi into swapping
isn't the same bug to be.

As Helmut noticed, there is already a size cap in rrd, so do I still
need implement one in munin ? If yes, would you mind to file another
bugreport (for RAM exhaustion) ?

Thx !

r4825: http://munin-monitoring.org/changeset/4825

--
Steve Schnepp
http://blog.pwkf.org/



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#669347: Handling mostly unused plugins.

[Steve Schnepp]

Package: munin-plugins-core
Version: 2.0~rc5-3
Severity: whishlist

I'm also sometimes tempted to remove old and mostly unused plugins
(see bug #668778)
But once they are in trunk, some users might depends on them.

So I think we should create a new munin-plugins-* package for them.
This bug report is here for reminding.
For naming, munin-plugins-osoblete or munin-plugins-old comes to my mind.

Would it also be possible to have some usage stats reported ?
Something a-la popcon, but for plugins...

--
Steve Schnepp
http://blog.pwkf.org/



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#668536: munin: The tempfile location has to be predictable, but not creatable by anyone.

[Steve Schnepp]

Actually we need to have a predictable tmpfile location (for the
caching feature).

The real issue is that it shouldn't be in /tmp as kjetilho said :

 kjetilho doesn't help if the attacker can do mkdir /tmp/subdir;
chmod 777 /tmp/subdir after a reboot

So, let's go for some directories created at install time in /var/lib/munin.

- /var/lib/munin/cgi-tmp/munin-cgi-graph/ for the files generated by
munin-cgi-graph
- /var/lib/munin/cgi-tmp/munin-cgi-html/ for the files generated by
munin-cgi-html (none yet)

The /var/lib/munin/cgi-tmp/ directory is to be created owned by the
CGI user (in order for it to whatever it needs).

--
Steve Schnepp
http://blog.pwkf.org/



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#668340: Different users for munin and munin-node

[Steve Schnepp]

Package: munin
Severity: wishlist

Currently the package munin (server) and munin-node (agent) are using the
same user : munin.

When both are on the same server, the node has a full access to all the
files of the master, including the rrd and the database files.

I'd naively suggest that the munin package user should be changed (to
munind:munind). It involves lesser impact than on munin-node in number of
installs.

Bug#667493: the jmx_ plugin should be moved into munin-plugins-java

[Steve Schnepp]

package: munin-plugins-java
version: 2.0~rc2-1
severity: grave

The real plugin is a wrapper script : /usr/share/munin/plugins/jmx_
which is currently provided by the munin-plugins-core package. Both
files are useless w/o each other, it makes munin-plugins-java unusable
as a standalone package.

This bug is to remind me to move the jmx_ plugin into the correct package.

--
Steve Schnepp
http://blog.pwkf.org/



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#661884: Fixed in 2.0

[Steve Schnepp]

Fixed 661884 munin/2.0~rc2-1
Thanks

This bug has been fixed somewhere in trunk and the 1.999 series.

Bug#519039: Closing...

[Steve Schnepp]

I'm closing this bug.

In 2.0, there is a separate package withheld plugins, so there is *no* need
to disable node when it is installed.

If you really want to disable it, use update-rc.d

Bug#584167: 584167 is fixed in trunk

[Steve Schnepp]

fixed 584167 munin/2.0~rc2-1
thanks

It was fixed in r4292.

--
Steve Schnepp
http://blog.pwkf.org/



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#488360: Status request for 488360 (cciss support to the smart_ plugin)

[Steve Schnepp]

So, what's the status on this bug ?

Since, if the patch works correctly, I'm ready to include it upstream,
and it might be included in 2.0.

--
Steve Schnepp
http://blog.pwkf.org/



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#665688: infos

[Steve Schnepp]

It seems to be not translated just in the POD parts, and was
introduced in 1.4.0.

--
Steve Schnepp
http://blog.pwkf.org/



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#653612: graph size settings for multigraphs works, but diskstats overrides it

[Steve Schnepp]

fixed 653612 munin/2.0~rc2-1
thanks

Diskstats isn't a good multigraph plugin example here, since it
overrides the graph_width with a graph_width 400.
I tested it on r4512 and and it works as expected on a test multigraph plugin.

So I'm changing this to fixed in rc2. [ Was fixed before also, but well. ]

Feel free to provide me a sample plugin output (config + fetch) that
triggers the issue in rc2 so I can investigate futher.

--
Steve Schnepp
http://blog.pwkf.org/



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#608588: Cannot reproduce 608588

[Steve Schnepp]

notfound 608588 munin/2.0~rc2-1
thx

I don't have the bug here.

I'm using iptables/1.4.8-3 and munin/2.0~rc2-1, but as my ip_ plugin
is the same as yours, the bug should also be present.

What's :
- your iptables version ?
- your iptables output of : iptables -L INPUT -v -n -x

--
Steve Schnepp
http://blog.pwkf.org/



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#626346: Ping

[Steve Schnepp]

Holger, you said :

 fix is sitting on my disk, waiting for me to commit, which is blocked by some
 network problems here. Will be uploaded soon.

Do you still have any plan to upload it ?

--
Steve Schnepp
http://blog.pwkf.org/



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#648891: Fwd: Bug#626346: Ping

[Steve Schnepp]

tags 648891 + fixed pending
thanks

On Wed, Mar 21, 2012 at 17:31, Holger Levsen hol...@layer-acht.org wrote:
 Steve, can you please take a look at the patch and apply it?! Thanks already 
 :)

I fixed the last plugins for that in r4758 and r4759.
Will normally be in 2.0~rc3.

--
Steve Schnepp
http://blog.pwkf.org/



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#652364: munin-node: Increase select timeout to avoid waking up 150 times before doing any work

[Steve Schnepp]

 Thanks. I've forwarded this info to the upstream trac.

Holger, I'm afraid that 2s is a hard configured value in Net::Server::Fork.
See line 189 of /usr/share/perl5/Net/Server/Fork.pm from
libnet-server-perl (0.97-1)

--
Steve Schnepp
http://blog.pwkf.org/



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#624626: puf doesn't urldecode filenames when writing them to disk

[Steve Schnepp]

Package: puf
Version: 1.0.0-6
Severity: important
Tags: upstream


When downloading an URL with a url entity in it (such as %20, space), puf does 
create a file with a %20. 
It should url decode the filename, and write a filename with a space in it as 
wget.

puf http://example.com/filename%20with%20space.html creates a 
filename%20with%20space.html file.

wget http://example.com/filename%20with%20space.html creates a filename with 
space.html file.

-- System Information:
Debian Release: 6.0.1
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 2.6.32-5-686 (SMP w/2 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages puf depends on:
ii  libc6 2.11.2-10  Embedded GNU C Library: Shared lib

puf recommends no packages.

puf suggests no packages.

-- no debconf information



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#624638: puf should urldecode filenames when writing them to disk

[Steve Schnepp]

Package: puf
Version: 1.0.0-6
Severity: important
Tags: upstream

*** Please type your report below this line ***

puf should urldecode filenames (and directory names) when dumping them
to disk, as wget does it.

puf http://example.com/filename%20with%20spaces.html writes a file
named filename%20with%20spaces.html
wget http://example.com/filename%20with%20spaces.html writes a file
named filename with spaces.html


-- System Information:
Debian Release: 6.0.1
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 2.6.32-5-686 (SMP w/2 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages puf depends on:
ii  libc6 2.11.2-10  Embedded GNU C Library: Shared lib

puf recommends no packages.

puf suggests no packages.

-- no debconf information

--
Steve Schnepp
http://blog.pwkf.org/



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#623572: thttpd: Pass Cache-Control header to HTTP_CACHE_CONTROL CGI environment

[Steve Schnepp]

Package: thttpd
Version: 2.25b-11
Severity: wishlist
Tags: patch

It would be nice to pass the Cache-Control header to spawned CGI
processes.

Here is a minimal patch that does just this.

-- System Information:
Debian Release: 6.0.1
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: kfreebsd-amd64 (x86_64)

Kernel: kFreeBSD 8.1-1-amd64
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash

Versions of packages thttpd depends on:
ii  libc0.1   2.11.2-10  Embedded GNU C Library: Shared lib

Versions of packages thttpd recommends:
ii  logrotate 3.7.8-6Log rotation utility

Versions of packages thttpd suggests:
pn  thttpd-util   none (no description available)

-- no debconf information
diff -u thttpd-2.25b.orig/libhttpd.c thttpd-2.25b/libhttpd.c
--- thttpd-2.25b.orig/libhttpd.c	2011-04-21 12:03:04.0 +0200
+++ thttpd-2.25b/libhttpd.c	2011-04-21 12:03:10.0 +0200
@@ -1733,6 +1733,7 @@
 hc-acceptl = ;
 hc-cookie = ;
 hc-contenttype = ;
+hc-cachecontrol = ;
 hc-reqhost[0] = '\0';
 hc-hdrhost = ;
 hc-hostdir[0] = '\0';
@@ -2189,6 +2190,12 @@
 		cp += strspn( cp,  \t );
 		hc-contenttype = cp;
 		}
+	else if ( strncasecmp( buf, Cache-Control:, 14 ) == 0 )
+		{
+		cp = buf[14];
+		cp += strspn( cp,  \t );
+		hc-cachecontrol = cp;
+		}
 	else if ( strncasecmp( buf, Content-Length:, 15 ) == 0 )
 		{
 		cp = buf[15];
@@ -2211,7 +2218,6 @@
 	else if ( strncasecmp( buf, Accept-Charset:, 15 ) == 0 ||
 		  strncasecmp( buf, Accept-Language:, 16 ) == 0 ||
 		  strncasecmp( buf, Agent:, 6 ) == 0 ||
-		  strncasecmp( buf, Cache-Control:, 14 ) == 0 ||
 		  strncasecmp( buf, Cache-Info:, 11 ) == 0 ||
 		  strncasecmp( buf, Charge-To:, 10 ) == 0 ||
 		  strncasecmp( buf, Client-IP:, 10 ) == 0 ||
@@ -3063,6 +3069,8 @@
 	envp[envn++] = build_env( HTTP_COOKIE=%s, hc-cookie );
 if ( hc-contenttype[0] != '\0' )
 	envp[envn++] = build_env( CONTENT_TYPE=%s, hc-contenttype );
+if ( hc-cachecontrol[0] != '\0' )
+	envp[envn++] = build_env( HTTP_CACHE_CONTROL=%s, hc-cachecontrol );
 if ( hc-hdrhost[0] != '\0' )
 	envp[envn++] = build_env( HTTP_HOST=%s, hc-hdrhost );
 if ( hc-contentlength != -1 )
diff -u thttpd-2.25b.orig/libhttpd.h thttpd-2.25b/libhttpd.h
--- thttpd-2.25b.orig/libhttpd.h	2011-04-21 12:03:04.0 +0200
+++ thttpd-2.25b/libhttpd.h	2011-04-21 12:03:10.0 +0200
@@ -114,6 +114,7 @@
 char* acceptl;
 char* cookie;
 char* contenttype;
+char* cachecontrol;
 char* reqhost;
 char* hdrhost;
 char* hostdir;

Bug#620129: cstream: Porting to kfreebsd

[Steve Schnepp]

Package: cstream
Version: 2.7.6-1
Severity: normal
Tags: patch

A patch is attached to make it build on kfreebsd-*, that doesn't have O_DIRECT.

-- System Information:
Debian Release: 6.0.1
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: kfreebsd-amd64 (x86_64)

Kernel: kFreeBSD 8.1-1-amd64
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash

Versions of packages cstream depends on:
ii  libc0.1   2.11.2-10  Embedded GNU C Library: Shared lib

cstream recommends no packages.

cstream suggests no packages.

-- no debconf information
--- cstream.c.orig  2008-12-19 21:38:37.0 +
+++ cstream.c   2011-03-30 12:27:43.0 +
@@ -569,11 +569,16 @@
   }

   if (state-using_o_direct) {
+#ifdef O_DIRECT
 flags |= O_DIRECT;
 if (o-v  1) {
   fprintf(stderr, Using O_DIRECT on output file with blocksize %d\n
  , state-b);
 }
+#else
+fprintf(stderr, Trying to use O_DIRECT but this OS doesn't have it\n);
+exit(2);
+#endif

 if (!o-user_specified_blocksize) {
 #ifdef HAVE_SYS_STATVFS_H

Bug#193782: cstream: needs read permission for the output file

[Steve Schnepp]

Tags: patch

Here is a small patch that provides a fix.
--- cstream.c.orig  2011-03-30 13:21:26.0 +
+++ cstream.c   2011-03-30 13:22:08.0 +
@@ -699,7 +699,7 @@
 if (strchr(o-o, ':')  !strchr(o-O, 'N'))
   state-ofd = open_tcp(o, O_WRONLY);
 else {
-  open_output_file(o, state, O_RDWR | O_CREAT | O_TRUNC); /* sets ofd */
+  open_output_file(o, state, O_WRONLY | O_CREAT | O_TRUNC); /* sets ofd */
 }
   }

@@ -933,7 +933,7 @@
   exit(2);
 }
 state-using_o_direct = 0;
-open_output_file(o, state, O_RDWR | O_APPEND);
+open_output_file(o, state, O_WRONLY | O_APPEND);
   }

   ret = write(state-ofd, buf, n_bytes);

Bug#193782: cstream: needs read permission for the output file

[Steve Schnepp]

tags 193782 + patch
quit





On Wed, Mar 30, 2011 at 15:29, Steve Schnepp steve.schn...@gmail.com wrote:
 Tags: patch

 Here is a small patch that provides a fix.




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#619949: sysstat: iostat is unusable on kfreebsd-* (no disk-related stats)

[Steve Schnepp]

Package: sysstat
Version: 9.0.6.1-2
Severity: normal

On the kfreebsd-* architecture, iostat doesn't output any disk-related stats.

-- System Information:
Debian Release: 6.0.1
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: kfreebsd-amd64 (x86_64)

Kernel: kFreeBSD 8.1-1-amd64
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash

Versions of packages sysstat depends on:
ii  bzip2   1.0.5-6  high-quality block-sorting file co
ii  debconf [debconf-2.0]   1.5.36.1 Debian configuration management sy
ii  libc0.1 2.11.2-10Embedded GNU C Library: Shared lib
ii  lsb-base3.2-23.2squeeze1 Linux Standard Base 3.2 init scrip
ii  ucf 3.0025+nmu1  Update Configuration File: preserv

Versions of packages sysstat recommends:
ii  cron  3.0pl1-116 process scheduling daemon

Versions of packages sysstat suggests:
pn  isag  none (no description available)

-- debconf information:
  sysstat/enable: false
  sysstat/remove_files: true



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#612120: www.debian.org/ports/kfreebsd-i386 is missing

[Steve Schnepp]

Is it possible to have 301 redirects from the missing pages to the correct one ?

That addition would make the intended sharing obvious.

2011/2/7, Samuel Thibault sthiba...@debian.org:
 David Prévot, le Sun 06 Feb 2011 23:50:26 -0400, a écrit :
 Le 05/02/2011 22:39, Samuel Thibault a écrit :
  Simon Paillard, le Sun 06 Feb 2011 03:30:48 +0100, a écrit :
  On Sun, Feb 06, 2011 at 03:25:10AM +0100, Samuel Thibault wrote:
  Wolodja Wentland, le Sun 06 Feb 2011 01:46:09 +, a écrit :
  http://www.debian.org/ports/kfreebsd-i386/ is missing and results in
  a
  404.
 
  Yes, that's expected, it's http://www.debian.org/ports/kfreebsd-gnu/
  for
  both.
  Where did you see that bogus URL?
 
  http://debian.org/releases/squeeze/
  We link according to the arch name.
 
  Ok, that's actually collusion.  In the debian manual, we separate arch
  name from port website name.

 Hi kFreeBSD team,

 We are wondering if the kfreebsd-i386 and kfreebsd-amd64 would deserve
 their own http://www.debian.org/ports/ pages. It may be the more
 consistent approach regarding existing directory name (alpha, amd64,
 arm, hppa, i386, ia64, m68k, mips, powerpc, s390, sparc, sparc64, etc.)
 but this choice is up to you.

 If there is no point in maintaining both the ports/kfreebsd-amd64 and
 ports/kfreebsd-i386 pages, we could try to tweak the auto-generated
 links about kfreebsd-amd64 and kfreebsd-i386 to actually point to
 ports/kfreebsd-gnu, but since those links maybe automatically generated
 in other documents like release-notes or installation-guide, we may also
 need to prepare a 301 redirection from ports/kfreebsd-amd64 and
 kfreebsd-i386.

 The installation guide already correctly generates the links.

 Samuel


 --
 To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
 with a subject of unsubscribe. Trouble? Contact
 listmas...@lists.debian.org
 Archive:
 http://lists.debian.org/20110207112242.ga9...@const.bordeaux.inria.fr



-- 
Envoyé avec mon mobile

-- 
Steve Schnepp
http://blog.pwkf.org/



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#582786: [munin-users] Bug#582786: munin: munin-cgi-graph fails on multigraphs

[Steve Schnepp]

2010/9/19 Holger Levsen hol...@layer-acht.org

 I'm not using multigraph, so I cannot really comment on this patch, but it
 seems to me it would be worthwhile to get #582786 fixed for squeeze.


Having a working CGI in squeeze would be obviously quite nice :-)


 Can someone of the usual suspects please comment 
 onhttp://bugs.debian.org/cgi-bin/bugreport.cgi?msg=10;filename=multigraph-v3.patch;att=1;bug=582786


For the record, I created a new param --only-fqn to fix this in 2.0 [ see
commit r3325  r3329 ].
It also fixed graphing when you have nested groups.

Maybe the fix could somehow be backported to the 1.4 branch...

-- 
Steve Schnepp
http://blog.pwkf.org/

Bug#595063: read() builtin doesn't read integer value /proc files (but bash's does)

[Steve Schnepp]

2010/9/3 Jilles Tjoelker jil...@stack.nl:
 This patch assumes that the file descriptor is discarded afterwards (its
 position does not matter). Therefore the very common construct
  while read x; do
    ...
  done
 stops working.

Ohh.. thanks for that, I didn't see it.

Actually while read x continues to work.
But reopening the file doesn't as in :

read a b  datafile
echo ${a} ${b}
read a b  datafile
echo ${a} ${b}

I attached an updated patch that corrects this pb by discarding the
buffer when opening a new file.
I also put everything in new files (bufreadcmd.c  .h), in order to
ease its understanding.

--
Steve Schnepp
http://blog.pwkf.org/



 A possible fix is to check first if the input supports seeking. If it
 does, use the buffering and at the end of the line seek backwards for
 the number of bytes remaining in the buffer. If it does not, read one
 byte at a time.

 --
 Jilles Tjoelker



--
Steve Schnepp
http://blog.pwkf.org/
Common subdirectories: dash-0.5.4/src/bltin and dash-0.5.4-patched/src/bltin
diff -puN dash-0.5.4/src/bufreadcmd.c dash-0.5.4-patched/src/bufreadcmd.c
--- dash-0.5.4/src/bufreadcmd.c	1970-01-01 01:00:00.0 +0100
+++ dash-0.5.4-patched/src/bufreadcmd.c	2010-09-04 12:31:46.0 +0200
@@ -0,0 +1,59 @@
+/*
+ * Offers a buffered read builtin
+ */
+
+#include unistd.h
+#include stdlib.h
+
+#include bufreadcmd.h
+
+#ifdef BUF_READ_BUILTIN_DISABLED
+int dup2_wrapper(int old, int new) {
+	return dup2(old, new);
+}
+int read_stdin_bufferred(char *c) {
+	return read(0, buffer, 1);
+}
+#else // BUF_READ_BUILTIN_DISABLED
+
+/*
+ * Reads from fd 0, with a CHUNK_READ_SIZE,
+ * but emitting one char at a time
+ */
+#define CHUNK_READ_SIZE 32
+static char buffer[CHUNK_READ_SIZE];
+static int buffer_offset = 0;
+static int buffer_len = 0;
+
+int read_stdin_bufferred(char* c) {
+   if (buffer_len == 0) {
+   // No caracter left, resetting buffer  read some more
+   buffer_offset = 0;
+   buffer_len = read(0, buffer, CHUNK_READ_SIZE);
+
+   if (buffer_len == 0) {
+   // Nothing to read anymore
+   return 0;
+   }
+   }
+
+   // Still some character left
+   *c = buffer[buffer_offset++];
+   buffer_len--;
+
+   return 1;
+}
+
+static void _flush_readcmd(int fd) {
+	if (fd == 0) { 
+		// Flush the buffer, discarding its content
+		buffer_len = 0;
+	}
+}
+
+/* Intercept dup2() calls */
+int dup2_wrapper(int old, int new) {
+	_flush_readcmd(new);
+	return dup2(old, new);
+}
+#endif // BUF_READ_BUILTIN_DISABLED
diff -puN dash-0.5.4/src/bufreadcmd.h dash-0.5.4-patched/src/bufreadcmd.h
--- dash-0.5.4/src/bufreadcmd.h	1970-01-01 01:00:00.0 +0100
+++ dash-0.5.4-patched/src/bufreadcmd.h	2010-09-04 12:23:53.0 +0200
@@ -0,0 +1,3 @@
+/* Used for flushing the readcmd read() buffer */
+int dup2_wrapper(int to, int from);
+int read_stdin_bufferred(char *c);
Common subdirectories: dash-0.5.4/src/.deps and dash-0.5.4-patched/src/.deps
diff -puN dash-0.5.4/src/eval.c dash-0.5.4-patched/src/eval.c
--- dash-0.5.4/src/eval.c	2007-07-13 10:26:42.0 +0200
+++ dash-0.5.4-patched/src/eval.c	2010-09-04 12:24:55.0 +0200
@@ -64,6 +64,8 @@
 #include myhistedit.h
 #endif
 
+#include bufreadcmd.h
+
 
 /* flags in argument to evaltree */
 #define EV_EXIT 01		/* exit after evaluating tree */
@@ -543,11 +545,12 @@ evalpipe(union node *n, int flags)
 close(pip[0]);
 			}
 			if (prevfd  0) {
-dup2(prevfd, 0);
+dup2_wrapper(prevfd, 0);
+
 close(prevfd);
 			}
 			if (pip[1]  1) {
-dup2(pip[1], 1);
+dup2_wrapper(pip[1], 1);
 close(pip[1]);
 			}
 			evaltreenr(lp-n, flags);
@@ -625,7 +628,7 @@ evalbackcmd(union node *n, struct backcm
 			FORCEINTON;
 			close(pip[0]);
 			if (pip[1] != 1) {
-dup2(pip[1], 1);
+dup2_wrapper(pip[1], 1);
 close(pip[1]);
 			}
 			eflag = 0;
diff -puN dash-0.5.4/src/Makefile dash-0.5.4-patched/src/Makefile
--- dash-0.5.4/src/Makefile	2010-09-04 13:06:05.0 +0200
+++ dash-0.5.4-patched/src/Makefile	2010-09-04 13:08:26.0 +0200
@@ -57,7 +57,7 @@ am__objects_1 = alias.$(OBJEXT) arith_yy
 	miscbltin.$(OBJEXT) mystring.$(OBJEXT) options.$(OBJEXT) \
 	parser.$(OBJEXT) redir.$(OBJEXT) show.$(OBJEXT) trap.$(OBJEXT) \
 	output.$(OBJEXT) printf.$(OBJEXT) system.$(OBJEXT) \
-	test.$(OBJEXT) times.$(OBJEXT) var.$(OBJEXT)
+	test.$(OBJEXT) times.$(OBJEXT) var.$(OBJEXT) bufreadcmd.$(OBJEXT)
 am_dash_OBJECTS = $(am__objects_1) arith.$(OBJEXT)
 dash_OBJECTS = $(am_dash_OBJECTS)
 dash_DEPENDENCIES = builtins.o init.o nodes.o signames.o syntax.o
@@ -169,14 +169,14 @@ dash_CFILES = \
 	alias.c arith_yylex.c cd.c error.c eval.c exec.c expand.c \
 	histedit.c input.c jobs.c mail.c main.c memalloc.c miscbltin.c \
 	mystring.c options.c parser.c redir.c show.c trap.c output.c \
-	bltin/printf.c system.c bltin/test.c bltin/times.c var.c
+	bltin/printf.c system.c bltin/test.c bltin/times.c var.c bufreadcmd.c

Bug#595063: read() builtin doesn't read integer value /proc files (but bash's does)

[Steve Schnepp]

2010/9/2 Jilles Tjoelker jil...@stack.nl:

Thanks for your prompt reply.

 Note that a change in the file between the single-byte reads will cause
 an inconsistent value to be read. This is also the case with regular
 files on a filesystem, so it is acceptable.

Are you implying that:
- if the procfs is made to support char per char reads, dash reading
an inconsistent value is actually a feature ?
- buffering should, therefore, always be explicit ?

On a side note, the whole procfs seems to be designed around one
unique page read if possible (1x 4K).
I think it does so in order to be able to vastly simplify its
usage/implementation by kernel modules.

 If single-byte reads are really unacceptable, then the proper way to
 read these files needs to be documented, and clear violations that will
 not work properly should cause an error (in this case, this means that
 reading one byte from offset 0 should fail like reading one byte from
 offset 1 does).

+1 for the proper way to read these files needs to be documented and
I also think that emitting an error would be better than silently
returning erroneous data. [ EOVERFLOW is coming to my mind ]

--
Steve Schnepp
http://blog.pwkf.org/



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#595063: read() builtin doesn't read integer value /proc files (but bash's does)

[Steve Schnepp]

2010/9/1 Steve Schnepp steve.schn...@gmail.com:
 conforming to POSIX isn't a realistic option, would it be possible to
 have a workaround that doesn't involve an external tool like cat(1) ?

Hi, I just hacked  attached a little patch away to be able to solve this case.
Feel free to reply with your comments.

NB: I just targeted dash-0.5.5.1, but it might apply to any version.

--
Steve Schnepp
http://blog.pwkf.org/


chunked_bltin_read.diff
Description: Binary data

Bug#595063: read() builtin doesn't read integer value /proc files but bash's does

[Steve Schnepp]

Hi, I opened bug 595063 on the debian BTS [1] and I was suggested to resend
the email upstream.

So I copied the body of the bug below :

dash's read() builtin seems to read the underlying file 1 char at a
time. This doesn't work with some files under /proc, since procfs isn't
fully POSIX compliant.

With bash it works :

$ bash -c 'read MAX  /proc/sys/kernel/pid_max; echo $MAX'
32768

With dash it only reads the first character :

$ dash -c 'read MAX  /proc/sys/kernel/pid_max; echo $MAX'
3

If we use the cat(1) external program it works :

$ dash -c 'MAX=$(cat /proc/sys/kernel/pid_max); echo $MAX'
32768

After a little digging, it only appears on files that contains just an
integer value. When asked to read with a non-null offset (*ppos != 0),
__do_proc_dointvec() just returns 0 (meaning an EOF) as shown on [2].

I'm aware that the issue isn't strictly a dash one, since it has the
right to read one character at a time. But since fixing procfs to be
conforming to POSIX isn't a realistic option, would it be possible to
have a workaround that doesn't involve an external tool like cat(1) ?

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=595063
[2] http://lxr.linux.no/#linux+v2.6.32/kernel/sysctl.c#L2371

-- 
Steve Schnepp
http://blog.pwkf.org/

Bug#595063: read() builtin doesn't read integer value /proc files (but bash's does)

[Steve Schnepp]

Hi, I opened bug 595063 on the debian BTS [1] and I was suggested to
resend the email upstream.

So I copied the body of the bug below :

dash's read() builtin seems to read the underlying file 1 char at a
time. This doesn't work with some files under /proc, since procfs isn't
fully POSIX compliant.

With bash it works :

$ bash -c 'read MAX  /proc/sys/kernel/pid_max; echo $MAX'
32768

With dash it only reads the first character :

$ dash -c 'read MAX  /proc/sys/kernel/pid_max; echo $MAX'
3

If we use the cat(1) external program it works :

$ dash -c 'MAX=$(cat /proc/sys/kernel/pid_max); echo $MAX'
32768

After a little digging, it only appears on files that contains just an
integer value. When asked to read with a non-null offset (*ppos != 0),
__do_proc_dointvec() just returns 0 (meaning an EOF) as shown on [2].

I'm aware that the issue isn't strictly a dash one, since it has the
right to read one character at a time. But since fixing procfs to be
conforming to POSIX isn't a realistic option, would it be possible to
have a workaround that doesn't involve an external tool like cat(1) ?

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=595063
[2] http://lxr.linux.no/#linux+v2.6.32/kernel/sysctl.c#L2371
--
Steve Schnepp
http://blog.pwkf.org/



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#595063: dash: read() builtin doesn't work with /proc files containing only an integer value

[Steve Schnepp]

Package: dash
Version: 0.5.4-12
Severity: normal


dash's read() builtin seems to read the underlying file 1 char at a
time. This doesn't work with some files under /proc, since procfs isn't
fully POSIX compliant. 


With bash it works : 

$ bash -c 'read MAX  /proc/sys/kernel/pid_max; ec
32768

With dash it only reads the first character :

$ dash -c 'read MAX  /proc/sys/kernel/pid_max; ec
3

If we use the cat(1) external program it works :

$ dash -c 'MAX=$(cat /proc/sys/kernel/pid_max); echo $MAX'
32768

After a little digging, it only appears on files that contains just an
integer value. When asked to read with a non-null offset (*ppos != 0),
__do_proc_dointvec() just returns 0 (meaning an EOF) as shown on [1].

[1] http://lxr.linux.no/#linux+v2.6.32/kernel/sysctl.c#L2371

I'm aware that the issue isn't strictly a dash one, since it has the
right to read one character at a time. But since fixing procfs to be
conforming to POSIX isn't a realistic option, would it be possible to
have a workaround that doesn't involve an external tool like cat(1) ? 

-- System Information:
Debian Release: 5.0.5
  APT prefers proposed-updates
  APT policy: (500, 'proposed-updates'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 2.6.32-bpo.3-686 (SMP w/1 CPU core)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages dash depends on:
ii  libc6   2.7-18lenny4 GNU C Library: Shared libraries

dash recommends no packages.

dash suggests no packages.

-- debconf information:
* dash/sh: true



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#583589: util-linux: fdisk does not detect the disksize

[Steve Schnepp]

Subject: util-linux: fdisk does not detect the disksize
Package: util-linux
Version: 2.16.2-0
Severity: important

*** Please type your report below this line ***

I installed successfully kfreebsd-i386 on ad0 on VMWare with an old
debian-installer version :
http://d-i.debian.org/daily-images/kfreebsd-i386/20090903-19:49/monolithic/mini.iso


But when I want to add a new disk, i cannot create a partition, since
fdisk doesn't manage to read the disk size :

-
# fdisk /dev/ad1
last_lba(): I don't know how to handle files with mode 20660
You will not be able to write the partition table.
You must set cylinders.
You can do this from the extra functions menu.

Command (m for help): p

Disk /dev/ad1: 0 MB, 0 bytes
255 heads, 63 sectors/track, 0 cylinders
-

fdisk cannot read the size for ad0 either, but it manages to print the
partition table.

-- Dmesg extract :
ad0: 4096MB VMware Virtual IDE Hard Drive 0001 at ata0-master UDMA33
ad1: 4096MB VMware Virtual IDE Hard Drive 0001 at ata0-slave UDMA33


-- System Information:
Debian Release: squeeze/sid
Architecture: kfreebsd-i386 (i686)

Kernel: kFreeBSD 8.0-1-686
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash

Versions of packages util-linux depends on:
ii  dpkg                    1.15.5.6         Debian package management system
ii  initscripts             2.87dsf-10       scripts for initializing and shutt
ii  install-info            4.13a.dfsg.1-5   Manage installed documentation in
ii  libblkid1               2.16.2-0         block device id library
ii  libc0.1                 2.10.2-6         Embedded GNU C Library: Shared lib
ii  libncurses5             5.7+20100313-2   shared libraries for terminal hand
ii  libuuid1                2.16.2-0         Universally Unique ID library
ii  lsb-base                3.2-23           Linux Standard Base 3.2 init scrip
ii  tzdata                  2010f-2          time zone and daylight-saving time
ii  zlib1g                  1:1.2.3.4.dfsg-3 compression library - runtime

util-linux recommends no packages.

Versions of packages util-linux suggests:
pn  dosfstools                    none     (no description available)
pn  kbd | console-tools           none     (no description available)
pn  util-linux-locales            none     (no description available)

-- no debconf information



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#464880: [munin-users] one minute intervals possible in 1.4?

[Steve Schnepp]

2009/12/5 Holger Levsen hol...@layer-acht.org

 # Make graphs show values per minute instead of per second
 #graph_period minute

 Does that really work now? I see http://munin.projects.linpro.no/ticket/5has
 been changed to Milestone 1.6 :-)


AFAIK it has more to do with the display of 60 MiB/min instead of 1 MiB/s
than with the munin-update frequency

-- 
Steve Schnepp
http://blog.pwkf.org/