Check SLA uptime in a linux server

13 01 2018

When a new server is up, usually from a remote provider, their reliability is covered under a Service License Agreement. In that document is reflected the garanteed uptime of the machine, a percentage value close to 100% which assure the time that the server have to be up.

There can be other clauses with the network uptime, storage uptime, what ever other service we had uptime that will aso have to be taken into account to the global uptime of our service. But now we are only going to focus exclusively on the operating system uptime. To know what is the value from our side, these are the steps:

When you have the access to the new server, as soon as posible, install the Tuptime package:

# apt-get install tuptime

Increase the sync interval. By default it save the time on disc each 5 minutes, which is ok for a normal user, but to have it as detailed proof of service, it can be done each minute. Change in “/etc/cron.d/tuptime” from:

*/5 * * * * tuptime if [ -x /usr/bin/tuptime ]; then /usr/bin/tuptime -x > /dev/null; fi


* * * * * tuptime if [ -x /usr/bin/tuptime ]; then /usr/bin/tuptime -x > /dev/null; fi

Or more agressive, assure the sync operation to disc too:

* * * * * tuptime if [ -x /usr/bin/tuptime ]; then /usr/bin/tuptime -x && sync > /dev/null; fi

Now it’s done, wait a few days or weeks and check how are things going.

Check the uptime for the last month. As one month (30 days) are 2592000 seconds, get the last n seconds from date:

# tuptime --tsince -2592000
System startups: 3 since 15:17:42 14/12/17
System shutdowns: 1 ok - 1 bad
System uptime: 97.3 % - 29 days, 4 hours, 35 minutes and 7 seconds
System downtime: 2.7 % - 19 hours, 24 minutes and 53 seconds
System life: 30 days, 0 hours, 0 minutes and 0 seconds

Check the uptime for the last year. As a year have 31536000 seconds:

# tuptime --tsince -31536000
System startups: 6 since 15:20:03 13/01/17
System shutdowns: 1 ok - 4 bad
System uptime: 94.39 % - 344 days, 12 hours, 33 minutes and 46 seconds
System downtime: 5.61 % - 20 days, 11 hours, 26 minutes and 14 seconds
System life: 1 year, 0 days, 0 hours, 0 minutes and 0 seconds>

The output give us a clear report of the uptime percentage. Even, it is possible to see the exact date and time if the “-t” table or “-l” option are passed to the command.

This is a good option to check the garanteed value without using any graph or pannel provided by the server provider. We have a strong view of how good or bad are service, any strange restart, even those that happen at intimely hours, will be registered and counted in the tuptime report.

If is required in the report an uptime / downtime percentage larger than two decimals, which is the default, use “–decp” option with the desired lenght.

More info:


Configure phpmyadmin for connect to RDS AWS MariaDB

30 03 2017

Ensure that “/etc/phpmyadmin/config-db.php” doesn’t haven any configured values:


Create a new file with for your particular values in “/etc/phpmyadmin/conf.d/myconf.php”

<?phpConfigure phpmyadmin for connect to RDS AWS MariaDB
$cfg['Servers'][$i]['extension'] = 'mysql';
$cfg['Servers'][$i]['host'] = '';
$cfg['Servers'][$i]['connect_type'] = 'tcp';
$cfg['Servers'][$i]['compress'] = TRUE;

Go to the phpmyadmin website and log with the administrative account.

More info:

Multiple network interfaces with multiple public IPs in an EC2 instance with different outbound source using network namespaces

14 02 2017

In this scenario we will have an ec2 instance with:

* 3 network interfaces
* 3 public IPs (one for each interface)
* 3 different process with different public outbound address running in separate network namespaces

As starting point, we have a simple ec2 instance with one interface and a public IP assigned to it. The steps are:

– Allocate two new elastic IPs

– Create two new network interfaces in the same subnet in which resides the instance.

– Associate the new elastic IPs to these new network interfaces.

– Associate the new network interfaces to the instance. Now, it have the default eth0 and two more, eth1 and eth2.

– Create a pair of network namespaces for the new interfaces:

ip netns add blue
ip link set eth1 netns blue
ip netns add green
ip link set eth2 netns green

– Request the IPs for the interfaces:

ip netns exec blue dhclient eth1ip netns exec green dhclient eth2

– And test it:

ip netns exec blue curl
ip netns exec green curl

Take into account that:

– You need to launch the proces with the “ip netns exec xxxx” due that systemd don’t support the network namespace assignement.

– Look the limits of AWS, by default, only 5 EIPs are allowed and each type of instance have a network limit.

VPN between PFSense in a LAN and Amazon AWS VPC with IPSec

18 10 2015

This manual cover the case of creating a IPSec VPN between a PFSense located inside a local network (in an office for example) and a VPC inside Amazon AWS, allowing the access of the resources in both sides transparently.



Base scenario

The following address are only for this manual, substitute them for your particular case:

Office LAN:
Office public IP:
Amazon VPC Net: | my_vpc



Create Customer Gateway


Start in AWS by creating a Customer Gateway. The routing can be dynamic, but as BGP is not going to be used, routing static must be select. For that reason, its neccesary to add a custom route to the Route Tables directly (later covered):

Name Tag:    test5
Routing:     Static
IP Address:





Create Virtual Private Gateways

Simply create a Virtual Private Gateway, VPG, and attach it to the target VPC.

Name Tag:     test5
Attached to: | my_vpc







Create VPN Connection

Now, create the VPN Connection joining all the things that were created before. After that, under Tunnel Details tab, there is two tunnels, we only use the first one, it have the Amazon AWS public IP for connect the IPSec VPN. Under Static Routes tab there is a route for our office network.

Name Tag:                 test5
Virtual Private Gateway:  vgw-xxxx | test5
Customer Gateway:         Existing
                          cgw-xxxx ( | test5
Routing Options:          Static
Static IP Prefixes:





Download the configuration. Mainly for know the Pre-Shared Key, the other parameters for PFsense are usually the same for all.

Vendor:    Generic
Platform:  Generic
Software:  Vendor Agnostic



Open the file and copy the Pre-Shared Key for later use:
Configure the IKE SA as follows
- Authentication Method : Pre-Shared Key
- Pre-Shared Key : AoLmjz_XLnktHkZxfSdm_69wJN11OqIuf9
- Authentication Algorithm : sha1
- Encryption Algorithm : aes-128-cbc
- Lifetime : 28800 seconds
- Phase 1 Negotiation Mode : main
- Perfect Forward Secrecy : Diffie-Hellman Group 2



Add custom route to Route Tables

This step is more dependent of your particular VPC subnets and route tables configuration, but essentially, its neccesary to add a route entry for send the traffic from your AWS subnet to your Office LAN trought the Virtual Gateway.

Target:       vgw-xxxxx | test5




PFSense configuration
Our office PFSense have two networks, one WAN interface, in this case behind a NAT but can be directly connected to internet with a public routable IP, and an other interface connected to the LAN.


Start with creating a IPSec VPN

Bring up the Phase 1 with the particular values, from the screen capture, usually only change the Remote Gateway and the Pre-Shared Key.

Key Exchange Version:  V1
Internet Protocol:     IPv4
Interface:             WAN
Remote Gateway:
Description:           VPC VPN
Authentication Method: Mutual PSK
Negotiation Mode:      Main
My identifier:         My IP address
Peer identifier:       Peer IP address
Pre-Shared Key:        AoLmjz_XLnktHkZxfSdm_69wJN11OqIuf9
Encryptation algorithm: AES 128 bits
Hash algorithm:        SHA1
DH key group:          2 (1024 bit)
Lifetime:              28800 seconds
Nat Transversal:       Auto
Dead Peer Detection:   Enable DPD
                       10 seconds
                       2 retries


Continue bringing up the Phase 2 with the particular values, from the screen capture, usually only change the Remote Network. For keep the tunnel up when there aren’t any traffic, add the IP of a AWS host in the “Automatically ping host” section.
Change Local Network to other different than “LAN subnet” if your local network is different, or greater, than the LAN connected to the interface.

Mode:                  Tunnel IPv4
Local Network:         LAN subnet
Remote Network:
Protocol:              ESP
Encryption algorithms: AES 128 bits
Hash algorithms:       SHA1
PFS key group:         2 (1024 bit)
Lifetime:              3600
Automatically ping host: ?


Define in VPN: IPsec: Settings “Maximum MSS” for avoid inexplicable failures. Tick “Enable MSS clamping on VPN traffic” and set 1387 in the box.

Finally, if all went well, must be something like this:


and this:


It’s necessary a firewall rule for allow IPSec traffic.
In case of your local network is different, or greater, than the LAN connected to the interface, add an other rule to allow all traffic under LAN tab.

Proto:       IPv4
Source:      *
Port:        *
Destination: *
Port:        *
Gateway:     *
Queue:       *


In the Amazon AWS side, the Status of VPN Connection must be changed from DOWN to UP:


Try to ping host from one side to the other, with the VPN stablished and if there aren’t any other particular network configuration, there sould not be any issue.

I hope it has been helpful…



  • You can configure the Tunnel 2 in the same PFSense, but don’t use the same public IP. For each IPSec tunnel, use a different public IP.




Other resources: