AWS¶
On this page, we will explain how to configure the AWS cloud provider environment to deploy the Zentyal server. Requirements
Requirements¶
To follow this document, you will need the following:
- An AWS account.
- A user with permissions for the following services:
- Route53 (if the domain is hosted in this service)
- VPC
- KMS
- EC2
Region¶
Before starting to create resources, we need to know which is the best region to use. To do this, we will use this website, where we can see which region has better latency from our location.
As seen in the image, in my specific case, I have selected all the European regions since I am in Spain. The displayed result indicates that Paris is the region with the best latency, therefore, this will be the region where I will deploy the environment.
VPC¶
The first service we will configure is VPC, which is basically a virtual network where we will place our Zentyal server.
We will create a VPC with the following configuration:
- Name: VPC-Prod-Zentyal
- IPv4 CIDR: 10.0.0.0/16
- IPv6: Disabled
- Tenancy: Default
- Tags:
- Name: VPC-Prod-Zentyal
- Env: Production
Note
Since Zentyal does not allow IPv6, we disable it to avoid possible security breaches.
Below is an image with the configuration.
Once it has been created, we can optionally enable the following options:
- DNS hostname
- DNS resolution
Subnet¶
Once we have our VPC created, we will proceed to create a public subnet, which will be where we will locate our Zentyal server.
The subnet configuration will be:
- Name: SUB-Prod-Public-1
- Availability zone: eu-west-3a
- IPv4 CIDR: 10.0.1.0/24
- Tags:
- Name: SUB-Prod-Public-1
- Env: Production
Below is an image with the configuration.
Gateway¶
The next thing we'll do is configure an Internet gateway for our VPC, so that instances using this subnet can access the internet.
The Internet gateway will be configured as follows:
- Name: GW-Prod-1
- Tags:
- Env: Production
- Name: GW-Prod-1
Here is an image of the configuration:
Finally, we will associate the newly created resource with our VPC.
Routes¶
Once we have created both the subnet and the gateway, we will need to create or modify the route table that AWS creates by default when we create a VPC.
For this case, we will have to edit the existing resource and perform the following actions:
-
Create the tags as shown in the image:
-
Ensure that the subnet is associated:
-
Set the gateway to resolve the rest of the network ranges.
Network ACL¶
The next resource we will modify is the default network ACL that AWS creates for us. The rules defined there allow us to deny or allow incoming and outgoing traffic from our subnets.
Once again, AWS creates a default network ACL for us, which we will modify as follows:
-
Create the tags as shown in the image:
-
Ensure that the subnet is associated:
-
Verify that all inbound traffic is allowed:
-
Verify that all outbound traffic is allowed:
Security Group¶
The last resource we will modify in the VPC service is the security group that we will associate with the Zentyal server, which is basically a virtual firewall that allows us to establish the allowed ports and IPs.
For this specific resource, we will do 2 things:
-
We will modify the tags of the resource that AWS created by default when we created the VPC.
-
We will create a new resource, which will contain the ports that we will allow public access to, which are:
- ICMP-IPv4 echo request ->
ping
- 22/TCP -> SSH.
- 25/TCP -> SMTP.
- 53/UDP -> DNS.
- 53/TCP -> DNS.
- 143/TCP -> IMAP.
- 443/TCP -> HTTPS.
- 465/TCP -> SMTPS.
- 587/TCP -> SMTPS con StartTLS.
- 993/TCP -> IMAPS.
- 8443/TCP -> Zentyal GUI.
- 11994/UDP -> OpenVPN.
The result should be as follows:
In addition, we will also set the following tags:
- Name: SG-Prod-Zentyal
- Tags:
- Name: SG-Prod-Zentyal
- Env: Production
- Host: arthas.icecrown.es
Note
The host 'arthas.icecrown.es' will be the name we give to the Zentyal server.
- ICMP-IPv4 echo request ->
EC2¶
Once we have the network (VPC) set up, we will proceed to create the necessary resources in the EC2 service.
Group Placement¶
The first resource we will create is a placement group, which will allow us to distribute instances (servers) across different hardware, minimizing potential errors that may arise from AWS.
The configuration we will set up is:
- Name: GP-Prod-1
- Placement strategy: Spread
- Spread level: Rack
- Tags:
- Name: GP-Prod-1
- Env: Production
Key Pair¶
Next, we will create a key pair, which will allow us to connect to the instance via SSH.
Considerations:
- Only during key pair generation will it be possible to download the private key.
- Access to the downloaded private key should be restricted, as this key provides full administrator access to the instance without the need to establish a password (default behavior on AWS Linux instances).
- The permissions the key should have are read-only for the user, in octal notation it is: 0400.
The configuration we will set up is:
- Name: KP-Prod-Zentyal
- Key pair type: RSA
- Private ket file format: .pem
- Tags:
- Name: KP-Prod-Zentyal
- Env: Production
- Host: arthas.icecrown.es
Network interface¶
The next resource we will use is to create a network interface, which will allow us to establish a static IP and associate it with the Zentyal instance, avoiding possible incidents in the most critical module, the network.
The configuration we will set up is:
- Name: NI-Prod-Zentyal
- Subnet: SUB-Prod-Public-1
- Private IPv4 address: 10.0.1.200
- Security Group: SG-Prod-Zentyal
- Tags:
- Name: NI-Prod-Zentyal
- Env: Production
- Host: arthas.icecrown.es
Instance¶
Once we have created all the above resources in the EC2 service, we will proceed to create the compute instance (server) on which we will install Zentyal.
Considerations:
- Due to the Zentyal modules we will be using, the instance must have a minimum of 4GB of RAM.
- For the project's testing purposes, I have opted for the most economical instance possible, which is of the general type and is called t3a.medium.
- The instance price can be obtained from here.
- I will use 3 EBS (hard disks) volumes to establish the following partitioning:
- System EBS of 30GB.
- Email EBS of 10GB.
- Personal directories and shared resources EBS of 10GB.
-
I will enable advanced monitoring since I will use AWS CloudWatch as the monitoring system.
Warning
This option has an additional cost, which can be checked here.
-
The options I will configure and that represent a monthly cost are:
- Instance type.
- Root volume.
- Detailed CloudWatch monitoring.
Therefore, the configuration we will define in the service will be:
- Name: arthas.icecrown.es
- AMI: Ubuntu Server 20.04 LTS (HVM), SSD Volume Type
- Architecture: 64-bit (x86)
- Instance type: t3a.medium
- Key pair: KP-Prod-Zentyal
- Network settings:
- VPC: VPC-Prod-Zentyal
- Subnet: SUB-Prod-Public-1
- Auto-assign public IP: Disable
- Firewall: Select existint security group
- Network interface: NI-Prod-Zentyal
- Configure storage:
- Root volume: 30 GB, GP3
- Advanced details:
- Shutdown behavior: Stop
- Termination protection: Enable
- Detailed CloudWatch monitoring: Enable
- Placement group: GP-Prod-1
- Tags:
- Name: arthas.icecrown.es
- Env: Production
- Host: arthas.icecrown.es
Volumes¶
Once we have created the instance, we will proceed to configure the volumes (hard drive) of our Zentyal server. In my specific case, I will create two additional volumes, one to host emails and another for personal directories and shared resources. The reason is that it will allow me to define different backup policies at the AWS level, and the data is on separate disks, with the advantages that this entails, such as recovering information in case of human error.
Before proceeding to create the additional volumes, we will set the tags for the system volume associated with the running instance:
- Name: EBS-Prod-System-Zentyal
- Env: Production
- Host: arthas.icecrown.es
- Type: System
Next, we create the additional volumes:
Warning
The volumes must be in the same availability zone as the instance, eu-west-3a in my case.
For mailboxes:
- Volume Type: General Purpose SSD (gp3)
- Size: 10GiB
- IOPS: 3000
- Throughput: 125
- Availability zone: eu-west-3a
- Snapshot ID: Don't create volume from a snapshot
- Encryption: Enabled
- KMS key: (default) aws/ebs
- Tags:
- Name: EBS-Prod-Mail-Zentyal
- Env: Production
- Host: arthas.icecrown.es
- Type: Mail
For personal directories and shared resources:
- Volume Type: General Purpose SSD (gp3)
- Size: 10GiB
- IOPS: 3000
- Throughput: 125
- Availability zone: eu-west-3a
- Snapshot ID: Don't create volume from a snapshot
- Encryption: Enabled
- KMS key: (default) aws/ebs
- Tags:
- Name: EBS-Prod-Shares-Zentyal
- Env: Production
- Host: arthas.icecrown.es
- Type: Shares
Finally, we will associate both volumes with the EC2 instance.
Elastic IP¶
The next resource we will create is an Elastic IP, which is simply a public IPv4 address that we will associate with our instance.
The tags we will define for the resource are:
- Name: EIP-Prod-Zentyal
- Env: Production
- Host: arthas.icecrown.es
Finally, we associate the newly created resource with the instance.
Route 53¶
The next necessary action is to create the DNS record in the domain to point to the public IP associated with the instance. In my specific case, I will use the Route 53 service to create the A
type DNS record, as this is where I have registered the domain.
Request email sending¶
To be able to send emails from the Zentyal server through the associated static IP, it is necessary to request AWS to remove the restriction they have by default through a form. To do this, simply follow this link where the steps are explained.
Considerations about the message:
- It must be written in English.
- It must be detailed; otherwise, they will request more information or even deny the request.
- Some recommended details are:
- Usage of the server.
- Number of users that will use email.
- Approximate number of emails that will be sent per hour.
An example of the message:
Saving Plans¶
Once the server has been created, configured, and thoroughly tested, it is highly recommended to purchase the instance using Saving Plans, as it will allow us to significantly reduce the cost of using the deployed EC2 instance.
Created: April 12, 2023