Deploy the product

Steps

A comprehensive list of steps to ensure a successful deployment:

1. Verify you are in the correct AWS account.
2. Ensure you are in the appropriate region.
3. Subscribe to the product using the link provided above, and ensure not to launch the product from the AWS Marketplace.
4. Confirm the product was not launched from the AWS Marketplace.
5. Deploy the product using the CloudFormation template link provided above.
6. Wait for the deployment to complete while continuing to review the remaining documentation.

Initial Startup

Expect a slight delay in the startup time of our product relative to launching an instance with a standard AMI. This occurs as our bespoke software configuration is applied to tailor the product to your needs, extending the initialization process by a few minutes.

Server Connection

Using SSM

All of our products are designed to support AWS Systems Manager (SSM) right out of the box. We strongly believe in security, and the fewer ports exposed to the public, the better. The SSM service provided by AWS perfectly aligns with this approach.

When you need to connect to an instance, opt for connecting through the Session Manager. Once you've gained access, execute the command sudo su ec2-user to switch to the user account where all of our tools are located. This ensures you have the appropriate permissions and access to the necessary resources. Additionally, you're encouraged to use the AWS Systems Manager service for secure and efficient management of your instances. This integrated service provides a unified interface for automated tasks and monitoring, further enhancing your operational security and efficiency.

Using SSH

This approach is also available to you. However, by default, we configure the Security Group to not expose port 22 to the public; it's set to be accessible only within the local subnet. If you need to access the server over the internet, you will need to change the Inbound rule accordingly. Once that is configured, you can access the instance using the ec2-user username and the SSH key you selected at deployment time.

Automatic Configuration of Linux Client Servers

Upon successful deployment of our server product, you have the flexibility to configure your Linux client servers by employing the following commands. It's crucial to substitute the placeholder values with actual data relevant to your setup. Additionally, verify that the EC2 instances intended to run these commands are authorized to access the S3 bucket containing the custom script.

The configuration commands can be implemented through various methods, including:

• Direct manual execution.
• Integration into the EC2 Instance UserData.
• Remote execution via AWS Systems Manager.
• Among other applicable techniques.

#!/bin/bash

# Copy the configuration script from S3 to the local system
aws s3 cp s3://PARAM_BUCKET_RSYSLOG/bash/rsyslog-client-setup.sh /tmp/rsyslog-client-setup.sh

# Grant execution permissions to the script
chmod +x /tmp/rsyslog-client-setup.sh

# Run the script to configure the client server to forward logs to the Rsyslog server
/tmp/rsyslog-client-setup.sh PARAM_RSYLOG_SERVER_IP

Logs Location

Logs are stored within the /var/log/0x4447-rsyslog directory. Within this directory, logs are further organized into subdirectories named according to the remote hostname. This structure facilitates straightforward identification and management of logs for each connected client.

User Management

For enabling access to logs from remote servers via our product for additional team members, we have established a dedicated user group named rsyslog. This group is granted exclusive access to the remote logs. The following section serves as a refresher on managing user accounts and passwords within a Linux environment.

User Creation

To create a new user and assign them to the rsyslog group:

sudo useradd -g rsyslog PARAM_USER_NAME

Setting a Password

To establish or update a user's password:

sudo passwd PARAM_USER_NAME

User Deletion

To remove a user from the system:

sudo userdel PARAM_USER_NAME

Password Modification

To change an existing user's password:

sudo passwd PARAM_USER_NAME

Advanced Details

Key Features

• SSL Encryption: By default, SSL is activated to ensure logs are transmitted over a secure channel.
• SSH Access Control: Access via SSH is carefully controlled. Password-based SSH access is limited strictly to the log directory, enhancing security.
• Organized Log Storage: Logs are meticulously organized in separate directories named after the remote hostname, simplifying log management and retrieval.

Use Cases

The potential applications of our product are only limited by your creativity. Here are some inspirations:

• Secure Production Log Access: Streamline secure access to production logs without granting direct remote access to the production server. This setup is invaluable for developers needing to debug issues without compromising server security.
• Docker Logs Integration: Configure Docker containers to forward logs to the host operating system, which in turn, sends them to our product. This approach ensures a seamless log management solution for containerized environments.

How To

How To Change the Instance Type

Ensure your data is backed up regularly. A straightforward method includes:

1. Navigate to the CloudFormation console.
2. Select the stack you wish to update.
3. Click the Update button.
4. Proceed with the default option by clicking Next.
5. On the Parameters page, select a new instance type from the dropdown menu.
6. Continue clicking Next until the process concludes.

Wait for the stack update to complete.

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.

The product is misbehaving

I followed all the instructions from the documentation.

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.

sudo cat /var/log/messages | grep 0x4447