|
Re: [Bacula-users] Hostname not found
2017-02-10 12:21:38
|
Hello,
I suspect that this is a problem with the FreeBSD networking
implementation. If I remember right on FreeBSD, when doing name
lookups, if the packet size is not *exactly* what FreeBSD wants,
it fails the call. On Linux and other machines (Solaris, Mac), as
long as the packet size is equal or greater than what is needed
the OS call succeeds. If I am not mistaken, Bacula allocates
space for the larger of IPv4 and IPv6 (which is always IPv6), and
so if you are using an IPv4 network, Bacula may send OS calls with
a packet size larger than actually required.
If this is the case, I would consider it a FreeBSD bug. For me to
fix it is a bit complicated, because I need to know exactly what
call is failing and the values that FreeBSD wants. By the way, it
is possible this is already fixed in the Enterprise version where
FreeBSD is supported too. If that is the case, in my next round
of backporting to start next week, it will get fixed.
Best regards,
Kern
On 02/10/2017 05:47 PM, Dan Langille wrote:
On 2017-02-10 10:02 am, Dan Langille wrote:
NOTE: this message is not about resolving
the permissions error. It is about [what appears to
be] a DNS issue.
Please help me understand which hostname is not being
resolved in these messages. My checks with dig to
verify DNS have found no errors.
I have checked:
Client: crey-fd
Read Storage:
"bacula-sd-01-file"
Write Storage: "tape01" (From Job
resource)
I've checked the bacula configuration
files, looked for the Address, and run 'dig +short' on
the hostname
Then, with the IP address from the
previous dig, I do 'dig +short -x'. I get the
original hostname.
Ideas please?
Dan, unfortunately this isn't solution to
your problem, but I can say, your not alone I have had
periodic issues with Bacula failing to resolve host
names on FreeBSD. I just gave up and went to IP
Addresses. When it occurs it has only been the Bacula
process. I have tried testing every which way I can from
the OS and always received successful resolution of
names. I have had it do it after running fine for
several days, then without a reboot, service restart or
anything just start failing to resolve. Rebooting server
sometimes would fix it, but sometimes it wouldn't, even
removed Bacula and reinstalled once without it fixing
the problem.
I just upgraded my home Bacula server to
7.4.5 this morning and after seeing this, tried
switching one of my clients over to name instead of of
IP and it did resolve ok and check status of that
client. Then checked with my storage daemon switched to
name as well. So it doesn't seem to be the latest update
that broke your system, perhaps you found that same bug
I have periodically ran into, but not found a solution
to yet.
On the server in question, are you using unbound? I've found
that the SD in question is using unbound, running FreeBSD 11,
and there is a DNS issue on that host.
--
Dan Langille - BSDCan / PGCon
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users
|
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users
|
|
|
