Re: hostname lookup failed?
On Fri, Apr 27, 2001 at 02:15:47PM -0500, John R. Jackson wrote: I think this is saying that on host samba2 it could not take IP address 10.0.1.2 and convert that back to a host name. That IP address should be the IP address of the machine that connected to samba2, i.e. your tape server (where you ran amcheck). So, go to samba2 and see if you can do a lookup of 10.0.1.2 and get back the right answer. Ah ha! I thought I had copied the hosts file over... guess I was wrong. Works fine now. Also, does that error have anything to do with this: NOTE: info dir /var/log/amanda/DailySet1/curinfo/samba2: does not exist NOTE: index dir /var/log/amanda/DailySet1/index/samba2: does not exist Those are just telling you you haven't done any backups of samba2 yet so those areas (directories) don't exist. They will be created on the first good run. Yeah, I figured that, but I thought I'd explore all avenues. Thomas J. Hudak John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED] Thanks, -- Thomas J. Hudak Systems Administrator Sistina Software Inc. - www.sistina.com Phone: 612.379.3951 Page: 612.318.1967 Fax: 612.379.3952 Key fingerprint = BEC6 3181 4C9B A7BB AF11 4717 6F85 B346 380D 523E PGP signature
firewalls??
Ok, I've posted to the group 2 times and no-one seems to have setup a working config through a firewall or can only guess as to how it *should* be, I have come to the conclusion that amcheck transmits it's data over ports *outside* of my specified range due to the fact that I can use nc to listen on either end on every port I've specified and they communicate directly yet amcheck still reports that the 6 port is unsecure. Something from amcheck is being masqueraded, I'm not sure exactly how to continue other than logging all netstat or tcpdump data and scouring it form data about amcheck... There must be an easier way to break through my firewall than this. If you have any suggestions please send them my way, I do not want to re-arrange the web/mail server setup to accomodate my backup scheme. My configuration schemes are listed in my last post, and due to mail havoc things aren't functioning quite as smoothly as and mail isn't being sorted properly yet, so excuse me if I'm repeating myself as I may not have yet seen replies. Thanks a lot, -- Thomas J. Hudak Jr. Systems Administrator Sistina Software Inc. Phone: 612.379.3951 Fax: 612.379.3952 PGP signature
amcheck and ports?
After much brain storming and headaches, I have come to 1 conclusion, amcheck is opening and transferring data on a (range) port(s) that are separate from what I have specified during configure. This occured to me after studying my known goods, port-port links are all ok, tested both directions with netcat (still not sure how masq does its masquerading...), verified perms on all affected binaries (amandad, amcheck) but only after running tcpdump | grep -e ".*amanda.*" was I able to know for a fact amcheck DOES NOT exclusively use the assigned port ranges! That is what is mucking up the process of amcheck successfully checking the remote hosts through a masquerading firewall. The output I received from tcpdump | grep -e ".*amanda.*" is below. tcpdump: listening on eth0 15:40:32.168288 fry.sistina.com.64280 bender.sistina.com.amanda: udp 176 15:40:32.175191 bender.sistina.com.amanda fry.sistina.com.64280: udp 49 15:40:32.177088 bender.sistina.com.amanda fry.sistina.com.64280: udp 101 15:40:32.208256 fry.sistina.com.64280 bender.sistina.com.amanda: udp 49 the only port above that *should*(?) be used by amcheck is the hostname service (port 101), which is the one port that I would assume is necessary to the function of amcheck and it's security measures, but in turn screws the ability to function via a masqueraded firewall without the proper rules. The others seem to be opened intentionally (as opposed to randomly) but do not follow the udp port restrictions I specified at compile time. Is this a bug? is this a feature? is this functionality simply unintentional? Whatever the reason, those ports are what cause the otherwise properly forwarded communications pathways to get hosed while running amcheck. If anyone has a fix/patch/update/suggestion/whatever for how to force amcheck to strictly use the specified udpportrange I would love to know. I am not a programmer or I would start digging through source to find the answers I need. Also, if someone could clear up the tcpdump output as I'm not fully sure that I understand *exactly* what each line means, but vaguely I understand that data from homer (behind the masq/firewall), since there is no input policy or forwarded port, is masquerading the data to bender, which intern see's it as an insecure port (due to masq) and responds appropriately. Again, this is all just an educated guess with some logged info to give me a known good. If anyone can clear up what amcheck is doing on those ports, or why, please let the list know. I have been searching through the mailing list archives for both users and hackers, and this has apparently been an issue for a while with no resolution currently available. *note: tcpdump results are the same ports EVERY time I've run it and I have not yet gotten any of the ipchains/ipmasqadm portfw rules to successfully avoid masqerading that data. Thanks ahead of time for any answers/suggestions given, this has been an issue for a while that I'm sure many people would love to see resolved. I hope this helps a little bit. -- Thomas J. Hudak Jr. Systems Administrator Sistina Software Inc. Phone: 612.379.3951 Fax: 612.379.3952 PGP signature
firewall config and netcat works... why dosn't amcheck?
Ok, using netcat I have determined that direct port-port communications exist for all specified portranges as well as 10080 via udp as configured for amandad. using the commands: homer: nc -l -p 10080 bender: nc -p 10080 -v homer.sistina.com 10080 - cmd-in-nc amanda to which homer's nc session prints amanda this works both ways on ALL configured port ranges (11080-11084-tcp / 850-854-udp) Here is my ipchains/ipmasqadm portfw rule set. /sbin/ipchains -A input -p udp -s $HOMER 10080 -d $BENDER 10080 -j ACCEPT /usr/sbin/ipmasqadm portfw -a -P udp -L $FRY 10080 -R $HOMER 10080 /sbin/ipchains -A output -p udp -s $FRY 10080 -d $HOMER 10080 -j ACCEPT /sbin/ipchains -A output -p tcp --sport 11080:11084 --dport 11080:11084 -s $FRY -d $HOMER -j ACCEPT /usr/sbin/ipmasqadm portfw -a -P tcp -L $FRY 11080 -R $HOMER 11080 /usr/sbin/ipmasqadm portfw -a -P tcp -L $FRY 11081 -R $HOMER 11081 /usr/sbin/ipmasqadm portfw -a -P tcp -L $FRY 11082 -R $HOMER 11082 /usr/sbin/ipmasqadm portfw -a -P tcp -L $FRY 11083 -R $HOMER 11083 /usr/sbin/ipmasqadm portfw -a -P tcp -L $FRY 11084 -R $HOMER 11084 ## UDP forwarding from homer to bender /sbin/ipchains -A output -p udp --sport 850:854 --dport 850:854 -s $FRY -d $HOMER -j ACCEPT /usr/sbin/ipmasqadm portfw -a -P udp -L $FRY 850 -R $HOMER 850 /usr/sbin/ipmasqadm portfw -a -P udp -L $FRY 851 -R $HOMER 851 /usr/sbin/ipmasqadm portfw -a -P udp -L $FRY 852 -R $HOMER 852 /usr/sbin/ipmasqadm portfw -a -P udp -L $FRY 853 -R $HOMER 853 /usr/sbin/ipmasqadm portfw -a -P udp -L $FRY 854 -R $HOMER 854 What other ports if any should/need to be forwarded or allowed through in order to get amcheck to complete successfully, as I am still getting this error.? ERROR: bender: [host fry.sistina.com: port 64865 not secure] Could it have something to do with the placement of the rules (probably a question for the author of ipchains)? or possibly that even though the rules are set and the routes work, everything is still being masqueraded? Is there a way to force no masquerading for a port or range of ports? I know these are not questions specific to amanda itself, but this is the only issue I have yet to deal with before a successful 2.4.2 config for ALL my boxen. Has anyone else backed up boxen OUTSIDE of their internal lan through an ipchains/other based firewall? Any light that could be shed on this problem is that much more helpfull. Thanks ahead of time for any responses. -- Thomas J. Hudak Jr. Systems Administrator Sistina Software Inc. Phone: 612.379.3951 Fax: 612.379.3952 PGP signature
Re: Selfcheck timeout
I was just checking over the strace's for amcheck and planner, and noticed, that amcheck makes a chdir call to change workin dir to /etc/amanda/DailySet1 when trying to open the amanda.conf file. Planner on the other hand makes no such call, and therefore lacks the ability to see "amanda.conf" which is the only thing it tries to open. If I could find out what variable is being set or how this working dir is called I think I'll be ok, but it seems to me that a standalone program like planner would have the ability to know *WHERE* it's config files are, and if not, have a command line option to point at it. Not just simply fail and dump to prompt. I'm thinking about manually editing the planner.c to point specifically to /etc/amanda/amanda.conf but I don't particularly *want* to do that nor do I have the time, nor am I a programmer. If someone has a solution for this, you would be making my life MUCH easier. Thanks, Tom Hudak On Mon, Nov 13, 2000 at 11:03:41AM -0600, Tom Hudak wrote: Does anyone else have problem with planner not reading the config file? I can see in the planner output that it's looking in /etc/amanda which is 664 and has a copy of amanda.conf as well as /etc/amanda/DailySet1 which is where I'm assuming it's looking. Planner should be able to read and execute fine, it's +s and I'm running it as the backup user. --help and -h give me no info, and there's no manpage to read about, so I'm stuck guessing whats causing this. Any help would be greatly appreciated. Thanks, Tom Hudak PGP signature
planner
Ok, once again my fault... planner is opening "amanda.conf" which it cannot see when being run from the dir it's in. I didn't figure this out til I ran the strace's on amcheck AND planner and looked at how it accessed the config file. I now will run planner from within the /etc/amanda/DailySet1 dir to test any probs and if anyone else has this happen, make a note to run planner from the config file's dir. Sorry if anyone was annoyed by the flurry of postings from me, but I was in a hurry and posted BEFORE I really had time to research the problem. Thanks again to all those that responded with advice. Thanks, Tom Hudak PGP signature
Re: planner
Well, to be honest, it was pissing me off. I had no way to verify what problems were caused by a timeout, no authorization, improper setup, but what was happening was (I found this out by running planner by hand) that planner itself was getting this error, "Connection packet receive: connection timed out" or something very similar (I wiped the log.) but it was showing up in the amdump reports as "RESULTS MISSING" on ALL drives, as well as a quickie at the end stating that it got an "empty schedule from planner." Well, talk about no mention of either problem in the FAQ! or at least not the problem that I was having. The "RESULTS MISSING" on my systems has NOTHING to do with the size of the UDP packet being transfered, but the fact that planner would not even run (and exit with 0). I have since gotten planner to run on it's own via amdump, as well as command line, and have stopped receiving those errors. I'm not sure why it was having trouble indexing the drives, but it seems to *not* have that trouble any more. Neither the sendsize.debug nor the amandad.debug report any problem or error's with the run, all I ever see is amandad: got ack: and some other versioning/debugging output, none of which states anything about any problems. I'm sorry if the info I'm giving you isn't much, but there's not much to be found. amdump's mail's give a vague description of a problem and there isn't much of a way to cross-reference that except the monthly archives/FAQ-o-Matic for which you have to determine the problem and the resolution to be any good. (hence defeating the purpose of the faq, to answer your unanswered question, maybe using the faq-o-matic could be used in determining what problems are, but as a reference for vague errors that could potentially be caused by many things, it just isn't enough.) Now that planner is indexing drives, things seem to be running A LOT smoother, such as amdump running all the way through, planner index's, taper records, etc. Thanks for the fast action on the mailing list, you've made one (I'm sure many more.) admin happy. Next task, punch a hole in the firewall for the web/ftp and I'll be golden. Thanks again, Tom Hudak On Mon, Nov 13, 2000 at 02:49:47PM -0500, John R. Jackson wrote: Dare I ask **why** you're trying to run planner by hand? I noticed the Subject on the previous E-mail was "Selfcheck timeout". Do I infer from that that one (or more) clients are having this issue? Since you're not getting a "connection refused" type error, I'm guessing amandad/sendsize are getting started on the client, but it would be useful to see that output (/tmp/amanda/amandad*debug and sendsize*debug). One possibility is that it is taking a long time to gather the estimate (for some reason) and that Amanda is getting tired of waiting. The etimeout configuration parameter controls that, or it might be something wrong with the client (or dump program) itself. Tom Hudak John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED] PGP signature
RESULTS MISSING
I have just ironed out my config, setup my clients and gotten amcheck to run
without problems, after setting the "record no" global option, running amdump
spits out this:
FAILURE AND STRANGE DUMP SUMMARY:
smb/home RESULTS MISSING
smb/var/data/kalisa RESULTS MISSING
homer /dev/hda1 RESULTS MISSING
homer /dev/md0 RESULTS MISSING
STATISTICS:
Total Full Daily
Dump Time (hrs:min)0:00 0:00 0:00 (0:00 start, 0:00
idle)
Output Size (meg) 0.00.00.0
Original Size (meg) 0.00.00.0
Avg Compressed Size (%) -- -- --
Tape Used (%) 0.00.00.0
Filesystems Dumped0 0 0
Avg Dump Rate (k/s) -- -- --
Avg Tp Write Rate (k/s) -- -- --
^L
NOTES:
driver: WARNING: got empty schedule from planner
taper: tape Daily-05 kb 0 fm 0 [OK]
^L
DUMP SUMMARY:
DUMPER STATS TAPER
STATS
HOSTNAME DISK L ORIG-KB OUT-KB COMP% MMM:SS KB/s MMM:SS KB/s
homer /dev/hda1 MISSING
homer /dev/md0 MISSING
smb /home MISSING
smb -r/data/kalisaMISSING
(brought to you by Amanda version 2.4.1p1)
My question relates to the line's containing RESULTS MISSING (although I'm not
sure how the -r got in there, the disklist contains the full path: "smb --
-r/data/kalisa --". I
have checked the amdump.debug, selfcheck.debug and looked for other .debug files but
found
none on both the server and the client. Neither the client or host .debug
files contain anything about error's or problems, yet the error continues.
What causes this? am I not looking at the right debug files? I have found MANY
submissions like this to the hackers list, none of them seem to fit my current
setup. This is a brand spankin' new config and I *believe* it's correct. Any
info would be MUCH appreciated.
PGP signature
Re: RESULTS MISSING
On Thu, Nov 09, 2000 at 06:26:54AM -0600, Tom Hudak wrote:
I have a modification, it turns out the dumpers program was not u+x, so it
choked, now I'm getting "request to HOST timed out." I do not see a resolution
before leaving work tonight being reasonable, but If I should get any more
info in the next day or so, I'll repost.
I have just ironed out my config, setup my clients and gotten amcheck to run
without problems, after setting the "record no" global option, running amdump
spits out this:
FAILURE AND STRANGE DUMP SUMMARY:
smb/home RESULTS MISSING
smb/var/data/kalisa RESULTS MISSING
homer /dev/hda1 RESULTS MISSING
homer /dev/md0 RESULTS MISSING
STATISTICS:
Total Full Daily
Dump Time (hrs:min)0:00 0:00 0:00 (0:00 start, 0:00
idle)
Output Size (meg) 0.00.00.0
Original Size (meg) 0.00.00.0
Avg Compressed Size (%) -- -- --
Tape Used (%) 0.00.00.0
Filesystems Dumped0 0 0
Avg Dump Rate (k/s) -- -- --
Avg Tp Write Rate (k/s) -- -- --
^L
NOTES:
driver: WARNING: got empty schedule from planner
taper: tape Daily-05 kb 0 fm 0 [OK]
^L
DUMP SUMMARY:
DUMPER STATS TAPER
STATS
HOSTNAME DISK L ORIG-KB OUT-KB COMP% MMM:SS KB/s MMM:SS KB/s
homer /dev/hda1 MISSING
homer /dev/md0 MISSING
smb /home MISSING
smb -r/data/kalisaMISSING
(brought to you by Amanda version 2.4.1p1)
My question relates to the line's containing RESULTS MISSING (although I'm not
sure how the -r got in there, the disklist contains the full path: "smb --
-r/data/kalisa --". I
have checked the amdump.debug, selfcheck.debug and looked for other .debug files but
found
none on both the server and the client. Neither the client or host .debug
files contain anything about error's or problems, yet the error continues.
What causes this? am I not looking at the right debug files? I have found MANY
submissions like this to the hackers list, none of them seem to fit my current
setup. This is a brand spankin' new config and I *believe* it's correct. Any
info would be MUCH appreciated.
PGP signature
