Hello, The documentation should have stated that %d was the "daemon" name rather than the Director's name. Getting the Director's name has not been implemented.
If you want the Director's name, it really needs a new edit variable that will be a bit more complicated. Perhaps for the sake of this email we can call it %D. When editing %D in the Director, it would of course be simply myname. In either the FD or the SD, the Director that has called the FD or SD is known during the authentication process, however, the pointer to the Director resource, "director" for the FD, and probably the same for the SD, is not kept. It would need to be stored, probably in the jcr. However, I am wondering if it is really necessary to store the Director name (actually Director resource pointer) just to be able to edit it in a run script. Is there some really practical reason? Regards, Kern On 11/07/2011 10:43 AM, Bastian Friedrich wrote: > Hi, > > when using a client side run script, the job codes are evaluated by the > fd. Unfortunately, this results in a broken evaluation of the director > name %d (which is translated to the variable "myname", containing the > _client_ name in the fd rather than the director name). > > This has been checked in 5.2.1 and 5.0.3. > > I see the following options (and will be happy to implement one of them, if > appropriate): > > - Evaluate the runscript commands on the director side (move the > edit_job_codes call from lib/runscript.c to all locations where runscripts > are stored, in this case dird/fd_cmds.c) > > - Evaluate run scripts twice, passing sets of appropriate codes (just evaluate > %d on the director, all others on the fd). I'd modify the function's > prototype in that case. > > - Don't use "myname" for %d, but something better. I don't see the dir name > stored in the jcr structure, however? > > - Create a new appropriate variable in the fd, and modify %d for that variable > prior to executing edit_job_codes > > Any thoughts on that topic? > > Thx > Bastian > > PS: The topic is related to the job code callback stuff which I sent a cleanup > patch for on 2008-07-16 (Subject "Re: [Bacula-devel] Clone jobs and storage"). > Feel free to re-consider taking this or a similar patch upstream. I have an > updated patch for 5.2.1, just in case ... > ------------------------------------------------------------------------------ RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 _______________________________________________ Bacula-devel mailing list Bacula-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-devel
