Top Nav

Networking Broken On EC2 Instance Created From Snapshot

Situations have been observed where the network interface will fail to start on an AWS EC2 instance created from a snapshot of another instance. Since AWS EC2 lacks a facility to access the console, it’s not possible to login and fix this condition. One way to solve the problem is to:

  1. Stop the new instance.
  2. Detach root volume and attach to alternate server.
  3. From the alternate server, mount the root volume and edit the network config.
  4. Unmount the root volume.
  5. Make a snapshot of the root volume.
  6. Make an AMI image from the snapshot.
  7. Create a new EC2 instance from the AMI.

This will work but it takes significant effort and you have to have an available alternate server to mount and fix the root volume.

An alternate approach is to use the “User data” feature when creating the EC2 instance to inject a script that fixes the network config. For example let’s assume that we have a CentOS based AMI image named “host1-backup” which we wish to use create a new EC2 instance. The network config in the image has the MAC address explicitly specified in “/etc/sysconfig/network-scripts/ifcfg-ens5”. When the AMI boots, the specified MAC address does not match the interface and the new instance fails to start networking. This can be resolved as follows:

a. Launch a new EC2 using the “host1-backup” AMI from the AWS console. On “Step 3: Configure instance details”, in the “Advanced details” section enter the following:

b. When the instance starts the user data script will run and remove the HWADDR line from the interface control file.

c. Reboot the instance to allow the modified network config to activate.

There are other cases where this approach might be useful. for example a broken iptables / firewall config could be disabled from user data script.

Note that the “user data” script runs late in the boot process so it can not be used to fix problem like a missing volume from /etc/fstab or a corrupt boot loader.

0

Diffie–Hellman (DHE) Ciphers On Nginx

In some cases you may wish to allow Diffie–Hellman (DHE) ciphers in order to support older clients like IE on Windows 7.  On Plesk we often use the “intermediate” level in the Mozilla cipher set as described here:

https://wiki.mozilla.org/Security/Server_Side_TLS

The “intermediate” level includes:

  • ECDHE-ECDSA-AES128-GCM-SHA256
  • ECDHE-RSA-AES128-GCM-SHA256
  • ECDHE-ECDSA-AES256-GCM-SHA384
  • ECDHE-RSA-AES256-GCM-SHA384
  • ECDHE-ECDSA-CHACHA20-POLY1305
  • ECDHE-RSA-CHACHA20-POLY1305
  • DHE-RSA-AES128-GCM-SHA256
  • DHE-RSA-AES256-GCM-SHA384

Of course the “ECDSA” or “Elliptic Curve Digital Signature Algorithm” ciphers will only be available if you are using ECC signed certificates.

Additionally the “DHE” ciphers will not be available by default if you are using Nginx releases greater then 1.11. With the 1.11 release Nginx moved the DHE key to an external setting instead of an internally generated key. The stock Nginx packages on Ubuntu and CentoOS do not setup a DHE key which results in the DHE ciphers not being available.

To address this problem, start by generating a key:

Next tell Nginx where to find the key:

Verify Nginx config and restart:

Now the DHE ciphers will be offered to clients and Window 7 / IE clients will be able to connect to the sites hosted on the server.

 

 

 

0

Add Extra MySQL Root User

To add an extra “root” capable MySQL user start by logging in to the server on SSH and connect to MySQL CLI using an existing “root” level account. Next add the new user account:

Next grant permissions:

Now flush the privileges cache:

You might want to double check the results with:

 

 

0

Regenerate WP-Rocket .htaccess From Command Line

To regenerate the .htaccess file with WP-Rocket rules from the command line do the following:

  • Install wp-rocket extension for wp-cli:

  • Regenerate the .htaccess file:

There are additional useful commands on the rocket extension. See https://github.com/GeekPress/wp-rocket-cli for details.

 

 

 

0