SinLios Administrator Manual

1. Profile Scope

The SinLios Administrator installs and maintains independent platform instances for each customer. This role holds access to all panel functions and is the only profile authorized to configure:

• the software edition: Aula Control or Biblio Control;
• the commercial workstation capacity limit;
• available operational modules;
• optional Pusher real-time communication;
• the online documentation override URL;
• backups, restores, official updates, Cockpit migrations, and the public demo sandbox.

This profile is not intended for everyday center management. Following initial setup, at least one Center Administrator account must be created.

2. Pre-Installation Requirements

2.1 cPanel Hosting Requirements

• PHP 8.3 or higher.
• PHP extensions: pdo, pdo_sqlite, mbstring, intl, openssl, json,

ileinfo, dom, and zip.

• A domain or subdomain whose document root can point to control-platform/public.
• Write permissions for the PHP process in the storage directory.
• A valid HTTPS certificate for production environments.

Never expose the complete project root directory. SQLite databases, application keys, and installation locks must reside outside the public directory.

2.2 Provisioning the Environment

1. Create the customer subdomain in cPanel.
2. Upload and extract the official release archive outside public_html when feasible.
3. Configure the subdomain document root to control-platform/public.
4. Select PHP 8.3 or newer in MultiPHP Manager.
5. Verify that storage is writable. Typically 750 or 770 permissions suffice; avoid permanent 777 permissions.
6. Open https://subdomain/install.

If server requirements appear with red error indicators, resolve them before proceeding. The /health endpoint allows checking basic system readiness without signing in.

3. Initial Setup

The setup wizard runs only once. It prompts for:

• initial software edition: Aula Control or Biblio Control;
• visible product and center names;
• default language;
• brand theme colors;
• name, email, and password for the primary SinLios Administrator;
• initial workstation capacity limit.

The panel password must be at least 10 characters long. Use a unique password and record it in the SinLios team password manager.

Upon wizard completion:

1. Log in at /login.
2. Review SinLios → Service Configuration.
3. Enable licensed modules.
4. Open SinLios → Operations and generate the initial encrypted backup.
5. Create the first Center Administrator under Configuration → Management Team.

4. Commercial Configuration & Modules

Navigate to SinLios → Service Configuration.

4.1 Edition & Capacity

• Edition adjusts branding and operational terminology (educational vs. library focus) while preserving the identical underlying engine.
• Workstation Limit supports from 1 to 10,000 active workstations.
• Decreasing the limit below currently paired workstations will not disconnect devices, but prevents new pairings and reactivations until capacity is restored.
• Revoking an unused computer instantly frees up a license slot.
• Repairing a revoked device UUID reuses its identity, but also requires an available license slot.

Record all capacity adjustments in the client's commercial file. The system audits changes in the Activity Log, but this does not replace contractual documentation.

4.2 Modules

Modules govern which features exist in the client instance:

• Users.
• Workstations.
• Rooms / Classrooms.
• Applications.
• Time Control.
• Remote Control.
• Access Reports.
• Courses & Groups.
• Student Credentials.
• Shared Course Access.
• Bulk CSV Import.

Disabling a module hides and blocks its screens; it does not delete underlying data. Before disabling a module, confirm with the client which workflow will be discontinued.

4.3 Real-Time Communication

The recommended default mode is Adaptive Polling. It requires no cron jobs or resident background daemons and serves as a reliable standalone channel.

Alternatively, select Pusher + Fallback Polling and provide App ID, Key, Secret, and Cluster. Pusher accelerates notifications; SQLite remains the single source of truth, and clients operate seamlessly even if Pusher drops. The Pusher Secret is never exposed to client browsers or logged in the Activity Log.

4.4 Online Documentation

The platform includes the complete manuals built-in natively at /docs. If you wish to redirect the Help link to an external or custom website, enter a valid http or https URL. If left empty, the built-in documentation is used automatically.

5. Creating the Management Team

Under Configuration → Management Team → New Account, you can create:

• Center Administrator: Receives full operational permissions and can manage additional staff accounts.
• Manager: Receives only explicitly delegated operational permissions.

Panel passwords require at least 10 characters. Email addresses must be unique.

Delegable manager permissions:

1. Users and courses.
2. Desktop profiles and classrooms.
3. Workstations and remote control.
4. Reports and data export.
5. Activity log.

The daily time activation desk is accessible to all managers whenever the Time Control module is enabled.

Accounts are deactivated rather than deleted. It is impossible to deactivate the account currently in use. When editing one's own account, the role remains preserved.

6. Functional Commissioning

While the Center Administrator can finalize center setup, SinLios should validate at least one end-to-end workflow during commissioning.

6.1 Identity & Policies

In Configuration → Personalización, review:

• product and center names;
• language and time zone;
• default daily minutes and monthly allowance;
• client authentication mode;
• mandatory prior activation vs. automatic check-in;
• warning intervals, idle timeout, and stale session threshold;
• terms of use in Spanish and English;
• brand colors and logo;
• global Windows client security policies.

Changing the time zone changes the official operating day calculated by the server. Perform this adjustment prior to production go-live and confirm with center management.

6.2 Baseline Validation Workflow

1. Create an active, default classroom.
2. Create a secured application and a desktop profile containing it.
3. Assign the profile to the classroom.
4. Create a course and a test user.
5. Pair a Windows computer using a temporary code.
6. Grant daily time activation for the test user.
7. Log in via Aula Control Client and launch the application.
8. End the session and verify the log entry in Access Reports.
9. Verify that administrative steps appear in the Activity Log.

Do not enter real personal data during preliminary testing.

7. Workstation Pairing & Capacity Limits

1. Open Management → Workstations.
2. Select the intended classroom.
3. Generate a single-use pairing code.
4. On the workstation, open Aula Control Client and enter the HTTPS URL, pairing code, and device name.
5. The code expires in 10 minutes and is displayed only once.

If workstation capacity is reached, the server rejects new pairings without consuming the code. Revoke an obsolete device or increase license capacity according to contract.

A revoked workstation loses its authentication token immediately. To re-enroll it, issue a new pairing code. Never copy workstation identity files across machines.

8. Operations, Backups & Disaster Recovery

Navigate to SinLios → Operations. This screen is restricted exclusively to the Provider profile.

8.1 Production Diagnostics

Review PHP version, HTTPS status, public document root, private storage isolation, file permissions, SQLite integrity, pending database migrations, encryption status, and available disk space. HTTP is acceptable solely in local development environments.

8.2 Creating Backups

1. Enter a passphrase of at least 12 characters twice.
2. Download the resulting .acbackup archive.
3. Store the archive and passphrase in separate locations.
4. Keep at least one offsite backup copy independent of the hosting provider.

Backups encompass the database, encryption keys, installation locks, and user-uploaded media. Archives are encrypted using AES-256-GCM and cannot be decrypted without the original passphrase.

Recommended retention: 7 daily, 5 weekly, and 12 monthly snapshots, accompanied by quarterly test restores.

8.3 Restoring Backups

1. Select the .acbackup file.
2. Enter the corresponding passphrase.
3. Type RESTAURAR exactly as shown to confirm.
4. Allow the subsequent HTTP request to execute the restore process.
5. Re-authenticate if the current account differs from the snapshot.
6. Verify version, workstations, users, and perform a test session.

The platform verifies SHA-256 hashes and SQLite database integrity before swapping data, while keeping a rollback copy of the displaced state locally.

8.4 Installing Official Updates

1. Acquire the official package archive and SHA-256 checksum through verified SinLios distribution channels.
2. Generate and download an encrypted backup prior to updating.
3. Select the package, enter the SHA-256 hash, and type ACTUALIZAR.
4. The system creates a recovery point, verifies file manifests, replaces assets, and applies pending database schema migrations.
5. Inspect /health, review the diagnostics screen, and execute the baseline test workflow.

Never install identical or older version packages. A complete downgrade may require restoring data from an earlier backup.

8.5 Activity Log Retention

The Activity Log Retention panel reports total stored events, the oldest recorded timestamp, and estimated storage footprint. Initially, events are retained indefinitely.

To configure an automated retention policy:

1. Create an encrypted backup if complete historical records must be preserved.
2. Select a retention window: 90, 180, 365, 730, or 1,095 days.
3. Type RETENER.
4. Click Save & Apply.

Events exceeding the configured threshold are purged immediately upon saving. Afterwards, the system evaluates the policy at most once per day. For one-off purges, choose a cutoff date in Manual Purge, type PURGAR, and confirm: only records preceding that date in center local time will be removed.

Activity logs and access session reports are strictly decoupled. This maintenance task does not delete access logs or session metrics. Deletion frees SQLite internal database pages for reuse, although physical file size on disk may remain unchanged.

8.6 Migrating Cockpit CMS Installations

1. Suspend activity on the legacy installation and export all seven JSON collections from Cockpit.
2. Compress the exported JSON files into a single ZIP archive without altering them via spreadsheet editors.
3. Open SinLios → Operations → Migrate Biblio Control and click Analyze Export.
4. Examine detected totals and resolve duplicates, deleted user remnants, zero-duration sessions, and duplicate daily grants.
5. Confirm product edition, center name, time zone, initial classroom, capacity limit, and code-only login mode.
6. Create the Center Administrator account if not already provisioned.
7. Retain the recommended option to preserve historical identities, then type MIGRAR.
8. Download the migration summary report and verify users, applications, time grants, and historical access records.

The analysis stage executes in memory without modifying live data. Migration execution creates a recovery snapshot and runs within a single atomic database transaction; unexpected exceptions will not leave partial data. The uploaded ZIP remains stored in private storage and is purged upon completion. The administrator's password is never logged in reports.

Workstations do not carry over legacy access tokens. They remain pending by device name; when client computers pair using their previous computer names, they automatically inherit classroom assignments, desktop profiles, idle timeouts, control buttons, application termination rules, and folder cleanup policies. Conduct a pilot test and maintain Cockpit in read-only mode until final validation. Refer to docs/COCKPIT-MIGRATION.md for exhaustive migration rules.

9. Public Demo Sandbox

Public demonstration environments must operate on isolated test instances, never within production customer deployments.

1. Provision a dedicated subdomain with fictitious seed data only.
2. Under Operations → Public Demo, specify the public demo credentials, reset interval (typically 24 hours), and type DEMO.
3. The platform constrains workstation capacity to a single device, removes prior identities, and generates a baseline snapshot template.
4. To guarantee automated resets without requiring web traffic, schedule ools/demo-reset.php every 15 minutes via cPanel Cron Jobs.

Reset Now triggers an immediate rollback on the next request. Disable Demo restores regular operation, but does not render the test database suitable for production use.

10. Windows Client Security Architecture

• Maintain a dedicated local administrator recovery account.
• Use a dedicated standard Windows user account for Aula Control.
• Since version 1.1.4, the client prohibits replacing the Windows shell on administrator accounts.
• Universal Protection: The normal path writes silently to HKEY_CURRENT_USER, retains a reversible snapshot, does not run PowerShell, and needs no elevation. It does not make the profile mandatory.
• Mandatory User Profile: This is a separate, optional measure. kiosk/Configure-MandatoryProfile.ps1 can convert NTUSER.DAT to NTUSER.MAN while the target account is completely signed out; the advanced layer can schedule conversion through MoveFileEx for the next restart. Keep a recoverable copy and validate enable and rollback on a pilot computer.
• File Cleanup: When enabled, the policy removes the configured profile folders and covered public locations. It is destructive, does not guarantee a completely immutable workstation, and does not replace Deep Freeze or a full system-restoration image.
• Test applications and recovery procedures prior to applying full lockdown.
• Configure an exit PIN distinct from student access credentials.
• Universal lockdown operates reliably across modern Windows editions (Home, Pro, Enterprise).
• Replacing the user shell works on modern Windows editions. Shell Launcher and Keyboard Filter belong to the advanced layer and require a compatible edition, normally Enterprise, Education, or IoT Enterprise.
• Aula Control does not intercept Ctrl+Alt+Del.

Emergency maintenance key combinations must be restricted to authorized technical staff. Consult docs/WINDOWS-SECURE-ACCOUNT.md prior to large-scale fleet deployments.

11. Troubleshooting & FAQ

The setup wizard reappears or reports non-writable storage

Verify directory permissions for storage, ensure proper PHP process ownership, and check the web server document root. Never move SQLite into the public web root.

A new workstation cannot pair

Check pairing code expiration, ensure the target classroom is active, verify the HTTPS URL, and check available license capacity. If the device appears revoked, generate a fresh pairing code; if license capacity is full, revoke unused machines or expand capacity.

Status updates or commands experience latency

Fallback adaptive polling may introduce a brief delay. Verify that the client computer is online. When utilizing Pusher, validate credentials while ensuring fallback polling remains enabled.

Daily time activation calculations appear incorrect

Review the center time zone configuration. The workstation's local clock does not govern official server time.

A backup encryption passphrase has been lost

Encrypted backups without passphrases cannot be recovered. Immediately generate a new backup with a known passphrase and document its secure custody.

An update process fails to complete

Do not manually overwrite application files piece by piece. Review diagnostics, server error logs, and the local recovery point. If database schemas have already migrated, restore from the pre-update backup snapshot.

12. Customer Handoff Checklist

Before concluding the installation:

• [ ] HTTPS connection and /health response verified.
• [ ] Initial backup generated, downloaded, and secured offsite.
• [ ] Edition, active modules, and workstation capacity confirmed.
• [ ] Center identity and time zone configured.
• [ ] Center Administrator provisioned and login verified.
• [ ] Classroom, desktop profile, application, and test user validated.
• [ ] First workstation paired and tested.
• [ ] Help section and documentation links confirmed.
• [ ] Administrative credentials delivered via secure channel.
• [ ] Test data cleared or clearly designated.

Back to Documentation Index