Reseller RFC

Feature Request
, , ,
1

A preview of the Reseller will launch by the end of this year. As it’s starting to come together in development, it’s easier to design for features now rather than design in features at a later date. I’d like to leave this post open for folks to solicit their ideas going forward.

First, a quick overview of how it works:

API

  • Introducing AddReseller, DeleteReseller, EditReseller, SuspendReseller, ActivateReseller commands that complement the existing *Domain commands.
  • API commands namespaced in admin module, (admin:add-reseller, admin:edit-reseller, etc).
  • New API module, reseller will mirror admin module; these are the API signatures for resellers to add sites (reseller:add-site, reseller:edit-site, etc).
    • Following mirror logic, reseller:add-reseller would be possible for nested resellers to be implemented at a later time.
  • New $rgroup property is set for user contexts. This designates a Site/User Administrator under a reseller group or a reseller itself if $site property is null. Everything else is transparent internally.

Layout

  • Sites remain familiar siteXX naming and will be virtually indistinguishable on the surface. Reseller groups follow the form groupXX. Sites are physically located within /home/virtual/groupXX with symlinks for siteXX to /home/virtual. This is structured for backup flexibility. For example:
    drwxr-xr-x  28 root root 4096 Nov 25 00:54 group1
lrwxrwxrwx   1 root root   31 Nov 25 00:54 site52 -> /home/virtual/group1/site52
lrwxrwxrwx   1 root root   31 Nov 25 00:54 testast123.tast -> /home/virtual/group1/site52/fst
lrwxrwxrwx   1 root root   31 Nov 25 00:54 admin52 -> /home/virtual/group1/site52/fst

UI

  • Reseller logins will be similar to admin, i.e. without domain. No reseller login may duplicate an admin username.
  • Rough release will be a watered down admin interface with Nexus as the main entry page.
  • All domains have SSO.
    • Likewise, admin may SSO into a reseller or site directly.

Resources

  • Both storage and cgroup operate in real-time and may be overcommitted or reserved. These are implemented as project quotas and hierarchies respectively.
  • Total resource utilization may never exceed reseller limits. Additional resource consumption is rejected automatically by the kernel.
  • Bug exists in 4.x and 5.x kernels with overlay descendent buildups when project quotas are enabled. Waiting on Red Hat to backport it (RHEL-68854). I have workarounds in place as I’m building this out.

:books: Consider 10 GB storage, 512 MB memory. Reseller “A” (group1) consists of sites: site1, site2, site3.

Overcommit mode

group1 assigns 8 GB to site1, 2 GB to site2, and 5 GB to site3. Memory is assigned as 256 MB, 256 MB, 256 MB. Both storage and memory are reported as “dynamic”, which indicates the limit may fluctuate based upon neighboring usage.

image

Reserved mode

Follows conventional allocation with cPanel and company. Resources may not be allocated beyond what’s assigned to reseller.

group1 assigns 8 GB to site1, 2 GB to site2, and 5 GB to site3.
:x: this is a violation. 10 GB has already been allocated. Likewise “dynamic” flag is not set.

Memory is assigned as 256 MB, 256 MB~~, 256 MB~~.
:x: this is a violation. 512 MB has already been assigned. Likewise “dynamic” flag is not set.

Ergonomics

  • admin:bless, reseller:bless mode allows splitting an addon domain/subdomain to its own account.
    • Blessing a domain temporarily defers mail delivery for the source account through a new Postfix transport called maintenance. This is a temporary, non-permanent 4xx status.
    • Site traffic for migrating domains/subdomains is temporarily rejected (503 status). Any Web Apps installed within these locations will also be migrated/reconfigured on the new account.
    • In overcommit mode, resource allocations is a straight copy otherwise the resource chunks will need to be defined in reserved mode for resellers. For admin blessing a site, it’s a straight resource copy.
  • Notifications are stored in sqlite databases for each user under info/users/.db/. This is still fluid - but looks like we’ll be using this for storage. Reseller can dispatch notifications to its users as can admin system-wide.

Anything else I’m missing thus far?

2 Likes
2
  1. What is needed to perform a full backup & restore of reseller data? (Bacula & standalone backup solutions need to be updated to include new stuff, pls guidelines thx)
  2. Can smart-hosts be configured per-reseller?
  3. How much flexibility will reseller have? Can they check logs (without logging as user) and do pseudo-sudo-like operations?
  4. How would reseller migrations look like? Would it be possible? Is it in current scope or will be later? Has it been tested?
  5. Can we update docs adding terminology: admin = server, reseller = app superuser(-ish), user = app user / reseller client or whatever best fits?
  6. Can reseller receive quota notifications too?
1 Like
3

Following Anatoli’s question count:

  1. What will the “migration”/“import” of reseller accounts look like when importing “reseller” accounts from a cpanel server?
  2. Can the notifications be done via mysql/mariadb instead? This would “tie in” more neatly with how apiscp currently stores data. If not, what was the reason behind the design decision?
  3. Will we get a “visual plan editor”, as that seems like a requirement for resellers to effectively use apiscp.
  4. Can DNS backend be configured per reseller?
  5. How will Reseller DNS Lists/Settings be isolated/Split from the Server ADMIN (if using a dns cluster (powerdns) type of setup)?
  6. Can Accounts be “unblessed” and assigned/moved to to a reseller(s) account?
  7. What do account transfers between two reseller accounts look like?
1 Like
4

Everything continues to remain under /home/virtual. Sites created will be within /home/virtual/groupXX/siteXX. To backup (or not backup) a reseller, include/exclude /home/virtual/groupXX from the mix.

groupXX will become a valid marker for en-masse selections, e.g. SuspendSite group1 would suspend the reseller and transfersite.php -s SRV2.DOMAIN.COM group1 performs similarly.

Appliance Administrator: root
Reseller Administrator: resellers (superusers)
Site Administrator: account administrator
User Administrator: least-privileged users of an account

That’s part of the plan.

I’ll need sample backups from cPanel servers to evaluate how to best approach it.

How is a notice logged to MariaDB if MariaDB is down?

Panel data is primarily stored in PostgreSQL as MariaDB isn’t nearly as reliable. Some elements of the panel still use MariaDB, but those are for historical reasons. Storing messages in a sqlite file allows for easy transfer to new servers - without replaying the messages - as well as charging storage to the account quota. Initially I looked into LMDB that’s a pure key-value storage engine but query support is required otherwise it’s cumbersome to have message classes/auto-expiration TTLs. Likewise, preferences must be ported to another backend that supports concurrent writers; this provides preliminary testing.

Anything in particular to build into this design? Plan editor would be available to both Appliance and Reseller Administrators.

Three approaches: catalogs (zone templates), accounts, or comments. Catalogs require PowerDNS 4.7+. Accounts and comments work similarly with accounts having a 40 char limit while comments are variable length. I added comment support to zones in March. Accounts/comments can be expanded to include the reseller’s billing ID (“invoice”) per zone, which gives enough information to work backwards.

Move the folder /home/virtual/groupXX/siteXX to /home/virtual/groupXY/siteXY + /sys/fs/cgroup/groupXX/siteXX to /sys/fs/cgroup/groupXY/siteXX. Site ID remains the same but the parent directory, which correlates to cgroup + xfs project hierarchy changes to reflect the new reseller; a minimal move.

5

Ohh wow. Great to see some improvements even though I doubt I’ll use this feature extensively. More important for me in this context is whether there will come along rhel9 support.