From: <bac...@li...> - 2008-01-25 09:55:01
|
The following issue has been UPDATED. ====================================================================== http://bugs.bacula.org/view.php?id=1029 ====================================================================== Reported By: minkus Assigned To: ====================================================================== Project: bacula Issue ID: 1029 Category: other Reproducibility: always Severity: tweak Priority: normal Status: feedback ====================================================================== Date Submitted: 12-31-2007 14:30 UTC Last Modified: 01-25-2008 09:54 UTC ====================================================================== Summary: IP Address Resolution Priorities Description: When a host has both an A and an AAAA record it seems that Bacula prefers the A record. Since most people who run IPv6 are still running it in dual-stack environments most hosts will have both records. It is common practice for clients to favor AAAA records in order to facilitate the eventual switchover. Second, when a host has both types of records (A and AAAA) and the Bacula daemons are only listening on IPv6, Bacula does not try to fail over to the other address. I tried to force Bacula to use IPv6 by forcing the FD to listen on IPv6 but the director will try to use the A record and never even attempt to contact the FD over IPv6. Most clients attempt the preferred record and then fall back to the non-preferred record in the event of error. Both of these are, in my opinion, minor tweaks that would help to facilitate IPv6 adoption as more people contemplate using Bacula in IPv6 environments. ====================================================================== ---------------------------------------------------------------------- Dan Langille - 12-31-07 14:52 ---------------------------------------------------------------------- See http://marc.info/?l=bacula-users&m=119881409808418&w=2 for post on bacula-users ---------------------------------------------------------------------- kern - 01-16-08 21:31 ---------------------------------------------------------------------- This sounds more like a Feature Request than a real bug, since once you supply an address or addresses for Bacula to listen on, it gives up if any fail. Some time ago this was discussed, and if I remember right most all users preferred it this way. In addition, I know nothing about IPv6, don't have it running here, and don't know how to get it running, so: Do you know anyone who can supply a patch for this? If not, I fear that this is not something that will be resolved in the near future. ---------------------------------------------------------------------- minkus - 01-17-08 23:00 ---------------------------------------------------------------------- Binding to an address is not a problem. Bacula will bind to an IPv6 address or an IPv4 address - or both. It should try to bind to all addresses that it is given. I agree, that if one of those addresses fails to bind then it should be treated as an error. The problem is not with binding but when resolving a remote host. I have a host with the following records: test.mydomain.com A 10.20.30.40 test.mydomain.com AAAA 2001::1 If I point a user agent to test.mydomain.com, most user agents such as a web browser or mail client will first try to contact the host using the AAAA record and if that fails then it will try to contact the host using the A record. In this manner it tries all protocols until one of them works. This aides during the v4 to v6 transition because not all hosts will necessarily be able to contact every other host via v4 or v6 only. Almost all admins that make use of v6 are running in a dual stack environment since there are some services (such as the public Internet) that just do not work over v6. In my setup, I have several LANs where all of the hosts run dual stack both v4 and v6. These LANs are connected over a v4-only backbone. I have both AAAA and A records for each host since each host has both types of addresses. Hosts in different LANs are not able to communicate with each other over v6 even though they can communicate with hosts in the same LAN over v6. I want all services to use IPv6 if possible, that way I can make sure that my network and all of its services work correctly over v6. Using my example above, Bacula will currently always try to connect to test.mydomain.com using the A record. Since v6 is the newer protocol and v4 will eventually be phased out, it is generally accepted practice to prefer AAAA records. That is test.mydomain.com will resolve to 2001::1 rather than 10.20.30.40. If test.mydomain.com only had an AAAA record then currently Bacula would resolve correctly to the AAAA record. Semantically it is just a matter of preferring the AAAA record over the A record when both exist. As mentioned above, most user agents will attempt to contact a host using the AAAA record and fall back to the A record if the attempt over v6 fails. I know that I am at the forefront of IPv6 adoption. I know that this isn't high on your list of priorities and that is fine with me. I wasn't necessarily looking for this to be changed immediately. More than anything, I wanted you to be aware of these catches now so that they can be resolved before v6 becomes more popular in the next few years. I am not the only person to have mentioned this in the past: http://sourceforge.net/mailarchive/forum.php?thread_name=1B2DF9CE-5DAA-4C5F-9468-7648B633286A%40bodgit-n-scarper.com&forum_name=bacula-users If I had the coding skills to provide a patch I would. But my coding skills are a bit rusty. I may be able to help you out with ipv6 since I have been working on implementing v6 over the last year or so. ---------------------------------------------------------------------- kern - 01-25-08 09:54 ---------------------------------------------------------------------- I've briefly looked at the code, and as far as I can tell, Bacula should try to connect to each IP address obtained until it finds one that works. If an IP address fails to connect, Bacula will just go on to the next one. Perhaps you could run one of your daemons with -d 100 in a case where you experience a failure and post the output to this bug report. That might give me a better idea of what is going wrong. If you can test and help diagnose the problem, I can do the programming part ... Issue History Date Modified Username Field Change ====================================================================== 12-31-07 14:30 minkus New Issue 12-31-07 14:52 Dan Langille Note Added: 0003039 01-16-08 21:31 kern Note Added: 0003074 01-16-08 21:31 kern Status new => feedback 01-17-08 22:35 minkus Note Added: 0003083 01-17-08 23:00 minkus Note Edited: 0003083 01-25-08 09:54 kern Note Added: 0003096 ====================================================================== |