Camera running OpenIPC
If the camera runs OpenIPC firmware, the agent is installed on the camera itself. It joins your network on its own and becomes a full participant in it: video, ONVIF, settings and SSH answer remotely exactly as they did at home.
The agent's settings live in the U-Boot environment rather than in the filesystem, which is why they
survive a rootfs reflash. Before you start: the camera needs wg, ip and fw_setenv – OpenIPC
firmware has all three.
1. One line on the camera
Take an enrolment token from the panel, under "How to connect" – it comes already filled into a ready command. SSH into the camera and run it:
curl -fsSL https://cloud.openipc.ru/install.sh | sh -s -- tok_...
There is nothing else to choose. The installer looks at the camera's processor, fetches the build for
it, checks its checksum, puts the agent in /usr/sbin/ and the start script in /etc/init.d/, writes
the address and the token, and starts the agent. No reboot is needed: the service brings the tunnel
up itself.
A few seconds later the camera shows up in the panel – already yours: you minted the token, and a device that joins with it belongs to you from the first second. There is nothing to claim, but the RTSP login and password do have to be set – otherwise the video stays empty, see step 4.
If anything goes wrong, the installer does not explain itself on the camera: it prints a two-digit
code – cerberus: E13, "no build for this processor yet", for example – and stops without touching
anything. Every code is decoded below, under Installer codes.
The agent's source is open: github.com/OpenIPC/cerberus. Its builds for every architecture are published there too, and that is where the installer takes them from.
2. What it does, in case you need it by hand
You do not have to know this, but if something went wrong, these are the same steps. The address and the token go into the U-Boot environment rather than the filesystem, which is why they survive a rootfs reflash:
fw_setenv cerberus_api https://cloud-api.openipc.ru/v1 fw_setenv cerberus_enrollment_token tok_... /etc/init.d/S99cerberus restart
These keys used to be called streq_api and streq_enrollment_token. The old names still work, and
cameras connected with them do not need to change anything: the agent moves its own keys itself.
Nothing else on the camera is touched: the rootfs stays as it was, and all of the agent's state lives in the U-Boot environment.
3. If someone else minted the token
A camera that joined with someone else's token – a batch token, or one an installer minted – belongs
to no one, and its stream is served to nobody. What claims it then is the claim code: that is how
you prove the hardware is in your hands. The installer prints it right after installing, as
cerberus: claim K7M29XQFTB3P; if the line is lost, the code and everything else stored is printed
by cerberus status:
cerberus status
In the panel press "Add", enter the claim code – as shown, dashes and any case are fine – and press "Claim".
4. RTSP login and password
This step is always needed, even once the camera shows up in the panel. The cloud pulls video from the camera over RTSP, and RTSP is behind a password: without the login and password the cloud gets an empty answer from the camera rather than a picture, and the player opens black.
In the panel open "Devices and network", press the RTSP button in the camera's row and enter
the camera's login and password. Usually they are the same as for its web interface; on a fresh
OpenIPC they are root / 12345. Once saved, the button reads RTSP ✓. If the camera was added
through "Add", the panel asks for them itself as soon as the camera connects.
Changed the password on the camera – change it here too. They are stored encrypted and the panel never shows them back – they can be replaced, not read – and they exist for exactly one purpose: so the cloud can pull the stream when there is no direct path to the camera.
Remove the cloud from a camera
If the camera should no longer be in the cloud, one line takes it all off – the same way it went on:
curl -fsSL https://cloud.openipc.ru/uninstall.sh | sh
The script stops the service, tears the tunnel interface down, erases everything the agent wrote
into the U-Boot environment (the address, the token, the camera's key, the claim code, the join
material), removes the autostart entry from /etc/init.d/ and deletes the agent itself. No reboot
is needed. It does not touch the firmware or the camera's own settings: video, RTSP and the web
interface stay as they were.
The device's record in the cloud stays, and that is deliberate: the agent has no right to revoke itself. Otherwise a camera someone reached over SSH could be signed out of another person's account without asking them. Remove the device in the panel – "Devices and network", "Release".
Installing it again works exactly as the first time – the camera will issue a new claim code: its key and its number were erased with everything else, so to the cloud it is a new piece of hardware.
Installer codes
The installer is terse on purpose: a long explanation is no fun to read on a camera's console, while a code is short and can be quoted in the chat. It prints the address of this page next to the code, so that there is nothing to go looking for:
cerberus: E13 cerberus: https://cloud.openipc.ru/docs/openipc-camera/#codes
The code is also the command's exit status. Until it is printed, nothing on the camera has changed.
The agent itself prints the same address after every error of its own (cerberus: error: …); those
are worded rather than numbered, and the table under "If something is wrong" covers them.
| Code | What happened | What to do |
|---|---|---|
E10 | the command was not run as root | log into the camera as root and run it again |
E11 | the camera has no fw_printenv | this is not OpenIPC firmware – the agent does not install on it |
E13 | there is no build for this processor yet | name the model and the processor in the beta chat – they are printed on the line above, cerberus: chip …, cpu … |
E14 | the agent or its start script did not download | run the command again: this is usually a dropped connection |
E15 | the checksum did not match | retry; if it keeps happening, write to the chat – the file arrives corrupted |
E16 | cannot write to /usr/sbin or /etc/init.d | the camera is out of space, or the partition is mounted read-only |
E17 | fw_setenv did not store the address and the token | check that the environment is reachable at all: fw_printenv |
E20 | the agent is installed, no token was given | run the two fw_setenv lines it printed and restart the service |
E21 | installed and started, but it did not reach the cloud within 40 seconds | the camera did not reach the cloud: check the address and the link, then cerberus status |
E30 | the uninstall (uninstall.sh) could not remove something | the partition is mounted read-only, or fw_setenv does not work |
E20 and E21 are not failures. The first is what the command answers when run without a token:
the agent is in place, it just has not been told where to connect. The second means the agent is
running but has not connected yet – the code appears by itself once the camera reaches the cloud.
If something is wrong
| Symptom | Usually | What to do |
|---|---|---|
| The camera never appeared in the panel | the token was spent or expired | mint a new one and repeat step 1 |
cerberus status says "not enrolled" | the camera did not reach the cloud | check the address in cerberus_api and that the camera has internet |
| The camera is there, the stream is not | it joined with someone else's token and is not claimed | enter the claim code, step 3 |
| The stream opens empty | the RTSP login and password are not set or wrong | set them, step 4 |
| The camera vanished after a reflash | the U-Boot environment, and the key with it, was erased | connect it again, step 1; release the old device in the panel |
The camera's key, its claim code and its number live in the U-Boot environment together, and that is deliberate. Keeping the number while losing the key would leave a camera that can neither prove it is the old one nor start afresh. While they live together, an erased environment simply means a new camera: it connects from scratch, and the old record is released in the panel.