Re: [PLUG] incron issue
My sample code works like this in principle: 1. You said 4-ish invocations per print file. That means that there would be 4-ish instances of your script running, if I would not use that lock file in /tmp to detect that another script instance is already dealing with the print file. So, the script starts, looks for another script's lock file, if it doesn't find one , it creates own one, waits a bit, checks again, and if there is no collision (imagine multiple scripts checking and creating locks at the same time) it waits for the print file to become stable. 2. The print file is considered stable if it is not changed for the duration of 3 (I believe) 1 second wait loops. If the file changes, the loop counter resets and another 3 set of loops goes by. This way, you do not have to wait for the max possible print time, every time. I imagine that long or complex document might take long time to print - if we know that the printing application updates the file at least every few seconds - we reset the timer at every change, re-starting the count down. 3. File gets sent to a printer when it is considered stable, and then moved to a backup dir under new name consisting of a time stamp + the original name. If something goes wrong you can re-print manually. Backed up files should sort by its date stamp. 4. On exit, the script removes the lock file. That's about allif I remember correctly. I guess, you could call that lock file a semafor if that sounds better. Alternatively, you could also look for another process instead of keeping the lock/semafor file, but that would not allow for multiple files printing correctly at the same file. I hope that it is little clearer. -T On Nov 21, 2017 7:12 PM, "Denis Heidtmann" wrote: > Me looking at kernel software would be no more educational than me reading > about it in Greek. And I did not think I wanted to debug the spooler, > whatever that is. > > So to get down to the essentials, using only IN_CLOSE_WRITE, I get four > events (with this particular application printing). For a big print job > the timespan from the first event to the last is 10 seconds. I can explore > my two other applications and come up with a maximum (probable) time. Add > a buffer to that and use that time as a delay prior to printing the file. > That was my intended approach. > > As I understand your approach it is to check the time stamp for the file in > question, delay 2 seconds, then assume if no change has occurred, the file > is ready to print. Is this understanding correct? If so, this assumes > that the driver/application changes the file more frequently than every 2 > seconds. To explore that, I was trying to send the time to the log every > time I got an icron invocation with the IN_ALL_EVENTS mask. Hence my use > of that mask and trying to capture the time to the log. This, I hope, > explains why I wanted to see the result of $1)" >> /home/denis/incronlog.log>, and the question of why no time appears > in the log. Notice that there are many cases in the log where $1 appears > to be a filename. > > -Denis > > On Tue, Nov 21, 2017 at 1:37 PM, Tomas Kuchta < > tomas.kuchta.li...@gmail.com> > wrote: > > > Of course that you see some/many invocations without any file names when > > you trigger on all directory events. All sorts of of processes go by all > > sorts of directories all the time on modern desktop. Not all of them look > > at files. > > > > What your aim is, I believe/hope, to respond to print file write and > close > > - and send that file to a printer. Ideally deleting or backing that file > > away from the print dir. You want to do that reliably and without > multiple > > processes acting on any given file. > > > > If you want to debug print job spooler, I would suggest to do just that. > Do > > exactly what you need to do, keep it simple, and expand from there. > > > > If you are curious about kernel interworks, I would suggest to start > > looking at kernel documentation and source code - it is more systematic > way > > of learning. Unfortunately, I am not the right person to have meaningful > > conversation about kernel and VFS events/triggers. My knowledge is too > > shallow for that. > > > > Good luck, > > Tomas > > > > On Nov 21, 2017 9:44 AM, "Denis Heidtmann" > > wrote: > > > > > It is fully my intention to use only IN_CLOSE_WRITE in the final > version. > > > I currently am using IN_ALL_EVENTS just to see what the print > > > driver/application is doing. In fact, when I first started working on > > this > > > I used just IN_CLOSE_WRITE and saw 4 invocations. That is what sent > me > > > exploring. > > > > > > Regarding what is in $1, I see what seems to me to indicate a file name > > in > > > $1 *sometimes*. Why only sometimes? Here is the test script: > > > #! /bin/bash > > > # test of incron > > > echo -n "time: $(stat -c '%Y' $1)" >> /home/denis/incronlog.log > > > echo "test: $1 $2" >> /home/denis/incronlog.log > > > > > > I get perhaps 27
Re: [PLUG] incron issue
Me looking at kernel software would be no more educational than me reading about it in Greek. And I did not think I wanted to debug the spooler, whatever that is. So to get down to the essentials, using only IN_CLOSE_WRITE, I get four events (with this particular application printing). For a big print job the timespan from the first event to the last is 10 seconds. I can explore my two other applications and come up with a maximum (probable) time. Add a buffer to that and use that time as a delay prior to printing the file. That was my intended approach. As I understand your approach it is to check the time stamp for the file in question, delay 2 seconds, then assume if no change has occurred, the file is ready to print. Is this understanding correct? If so, this assumes that the driver/application changes the file more frequently than every 2 seconds. To explore that, I was trying to send the time to the log every time I got an icron invocation with the IN_ALL_EVENTS mask. Hence my use of that mask and trying to capture the time to the log. This, I hope, explains why I wanted to see the result of > /home/denis/incronlog.log>, and the question of why no time appears in the log. Notice that there are many cases in the log where $1 appears to be a filename. -Denis On Tue, Nov 21, 2017 at 1:37 PM, Tomas Kuchta wrote: > Of course that you see some/many invocations without any file names when > you trigger on all directory events. All sorts of of processes go by all > sorts of directories all the time on modern desktop. Not all of them look > at files. > > What your aim is, I believe/hope, to respond to print file write and close > - and send that file to a printer. Ideally deleting or backing that file > away from the print dir. You want to do that reliably and without multiple > processes acting on any given file. > > If you want to debug print job spooler, I would suggest to do just that. Do > exactly what you need to do, keep it simple, and expand from there. > > If you are curious about kernel interworks, I would suggest to start > looking at kernel documentation and source code - it is more systematic way > of learning. Unfortunately, I am not the right person to have meaningful > conversation about kernel and VFS events/triggers. My knowledge is too > shallow for that. > > Good luck, > Tomas > > On Nov 21, 2017 9:44 AM, "Denis Heidtmann" > wrote: > > > It is fully my intention to use only IN_CLOSE_WRITE in the final version. > > I currently am using IN_ALL_EVENTS just to see what the print > > driver/application is doing. In fact, when I first started working on > this > > I used just IN_CLOSE_WRITE and saw 4 invocations. That is what sent me > > exploring. > > > > Regarding what is in $1, I see what seems to me to indicate a file name > in > > $1 *sometimes*. Why only sometimes? Here is the test script: > > #! /bin/bash > > # test of incron > > echo -n "time: $(stat -c '%Y' $1)" >> /home/denis/incronlog.log > > echo "test: $1 $2" >> /home/denis/incronlog.log > > > > I get perhaps 270 invocations with IN_ALL_EVENTS. A sampling shows some > > responses with the file name, but no times: > > > > test: IN_ACCESS,IN_ISDIR > > time: test: IN_CLOSE_NOWRITE,IN_ISDIR > > time: test: IN_CLOSE_NOWRITE,IN_ISDIR > > time: test: tst1.PLT IN_OPEN > > time: time: test: tst1.PLT IN_OPEN > > test: tst1.PLT IN_OPEN > > time: test: tst1.PLT IN_CLOSE_NOWRITE > > time: test: tst1.PLT IN_ACCESS > > time: test: tst1.PLT IN_CLOSE_NOWRITE > > time: time: test: IN_CLOSE_NOWRITE,IN_ISDIR > > test: IN_ACCESS,IN_ISDIR > > time: test: tst1.PLT IN_CLOSE_NOWRITE > > > > There are a number of questions raised by this, but I expect that most > can > > be explained by the rapid multiple invocations. Does that also explain > the > > missing times? > > > > -Denis > > > > > > On Tue, Nov 21, 2017 at 12:23 AM, Tomas Kuchta < > > tomas.kuchta.li...@gmail.com > > > wrote: > > > > > $(some command) will simply execute the command and give return value. > > > > > > You do not see any time stamp because you are not giving stat a file. > $1, > > > in > > > your case, doesn't contain file name. > > > > > > I have asked or suggested before to only use IN_CLOSE_WRITE event. That > > is > > > what you want - run the script after the file/dir was written to and is > > > closed. Not the other times when you look at it or read the file with > > your > > > script. Taking those other events off should solve the multiple > > invocation > > > problem. > > > > > > I hope it helps, > > > Tomas > > > > > > > > > On Nov 20, 2017 5:54 PM, "Denis Heidtmann" > > > wrote: > > > > > > Working my way through the script, trying to understand the behavior. > > Here > > > is a simple test: > > > > > > #! /bin/bash > > > # test of incron > > > echo -n "time: $(stat -c '%Y' $1)" >> /home/denis/incronlog.log > > > echo "test: $1 $2" >> /home/denis/incronlog.log > > > # sleep 10 > > > > > > It generates what I would expect when exe
Re: [PLUG] SMTP communications question
On Tue, 21 Nov 2017, Rich Shepard wrote: To improve your emails deliverability, your MTA-EHLO/PTR/MX hostnames should all match. If you use an inbound/cloud filtering service, the hostname in your DNS MX record doesn't need to match, but the MTA EHLO and PTR/reverse DNS should match. They'll all match. Hadn't thought of this since I set up postfix ~20 years ago. In main.cf the myhostname variable was set to salmo.appl-ecosys.com so I just changed it to mail.appl-ecosys.com. They are aliased to each other in /etc/hosts. Thanks again, Alex, Rich ___ PLUG mailing list PLUG@pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
Re: [PLUG] SMTP communications question
> > > BTW, if you can suggest a mail list or web forum for openDKIM assistance > I'd appreciate it. > > I gave up on trying to make mail work a long time ago. In fact, now that I think of it, I believe it was trying to get DKIM to work that finally pushed me over the edge to giving up. -wes ___ PLUG mailing list PLUG@pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
Re: [PLUG] SMTP communications question
On Tue, 21 Nov 2017, Alexandre Bedard wrote: Your EHLO hostname is controlled by your MTA (Postfix, Sendmail,qmail, etc), not the MUA. Most MTA's have a configuration option to specify your mail server's EHLO hostname. Most Linux distros/MTA's will default to the contents of /etc/mailname. Alex, Ah, I didn't remember this. I'll go look for it in master.cf or main.cf and change it from 'salmo' to 'mail.' Then, ... To improve your emails deliverability, your MTA-EHLO/PTR/MX hostnames should all match. If you use an inbound/cloud filtering service, the hostname in your DNS MX record doesn't need to match, but the MTA EHLO and PTR/reverse DNS should match. They'll all match. Happy Thanksgiving, Rich ___ PLUG mailing list PLUG@pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
Re: [PLUG] SMTP communications question
On Tue, 21 Nov 2017, wes wrote: This is up to the administrator of the recipient MTA. They can decide whether to reject mail from senders who claim to be host x in their HELO, but have a different name in their PTR record. In my experience, most of them simply check that a PTR record exists at all, as it used to be hard to get them. Wes, And I just found an answer on the web: "Although email servers can (by RFC) accept connections that have a poorly formatted HELO or server identification string sent during email transmission dialogue (eg MTA to MTA communications) most Best Practises documents insist that all identifiers are correctly used, and in the case of HELO (or EHLO) this applies as well. The principal is that the HELO should identify the sending server in such a way that it can be used to identify servers with problems, such as leaking Spam or incorrectly formatted emails." It's postfix (in your case) that adds the hostname, not alpine. I should have realized this. BTW, if you can suggest a mail list or web forum for openDKIM assistance I'd appreciate it. Happy Thanksgiving, Rich ___ PLUG mailing list PLUG@pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
Re: [PLUG] SMTP communications question
This is up to the administrator of the recipient MTA. They can decide whether to reject mail from senders who claim to be host x in their HELO, but have a different name in their PTR record. In my experience, most of them simply check that a PTR record exists at all, as it used to be hard to get them. It's postfix (in your case) that adds the hostname, not alpine. -wes On Tue, Nov 21, 2017 at 2:44 PM, Rich Shepard wrote: > I understand that when an e-mail message is sent the client MTA initiates > communications with the receiving/relaying server MTA with a HELO or EHLO > command. The recipient MTA is identified by its DNS MX record. Both > HELO/EHLO and MX have a host name prefixed to the domain name. > > Does it matter if the sending MTA host name differs from the PTR host > name? The Frontier DNS tech told me that the PTR host name needed to match > the DNS A record for the sending host (which is mail.) > > My PTR and DNS A records have been set to mail.appl-ecosys.com. When an > outbound message is queued by the recipient MTA's greylisting process I can > see in the postfix queue that the HELO host is salmo.appl-ecosys.com. I > think that the MUA (alpine) adds the host name, but I'm not sure of this. > > Rich > > > > ___ > PLUG mailing list > PLUG@pdxlinux.org > http://lists.pdxlinux.org/mailman/listinfo/plug > ___ PLUG mailing list PLUG@pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
[PLUG] SMTP communications question
I understand that when an e-mail message is sent the client MTA initiates communications with the receiving/relaying server MTA with a HELO or EHLO command. The recipient MTA is identified by its DNS MX record. Both HELO/EHLO and MX have a host name prefixed to the domain name. Does it matter if the sending MTA host name differs from the PTR host name? The Frontier DNS tech told me that the PTR host name needed to match the DNS A record for the sending host (which is mail.) My PTR and DNS A records have been set to mail.appl-ecosys.com. When an outbound message is queued by the recipient MTA's greylisting process I can see in the postfix queue that the HELO host is salmo.appl-ecosys.com. I think that the MUA (alpine) adds the host name, but I'm not sure of this. Rich ___ PLUG mailing list PLUG@pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
Re: [PLUG] incron issue
Of course that you see some/many invocations without any file names when
you trigger on all directory events. All sorts of of processes go by all
sorts of directories all the time on modern desktop. Not all of them look
at files.
What your aim is, I believe/hope, to respond to print file write and close
- and send that file to a printer. Ideally deleting or backing that file
away from the print dir. You want to do that reliably and without multiple
processes acting on any given file.
If you want to debug print job spooler, I would suggest to do just that. Do
exactly what you need to do, keep it simple, and expand from there.
If you are curious about kernel interworks, I would suggest to start
looking at kernel documentation and source code - it is more systematic way
of learning. Unfortunately, I am not the right person to have meaningful
conversation about kernel and VFS events/triggers. My knowledge is too
shallow for that.
Good luck,
Tomas
On Nov 21, 2017 9:44 AM, "Denis Heidtmann"
wrote:
> It is fully my intention to use only IN_CLOSE_WRITE in the final version.
> I currently am using IN_ALL_EVENTS just to see what the print
> driver/application is doing. In fact, when I first started working on this
> I used just IN_CLOSE_WRITE and saw 4 invocations. That is what sent me
> exploring.
>
> Regarding what is in $1, I see what seems to me to indicate a file name in
> $1 *sometimes*. Why only sometimes? Here is the test script:
> #! /bin/bash
> # test of incron
> echo -n "time: $(stat -c '%Y' $1)" >> /home/denis/incronlog.log
> echo "test: $1 $2" >> /home/denis/incronlog.log
>
> I get perhaps 270 invocations with IN_ALL_EVENTS. A sampling shows some
> responses with the file name, but no times:
>
> test: IN_ACCESS,IN_ISDIR
> time: test: IN_CLOSE_NOWRITE,IN_ISDIR
> time: test: IN_CLOSE_NOWRITE,IN_ISDIR
> time: test: tst1.PLT IN_OPEN
> time: time: test: tst1.PLT IN_OPEN
> test: tst1.PLT IN_OPEN
> time: test: tst1.PLT IN_CLOSE_NOWRITE
> time: test: tst1.PLT IN_ACCESS
> time: test: tst1.PLT IN_CLOSE_NOWRITE
> time: time: test: IN_CLOSE_NOWRITE,IN_ISDIR
> test: IN_ACCESS,IN_ISDIR
> time: test: tst1.PLT IN_CLOSE_NOWRITE
>
> There are a number of questions raised by this, but I expect that most can
> be explained by the rapid multiple invocations. Does that also explain the
> missing times?
>
> -Denis
>
>
> On Tue, Nov 21, 2017 at 12:23 AM, Tomas Kuchta <
> tomas.kuchta.li...@gmail.com
> > wrote:
>
> > $(some command) will simply execute the command and give return value.
> >
> > You do not see any time stamp because you are not giving stat a file. $1,
> > in
> > your case, doesn't contain file name.
> >
> > I have asked or suggested before to only use IN_CLOSE_WRITE event. That
> is
> > what you want - run the script after the file/dir was written to and is
> > closed. Not the other times when you look at it or read the file with
> your
> > script. Taking those other events off should solve the multiple
> invocation
> > problem.
> >
> > I hope it helps,
> > Tomas
> >
> >
> > On Nov 20, 2017 5:54 PM, "Denis Heidtmann"
> > wrote:
> >
> > Working my way through the script, trying to understand the behavior.
> Here
> > is a simple test:
> >
> > #! /bin/bash
> > # test of incron
> > echo -n "time: $(stat -c '%Y' $1)" >> /home/denis/incronlog.log
> > echo "test: $1 $2" >> /home/denis/incronlog.log
> > # sleep 10
> >
> > It generates what I would expect when executed from the command line:
> > ~/scripts/intest.sh examples.desktop:
> > time: 1464568514test: examples.desktop
> >
> > But when invoked by incron the line including the time is empty except
> for
> > the word "time:" The time value is absent.
> > time: time: test: IN_ACCESS,IN_ISDIR
> > test: IN_CLOSE_NOWRITE,IN_ISDIR
> > time: test: IN_ACCESS,IN_ISDIR
> > time: test: IN_OPEN,IN_ISDIR
> > time: test: IN_OPEN,IN_ISDIR
> > etc.
> >
> > My knowledge of the use of $, (, ", ', and { is lacking, so I expect
> > that is where the trouble lies.
> >
> > Is the problem obvious?
> >
> > Thanks,
> > -Denis
> >
> > On Sun, Nov 19, 2017 at 10:42 PM, Tomas Kuchta <
> > tomas.kuchta.li...@gmail.com
> > > wrote:
> >
> > > The script I posted does its own locking, so that other copies would
> know
> > > that it is already running and what file it is serving.
> > >
> > > See the lock file being created, checked and removed.
> > >
> > > Tomas
> > >
> > > On Nov 19, 2017 9:10 PM, "Denis Heidtmann"
> > > wrote:
> > >
> > > > Your script has things in it that stretch my knowledge of Bash, so
> > > > understanding what it does is difficult for me.
> > > >
> > > > I have no experience with file locking. Is this a standard protocol?
> > > > Since the print file is created by a Windows print driver, I wonder
> if
> > > the
> > > > locking which is described in the ubuntu docs is reliably applicable.
> > > >
> > > > This is likely a discussion that stretches what is reasonable to
> > attempt
> > > > via a forum, since I need considerabl
Re: [PLUG] incron issue
It is fully my intention to use only IN_CLOSE_WRITE in the final version.
I currently am using IN_ALL_EVENTS just to see what the print
driver/application is doing. In fact, when I first started working on this
I used just IN_CLOSE_WRITE and saw 4 invocations. That is what sent me
exploring.
Regarding what is in $1, I see what seems to me to indicate a file name in
$1 *sometimes*. Why only sometimes? Here is the test script:
#! /bin/bash
# test of incron
echo -n "time: $(stat -c '%Y' $1)" >> /home/denis/incronlog.log
echo "test: $1 $2" >> /home/denis/incronlog.log
I get perhaps 270 invocations with IN_ALL_EVENTS. A sampling shows some
responses with the file name, but no times:
test: IN_ACCESS,IN_ISDIR
time: test: IN_CLOSE_NOWRITE,IN_ISDIR
time: test: IN_CLOSE_NOWRITE,IN_ISDIR
time: test: tst1.PLT IN_OPEN
time: time: test: tst1.PLT IN_OPEN
test: tst1.PLT IN_OPEN
time: test: tst1.PLT IN_CLOSE_NOWRITE
time: test: tst1.PLT IN_ACCESS
time: test: tst1.PLT IN_CLOSE_NOWRITE
time: time: test: IN_CLOSE_NOWRITE,IN_ISDIR
test: IN_ACCESS,IN_ISDIR
time: test: tst1.PLT IN_CLOSE_NOWRITE
There are a number of questions raised by this, but I expect that most can
be explained by the rapid multiple invocations. Does that also explain the
missing times?
-Denis
On Tue, Nov 21, 2017 at 12:23 AM, Tomas Kuchta wrote:
> $(some command) will simply execute the command and give return value.
>
> You do not see any time stamp because you are not giving stat a file. $1,
> in
> your case, doesn't contain file name.
>
> I have asked or suggested before to only use IN_CLOSE_WRITE event. That is
> what you want - run the script after the file/dir was written to and is
> closed. Not the other times when you look at it or read the file with your
> script. Taking those other events off should solve the multiple invocation
> problem.
>
> I hope it helps,
> Tomas
>
>
> On Nov 20, 2017 5:54 PM, "Denis Heidtmann"
> wrote:
>
> Working my way through the script, trying to understand the behavior. Here
> is a simple test:
>
> #! /bin/bash
> # test of incron
> echo -n "time: $(stat -c '%Y' $1)" >> /home/denis/incronlog.log
> echo "test: $1 $2" >> /home/denis/incronlog.log
> # sleep 10
>
> It generates what I would expect when executed from the command line:
> ~/scripts/intest.sh examples.desktop:
> time: 1464568514test: examples.desktop
>
> But when invoked by incron the line including the time is empty except for
> the word "time:" The time value is absent.
> time: time: test: IN_ACCESS,IN_ISDIR
> test: IN_CLOSE_NOWRITE,IN_ISDIR
> time: test: IN_ACCESS,IN_ISDIR
> time: test: IN_OPEN,IN_ISDIR
> time: test: IN_OPEN,IN_ISDIR
> etc.
>
> My knowledge of the use of $, (, ", ', and { is lacking, so I expect
> that is where the trouble lies.
>
> Is the problem obvious?
>
> Thanks,
> -Denis
>
> On Sun, Nov 19, 2017 at 10:42 PM, Tomas Kuchta <
> tomas.kuchta.li...@gmail.com
> > wrote:
>
> > The script I posted does its own locking, so that other copies would know
> > that it is already running and what file it is serving.
> >
> > See the lock file being created, checked and removed.
> >
> > Tomas
> >
> > On Nov 19, 2017 9:10 PM, "Denis Heidtmann"
> > wrote:
> >
> > > Your script has things in it that stretch my knowledge of Bash, so
> > > understanding what it does is difficult for me.
> > >
> > > I have no experience with file locking. Is this a standard protocol?
> > > Since the print file is created by a Windows print driver, I wonder if
> > the
> > > locking which is described in the ubuntu docs is reliably applicable.
> > >
> > > This is likely a discussion that stretches what is reasonable to
> attempt
> > > via a forum, since I need considerable education.
> > >
> > > I appreciate your efforts. I will play with it in an attempt to learn
> > what
> > > you are proposing, but do not be surprised if it takes me some time.
> > >
> > > -Denis
> > >
> > >
> > >
> > > On Sat, Nov 18, 2017 at 9:17 PM, Tom
> > wrote:
> > >
> > > > Hi Denis,
> > > >
> > > > Try something like the script below.
> > > > It uses a lock to detect its own invocation as well as multiple
> > > > invocations of self. If it prints it backs up the printed file, so
> you
> > > > should not lose anything, should things go south.
> > > >
> > > > Note: I did not properly test it. So, give it good pass over and test
> > > > it before calling it a day. As I said, it should not loose any print
> > > > files and you should know if it prints.
> > > >
> > > > Please insert your own print command instead of the echo "" and
> > > > redirect the output to a log file or /dev/null so it does not end up
> > > > with incron.
> > > >
> > > > Beware of broken script lines by the email.
> > > >
> > > > I hope that it works as intended or as an example,
> > > > Tomas
> > > >
> > > > #!/bin/bash
> > > > ##
> > > > # This command submits a file to print
> > > > # It is triggered by incron and tries to
> > > > # grac
Re: [PLUG] Reality check
On 11/20/2017 07:58 PM, Mke C> wrote: On 11/20/2017 05:54 PM, plug-requ...@pdxlinux.org wrote: -clip - When the firewall receives an ICMP packet, ping and traceroute both will show failure and/or lack of "up: state. If the attacker knows the device is there by DNS resolution or IP address, they have a known target, and the dropping of packets (IMO) is just obscuring things a little bit. This is more of an ol' skool mentality that reflects a serious lack of a deeper understanding of networking and of being a good & useful netizen. In reality, we should actually see less and less of this over time as the ICMP protocol suite is very useful and blocking it doesn't amount to very much that's good and/or useful. Coming from an admin background, you are correct that I don't have a deep understanding of networking. I am continually trying to learn from my mistakes, the input of others, and from readings that I can pick up. I agree that ICMP is a useful too, and I am frustrated by the security group at $WORK that has disabled the return of these packets. Other tools that you can try are telnet to the port for the service in question, nmap to check for all open ports (potential for looking like an attacker), and netcat (nc) to test for specific, or scan for all open, ports. A deeper way to search if things are connecting at all is the use of netstat, Wireshark, or tcpdump in some cases. I've been a network engineer for over a decade and I've learned to use the simplest tool possible for a task. In this case tcping is a very good simple and easy to use tool for anyone who's just wanting to test connectivity to network host. Most implementations allow for a port number to be specified. If you're unsure of the port number from the Linux cli you can cat the /etc/services file to get a listing of udp & tcp ports w. description that's updated by IANA. e.g. ~$ cat /etc/services # Network services, Internet style # # Note that it is presently the policy of IANA to assign a single well-known port number for both TCP and UDP; hence, officially ports have two entries # even if the protocol doesn't support UDP operations. # # Updated from http://www.iana.org/assignments/port-numbers and other sources like http://www.freebsd.org/cgi/cvsweb.cgi/src/etc/services . # New ports will be added on request if they have been officially assigned by IANA and used in the real-world or are needed by a debian package. # If you need a huge list of used numbers please install the nmap package. tcpmux 1/tcp # TCP port service multiplexer echo 7/tcp echo 7/udp discard 9/tcp sink null discard 9/udp sink null systat 11/tcp users This particular implementation, https://www.elifulkerson.com/projects/tcping.php , provides a lot of HTTP mode options as well setting wait interval for a response, calculating jitter (variance in delay) and prefer ipv4 or ipv6. Cool, a new tool to check out. Thank you for this information. Network connectivity is going to likely become more problematic, and our means of testing things will likely become more restricted as time passes. Just my guess, but it's a trend I have been noticing. I don't follow nor subscribe to this logic at all. I expect network connectivity and ways to test to it to only get better as everyone and their grandparents demand well performing, highly reliable internet connectivity from all of their devices, everywhere. 5 years ago while working at an ISP in downtown Portland I had to work on networking problems from end-users of our ISP business partners who where complaining about high ping times in their favorite online game. And I'm talking about sub 150 ms round-trip ping times which is used as the measuring stick for toll quality VoIP. My pessimism revolves around the increasing number of attacks by black hats (thinking of Mirai), human errors that impact large networks (recent Level 3 / Comcast routing issues), and the potential of the federal government trying to take away a level playing field. It is my hope that the tools will get better and with it the willingness on the part of the major ISP players to provide more transparency and information real time as problems happen in the future. > Also, consider that IPv6 provides improved QOS functionality, better > security and faster routing on an end to end connection basis. As > infrastructure gets re-designed and changed out I only expect network > connectivity to get less problematic with greater visibility into > problems provided by better tools and information. All good things for me to learn from and consider. IPv6 is not something that I have deep understanding of, and maybe now is the time to start looking at, and learning, it again. dafr ___ PLUG mailing list PLUG@pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
Re: [PLUG] Reality check
Not the original poster - BUT, thank you very much for such positive post Mike. ... more or these please ... and Knipex tools too! On Nov 20, 2017 7:58 PM, "Mke C>" wrote: On 11/20/2017 05:54 PM, plug-requ...@pdxlinux.org wrote: > With the mail/phone issues I've had recently I want to check that I'm >> doing things correctly. Two instances of not reaching web pages. >> >> I can load (and ping)www.opendkim.org, but cannot load (or ping) >> >> lists.opendkim.org. This means their mail list page is off-line. Yes? >> >> No, not necessarily. > > Yesterday and today I try to accesswww.verizonwireless.com but the > > page >> won't load. Neither can I ping that server. This means that their web site >> is down. Yes? >> >> Again, not necessarily. > > More and more IT / Security groups are going to dropping the ICMP (ping) > packets for "security" reasons, and this affects several tools that have > long been used by the layperson and professional alike. > > When the firewall receives an ICMP packet, ping and traceroute both will > show failure and/or lack of "up: state. If the attacker knows the device is > there by DNS resolution or IP address, they have a known target, and the > dropping of packets (IMO) is just obscuring things a little bit. > This is more of an ol' skool mentality that reflects a serious lack of a deeper understanding of networking and of being a good & useful netizen. In reality, we should actually see less and less of this over time as the ICMP protocol suite is very useful and blocking it doesn't amount to very much that's good and/or useful. Other tools that you can try are telnet to the port for the service in > question, nmap to check for all open ports (potential for looking like an > attacker), and netcat (nc) to test for specific, or scan for all open, > ports. > > A deeper way to search if things are connecting at all is the use of > netstat, Wireshark, or tcpdump in some cases. > I've been a network engineer for over a decade and I've learned to use the simplest tool possible for a task. In this case tcping is a very good simple and easy to use tool for anyone who's just wanting to test connectivity to network host. Most implementations allow for a port number to be specified. If you're unsure of the port number from the Linux cli you can cat the /etc/services file to get a listing of udp & tcp ports w. description that's updated by IANA. e.g. ~$ cat /etc/services # Network services, Internet style # # Note that it is presently the policy of IANA to assign a single well-known port number for both TCP and UDP; hence, officially ports have two entries # even if the protocol doesn't support UDP operations. # # Updated from http://www.iana.org/assignments/port-numbers and other sources like http://www.freebsd.org/cgi/cvsweb.cgi/src/etc/services . # New ports will be added on request if they have been officially assigned by IANA and used in the real-world or are needed by a debian package. # If you need a huge list of used numbers please install the nmap package. tcpmux1/tcp# TCP port service multiplexer echo7/tcp echo7/udp discard9/tcpsink null discard9/udpsink null systat11/tcpusers This particular implementation, https://www.elifulkerson.com/p rojects/tcping.php , provides a lot of HTTP mode options as well setting wait interval for a response, calculating jitter (variance in delay) and prefer ipv4 or ipv6. Network connectivity is going to likely become more problematic, and our > means of testing things will likely become more restricted as time passes. > Just my guess, but it's a trend I have been noticing. > I don't follow nor subscribe to this logic at all. I expect network connectivity and ways to test to it to only get better as everyone and their grandparents demand well performing, highly reliable internet connectivity from all of their devices, everywhere. 5 years ago while working at an ISP in downtown Portland I had to work on networking problems from end-users of our ISP business partners who where complaining about high ping times in their favorite online game. And I'm talking about sub 150 ms round-trip ping times which is used as the measuring stick for toll quality VoIP. Also, consider that IPv6 provides improved QOS functionality, better security and faster routing on an end to end connection basis. As infrastructure gets re-designed and changed out I only expect network connectivity to get less problematic with greater visibility into problems provided by better tools and information. ___ PLUG mailing list PLUG@pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug ___ PLUG mailing list PLUG@pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
Re: [PLUG] incron issue
$(some command) will simply execute the command and give return value.
You do not see any time stamp because you are not giving stat a file. $1, in
your case, doesn't contain file name.
I have asked or suggested before to only use IN_CLOSE_WRITE event. That is
what you want - run the script after the file/dir was written to and is
closed. Not the other times when you look at it or read the file with your
script. Taking those other events off should solve the multiple invocation
problem.
I hope it helps,
Tomas
On Nov 20, 2017 5:54 PM, "Denis Heidtmann"
wrote:
Working my way through the script, trying to understand the behavior. Here
is a simple test:
#! /bin/bash
# test of incron
echo -n "time: $(stat -c '%Y' $1)" >> /home/denis/incronlog.log
echo "test: $1 $2" >> /home/denis/incronlog.log
# sleep 10
It generates what I would expect when executed from the command line:
~/scripts/intest.sh examples.desktop:
time: 1464568514test: examples.desktop
But when invoked by incron the line including the time is empty except for
the word "time:" The time value is absent.
time: time: test: IN_ACCESS,IN_ISDIR
test: IN_CLOSE_NOWRITE,IN_ISDIR
time: test: IN_ACCESS,IN_ISDIR
time: test: IN_OPEN,IN_ISDIR
time: test: IN_OPEN,IN_ISDIR
etc.
My knowledge of the use of $, (, ", ', and { is lacking, so I expect
that is where the trouble lies.
Is the problem obvious?
Thanks,
-Denis
On Sun, Nov 19, 2017 at 10:42 PM, Tomas Kuchta wrote:
> The script I posted does its own locking, so that other copies would know
> that it is already running and what file it is serving.
>
> See the lock file being created, checked and removed.
>
> Tomas
>
> On Nov 19, 2017 9:10 PM, "Denis Heidtmann"
> wrote:
>
> > Your script has things in it that stretch my knowledge of Bash, so
> > understanding what it does is difficult for me.
> >
> > I have no experience with file locking. Is this a standard protocol?
> > Since the print file is created by a Windows print driver, I wonder if
> the
> > locking which is described in the ubuntu docs is reliably applicable.
> >
> > This is likely a discussion that stretches what is reasonable to attempt
> > via a forum, since I need considerable education.
> >
> > I appreciate your efforts. I will play with it in an attempt to learn
> what
> > you are proposing, but do not be surprised if it takes me some time.
> >
> > -Denis
> >
> >
> >
> > On Sat, Nov 18, 2017 at 9:17 PM, Tom
> wrote:
> >
> > > Hi Denis,
> > >
> > > Try something like the script below.
> > > It uses a lock to detect its own invocation as well as multiple
> > > invocations of self. If it prints it backs up the printed file, so you
> > > should not lose anything, should things go south.
> > >
> > > Note: I did not properly test it. So, give it good pass over and test
> > > it before calling it a day. As I said, it should not loose any print
> > > files and you should know if it prints.
> > >
> > > Please insert your own print command instead of the echo "" and
> > > redirect the output to a log file or /dev/null so it does not end up
> > > with incron.
> > >
> > > Beware of broken script lines by the email.
> > >
> > > I hope that it works as intended or as an example,
> > > Tomas
> > >
> > > #!/bin/bash
> > > ##
> > > # This command submits a file to print
> > > # It is triggered by incron and tries to
> > > # gracefully deal with multiple incron invocations
> > > # and waits for file to be closed by the
> > > # print application.
> > > # Example incron line:
> > > # printDirToMonitor IN_CLOSE_WRITE submitPrinterJob.bash $#
> > > ##
> > > lockDir=/tmp/
> > > lockFileBaseName=/tmp/submitPrinterJob
> > > thisPid=$$
> > > fileToPrint=$1
> > > printedFilesDir=/home/$USER/printedFilesDir
> > > mkdir -p $printedFilesDir
> > >
> > > searchLockPattern="${lockFileBaseName}_${fileToPrint}_*.lock"
> > > myLockFileName="${lockFileBaseName}_${fileToPrint}_${thisPid}.lock"
> > >
> > > # check if the file to print is still there
> > > if [ -e $fileToPrint ]; then
> > > # Check if another script is running and serving this file
> > > # Issue lock if not
> > > c=0
> > > while (( $c < 2 )); do
> > > if [ ! -e $searchLockPattern ]; then
> > > # Cannot see any other process'lock
> > > touch $myLockFileName
> > > else
> > > # there is a lock
> > > if [ ! -e $myLockFileName ]; then
> > > # the lock is not mine --> exit without printing,
> > > # make sure not to leave own lock, in case it take time to
> > > # show up
> > > rm -f $myLockFileName
> > > exit 0
> > > fi
> > > fi
> > > # There should be a lock and mine --> do nothing , just wait
> > > c=$(( $c + 1 ))
> > > sleep 2
> > > done
> > > # if I got here I got a lock --> send the file to printer
> > > if [ ! -e $fileToPrint ]; then
> > > echo "WARNING: File $fileToPrint disapeared"
> > > else
