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

  1. Copy the bash script that will configure the client.
  2. Make the script executable.
  3. 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:

  1. Go to the CloudFormation console
  2. Click on the stack that you want to update.
  3. Click the Update button.
  4. Keep the default selection and click Next
  5. On the new Parameters page, change the instance type from the drop down.
  6. 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