Become Part of our Team and Push Digital Sovereignty
- Teamleader IT / Project Manager (m/f/x)
- IT Consultant (m/f/x)
- Outbound Sales Represantative (m/f/x)
Have you ever thought?: “It’s enough! I finally want to set up my own robust, powerful server at home to put an end to the permanent threat that someone might hack my precious data.”
I did! And today, I’d like to share with you here all the necessary steps that are required for this. In addition to UCS, my home server scenario also includes a software bundle made up of groupware, mail, and file exchange software, i.e. ownCloud and the Kopano apps. This bundle make proprietary mail and groupware solutions redundant if you like. In addition, I also show you how to install Let’s Encrypt so that the connections to your UCS server will be well protected, too.
Basically, private users confront the same questions as enterprises: „Shall I run the server on my own hardware, in my own “IT center” (or storeroom), or shall I run it on a rented system, hosted somewhere, e.g., a “dedicated server” with a cloud service provider. Before you decide, it is important to ask yourself how you actually intend to use the server.
A rented system involves a small initial investment and is not usually associated with significant bandwidth restrictions. On top, it is easier to adjust it to your requirements. A rented system is practical when you need access from different locations, e.g., when the server is used by all members of your organization who might work somewhere else.
If you run a system on your own network, it first offers you full control over your own data and also supports additional application scenarios such as a standard file server or the streaming of music and videos to local media players. However, the dependence on a private Internet connection often is a bottleneck when you want to access the system from outside; even the very latest VDSL connections come with a comparatively low upload capacity. Some Internet providers prevent any access from outside. I therefore recommend to run a few tests before you invest in new hardware.
The following steps I describe below are generally applicable for both options.
UCS has only minor requirements on hardware, so the choice is yours. In principle, older desktop hardware can be suitable, too. However, they are often related to disadvantages in terms of reliability and power consumption if the system runs non-stop. If you decide to invest in a very new system, there are manufacturers offering systems which are suitable to be operated 24/7 (often referred to as “SOHO NAS” (Small or Home Office Network Attached Storage) systems). The HP systems in the MicroServer range and the Low Energy Servers from Thomas-Krenn are examples.
The next thing you need to think about is the matter of the system’s size. The setup we present here runs on a system with a smaller CPU and 4 GB RAM without any problems. The number of simultaneous accesses is the critical part. If the number of users or applications increases, you will eventually be needing more capacity. Cloud offers can always be expanded easily. In case you purchase the system, it is thus worth it starting out with already 8 or 16 GB RAM and a CPU with 4 cores.
The hard disk space required for UCS is negligible – 10 GB is more than enough to keep the operating system working for a long time. The decisive factor here is what you intend to do with it, particularly, the amount of data that you save on the system. Please also consider redundancy via mirrored disks (RAID) when purchasing hardware. Further information on this aspect can also be found in the Debian HowTos I linked further down.
To access the system from the Internet, you need a public IP address and corresponding DNS entry. If you rent server resources, they supply you with at least an IP address and often also a public domain.
In home networks, the public IP is generally assigned to the private router. This needs to be configured so that it can pass requests on to the local UCS system. How this is done depends on the router itself and possibly on the Internet provider. You can find HowTos for that on the Web for the majority of routers and firewalls. If the private router does not have a public IP, it might be difficult or even impossible to run a publicly accessible server behind it. In case of doubt, please contact your Internet provider or seek further information on the Web.
The next requirement is a publicly resolvable DNS entry, which can be procured from providers of dynamic DNS. The router takes care of all communication with the DNS provider. As such, it is important to pay attention to compatibility here. The following example uses the domain “my-ucs.dnsalias.org” as an example.
For the services described here, it is necessary to make port 80 (HTTP) and 443 (HTTPS) as well as 587 (SMTP Submission for incoming mails) externally available. For remote administration, especially for systems that are not in the home network, access to port 22 for SSH makes sense. Further ports may result from further applications, e.g., if IMAPS / SMTPS should be used for mail clients in addition to ActiveSync. While in home setup these ports are actively enabled in the local router, the configuration of a system operated by a provider should be designed to block all other ports.
In the majority of home networks, DHCP is used to assign IP addresses automatically. However, since the server address needs to be set in the configuration of the router for the release of the ports to external, the server must always get the same address. To achieve this, you can save the UCS system or MAC address in the router’s DHCP configuration. Alternatively, you can determine a fixed IP address during the UCS installation. In this case, however, it must be ensured that the router does not assign it to any other device. When using a fixed IP, please always ensure that the specifications for the default gateway and name server are correct. In the majority of cases, both is the router’s IP.
For the installation, you download the UCS ISO image from our website and burn it onto a DVD or transfer it to a USB stick. The system should then be booted from this medium (BIOS setting). The installation then begins including a range of different steps such as the configuration of the language, the mounted hard disks are partitioned. In many cases, you can simply adopt the partitioning suggestion. If you want to increase the failure security with a software RAID or expanded partitioning, set it up manually.
For details, please refer to the Debian documentation since UCS uses it’s installation process.
After the basic installation begins the actual UCS configuration.
The following information is practical for the planned setup.
Find the complete documentation of the installation in the UCS manual.
After the installation, you can access the system via an Internet browser at http://<IP> or http://<domain>. By clicking on the “system and domain settings” link, you get to the Univention Management Console (UMC) where you can log in as the “Administrator” using the password you specified during the installation process. The remainder of the setup is performed there.
First thing you need to do after the installation and before you can install and set up the required services is to unlock the App Center. This is done via the “key”, which is sent to the address you have given during the installation process. Upload the key directly from the welcome dialog that appears after the installation or go later to the UMC, click on the top right „Burger“ menu icon and select the point “License” and then “Import new license”.
The first app we install is ownCloud, which is a common storage location for files from PCs and mobile devices. Open the “App Center” module in the UMC and search for “ownCloud”. The installation of ownCloud can be triggered directly. Simply follow the instructions in the web interface.
After completing the installation, ownCloud can be reached via https://<ip>/ownCloud. This link can also be found on the overview page of the UCS server. When you go there, however, a warning message about the SSL certificate will appear first which we are going to eliminate later by installing Let’s Encrypt.
For the now following installation of a mail and groupware we are using Kopano. For our purposes you can use it for free.
This is done by installing the following components of Kopano one after another from the App Center module of the UMC: Kopano Core, Kopano WebApp and Z-Push for Kopano.
During the installation of Kopano, a mail domain will also be created in UCS. Using the UMC module „Mail“ from the category „Domain“, you can ensure that the mail domain is configured correctly. In our example it is called “my-ucs.dnsalias.org”.
After the installation, you can set up user accounts. The “primary mail address” is the mail address that the user will use in Kopano. It thus should use the public domain, for example email@example.com.
The mail service is now capable of receiving mails sent to the publicly accessible mail domain, here: my-ucs.dnsalias.org. To make sure that the sending of mails works without any problems and that mails will not be directly blocked by spam filters of other mail servers, this name should also be used as “helo”. For this, set the UCR variable “mail/smtp/helo/name” to the publicly accessible FQDN – in this example: my-ucs.dnsalias.org. The setting of UCR (“Univention Configuration Registry”) variables can be performed in the UMC module of the same name or in the command line with the command
ucr set mail/smtp/helo/name=“my-ucs.dnsalias.org“
If possible, we also recommend to use an SMTP relay host. In particular if the sender’s IP address differs from that of the public domain.
In the default setting, Postfix creates a direct SMTP connection to the mail server responsible for the domain when an e-mail is sent to a non-local address. This server is determined by querying the MX record in the DNS.
Alternatively, a mail relay server can also be used, i.e., a server which receives the mails and takes over their further sending. This type of mail relay server can be provided by a superordinate corporate headquarters or the Internet provider, for example. To set a relay host, it must be entered as a fully qualified domain name (FQDN) in the Univention Configuration Registry variable mail/relayhost.
If authentication is necessary on the relay host for sending, the Univention Configuration Registry variable mail/relayauth must be set to yes and the /etc/postfix/smtp_auth file edited. The relay host, user name and password must be saved in this file in one line.
must then be executed for this file to adopt the changes via Postfix.
Incoming mails are routed according to the current status of the implementation for the public DNS entry of the server: If mails are to be sent to addresses of the domain my-ucs.dnsalias.org, the IP of the assigned MX record of the domain or the IP address of the domain itself is used in the DNS and contacted as the destination. The latter is the case in our configuration: the mail domain corresponds to the public name of the server, so that our system is found by other mail servers and contacted for the delivery of mails.
Port 25 is specified in the UCS firewall by default. However, port 587 is preferred for the direct exchange between mail servers. This can be approved by UCR in the firewall. This is done by setting the variable “security/packetfilter/package/manual/tcp/587/all” to “ACCEPT” – as above for the “helo” string. This is also possible here via the UMC module or the command line.
Following the changes, the “postfix” and “univention-firewall” services need to be restarted. Do this via the command line
"service postfix restart; service univention-firewall restart"
or by rebooting the server.
The overview page in UCS, the “Univention Portal”, provides a good introduction to all available services. Access it now easily via “https://my-ucs.dnsalias.org”. However, there is still the certificate warning in the browser, which we’ve already seen during the ownCloud installation.
It can be solved easily with Let’s Encrypt.
By default, the UCS web server uses a self-signed certificate, which leads to warnings in the browser. Via the installation of a certificate with “Let’s Encrypt” you can solve that. The corresponding app can be found in the App Center.
After installation, open a configuration mask by clicking on “App Settings”: enter here the domains (my-ucs.dnsalias.org and server.my-ucs.dnsalias.org), separated by spaces, and checkmark the services that should use the certificate. In our example the certificate should be used in Apache and Postfix. With a click on “Apply changes” a certificate will be created and integrated into the services. You can check the „status“ field in the „App Settings“ to see if the certificate was aquired successfully. Port 80 must stay open for Let’s Encrypt to be able to renew the certificate regularly. You can make Apache redirect all other HTTP connections to HTTPS, because Let’s Encrypt is excluded from this, though.
ucr set apache2/force_https=yes
Now the configured services “Postfix” and “Apache” must be restarted, to actually use the new certificate. This can be accomplished via the “System services” module below “System” in the web interace or with the following commands on the command line:
service apache2 restart
service postfix restart
Finally, you need to reload the web interface once.
Users can now be added to the system. For every user account created in UCS, a corresponding account is created automatically in ownCloud and, if a primary mail address has been specified, in Kopano, too. The user can then log in to both services with the account password. Password changes are possible via the menu in the Univention Portal.
Kopano and ownCloud can also be used by smartphones. To synchronize e-mails, contacts and appointments with Kopano, an “Exchange” account is set up on the smartphone, for details see the Kopano documentation. ownCloud offers its own Android iOS app that allows you to share files with your smartphone and automatically save captured pictures and videos to the server.
This setup is a good basis to integrate more services from the many apps offered for UCS:
Having followed all above steps successfully, you can now enjoy your new home server setup.
I hope you like my scenario and look forward to your feedback and comments.
For detailed questions on this, you can also refer to the
Maren Abatielos joined Univention in 2012. Since then she has been engaged in content and social media marketing for UCS and Open Source in general.
Is this with the community version of UCS or the paid version? Nicely written and maybe some more usecases like enabling print and file servers, as well as domain controlling and active directory could follow in part 2Reply
thanks for the comment! The scenario described in this article was created with the free core edition of UCS. The core edition is available for personal and commercial use with an unlimited amount of users. You can find a detailed comparison of the core edition and subscriptions here: https://www.univention.com/products/prices-and-subscriptions/
Thanks for the suggestions regarding a sequel of this tutorial!
I can already point you towards the App Center included in UCS. The app “Active Directory-compatible domain controller” extends UCS with Active Directory functionality and allows you to e.g. set-up File shares for Windows clients . You can find more about that here: https://www.univention.com/products/univention-app-center/app-catalog/samba4/
For print services, Univention offers the “Print server” app, that’s easily configurable via the web interface: https://www.univention.com/products/univention-app-center/app-catalog/cups/
I’d also like to recommend this article by my colleague Michael: https://www.univention.com/2017/09/shed-light-on-the-it-jungle-with-a-domain-controller/
It’s a nice introduction to the concept and terminology of a domain and good point to start.Reply
Hi, as a home user, is there a way you can add an option in the Lets Encrypt App Settings to install a certificate for internal home use only?
I suspect that the same as I, not everyone needs to run a public facing website and have no need to open ports. It would still be good practice to run secure at home and also to be able to deliver certificates to machines joining the domain.
Really appreciate UCS and the teams dedication to making a product that you don’t have to be a complete and utter tech CLI Guru! UCS does make it a lot easier for those of us wanting to deploy something a lot safer than the pre-pandemic accepted norm, but don’t have the full knowledge to go down the home-lab route.Reply
This manual doesn’t work, as nearly all manuals available for UCS.
The implementation of Lets Encrypt is useless, as the UCS does not use these certifcates if You follow that manuals (also apache doesn’t use it). No manual implement the needed steps to use these certificates. UCS always stays on the certificates created on the machine (which are unsafe).
Why do all manuals mention that “Lets Encrypt.app” in UCS, but nobody mentions how to implement them.
The UMC stays on the self created certificates. The Lets encrypt certificates are placed in a directory (/etc/univention/letsencrypt) which isn’t used by any other app. The look in “/etc/univention/ssl” for certificates.
an addition to that:
You need to change the entries in the “Univention Configuration Registry”, then it looks like, the Lets Encrypt certs are used.