During the last opsi conference I had many nice talks with different opsi users. I got some questions about how to do some common tasks with opsi on the commandline and want to show what can be done in this post.

These examples are to be executed on the commandline of your opsi server. It makes of use an opsirc file to avoid manually typing in credentials. If you are scripting your opsi installation I recommend setting it up!

opsi-admin talks to the server with JSON-RPC. Please be aware of how your shell handles quotation marks and curly brackets.

Listing all clients

In opsi hosts are differentiated between OpsiClient, OpsiDepotserver and OpsiConfigserver.

To now get a list of all clients we filter for OpsiClient:

opsi-admin method host_getObjects '' '{"type": "OpsiClient"}'

In case you only need the IDs of the clients use host_getIdents:

opsi-admin method host_getIdents 'unicode' '{"type": "OpsiClient"}'

Listing all products

In case you want to know what products are available in your environment you can use the following:

opsi-admin method product_getObjects

This might list one product more than once if there are still references to old versions in your environments. Such a reference could e.g. be that you run a multidepot environment and one of your depots still has an older version installed.

Changing a host description

This is one of the tasks that is easily done through the three steps of reading the value, modifying it and then inserting it again. Once you got this into your blood you can easily change most things on your server without any need to botch around directly in the backend data.

In this example we are changing the client niko-client1.uib.local:

opsi-admin method host_getObjects '' '{"id": "niko-client1.uib.local"}' > host.json
sed --in-place 's/"description":.*/"description": "This is the new text.",/' host.json
opsi-admin method host_updateObjects < host.json

The important thing is that the file has to be valid JSON and therefore we need to add the comma at the end of the replacing text!

Changing the host parameters of a specific client

What is shown as host parameters in opsi-configed is a Config object in the backend. These are the global defaults. These configs can be overriden per client with specific ConfigState. If there isn't a ConfigState for a client the global default will be used.

Reading all configs

To get an overview of the configs you have, their type and possible we use config_getObjects. The possible values are important if we are dealing with configs that only accept specific values.

opsi-admin method config_getObjects

Change a config for a client

We now decided to change the depot assignment of a client (the config is clientconfig.depot.id) and change this to another server:

opsi-admin method configState_create 'clientconfig.depot.id' 'niko-client1.uib.local' '["depotserver.uib.local"]'

Controlling the value:

opsi-admin method configState_getObjects '' '{"configId": "clientconfig.depot.id", "objectId": "niko-client1.uib.local"}'

Methods ending with ..._create are present for many object types. These take the values required for object creation as parameters and might be simpler for your use case because you do not need a complete JSON object but can use the order of the parameters to assign the values.

What parameters are required can easily be checked with opsi-admin -ic by typing method followed by the methodname and then pressing [TAB] to show what requires are accepted. Parameters whose name is preceded with an asterik are optional. Parameters with two asteriks usually require a filter object in JSON form.

Retrieving a products dependencies

Simple approach:

opsi-admin method productDependency_getObjects '' '{"productId": "jedit"}'

For every package version the dependencies could be different. If you run an environment where different versions of a package could be available you should specify the versions of the package.

opsi-admin method productDependency_getObjects '' '{"productId": "jedit", "productVersion": "5.4.0"}'

You could narrow this further down by providing an additional packageVersion.

Get status of a package on a specific client

We use productOnClient_getObjects to get the installation status and filter by client and product ID.

opsi-admin method productOnClient_getObjects '["installationStatus"]' '{"clientId": "niko-client1.uib.local", "productId": "win7-x64"}'

We can also filter for products with a specific status on a client:

opsi-admin method productOnClient_getObjects '["installationStatus"]' '{"clientId": "niko-client1.uib.local", "installationStatus": "installed"}'

Marking a package for installation on a client

The easiest way to do achieve this is using one of the action-focussed methods that are provided as backend extensions:

opsi-admin method setProductActionRequestWithDependencies firefox 'niko-client1.uib.local' setup

To do the same with the core methods we create a productOnClient object that contains our action request. Here is a simple variant that requests 'setup' for the LocalbootProduct firefox.

opsi-admin method productOnClient_create firefox LocalbootProduct 'niko-client1.uib.local' null 'setup'

To check for the status we use the following:

opsi-admin method productOnClient_getObjects '' '{"clientId": "niko-client1.uib.local", "productId": "firefox"}'

If you have further questions head to the opsi development forum. This is the beste place for questions around API and scripting with opsi!

And if you want to meet fellow opsi users you should register for the upcoming opsiconf in 2020!