Users

planejadoPlanejado para o WardPane 2.2. Este recurso não está na versão atual; a página descreve como ele deve funcionar. Roteiro

WardPane 2.2 will have users the way ISPmanager does. People sign in to the panel with their Linux account on the server, and each of them sees only their own sites and the sections root has allowed. One server can then host sites for a team, for clients or for separate projects, and nobody sees the others’ sites.

Signing in

Users sign in to the panel with the user name and password of their operating system account on the server. There is no separate panel password: when the password changes on the server, it changes for the panel too.

The panel itself never runs as root and cannot read /etc/shadow. A small root helper checks passwords through unix_chkpwd, the same program PAM uses; passwords are never written anywhere or logged. Repeated wrong passwords are slowed down and then blocked, with the same limits as every other sign-in to the panel (see Security notes below).

What a user sees

A regular user sees:

• the sites they own, and nothing of other users’ sites;
• the parts of the panel root has granted them (permissions are set per user by root);
• their own databases and mail, where root allows it.

New users start in Simple mode, which hides advanced fields and explains settings in plain words. Each user can switch to Expert mode, and the server remembers the choice.

Admins

Root and members of the sudo group are admins. They see every site and every section, manage users and their permissions, and change the panel settings.

An admin can also log in as a user without knowing the user’s password. The panel then looks exactly as that user sees it, which helps when fixing their site or checking what they are allowed to do.

Owners and sites

Every site created in 2.0 belongs to an owner, which is a Linux user. The site’s files live in the owner’s home:

/var/www/<owner>/data/www/<domain>

The default owner is www-root, a Linux user that WardPane creates. If you run the server alone, all your sites can belong to www-root. Root can create more owners and give each of them their own sites.

PHP and Node.js run as the site’s owner, so the owner can manage the files and apps of their sites from their own shell (for example pm2 list and pm2 restart <domain> for Node.js apps). See Shell client and Node.js.

Sites from before 2.0

Sites created before 2.0 (including those from Small Web Panel 1.x) keep their old layout in /var/www/<domain>, and their PHP runs as a per-site Linux user named wp_<id>, with the comment “WardPane site”. WardPane owns these accounts, so do not use them for anything else. A later release will add an action that moves such sites to the new layout one at a time.

The emergency login

Besides the server accounts there is the panel’s own login from /opt/wardpane/.env (PANEL_USER and PANEL_PASSWORD). In 2.0 it is the normal way to sign in. From 2.2 it becomes an emergency login, off by default, meant for the case when signing in with server accounts does not work.

If you are locked out of the panel, these tools still work over SSH:

sudo node /opt/wardpane/bin/unlock-login.js                  # lift all sign-in blocks now
sudo node /opt/wardpane/bin/unlock-login.js --reset-access   # take name, password, PANEL_ALLOW_IPS and ROOT_LOGIN from .env again
sudo systemctl restart wardpane

--reset-access removes these values from the panel’s saved settings (the previous file is kept as settings.json.before-reset-<time>), repairs an unreadable settings file and lifts the sign-in blocks. For the password, PANEL_PASSWORD must be set in .env. You can reset one thing only, for example --reset-access=allow-ips.

Security notes

• The panel is reachable from the internet, so server passwords that can sign in to it should be long and random. You can also limit access to the panel by address with PANEL_ALLOW_IPS (in Settings > Panel access or in .env), and other addresses will not even see the sign-in page.
• Sign-in attempts are limited: by default an address (for IPv6, its /64) is blocked for 15 minutes after 5 failures, and a wave of failures from many addresses closes sign-in for addresses that have not signed in before.
• A panel session lasts at most 12 hours and ends after 2 hours without activity (SESSION_HOURS, SESSION_IDLE_MINUTES).