On Thursday 22 March 2007, Douglas K. Rand wrote:
>Doug> I'm running an Amanda client on a pair of FreeBSD 5.4 and after
>Doug> upgrading from 2.4.5p1 to 2.5.1p3 I'm getting core dumps of
> amandad.
>
>Doug> Anybody have any ideas before I simply downgrade back to 2.4.5?
>
>Gene> When you did the upgrade was an ldconfig done as the last thing,
>Gene> or very close to last in order to refresh the library linkages
>Gene> correctly?
>
>Yup. I did the upgrade via portupgrade on FreeBSD, and at the very end
>of the session:
>
> ===> Compressing manual pages for amanda-client-2.5.1p3_1,1
> ===> Running ldconfig
> /sbin/ldconfig -m /usr/local/lib
> ===> Registering installation for amanda-client-2.5.1p3_1,1
>
>
>Gene> It shouldn't hurt to do it again by hand, as root, just to
>Gene> check.
>
>Just did so and re-ran my test. Same result:
>
> Program terminated with signal 11, Segmentation fault.
> #0 0x0804ac8d in s_ackwait (as=0x805b000, action=A_RECVPKT,
> pkt=0x280bb000) at amandad.c:1068 1068
> security_stream_read(dh->netfd, process_writenetfd, dh);
>
>Doug> These hosts are behind a firewall, but I checked that the
>Doug> AMANDA_PORTRANGE=50001,50099 and AMANDA_UDPPORTRANGE=801,899 knobs
>Doug> from /etc/make.conf are correctly finding their way into
>Doug> config.status: '--with-udpportrange=801,899'
>Doug> '--with-portrange=50001,50099'
>
>Gene> And are these ports actually open to these protocols according
>Gene> to the firewall rules?
>
>Yes, because the 2.4.5p1 version worked like a charm, and because my
>packet filter config has:
>
> amanda="67.134.74.26"
> amandaports="50000:50100"
> [...]
> pass in log quick inet proto tcp from $amanda to $lan port
> $amandaports flags S/SARF keep state pass in log quick inet proto udp
> from $amanda to $lan port amanda keep state
>
>Damn it, the above is a lie.
>
>I just watched with tcpdump the actual traffic and clearly something
>isn't happening right. From the packet filter log:
>
>17:50:48.462364 rule 21/0(match): pass in on fxp0: IP 67.134.74.26.874 >
> 207.109.234.250.10080: UDP, length: 125 17:50:48.591917 rule
> 21/0(match): pass in on fxp0: IP 67.134.74.26.877 >
> 207.109.234.250.10080: UDP, length: 260 17:50:48.636197 rule
> 0/0(match): block in on fxp0: IP 67.134.74.26.1026 >
> 207.109.234.250.53055: S 160641676:160641676(0) win 65535 <mss
> 1460,nop,wscale 1,nop,nop,timestamp 611117423 0,sackOK,eol>
> 17:50:51.634698 rule 0/0(match): block in on fxp0: IP 67.134.74.26.1026
> > 207.109.234.250.53055: S 160641676:160641676(0) win 65535 <mss
> 1460,nop,wscale 1,nop,nop,timestamp 611120423 0,sackOK,eol>
> 17:50:54.833986 rule 0/0(match): block in on fxp0: IP 67.134.74.26.1026
> > 207.109.234.250.53055: S 160641676:160641676(0) win 65535 <mss
> 1460,nop,wscale 1,nop,nop,timestamp 611123623 0,sackOK,eol>
> 17:50:58.033361 rule 0/0(match): block in on fxp0: IP 67.134.74.26.1026
> > 207.109.234.250.53055: S 160641676:160641676(0) win 65535 <mss
> 1460,sackOK,eol> 17:51:01.232929 rule 0/0(match): block in on fxp0: IP
> 67.134.74.26.1026 > 207.109.234.250.53055: S 160641676:160641676(0) win
> 65535 <mss 1460,sackOK,eol> 17:51:04.432183 rule 0/0(match): block in
> on fxp0: IP 67.134.74.26.1026 > 207.109.234.250.53055: S
> 160641676:160641676(0) win 65535 <mss 1460,sackOK,eol> 17:51:10.630986
> rule 0/0(match): block in on fxp0: IP 67.134.74.26.1026 >
> 207.109.234.250.53055: S 160641676:160641676(0) win 65535 <mss
> 1460,sackOK,eol> 17:51:22.828770 rule 0/0(match): block in on fxp0: IP
> 67.134.74.26.1026 > 207.109.234.250.53055: S 160641676:160641676(0) win
> 65535 <mss 1460,sackOK,eol> 17:51:47.024174 rule 0/0(match): block in
> on fxp0: IP 67.134.74.26.1026 > 207.109.234.250.53055: S
> 160641676:160641676(0) win 65535 <mss 1460,sackOK,eol> 17:52:03.654909
> rule 21/0(match): pass in on fxp0: IP 67.134.74.26.877 >
> 207.109.234.250.10080: UDP, length: 257 17:52:03.735340 rule
> 0/0(match): block in on fxp0: IP 67.134.74.26.1026 >
> 207.109.234.250.57850: S 2945510063:2945510063(0) win 65535 <mss
> 1460,nop,wscale 1,nop,nop,timestamp 611192537 0,sackOK,eol>
> 17:52:06.734533 rule 0/0(match): block in on fxp0: IP 67.134.74.26.1026
> > 207.109.234.250.57850: S 2945510063:2945510063(0) win 65535 <mss
> 1460,nop,wscale 1,nop,nop,timestamp 611195537 0,sackOK,eol>
> 17:52:09.933969 rule 0/0(match): block in on fxp0: IP 67.134.74.26.1026
> > 207.109.234.250.57850: S 2945510063:2945510063(0) win 65535 <mss
> 1460,nop,wscale 1,nop,nop,timestamp 611198737 0,sackOK,eol>
> 17:52:13.133348 rule 0/0(match): block in on fxp0: IP 67.134.74.26.1026
> > 207.109.234.250.57850: S 2945510063:2945510063(0) win 65535 <mss
> 1460,sackOK,eol> 17:52:16.332645 rule 0/0(match): block in on fxp0: IP
> 67.134.74.26.1026 > 207.109.234.250.57850: S 2945510063:2945510063(0)
> win 65535 <mss 1460,sackOK,eol> 17:52:19.532136 rule 0/0(match): block
> in on fxp0: IP 67.134.74.26.1026 > 207.109.234.250.57850: S
> 2945510063:2945510063(0) win 65535 <mss 1460,sackOK,eol>
> 17:52:25.730933 rule 0/0(match): block in on fxp0: IP 67.134.74.26.1026
> > 207.109.234.250.57850: S 2945510063:2945510063(0) win 65535 <mss
> 1460,sackOK,eol> 17:52:37.928605 rule 0/0(match): block in on fxp0: IP
> 67.134.74.26.1026 > 207.109.234.250.57850: S 2945510063:2945510063(0)
> win 65535 <mss 1460,sackOK,eol> 17:53:02.124096 rule 0/0(match): block
> in on fxp0: IP 67.134.74.26.1026 > 207.109.234.250.57850: S
> 2945510063:2945510063(0) win 65535 <mss 1460,sackOK,eol>
>
>So clearly the problem is that my new client isn't using the right
>ports, which is further shown by this packet from the client to the
>server:
>
> 17:57:30.601244 IP 207.109.234.250.10080 > 67.134.74.26.891: UDP,
> length: 131 0x0000: 4500 009f d4a8 0000 4011 5d9d cf6d eafa
> E.......@.]..m.. 0x0010: 4386 4a1a 2760 037b 008b f2a2 416d 616e
> C.J.'`.{....Aman 0x0020: 6461 2032 2e35 2052 4550 2048 414e 444c
> da.2.5.REP.HANDL 0x0030: 4520 3030 302d 3030 3030 3030 3030 2053
> E.000-00000000.S 0x0040: 4551 2031 3137 3531 3634 3738 320a 434f
> EQ.1175164782.CO 0x0050: 4e4e 4543 5420 4441 5441 2035 3433 3230
> NNECT.DATA.54320 0x0060: 204d 4553 4720 3535 3433 3220 494e 4445
> .MESG.55432.INDE 0x0070: 5820 3537 3333 380a 4f50 5449 4f4e 5320
> X.57338.OPTIONS. 0x0080: 6665 6174 7572 6573 3d66 6666 6666 6566
> features=fffffef 0x0090: 6639 6666 6566 6666 6666 6637 663b 0a
> f9ffeffffff7f;.
>
>And then the server is unable to establish a connection to port 54320
>on the client. From the config.status file here's the config line,
>with some arbitrary white space added for readability:
>
> configured by ./configure, generated by GNU Autoconf 2.59,
> with options \"
> '--libexecdir=/usr/local/libexec/amanda'
> '--with-amandahosts'
> '--with-fqdn'
> '--with-dump-honor-nodump'
> '--with-buffered-dump'
> '--disable-libtool'
> '--with-user=operator'
> '--with-group=operator'
> '--with-index-server=amanda.meridian-enviro.com'
> '--with-tape-server=amanda.meridian-enviro.com'
> '--with-config=daily'
> '--with-udpportrange=801,899'
> '--with-portrange=50001,50099'
> '--with-gnutar-listdir=/var/amanda/gnutar-lists'
> '--with-gnutar=/usr/local/bin/gtar'
> '--without-server'
> '--prefix=/usr/local'
> '--build=i386-portbld-freebsd5.4'
> 'CFLAGS=-g'
> 'CXX=c++'
> 'build_alias=i386-portbld-freebsd5.4'
> 'CC=cc'
> 'CXXFLAGS=-g'\"
>
>And inspection of the configure script suggests that the ChangeLog is
>incorrect:
>
> 2001-08-14 John R. Jackson (jrj AT purdue DOT edu)
> [...]
> * configure.in: Added several more port range sanity checks.
> Added --with-tcpportrange as an alias for --with-portrange.
>
>It seems that rev 1.327 removed support for --with-portrange.
>
>I just tweaked the Makefile for the misc/amanda-server port (which is
>a slave of the amanda-client port) to use --with-tcpportrange instead
>of --with-portrange and it works like a champ.
>
>The interesting part is that I'm actually the guy that submitted the
>patch to add the AMANDA_PORTRANGE and AMANDA_UDPPORTRANGE knobs to
>/etc/make.conf for the FreeBSD port of amanda. ;)
>
>I'll submit a PR to fix this problem.
Chuckle, darned if I'm not reminded of the shoemakers kids story. The one
about everybody in town having good shoes except the shoemakers kids, he
too busy making shoes for everyone else.
But you got it fixed, and that's what counts.
FWIW, I'm on linux, and have been using this script to drive my configure
for quite a while now, saves me from making all them darned typu's you
know :)
--------------
#!/bin/sh
# since I'm always forgetting to su amanda...
if [ `whoami` != 'amanda' ]; then
echo
echo "!!!!!!!!!!!! Warning !!!!!!!!!!!!"
echo "Amanda needs to be configured and built by the user amanda,"
echo "but must be installed by user root."
echo
exit 1
fi
make clean
rm -f config.status config.cache
./configure --with-user=amanda \
--with-group=disk \
--with-owner=amanda \
--with-gnu-ld \
--prefix=/usr/local \
--with-tapedev="FILE:/amandatapes" \
--with-debugging=/tmp/amanda-dbg/ \
--with-tape-server=coyote \
--with-bsdtcp-security --with-amandahosts \
--with-configdir=/usr/local/etc/amanda \
--with-config=Daily \
--with-gnutar=/bin/tar
make
---------
But that has no provisions for poking holes in a firewall as everything is
behind a dd-wrt firewall here these days. All that's left when this is
done is to become root and do the 'make install;ldconfig;su
amanda -c "amcheck Daily"'
Which, since I was just installing the 2.5.1p3-20070321 snapshot, reminded
me to finish by doing the above. Amcheck Daily looks good. I build all
of this from the tarball as I wouldn't let rpm even sniff at this, the
perms would be hosed for sure.
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
The greatest dangers to liberty lurk in insidious encroachment by men
of zeal, well-meaning but without understanding.
-- Justice Louis D. Brandeis
|
