Put this in a FAQ somewhere!
It already is. In:
http://amanda.sourceforge.net/fom-serve/cache/140.html
it says:
If you are using a fire wall or TCP wrappers, make sure it is set up
to allow the amanda service in to the client from the server.
Since all modern Unix use a TCP
Put this in a FAQ somewhere!
It already is. In:
http://amanda.sourceforge.net/fom-serve/cache/140.html
it says:
If you are using a fire wall or TCP wrappers, make sure it is set up
to allow the amanda service in to the client from the server.
-doug
John R. Jackson, Technical Software
Hang on a moment here. What we should be thinking is that someone
thinks there should be a cross reference to this question in the
FAQ We all categorise things differently to each other so what
might seem like a sensible place for a question to you, may not be
sensible to the next person...
FAQ We all categorise things differently to each other so what
might seem like a sensible place for a question to you, may not be
sensible to the next person...
Well the web should be a very flexible tool for offering multiple
indexation of a FAQ. Or have a search on contents tool :)
If the guilty party of this thread can put forth another $.1, I just
wanted to point out my frustration in trying to determine why amanda was
having this problem with inetd. I had honestly forgotten about the tcp
wrapper part, and it didn't occur to me how inetd/amanda would react if
there
having this problem with inetd. I had honestly forgotten about the tcp
wrapper part, and it didn't occur to me how inetd/amanda would react if
there wasn't an entry in the hosts.allow file. Considering that amandad
Doug,
There is no reason to blame yourself on that. Systematic use of TCP
Ok, now I'm stumped. I have two FBSD 4.3 machines, one inside and one
outside a firewall. I compiled amanda2.4.2p2 on the internal machine and
it checks out fine. So, I tarred up libexec, lib/liba*, and sbin/am*, put
it on the external machine, HUP'd inetd and poof, it still doesn't
work.
Ok, this was a weird one. It turned out to be due to tcpwrappers. I just
saw a recent post suggesting it. It's odd that inetd closed the port, but
I would guess that that might be caused because the protocol is udp
instead of tcp?
Put this in a FAQ somewhere!
-doug
On Thu, 7 Jun 2001, Doug
This is when I manually ran it.
# cat amandad.out.63688
Sat Jun 2 10:20:24 PDT 2001: starting amandad
Sat Jun 2 10:20:54 PDT 2001: amandad done: status is 1
more /tmp/amanda/amandad.xxx.debug
amandad: debug 1 pid 63690 ruid 0 euid 0 start time Sat Jun 2 10:20:24
2001
[compile info - snip]
I had a similar problem with amanda 2.4.1p2 on Solaris 8 client (no
auditing..).
After much of the same kinds of debugging techniques (this list is
great!) I discovered that the client side amandad was dying due to
inability to find a shared library. The problem only showed up when
amandad
print: not found
Change print to echo in the script.
-doug
John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
I have a new FBSD 4.3 box and I installed the amanda 2.4.2p2 client with
the same parameters as my other FBSD 4.2 clients:
./configure --with-gtar=/usr/local/bin/gtar --without-server
--with-portrange=900,950 --with-udpportrange=900,950 --with-user=root
--with-group=wheel --with-amandahosts
Done. The script still doesn't execute, inetd just terminates the
service. Here's what tcpdump shows:
# tcpdump udp
tcpdump: listening on fxp0
17:10:40.132018 amanda-server.930 client.amanda: udp 214
17:10:49.591485 amanda-server.930 client.amanda: udp 214
Nothing in /tmp. Very strange,
Done. The script still doesn't execute ...
Doesn't execute at all???
Is anything logged to /var/adm/messages (or wherever inetd puts
stuff)?
What happens if you run the script as your Amanda user (root?). It should
sit for 30 seconds and then terminate, and you should get the script
output
14 matches
Mail list logo
