One of the cool things of using open protocols and interfaces is that you are not limited to use special tooling and can resort to tools you are familiar with. No need to use some unknown programming language or to throw huge amounts of money at some company to get access to the data in your system. This post will explain how you can access the API of your opsi server with curl.

The accessibility for data via open standards is a huge advantage not only for external applications but also for the internal development. Different parts of the system can be implemented with different programming language - whatever fits the job. And for testing purposes there is always another way to produce and receive the data.

Accessing the opsi server

So let's access opsi on the commandline of some Linux machine via curl and get some basic information about the system:

curl --insecure --user username --data '{"params": [], "id": 1, "method": "backend_info"}' https://opsiserver.your.domain:4447/rpc

Update 06.08.2018: Of course you can also use Windows for such a request. As Detlef pointed the syntax for curl on Windows is slightly different. You have to use double quotation marks for all values and this leads to escaping the inner ones.

It would look like this:

curl --insecure --user username --data "{\"params\": [], \"id\": 1, \"method\": \"backend_info\"}" https://opsiserver.your.domain:4447/rpc

Update end

The --insecure parameter is required if you are using self-signed certificates to disable the verification of the certificate. Since the server requires authentication we need to provide the user to access the API with the --user parameter. You will be asked for the corresponding password through a prompt. The --data parameter is then used to POST the JSON-formatted request to the server. The format follows the first version of the JSON-RPC specification. When specifying the address - this is the last part of the line - you need to make sure that the proper port is used and that you post against /rpc.

A succesful call will return you one line with the results that may look a little bit like the following:

{"id": 1, "result": {"opsiVersion": "4.0.7.30", "realmodules": {...}, "modules": {...}}, "error": null}

The output usually is much longer but to be able to concentrate on the more important parts I replaced some parts by ....

The first thing we get by receiving such a result is that we know that the opsi-server is up and running. Yeah! :) With every response we get an id matching the one we used when posting our request. So for multiple requests we can differentiate what result belongs to which request. We are running 4.0.7 in this example - great! If something went wrong we will receive data in error with more information about what went wrong. This call succeeded and therefore we did not get an error back.

If you want to leverage the API further you now should try the method backend_getInterface to see what methods the API offers and what parameters they use.

Do you already use something similar to access the opsi API? wget anyone?