Re: fetchamil / procmail as non root : unable to call script
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
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
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
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
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 > >