Initially, there are three user accounts you can log into: 'root',
'toor' ('root' spelled backwards) and 'bigboss'. Of these three, only
the latter is an unprivileged, normal user. The other two are
superusers. All three accounts have the password given to you when
the box was created. So, if you want to change it, you may want to do
that for all three accounts.
Note that, after assigning and giving you the initial password, we
dispose of that information and also do not store any of your future
passwords anywhere. So if you happen to forget it all we can do to
help you out is set a new one.
Writing down a password, on the other hand, is also not too good an
idea since this way it can get in the wrong hands. We suggest to
use the preinstalled program 'apg'. It generates a bunch of
pronounceable, yet dictionary attack proof passwords. Pick one
you like, possibly running 'apg' repeatedly.
Of the initally existing accounts, 'bigboss' is an example user
where you can study how things are done in this system. However,
we suggest that you leave it intact since certain resources belong
to that user, for instance the web area and the "Server Box Information
Area" you can access via a web browser. And email to system accounts
goes to 'bigboss' as well. We consider it, as the name suggests, the
non-privileged system owner account.
We recommend to check bigboss' email from time to time since the
periodically generated status reports about the health of your box
end up in that email folder (IMAP). Alternatively, by means of a
'.forward' file you can also have the system send the status messages,
or rather email to any relevant system account, to some other email
address.
To add your own user accounts, run 'adduser'. It asks you a couple of
questions about the user's preferences. Answer them and the account
will get created. It is populated with a number of initial config
files that the respective user can modify to meet his needs.
If you would like to change some properties in '/etc/passwd' later on,
never edit this file directly. It is just an automatically generated
excerpt from the actual user password database, '/etc/master.passwd'.
However, do not edit this file directly, either. Use the command
'vipw' instead. It makes sure that all files involved stay in sync.
On the other hand, changing the group file '/etc/group' (the counterpart
of '/etc/passwd') is straightforward. Just edit it with your favorite
editor.
|
|
|
Services that do not run as user 'root' for security reasons, like the
email, news, web and IMAP server daemons, have one apparently invincible
problem with authenticating users: they cannot access the encrypted
password of the respective account since only user 'root' can do so.
We solved this problem by integrating a radius server which runs as
user 'root'. Its sole purpose in life in our setup is to act as an
authentication proxy for unprivileged services. This way all of our
preinstalled services can, where applicable, authenticate users
without the need to scatter additional password databases all over
the system. Just create the necessary user accounts, and all services
can use them for authentication. You may need to add the user to access
control lists (ACLs) in the respective service's config file in order
to fine-tune who is allowed to do what, but you do not need any extra
password files.
If a user should be able to use some of the services where authentication
is necessary but you do not want him to actually get shell access to your
box, give him a home directory of '/nonexistent' and a shell of
'/sbin/nologin'. Most internal daemon users are protected the same way.
Please note that radius servers cannot deal with
passwords longer than 16 characters. So if you would like user accounts
to work with any service, that is, not just shell logins, we recommend
choosing passwords that are no longer than 16 characters.
|
|
|
FreeBSD distributions come with filesystem quotas
disabled by default because this feature is rarely used. On the other hand,
when you need filesystem quotas you are likely to need them badly.
Likewise, our server boxes have filesystem quotas
disabled by default, too. However, in case you would like to use
them please contact our support. In order to enable filesystem quotas for an
individual box we have to temporarily shut it down and re-mount its filesystem
container. This will take only a couple of minutes at max. Once enabled,
quota management from inside a server box takes place with the expected
commands, namely quota(1), edquota(8) and repquota(8).
|
|
|
|
