On Sat, 2009-12-05 at 13:24 -0500, John Drescher wrote:
> > I've been all through the documentation and I was sure I set up things
> > correctly.
> >
> > Server is CentOS-5 built 3.0.3
> > Client is Macintosh built 3.0.3
> >
> > Server can telnet to client port 9102
> > Client can telnet to server port 9103
> >
> > Server can back itself up and passes tests including autochanger.
> >
> > I know firewalls are not the issue and that the client fd is running and
> > if I stop the client-fd, I cannot telnet to the client on port 9102
> >
> > Because I read that the storage daemon must be resolvable by the client,
> > I am using an fqdn that is internally resolvable by both server and
> > client from intranet dns server (represented as FQDN)
> >
> > Director calls itself...
> > Director {
> >  Name = SRV1-dir
> >  DIRport = 9101
> >  QueryFile = "/etc/bacula/query.sql"
> >  WorkingDirectory = "/var/lib/bacula"
> >  PidDirectory = "/var/run"
> >  SubSysDirectory = "/var/lock/subsys"
> >  Maximum Concurrent Jobs = 1
> >  Password = "password"
> >  Messages = Standard
> > }
> >
> > Director says about client...
> > Client {
> >  Name = ja
> >  Address = 192.168.1.18
> >  FDPort = 9102
> >  Catalog = MyCatalog
> >  Password = "password"
> >  File Retention = 75d
> >  Job Retention = 75d
> >  AutoPrune = yes
> > }
> >
> > Director says about storage...
> > Storage {
> >  Name = FQDN-sd
> >  Address = 127.0.0.1
> >  SDPort = 9103
> >  Password = "password"
> >  Device = LTO-4
> >  Media Type = LTO-4
> > }
> >
> You should not have 127.0.0.1 in any bacula configuration file unless
> you are using ssh tunnels .
----
sorry about the private reply, I see now that another reply made it to
the list...

that's where I started, with the FQDN of the server and so I set it back
in both places it was used, restarted the bacula-dir daemon and still,
the problem.

The director (on the server) can connect to the 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 '^]'.

and the client can connect to the storage daemon on the server...
# telnet 192.168.1.6 9103
Trying 192.168.1.6...
Connected to FQDN.
Escape character is '^]'.

and the client can connect to the director on the server...
 telnet 192.168.1.6 9101
Trying 192.168.1.6...
Connected to FQDN.
Escape character is '^]'.

and ALL of the passwords are the same so I am sure that that isn't the
issue.

There is one difference that is probably significant.

>>From the client, if I telnet to the director (port 9101) or to the
storage daemon (9103) and I type 'QUIT' it actually quits.

>>From the server, if I telnet to the client (port 9102), I can type QUIT
but it doesn't disconnect so I am thinking that the client is
misbehaving but nothing is getting logged in system logs on the client
and I don't have any notion of debugging this.

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