Re: [PLUG] incron issue

[Tomas Kuchta]

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
> > echo "Printing file $fileToPrint"
> > # backing up and removing printed file
> > mv $fileToPrint $printedFilesDir
> > sleep 1
> > # removing lock file
> > rm -f $myLockFileName
> >   fi
> > fi
> > exit 0
> > ##
> >
> > On Sat, 2017-11-18 at 15:01 -0800, Denis Heidtmann wrote:
> > > It turns out that the multiple file closings is at least partially
> > > attributable to the application, since another application had two
> > > closings
> > > rather than four.  Using the application with the four closings I
> > > tried
> > > again with a much more complicated drawing.  This slowed down the
> > > writing
> > > of the print file to 10 seconds.  Those 10 seconds were taken up
> > > mostly
> > > between the first and second closing (4 sec.) and the third and
> > > fourth (6
> > > sec.)  I may need to put a delay at the start of my printing script
> > > so it
> > > does not try to print an incomplete file.
> > >
> > > An aside:  The "masks" in the incrontab are separated by comas but no
> > > spaces are allowed.
> > >
> > > Nothing turns out as simple as it appears initially.
> > >
> > > -Denis
> > >
> > > On Fri, Nov 17, 2017 at 11:38 PM, Tom 
> > > wrote:
> > >
> > > >
> > > > I am glad you worked it out. Well done.
> > > >
> > > > Darn fast computers!!
> > > >
> > > > -T
> > > >
> > > > On Fri, 2017-11-17 at 18:04 -0800, Denis Heidtmann wrote:
> > > > >
> > > > > On the "Create":  this convinces me that I should take up
> > > > > drinking
> > > > > coffee,
> > > > > so some stronger 

Re: [PLUG] incron issue

[Denis Heidtmann]

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
> echo "Printing file $fileToPrint"
> # backing up and removing printed file
> mv $fileToPrint $printedFilesDir
> sleep 1
> # removing lock file
> rm -f $myLockFileName
>   fi
> fi
> exit 0
> ##
>
> On Sat, 2017-11-18 at 15:01 -0800, Denis Heidtmann wrote:
> > It turns out that the multiple file closings is at least partially
> > attributable to the application, since another application had two
> > closings
> > rather than four.  Using the application with the four closings I
> > tried
> > again with a much more complicated drawing.  This slowed down the
> > writing
> > of the print file to 10 seconds.  Those 10 seconds were taken up
> > mostly
> > between the first and second closing (4 sec.) and the third and
> > fourth (6
> > sec.)  I may need to put a delay at the start of my printing script
> > so it
> > does not try to print an incomplete file.
> >
> > An aside:  The "masks" in the incrontab are separated by comas but no
> > spaces are allowed.
> >
> > Nothing turns out as simple as it appears initially.
> >
> > -Denis
> >
> > On Fri, Nov 17, 2017 at 11:38 PM, Tom 
> > wrote:
> >
> > >
> > > I am glad you worked it out. Well done.
> > >
> > > Darn fast computers!!
> > >
> > > -T
> > >
> > > On Fri, 2017-11-17 at 18:04 -0800, Denis Heidtmann wrote:
> > > >
> > > > On the "Create":  this convinces me that I should take up
> > > > drinking
> > > > coffee,
> > > > so some stronger brain stimulant. Dumb.
> > > >
> > > > On the multiple entries, I think the issue is that my test script
> > > > is
> > > > very
> > > > short and fast.  I added a sleep 10 and I get only one entry--the
> > > > first
> > > > one.  Apparently the print driver (or the program calling it)
> > > > closes
> > > > the
> > > > file multiple times.  I added $% to the incrontab file and %2 to
> > > > the
> > > > script
> > > > (but w/o the sleep in my script) I got:
> > > >
> > > > test1 create  test23 IN_CLOSE_WRITE
> > > > test1 create  

Re: [PLUG] Reality check

[david]

On 11/18/2017 03:47 PM, Rich Shepard 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 access www.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.


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.


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.


dafr
___
PLUG mailing list
PLUG@pdxlinux.org
http://lists.pdxlinux.org/mailman/listinfo/plug

[PLUG] openDKIM configuration needs fixing

[Rich Shepard]

  My switch from SpiritOne to Frontier FiOS has been an education because I
once again have a static IP address and am seeing a bunch of issues not
before encountered. Most I've resolved, two remain.

  When I tried sending a response to John yesterday it was rejected by
gmx.net because of a failed reverse DNS lookup; the PTR record points to
..bvtn.or.frontiernet.net rather than ..mail.appl-ecosys.com because Frontier
assumed I have a a mail account with them. After a half-hour on the phone
with their service rep yesterday he learned that the folks who can change
the PTR record don't work weekends. Sigh. I'll take care of this tomorrow.

  My DNS records are now fully SPF-compliant, thanks to help from an IT mail
openSPF expert in Dublin. Mail sent from both my domains to
check-a...@verifier.port25.com pass the SPF test.

  The remaining issue is getting openDKIM to pass the port25.com
verification. Yesterday I installed it (using a SlackBuilds.org package) and
ran through the setup of keys, known hosts, etc. following a blog page based
on CentOS. When I start opendkim it does so and tells me it's running. But,
when I send messages to port25.com it does not see DKIM.

  I still cannot load lists.opendkim.org; traceroute fails at 13 hops:
be2095.rcr21.b001848-1.sjc01.atlas.cogentco.com (154.54.3.138) 25.898 ms
be2063.rcr21.b001848-1.sjc01.atlas.cogentco.com (154.54.1.162) 24.978 ms
25.118 ms

  This is all terra incognita for me and I would like help checking
configuration and everything else to find why it starts but is not seen by a
mail recipient.

  If you understand opendkim and will help me get it going, please contact
me off the list.

Rich
___
PLUG mailing list
PLUG@pdxlinux.org
http://lists.pdxlinux.org/mailman/listinfo/plug