technical:hosting_operations

Existing hosts: updates and support

This reference is for operators who already have an installation. New hosts should contact Papapyrus for onboarding files first. Use the current instructions supplied for your installation; old version-pinned repair helpers are not general installers.

Updates

Keep the same installation, authorization, catalogs, titles, tuning, enrollment, ratings and statistics. Healthy opted-in hosts receive signed updates through their saved policy. Compatible worker updates wait for individual rooms to empty; shared-controller updates wait for all configured rooms on that host.

Use the installed release's protected operator entry and its exact instance. An entry from an older release may intentionally refuse after upgrade. The operator command reference explains the available actions; these are machine-side commands, not player dot commands.

A temporary preparation refusal in a healthy room can defer and retry an update in current releases. A deliberately stopped host, uncertain ownership or a failed cleanup retains its separate checks. Publication does not force a stopped host to start. See update windows and maintenance.

If something goes wrong

Keep the installation state and reports, and contact Papapyrus. Send room links, times and timezone, the installed version, what players experienced and redacted support output. Include the safe failure code, failed operation and HTTP status when available.

Do not reinstall, delete journals or repeatedly start rooms to bypass an uncertain outcome. Recovery instructions must match the exact failure and release. A failed systemd unit and uncertain room ownership are different facts. The version-pinned packages in old release notes apply only to their documented states.

Never send passwords, OAuth credentials/codes, token files, bound invitations or raw backups. Keep unredacted evidence locally.

Sharing and privacy choices

Onboarding explains directory listing, public statistics, shared map ratings, diagnostics and update policy. Existing explicit opt-outs remain effective. Public directory listing does not publish passwords or private room rosters. Diagnostic reports are private maintainer records, separate from public player statistics.

For an existing host, network-reporting-configure accepts all four reporting choices through the current kit's protected standard-input schema. To disable all four:

{"share_statistics":false,"consume_statistics":false,"operational_logs":false,"public_chat":false}

The choices can be configured separately, but public_chat requires operational_logs. Use network-reporting-support to inspect pending changes. Leave the network agent running until a requested central withdrawal is acknowledged; an unavailable hub can delay that acknowledgment.

Ratings are separate: ratings-configure with {“share_ratings”:false} disables contribution, and ratings-reader-configure with {“mode”:“independent”} selects independent local feedback. Follow the current kit's full schema and invocation. Statistics consumption is bound when a worker starts, so a change can require its next safe replacement.

Historical player data is not automatically approved by enabling sharing. Reviewed public-room history follows its own installation-bound procedure. Local capture, hub acknowledgment, cache availability and website publication are separate stages.

Useful checks

  • status / support — installation, room and recovery summaries.
  • network-support — enrollment and heartbeat.
  • ratings-support — locally captured, queued and acknowledged feedback.
  • network-reporting-support — activity/diagnostic reporting.
  • update-status — discovery, waiting, installation or a held update.

Use ownership-review only under the stopped-service conditions required by your kit. Ask Papapyrus before attempting unfamiliar recovery operations.

Hosting overview and contact · Operator commands · Privacy · Release history

Managed administration and updates

Published v7.2.9 provides authenticated central administration for managed public and private rooms. Authorized staff use the private fleet-control channel; public lobby channels never accept fleet commands. Requests carry durable IDs, installation/generation bindings and configuration revisions. Only the hosting operator can change the concurrent-room ceiling, default four.

Explicit stopped intent survives updates, recovery and reboot. Live-safe settings apply without recreation; changes requiring recreation affect the target at a safe boundary. This controller release still requires the host-wide safe empty/idle update gate. Keep settings, authorization, catalogs, enrollment and history; do not reinstall or clear ownership to force updates.

Managed participation includes shared ratings/statistics, staff-only diagnostic/chat reporting, automatic updates and central room administration. These have no separate in-product opt-outs in migrated managed hosts. Older hosts retain legacy behaviour until upgraded. Private-room information and credentials remain excluded from public projections. Full owner map exclusions are mirrored into compatible signed feeds; only map IDs leave private moderation records.

Discord cards retain artwork, maps, settings and players without map progress; website progress remains. See release notes and qualification limits, currently running rooms and the matching GitHub installer guides for exact protected operator commands.

Private fleet controls

The private fleet channel is enabled. Administrators can begin with .fleet hosts, .fleet status owner and .fleet settings owner room2. Hosts on older releases report unsupported capabilities until their safe update completes. Opening, closing, restarting or changing a room remains an explicit staff action; status checks do not mutate rooms.

Compact central service kits must include the native mode validators and default greetings; the v7.2.9 central packaging repair and corrected source builder cover this dependency closure. Client runtime digests and the existing signed update queue are unchanged. If a deployment holds on local process cleanup, retain the exact operation and ownership state for the bounded native recovery path rather than reinstalling or repeating room creation.

v7.2.12 first-successor activation

On affected v7.2.9/v7.2.10 installations, the first successor can hold during root preflight before any native update is submitted. Use the pinned v7.2.12 queue-only activator with the existing instance, following the checked instructions. Do not reinstall, repeat OAuth or clear ownership. The older v7.2.11 activator can safely refuse an unnecessary intermediate selection; use v7.2.12 instead. waiting_empty means queued rather than installed. Keep the normal updater running; no occupied rooms are forced closed. Return any refusal and retain state.

The release includes guarded local .stats access, Catch statistics downloads and private participation in player totals. See release notes and qualification limits.

For v7.2.12 use poolrotater-activate-v7.2.12-v4.py and its matching .sha256 file. Revision4 also arms the checked native timer; earlier activators are retained for history. Return the final JSON, including timer_armed, rather than manually restarting rooms.

technical/hosting_operations.txt · Last modified: by wikiadmin

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki