Operate your ISP with Core

1. How Netmarga works

Hub distributes the platform. Each ISP runs its own Core server. Core holds that ISP’s operational records. Clients register and work through their Core panel; they do not need a Hub administrator account.

Core registers its organisation with Hub over HTTPS, then reports its status and retrieves configuration. CRM and business records remain in the Core server’s local databases. Device login profiles also remain on that Core server. Network Monitoring inventory is currently manual. An existing Oxidized installation can use the new profile connector for configuration backups.

This manual describes Core 0.5.7, CRM 1.2.0, Network Monitoring 0.2.0 and the other initial business modules at 0.1.0. A feature labelled “not connected yet” is not running in the background.

2. Where to sign in

Replace YOUR-CORE-IP with the address or DNS name of the ISP’s Core server. 127.0.0.1 means the computer you are currently using; it is not an outside-access address. Allow Core’s TCP 8443 through the appropriate server/network firewall. If the server is behind NAT, external access also requires the appropriate network forwarding or VPN.

Core initially uses a self-signed HTTPS certificate. Verify the fingerprint printed by the installer before trusting it. Use a properly managed certificate for routine customer-facing access. Hub and Core accounts are separate; changing one does not change the other.

3. Install and register Core

1. Prepare an Ubuntu 22.04, 24.04 or 26.04, or Debian 12/13 server running systemd, with root/sudo access and outbound HTTPS.
2. Open Install Core. Download the package or run the installation command below on the client’s server.
3. Save the panel access code and certificate fingerprint printed by the installer.
4. Open the Core panel on port 8443. Sign in as admin with the initial access code.
5. Enter organisation name, contact name and email; click Register & activate. Registration activates immediately.
6. Change the initial administrator password and create named organisation accounts.
7. Select the required modules in the left menu and install them.

curl --proto '=https' --tlsv1.2 -fsS https://hub.netmarga.com/install-core.sh | sudo bash

Core installs only its panel, Hub management VPN and update components. LibreNMS is installed separately from NOC → Network Monitoring when an administrator chooses it. RADIUS and other packages remain separate modules. The installer preserves an existing managed Core registration and its records during upgrades. It refuses an unmanaged Core directory and conflicting unmanaged FreeRADIUS installations rather than taking them over.

4. Organisation users and permissions

Use Organisation users in the top bar to create usernames. Assign each person their own account so audit records identify who made a change. The current screen creates users; account deletion and a complete role editor are not implemented.

Every organisation user can use Change password with their current password. Core administrator/staff passwords are 12–128 characters. Changing a password invalidates existing sessions for that account. Use Sign out when finished.

5. Installing and using modules

The left menu selects a module; its content opens on the right. If it is not installed, an administrator sees an Install button. Installation checks that Core is actively registered with Hub. An already installed module can be used locally while Hub is temporarily unreachable.

1. Select a module and click Install once.
2. Select its record category, such as Invoices, Tickets or Devices.
3. Complete the Add record form and click Save record.
4. Click a record ID in the list to edit it. Click New record to start another record.

The new business modules display the latest 200 records. They do not yet provide search, pagination, deletion or full reports. If someone else edits a record first, a revision check rejects an outdated save: refresh, review the latest values and apply your changes again. Recent activity lists the actor and time; it is not a complete field-by-field history.

Business-module customer/subscriber references are currently text fields. CRM and Subscriber Management have their own linked records. Do not assume that entering a name in Billing automatically links or updates a CRM customer.

6. CRM: from prospect to installation

Install CRM to enable its customer and subscriber functions. Start with Customers and Locations, then use the sales records as needed.

1. Customers: create the person or organisation receiving service.
2. Contacts: record the people and contact details associated with the customer.
3. Locations: add the customer’s service premises and coverage information.
4. Leads and Tasks: track prospects and follow-up work.
5. Quotations: record a proposed service. Use the quote conversion action to create its installation order.
6. Orders: track installation work and associate the resulting subscriber connection.
7. Notes: retain relevant customer history.

These are operational records. Saving an order does not send an installer to a site, configure a router, collect a payment or provision an external service automatically.

7. Create an ISP subscriber connection

1. Create the customer and their service location.
2. Open Service plans. Enter the speed, price, currency, billing cycle and availability.
3. Open NAS / RADIUS. Register the NAS with its IP address, vendor and shared secret.
4. Open Subscribers and create the connection. Link its customer, location, plan and NAS; link an installation order where applicable.
5. Enter the unique subscriber username, connection type (PPPoE or hotspot), NAS authentication password and service status. Set applicable start/end dates.
6. To allow self-service access, set a separate subscriber panel password. Add the recorded WiFi SSID/password if you want those details visible to that subscriber.
7. Configure the corresponding NAS to use this Core’s RADIUS address and matching secret, then test one connection before adding more.

A customer can have multiple subscriber connections. The panel identity is the subscription username, not a shared login covering every connection owned by a customer.

Active is eligible for network authentication subject to the other policy checks. Pending, Suspended and Terminated are not eligible. An account can also fail authentication when its NAS is disabled or its dates exclude the current day. Billing status does not automatically change the subscriber status.

8. Keep the different passwords separate

The subscriber uses the same username for network access and self-service, but the two passwords are stored separately. Resetting the panel password does not change the NAS authentication password. A blank saved password field generally preserves the existing value; it does not erase it. Older long NAS/authentication credentials remain usable until explicitly replaced.

Core and subscriber panel passwords are hashed. RADIUS needs recoverable authentication credentials for supported protocols. Oxidized also needs recoverable device credentials; its saved profile secrets are encrypted. No saved device password is shown in profile lists or edit forms.

9. RADIUS and NAS operation

Managed FreeRADIUS reads the policy generated from CRM. Synchronization runs approximately every 15 seconds. Configure the NAS to send authentication to the Core server’s UDP 1812 and accounting to UDP 1813; restrict those ports to your NAS addresses. The NAS shared secret must match the record in Core.

MikroTik and Huawei PPPoE/hotspot policies include vendor speed attributes. Configure the appropriate RADIUS use on the device itself. NAS registration in Core does not configure the router or create its PPPoE server/hotspot portal.

Accounting supports start, interim and stop records. Configure interim updates on the NAS if you need continuing usage data. Core displays recent accounting records; absent interim updates can leave usage/status stale.

Suspending a subscriber changes eligibility for a later authentication. This release does not send live disconnect/CoA commands, so an already connected session may require action on the NAS. Hotspot vouchers, a generated captive portal, IPoE/EAP and automatic router provisioning are not included. PAP/CHAP have software-level packet validation; verify your own MikroTik/Huawei hardware configuration before production use.

10. Subscriber self-service

1. Set the subscriber’s panel password in the Subscriber record.
2. Give the subscriber their username, panel password and https://YOUR-CORE-IP:8443/subscriber.
3. The subscriber signs in to view only that subscription’s service details and recorded WiFi details.
4. They can change their panel password by supplying the current password and confirming the new password.

No panel password means self-service login is disabled for that subscription. The page does not reveal the NAS authentication password or NAS shared secret. A WiFi password shown here is the value entered in CRM; saving it does not remotely change a router’s WiFi configuration. Service status is recorded policy information, not a live router-health measurement.

11. The other business modules

Billing example: add an invoice, then record a receipt in Payments when paid. Payment entries do not update the invoice automatically; review the payment and change invoice status manually. This is an initial register, not a complete accounting ledger.

IPAM example: add subnet 192.0.2.0/24, then assign 192.0.2.10 within it. These documentation addresses are examples, not your actual network. Register the subnet before its addresses. A subnet with assigned address records cannot have its CIDR changed in place.

12. Network Monitoring and device inventory

Use Network Monitoring for Devices, Login Profiles and Incidents. Devices hold a management IP, vendor, site and manually recorded status. Incidents record severity, ownership and investigation/resolution notes.

Monitoring and configuration backup are different functions. LibreNMS handles polling/graphs once separately installed and configured. Oxidized logs into a device and retrieves its configuration. A configuration-backup profile is not an SNMP community and is not a RADIUS shared secret.

Core can install LibreNMS from NOC → Network Monitoring and opens it inside Core with the current Core account. Core administrators receive LibreNMS administrator access; staff receive global read access initially. LibreNMS does not yet automatically import the Core device inventory. The profile connector below supplies the devices enabled for Oxidized backup only.

13. Create and assign Oxidized login profiles

1. Sign in as an organisation administrator. Install Network Monitoring if necessary.
2. Open Network Monitoring → Login Profiles.
3. Enter a descriptive profile name, such as “Huawei access switches — east site”.
4. Enter the device’s SSH username, login password and SSH port (usually 22).
5. If the device requires a separate privileged-mode password, enter the optional Enable password.
6. Set Profile status to Enabled and save.
7. Open Devices and edit the relevant device. Select its Oxidized login profile.
8. Select the correct Oxidized model: routeros for MikroTik RouterOS, vrp for Huawei VRP, ios for Cisco IOS or junos for Juniper Junos.
9. Set Configuration backups to Enabled and save.

Use a separate profile for a device with unique credentials, or share a profile among devices that actually use the same login. A device has one assigned profile. Changing that profile’s password affects all devices assigned to it after synchronization; it does not change the password on the devices themselves.

To rotate credentials, update the device login and its profile together, then verify a successful backup. Blank password inputs retain the stored value. To remove an optional enable password, set Clear saved enable password to Yes and save. Disabling a profile excludes all of its devices from the connector; disabling a device’s Configuration backups excludes just that device.

Only administrators can create/edit login profiles or device assignments, because changing a device address controls where credentials are sent. Staff can view the device inventory and work on incidents. Passwords are encrypted in the local database; keep device-profile.key with your protected Core backups. Losing that key makes saved profiles unreadable.

14. Connect an existing LibreNMS/Oxidized installation

The verified latest script from core.netmarga.com was LibreNMS installer 1.1.51, published September 12, 2026. It uses an older NOC HTTP credential source. Do not rerun that complete installer on the new Hub/Core merely to connect profiles: it depends on the older login proxy and changes host nginx.

The new connector applies to an existing local Docker installation using that script’s layout: /opt/isp-modules/librenms/compose.yml and its oxidized directory. Core 0.5.7 and the monitoring module must be on the same server. It does not install LibreNMS, copy the older NOC’s devices, or connect a remote monitoring server.

1. Enter every device that should remain in the Oxidized source. Assign enabled profiles and enable Configuration backups. At least one enabled device is required for initial connection.
2. Review the change: this replaces the older NOC source for this Oxidized instance. Devices absent from the new enabled Core inventory will no longer be supplied by that source.
3. In a maintenance window, run the following command on that Core server:

sudo python3 /opt/isp-core/oxidized_profiles.py --connect

The connector saves a private copy of the previous Oxidized configuration, changes its source to a local JSON file, restarts the Oxidized container and enables a 30-second synchronization timer. It preserves the other configuration sections and configuration-history storage. Enabled nodes use stable names such as core-device-12; older hostname-based histories are not merged into those names.

Profile changes update the local source and restart Oxidized to apply them. An empty enabled inventory stops the Oxidized container; enabling devices again causes a subsequent synchronization to restart it. The source file contains the credentials Oxidized needs and is readable only by root/the container account. It is never a browser download.

sudo systemctl status isp-oxidized-sync.timer
sudo journalctl -u isp-oxidized-sync.service -n 50 --no-pager
cd /opt/isp-modules/librenms
sudo docker compose ps oxidized

Verify actual backup success in Oxidized/LibreNMS, including SSH reachability, the correct model, device privileges and any SSH host-key requirements. The connector does not create device users or verify their passwords when a profile is saved. Physical device backup has not been validated by this release’s automated tests.

If an old LibreNMS installer overwrites the source configuration, the sync service stops with an error. Review the configuration and reconnect. To stop synchronization, use sudo systemctl disable --now isp-oxidized-sync.timer; this alone does not restore the older source. Its saved configuration is under Core state as oxidized-config-before-*.yaml. Restore the appropriate copy with root access and restart Oxidized after reviewing its contents.

15. Core updates

1. Sign in as an administrator and open Updates.
2. Click Check for updates. Core also checks automatically about once an hour.
3. Review the version and release notes, then apply the update.
4. Allow the maintenance period to finish; refresh and sign in again if the panel restarts.
5. Check the installed version and open the affected modules.

Updating Core does not change administrator or staff passwords. Keep using your existing username and password. Initial credentials are generated only when a panel is first installed. If an existing account/configuration file is missing, the installer stops for recovery instead of creating a replacement password.

Updates download from the fixed Hub HTTPS origin and verify the installer checksum. The update process backs up the application and state, stops relevant services, runs the installer and verifies service health. On a detected failure it attempts to restore the prior application/state. OS package changes are not automatically rolled back.

Core 0.5.7 includes the panel updater and the LibreNMS installation job. Older Core installations need a command-line upgrade to gain it. Business modules are bundled with Core; their code updates with Core, while module installation state and local records are preserved.

16. Backups and data ownership

Arrange regular protected off-server backups for each ISP Core. The update backup is useful recovery protection but is not a substitute for your backup schedule. The Hub’s backup does not contain the ISP’s local CRM database.

Use consistent database backups or stop writers during a maintenance window; do not simply copy an actively changing SQLite database and assume it is complete. Preserve ownership, permissions and the profile key with the matching database. Protect backups because they contain credentials and customer data. Verify a restore on an isolated server before relying on it. Do not run two restored Core servers with the same registration identity.

Restoring a Core update backup does not restore LibreNMS Docker volumes. Back up monitoring data separately, particularly before changing its installation or source.

17. Daily administrator checks

1. Check that Core registration and services are healthy.
2. Review failed subscriber authentications and recent accounting when investigating access problems.
3. Review open installation orders, support tickets and network incidents.
4. Reconcile payments manually with invoice status while billing remains an initial register.
5. Check backup completion and available disk space.
6. Review available Core updates and schedule a maintenance window.
7. For connected Oxidized, verify recent successful configuration backups, not just that its container is running.

sudo systemctl status isp-core isp-core-panel isp-radius
sudo systemctl status isp-radius-sync.timer isp-core-update.timer
sudo journalctl -u isp-core-panel -n 50 --no-pager
sudo journalctl -u isp-radius-sync -n 50 --no-pager
df -h

These are diagnostic commands, not service reset commands. Review logs locally; do not publish credentials or full customer records when requesting support.

18. Troubleshooting

19. Release boundaries and references

Working: Core registration/users/updates, CRM and subscribers, managed RADIUS, separate subscriber self-service, initial business records, encrypted device login profiles and an opt-in local Oxidized source connector.

Not yet complete: live monitoring integration, automatic billing/payment processing, external integration execution, payroll, provisioning, CoA and hotspot vouchers. The connector’s software tests do not prove a successful backup from your particular router.

Implementation references: Oxidized source configuration, Oxidized SSH inputs, and Fernet authenticated encryption. The preserved installer archive and its verified checksum are documented in the project’s Network Monitoring provenance file.

Netmarga Administrator Manual · Core 0.5.7 · Updated September 24, 2026. Review and revise this manual when module behaviour changes.