Solved: Failed to start raise network interfaces on ubuntu using vmware workstation   Recently updated !

I updated ubuntu on my virtual machine and once it finished it wasn’t being assigned an IP address. During boot it showed the error “Failed to start raise network interfaces”.

Create a new file 10-rename-network.rules in /etc/udev/rules.d/ and add the following content to it:

SUBSYSTEM==”net”, ACTION==”add”, ATTR{address}==”ff:ff:ff:ff:ff:ff”, NAME=”eth0″


eth0 = desired network interface name, used in /etc/network/interfaces
ff:ff:ff:ff:ff:ff = hardware mac address of the network device

You can check your current MAC address with the command: # ip link show interface. where interface is the name of your network interface. The section that interests us at the moment is the one that has “link/ether” followed by a 6-byte number.

Then restart the VM. After that you should have an IP address again. Verify by typing “ip a” .

Example of attacks on your wordpress site

Below is a log of failed attempts by a script or bot to guess your WordPress admin panel URL. WordPress is the most popular website platform in the world and is also the most attacked. Any wordpress site my team takes on will get a security sweep that includes implementation of a custom admin panel url and multi factor authentication for all users to keep people out of your admin panel.

On a similar note, attacks on WordPress sites are common against installed plugins, which aren’t developed as securely as the WordPress platform itself. Here is an example of a bot checking for specific files on specific plugins that have known vulnerabilities. I highly recommend keeping the number of plugins and themes on your wordpress site to a minimum, and keeping them up to date.

Example of a security attack on your magento store

One of my clients’ sites has a 404 not found logger installed so we can easily add needed redirects. While reviewing the log today it became apparent somebody had run a script against the site to check for a couple hundred combinations of common directories and files that could be downloaded. Many of them were looking for database backup files. The scary thing is, as I’ve worked on dozens of Magento sites, I’ve seen files and directories with these names available publically when I start working on their project. All someone has to do is guess the filename and proper path and they’ll download an older copy of your database – whenever your developer created that file. It’s difficult for a store owner to identify this security risk because most of them aren’t accessing the code files and looking. Be sure to have a development team working on your site that is focused on security and doesn’t leave these files laying around! The good news is, we don’t have any vulnerable data accessible like this on our customers’ project, and we blocked this IP address.

Certbot auto-renew didn’t work because nginx wasn’t reloaded

Two sites on my server (Debian on nginx) are using certbot SSL certificates and I was greeted with a browser notice that one of them was expired. Certbox creates a cron job to do automatic renewal of the SSL and it works, but an nginx reload needs to occur afterward for the new cert to take effect. This is not automatically configured when you install Certbot, which creates this cron job at /etc/cron.d/certbot

0 */12 * * * root test -x /usr/bin/certbot && perl -e 'sleep int(rand(3600))' && certbot -q renew

To solve, add this at the end of the cron job command so have nginx reloaded after each successful SSL renewal

--renew-hook "/etc/init.d/nginx reload"

The final cron command is

0 */12 * * * root test -x /usr/bin/certbot && perl -e 'sleep int(rand(3600))' && certbot -q renew --renew-hook "/etc/init.d/nginx reload"

Alternatively, you can add a line for each domain separately under the renewalparams section of the file /etc/letsencrypt/renewal/

renew_hook = service nginx reload

Adding lets encrypt certbot to your site

For fun today I installed certbot, formally known as Let’s Encrypt, on one of my personal projects in order to get a free SSL cert for the site. It was pretty straight forward and worked very well! Below are notes and tips that may help your install.

My server is running Debian Linux with an nginx web server.

  1. Go to and enter your flavor of linux and type of server. If you’re unsure what distro/flavor of linux you have, type this on the command line “cat /etc/issue” .
  2. For my combination, the fully automated solution was not available. Their automated solution will prompt you for which sites on your server you want to install the certificate for, and then it will edit your nginx conf files for each site so the certificate is used. I haven’t tried this myself, but automated things like this make me weary, so I probably would have done the manual install anyway.

  3. The next step was to follow the instructions on the following page as the root user I won’t go through them in detail as it really is just following their instructions and commands provided. I did add the Jessie backports as described here I used the webroot install approach.
  4. I initially had some trouble because one of my sites is using the Yii framework and I didn’t point the certbot certonly command at the webroot, but instead at the code root of the framework. The process will create a .well-known directory and it must be within the webroot so it can be authenticated. The .well-known directory will be empty and it’s OK to have it owned by the root user and group. A successful run of the certbot certonly command will result in a message like “Congratulations! Your certificate and chain have been saved…”
  5. The next thing is to configure your nginx conf file to use the new cert. Also don’t forget to change your conf file to listen to port 443 instead of port 80.
    server {
    	listen 443;
    	ssl on;
    	ssl_certificate /etc/letsencrypt/live/;
    	ssl_certificate_key /etc/letsencrypt/live/;

    Then restart nginx. You may also need to make application changes so the site uses an HTTPS domain depending on the framework or type of application you have.

  6. Last thing to know is the certbot certonly command will create a cron job for you at /etc/cron.d/certbot with the below contents that tries to auto renew twice per day
    0 */12 * * * root test -x /usr/bin/certbot -a \! -d /run/systemd/system && perl -e 'sleep int(rand(3600))' && certbot -q renew