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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users