Frequently asked questions

Honest answers to the questions we hear most often. If you do not find what you are looking for, the details are on the agent page and the how it works page.

Questions and answers

No. The MyOsicam agent reads and adopts the OScam installation that is already on your server — it does not modify any configuration file without an explicit instruction from you via the panel. OScam keeps running exactly as you configured it; subscribers continue to be served without any interruption during or after the agent install.

The only change at install time is the addition of a systemd service unit and a narrow sudoers rule that lets the agent manage the OScam service. Nothing in your existing oscam.conf, oscam.server, or oscam.user is touched.

Yes. OScam runs as an independent service on each of your servers. The MyOsicam panel and the agent are your management plane — they let you monitor and configure your fleet, but they are not in the path of OScam's actual card-sharing traffic.

If the panel is unreachable, or if the agent on a server stops for any reason, OScam keeps serving your subscribers without interruption. The agent will reconnect automatically once the panel is reachable again and resume normal heartbeat and sync operations.

Only management-plane metadata is sent to the MyOsicam panel. That includes:

  • The list of OScam instances on your server (names, config paths, runtime status).
  • Configuration summaries: reader count, protocol ports, global settings from oscam.conf.
  • Reader and user-account entries from oscam.user — usernames, enabled state, caid/ident lists.
  • Lightweight resource readings: CPU usage (%), RAM consumption (MB), system load average.
  • Heartbeat data: the agent's host identity and last-seen timestamp.

What is never sent: subscriber card data, entitlement details, decryption keys, DVB decryption material, or any other sensitive payload. Your data stays on your own infrastructure; the panel only receives what you need to manage your fleet from a single dashboard.

Yes. The agent is a standard systemd service plus a single line in /etc/sudoers.d/. To remove it cleanly:

  1. Stop and disable the service: sudo systemctl stop myosicam-agent && sudo systemctl disable myosicam-agent.
  2. Remove the service unit file: sudo rm /etc/systemd/system/myosicam-agent.service && sudo systemctl daemon-reload.
  3. Remove the agent binary: sudo rm /usr/local/bin/myosicam-agent.
  4. Remove the sudoers rule: sudo rm /etc/sudoers.d/myosicam-agent.

After removal, OScam is completely untouched — it continues running exactly as it did before you installed the agent. No residue is left in any OScam configuration file.

No. The agent makes outbound HTTPS connections to the panel — your OScam server never needs to accept incoming connections from the internet. You do not need a public IP address on the server, and you do not need to open any inbound firewall ports.

The panel itself does need to be reachable over HTTPS (that is your management interface), but the individual servers running OScam and the agent have no such requirement. They only need outbound internet access on port 443 to reach the panel.

The MyOsicam agent supports Ubuntu 20.04 LTS or newer and Debian 12 or newer. Ubuntu 22.04+ is recommended for new installs. The agent is a statically compiled Go binary with no C-library dependency, so it is straightforward to support future distributions.

The MyOsicam panel itself requires Ubuntu 22.04 LTS or newer, or Debian 12 or newer. This higher floor is due to the PHP 8.3 runtime and systemd requirements of the panel installer.

Root access is needed exactly once — during the SSH-based install triggered from the panel. The installer uses root to:

  • Create the myosicam-agent systemd service unit.
  • Write a narrow sudoers rule that allows the agent to start and stop OScam without a password.

After that, the agent daemon runs as its own unprivileged system user. No root privileges are involved in any routine operation: heartbeats, syncs, config reads, or applying panel-initiated changes all happen as that unprivileged user.

There is no hard limit. MyOsicam is fleet-oriented by design — the panel dashboard is built to give you a clear view across as many servers as you operate. Each server runs one agent instance, and each agent manages all OScam instances on that server. Practical limits are determined by the resources of the server hosting your panel.

Yes. Every request the agent sends to the panel is signed with an HMAC-SHA256 signature computed from a shared secret established at registration. The panel verifies the signature on every call and rejects anything with a missing or incorrect signature.

The initial install uses a single-use install token generated by the panel before the SSH install is triggered. The token is presented by the agent on its first registration call and is immediately invalidated once used — it cannot be replayed.

All traffic travels over HTTPS (TLS). The agent never opens a listening port; it only initiates outbound connections to the panel.

OScam is completely unaffected. The agent is a standard systemd service configured to restart automatically on failure. If the agent crashes or is manually restarted, OScam continues serving subscribers without interruption. When the agent comes back up it re-establishes its connection to the panel, sends a fresh heartbeat, and resumes normal operation — no manual intervention needed.

No. The agent only applies changes that you explicitly initiate through the panel. It **never silently rewrites** your oscam.conf or oscam.server files.

User-account management (adding, editing, or removing entries in oscam.user) can be done via the panel, and the agent applies those changes directly to the file and triggers a live WebIF reload — no OScam restart required. Any other configuration changes must be explicitly authorised through the panel interface; the agent does not make autonomous decisions about your OScam configuration.

The panel includes a built-in self-update mechanism. When a new release is available you will see a notification inside the panel UI. Updates are signed releases — the panel verifies the signature before applying anything. The update process downloads the new release, applies it in-place, and restarts the panel service. You do not need SSH access or manual file transfers to keep your panel current.