[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bacula-devel] StorageDaemon: Job name not found


Hi,

thanks for the answer. I will have a look into the tunneling-part of
the really big documentation. And I also will try to run all services
(FD, SD, director) in debug-mode to see what happens where.
BTW: in the tunneling-part are two servers: client (with FD) and
server (with SD and director) - if I do this so I can backup a client
also over a ssh-connection. If I have tree servers (client, director,
storage) I can't do this over ssh. But I can backup a client with
three servers if all servers are in the same network.
Anyway. I will try it again with higher debug-level and report here -
if you want to know about the result.

Best regards,
Thomas
---
> On Monday 31 March 2008 11:33:29 Pierce wrote:
>> Hi,
>>
>> it's true, I asked this question in bacula-users list. There I get no
>> answer. I also program (java, no C) and thats why I think the question
>> should be better here. The reason is:
>> I read some days all manuals and todos I found. I tried a lot of
>> things. But everytime I get an error from the FD: authorization
>> failed - I should compare my passwords and so on. But this can't be
>> the reason.
>>
>> BTW: to now I didn't find any manual where the director and the storage
>> daemon are not on the same machine AND where a ssh-connection is used.
>>
>> My main problem is not to crypt the connection between FD and SD. My
>> main problem is, that the SD is behind a NAT-firewall and the FD can't
>> connect to the SD directly. That's why I created a ssh-tunnel.
>>
>> Anyway. The FD says: authorization failed. But the SD says: job name
>> not found. I trust the SD.

> They are most likely both correct.  The FD was asking the SD to be 
> authenticated, and that failed.  It failed in the SD because the Director had
> not previously contacted the SD to "start" the job (or at least something
> went wrong with that -- turning on debug or a higher level in the SD would
> probably give you more info).

> Your Director is probably talking to the wrong SD -- or the FD is talking to
> the wrong SD.  In any case, most likely the DIR and the FD are talking to
> different SDs.  Make sure only one exists on all your system, and you will
> probably nail the problem.

>>
>> But: who tells the SD about the jobname? 

> The Director before it contacts the FD.

>> I thinks this point can 
>> explain a programmer only who knows the internal communication.

> Well, it is documented somewhere in the *big* manual -- probably in the
> Tunneling chapter.


> Best regards,

> Kern

>>
>> Best regards,
>> Thomas
>> ---
>>
>> > Have you asked this question on the bacula-users list?  That is where you
>> > will get the best support of this kind.  See www.bacula.org -> Support.
>> >
>> > I am not at all an expert on these subjects (I program and don't have TLS
>> > here), but my best guess is that you haven't set up all the tunnels that
>> > are necessary.  Please see the manual on how to do it, or use Bacula
>> > built-in TLS, which is much simpler.
>> >
>> > Best regards,
>> >
>> > Kern
>> >
>> > On Monday 31 March 2008 10:18:18 Thomas Rotter wrote:
>> >> Hello,
>> >>
>> >> I've got 3 Hosts:
>> >> evo_www (IP 1.2.3.4) with a FD
>> >> OBC (IP 192.168.100.160) with the Director (and a test-SD)
>> >> OBC2 (IP 192.168.100.161) with a SD
>> >>
>> >> If I start a job for backup evo_www on OBC2 I get an error.
>> >>
>> >> Before that I create a ssh-tunnel like this:
>> >> /usr/bin/ssh -fnCN2 -o PreferredAuthentications=publickey -i
>> >> /etc/bacula/ssh/bacula -l root -R 9101:192.168.100.160:9101 -R
>> >> 9103:192.168.100.161:9103 evo_www
>> >>
>> >> The tunnel is ok because if I start the OBC2-SD in debug-mode I get
>> >> output if I started the job:
>> >> obc2-sd: bnet.c:1154 who=client host=192.168.100.160 port=36643
>> >> obc2-sd: job.c:207 Job name not found: evo-www.2008-03-25_21.14.28
>> >>
>> >> A lot of minutes later the FD has a timeout:
>> >> evo-plattform1-fd: btimers.c:212 thread timer 0x80a3808 kill bsock
>> >> tid=0xb70f2b90 at 1206476671. evo-plattform1-fd: authenticate.c:196
>> >> cram_get_auth failed for Storage daemon evo-plattform1-fd: job.c:208
>> >> Quit command loop. Canceled=1
>> >>
>> >> The most interesting thing for me is, that a backup of evo_www over
>> >> SSH on OBC is successfull. The only different is the ssh-tunnel
>> >> /usr/bin/ssh -fnCN2 -o PreferredAuthentications=publickey -i
>> >> /etc/bacula/ssh/bacula -l root -R 9101:192.168.100.160:9101 -R
>> >> 9103:192.168.100.160:9103 evo_www
>> >>
>> >>
>> >> My question is: why does the SD on OBC2 not know about the job? What's
>> >> wrong? Or WHEN does the SD hear about the job? And who talk about the
>> >> job? The director or the FD?
>> >>
>> >> The SD is: 2.0.3-4ubuntu4
>> >> The director ist: Version: 2.0.3-4ubuntu4
>> >> I tried some hosts with different versions of FD.
>> >> The FD is: less than 2.0.3
>> >>
>> >>
>> >> I hope anobody can help me.
>> >>
>> >> Kind regards,
>> >> Thomas Rotter
>> >>
>> >>
>> >> ------------------------------------------------------------------------
>> >>- Check out the new SourceForge.net Marketplace.
>> >> It's the best place to buy or sell services for
>> >> just about anything Open Source.
>> >> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketp
>> >>lac e _______________________________________________
>> >> Bacula-devel mailing list
>> >> Bacula-devel@xxxxxxxxxxxxxxxxxxxxx
>> >> https://lists.sourceforge.net/lists/listinfo/bacula-devel



-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
Bacula-devel mailing list
Bacula-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/bacula-devel


This mailing list archive is a service of Copilotco.