Just got a new server? You will receive an email containing the details of the server and a separate email with the password for the 'admin' user (see below). Here's some extra information about it you may find useful. (Not all information will be relevant to your server. e.g. the Apache section is only relevant if you requested a web server. GitLab section is only relevant if you've been given a GitLab server.) See also the FAQs linked on the right.
Logging in to the server.
Log in to the servers is via SSH with University usernames.
Log in for the username of the person who requested the server is enabled by default. All usernames that can login are a made a member of the admin group, which has write permissions on /data and web server document root (where applicable). We can enable login for additional University usernames on request.
All servers are supplied with a shell user called admin that has the capability to manage web content (where applicable). This user is local, not tied to any University membership. It can be used for things which you want to do in a way which is not tied to any one person's username. E.g. if you have a script which is called as a cronjob and potentially needs to be modified by more than one person, you can put that script in the admin user's home directory and call it from the admin user's crontab. To switch to the admin user after logging in with your University username use
[u1234567@foo:test: ~]$ su - admin Password: [admin@foo:test: ~]$ whoami admin [admin@foo:test: ~]$
Where applicable there is also a database user called admin which can administer databases . When your server is set you you will be sent an email containing a temporary password for both these users.
As the server owner, all password reset requests will come through to your email account. We do not know this password and we will not ask for it. If you need to reset it, a simple call to the IT Services Helpdesk will generate a new password which you will be sent to the server admin contact.
It was previously possible to log in to severs directly with the admin user. Information on why that was changed can be found here.
SSH access is limited to the campus network. Access from off campus can be achieved by way of the VPN.
How can I upload files to my server?
Files can be copied to the server using SFTP or SCP. See also How can I upload files to my server?
N.B. Limitations on where SSH connections can be made from also apply to SFTP and SCP as they work over SSH.
Unless otherwise stated elsewhere servers have 1 CPU core, 2GB RAM and 10GB of disk space for customer content. These can be increased if required. (Increasing CPU cores or RAM requires the server to be briefly shut down.)
Servers are provisioned with two separate disks. One contains the OS and core applications, the other is mounted at /data and contains all customer content (home directory of the admin user and home directories created for any additional users for which log in has been enabled, web content, databases.)
Downtime and Patching
All servers have updates applied every Monday at a time between 04:00 and 05:30 and are then rebooted. The exact time varies by individual server each week to avoid all the servers rebooting at the same time and overloading the underlying infrastructure. You should take this in to account when scheduling cronjobs. If your server needs to stay up during these times, we can work out a maintenance schedule to suit you. Note however the server will need to be patched and rebooted at least weekly.
A snapshot of your server is taken nightly for the purposes of Disaster Recovery.
The DocumentRoot is
/var/www/html/ and this is where you should place your content.
HTTPS is enabled with a wildcard certificate that matches your server's hostname. We can also set up an additional .warwick.ac.uk alias and SSL certificate if required.
Single Sign-on integration is available on request.
You can apply configuration by way of .htaccess files (see note about php_value below).
Logs are in
PHP is invoked by way of PHP_FPM. This means that php_value can't be used in .htaccess
MariaDB/PostgreSQL is configured with one database called db1 to which the admin database user has complete access.
You can create additional databases (as the admin database user) however, it must begin with db (e.g. db_supersecretproject. This restriction makes it easier for us to back up any databases that may get created).
A daily cronjob runs mysqldump or pg_dumpall creating a backup of all databases at /data/my_backup.sql.gz or /data/pgsql/
Please note that root access is not provided.