Re: DLE entries containing # (hash mark) break the communication

2017-06-26 Thread Jon LaBadie 
On Mon, Jun 26, 2017 at 05:15:34PM +0200, Heiko Schlittermann wrote:
> Jon LaBadie  (Mo 26 Jun 2017 16:40:34 CEST):
> …
> > > ERROR [FORMAT ERROR IN REQUEST PACKET Error on line 1 char 2216: \
> > > Element 'property' was closed, but the currently open element is 
> > > 'value']
> > > 
> > > 
> > > If I replace the "#" by "?" it works find. The behaviour is reproducable
> > > if I put "#" anywhere else in some other patterns.
> > 
> > I have no comment on the "defect".  Just a possible workaround
> > that, if it works, will match the original pattern.
> > 
> > Rather than using a "?" wildcard that matches any character,
> > use a character class that only matches the octothorpe, "[#]".
> 
> No, that doesn't work, as [#] still contains the #, which triggers
> the defect.
> 

Typically the octothorpe only causes problems as the lead character
or after whitespace.  I had hoped that at some point amanda was
striping things in your pattern to the last "/" making the "#"
the first char.

> ["-$]
> 
> could work, it limits the collateral damage from matching any character
> to matching " and $ additionally to #.
> 

Then old-fart that I am, I was thinking [^ -"$->] but realized that is
so ASCII/US-centric of me.

> Best regards from Dresden/Germany
> Viele Grüße aus Dresden
> Heiko Schlittermann
> -- 
>  SCHLITTERMANN.de  internet & unix support -
>  Heiko Schlittermann, Dipl.-Ing. (TU) - {fon,fax}: +49.351.802998{1,3} -
>  gnupg encrypted messages are welcome --- key ID: F69376CE -
>  ! key id 7CBF764A and 972EAC9F are revoked since 2015-01  -


>>> End of included message <<<

-- 
Jon H. LaBadie j...@jgcomp.com
 11226 South Shore Rd.  (703) 787-0688 (H)
 Reston, VA  20190  (703) 935-6720 (C)

Re: DLE entries containing # (hash mark) break the communication

2017-06-26 Thread Heiko Schlittermann 
Jon LaBadie  (Mo 26 Jun 2017 16:40:34 CEST):
…
> > ERROR [FORMAT ERROR IN REQUEST PACKET Error on line 1 char 2216: \
> > Element 'property' was closed, but the currently open element is 
> > 'value']
> > 
> > 
> > If I replace the "#" by "?" it works find. The behaviour is reproducable
> > if I put "#" anywhere else in some other patterns.
> 
> I have no comment on the "defect".  Just a possible workaround
> that, if it works, will match the original pattern.
> 
> Rather than using a "?" wildcard that matches any character,
> use a character class that only matches the octothorpe, "[#]".

No, that doesn't work, as [#] still contains the #, which triggers
the defect.

["-$]

could work, it limits the collateral damage from matching any character
to matching " and $ additionally to #.

Best regards from Dresden/Germany
Viele Grüße aus Dresden
Heiko Schlittermann
-- 
 SCHLITTERMANN.de  internet & unix support -
 Heiko Schlittermann, Dipl.-Ing. (TU) - {fon,fax}: +49.351.802998{1,3} -
 gnupg encrypted messages are welcome --- key ID: F69376CE -
 ! key id 7CBF764A and 972EAC9F are revoked since 2015-01  -


signature.asc
Description: PGP signature

Re: DLE entries containing # (hash mark) break the communication

2017-06-26 Thread Jon LaBadie 
On Mon, Jun 26, 2017 at 01:42:55PM +0200, Heiko Schlittermann wrote:
> Hello,
> 
> Amanda-Server is3.3.6   (package by Debian 8 (jessie))
> Amanda-Client is3.3.9   (package by Debian 9 (stretch))
> 
> My server side configuration contains:
> 
> define application tar {
> plugin "amgtar"
> # grep -E (posix extended regular expressions)
> …
> property append "NORMAL" "/#sql_[0-9a-zA-Z]+_[0-9]+\.MY[DI]: File removed 
> before we read it$"
> …
> }
> 
> Note the "#" in the pattern!
> 
> ERROR [FORMAT ERROR IN REQUEST PACKET Error on line 1 char 2216: \
> Element 'property' was closed, but the currently open element is 'value']
> 
> 
> If I replace the "#" by "?" it works find. The behaviour is reproducable
> if I put "#" anywhere else in some other patterns.

I have no comment on the "defect".  Just a possible workaround
that, if it works, will match the original pattern.

Rather than using a "?" wildcard that matches any character,
use a character class that only matches the octothorpe, "[#]".

-- 
Jon H. LaBadie j...@jgcomp.com
 11226 South Shore Rd.  (703) 787-0688 (H)
 Reston, VA  20190  (703) 935-6720 (C)

DLE entries containing # (hash mark) break the communication

2017-06-26 Thread Heiko Schlittermann 
Hello,

Amanda-Server is3.3.6   (package by Debian 8 (jessie))
Amanda-Client is3.3.9   (package by Debian 9 (stretch))

My server side configuration contains:

define application tar {
plugin "amgtar"
# grep -E (posix extended regular expressions)
…
property append "NORMAL" "/#sql_[0-9a-zA-Z]+_[0-9]+\.MY[DI]: File removed 
before we read it$"
…
}

Note the "#" in the pattern!

ERROR [FORMAT ERROR IN REQUEST PACKET Error on line 1 char 2216: \
Element 'property' was closed, but the currently open element is 'value']


If I replace the "#" by "?" it works find. The behaviour is reproducable
if I put "#" anywhere else in some other patterns.

My question: Is this solved already? Or should I start digging into the
code of the amanda-client (the problem appeared with the update to
3.3.9)?

For me it looks as if the client code assumes that everything following
the # is a comment (or some similiar idea) and stops parsing the DLE
entry.

For reference I'll attach the complete debug log

Best regards from Dresden/Germany
Viele Grüße aus Dresden
Heiko Schlittermann
-- 
 SCHLITTERMANN.de  internet & unix support -
 Heiko Schlittermann, Dipl.-Ing. (TU) - {fon,fax}: +49.351.802998{1,3} -
 gnupg encrypted messages are welcome --- key ID: F69376CE -
 ! key id 7CBF764A and 972EAC9F are revoked since 2015-01  -
Mon Jun 26 13:11:22 2017: thd-0x8202a600: amandad: pid 7114 ruid 34 euid 34 
version 3.3.9: start at Mon Jun 26 13:11:22 2017
Mon Jun 26 13:11:22 2017: thd-0x8202a600: amandad: 
security_getdriver(name=bsdtcp) returns 0xb7684500
Mon Jun 26 13:11:22 2017: thd-0x8202a600: amandad: version 3.3.9
Mon Jun 26 13:11:22 2017: thd-0x8202a600: amandad: build: 
VERSION="Amanda-3.3.9" BUILT_DATE="" BUILT_MACH=""
Mon Jun 26 13:11:22 2017: thd-0x8202a600: amandad:BUILT_REV="6535" 
BUILT_BRANCH="tags" CC="gcc"
Mon Jun 26 13:11:22 2017: thd-0x8202a600: amandad: paths: 
bindir="/usr/sbin" sbindir="/usr/sbin"
Mon Jun 26 13:11:22 2017: thd-0x8202a600: amandad:
libexecdir="/usr/lib/amanda"
Mon Jun 26 13:11:22 2017: thd-0x8202a600: amandad:
amlibexecdir="/usr/lib/amanda" mandir="/usr/share/man"
Mon Jun 26 13:11:22 2017: thd-0x8202a600: amandad:
AMANDA_TMPDIR="/tmp/amanda"
Mon Jun 26 13:11:22 2017: thd-0x8202a600: amandad:
AMANDA_DBGDIR="/var/log/amanda" CONFIG_DIR="/etc/amanda"
Mon Jun 26 13:11:22 2017: thd-0x8202a600: amandad:
DEV_PREFIX="/dev/" RDEV_PREFIX="/dev/r"
Mon Jun 26 13:11:22 2017: thd-0x8202a600: amandad:DUMP="/sbin/dump" 
RESTORE="/sbin/restore" VDUMP=UNDEF
Mon Jun 26 13:11:22 2017: thd-0x8202a600: amandad:VRESTORE=UNDEF 
XFSDUMP="/sbin/xfsdump"
Mon Jun 26 13:11:22 2017: thd-0x8202a600: amandad:
XFSRESTORE="/sbin/xfsrestore" VXDUMP=UNDEF VXRESTORE=UNDEF
Mon Jun 26 13:11:22 2017: thd-0x8202a600: amandad:
SAMBA_CLIENT="/usr/bin/smbclient" GNUTAR="/bin/tar"
Mon Jun 26 13:11:22 2017: thd-0x8202a600: amandad:
COMPRESS_PATH="/bin/gzip" UNCOMPRESS_PATH="/bin/gzip"
Mon Jun 26 13:11:22 2017: thd-0x8202a600: amandad: LPRCMD=UNDEF  
MAILER=UNDEF
Mon Jun 26 13:11:22 2017: thd-0x8202a600: amandad:
listed_incr_dir="/var/lib/amanda/gnutar-lists"
Mon Jun 26 13:11:22 2017: thd-0x8202a600: amandad: defs:  
DEFAULT_SERVER="localhost" DEFAULT_CONFIG="DailySet1"
Mon Jun 26 13:11:22 2017: thd-0x8202a600: amandad:
DEFAULT_TAPE_SERVER="localhost" DEFAULT_TAPE_DEVICE=""
Mon Jun 26 13:11:22 2017: thd-0x8202a600: amandad:NEED_STRSTR 
AMFLOCK_POSIX AMFLOCK_FLOCK AMFLOCK_LOCKF
Mon Jun 26 13:11:22 2017: thd-0x8202a600: amandad:AMFLOCK_LNLOCK 
SETPGRP_VOID AMANDA_DEBUG_DAYS=4 BSD_SECURITY
Mon Jun 26 13:11:22 2017: thd-0x8202a600: amandad:USE_AMANDAHOSTS 
CLIENT_LOGIN="backup" CHECK_USERID HAVE_GZIP
Mon Jun 26 13:11:22 2017: thd-0x8202a600: amandad:
COMPRESS_SUFFIX=".gz" COMPRESS_FAST_OPT="--fast"
Mon Jun 26 13:11:22 2017: thd-0x8202a600: amandad:
COMPRESS_BEST_OPT="--best" UNCOMPRESS_OPT="-dc"
Mon Jun 26 13:11:22 2017: thd-0x8202a600: amandad:CONFIGURE_ARGS=" 
'--build=i686-linux-gnu' '--includedir=${prefix}/include' 
'--mandir=${prefix}/share/man' '--infodir=${prefix}/share/info' 
'--localstatedir=/var' '--disable-silent-rules' 
'--libdir=${prefix}/lib/i386-linux-gnu' 
'--libexecdir=${prefix}/lib/i386-linux-gnu' '--disable-maintainer-mode' 
'--disable-dependency-tracking' '--prefix=/usr' '--bindir=/usr/sbin' 
'--libexecdir=/usr/lib/amanda' '--without-amlibexecdir' '--without-amperldir' 
'--sysconfdir=/etc' '--sharedstatedir=/var/lib' '--localstatedir=/var/lib' 
'--with-user=backup' '--with-group=backup' '--with-tcpportrange=5,50100' 
'--with-udpportrange=840,860' '--with-debugging=/var/log/amanda' 
'--with-gnutar-listdir=/var/lib/amanda/gnutar-lists' 
'--with-amandates=/var/lib/amanda/amandates'

RESULTS MISSING on all DLE when only one estimate fails?

2017-06-26 Thread Matthias Teege 
Hallo!

I've installed Amanda 3.3.3 on a Centos server. Sometimes backups are
failing with "RESULTS MISSING" and "driver: WARNING: got empty
schedule from planner". I think this is mostly because of estimate
timeouts. I see "planner: ERROR Some estimate timeout on
a.example.com, using server estimate if possible". Thats something I
can handle.

But why do I get "RESULTS MISSING" for all hosts/DLE and "... empty
schedule ..." when only one estimate fails? There are planner/estimate
results from all my DLE, except one, in the logs. Shouldn't the amanda
planner return a schedule without the failing DLE?

Thanks!
Matthias