"port xxx not secure" errors
Hi all,
This is my last problem for the time being...
Server side reports this (amdump.1):
driver: result time 2126.498 from dumper2: TRY-AGAIN 02-9 "NAK: host
h-74-0-x-28.phlapafg.covad.net: port 1026 not secure"
The IP address there is the amanda server.
Client side reports this (amandad.debug):
security_handleinit(handle=0x8052000, driver=0x28094900 (BSDTCP))
security_streaminit(stream=0x8058000, driver=0x28094900 (BSDTCP))
security_seterror(handle=0x8052000, driver=0x28094900 (BSDTCP) error=host
h-74-0-x-28.phlapafg.covad.net: port 1026 not secure)
amandad: time 0.002: accept error: host h-74-0-x-28.phlapafg.covad.net:
port 1026 not secure
amandad: time 0.002: sending NAK pkt:
<
ERROR host h-74-0-x-28.phlapafg.covad.net: port 1026 not secure
If I'm reading this right, the client is listening via inetd, it accepts a
connection FROM the server, but it does not like that the server is
connecting to it from a port above 1024.
The check appears to be in common-src/security-util.c:
/*
* Request packets must come from a reserved port
*/
if (ntohs(rh->peer.sin_port) >= IPPORT_RESERVED) {
security_seterror(&rh->sech,
"host %s: port %d not secure", rh->hostname,
ntohs(rh->peer.sin_port));
amfree(service);
amfree(security_line);
return (-1);
}
But that doesn't tell me much about what controls what port the server
decides to bind to when contacting the client.
I saw a FAQ entry about this error when running amcheck without the suid
root bit, but this happens during amdump and amcheck. It seems fairly
random.
Any ideas?
Thanks,
Charles
Re: dead processes
Joshua Baker-LePain wrote:
On Mon, 23 Apr 2007 at 1:53pm, Don Murray wrote
Note the "selfchecks" that are running with "D" process state - meaning they
are sleeping in the kernel and are uninterruptible and therefore unkillable.
So - it looks like I need to reboot my client before I can get a backup from
it again, which is a little harsh.
I was wondering whether anyone knows why Amanda client 2.4.4 would get wedged
like that, is there something I can do to minimize the problem? Also, if
anyone has ideas about avoiding the estimate issues all together, I would
appreciate any advice.
Look in /tmp/amanda on the clients for the *debug files relating to the
hung processes. They should have more details on what went wrong. Also,
the alternate estimate methods went in before 2.5 -- I'm running 2.4.5p1
and 'man amanda.conf' says "estimate client|calcsize|server".
Joshua - thanks for the reply.
Whenever I include "estimate calcsize" or "estimate client" in my
amanda.conf I get :
"/etc/amanda/daily/amanda.conf", line 36: configuration keyword expected
"/etc/amanda/daily/amanda.conf", line 36: end of line expected
on the "estimate" line. I've tried as a general parameter and I've
tried within a particular dump type definition. Maybe I'm doing
something wrong? There doesn't appear to be an "amanda.conf" man page
installed by the RPM but I did go to
/usr/share/doc/amanda-server-2.4.4p3 and grepped for "calcsize". There
is mention of it in the "whats.new" file... says it must be installed
with setuid to root. Which I believe it is:
[EMAIL PROTECTED] amanda-server-2.4.4p3]# locate calcsize
/usr/lib/amanda/calcsize
[EMAIL PROTECTED] amanda-server-2.4.4p3]# cd /usr/lib/amanda
[EMAIL PROTECTED] amanda]# ls -l calcsize
-rwsr-x--- 1 root disk 19401 Jun 28 2004 calcsize
So the calcsize program exists but I am too daft to enable it in the
amanda.conf file. Is this incorrect - this is the kind of definition
where if I comment out the estimate line, all is good, otherwise I get a
check error.
define dumptype remote {
global
compress client fast
estimate calcsize
}
As for the selfcheck hanging up.
The log files are kept in /var/log/amanda on this system.
"selfcheck" is the process that is hung and its log isn't very helpful...
[EMAIL PROTECTED] amanda]# cat selfcheck.2007042021.debug
selfcheck: debug 1 pid 12910 ruid 33 euid 33: start at Fri Apr 20
20:00:01 2007
/usr/lib/amanda/selfcheck: version 2.4.4p3
selfcheck: time 0.000: checking disk /backedup/home
I'm also pasting below the run up in the "amandad..debug" file to
the first ERROR encountered. It all seems ok to me until it gets to the
"ERROR amandad busy".
I sure wish I didn't have to reboot to get rid of those hung processes.
Each time I try to run amcheck I get:
Amanda Backup Client Hosts Check
ERROR: NAK gilmore: amandad busy
Client check: 4 hosts checked in 10.120 seconds, 1 problem found
:(
Don
Amanda 2.4 REQ HANDLE 001-28D005F7 SEQ 1177124409
SECURITY USER amanda
SERVICE selfcheck
OPTIONS features=feff9ffe0f;maxdumps=1;hostname=gilmore;
GNUTAR /backedup/home 0 OPTIONS
|;bsd-auth;compress-fast;index;exclude-optional;
GNUTAR /backedup/project 0 OPTIONS
|;bsd-auth;compress-fast;index;exclude-optional;
GNUTAR /nonbackedup/work3/backups/vancouver 0 OPTIONS
|;bsd-auth;compress-fast;index;exclude-optional;
GNUTAR /nonbackedup/work3/backups/spruce 0 OPTIONS
|;bsd-auth;compress-fast;index;exclude-optional;
GNUTAR /nonbackedup/work3/backups/princeedward 0 OPTIONS
|;bsd-auth;compress-fast;index;exclude-optional;
GNUTAR /nonbackedup/work3/backups/nootka 0 OPTIONS
|;bsd-auth;compress-fast;index;exclude-optional;
GNUTAR /nonbackedup/work3/backups/glen 0 OPTIONS
|;bsd-auth;compress-fast;index;exclude-optional;
GNUTAR /nonbackedup/work3/backups/fs2 0 OPTIONS
|;bsd-auth;compress-fast;index;exclude-optional;
GNUTAR /nonbackedup/work3/backups/burrard 0 OPTIONS
|;bsd-auth;compress-fast;index;exclude-optional;
GNUTAR / 0 OPTIONS
|;bsd-auth;compress-fast;index;exclude-list=/tmp;exclude-optional;
amandad: time 30.047: received dup P_REQ packet, ACKing it
amandad: time 30.047: sending ack:
Amanda 2.4 ACK HANDLE 001-28D005F7 SEQ 1177124409
amandad: time 60.048: got packet:
Amanda 2.4 REQ HANDLE 001-28D005F7 SEQ 1177124409
SECURITY USER amanda
SERVICE selfcheck
OPTIONS features=feff9ffe0f;maxdumps=1;hostname=gilmore;
GNUTAR /backedup/home 0 OPTIONS
|;bsd-auth;compress-fast;index;exclude-optional;
GNUTAR /backedup/project 0 OPTIONS
|;bsd-auth;compress-fast;index;exclude-optional;
GNUTAR /nonbackedup/work3/backups/vancouver 0 OPTIONS
|;bsd-auth;compress-fast;index;exclude-optional;
GNUTAR /nonbackedup/work3/backups/spruce 0 OPTIONS
|;bsd-auth;compress-fast;index;exclude-optional;
GNUTAR /nonbackedup/work3/backups/princeedward 0 OPTIONS
|;bsd-auth;compress-fast;index;exclude-optional;
GNUTAR /nonbackedup/work3/bac
Re: Amanda Client
On Tuesday 24 April 2007, James Wilson wrote:
>The reason I use amandabackup is because that is the user I created on
>the server with the rpm packages. I have changed all the permissions on
>the files to read amandabackup disk. I also copied what you posted below
>and changed the host to amandabackup. From what you posted below the
>only_from field should that be the client name or the amanda server
>name? I can't test right because amanda is doing a backup but I will
>test as soon as the backups are done.
>
That's essentially correct I believe, but check the docs.
I think it is the expected client name, which is in this case also the server
as I've not gotten around to setting up my kubuntu box out in the shop as
another client, which in retrospect I should have. I have to reinstall that
box (it runs my milling machine via emc2) at some point as I managed to mess
up the root account on it, and when I do get it reinstalled, I will set that
box up as a second client, at which point (check the docs, Gene) I think I'll
have to make that a comma separated list of FQDN's.
As for the backup user, amanda seemed like a good name for it at the time. :)
More below.
>Gene Heskett wrote:
>> On Monday 23 April 2007, James Wilson wrote:
>>> Are you talking about the /etc/xinetd.d/amanda file? in my case it is
>>> amandabackup.
>>
>> That is not the usual name for that file. What distro are you running?
>>
>> OTOH, the actual name of that file isn't terribly important, but the
>> contents are, and should generally resemble this, although the server
>> locations could change depending on your packaging system, and of course
>> the FQDN too:
>>
>> # default = off
>> #
>> # description: Part of the Amanda server package
>> # This is the list of daemons & such it needs
>> service amanda
>> {
>> only_from = coyote.coyote.den
>> disable = no
>> socket_type = dgram
>> protocol= udp
>> wait= yes
>> user= amanda
>> group = disk
>> groups = yes
>> server = /usr/local/libexec/amandad
>> server_args = -auth=bsd amdump amindexd amidxtaped
>> }
>> service amandaidx
>> {
>> disable = no
>> socket_type = stream
>> protocol= tcp
>> wait= no
>> user= amanda
>> group = disk
>> groups = yes
>> server = /usr/local/libexec/amindexd
>> }
>> service amidxtape
>> {
>> disable = no
>> socket_type = stream
>> protocol= tcp
>> wait= no
>> user= amanda
>> group = disk
>> groups = yes
>> server = /usr/local/libexec/amidxtaped
>> }
>> ===
>> which will result in those 3 'service's being registered with xinetd for
>> ready availability in the event they are called upon. As far as xinetd is
>> concerned there is zero difference in how it works if the file was broken
>> up into 3 pieces at the service keyword, and named jimbo, bubba and
>> teri-sue, or this all in one file was named after a BC comic strip
>> character. Its what is in the file(s) that that count. :-)
I would add that the 'server' lines in each of the 3 sections above could be
different, mine is a local install as I'm nearly always running the newest
snapshot, in this case 2.5.1p3-20070420. Make sure they are the actual path
to those executeables _on your system_. This is part of amanda's security
model.
>>
>>> Pavel Pragin wrote:
James Wilson wrote:
> Hey All,
>
>I have amanda version 2.5.0p2 I have installed version 2.5.0p2-4
> for the amanda client. I have added the amanda server and the amanda
> user in the .amandahost file on the client I checked the
> /etc/services and all the amanda ports are there. But when I try to
> do an amcheck tape this is what I get. It's been awhile since I have
> added a client, am I missing something?
>
> WARNING: ifx-se-02.transolutions.net: selfcheck request failed:
> timeout waiting for ACK
> Client check: 1 host checked in 30.036 seconds, 1 problem found
Hello,
It sound like you are trying to use "bsd" authentication to connect to
a client that is using "bsdtcp". You either need to upgrade to the
2.5.1 server or change the client to run "bsd". These changes need to
be made in the xientd service for amanda.
Thank You
--
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)
It isn't necessary to have relatives in Kansas City in order to be
unhappy.
-- Groucho Marx
Re: dead processes
On Mon, 23 Apr 2007 at 1:53pm, Don Murray wrote Note the "selfchecks" that are running with "D" process state - meaning they are sleeping in the kernel and are uninterruptible and therefore unkillable. So - it looks like I need to reboot my client before I can get a backup from it again, which is a little harsh. I was wondering whether anyone knows why Amanda client 2.4.4 would get wedged like that, is there something I can do to minimize the problem? Also, if anyone has ideas about avoiding the estimate issues all together, I would appreciate any advice. Look in /tmp/amanda on the clients for the *debug files relating to the hung processes. They should have more details on what went wrong. Also, the alternate estimate methods went in before 2.5 -- I'm running 2.4.5p1 and 'man amanda.conf' says "estimate client|calcsize|server". -- Joshua Baker-LePain Department of Biomedical Engineering Duke University
Re: Amanda Client
The reason I use amandabackup is because that is the user I created on
the server with the rpm packages. I have changed all the permissions on
the files to read amandabackup disk. I also copied what you posted below
and changed the host to amandabackup. From what you posted below the
only_from field should that be the client name or the amanda server
name? I can't test right because amanda is doing a backup but I will
test as soon as the backups are done.
Gene Heskett wrote:
On Monday 23 April 2007, James Wilson wrote:
Are you talking about the /etc/xinetd.d/amanda file? in my case it is
amandabackup.
That is not the usual name for that file. What distro are you running?
OTOH, the actual name of that file isn't terribly important, but the contents
are, and should generally resemble this, although the server locations could
change depending on your packaging system, and of course the FQDN too:
# default = off
#
# description: Part of the Amanda server package
# This is the list of daemons & such it needs
service amanda
{
only_from = coyote.coyote.den
disable = no
socket_type = dgram
protocol= udp
wait= yes
user= amanda
group = disk
groups = yes
server = /usr/local/libexec/amandad
server_args = -auth=bsd amdump amindexd amidxtaped
}
service amandaidx
{
disable = no
socket_type = stream
protocol= tcp
wait= no
user= amanda
group = disk
groups = yes
server = /usr/local/libexec/amindexd
}
service amidxtape
{
disable = no
socket_type = stream
protocol= tcp
wait= no
user= amanda
group = disk
groups = yes
server = /usr/local/libexec/amidxtaped
}
===
which will result in those 3 'service's being registered with xinetd for ready
availability in the event they are called upon. As far as xinetd is
concerned there is zero difference in how it works if the file was broken up
into 3 pieces at the service keyword, and named jimbo, bubba and teri-sue, or
this all in one file was named after a BC comic strip character. Its what is
in the file(s) that that count. :-)
Pavel Pragin wrote:
James Wilson wrote:
Hey All,
I have amanda version 2.5.0p2 I have installed version 2.5.0p2-4
for the amanda client. I have added the amanda server and the amanda
user in the .amandahost file on the client I checked the
/etc/services and all the amanda ports are there. But when I try to
do an amcheck tape this is what I get. It's been awhile since I have
added a client, am I missing something?
WARNING: ifx-se-02.transolutions.net: selfcheck request failed:
timeout waiting for ACK
Client check: 1 host checked in 30.036 seconds, 1 problem found
Hello,
It sound like you are trying to use "bsd" authentication to connect to
a client that is using "bsdtcp". You either need to upgrade to the
2.5.1 server or change the client to run "bsd". These changes need to
be made in the xientd service for amanda.
Thank You
NeedHelp
Hello! I'm using Amanda software of version 2.5.1p3 under FreeBSD-4.11. Everything works fine but one thing: Amanda cannot calculate size of holding disk and tape-storage mounted via NFS. This causes failure of the dump process. The logs are showing how it goes on: - cut of amdump.1: driver: flush size 0 driver: find_diskspace: time 115.490: want 1136256 K find diskspace: not enough diskspace. Left with 1136256 K driver: find_diskspace: time 115.490: want 13504 K find diskspace: not enough diskspace. Left with 13504 K driver: state time 115.490 free kps: 3 space: 0 taper: idle idle-dumpers: 1 qlen tapeq: 0 runq: 0 roomq: 0 wakeup: 0 driver-idle: no-diskspace - amcheck command output: === backup:/usr/local/etc/amanda/Backup$ amcheck Backup Amanda Tape Server Host Check - WARNING: holding disk /mnt/hold: only 0 KB free, using nothing slot 10: read label `Thursday2', date `20070416172936' NOTE: skipping tape-writable test Tape Thursday2 label ok Server check took 0.827 seconds Amanda Backup Client Hosts Check Client check: 2 hosts checked in 1.489 seconds, 0 problems found (brought to you by Amanda 2.5.1p3) backup:/usr/local/etc/amanda/Backup$ - my network partition where the dumps must be stored: sta1:/backup 20161172 8963380 1017365247%/mnt - my exports file on NFS server (under FreeBSD too): == /backup -alldirs -network 192.168.15.0 -mask 255.255.255.252 -maproot=root Could you please help me, are there some ideas about Amanda implementation under FreeBSD in conjunction with NFS? I've tested Amanda under Linux with kernel 2.6 - backups were susccessfully done via NFS. Maybe there is a difference between implementations of RPC calls on Linux and FreeBSD-4.x? Thank you!
