G Jo <g.johnston <at> kainos.com> writes:

> Hi Marco,
> 
> Firstly thank you very much for taking the time to respond to my
> posting, it’s very much appreciated.
> 
> In turn to address the points and the queries from your reply:
> [MVW] - I guess you build your plugin using the code at:
https://github.com/bareos/contrib-pgsql-plugin]
> 
> [GJ] – Yes i believe that’s what we used.
> 
Its kind of important that you know for sure. That is the only
plugin that will work.


> 
> [GJ] – Interesting to note both that the plugin is not fully supported
> but that you have gotten it to work previously.
Its more that we don't check on regular basis if things still work
and we don't support it as standard part of the BAREOS subscription.
So any support is on best effort or as payed time and material basis.

> 
> [GJ] On 1st execution the status client=ip-172-31-72-8-fd returned
> nothing so no plugins where loaded.
> 
> *status client=ip-172-31-72-8-fd
> Connecting to Client ip-172-31-72-8-fd at ip-172-31-72-8:9102
> 
> I checked my initial bareos-fd.conf configuration and it was
> as follows with the Plugin Directory explicitly named as
> /opt/bacula/plugins but no entry for Plugin Names
> 
> FileDaemon {                          # this is me
>   Name = ip-172-31-72-8-fd
>   Plugin Directory = /opt/bacula/plugins
> 
That is probably because Bacula Enterprise Edition installs
itself into /opt/bacula and Plugin Names is something only
Bareos supports as Bacula loads its plugins in fully random order
(e.g. the way they are found in the directory) and doesn't allow
you to only load some plugins from a dir and in a certain stacked order.


> 
> [GJ] Now the default bareos Plugin Directory which is initially commented
> in rgw bareos-fd.conf file out is 
> 
> Plugin Directory = /usr/lib64/bareos/plugins
> 
> I modified the file to use this plugin directory instead of
> /opt/bacula/plugins and restarted the bareos-fd service.
> 
Yes the default for BAREOS are indeed different we use the normal
system paths and every supported plugin is installed there when
you install the different RPMs.

> This time the bconsole command status client=ip-172-31-72-8-fd
> returned details that the bpipe plugin had been loaded
> 
> *status client=ip-172-31-72-8-fd
> Connecting to Client ip-172-31-72-8-fd at ip-172-31-72-8:9102
> 
> Plugin Info:
>  Plugin     : bpipe-fd.so
>  Description: Bareos Pipe File Daemon Plugin
>  Version    : 2, Date: January 2014
>  Author     : Kern Sibbald
>  License    : Bareos AGPLv3
> 
> Checking the contents of the /usr/lib64/bareos/plugins directory I
> found only the bpipe-fd.so library. 
> 
> Having proved that the bpipe plugin library could be loaded from
> the /usr/lib64/bareos/plugins directory I copied the pgsql plugin
> library from /opt/bacula/plugins to leave the directory contents as
> 
> root <at> ip-172-31-72-8 plugins]# pwd
> /usr/lib64/bareos/plugins
> [root <at> ip-172-31-72-8 plugins]# ls -l
> total 120
> -rwxr-xr-x 1 root root  20056 Dec 31 18:00 bpipe-fd.so
> -rwxr-xr-x 1 root root 100234 May 15 10:02 pgsql-fd.so
> 
> I restarted the bareos-fd daemon service but with the 2 plugin
> libraries in place console command status
> client=ip-172-31-72-8-fd only loaded the bpipe plugin.
> 
> I then tried changing the bareos-fd.conf config to name only the
> pgsql plugin using this configuraiton
> 
> Plugin Directory = /usr/lib64/bareos/plugins
> Plugin Names = "pgsql"
> 
> And this time status client=ip-172-31-72-8-fd showed that no plugins
> where loaded.
Seems the dlopen of the plugin fails probably because its missing some
symbols or such.

> 
> As a penultimate attempt I tried with the pgsql-fd.so plugin being the
> only plugin library in /usr/lib64/bareos/plugins but again it failed
> to register as a plugin via status client=ip-172-31-72-8-fd with and
> without explicitly naming it in Plugin Names.
> 
> And finally I tried renaming the pgsql-fd.so to bpipe-fd.so to try and
> fool bareos into loading it but again no plugins where loaded.
> 
> So, in summary no matter what I tried, the pgsql plugin failed to load.
> 

To be sure that the pgsql plugin is a proper plugin for bareos you
could run the bpluginfo binary which peeks at the plugin to see if
it can find the right entry points and some plugin specific MAGIC data.

For the bpipe-fd.so on Solaris that looks like:

15:14 [mvw:mercury][3967]
/projects/GITrepositories/BAREOS/contrib-pgsql-plugin >
/opt/bareos/sbin/i86/bpluginfo -iv /opt/bareos/lib/plugins/bpipe-fd.so     
                                                                           
                                    

Plugin type:            Bareos File Daemon plugin
Plugin magic:           *FDPluginData*
Plugin version:         2
Plugin release date:    January 2014
Plugin author:          Kern Sibbald
Plugin licence:         Bareos AGPLv3
Plugin description:     Bareos Pipe File Daemon Plugin
Plugin API version:     9
Plugin usage:
bpipe:file=<filepath>:reader=<readprogram>:writer=<writeprogram>
 readprogram runs on backup and its stdout is saved
 writeprogram runs on restore and gets restored data into stdin
 the data is internally stored as filepath (e.g. mybackup/backup1)

Plugin functions:
 newPlugin()
 freePlugin()
 getPluginValue()
 setPluginValue()
 handlePluginEvent()
 startBackupFile()
 endBackupFile()
 startRestoreFile()
 endRestoreFile()
 pluginIO()
 createFile()
 setFileAttributes()
 checkFile()


> I’ve run out of things to try so I’d be grateful if could review my
> logic and see if you can suggest anything.
> 
> One thing I should mention in case it is relevant
> 
> On the director server our bareos catalog database is a mysql database
> containing 30 tables. However as the pgsql plugin demands a postgres
> database it is stored in a separate postgres instance with 4 tables.
>
The actual meta data for the backup program and for the plugin being
separate is fine I think its even better as I would not want to even
merge the two even when its possible. Its also not a problem yet as you
don't get the plugin loaded which is something not related to any config
data being used later on.

You can also run the bareos-fd in debug mode which will probably reveal
much more about the loading of the plugins etc.

e.g. something like bareos-fd -f -d 200
will run the bareos-fd in a pretty high debug level and show what its
doing regarding the loading of plugins.

e.g.

mercury-fd: plugins.c:222-0 load_plugins
mercury-fd: fd_plugins.c:1615-0 is_plugin_compatible called
mercury-fd: fd_plugins.c:1590-0 Loaded plugin: python-fd.so

 
-- 
Marco van Wieringen                   [email protected]
Bareos GmbH & Co. KG                  Phone: +49-221-63069389
http://www.bareos.com                     

Sitz der Gesellschaft: Köln | Amtsgericht Köln: HRA 29646
Komplementär: Bareos Verwaltungs-GmbH
Geschäftsführer: Stephan Dühr, M. Außendorf, J. Steffens,
                 P. Storz, M. v. Wieringen

-- 
You received this message because you are subscribed to the Google Groups 
"bareos-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to