Bug#930641: closed by Debian FTP Masters (Bug#1023560: Removed package(s) from unstable)

[Sergey B Kirpichev]

On Sun, Nov 06, 2022 at 10:12:34PM +, Debian Bug Tracking System wrote:
> This is an automatic notification regarding your Bug report
> which was filed against the guile-2.2-doc package:
> 
> #930641: r5rs.info missing
> 
> It has been closed by Debian FTP Masters .
> 
> Their explanation is attached below along with your original report.
 
> as the package guile-2.2 has just been removed from the Debian archive
> unstable we hereby close the associated bug reports.  We are sorry
> that we couldn't deal with your issue properly.

Wow.  Brave New Worl^WDebian.  Who cares that the issue is
valid for guile-3.0 as well?

Bug#966185: monit: new upstream version 5.27.0

[Sergey B Kirpichev]

On Fri, Jul 31, 2020 at 11:32:54AM +0200, Christian Göttsche wrote:
> > I would appreciate any help with this upgrade.  There seems to
> > be some issues with dh_autoreconf.
> >
> 
> I think they should be solved by using the upstream bootstrap script:
> 
> override_dh_autoreconf:
> dh_autoreconf ./bootstrap

Thank you, this workaround seems to be working.

Bug#966185: monit: new upstream version 5.27.0

[Sergey B Kirpichev]

tags 966185 +help
thanks

On Fri, 24 Jul 2020 14:24:50 +0200 =?UTF-8?Q?Christian_G=C3=B6ttsche?= 
 wrote:
> Since about a month there is a new upstream version 5.27.0 [1].
> It would be nice to see it packaged in Debian sid.

I would appreciate any help with this upgrade.  There seems to
be some issues with dh_autoreconf.

Bug#959024: Problems with uscan'ing on github from tracker.debian.org

[Sergey B Kirpichev]

Package: tracker.debian.org
Severity: important

Right now in https://tracker.debian.org/pkg/auto-07p I see:
-->8--
Problems while searching for a new upstream version

uscan had problems while searching for a new upstream version:

In watchfile debian/watch, reading webpage
  https://github.com/auto-07p/auto-07p/releases failed: 429 too many
  requests
-->8--

Set severity important to reflect the checker status (high).

Bug#902204: monit: spurious "monit alert -- Link up eth0" messages

[Sergey B Kirpichev]

tags 902204 +fixed-upstream
forwarded 902204 
https://bitbucket.org/tildeslash/monit/issues/840/regression-failed-link-check-generates
thanks

Bug#902204: Processed: Re: Bug#902204: monit: spurious "monit alert -- Link up eth0" messages

[Sergey B Kirpichev]

tag 902204 +pending
thanks

On Wed, Apr 22, 2020 at 08:48:49PM +0200, mart...@tildeslash.com wrote:
> Hello,
> 
> the problem is fixed: 
> https://bitbucket.org/tildeslash/monit/commits/f3bea23a52db

I'm glad to hear.  Please try post to the bug thread next time.

Will be 5.27.0 soon (May?) or I should rather port this fix,
which seems to be trivial.

> > On 5 Feb 2020, at 15:06, Debian Bug Tracking System  
> > wrote:
> > 
> > Processing commands for cont...@bugs.debian.org:
> > 
> >> severity 902204 normal
> > Bug #902204 [monit] monit: spurious "monit alert --  Link up eth0" messages
> > Severity set to 'normal' from 'important'
> >> thanks
> > Stopping processing here.
> > 
> > Please contact me if you need assistance.
> > -- 
> > 902204: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=902204
> > Debian Bug Tracking System
> > Contact ow...@bugs.debian.org with problems
> > 
> `

Bug#902204: monit: spurious "monit alert -- Link up eth0" messages

[Sergey B Kirpichev]

severity 902204 normal
thanks

Lowered bug severity to reflect upstream's one.

On Sun, 7 Jul 2019 09:16:45 +0300 Sergey B Kirpichev  
wrote:
> forwarded 902204 
> https://bitbucket.org/tildeslash/monit/issues/490/separate-link-down-and-link-error-event
> thanks
> 
> Martin, please correct me if I set wrong upstream issue for this bug.
> 
> On Tue, 19 Feb 2019 22:47:46 +0100 "mart...@tildeslash.com" 
>  wrote:
> > 
> > > On 19 Feb 2019, at 02:47, Vincent Lefevre  wrote:
> > > 
> > > Hi,
> > > 
> > > On 2019-02-18 22:51:50 +0100, mart...@tildeslash.com wrote:
> > >> Hello, the 5dc2681 is not bug.
> > > 
> > > Well, I assume that the bug was already present, but I think that it
> > > was 5dc2681 that made it visible.
> > > 
> > >> Vincent, please can you run Monit in debug mode and send output? (monit 
> > >> -vI)
> > > 
> > > When starting monit with the Ethernet cable unplugged:
> > > 
> > > # /usr/bin/monit -c /etc/monit/monitrc -vI
> > > Runtime constants:
> > > Control file   = /etc/monit/monitrc
> > > Log file   = /var/log/monit.log
> > > Pid file   = /run/monit.pid
> > > Id file= /var/lib/monit/id
> > > State file = /var/lib/monit/state
> > > Debug  = True
> > > Log= True
> > > Use syslog = False
> > > Is Daemon  = True
> > > Use process engine = True
> > > Limits = {
> > >=   programOutput: 512 B
> > >=   sendExpectBuffer:  256 B
> > >=   fileContentBuffer: 512 B
> > >=   httpContentBuffer: 1 MB
> > >=   networkTimeout:5 s
> > >=   programTimeout:5 m
> > >=   stopTimeout:   30 s
> > >=   startTimeout:  30 s
> > >=   restartTimeout:30 s
> > >= }
> > > On reboot  = start
> > > Poll time  = 120 seconds with start delay 0 seconds
> > > Event queue= base directory /var/lib/monit/events with 100 slots
> > > Mail server(s) = localhost:25 with timeout 30 s
> > > Start monit httpd  = False
> > > Alert mail to  = vinc...@vinc17.net
> > >   Alert on = All events
> > > 
> > > The service list contains the following entries:
> > > 
> > > Network Name  = eth0
> > > Interface= eth0
> > > Monitoring mode  = active
> > > On reboot= start
> > > Link status  = if failed then alert
> > > Link capacity= if changed then alert

Bug#944282: stretch-pu: monit 1:5.20.0-6+deb9u1

[Sergey B Kirpichev]

On Tue, Jan 28, 2020 at 08:37:37AM +, Adam D. Barratt wrote:
> On 2019-11-07 08:49, Sergey B Kirpichev wrote:
> > I would like to make an upload to stable in order to fix bug
> > #941895 (CSRF check) in the monit package.
> 
> Please go ahead; sorry for the delay.

Thanks, uploaded.

Bug#806941: Re: Bug#806941: Change upstream for lib-apache2-mod-rpaf

[Sergey B Kirpichev]

On Fri, Jan 10, 2020 at 03:51:35PM +0100, Marco d'Itri wrote:
> - you orphan the package and let somebody else adopt it so that they can 
>   package a modern version

I did, long time ago.

Bug#941895: monit: invalid CSRF check causes login issues

[Sergey B Kirpichev]

On Mon, Nov 04, 2019 at 12:10:48PM +, Jonathan Wiltshire wrote:
> Yes, that seems to solve it - thanks for your patience.

Thank you for feedback!

I've sent bugreport against release.debian.org:
https://bugs.debian.org/944282

Maybe next year the package will be uploaded.

Bug#944282: stretch-pu: monit 1:5.20.0-6+deb9u1

[Sergey B Kirpichev]

Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu

Dear Release Team,

I would like to make an upload to stable in order to fix bug
#941895 (CSRF check) in the monit package.

Package on mentors.d.n:
https://mentors.debian.net/package/monit

The full patch between this new package version and the version
1:5.20.0-6 currently in Stretch is attached.
diff -Nru monit-5.20.0/debian/changelog monit-5.20.0/debian/changelog
--- monit-5.20.0/debian/changelog	2017-01-11 16:48:27.0 +0300
+++ monit-5.20.0/debian/changelog	2019-10-09 15:47:31.0 +0300
@@ -1,3 +1,9 @@
+monit (1:5.20.0-6+deb9u1) stretch; urgency=medium
+
+  * Implement position independent CSRF cookie value (Closes: #941895).
+
+ -- Sergey B Kirpichev   Wed, 09 Oct 2019 15:47:31 +0300
+
 monit (1:5.20.0-6) unstable; urgency=medium
 
   * Fix regression from #849886, test monit.log existence (Closes: #850829)
diff -Nru monit-5.20.0/debian/patches/12_PID_CSRF.patch monit-5.20.0/debian/patches/12_PID_CSRF.patch
--- monit-5.20.0/debian/patches/12_PID_CSRF.patch	1970-01-01 03:00:00.0 +0300
+++ monit-5.20.0/debian/patches/12_PID_CSRF.patch	2019-10-09 15:47:31.0 +0300
@@ -0,0 +1,109 @@
+Origin: https://bitbucket.org/tildeslash/monit/commits/f9a9a7a92
+Description: Position independent CSRF cookie value
+Bug-Debian: https://bugs.debian.org/941895
+
+---
+ src/http/processor.c |   61 +--
+ 1 file changed, 45 insertions(+), 16 deletions(-)
+
+--- a/src/http/processor.c
 b/src/http/processor.c
+@@ -258,7 +258,7 @@ void set_header(HttpResponse res, const
+ for (n = p = res->headers; p; n = p, p = p->next) {
+ if (IS(p->name, name)) {
+ FREE(p->value);
+-p->value = Str_dup(value);
++p->value = Str_dup(h->value);
+ destroy_entry(h);
+ return;
+ }
+@@ -288,6 +288,7 @@ void set_status(HttpResponse res, int co
+  * @param mime Mime content type, e.g. text/html
+  */
+ void set_content_type(HttpResponse res, const char *mime) {
++ASSERT(mime);
+ set_header(res, "Content-Type", "%s", mime);
+ }
+ 
+@@ -720,9 +721,11 @@ static void destroy_entry(void *p) {
+ /* - Checkers/Validators */
+ 
+ 
+-/**
+- * Do Basic Authentication if this auth. style is allowed.
+- */
++static boolean_t _isCookieSeparator(int c) {
++return (c == ' ' || c == '\n' || c == ';' || c == ',');
++}
++
++
+ static boolean_t is_authenticated(HttpRequest req, HttpResponse res) {
+ if (Run.httpd.credentials) {
+ if (! basic_authenticate(req)) {
+@@ -734,28 +737,54 @@ static boolean_t is_authenticated(HttpRe
+ }
+ if (IS(req->method, METHOD_POST)) {
+ // Check CSRF double-submit cookie (https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet#Double_Submit_Cookie)
+-const char *cookie = get_header(req, "Cookie");
+ const char *token = get_parameter(req, "securitytoken");
+-if (! cookie) {
+-LogError("HttpRequest: access denied -- client [%s]: missing CSRF token cookie\n", NVLSTR(Socket_getRemoteHost(req->S)));
+-send_error(req, res, SC_FORBIDDEN, "Invalid CSRF Token");
+-return false;
+-}
+ if (! token) {
+ LogError("HttpRequest: access denied -- client [%s]: missing CSRF token in HTTP parameter\n", NVLSTR(Socket_getRemoteHost(req->S)));
+ send_error(req, res, SC_FORBIDDEN, "Invalid CSRF Token");
+ return false;
+ }
+-if (! Str_startsWith(cookie, "securitytoken=")) {
+-LogError("HttpRequest: access denied -- client [%s]: no CSRF token in cookie\n", NVLSTR(Socket_getRemoteHost(req->S)));
++const char *cookie = get_header(req, "Cookie");
++if (! cookie) {
++LogError("HttpRequest: access denied -- client [%s]: missing CSRF token cookie\n", NVLSTR(Socket_getRemoteHost(req->S)));
+ send_error(req, res, SC_FORBIDDEN, "Invalid CSRF Token");
+ return false;
+ }
+-if (Str_compareConstantTime(cookie + 14, token)) {
+-LogError("HttpRequest: access denied -- client [%s]: CSRF token mismatch\n", NVLSTR(Socket_getRemoteHost(req->S)));
+-send_error(req, res

Bug#936164: auto-07p: Python2 removal in sid/bullseye

[Sergey B Kirpichev]

tags 937695 +pending +upstream +fixed-upstream
thanks

It seems, Python3-compatible release will be available
soon: https://github.com/auto-07p/auto-07p/issues/2

On Fri, 30 Aug 2019 07:10:54 + Matthias Klose  wrote:
> Package: src:auto-07p
> Version: 0.9.1+dfsg-7
> Severity: normal
> Tags: sid bullseye
> User: debian-pyt...@lists.debian.org
> Usertags: py2removal
> 
> Python2 becomes end-of-live upstream, and Debian aims to remove
> Python2 from the distribution, as discussed in
> https://lists.debian.org/debian-python/2019/07/msg00080.html
> 
> Your package either build-depends, depends on Python2, or uses Python2
> in the autopkg tests.  Please stop using Python2, and fix this issue
> by one of the following actions.
> 
> - Convert your Package to Python3. This is the preferred option.  In
>   case you are providing a Python module foo, please consider dropping
>   the python-foo package, and only build a python3-foo package.  Please
>   don't drop Python2 modules, which still have reverse dependencies,
>   just document them.
>   
>   This is the preferred option.
> 
> - If the package is dead upstream, cannot be converted or maintained
>   in Debian, it should be removed from the distribution.  If the
>   package still has reverse dependencies, raise the severity to
>   "serious" and document the reverse dependencies with the BTS affects
>   command.  If the package has no reverse dependencies, confirm that
>   the package can be removed, reassign this issue to ftp.debian.org,
>   make sure that the bug priority is set to normal and retitle the
>   issue to "RM: PKG -- removal triggered by the Python2 removal".
> 
> - If the package has still many users (popcon >= 300), or is needed to
>   build another package which cannot be removed, document that by
>   adding the "py2keep" user tag (not replacing the py2remove tag),
>   using the debian-pyt...@lists.debian.org user.  Also any
>   dependencies on an unversioned python package (python, python-dev)
>   must not be used, same with the python shebang.  These have to be
>   replaced by python2/python2.7 dependencies and shebang.
> 
>   This is the least preferred option.
> 
> If the conversion or removal needs action on another package first,
> please document the blocking by using the BTS affects command, like
> 
>   affects  + src:auto-07p
> 
> If there is no py2removal bug for that reverse-dependency, please file
> a bug on this package (similar to this bug report).
> 
> If there are questions, please refer to the wiki page for the removal:
> https://wiki.debian.org/Python/2Removal, or ask for help on IRC
> #debian-python, or the debian-pyt...@lists.debian.org mailing list.
> 
> 

Bug#941895: (no subject)

[Sergey B Kirpichev]

cont...@bugs.debian.org
Bcc: 
Subject: Re: Bug#941895: monit: invalid CSRF check causes login issues
Reply-To: skirpic...@gmail.com
In-Reply-To: <20191009143716.GA17535@note>
X-Debbugs-No-Ack: no, please

tags 941895 +moreinfo
thanks

Ok, I'll wait for feedback for 2 weeks.

On Wed, 9 Oct 2019 17:37:16 +0300 Sergey B Kirpichev  
wrote:
> On Mon, Oct 07, 2019 at 12:15:13PM +0100, Jonathan Wiltshire wrote:
> > I'm happy to sponsor uploads to the stable suites, certainly. You will
> > need approval from the stable release managers first then, and I will
> > avoid wearing that hat for this case in order to avoid a conflict of
> > interest.
> 
> I think, I can handle stable uploads myself, as I did previously.  But
> if not (release managers may be unhappy with changes) - backports is
> only option.
> 
> Meanwhile, I'll raise issue severity (only important+ bugfixes
> can enter point releases).
> 
> > I don't monitor monit (haha) or sponsorship-requests generally, so drop
> > me a mail when you are ready for it to be uploaded.
> 
> I've cherry-picked
> https://bitbucket.org/tildeslash/monit/commits/f9a9a7a92
> - please test package.  It was uploaded to the mentors.d.n:
> https://mentors.debian.net/package/monit
> 
> Please test.
> 
> 

Bug#941895: monit: invalid CSRF check causes login issues

[Sergey B Kirpichev]

severity 941895 important
thanks

On Mon, Oct 07, 2019 at 12:15:13PM +0100, Jonathan Wiltshire wrote:
> I'm happy to sponsor uploads to the stable suites, certainly. You will
> need approval from the stable release managers first then, and I will
> avoid wearing that hat for this case in order to avoid a conflict of
> interest.

I think, I can handle stable uploads myself, as I did previously.  But
if not (release managers may be unhappy with changes) - backports is
only option.

Meanwhile, I'll raise issue severity (only important+ bugfixes
can enter point releases).

> I don't monitor monit (haha) or sponsorship-requests generally, so drop
> me a mail when you are ready for it to be uploaded.

I've cherry-picked
https://bitbucket.org/tildeslash/monit/commits/f9a9a7a92
- please test package.  It was uploaded to the mentors.d.n:
https://mentors.debian.net/package/monit

Please test.

Bug#941895: monit: invalid CSRF check causes login issues

[Sergey B Kirpichev]

tags 941895 +moreinfo
thanks

On Mon, Oct 07, 2019 at 11:33:34AM +0100, Jonathan Wiltshire wrote:
> Please consider backporting this fix to stretch in the next oldstable
> point release. I haven't investigated whether it is the sole change in
> 5.21 or whether it would have to be cherry-picked.

5.21 should work, yes.   BTW, why you can't use the stable backport?

Are you able to sponsor oldstable backport?  See
https://bugs.debian.org/887350 - the previous stretch backport
was sitting on the mentors.d.n more than year...

Bug#941075: monit: no systemctl file for monit

[Sergey B Kirpichev]

tags 941075 +unreproducible
thanks

On Tue, Sep 24, 2019 at 04:34:21PM +0200, Han Boetes wrote:
>No, it means you can close the bug, and absolutely nothing else.

Why you open an issue, if you are not intended to help with it's
solution?

Lets reiterate my question:
--->8--
I don't understand.  What conditions lead to the state "monit not
running"?
-->8--
Could you help with this?

Bug#941075: monit: no systemctl file for monit

[Sergey B Kirpichev]

On Tue, Sep 24, 2019 at 03:44:03PM +0200, Han Boetes wrote:
>Never you mind, you can close the bug.

Is that means the problem was identified right, i.e. you are
using initscript /etc/init.d/monit directly?

>On Tue, Sep 24, 2019 at 12:06 PM Sergey B Kirpichev
><[1]skirpic...@gmail.com> wrote:
>  I don't understand.  What conditions lead to the state "monit not
>  running"?
> 
>  Perhaps, you have system with systemd, but manage monit using
>  /etc/init.d/monit
>  script directly.  You shouldn't do it, this makes systemd crazy, but
>  this is not a monit's problem.
> 
>  Use systemctl to start/stop/reload monit on systemd-enabled
>  hosts - and everything should work and systemd will be happy.  Please
>  let me know if you still have problems after using this suggestion.

Bug#941075: monit: no systemctl file for monit

[Sergey B Kirpichev]

tags 941075 +moreinfo
thanks

On Tue, Sep 24, 2019 at 11:38:52AM +0200, Han Boetes wrote:
> The current monit package does not include a systemctl file, often resulting 
> in
> monit not running. If I'd check the status with systemctl the result was:
> active(exited) see also: https://unix.stackexchange.com/questions/241970/what-
> does-status-active-exited-mean-for-a-systemd-service

I don't understand.  What conditions lead to the state "monit not
running"?

Perhaps, you have system with systemd, but manage monit using /etc/init.d/monit
script directly.  You shouldn't do it, this makes systemd crazy, but
this is not a monit's problem.

Use systemctl to start/stop/reload monit on systemd-enabled
hosts - and everything should work and systemd will be happy.  Please
let me know if you still have problems after using this suggestion.

> Easy fix: add a systemd file and remove the /etc/init.d/monit file

Are you volunteered to debug and fix any problems with systemd-enabled
setups and this unit file?  Please look to the README.Debian: monit can
work with systemd, but it would be better, if you avoid this use case.

Bug#931974: O: festvox-ru - Russian male speaker for Festival

[Sergey B Kirpichev]

On Sun, Jul 28, 2019 at 05:23:17PM +0200, Samuel Thibault wrote:
> Sergey B Kirpichev, le dim. 28 juil. 2019 17:52:29 +0300, a ecrit:
> > On Sun, Jul 28, 2019 at 04:44:25PM +0200, Samuel Thibault wrote:
> > > We can maintain this along the other voices under the tts-team umbrella.
> > > I have added you to the tts-team group on salsa, I guess this is enough
> > > for you to transfer the salsa project?
> > 
> > What exactly I should do?
> 
> On salsa, on your festvox-ru project page, in the Settings panel, in the
> General subpanel, Expand the Advanced section, and in the Transfert
> Project box, you should be able to choose "Debian TTS Maintainers". If
> it doesn't appear in the list, I'll increase your access to the group.

Thank you, I did.  Hopefully, everything ok.

Bug#931974: O: festvox-ru - Russian male speaker for Festival

[Sergey B Kirpichev]

On Sun, Jul 28, 2019 at 04:44:25PM +0200, Samuel Thibault wrote:
> We can maintain this along the other voices under the tts-team umbrella.
> I have added you to the tts-team group on salsa, I guess this is enough
> for you to transfer the salsa project?

What exactly I should do?

Bug#931972: Bug#930637: unblock: monit/1:5.25.2-3+deb10u1

[Sergey B Kirpichev]

On Wed, Jul 17, 2019 at 06:56:53AM +0200, Sebastiaan Couwenberg wrote:
> buster-backports is now open, but the monit package cannot be uploaded
> to it in its current shape.
> 
> The version is not correct: 5.26.0-1~bpo9+1
> 
> For buster-backports '~bpo10+1` should be used.
> 
> Beware that `dch --bpo` still defaults to stretch-backports on buster,
> so you need to change the distribution and changelog entry to
> buster-backports too.

Yes, broken dch was the reason.  I didn't fix changelog fully.

I hope, that fixed now.  Sorry.

https://mentors.debian.net/debian/pool/main/m/monit/monit_5.26.0-1~bpo10+1.dsc

> The .orig.tar.gz is not available on mentors, and there is no
> buster-backports branch in the repo on Salsa yet, so the package cannot
> be built currently.
> 
> Please push the buster-backports branch to Salsa, I'll take it from there.

Pushed too.

Bug#930637: unblock: monit/1:5.25.2-3+deb10u1

[Sergey B Kirpichev]

On Sun, 7 Jul 2019 08:29:08 +0200 Sebastiaan Couwenberg  
wrote:
> Please upload a new revision to unstable with source-only changes...

Backport for Buster:
https://mentors.debian.net/package/monit
Please sponsor this package.

Sponsorship request:
https://bugs.debian.org/931972

Bug#931974: O: festvox-ru - Russian male speaker for Festival

[Sergey B Kirpichev]

Package: wnpp
Severity: normal

I am winding down my involvement in Debian to a minimum and I have
no intentions to support this package anymore.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

Bug#931972: RFS: monit/1:5.26.0-1~bpo9+1 -- backport for buster

[Sergey B Kirpichev]

Package: sponsorship-requests
Severity: normal

I am looking for a sponsor for my backport package "monit":

To access further information about this package, please visit the
following URL:

https://mentors.debian.net/package/monit

Bug#931973: O: libapache2-mod-qos - quality of service module for the apache2

[Sergey B Kirpichev]

Package: wnpp
Severity: normal

I am winding down my involvement in Debian to a minimum and I have
no intentions to support this package anymore.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

Bug#930637: unblock: monit/1:5.25.2-3+deb10u1

[Sergey B Kirpichev]

On Sun, Jul 07, 2019 at 08:29:08AM +0200, Sebastiaan Couwenberg wrote:
> Please upload a new revision to unstable with source-only changes to

I did just now (5.26.0).

Bug#902204: monit: spurious "monit alert -- Link up eth0" messages

[Sergey B Kirpichev]

forwarded 902204 
https://bitbucket.org/tildeslash/monit/issues/490/separate-link-down-and-link-error-event
thanks

Martin, please correct me if I set wrong upstream issue for this bug.

On Tue, 19 Feb 2019 22:47:46 +0100 "mart...@tildeslash.com" 
 wrote:
> 
> > On 19 Feb 2019, at 02:47, Vincent Lefevre  wrote:
> > 
> > Hi,
> > 
> > On 2019-02-18 22:51:50 +0100, mart...@tildeslash.com wrote:
> >> Hello, the 5dc2681 is not bug.
> > 
> > Well, I assume that the bug was already present, but I think that it
> > was 5dc2681 that made it visible.
> > 
> >> Vincent, please can you run Monit in debug mode and send output? (monit 
> >> -vI)
> > 
> > When starting monit with the Ethernet cable unplugged:
> > 
> > # /usr/bin/monit -c /etc/monit/monitrc -vI
> > Runtime constants:
> > Control file   = /etc/monit/monitrc
> > Log file   = /var/log/monit.log
> > Pid file   = /run/monit.pid
> > Id file= /var/lib/monit/id
> > State file = /var/lib/monit/state
> > Debug  = True
> > Log= True
> > Use syslog = False
> > Is Daemon  = True
> > Use process engine = True
> > Limits = {
> >=   programOutput: 512 B
> >=   sendExpectBuffer:  256 B
> >=   fileContentBuffer: 512 B
> >=   httpContentBuffer: 1 MB
> >=   networkTimeout:5 s
> >=   programTimeout:5 m
> >=   stopTimeout:   30 s
> >=   startTimeout:  30 s
> >=   restartTimeout:30 s
> >= }
> > On reboot  = start
> > Poll time  = 120 seconds with start delay 0 seconds
> > Event queue= base directory /var/lib/monit/events with 100 slots
> > Mail server(s) = localhost:25 with timeout 30 s
> > Start monit httpd  = False
> > Alert mail to  = vinc...@vinc17.net
> >   Alert on = All events
> > 
> > The service list contains the following entries:
> > 
> > Network Name  = eth0
> > Interface= eth0
> > Monitoring mode  = active
> > On reboot= start
> > Link status  = if failed then alert
> > Link capacity= if changed then alert
> > 
> > System Name   = zira
> > Monitoring mode  = active
> > On reboot= start
> > 
> > ---

Bug#930637: unblock: monit/1:5.25.2-3+deb10u1

[Sergey B Kirpichev]

On Thu, Jul 04, 2019 at 02:13:03PM +0200, Bas Couwenberg wrote:
> How often do you expect to need NEW processing for monit?

Probably, once every major release.  Backport is a frequent request.

> Do you know any users of the package who have contributed patches or other
> maintainer type bugreports that could be recruited to help co-maintain the
> package?

Yes, take look in the history.  Someone was added to Uploaders, but
after year+ of inactivity - I've decided to remove that contributor.

> My strong preference is for you to maintain the backport as you are the most
> able maintainer of the package, so I hope we can find a solution where I can
> support you with the unpleasant bureaucracy to enable you keep doing your
> work on the monit package (and its backports).

Ok, ping me (e.g. with a bug), when this option will be available.  I'll
provide a package after few days.

Bug#930637: unblock: monit/1:5.25.2-3+deb10u1

[Sergey B Kirpichev]

On Thu, Jul 04, 2019 at 12:48:23PM +0200, Bas Couwenberg wrote:
> The RT ticket show that you were added to the backports ACL

It doesn't help too much: initial upload must be sponsored.

> I guess Michal
> wasn't available to sponsor your initial backports upload

Unfortunately, nobody wasn't available to sponsor for a
year.  But now we have Anti-Harassment Team.  Hooray!

> Are you willing to maintain the monit backport if I sponsor the NEW uploads

No.  Next time _you_ may be unavailable to sponsor backport for
a buster+1.  I won't give package users impression that backports
are supported, when it's not the case.

Feel free to provide backport yourself.  I also can add you as
a co-maintainer and/or step down as a package maintainer.

Bug#930637: unblock: monit/1:5.25.2-3+deb10u1

[Sergey B Kirpichev]

On Thu, Jul 04, 2019 at 10:31:07AM +0200, Bas Couwenberg wrote:
> We rely on monit at $DAYJOB, so I want to help you get monit back in buster.

Am afraid, there is no chance for monit to enter buster.  Sorry for this
situation, but I believe this is not just my fault (see this bug
thread).  Anyway, if you know someone, who can offer better support
for monit in the debian - just tell.  I will appreciate any help
and/or may step down as a maintainer.

> I'm somewhat reluctantly willing to maintain the monit backport
> if you don't want to main the package in backports.

Sure, do.

> Are you willing to maintain monit in backports if the stable update is not
> accepted?

I will not try again to spend my time for providing backports.  Feel
free to waste your time.

Bug#930637: unblock: monit/1:5.25.2-3+deb10u1

[Sergey B Kirpichev]

On Thu, Jul 04, 2019 at 10:54:10AM +0200, Paul Gevers wrote:
> Once packages can migrate normally again (somewhere next week if
> everything goes as expected), monit will be back in testing and
> backports is a viable option.

Feel free to do backport.

Latest one was dated Fri, 21 Dec 2018 (https://bugs.debian.org/887350).
No luck.  Have fun with the debian bureaucracy.

Bug#930637: unblock: monit/1:5.25.2-3+deb10u1

[Sergey B Kirpichev]

On Thu, Jun 27, 2019 at 01:40:42PM +0200, Paul Gevers wrote:
> We're sorry, but we'll be removing monit from buster shortly.

Thanks for a great release menagement!

Bug#930637: unblock: monit/1:5.25.2-3+deb10u1

[Sergey B Kirpichev]

On Tue, Jun 18, 2019 at 08:21:38PM +0200, Paul Gevers wrote:
> Can you ask somebody else to upload it then?

No.

Bug#930637: unblock: monit/1:5.25.2-3+deb10u1

[Sergey B Kirpichev]

On Mon, 17 Jun 2019 21:19:07 +0200 Paul Gevers  wrote:
> we don't want packages going though it that don't need to.

monit package going to be removed from buster.  Maybe this
justifies migration from t-p-u?

I'm away from my build environment and hardly able to prepare
in time that you require for Sid.

Bug#930637: unblock: monit/1:5.25.2-3+deb10u1

[Sergey B Kirpichev]

On Mon, Jun 17, 2019 at 09:20:18PM +0200, Paul Gevers wrote:
> > This debdiff looks good. Can you please upload it as
> > 1:5.25.3-1+really5.25.2-1 (with the source tar ball of 1:5.25.2) to
> > unstable as requested in bug 930313. tpu isn't covered well by QA, so we
> > don't want packages going though it that don't need to.
> 
> Should have been 1:5.25.3+really5.25.2-1.

Could you kindly explain what's wrong with the
current version?  I don't understand why I should set an invalid
upstream version.

Bug#930641: r5rs.info missing

[Sergey B Kirpichev]

Package: guile-2.2-doc
Severity: important

The Guile manual has broken references to the r5rs.info,
which is not installed.

Bug#930637: unblock: monit/1:5.25.2-3+deb10u1

[Sergey B Kirpichev]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package monit in t-p-u.  The version
1:5.25.2-3+deb10u1 has only targeted fixes for security
issue #927775 (two CVE's).  See attached diff.
diff --git a/debian/changelog b/debian/changelog
index bd3d9b0..8712671 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+monit (1:5.25.2-3+deb10u1) testing-proposed-updates; urgency=medium
+
+  * Backport upstream fixes (Closes: #927775):
++ CVE-2019-11454 Persistent cross-site scripting (XSS) in http/cervlet.c
++ CVE-2019-11455 A buffer over-read in Util_urlDecode in util.c
+
+ -- Sergey B Kirpichev   Mon, 17 Jun 2019 10:57:40 +0300
+
 monit (1:5.25.2-3) unstable; urgency=medium
 
   * Spelling fixes in manpage
diff --git a/debian/patches/CVE-2019-11454.patch b/debian/patches/CVE-2019-11454.patch
new file mode 100644
index 000..ce73e8d
--- /dev/null
+++ b/debian/patches/CVE-2019-11454.patch
@@ -0,0 +1,20 @@
+Description: Fix CVE-2019-11454
+Origin: https://bitbucket.org/tildeslash/monit/commits/328f607
+Forwarded: not needed
+Bug-Debian: https://bugs.debian.org/927775
+
+---
+ src/http/cervlet.c |2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/src/http/cervlet.c
 b/src/http/cervlet.c
+@@ -906,7 +906,7 @@ static void do_viewlog(HttpRequest req,
+ StringBuffer_append(res->outputbuffer, "");
+ while ((n = fread(buf, sizeof(char), sizeof(buf) - 1, f)) > 0) {
+ buf[n] = 0;
+-StringBuffer_append(res->outputbuffer, "%s", buf);
++escapeHTML(res->outputbuffer, buf);
+ }
+ fclose(f);
+ StringBuffer_append(res->outputbuffer, "");
diff --git a/debian/patches/CVE-2019-11455.patch b/debian/patches/CVE-2019-11455.patch
new file mode 100644
index 000..3845fd3
--- /dev/null
+++ b/debian/patches/CVE-2019-11455.patch
@@ -0,0 +1,58 @@
+Description: Fix CVE-2019-11455
+Origin: https://bitbucket.org/tildeslash/monit/commits/f12d0cdb
+Forwarded: not needed
+Bug-Debian: https://bugs.debian.org/927775
+
+---
+ src/util.c |   16 +---
+ 1 file changed, 9 insertions(+), 7 deletions(-)
+
+--- a/src/util.c
 b/src/util.c
+@@ -233,7 +233,7 @@ static char *is_str_defined(char *s) {
+ /**
+  * Convert a hex char to a char
+  */
+-static char x2c(char *hex) {
++static char _x2c(char *hex) {
+ register char digit;
+ digit = ((hex[0] >= 'A') ? ((hex[0] & 0xdf) - 'A')+10 : (hex[0] - '0'));
+ digit *= 16;
+@@ -535,7 +535,7 @@ void Util_handleEscapes(char *buf) {
+  */
+ *(buf + insertpos) = *(buf+editpos);
+ } else {
+-*(buf + insertpos) = x2c([editpos + 3]);
++*(buf + insertpos) = _x2c([editpos + 3]);
+ editpos += 4;
+ }
+ }
+@@ -571,7 +571,7 @@ int Util_handle0Escapes(char *buf) {
+ switch (*(buf + editpos + 1)) {
+ case '0':
+ if (*(buf + editpos + 2) == 'x') {
+-*(buf + insertpos) = x2c([editpos+3]);
++*(buf + insertpos) = _x2c([editpos+3]);
+ editpos += 4;
+ }
+ break;
+@@ -1561,13 +1561,15 @@ char *Util_urlDecode(char *url) {
+ if (url && *url) {
+ register int x, y;
+ for (x = 0, y = 0; url[y]; x++, y++) {
+-if ((url[x] = url[y]) == '+')
++if (url[y] == '+') {
+ url[x] = ' ';
+-else if (url[x] == '%') {
+-if (! (url[x + 1] && url[x + 2]))
++} else if (url[y] == '%') {
++if (! url[y + 1] || ! url[y + 2])
+ break;
+-url[x] = x2c(url + y + 1);
++url[x] = _x2c(url + y + 1);
+ y += 2;
++} else {
++url[x] = url[y];
+ }
+ }
+ url[x] = 0;
diff --git a/debian/patches/series b/debian/patches/series
index 98bcb60..fc

Bug#927775: monit: CVE-2019-11454 CVE-2019-11455

[Sergey B Kirpichev]

On Wed, 12 Jun 2019 17:07:11 +0200 Ivo De Decker  wrote:
> As the security team considers this an issue that needs to be fixed for
> buster, I'm increasing the severity. Please do not downgrade it again.

Thanks for "help", security team.

> Note that the revert Paul mentioned in #930313

I don't understand what exactly he mean.  I'll try to upload
targeted fix to the testing-proposed-updates.

> Otherwise we'll be forced to remove monit from
> buster manually.

I'm fine with this.

Bug#927775: monit: CVE-2019-11454 CVE-2019-11455

[Sergey B Kirpichev]

On Sun, Jun 09, 2019 at 01:44:18PM +0200, Salvatore Bonaccorso wrote:
> I gave a reason though now in my previous mail

I was expecting such explanation before changing in severity...

> > > Could you please work out with the Release team via an unblock request
> > > if they would wave through the version or a sheduled a targeted fix
> > > via testing-proposed-updates?
> > 
> > Yes, I'm planing backports for these fixes.  I don't know why this
> > require increase in the bug severity.
> 
> Perfect, thanks! The increase in severity was done as per above, to
> make sure it is marked release critical and not missed for the
> release of buster.
> 
> I still do not get it why a new upstream version was uploaded to
> unstable at this point in the freeze, though.

I hope, release team will unblock transition, it's a bugfix release.

Bug#927775: monit: CVE-2019-11454 CVE-2019-11455

[Sergey B Kirpichev]

On Sun, Jun 09, 2019 at 12:08:21PM +0200, Salvatore Bonaccorso wrote:
> After some time passed, on 2019-06-03, another Debian security team
> member (Moritz Muehlenhoff ) raised the severity to a
> release critical value.

For no reasons.

> Could you please work out with the Release team via an unblock request
> if they would wave through the version or a sheduled a targeted fix
> via testing-proposed-updates?

Yes, I'm planing backports for these fixes.  I don't know why this
require increase in the bug severity.

Bug#927775: monit: CVE-2019-11454 CVE-2019-11455

[Sergey B Kirpichev]

severity 927775 important
thanks

No reasons, so revert back severity.

On Tue, 4 Jun 2019 08:00:43 +0300 Sergey B Kirpichev  
wrote:
> On Tue, 23 Apr 2019 06:53:03 +0200 Salvatore Bonaccorso  
> wrote:
> > CVE-2019-11454[0]:
> > | Persistent cross-site scripting (XSS) in http/cervlet.c in Tildeslash
> > | Monit before 5.25.3 allows a remote unauthenticated attacker to
> > | introduce arbitrary JavaScript via manipulation of an unsanitized user
> > | field of the Authorization header for HTTP Basic Authentication, which
> > | is mishandled during an _viewlog operation.
> > 
> > 
> > CVE-2019-11455[1]:
> > | A buffer over-read in Util_urlDecode in util.c in Tildeslash Monit
> > | before 5.25.3 allows a remote authenticated attacker to retrieve the
> > | contents of adjacent memory via manipulation of GET or POST
> > | parameters. The attacker can also cause a denial of service
> > | (application outage).
> 
> Why severity "grave"?  Seems wrong accordingly to the
> description in https://www.debian.org/Bugs/Developer#severities.
> 
> 

Bug#927775: monit: CVE-2019-11454 CVE-2019-11455

[Sergey B Kirpichev]

On Tue, 23 Apr 2019 06:53:03 +0200 Salvatore Bonaccorso  
wrote:
> CVE-2019-11454[0]:
> | Persistent cross-site scripting (XSS) in http/cervlet.c in Tildeslash
> | Monit before 5.25.3 allows a remote unauthenticated attacker to
> | introduce arbitrary JavaScript via manipulation of an unsanitized user
> | field of the Authorization header for HTTP Basic Authentication, which
> | is mishandled during an _viewlog operation.
> 
> 
> CVE-2019-11455[1]:
> | A buffer over-read in Util_urlDecode in util.c in Tildeslash Monit
> | before 5.25.3 allows a remote authenticated attacker to retrieve the
> | contents of adjacent memory via manipulation of GET or POST
> | parameters. The attacker can also cause a denial of service
> | (application outage).

Why severity "grave"?  Seems wrong accordingly to the
description in https://www.debian.org/Bugs/Developer#severities.

Bug#902204: monit: spurious "monit alert -- Link up eth0" messages

[Sergey B Kirpichev]

tags 902204 -moreinfo
thanks

On Sat, 22 Dec 2018 03:17:27 +0100 Vincent Lefevre  wrote:
> So, it seems to be a bug in the monit code that makes it think that
> the link is up while it is not.
> 
> In validate.c, I see:
> 
> [...]
> for (LinkStatus_T link = s->linkstatuslist; link; link = link->next) {
> Event_post(s, Event_Link, State_Succeeded, link->action, 
> "link data collection succeeded");
> }
> // State
> if (! Link_getState(s->inf.net->stats)) {
> for (LinkStatus_T link = s->linkstatuslist; link; link = 
> link->next)
> Event_post(s, Event_Link, State_Failed, link->action, 
> "link down");
> return State_Failed; // Terminate test if the link is down
> } else {
> for (LinkStatus_T link = s->linkstatuslist; link; link = 
> link->next)
> Event_post(s, Event_Link, State_Succeeded, 
> link->action, "link up");

Ok, CC upstream to see their opinion (I think this problem wasn't reported yet.)

Bug#919645: RFS: monit/1:5.25.2-2~bpo9+1 [BPO]

[Sergey B Kirpichev]

Package: sponsorship-requests
Severity: normal

I (current maintainer of the package) am looking for (6 or 7-th time?) a sponsor
for my backport of the package monit.

Package can be downloaded from m.d.n:
https://mentors.debian.net/package/monit

Bug#887350: monit: Request for a monit backport

[Sergey B Kirpichev]

On Mon, 24 Dec 2018 17:13:17 +0100 Antoine Joubert  
wrote:
> I wanted to let you know that I’ve not had any issues with your backport of 
> monit over the week-end.

Ok, I've requested (rt.debian.org ticket #7591) upload permissions for
backports queue, instead of asking 6 (or 7th) time for sponsorship.
No idea how long it will take, but then I'll upload package.

Bug#885224: nlopt: please migrate to guile-2.2

[Sergey B Kirpichev]

On Fri, 6 Jul 2018 15:29:48 +0200 Andreas Tille  wrote:
> I've checked this by simply replacing Build-Depends like this:
> 
> 
> diff --git a/debian/control b/debian/control
> index 600f8f1..ba9335d 100644
> --- a/debian/control
> +++ b/debian/control
> @@ -9,8 +9,8 @@ Build-Depends: debhelper (>= 11~),
> dh-octave,
> python-all-dev,
> python-numpy,
> -   guile-2.0,
> -   guile-2.0-dev,
> +   guile-2.2,
> +   guile-2.2-dev,
> dh-exec
>  Standards-Version: 4.1.4
>  Vcs-Browser: https://salsa.debian.org/science-team/nlopt
> @@ -175,7 +175,7 @@ Section: libs
>  Depends: libnlopt0 (= ${binary:Version}),
>   ${shlibs:Depends},
>   ${misc:Depends},
> - guile-2.0
> + guile-2.2
>  Pre-Depends: ${misc:Pre-Depends}
>  Description: nonlinear optimization library -- Guile bindings
>   NLopt is a free/open-source library for nonlinear optimization, providing
> 
> 
> Unfortunately this does not work and leads to build errors.  Some
> patches would be welcome.

I suspect, this is fixed in newer version, published
on Github.  I'll try to adapt package to build nlopt-2.5.0 (there
are some major changes like changing build system to cmake).

Bug#917025: tracker.debian.org: 0 new commits since last upload

[Sergey B Kirpichev]

Package: tracker.debian.org
Severity: normal

Not sure if this is a duplicate of #910987, but I see the problem.
Right now interface on https://tracker.debian.org/pkg/monit shows:
-->8--
 action needed
 0 new commits since last upload, time to upload? normal
 vcswatch reports that this package seems to have a new changelog entry
 (version 1:5.25.2-2, distribution unstable) and new commits in its VCS.
 You should consider whether it's time to make an upload.

 Here are the relevant commit messages:

 None

 Created: 2018-12-21 Last update: 2018-12-21 15:05
-->8---

Latest commit is 727f110b (tagged then, after several minutes,
everything was pushed to the public repo _before_ upload to
the debian archive was done).

Bug#902204: monit: spurious "monit alert -- Link up eth0" messages

[Sergey B Kirpichev]

On Fri, Dec 21, 2018 at 01:31:40PM +0100, Vincent Lefevre wrote:
> > > > monit is spamming me with spurious "monit alert --  Link up eth0"
> > > > messages every 2 minutes! I currently have no Ethernet cable, so
>  ^
> > > > that "Link up eth0" is wrong, and there are no recent lines about
>^^^
> > > > eth0 in the journalctl output.
> > 
> > Please, show /proc/net/dev on system, which is spamming.
> 
> Inter-|   Receive|  Transmit
>  face |bytespackets errs drop fifo frame compressed multicast|bytes
> packets errs drop fifo colls carrier compressed
>   eth0: 956331421  927630000 0  0  5275 101028194 
>  623527000 0   0  0
> 
> > > [CEST Jun 23 12:19:47] info : 'eth0' link data collection succeeded
> > > [CEST Jun 23 12:19:47] error: 'eth0' link down
> > 
> > It seems, you have an interface with cable unplugged.
> 
> Yes, as said above.

Ok, I see, thank you for patience.

Does it send you alert if you
remove "if changed link capacity then alert" line too, correct?
If so, I suspect that the currect monit's behaviour is correct and I suggest
you just adding "if failed link then unmonitor"-like line.

Bug#890683: monit: Invalid CSRF Token error on web interface

[Sergey B Kirpichev]

BTW, backport issue is here:
https://bugs.debian.org/887350

Backport was uploaded to mentors:
https://mentors.debian.net/package/monit

On Fri, 21 Dec 2018 11:26:18 +0300 Sergey B Kirpichev  
wrote:
> tag 890683 + upstream
> thanks
> 
> On Sat, 17 Feb 2018 18:28:37 +0100 Peter Baranyi  
> wrote:
> > I am always getting this error when clicking start/stop/restart/disable 
> > buttons
> > on the web interface:
> > Invalid CSRF Token
> > This makes the web interface read-only, actions cannot be carried out.
> > This error is already fixed in sid, version 1:5.25.1-1
> 
> I think, that the problem is fixed in
> https://bitbucket.org/tildeslash/monit/issues/495/invalid-csrf-check
> 
> So, everything should work in stable, if you will use a dedicated
> domain for the web interface.  Let me know if this workaround doesn't
> work.
> 
> For now, I don't think that issue is severe enough and there will
> be port of this fix to stable.  I hope, monit's backport will be available
> soon, so you can try it.
> 
> 

Bug#887350: monit: Request for a monit backport

[Sergey B Kirpichev]

tag 887350 +pending
thanks

On Mon, 15 Jan 2018 11:39:03 +0100 "Antoine J."  wrote:
> Since you've done it for jessie, I was wondering, would you be willing
> to backport the version of monit currently in debian unstable (5.25.1-1)
> to stretch ?

Please try this version:
https://mentors.debian.net/package/monit

Can you test that it works for you well?

Bug#890683: monit: Invalid CSRF Token error on web interface

[Sergey B Kirpichev]

tag 890683 + upstream
thanks

On Sat, 17 Feb 2018 18:28:37 +0100 Peter Baranyi  
wrote:
> I am always getting this error when clicking start/stop/restart/disable 
> buttons
> on the web interface:
> Invalid CSRF Token
> This makes the web interface read-only, actions cannot be carried out.
> This error is already fixed in sid, version 1:5.25.1-1

I think, that the problem is fixed in
https://bitbucket.org/tildeslash/monit/issues/495/invalid-csrf-check

So, everything should work in stable, if you will use a dedicated
domain for the web interface.  Let me know if this workaround doesn't
work.

For now, I don't think that issue is severe enough and there will
be port of this fix to stable.  I hope, monit's backport will be available
soon, so you can try it.

Bug#902204: monit: spurious "monit alert -- Link up eth0" messages

[Sergey B Kirpichev]

tag 902204 +moreinfo +unstable
thanks

On Sat, 23 Jun 2018 13:31:22 +0200 Vincent Lefevre  wrote:
> On 2018-06-23 12:52:56 +0200, Vincent Lefevre wrote:
> > With the following settings:
> > 
> > check network eth0 with interface eth0
> > if changed link capacity then alert
> > 
> > monit is spamming me with spurious "monit alert --  Link up eth0"
> > messages every 2 minutes! I currently have no Ethernet cable, so
> > that "Link up eth0" is wrong, and there are no recent lines about
> > eth0 in the journalctl output.

Please, show /proc/net/dev on system, which is spamming.

> [CEST Jun 23 12:19:47] info : 'eth0' link data collection succeeded
> [CEST Jun 23 12:19:47] error: 'eth0' link down

It seems, you have an interface with cable unplugged.

Bug#877633: test patch unstable

[Sergey B Kirpichev]

On Thu, 13 Dec 2018 19:56:07 + marc marc  wrote:
> I have tested the patch 
> https://salsa.debian.org/sk-guest/monit/commit/ac71b49a08b7f6aa23c185183ab87a64cae4e913
> error: Depend service 'sshd_dsa_key' is not defined in the control file
> 
> for the stable version, no template is indeed enable by default
> but If you install a monitoring with a template that kill a working 
> service, imho the bug can hardly be more important for a system such as 
> monit.
> at least in stable, a small fix like this is needed :

OK, the patch is working for stable, isn't?

What do you think about backporting monit, there is
https://bugs.debian.org/cgi-bin/887350
?  Is this an acceptable solution for you?

Bug#877633: this bug stop sshd

[Sergey B Kirpichev]

On Wed, Dec 12, 2018 at 08:38:51PM +0100, Jocelyn Jaubert wrote:
> We lost access to a debian stretch machine after sshd was killed by
> installing monit and openssh checker, like we did on previous debian
> version.

1) All configuration snippets povided - are disabled per default.
2) You should carefully read configuration file before turn it on.

Given this, I'm not sure that stable release managers accept a fix.

> Now we know how to solve it, we can put a workaround in the script
> installing monit, but other unaware people might hit the same issue.

But I'll try to provide a fix for stable release, asap.

Bug#877633: this bug stop sshd

[Sergey B Kirpichev]

On Wed, 12 Dec 2018 11:13:24 + marc marc  wrote:
> could the priority of the fix be increased accordingly ?

Are you about backporting existing fix to stable?  I'm not sure,
that the problem is too severe.

Bug#906499: parser-mysql: FTBFS in buster/sid (aclocal-1.15: command not found)

[Sergey B Kirpichev]

socket-ssl-perl (2.059-1) ...
Setting up libxml-simple-perl (2.25-1) ...
Setting up libnet-smtp-ssl-perl (1.04-1) ...
Setting up libmailtools-perl (2.18-1) ...
Setting up libemail-valid-perl (1.202-1) ...
Setting up lintian (2.5.102) ...
Processing triggers for libc-bin (2.27-6) ...
I: Copying back the cached apt archive contents
I: new cache content 'libtool_2.4.6-4_all.deb' added
I: new cache content 'libmariadbclient18_1%3a10.1.35-1_amd64.deb' added
I: new cache content 'libmariadbclient-dev_1%3a10.1.35-1_amd64.deb' 
added
I: new cache content 'libmariadbclient-dev-compat_1%3a10.1.35-1_amd64.deb' 
added
I: new cache content 'libltdl7_2.4.6-4_amd64.deb' added
I: new cache content 'libltdl-dev_2.4.6-4_amd64.deb' added
I: new cache content 'parser3-common_3.4.5-4_amd64.deb' added
I: new cache content 'parser3-dev_3.4.5-4_amd64.deb' added
I: new cache content 'lintian_2.5.102_all.deb' added
I: Building the package
I: Running cd /build/parser-mysql-10.7/ && env 
PATH="/usr/sbin:/usr/bin:/sbin:/bin" HOME="/nonexistent" dpkg-buildpackage -us 
-uc -rfakeroot
dpkg-buildpackage: warning: using a gain-root-command while being root
dpkg-buildpackage: info: source package parser-mysql
dpkg-buildpackage: info: source version 10.7-3
dpkg-buildpackage: info: source distribution unstable
dpkg-buildpackage: info: source changed by Sergey B Kirpichev 

 dpkg-source --before-build parser-mysql-10.7
dpkg-buildpackage: info: host architecture amd64
 fakeroot debian/rules clean
dh clean
   dh_clean
 dpkg-source -b parser-mysql-10.7
dpkg-source: info: using source format '3.0 (quilt)'
dpkg-source: info: building parser-mysql using existing 
./parser-mysql_10.7.orig.tar.gz
dpkg-source: info: building parser-mysql in parser-mysql_10.7-3.debian.tar.xz
dpkg-source: info: building parser-mysql in parser-mysql_10.7-3.dsc
 debian/rules build
dh build
   dh_update_autotools_config
   dh_autoreconf
libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, 'config'.
libtoolize: copying file 'config/compile'
libtoolize: copying file 'config/config.guess'
libtoolize: copying file 'config/config.sub'
libtoolize: copying file 'config/depcomp'
libtoolize: copying file 'config/install-sh'
libtoolize: copying file 'config/missing'
libtoolize: copying file 'config/ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'm4'.
libtoolize: copying file 'm4/libtool.m4'
libtoolize: copying file 'm4/ltargz.m4'
libtoolize: You should add the contents of 'm4/ltargz.m4' to 'aclocal.m4'.
libtoolize: copying file 'm4/ltdl.m4'
libtoolize: copying file 'm4/ltoptions.m4'
libtoolize: copying file 'm4/ltsugar.m4'
libtoolize: copying file 'm4/ltversion.m4'
libtoolize: copying file 'm4/lt~obsolete.m4'
libtoolize: putting libltdl files in LT_CONFIG_LTDL_DIR, '.'.
libtoolize: copying file './COPYING.LIB'
libtoolize: creating file './Makefile.am'
libtoolize: copying file './README'
libtoolize: creating file './configure.ac'
libtoolize: creating file './aclocal.m4'
libtoolize: creating file './Makefile.in'
libtoolize: copying file './config-h.in'
libtoolize: creating file './configure'
libtoolize: copying file './libltdl/lt__alloc.h'
libtoolize: copying file './libltdl/lt__argz_.h'
libtoolize: copying file './libltdl/lt__dirent.h'
libtoolize: copying file './libltdl/lt__glibc.h'
libtoolize: copying file './libltdl/lt__private.h'
libtoolize: copying file './libltdl/lt__strl.h'
libtoolize: copying file './libltdl/lt_dlloader.h'
libtoolize: copying file './libltdl/lt_error.h'
libtoolize: copying file './libltdl/lt_system.h'
libtoolize: copying file './libltdl/slist.h'
libtoolize: copying file './loaders/dld_link.c'
libtoolize: copying file './loaders/dlopen.c'
libtoolize: copying file './loaders/dyld.c'
libtoolize: copying file './loaders/load_add_on.c'
libtoolize: copying file './loaders/loadlibrary.c'
libtoolize: copying file './loaders/preopen.c'
libtoolize: copying file './loaders/shl_load.c'
libtoolize: copying file './lt__alloc.c'
libtoolize: copying file './lt__argz.c'
libtoolize: copying file './lt__dirent.c'
libtoolize: copying file './lt__strl.c'
libtoolize: copying file './lt_dlloader.c'
libtoolize: copying file './lt_error.c'
libtoolize: copying file './ltdl.c'
libtoolize: copying file './ltdl.h'
libtoolize: copying file './slist.c'
libtoolize: Remember to add 'LTDL_INIT' to configure.ac.
libtoolize: putting auxiliary files in '.'.
libtoolize: copying file './compile'
libtoolize: copying file './config.guess'
libtoolize: copying file './config.sub'
libtoolize: copying file './depcomp'
libtoolize: copying file './install-sh'
libtoolize: copying file './missing'
libtoolize: copying file './ltmain.sh'
libtoolize: putting macros in 'libltdl/m4'.
libtoolize: copying file 'libltdl/m4/libtool.m4'
libtoolize: copying file 'libltdl/m4/ltargz.m4'
libtoolize: You should add the contents of 'libltdl/m4/ltargz.m4' to 
'aclocal.m4'.
libtoolize: copyin

Bug#900132: O: libapache2-mod-bw - bandwidth limiting module for apache2

[Sergey B Kirpichev]

Package: libapache2-mod-bw
Severity: normal

Apparently, I have no time to work on this package.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

Bug#900131: O: libapache2-mod-rpaf - module for Apache2 which takes the last IP from the 'X-Forwarded-For' header

[Sergey B Kirpichev]

Package: libapache2-mod-rpaf
Severity: normal

Apparently, I have no time to work on this package.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

Bug#877633: Acknowledgement (monit openssh-server config depends on a key which is not required to be there)

[Sergey B Kirpichev]

tag 877633 +moreinfo
thanks

On Tue, 3 Oct 2017 18:19:14 +0200 Alexander Schier  
wrote:
> It gets even worse: With the failing dependency, monit stops the sshd
> until you log in manually and remove the config (or create the key).

Are you sure?  Unless you changed rootstrict template, monit should
just unmonitor sshd, not stop it.

Bug#868778: monit: Invalid CSRF check when using monit web page

[Sergey B Kirpichev]

On Tue, Aug 29, 2017 at 08:58:44PM +0200, mart...@tildeslash.com wrote:
> According to the output, the installed Monit version is 5.20.0 (first version 
> with CSRF protection). The CSRF cookie in 5.20.0 was position dependent 
> (https://bitbucket.org/tildeslash/monit/issues/495/invalid-csrf-check). The 
> problem was fixed in Monit 5.21.0.

Correct me, if I'm wrong.  Workarround is (no-upgrade-solution): using
a dedicated TLD for monit?

Bug#872715: Compat 10

[Sergey B Kirpichev]

On Tue, Aug 29, 2017 at 04:14:33PM +0200, Szépe Viktor wrote:
>Please see the new autoreconf policy
>[1]https://lintian.debian.org/tags/useless-autoreconf-build-depends.html

Thanks!  This part was added too.

Bug#873539: monit 1:5.23.0-3 won't install - "epoch in version is empty"

[Sergey B Kirpichev]

On Tue, Aug 29, 2017 at 01:24:27AM +0200, Vincent Lefevre wrote:
> > dpkg-maintscript-helper: error: dpkg: error: version '"1:5.15-1~"' has bad 
> > syntax: epoch in version is empty

Looks like regression in dpkg-maintscript-helper: quotation marks were passed 
to dpkg --validate-version.

C.f.
# dpkg --validate-version -- "1:5.15-1"
# dpkg --validate-version -- "1:5.15-1~"
vs
# dpkg --validate-version -- '"1:5.15-1~"'
dpkg: error: version '"1:5.15-1~"' has bad syntax: epoch in version is empty

Probably, this could be solved on the monit side by changing
mv_conffile /etc/monit/monitrc.d/acpid /etc/monit/conf-available/acpid 
"1:5.15-1~"
to
mv_conffile /etc/monit/monitrc.d/acpid /etc/monit/conf-available/acpid 1:5.15-1~

Bug#872715: monit: debian tweaks

[Sergey B Kirpichev]

tags 872715 +pending
thanks

On Sun, 20 Aug 2017 14:34:56 +0200 =?UTF-8?Q?Christian_G=C3=B6ttsche?= 
 wrote:
> - switch to debhelper compat level 10

ok

> - strip unneeded linked libraries

Not sure why you think that autoreconf is not needed...

> - remove whitespaces from series file

I prefer to keep whitespaces here (unless you have
good arguments againts, e.g. it break some tool).

> - use https addresses

ok for mmonit page

Bug#873491: override: libapache2-mod-qos: httpd/extra

[Sergey B Kirpichev]

Package: ftp.debian.org
Severity: normal

There were override disparities found in suite unstable:

libapache2-mod-qos: Override says httpd - optional, .deb says httpd - extra

Bug#868778: monit: Invalid CSRF check when using monit web page

[Sergey B Kirpichev]

fixed 868778 monit/1:5.21.0-1
tags 868778 +upstream
thanks

On Tue, 18 Jul 2017 14:48:30 +0200 Cyril Mertens  wrote:
> As a quick and dirty workaround, I installed monit package from Sid,
> reverted to the monit package from Stretch and then the problem was no
> more longer present, web controls of monit were made useable again.
> 
> Here are the usual lines automatically added by reportbug.

Most importand part (monitrc content) wasn't included, so I can't
help too much.  Monit's bugtracker suggests that there are other
workarrounds, without need for upgrade.

BTW, problem is fixed in sid/testing.

Bug#867669: monit summary doesn't detect rxvt as color terminal

[Sergey B Kirpichev]

On Thu, 13 Jul 2017 00:13:49 +0200 Alexander Schier  
wrote:
> Will there be a backport to stretch?

This bug at least not severe enough.  Fill free to change
it's severity to important or higher (with a good explanation).

Bug#868456: monit isn't reloaded when program binaries are updated

[Sergey B Kirpichev]

tags 868456 + wontfix
thanks

On Sat, 15 Jul 2017 17:09:22 +0200 Alexander Schier  
wrote:
> This should probably integrate in some way with apt post-hooks or
> the checkrestart script or something similiar or the checksum check
> should be removed from the scripts.

Have you seen README.Debian file, coming with the monit package?
There are instructions on how to reload monit config after updating
packages.

Monit - is a generic monitoring tool, it's not especially for
your local binaries, coming from deb packages.  That's why this
hook wasn't enabled by default.

So, I don't think there is something more to do on
packaging side.  I'll mark this as a wontfix, unless
you have good arguments against.

Bug#867669: monit summary doesn't detect rxvt as color terminal

[Sergey B Kirpichev]

tag 867669 + upstream fixed-upstream
thanks

On Tue, Jul 11, 2017 at 10:46:04AM +0200, mart...@tildeslash.com wrote:
> the problem was fixed in the upstream: 
> https://bitbucket.org/tildeslash/monit/commits/cf945190e280948f757646bd1fa7497a7f184434

So, this will be fixed with next upload to unstable, I hope.

I don't think that the problem is severe enough to enter
proposed-updates, etc.

> > On 8 Jul 2017, at 13:56, Alexander Schier  wrote:
> > 
> > Package: monit
> > Version: 5.20.0-6
> > Severity: normal
> > 
> > Dear Maintainer,
> > when running "monit summary" in rxvt with TERM=rxvt-unicode I get a
> > plain dumb-terminal output. When running it in the same terminal as
> > "TERM=xterm monit summary" I get a nicely formatted table with colors
> > indicating the status of the services.
> > It seems, that monit needs a longer list of terminals supporting colors
> > and/or a switch to force colored output.
> > 
> > 
> > with kind regards,
> > Alexander Schier
> > 
> > 
> > -- System Information:
> > Debian Release: buster/sid
> >  APT prefers testing
> >  APT policy: (500, 'testing')
> > Architecture: amd64 (x86_64)
> > Foreign Architectures: i386
> > 
> > Kernel: Linux 4.9.0-3-amd64 (SMP w/8 CPU cores)
> > Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE= 
> > (charmap=UTF-8)
> > Shell: /bin/sh linked to /bin/dash
> > Init: sysvinit (via /sbin/init)
> > 
> > Versions of packages monit depends on:
> > ii  libc6  2.24-12
> > ii  libpam0g   1.1.8-3.6
> > ii  libssl1.1  1.1.0f-3
> > ii  lsb-base   9.20161125
> > ii  zlib1g 1:1.2.8.dfsg-5
> > 
> > monit recommends no packages.
> > 
> > Versions of packages monit suggests:
> > ii  postfix [mail-transport-agent]  3.2.2-1
> > ii  sysvinit-core   2.88dsf-59.9
> > 

Bug#755797: RFA: awstats -- powerful and featureful web server log analyzer

[Sergey B Kirpichev]

retitle 755797 O: awstats -- powerful and featureful web server log
analyzer
thanks

Apparently, I have no time to work on this package.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

On Wed, 7 Dec 2016 14:39:23 +0300 Sergey B Kirpichev <skirpic...@gmail.com> 
wrote:
> retitle 755797 RFA: awstats -- powerful and featureful web server log analyzer
> thanks
> 
> Hereby, I increase severity of this report to RFA.
> 
> I don't have production installation of awstats anymore.  Probably, I
> can assist new maintainers as a co-maintainer, but not more.
> 
> 

Bug#834653: nlopt: typo in debian/rules (override_dh_auto_reconf -> override_dh_autoreconf)

[Sergey B Kirpichev]

On Sat, Jul 08, 2017 at 09:42:32PM +0100, Chris Lamb wrote:
> Uploaded :)  Do upgrade your lintian for your next package preparation
> (eg. for at least Standards-Version: 4.0.0)

I hope so, but not all warnings were fixed.

Bug#834653: nlopt: typo in debian/rules (override_dh_auto_reconf -> override_dh_autoreconf)

[Sergey B Kirpichev]

On Wed, 17 Aug 2016 21:32:09 +0100 Chris Lamb  wrote:
> I believe there is a typo in your debian/rules (override_dh_auto_reconf -> 
> override_dh_autoreconf).
> 
> I don't believe this affects the working of the package, but if anyone
> in the future added the "dh $@ --with=autoreconf" magic, then it would
> _not_ be able to see your override. Therefore, I suggest you normalise
> the name.

Patched.

Chris, could you review and upload package (I don't have
permissions for this package, as before).

Package was uploaded to m.d.n:
https://mentors.debian.net/package/nlopt

It seems, that git packaging was started anyway:
https://anonscm.debian.org/cgit/debian-science/packages/nlopt.git/
I see that Git now is a standard for the Debian Science, so I hope - this
is fine, despite Christophe may disagree with such a decision.

So, my work was fully pushed to this git repo, except for the final
commit, that touches changelog.  Please fix everything you don't
like, then commit and tag release.

I'm CC'ing Afif, who started packaging in Git.

Bug#862390: ship CMake config files with the nlopt package

[Sergey B Kirpichev]

severity 862390 wishlist
thanks

On Fri, 12 May 2017 09:51:29 +0200 sla...@staszic.waw.pl wrote:
> These *.cmake files enable CMake users to use find_package(NLopt) in 
> their CMake scripts.
> It would be great to ship these *.cmake files in the Debian package as 
> well.

It should be easy, when nlopt version with cmake will be released.

Meanwhile, marking this as a wishlist issue.

Bug#855600: src:nlopt: Please provide binary package for cxx library

[Sergey B Kirpichev]

On Mon, 20 Feb 2017 22:03:19 -0800 Afif Elghraoui  wrote:
> Anyway, I see the packaging is still in SVN. I'll switch it to Git and
> prepare a team upload.

Please ask first other co-maintainers!

Personally, I'm +1 for packaging in Git.  Unfortunally, Christophe
rejected this idea in the past.

Bug#857863: add systemd service

[Sergey B Kirpichev]

On Thu, Apr 13, 2017 at 08:03:31PM +0200, Christian Göttsche wrote:
> I might be able to help with systemd related issues but I can not
> promise anything.

Then sorry, I don't have resources to do this myself.

If you think, that there are some problems (which one, why do you think
so?) with provided (as an example) systemd config - I'm happy
to review/accept your patches.

Bug#857863: add systemd service

[Sergey B Kirpichev]

On Thu, Apr 13, 2017 at 12:12:37AM +0200, Christian Göttsche wrote:
> 2017-04-12 20:22 GMT+02:00 Sergey B Kirpichev <skirpic...@gmail.com>:
> > tags 857863 +moreinfo
> > thanks
> >
> > On Wed, Apr 12, 2017 at 05:50:51PM +0200, Christian Göttsche wrote:
> >> Updated version, similar to the upstream[1] one:
> >
> > Are you ready to support monit in systemd-enabled configurations?
> 
> What do you mean by that?

I mean - will you write guide for users on how to fix default
systemd configuration to not conflict with monit?  Will you
debug and fix systemd-related issues, if they appear in bts?

Bug#857863: add systemd service

[Sergey B Kirpichev]

tags 857863 +moreinfo
thanks

On Wed, Apr 12, 2017 at 05:50:51PM +0200, Christian Göttsche wrote:
> Updated version, similar to the upstream[1] one:

Are you ready to support monit in systemd-enabled configurations?

Bug#851101: monit: should better support systemd

[Sergey B Kirpichev]

On Thu, Jan 12, 2017 at 01:59:24AM +0100, Vincent Lefevre wrote:
> but systemd does not support $all in its LSB compatibility support,
> and there's no easy way to fix cleanly (see bug 850703).

I don't see why it's not easy to fix.  Obviously, only one
package should use $all (and this package is a very specia
one).  Any more problems?

> BTW, according to :
> "This only work for start ordering, not stop ordering."

Some time ago it was working.  If that's broken now, I believe
we should open a bug.

> Since systemd has its own monitoring system of daemons

Which I suggest you to turn off, unless you want to play
races with systemd.  That was mentioned in docs.

> I don't think
> that the equivalent of $all would really be needed.

I don't care about systemd.  But I do care about monit.  With sysvinit -
there is no another (non system-specific) way to specify setup
where monit starts last and stops first.

> The only problem
> I can notice is that monit starts before the MTA, so that it can't
> immediately send mail.

If it starts before service - it will start the service.  Perhaps,
in most cases - you will get few more emails and nothing else.
But sometimes it could be worse.  Especially with "own
monitoring system" in some inits...

> # Should-Start:  $all mail-transport-agent
> would be better.

That addition should be safe.  But shouldn't MTA be in Depends
for this?  Right now MTA - only a suggestion for monit.

Bug#839804: monit: errors every 2 minutes in the log file: "Queued event file: unable to read event size -- end of file"

[Sergey B Kirpichev]

tags 839804 -moreinfo +unreproducible
thanks

On Mon, Jan 09, 2017 at 04:09:47PM +0100, Vincent Lefevre wrote:
> Yes, it seems so... unless the problem is not always reproducible
> (e.g. if there's some race condition).
> 
> I also wonder whether suspending the laptop can also yield the
> issue.
> 
> > If this is correct, problem seems to be solved in the new
> > version.  If not - please try to reproduce situation, when
> > event-files are created.
> 
> I'll try to reproduce the problem by rebooting the machine
> (not before Wednesday, though).

I'll wait for your reply till the end of week.  Then, I'll
close bug as unreproducible, if nothing happens.

Bug#826148: systemd looses track of service status after it was restarted by monit.

[Sergey B Kirpichev]

tags 826148 -pending +wontfix
thanks

Addition.

On Mon, Jan 09, 2017 at 06:36:46PM +0100, Mario Lipinski wrote:
> >1) monit doesn't support systemd.  If you are ready to support this
> >   package for systemd - please do.
> 
> I just use monit on a Debian system with its default init system. I would
> expect monit to work on such a system. If it does not, this should be noted
> in the documentation and also probably declare appropriate dependencies
> (e.g. to require certain init system or conflict systemd) in the package
> meta information. Not sure whether I missed something in this direction. I
> already proposed a solution that could work on all systems in my initial
> email.

Disclamer: systemd-enabled setups are not tested.  So, if you feel that
there should be direct conflict with systemd - I can add that.  But
in principle, any LSB-compatible init should work.

> >2) "This is not the case when used via monit." - and why it's the monit
> >   problem, but not systemd*?
> 
> I think that this issue could be handled better on the monit side, but feel
> free to forward this to the systemd maintainers.
> 
> I consider the compatibility approach for /etc/init.d (sysvinit) by systemd
> very hackish and thus I would prefer a more general solution to control
> services. According to
> https://www.freedesktop.org/wiki/Software/systemd/Incompatibilities/ calling
> init scripts directly is also discouraged by LSB.

I don't see service command in LSB:
http://refspecs.linuxfoundation.org/LSB_5.0.0/LSB-Common/LSB-Common/rcommands.html
Do I miss something?

> I was talking about using the /usr/sbin/service binary. In #791667 as far as
> I can see only invoke-rc.d was suggested.
> 
> I agree, that maintainer script requirements may not apply to the monit
> configuration, but would strongly encourage you to consider a more general
> solution for controlling services.
> /usr/sbin/service as well as invoke-rc.d (maybe event with --force) seem to
> be alternatives worth considering.

service can run upstart job, for example, instead of init-file.  No, thank you.

The point of code snippets in conf-available - be good starting points
for your local configuration.  If you run upstart job (or run systemd
unit, whatever), but monitor init-file instead - something is deeply wrong.

If you have idea how to provide better examples, that able to work with
different inits - feel free to post a patch.  For now, I believe that
is't better to use LSB-compatible solution (/etc/init.d/foo start|stop -
documented by LSB).

Bug#850829: monit overwrites its log file

[Sergey B Kirpichev]

tags 850829 -unreproducible +pending
thanks

On Tue, Jan 10, 2017 at 08:20:14PM +0100, Vincent Lefevre wrote:
> No, I don't think I have anything that should affect --reinstall.
> Correct me if I'm wrong, but it seems normal that with --reinstall,
> the package gets configured (ditto with an upgrade). So, it is
> normal that
> 
>   install -o root -g adm -m 0640 /dev/null /var/log/monit.log
> 
> gets executed, which copies /dev/null to /var/log/monit.log, hence
> the problem.

Huh.  The reason was simple, old package version.  (Mirror I used
wasn't up to date.)  Sorry.

Sure, it was regression from #849886.  Thank you
for patience.  I believe, fix was commited.

Bug#850829: monit overwrites its log file

[Sergey B Kirpichev]

On Tue, Jan 10, 2017 at 08:03:31PM +0100, Vincent Lefevre wrote:
> On 2017-01-10 21:49:26 +0300, Sergey B Kirpichev wrote:
> > Hmm, I can't reproduce this as suggested by you.
> 
> On my side, I've tried two other times, and each time it was
> reproducible.

Apparently, you have some local settings, different from
defaults.  For APT maybe or systemd/journald.

Bug#850829: monit overwrites its log file

[Sergey B Kirpichev]

tags 850829 -pending +unreproducible
thanks

> On Tue, Jan 10, 2017 at 05:28:27PM +0100, Vincent Lefevre wrote:
> > However...
> > 
> > # apt install --reinstall monit
> 
> Oh, I see, this happens on reinstallation.

Hmm, I can't reproduce this as suggested by you.

# apt install monit
Reading package lists... Done
Building dependency tree   
Reading state information... Done
The following additional packages will be installed:
  libssl1.1
Suggested packages:
  exim4 | postfix | mail-transport-agent sysvinit-core
The following NEW packages will be installed:
  libssl1.1 monit
0 upgraded, 2 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/1,646 kB of archives.
After this operation, 4,502 kB of additional disk space will be used.
Do you want to continue? [Y/n] 
Preconfiguring packages ...
[...]
root@sid:~# systemctl restart monit
root@sid:~# cat /var/log/monit.log 
[MSK Jan 10 21:27:31] info :  New Monit id: 03a56de07d33c77d28b720c293e8b78a
 Stored in '/var/lib/monit/id'
[MSK Jan 10 21:27:31] info : Starting Monit 5.20.0 daemon
[MSK Jan 10 21:27:31] info : 'sid' Monit 5.20.0 started
[MSK Jan 10 21:28:03] info : Monit daemon with pid [971] stopped
[MSK Jan 10 21:28:03] info : 'sid' Monit 5.20.0 stopped
[MSK Jan 10 21:28:03] info : Starting Monit 5.20.0 daemon
[MSK Jan 10 21:28:03] info : 'sid' Monit 5.20.0 started
root@sid:~# apt install --reinstall monit
Reading package lists... Done
Building dependency tree   
Reading state information... Done
0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 0 not upgraded.
Need to get 0 B/309 kB of archives.
After this operation, 0 B of additional disk space will be used.
(Reading database ... 20013 files and directories currently installed.)
Preparing to unpack .../monit_1%3a5.20.0-4_amd64.deb ...
Unpacking monit (1:5.20.0-4) over (1:5.20.0-4) ...
Setting up monit (1:5.20.0-4) ...
Processing triggers for systemd (232-8) ...
root@sid:~# cat /var/log/monit.log 
[MSK Jan 10 21:27:31] info :  New Monit id: 03a56de07d33c77d28b720c293e8b78a
 Stored in '/var/lib/monit/id'
[MSK Jan 10 21:27:31] info : Starting Monit 5.20.0 daemon
[MSK Jan 10 21:27:31] info : 'sid' Monit 5.20.0 started
[MSK Jan 10 21:28:03] info : Monit daemon with pid [971] stopped
[MSK Jan 10 21:28:03] info : 'sid' Monit 5.20.0 stopped
[MSK Jan 10 21:28:03] info : Starting Monit 5.20.0 daemon
[MSK Jan 10 21:28:03] info : 'sid' Monit 5.20.0 started
[MSK Jan 10 21:30:52] info : Monit daemon with pid [1055] stopped
[MSK Jan 10 21:30:52] info : 'sid' Monit 5.20.0 stopped
[MSK Jan 10 21:30:58] info : Starting Monit 5.20.0 daemon
[MSK Jan 10 21:30:58] info : 'sid' Monit 5.20.0 started

As you can see, /var/log/monit.log was preserved.  This system was configured
with default systemd settings (i.e. no persistent logging).  Nothing wrong
happens also if I enable persistent logging, as documented in docs.

Bug#850829: monit overwrites its log file

[Sergey B Kirpichev]

tags 850829 +pending
thanks

On Tue, Jan 10, 2017 at 05:28:27PM +0100, Vincent Lefevre wrote:
> However...
> 
> # apt install --reinstall monit

Oh, I see, this happens on reinstallation.

> Something wrong in the postinst script?
> Could this be:
> install -o root -g adm -m 0640 /dev/null /var/log/monit.log

Yes, thank you.  Apparently, this should be inside of "if else"
loop: logfile existence must be tested first.

Not sure what to do if it is exists.  Just nothing, or
secure file permissions and owner/group.  Probably second.

Bug#826148: systemd looses track of service status after it was restarted by monit.

[Sergey B Kirpichev]

tags 826148 -moreinfo +pending
thanks

On Mon, Jan 09, 2017 at 06:36:46PM +0100, Mario Lipinski wrote:
> >1) monit doesn't support systemd.  If you are ready to support this
> >   package for systemd - please do.
> 
> I just use monit on a Debian system with its default init system. I would
> expect monit to work on such a system.

It works, but this configuration has some problems, see docs.

> If it does not, this should be noted
> in the documentation and also probably declare appropriate dependencies
> (e.g. to require certain init system or conflict systemd) in the package
> meta information.

Have you read the package documentation at all?  How can you miss
the package suggestions?

> I already proposed a solution that could work on all systems in my initial
> email.

Have you tested sysvinit setup with this solution?

> /usr/sbin/service as well as invoke-rc.d (maybe event with --force) seem to
> be alternatives worth considering.

invoke-rc.d was considered.  /usr/sbin/service seems to be more safe
solution.  Feel free to come with patch.

Bug#850829: monit overwrites its log file

[Sergey B Kirpichev]

On Tue, Jan 10, 2017 at 04:08:03PM +0100, Vincent Lefevre wrote:
> I've noticed that the latest version of monit has overwritten
> its log file (/var/log/monit.log). /var/log/monit.log.1 ends
> on January 2 with:

How logging system configured?  journald?

> [...]
> [CET Jan  2 07:32:58] error: Queued event file: unable to read event size 
> -- end of file
> [CET Jan  2 07:32:58] error: Queued event file: unable to read event size 
> -- end of file
> [CET Jan  2 07:32:58] error: 'eth0' link down
> [CET Jan  2 07:34:58] error: Queued event file: unable to read event size 
> -- end of file
> [CET Jan  2 07:34:58] error: Queued event file: unable to read event size 
> -- end of file
> [CET Jan  2 07:34:58] error: 'eth0' link down
> [CET Jan  2 07:35:07] info : Awakened by the SIGHUP signal
> Reinitializing Monit - Control file '/etc/monit/monitrc'
> 
> while /var/log/monit.log starts with:
> 
> [CET Jan 10 10:29:40] info : Starting Monit 5.20.0 daemon
> [CET Jan 10 10:29:40] info : 'zira' Monit 5.20.0 started

What happens with logfile if you do manual restart of the monit?  stop
and start?  If you do reload?

Bug#839804: monit: errors every 2 minutes in the log file: "Queued event file: unable to read event size -- end of file"

[Sergey B Kirpichev]

On Mon, Jan 09, 2017 at 04:09:47PM +0100, Vincent Lefevre wrote:
> Yes, it seems so... unless the problem is not always reproducible
> (e.g. if there's some race condition).
> 
> I also wonder whether suspending the laptop can also yield the
> issue.
> 
> > If this is correct, problem seems to be solved in the new
> > version.  If not - please try to reproduce situation, when
> > event-files are created.
> 
> I'll try to reproduce the problem by rebooting the machine
> (not before Wednesday, though).

Ok, I'll wait if you can reproduce the problem.  Unfortunately, I can't.

> > BTW, I don't think, that monit should cleanup some "broken" (from
> > his current point of view) files in events dir.
> 
> Any reason?
> 
> Note: The files were empty, so that they didn't contain any meaningful
> information, I suppose.

File also has metadata.  They may be essential
for debugging, as an example.

The creation of an empty file - seems to be the problem.  Monit shoundn't
just hide problems.

Bug#839804: monit: errors every 2 minutes in the log file: "Queued event file: unable to read event size -- end of file"

[Sergey B Kirpichev]

On Mon, Jan 09, 2017 at 03:20:07PM +0100, Vincent Lefevre wrote:
> On 2017-01-09 16:53:52 +0300, Sergey B Kirpichev wrote:
> > On Mon, Jan 09, 2017 at 02:15:57PM +0100, Vincent Lefevre wrote:
> > > The error messages no longer occur (without needing to restart monit).
> > 
> > But with restart (monit or system) they DO appear again, correct?
> 
> I've rebooted the machine, and the error message still no longer
> appears. But the /var/lib/monit/events directory is empty.
> 
> (There are just the normal messages at start up due to systemd's
> buggy LSB support.)

So, all mail-related problems - are present, event-files - were
created, but correctly removed?

If this is correct, problem seems to be solved in the new
version.  If not - please try to reproduce situation, when
event-files are created.

BTW, I don't think, that monit should cleanup some "broken" (from his
current point of view) files in events dir.

Bug#826148: systemd looses track of service status after it was restarted by monit.

[Sergey B Kirpichev]

tag 826148 +moreinfo
thanks

On Thu, Jun 02, 2016 at 06:52:39PM +0200, Mario Lipinski wrote:
> when a service such as openssh-server is restarted by monit, systemdctl
> status lists the restarted service as failed. While using /etc/init.d
> scripts interactively, the start/stop commands are redirected to systemd.
> This is not the case when used via monit. I would suggest calling the
> "service" command instead that should issue the correct service control
> commands.

1) monit doesn't support systemd.  If you are ready to support this
   package for systemd - please do.

2) "This is not the case when used via monit." - and why it's the monit
   problem, but not systemd*?

3) I would suggest calling the "service".
   - I was already suggested before.  The reason for using more low-level
 instruments is that this prevents from using service dependencies
 from LSB headers.  If you use monit - probably it does make sense
 to use also it to handle dependencies.  At least, by default.
 See also https://bugs.debian.org/791667, where it was discussed.

 I'm open to reconsider this, but please avoid using systemd
 in your argumentation.

Bug#839804: monit: errors every 2 minutes in the log file: "Queued event file: unable to read event size -- end of file"

[Sergey B Kirpichev]

On Mon, Jan 09, 2017 at 02:15:57PM +0100, Vincent Lefevre wrote:
> The error messages no longer occur (without needing to restart monit).

But with restart (monit or system) they DO appear again, correct?

> If the problem was that some files were too old, then monit should
> have done some clean up.

We can discuss solution when the reason for this problem will be identified.

> BTW, shouldn't they be under /run?

Maybe.

> I'm using systemd, as said in "System Information" in my bug report,
> and I haven't changed the init files. But systemd provides LSB
> compatibility.

Apparently, systemd support for LSB is bad in this case.

Bug#839804: monit: errors every 2 minutes in the log file: "Queued event file: unable to read event size -- end of file"

[Sergey B Kirpichev]

On Mon, Jan 09, 2017 at 01:32:59PM +0100, Vincent Lefevre wrote:
> > Can you check permissions on events dir & file?
> 
> root@zira:/home/vinc17# ls -l /var/lib/monit
> total 12
> drwx-- 2 root root 4096 2017-01-06 18:16:28 events
> -rw-r--r-- 1 root root   32 2015-07-07 13:17:34 id
> -rw--- 1 root root  768 2017-01-09 13:21:03 state
> root@zira:/home/vinc17# ls -l /var/lib/monit/events
> total 0
> -rw-r--r-- 1 root root 0 2015-07-25 17:15:17 1437837317_12a1a40
> -rw-r--r-- 1 root root 0 2016-12-23 10:51:02 1482486662_5640726e2fa0
>
> > If possible, please check new sid's version.
> 
> Same problem:

First file seems to be too old.  Second - too (but not too much).  What
if you clean up these files?

> > This shouldn't be.  Monit must be stopped first by init script (and
> > started last, by the way).  That's - package default.
> 
> Apparently not: there are lots of services stopped before monit.

Are you using sysvinit and standard init-file for monit?  It looks
like sysvinit-core - pruned on your system.

Bug#847196: monit segfault on stop and start

[Sergey B Kirpichev]

On Mon, Dec 12, 2016 at 04:23:57PM +0100, Arthur Hoffmann wrote:
> It looks like this bug is fixed,
> I did "dpkg -i monit_5.4-2+deb7u3_amd64.deb", monit restarted and is
> running
> now.
> Thank you.
> >Source package was uploaded to
> >https://mentors.debian.net/package/monit
> >amd64 deb attached.

Ok.  Meanwhile, let me know if you will have some problems with attached
above deb.

CCd Victor and Jonas.  Should this go to wheezy-security?  If so, Jonas,
can you do upload from mentors:
https://mentors.debian.net/debian/pool/main/m/monit/ ?

Bug#847196: monit segfault on stop and start

[Sergey B Kirpichev]

On Mon, Dec 12, 2016 at 02:06:41PM +0100, Martin Pala wrote:
> The securitytoken in collector is not needed at all - the CSRF
> protection is related to Monit's own HTTP API (the securitytoken
> cookie is not present in upstream).

Ok, I see.  Thank you, Martin.

> To fix the problem, just drop the  collector.c part of the patch.

Arthur, could you build package yourself to test this
fix?  Or I should provide *.dsc and *.deb somewhere?

Bug#847196: monit segfault on stop and start

[Sergey B Kirpichev]

On Mon, Dec 12, 2016 at 01:11:38PM +0100, Arthur Hoffmann wrote:
> Ok, now I have checked my config files and found out that it
> works with the latest package if I remove the following line:
> 
> set mmonit https://USER:PASSWORD@URL:PORT/collector

Ok, I see.  I don't use closed-source software, so I can't help.

Perhaps, other maintainers can.

> I'm using Monit with the latest M/Monit v3.6.2.

There is 5.20.0 in backports (that fixes CVE).  Could you test
this version too, as it could be that your problem is relevant
to upstream package?

Bug#847196: monit segfault on stop and start

[Sergey B Kirpichev]

On Mon, Dec 12, 2016 at 12:24:31PM +0100, Arthur Hoffmann wrote:
> I just want to confirm that Monit is running again on all 5 Debian Wheezy
> (i386 and amd64) machines if I downgrade the package with "sudo apt-get
> install monit=1:5.4-2".

Unfortunately, I can't reproduce this on several testing configs.
If you can provide additional info (asked above), please do.

Bug#847196: monit segfault on stop and start

[Sergey B Kirpichev]

reopen 847196
thanks

Please don't reply personally (unless you want to share
some private info)!  Either to bugtracker, or
add CC to bugtracker.

Meanwhile, bug reopened.  Perhaps, backport is still broken.
(Also, co-mantainers, please use git!)

BTW, I can't reproduce this yet.  Perhaps, this related somehow with
your configuration.

On Wed, Dec 07, 2016 at 12:49:39PM +0100, Arthur Hoffmann wrote:
> When I do this commands, the process is running for a moment:
> sudo service monit start && ps aux | grep monit
> [ ok ] Starting daemon monitor: monit.
> root  5663  0.0  0.0  34564   864 ?D12:35   0:00
> /usr/bin/monit -c /etc/monit/monitrc
> arthur   5682  0.0  0.0   6268   724 pts/0S+   12:35   0:00 grep
> monit
> 
> Than 2 seconds later I check it again and the process is away:
> sudo ps aux | grep monit
> arthur   5689  0.0  0.0   6268   724 pts/0S+   12:36   0:00 grep
> monit
> 
> Than I do sudo tail -n 5 /var/log/monit.log:
> 
> [CET Dec  6 16:07:57] info : 'server1.example.com' Monit started
> [CET Dec  7 12:35:49] info : Starting monit daemon with http interface
> at [*:2812]
> [CET Dec  7 12:35:49] info : Starting monit HTTP server at [*:2812]
> [CET Dec  7 12:35:49] info : monit HTTP server started
> [CET Dec  7 12:35:49] info : 'server1.example.com' Monit started
> 
> I could not debug it with the "-lv" switch (it does nothing):
> sudo /usr/bin/monit -lv -c /etc/monit/monitrc

Bug#847314: awstats: add databasebreak support in update.sh

[Sergey B Kirpichev]

On Sat, Dec 10, 2016 at 04:22:56PM +0200, Vincas Dargis wrote:
> No I am not, I do not know what's that "collab-maint" or how to join it.

It's there:
https://alioth.debian.org/projects/collab-maint/
Just ask admins to join, comment why (i.e. where you would like to
contribute).

(Or, if you prefer, just attach patches to this bug.)

> >There is RFA bug #755797 - so feel free to join package maintenance or
> >take over package maintenence.  I'll try to help you as best, as I can.
>
> Sadly, it seems I only have energy for some bug reports and minor patches
> here and there; package maintenance would be over my head.

Not a surprise to me.  Package is big and code is messy.  Neverless,
any help is welcomed.

> So in retrospect, would you find some time to review/accept my patch, or
> should I use some other channels (such as that collab-maint, whatever that
> means :-) ).

Sure, I'll try.  Probably, this can enter next release, but no promises.

Bug#847314: awstats: add databasebreak support in update.sh

[Sergey B Kirpichev]

On Sat, Dec 10, 2016 at 12:24:00PM +0200, Vincas Dargis wrote:
> Could you hint me the proper way to produce patch?
> 
> I image I should install Debian Jesting virtual machine, checkout latest
> source package... do changes in update.sh, build & install package, test,
> and then generate diff with git, attach here?

If you are member of the alioth group collab-maint (feel free to
join) - you also can just commit your changes.  Please use common sense and
standard practice for that (i.e. one logical change per commit,
good commit messages).

There is RFA bug #755797 - so feel free to join package maintenance or
take over package maintenence.  I'll try to help you as best, as I can.

Regarding tests - probably, you can also test update.sh on live version with
Jessie's version (update.sh has no changes, but I don't remember if
databasebreak switch is working on that version).  But in general - yes.
You need some testing setup, e.g. in VM.

Bug#755797: RFA: awstats -- powerful and featureful web server log analyzer

[Sergey B Kirpichev]

retitle 755797 RFA: awstats -- powerful and featureful web server log analyzer
thanks

Hereby, I increase severity of this report to RFA.

I don't have production installation of awstats anymore.  Probably, I
can assist new maintainers as a co-maintainer, but not more.

Bug#847196: monit segfault on stop and start

[Sergey B Kirpichev]

On Wed, Dec 07, 2016 at 09:41:11AM +0100, Arthur Hoffmann wrote:
> I'm not sure whether this bug is the same that I have got,
> but it began with 1:5.4-2+deb7u1 and it is NOT fixed with 1:5.4-2+deb7u2.

Very likely.

> The service/process is starting and writes some INFO log lines without
> errors into monit.log but the process exites than immediately.

Which log lines?

Bug#847314: awstats: add databasebreak support in update.sh

[Sergey B Kirpichev]

severity 847314 wishlist
thanks

On Wed, Dec 07, 2016 at 11:03:47AM +0200, Vincas Dargis wrote:
> Awstats has `databasebreak` parameter witch which user can access to statistic
> per day basis, for example,  instead only by month due to current defaults.
> 
> update.sh currently has two parameters set, with no possibility to apply
> `-databasebreak=...`:
> -config=$c \
> -update >$ERRFILE 2>&1
> 
> It would be useful to have a way to define databasebreak’s inside
> /etc/default/awstats file, to generate possibly multiple data files per config
> file (for every break). Later, user could set `awstats.cgi?databasebreak=day`
> cgi argument to access that data. By default, if no `AWSTATS_DATABASE_BREAK` 
> is
> set in defaults file, it should not apply `-databasebreak` argument to keep
> backwards compatibility.

Sounds interesting, feel free to provide the patch.