Once the configuration is set up and works correctly, you can manage your eBoxes using Perl scripts, this is the only available option so far.
The current framework relies on
EBox::ControlCenter::RemoteEBoxProxy
class which manages the list of eBoxes that are already in the
system and get an eBox proxy to send it actions.
RemoteEBoxProxy may divide its
functionality by two: accessing to the eBoxes in the control
center group and manage the eBox configuration remotely.
There are two static methods to do so:
ListNames and
GetEBoxByName. The former lists the
current eBox set using its unique identifier based on
the name provided when the eBox joining was done. The latter
is used to the proxy which represents the required eBox to
manage its configuration indicating if a read-only or
read-write instance is going to be handled.
Example 19.2 shows after adding first and second eBoxes to the group how a proxy is got:
Example 19.2. Accessing to an eBox proxy
my $eBoxesRef = EBox::ControlCenter::RemoteEBoxProxy->ListNames();
# This will show the current list of eBoxes
print 'List of eBoxes in this control center: ' . join ( ', ', @{$eBoxesRef} ) . '\n';
# Get the proxy reference
my $eBoxProxy;
try {
$eBoxProxy =
EBox::ControlCenter::RemoteEBoxProxy->GetEBoxByName('third', 0);
} catch EBox::Exceptions::DataNotFound with {
print STDERR 'The eBox with name three does not exist';
# Get second one instead
$eBoxProxy = EBox::ControlCenter::RemoteEBoxProxy->GetEBoxByName('second', 0);
};
This class does not provide a way to update the eBox database. This is done by the joinEBox.pl and quitEBox.pl programs as Section 19.2.2 explains.
Once the remote eBox proxy is obtained, we use it to handle
a concrete eBox configuration. There are some common methods
to know the current eBox general module configuration as
modNames or
modExists. However, the interesting
thing comes with the modMethod
method, which is intended to run a public method from any eBox
module installed in the remote eBox. It can launch any kind of
exception coming from the connection, the calling parameters
or the method execution on the server side, in this case, the
remote eBox. Its signature has these three positional arguments:
This String parameter indicates the module
to run a method, it must be one of the returning values
from modNames return
value.
Indicates the method name to run
An array containing the method parameters
Using this way, it may be possible to call every public method from any eBox module. Example 19.3 assumes a remote proxy is already got as Example 19.2 describes.
Example 19.3. Calling public methods from an remote eBox
# Print a squid log serach
print Dumper($eBoxProxy->modMethod('logs', 'search',
(
'2007-6-20 2:22:0',
'2007-6-22 2:22:0',
'squid',
15,
0,
'timestamp',
undef
)
)
) . '\n';
# Print the metadata information about the "stc2" certificate
print Dumper($eBoxProxy->modMethod('ca', 'getCertificateMetadata', (cn => 'stc2')));
As you may see, the parameters require to be enclosed in an
array. The returned value is the same one that a normal call
produces.