Delivery document Linux Server

From LUG
Jump to navigation Jump to search

Dear new client of a WUR server,

You have chosen a Red Hat 7/Ubuntu 16.04 LTS operating system. As linux management team, we are deeply happy that you have chosen for open source. Through the use of this document we would like to clarify the management rules and help provide you with some guidelines for the configuration of your system. This is additional information to Appendix 6 from the service catalogue.

Support: Please send a mail to and request a ticket for Infra Linux Beheer. We always strive for a quick solution time, but we can guarantee to keep by the standard service commitments.

Configuration: We use a configuration management system to administer parts of the OS so that we can centrally administer many of our managed servers. This allows us to maintain consistency and reproducibility between servers. Changes that you make to these files will be reverted automatically by our systems. The configuration files that are managed by us are clearly marked in the first or second line. A detailed list of these files you can find here. If you need to change the contents of these files, please send a mail to servicedesk to request a ticket.

The two most significant issues are highlighted:

  • selinux is always on. (on Red Hat systems) This is an advanced management system to improve security on our managed systems, preventing processes from being able to access files they were not allowed to access. For custom or non-standard builds, this can cause issues with deployment. Please let us know if you are having issues and we will be happy to assist you to have a working and safe environment.
  • Firewall is managed by us. The firewall is initially set as very closed, and is configured entirely by our config management tool and is not locally editable on a permanent basis. Please request a ticket to enable access to ports as needed for your environment.

Monitoring/Statistics: We provide access to our monitoring and statistics tool Zabbix as standard. By default, it is configured so that users of the server may log in to the service and administrators will get alert notifications in the case of serious issues, for example, if the disk space has run out. There are many more configuration options available, accessible at . We have several standard monitored services - see here for a list. For further monitoring or custom monitoring, you will have to configure these yourself. If you need assistance, that's no problem - we have several use cases to hand to be able to assist you with setting this up. Additionally, Zabbix provides statistics on all monitored servers. Every service can be displayed as a graph against time, for example as below, the memory usage:


Updates: We perform regular updates on systems in a coordinated fashion. Every third Tuesday of the month at 21:00 we update all production machines, and at 10:00 on the previous Sunday the OTA machines. We have an automated system to manage this, and you will be asked at server request which update slot your wish your server to be assigned to. If you can't use either of these times, a special maintenance window can be created for you - simply make a request for further information.

Vulnerability scan: Every month we do a security scan on all servers to search for (new) vulnerabilities. We use Nexpose for this task, and every month once this has been done you will receive a report about it. Solving problems related to core services falls under our responsibility, however you are responsible for the security of software that you have set up yourself. In doubt, you can always ask for an appointment with one of our security specialists. We have the optional security scanned Appspider available for scanning websites for vulnerabilities. It is freely available for your use - if this is of interest to you, please create a ticket or contact your service manager.

Packages: On Linux, most software is available in package form from standard repositories via yum or apt. We prefer installations from here, as it means that security updates are automatically installed as needed once a month during our standard update window. It is possible to add custom repos for certain applications that have them provided, to be able to gain access to versions younger than are provided by the OS, but be advised that these will be updated once a month as well. Manual installation is not preferred, but if it's really necessary then please let us know - we would like to help you have a maintainable, secure system, and maybe we can help you find an easier route to this.

Webserver: You may request an official SSL certificate for to secure your website via HTTPS. SSL-secured websites not only improve security, but they improve your rankings with Google. Our official WUR advice is that all websites should be secured in this fashion -again, if there's a reason not to, please let us know. If there is sensitive information (medical data, tax data) on your site, then please request an appointment with a security specialist to help you with additional security measures. You can request a memorable name for internal websites (<name> or external websites (<name> for free with a ticket to servicedesk. In general, we prefer to have a separate DNS name per project to allow for further expansion - directly referencing an scomp name for access makes it difficult to repair or replace components in the future.

Storage: Your system disk has a standard format, xfs or ext4. This should be sufficient under most cases, but if you wish to change this, this is a possibility.

Additional: If you are going to build/install a custom application, we would like you to do this in /opt, as this has been specifically enlarged for this purpose. If there's not enough room, or you need some custom storage, you can request extra storage from us. If you are going to do maintenance on your server yourself, then you should be aware of the custom script create_downtime. You can use this script from any managed server to let Zabbix known to temporarily halt monitoring this server, and so we don't get alerted about servers being temporarily restarted at odd times. By default, this script will request one hour, but you can request more or less than this. For example:

create_downtime 120

will put the server in maintenance for 2 hours.

More information:

Here on the wiki you can find technical procedures for connecting machines to other WUR systems. There is also an intranet group “Linux en Open Source” that news and questions may be asked in.