Building packages and applying them

A package is what a customer may use: how much disk space, how many websites, and which parts of the panel come with it. You build it once and then put customers on it.

The most important rule on this page comes first, because it is different from most panels: changing a package changes no account at all. You save the package, you then look at what that would mean for your customers, and only when you press Apply does anything happen on the servers. There is no button that quietly moves two hundred customers at once.

The three kinds of limit

The builder shows a summary at the top in three columns, and those columns are not decoration — they say what happens when a customer reaches a limit.

• Server enforces. CPU, memory, disk space, number of files and PHP workers. These are a cgroup slice, an FPM pool and a filesystem quota on the machine itself. Going past them is not "refused", it is impossible.
• Panel counts. Websites, databases and mailboxes. The server has never heard of a package; the panel counts these before it makes the call that would exceed them, and refuses that call with a plain message.
• Measured only. Bandwidth. This is counted and reported and never cut off: nothing on the server stops a website halfway through the month, and a package that claimed otherwise would be lying.

Throughout: 0 means unlimited. To say "no websites" or "no mail" you use the switches in the Features section, never a zero.

Building a package

1. Go to Packages in the sidebar and press Create package.
2. Choose the kind. A customer package applies to one hosting account. A reseller package applies to a whole group and is counted over the sum of their accounts — that is an administrator setting and is covered below.
3. Fill in the sections: Resources, Counts, Features, PHP, Mail.
4. Watch the summary at the top while you type. It follows what you enter.
5. Press Save package.

The kind is settled once the package exists. If you want the other kind, make a new package — the same numbers mean something completely different on a reseller package, so switching would re-interpret every figure on it.

The Features section has nine switches: mail, FTP, DNS management, databases, SSH, cron, SSL management, backups and statistics. Switch one off and that section is not drawn in the panel for that customer, and the API refuses it as well. That is how you build a mail-only package.

Rolling a change out to existing customers

After saving, press Review changes. That screen puts, per account, what is in force now beside what the package says today, field by field:

Disk (MB): 10240 MB → 20480 MB Mailboxes: 10 → 25 SSH: On → Off

Accounts labelled Custom hold a deliberate exception — somebody once set a different number there on purpose. A bulk apply skips them. That is not a bug: an exception somebody made is not noise for the next package change to tidy up. If you do want such an account back on the package, go to the account itself, open the Settings tab and press Back onto the package.

A Temporary until … label is a different thing. That account follows its package and holds a temporary increase on top of it that expires on its own; a bulk apply treats it like any other account.

The button says how many accounts it will touch: Apply to 2 account(s). That count already excludes the skipped ones.

When a server refuses

If something goes wrong during an apply — a server is unreachable, or an account is no longer on it — you get a conflict report and nothing has been applied. Not "most of it worked": nothing. The panel checks every server first, and only starts changing anything once they have all answered.

That is deliberate: half your customers on the new package and half on the old one is the one state you cannot get out of without going through them one by one.

Reseller packages

A reseller package caps a whole group. Beside the ordinary limits it has:

• Maximum number of accounts — a hard cap. Overselling never applies to it.
• Dedicated IP addresses, and whether customers may use the shared server address.
• Features this reseller may pass on — a customer package can never carry something that is switched off here.
• Own nameservers.
• Allow overselling, on by default.

Overselling on means: the sum of what has been handed out may exceed the ceiling, and the ceiling is enforced against what is actually used. Overselling off means: the sum itself is the limit, and an assignment that would break it is refused at the moment you make it.

If you lower a ceiling below what has already been handed out, one of two things happens depending on which kind of limit it is. For disk, bandwidth and IP addresses the change is accepted and flagged as more handed out than the ceiling: existing customers keep what they have, and new assignments are refused until the ceiling goes back up. For the maximum number of accounts the change is refused, with the affected accounts named; there is a separate confirmation if you want it anyway.

Only an administrator can change a reseller package. A reseller can see their own ceiling — it is what limits them, so hiding it would serve nobody — but cannot edit it.

From the command line

The same thing, without a browser, on the panel server:

# every package, both kinds
corecp-panel packages --list

# one package, resolved, with where each value came from
corecp-panel packages --show Business

# what applying it would change — this writes nothing
corecp-panel packages --diff Business

# apply it; custom accounts are skipped
corecp-panel packages --apply Business

# what a reseller has handed out in total, and what is being used
corecp-panel packages --reseller north-hosting

--apply exits non-zero when there was a conflict, so a script in a maintenance window stops instead of reporting a conflict report as success. Add --dry-run and it only prints the diff.