Re: fetchamil / procmail as non root : unable to call script

[BASSAGET Cédric]

Hi Joel, thanks for your response, you solved my problem. But I still don't
understand why ! :)

with :
$ cat ~/.procmailrc
LOGFILE=procmail.log
VERBOSE=yes
:0
* ^Message-ID: \/.*
| ./curl_molene.sh $MATCH

$ cat ~/curl_molene.sh
#!/bin/bash
/usr/bin/curl "http://url/alerte.php?messageid=$1;

it works as expected. but with :
$ cat ~/.procmailrc
LOGFILE=procmail.log
VERBOSE=yes
:0
* ^Message-ID: \/.*
| /usr/bin/curl "http://url/alerte.php?messageid=$MATCH;


it does not work. Any idea why ?
Regards

Le mer. 21 juin 2023 à 13:35, Joel Roth  a écrit :

> On Tue, Jun 20, 2023 at 07:52:24AM +0200, BASSAGET Cédric wrote:
> > Hello
> > I'm using fetchamil / procmail to fetch mails from an POP server and
> parse
> > it then launch a script or system call :
> >
> >
> > # cat .fetchmailrc
> > set logfile fetchmail.log
> > poll imaps.dom.tld proto POP3
> > user "u...@dom.tld" pass "xx" preconnect "date >> ~/fetchmail.log"
> > ssl
> > fetchall
> > keep
> > no rewrite
> > mda "/usr/bin/procmail ~/.procmailrc";
> >
> > # cat .procmailrc
> > LOGFILE=procmail.log
> > VERBOSE=yes
> > :0
> > * ^Message-ID: \/.*
> > #| /usr/bin/curl http://mail.dom.tld/script.php?messageid=$MATCH
> > | echo "whoami" > test.txt
> >
> >
> > This work fine when calling fetchamil as root with "fetchamil -f
> > .fetchmailrc". But when calling fetchmail from a dedicated user, the
> > external script in procmail is not called. It's written in the logfile
> that
> > :
> >
> > procmail: [25332] Mon Jun 19 16:20:28 2023
> > procmail: Assigning "MATCH="
> > procmail: Matched "<9088600d-446a-96b4-4043-29ecd0d5a...@dom.tld>"
> > procmail: Match on "^Message-ID: \/.*"
> > procmail: Assigning "LASTFOLDER= echo "whoami" > test.txt"
> >  Subject: test
> >   Folder:  echo "whoami" > test.txt
> >  1824
> > procmail: Executing " echo "whoami" > test.txt"
> >
> > but nothung happens.
> > Am I missing something ?
> > Regards
> > Cédric
>
> Are you sure that procmail is running the command in a shell?
> Could it be trying to execute a program named 'echo'.
> You might try creating a shell script you can call.
>
>
> --
> Joel Roth
>
>

Re: fetchamil / procmail as non root : unable to call script

[BASSAGET Cédric]

Hello Tomas,
Same result : log seems fine, but /tmp/test.txt still does not exist :

procmail: Executing " echo "whoami" > /tmp/test.txt"
procmail: Assigning "LASTFOLDER= echo "whoami" > /tmp/test.txt"
 Subject: test
  Folder:  echo "whoami" > /tmp/test.txt
1825

Regards

Le mar. 20 juin 2023 à 08:34,  a écrit :

> On Tue, Jun 20, 2023 at 07:52:24AM +0200, BASSAGET Cédric wrote:
> > Hello
> > I'm using fetchamil / procmail to fetch mails from an POP server and
> parse
> > it then launch a script or system call :
> >
> >
> > # cat .fetchmailrc
> > set logfile fetchmail.log
> > poll imaps.dom.tld proto POP3
> > user "u...@dom.tld" pass "xx" preconnect "date >> ~/fetchmail.log"
> > ssl
> > fetchall
> > keep
> > no rewrite
> > mda "/usr/bin/procmail ~/.procmailrc";
> >
> > # cat .procmailrc
> > LOGFILE=procmail.log
> > VERBOSE=yes
> > :0
> > * ^Message-ID: \/.*
> > #| /usr/bin/curl http://mail.dom.tld/script.php?messageid=$MATCH
> > | echo "whoami" > test.txt
> >
> >
> > This work fine when calling fetchamil as root with "fetchamil -f
> > .fetchmailrc". But when calling fetchmail from a dedicated user, the
> > external script in procmail is not called. It's written in the logfile
> that
> > :
> >
> > procmail: [25332] Mon Jun 19 16:20:28 2023
> > procmail: Assigning "MATCH="
> > procmail: Matched "<9088600d-446a-96b4-4043-29ecd0d5a...@dom.tld>"
> > procmail: Match on "^Message-ID: \/.*"
> > procmail: Assigning "LASTFOLDER= echo "whoami" > test.txt"
> >  Subject: test
> >   Folder:  echo "whoami" > test.txt
> >  1824
> > procmail: Executing " echo "whoami" > test.txt"
> >
> > but nothung happens.
>
> Hm. Long time I didn't play with fetchmail. One suggestion,
> though: when this 'echo "whoami"...' is executed, do you
> know which directory it is happening in? Try redirecting
> to /tmp/test.txt or whatever, just to be sure.
>
> Cheers
> --
> t
>

fetchamil / procmail as non root : unable to call script

[BASSAGET Cédric]

Hello
I'm using fetchamil / procmail to fetch mails from an POP server and parse
it then launch a script or system call :


# cat .fetchmailrc
set logfile fetchmail.log
poll imaps.dom.tld proto POP3
user "u...@dom.tld" pass "xx" preconnect "date >> ~/fetchmail.log"
ssl
fetchall
keep
no rewrite
mda "/usr/bin/procmail ~/.procmailrc";

# cat .procmailrc
LOGFILE=procmail.log
VERBOSE=yes
:0
* ^Message-ID: \/.*
#| /usr/bin/curl http://mail.dom.tld/script.php?messageid=$MATCH
| echo "whoami" > test.txt


This work fine when calling fetchamil as root with "fetchamil -f
.fetchmailrc". But when calling fetchmail from a dedicated user, the
external script in procmail is not called. It's written in the logfile that
:

procmail: [25332] Mon Jun 19 16:20:28 2023
procmail: Assigning "MATCH="
procmail: Matched "<9088600d-446a-96b4-4043-29ecd0d5a...@dom.tld>"
procmail: Match on "^Message-ID: \/.*"
procmail: Assigning "LASTFOLDER= echo "whoami" > test.txt"
 Subject: test
  Folder:  echo "whoami" > test.txt
 1824
procmail: Executing " echo "whoami" > test.txt"

but nothung happens.
Am I missing something ?
Regards
Cédric

webalizer bug in debian jessie

[BASSAGET Cédric]

Hello,
Referring to : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=858602

I'm looking for the 2.23.08-2 version of webalizer, which is referred in
this bug. Can't find it...
Can not install 2.23.08-3 because it needs libpng16-16 which is not
available in debian jessie repositories.

Can anybody tell me how to fix this bug ?
Regards
Cédric

Re: open-iscsi & multipath-tools

[BASSAGET Cédric]

Hello Christian,
I'm unable to reproduce for about 1 hour... Now, everyhting works fine
after a reboot, but... the only thing I've done is to remove the vg / pv i
created on multipath device... weird.

Regards,
Cédric

2016-04-22 15:17 GMT+02:00 Christian Seiler :

> Package: open-iscsi
> Version: 2.0.873+git0.3b4b4500-8+deb8u1
> Severity: normal
> Owner: !
> Tags: jessie moreinfo
>
> Hi there,
>
> FYI: I'm co-maintainer of open-iscsi in Debian, but not
> multipath-tools. CC'ing the bugtracker, assigning to open-iscsi for
> now, will reassign to multipath-tools later if necessary.
>
> Am 2016-04-22 14:45, schrieb Cédric Bassaget:
>
>> After a reboot, iscsi targets are OK, but multipath does not show any
>> volume. I have to restart it by hand to bring the multipath volume up.
>>
>
> Gah. During the freeze of Jessie I encountered some bugs related to the
> boot process and I thought we had fixed them all before Jessie was
> released. Obviously not... :-(
>
> I guess it's because on system startup, multipath-tools is launched
>> befors open-iscsi. open-iscsi seems to be systemd compliant, but not
>> multipath-tools.
>>
>
> For current versions (starting with Jessie) of multipath-tools, this
> is correct, as the daemon is supposed to be started and then pick up
> all of the devices as they appear dynamically.
>
> OTOH, what you're seeing in dmesg is just the modules that are loaded,
> which might be due to /etc/modules, /etc/modprobe.d or similar, so
> they don't necessarily indicate which is started before.
>
> root@virtm6:/etc# find rc?.d -name 'S*multipath-tools'
>> rc2.d/S02multipath-tools
>> rc3.d/S02multipath-tools
>> rc4.d/S02multipath-tools
>> rc5.d/S02multipath-tools
>>
>
> multipath-tools is still late-boot? That seems wrong to me. May be part
> of the problem you're seeing.
>
> Could you give me the output of the following on your system?
>
> systemctl show -p Before,After,WantedBy,Wants,RequiredBy,Requires
> multipath-tools.service
> systemctl show -p Before,After,WantedBy,Wants,RequiredBy,Requires
> open-iscsi.service
>
> Also, what does the following command tell you? (After booting, when
> the problem appears, but before restarting multipath to fix it.)
>
> journalctl -u open-iscsi.service -u multipath-tools.service
>
> What would be the best way to fox this problem ?
>>
>
> Well, there's probably still some bug in the integration between
> open-iscsi and multipath-tools. The output of the commands I requested
> will help me narrow down the problem, which will then hopefully give
> me enough information to tell you how to fix it on your local system,
> and hopefully this can be fixed in 8.5.
>
> Regards,
> Christian
>
>