Free Training
We offer free training sessions. Please don't hesitate to contact us through our training page for further assistance.
Video Tutorial
Deploy the product
First, subscribe to the product on the AWS Marketplace, and then deploy this CloudFormation file.
The First Boot
The boot time of our product may be slower compared to starting an instance from a clean AMI. This is because our custom code needs to be executed to prepare the product for you. As a result, this process may take a few minutes longer than usual.
Connecting to the Server
If you need to connect to the server, obtain its IP address and connect to the instance over SSH using the username ec2-user
. Make sure to use the private key you selected during the deployment process. Upon successful connection, you should be greeted with a custom MOTD (Message of the Day) that provides detailed product information.
Automatic configuration of Linux client servers
Note
This step is optional. If you are comfortable and confident in configuring your client servers yourself, you can proceed with manual configuration. Alternatively, if you are using another product that handles log forwarding or has its own UI for setup, you can utilize that product's interface to configure the necessary settings.
Once the server (our product) is deployed correctly, you can configure your clients using the following commands. Please ensure that you replace the placeholder values with the actual ones, and ensure that the EC2 instances running these commands have access to the S3 bucket where the custom script is located.
These commands can be executed:
- By manually executing them.
- By placing them in the EC2 Instance UserData.
- By executing them remotely through AWS Systems Manager.
- And so on.
#!/bin/bash
aws s3 cp s3://PARAM_BUCKET_RSYSLOG/bash/rsyslog-client-setup.sh /tmp/rsyslog-client-setup.sh
chmod +x /tmp/rsyslog-client-setup.sh
/tmp/rsyslog-client-setup.sh PARAM_RSYLOG_SERVER_IP
Explanation
- Copy the bash script that will configure the client.
- Make the script executable.
- Configure the client to send the logs to the Rsyslog server.
Logs location
The logs can be found in the /var/log/0x4447-rsyslog
folder. Inside this folder, you will find additional folders named after the remote hostname, allowing for easy identification and organization of logs.
User Management
To allow other team members to access the logs from remote servers through our product, we have created a special user group called rsyslog
. This user group has access only to the remote logs. Below is a reminder on how to manage users and passwords under Linux.
How to create a user
sudo useradd -g rsyslog PARAM_USER_NAME
How to set a password
sudo passwd PARAM_USER_NAME
How to delete a user
sudo userdel PARAM_USER_NAME
How to change a password
sudo passwd PARAM_USER_NAME
Advanced details
Key aspects
- SSL is enabled by default to only accept logs over a secure channel.
- User access is restricted to SSH using passwords and limited only to the log folder.
- Logs are organized in separate folders using the remote host name.
Example use cases
Your imagination is your limit, but here are some ideas worth considering:
- If you design your infrastructure in a way that avoids granting remote access to the production server for anyone, you can stream the logs from those servers into our product. This enables secure access to production logs, which is beneficial for developers looking to debug potential issues.
- Stream logs from Docker containers by configuring Docker to forward the logs to the host operating system. The host OS can then forward those log messages to our product.
Resilience
Our product incorporates built-in resilience measures to prevent data loss and ensure uninterrupted connectivity, even in the event of changing IP addresses. The CloudFormation template we provide offers a streamlined and efficient way to deploy and set up all the necessary components, allowing you to get up and running swiftly with everything you need.
Test the setup
Before going into production, it is important to thoroughly test the product. This is not because we lack confidence in its functionality, but rather to ensure that you become familiar with how it works and can address any potential challenges or issues beforehand. Testing will help you gain confidence in the product's performance and make necessary adjustments, if needed, before deploying it in a live production environment.
Security Concerns
Below we give you a list of potential ideas to consider regarding security, but this list is not exhaustive – it is just a good starting point.
- Never expose this server to the public. Use it only within a private network to restrict access to those who can send logs.
- Allow logging only from specific subnets.
- Block public SSH access.
- Allow SSH connections only from limited subnets.
- Ideally, allow SSH connections only from another central instance.
- Restrict root access to yourself and do not provide it to anyone else.
How To
How to change the instance type
Make sure you regularly back up your drive(s). One simple solution would be to use:
- Go to the CloudFormation console
- Click on the stack that you want to update.
- Click the
Update
button. - Keep the default selection and click
Next
- On the new
Parameters
page, change the instance type from the drop down. - Click
Next
till the end.
Please wait for the stack to finish updating.
F.A.Q
These are some of the common solutions to problems you may encounter:
Not authorized for images
My CloudFormation stack encountered a failure with the following error: API: ec2:RunInstances Not authorized for images:...
in the Event tab.
Solution
Before using our CloudFormation file, please ensure that you accept the subscription from the AWS Marketplace.
The product is misbehaving
I followed all the instructions from the documentation.
Solution
Please verify if the values entered in the UserData section have been successfully passed to the instance itself.
sudo cat /var/lib/cloud/instance/user-data.txt
UserData seams ok
The UserData reached the instance, but the product is not behaving as expected.
Solution
Use the following command to check if there were any errors during the boot process.
sudo cat /var/log/messages | grep 0x4447