On Sat, 2009-12-05 at 14:20 -0500, Dan Langille wrote:
> Craig White wrote:
> > On Sat, 2009-12-05 at 13:41 -0500, John Drescher wrote:
> >>> OK - I replaced the 127.0.0.1 references (only in bacula-dir.conf) with
> >>> the fully qualified domain name that does resolve on both client and
> >>> server, restarted the bacula-dir daemon but that doesn't change the
> >>> problem... in fact, that is where I started but I went to the 127.0.0.1
> >>> out of frustration.
> >>>
> >> Can you explain further where the problem exists. Parts of logs or
> >> error messages would be very helpful.
> > ----
> > via telnet from server to client...
> >
> > # telnet 192.168.1.18 9102
> > Trying 192.168.1.18...
> > Connected to 192.168.1.18 (192.168.1.18).
> > Escape character is '^]'.
> > QUIT
> >
> > but it will never QUIT or disconnect. It doesn't seem to 'time out' and
> > I can only get it to quit either by killing the process on the server or
> > by restarting the client or at least stopping the FD on the client.
> >
> > from bconsole...
> > *status client=ja
> > Connecting to Client ja at 192.168.1.18:9102
> > Failed to connect to Client ja.
> > ====
> > You have messages.
> > *
> > 05-Dec 10:29 SRV1-dir JobId 0: Fatal error: Unable to authenticate with
> > File daemon at "192.168.1.18:9102". Possible causes:
> > Passwords or names not the same or
> > Maximum Concurrent Jobs exceeded on the FD or
> > FD networking messed up (restart daemon).
> > Please see
> > http://www.bacula.org/en/rel-manual/Bacula_Freque_Asked_Questi.html#SECTION003760000000000000000
> > for help.
> >
> > - I've studied that link up and down and tried everything
> > - The 'Names' are the same
> > - The Passwords are the same
> > - The Maximum Concurrent Jobs on the FD is set to 20
> > - I've restarted the FD... the computer itself many times.
> >
> > Quite honestly, I don't believe that the 'Unable to authenticate with
> > File Daemon at...' message is accurately reflecting what is going on.
>
> People often think that. It has yet to be proven correct.
>
> Make no assumptions. Check every point. Do not rely on your memory.
>
> Verify you are using the correct IP address. Is 192.168.1.18 correct?
>
> ifconfig helps
>
> Verify that the bacula-fd IS indeed running.
>
> $ ps auwx | grep bacula
> root 1515 0.0 0.9 11712 4532 ?? Ss Fri04AM 0:00.38
> /usr/local/sbin/bacula-fd -u root -g wheel -v -c /usr/local/etc/bac
> dan 19235 0.0 0.2 3496 1020 2 S+ 7:16PM 0:00.01 grep bacula
>
>
> Is it attaching to 192.168.1.18?
>
> $ netstat -na | grep 9102
> tcp4 0 0 *.9102 *.* LISTEN
>
>
> On the bacula server, connect to the bacula client.
>
> $ telnet 10.66.0.1 9102
> Trying 10.66.0.1...
> Connected to bast.wifi.unixathome.org.
> Escape character is '^]'.
> lkajfd
> Connection closed by foreign host.
>
>
> NOTE the closure. If you're not getting that, are you connecting to the
> right place?
>
> Similarly, on the bacula client, telnet to the bacula server:
>
> $ telnet 10.66.0.1 9102
> Trying 10.66.0.1...
> Connected to bast.wifi.unixathome.org.
> Escape character is '^]'.
> lkajfd
> Connection closed by foreign host.
> $
>
> AGAIN, note the closure when you type random text.
>
> Mind you, I'm running TLS, but may not matter.
>
> If the above does not work, you have a problem elsewhere.
>
> Firewalls? Switches? Different networks?
----
none of this was all that useful since I've already excluded the issues
that you are speaking about but I am sort of thinking that the build on
the Macintosh is bad and perhaps someone can help me there.
To build on the Macintosh requires one to install debian's fakeroot
package. According to the readme included with fakeroot...
SysV IPC is the default; to build for TCP, run configure with
--with-ipc=tcp (case-sensitive).
Platform-specific notes:
FreeBSD:
To compile --with-ipc=tcp and gcc, make sure the -pthread flag
is used.
So I did ./configure --with-ipc=tcp CFLAGS=-pthread
(first time, I did only --with-ipc=tcp)
but when I was building the actual packages with 'make -C
platforms/osx', it couldn't find the expected library
(/usr/local/lib/libfakeroot.so) because in /usr/local/lib ...
# ls -l /usr/local/lib
total 176
-rwxr-xr-x 1 root wheel 37064 Dec 5 12:32 libfakeroot-0.dylib
-rw-r--r-- 1 root wheel 40008 Dec 5 12:32 libfakeroot.a
lrwxr-xr-x 1 root wheel 19 Dec 5 12:32 libfakeroot.dylib ->
libfakeroot-0.dylib
-rwxr-xr-x 1 root wheel 1008 Dec 5 12:32 libfakeroot.la
so to get bacula to build the packages, I created a symlink for
libfakeroot.so from libfakeroot-0.dylib
How does one get 'fakeroot' to build the so files?
Craig
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users
|
