When you sign up at Moss, you're either creating a new organization or joining an existing one. In the first case you're the admin of the organization, in the latter you're a developer.
Developers can create, deploy and monitor sites, and manage all related resources, e.g. databases or non-privileged server users.
Admins have full access to their Moss account. Hence, they can also add, manage and monitor servers, privileged server users, and any other resource in Moss.
A privileged server user is one that can become
sudo. Moss creates one such user automatically on your servers:
moss. The admin can log into the servers as
moss to run administration commands that require
Sites cannot be run by a privileged server user, because that poses an unnecessary security risk. Instead, usually you want to have a different (non-privileged) server user running each site on the server. E.g. user
app in the following screenshot.
Moss helps you manage different resources: servers, sites, server users, databases, database users, cron jobs, workers, firewall rules, and the like. These resources are organized in workspaces so that you can easily differentiate among environments, clients and/or teams.
Every resource has a status:
- Ok: Moss successfully set up the resource
- Error: Moss couldn't set up the resource
- Pending: There's some pending operation to perform on the resource
- Setting up: Moss is setting up the resource at this moment
- Deleting: Moss is deleting the resource at this moment
Servers have additional statuses. In any case, Moss doesn't shows anything special when a resource is ok. However you'll see some kind of indication when there's an ongoing operation on the resource or it's in "error" status:
To easily identify servers in "error" status, you'll see a warning sign next to them too:
You can run actions on your resources to achieve a given objective.
High-level resources like servers and sites have a dropdown menu with their available actions:
Other resources like databases and cron jobs have an array of available actions embedded in the table where they're listed:
The Set up action is common across all resources. If a resource is in "error" status because of a temporary failure, you can set it up again to try to fix it. You can also set up a resource which is "ok" - usually this is not necessary, but it's not a problem because we design our operations to be idempotent.
In effect, actions may trigger operations on your servers.
If Moss needs to connect to a server to run some commands, then it's an operation. You may check the operations that have taken place in the workspaces you belong to and access their full logs.