In this post I’ll explain how to run your own Internet radio station. On top of that, I’ll show you how to build an Alexa skill to deploy your station in the cloud, so anyone with Alexa can say: “Alexa, play <whatever_station>” and hear your Internet radio station. There are many tutorials that describe this, but most of them require that you pay for some radio station hosting. If that’s easier for you, then you can skip this tutorial. If you want to have your own radio on the Internet (build from scratch) and deploy it or not on Alexa, than this guide is for you. There are some prerequisites though. You’ll need a CentOS 7 instance with a public IP and if you decide to publish it on Alexa, then you’ll need valid SSL certificate.
IMPORTANT: If your want your station to be public on Alexa, then you also need license for the music. But no worries, if you just want your music played over Alexa at home (and not public), you can still do it.
Also, the ices2 client can’t stream MP3 files, so you have to convert them to OGG. If you want to stream MP3s directly, check the earlier version of ices. The configuration file is almost identical. Ogg-Vorbis is perfectly fine and I’ll show you how to convert your library from MP3 to OGG.
So, there are two parts of this tutorial. Build your own station first and then the optional Alexa part. Let’s start.

CentOS 7

Make sure you have a CentOS 7 instance ready in the cloud with a public IP. NATed instances are OK as long as you can control the ports. In addition, make sure SELinux is disabled. Disabling the OS firewall is optional. I assume that the firewall on the instance is on.

icecast

icecast is a streaming server similar to shoutcast. It broadcasts a stream that’s provided by a source. The source can be a microphone, sound card or a file. In order to stream a file, we need a client such as ices, LiquidSoap etc. You are not the client, you are the listener. Now that we have this straighten up, let’s install icecast from the source. Just copy and paste everything below. If you get an error, execute line by line and see where it fails. Fix any issues, if any.

yum -y groupinstall "Development Tools"
yum install -y wget curl-devel libvorbis-devel libxslt-devel libxslt-devel openssl-devel
cd /tmp
wget http://downloads.xiph.org/releases/icecast/icecast-2.4.4.tar.gz
tar xzvf icecast-2.4.4.tar.gz
cd icecast-2.4.4
./configure --prefix=/opt/icecast --with-curl --with-openssl
make
make install

We specified /opt/icecast where icecast will be installed (line 7). You can change that in the configure statement, but you have to adjust everything after. icecast creates a sample configuration file named icecast.xml under /opt/icecast/etc. If you look at the XML file, you’ll see a bunch of settings and some of them have to be changed.
We’ll change the following parameters:

<location> – Specifies where the radio station is located.
<admin> – An e-mail address of the radio station admin.
<hostname> – A hostname for the radio station. Important only if you are publishing this in YP directory of broadcast streams. Irrelevant for us, but we’ll change it anyway.
<source-password> – A password so the source client can attach to the icecast server and provide the OGG stream.
<relay-password> – Used only if the icecast is used as a relay.
<admin-user> – Username for the admin web page.
<admin-password> – Password for the admin user.
<logdir> – A directory where the log file is stored.
<user> – A local OS user that will run icecast. Don’t use root, it won’t work. You can create a separate user for this. The built-in nobody user is perfectly fine.
<group> – A local OS group that will run icecast.

So, let’s change these manually or with this code. Adjust to suit your needs.

cd /opt/icecast/etc
location="New Jersey"
admin=klimenta@iandreev.com
hostname=radio.iandreev.com
sourcepwd=Sup3rStr0ngP455w0rd
relaypwd=Sup3rStr0ngP455w0rd
admin=myusername
password=Sup3rStr0ngP455w0rd
logdir=/opt/icecast/log
user=nobody
group=nobody
sed -i "s/<location>Earth/<location>$location/" icecast.xml
sed -i "s/<admin>icemaster@localhost/<admin>$admin/" icecast.xml
sed -i "s/<hostname>localhost/<hostname>$hostname/" icecast.xml
sed -i "s/<source-password>hackme/<source-password>$sourcepwd/" icecast.xml
sed -i "s/<relay-password>hackme/<relay-password>$relaypwd/" icecast.xml
sed -i "s/<admin-user>admin/<admin-user>$admin/" icecast.xml
sed -i "s/<admin-password>hackme/<admin-password>$password/" icecast.xml
sed -i "s|<logdir>/opt/icecast/var/log/icecast|<logdir>$logdir|" icecast.xml
sed -i "s/<user>nobody/<user>$user/" icecast.xml
sed -i "s/<group>nogroup/<group>$group/" icecast.xml

Let’s create the log directory and give the icecast daemon permission to write.

cd /opt/icecast
mkdir log
chown -R nobody:nobody log

icecast doesn’t come with a startup systemd script, so we’ll have to take care of that.

cat << EOF > /etc/systemd/system/icecast.service
[Unit]
Description=Icecast Network Audio Streaming Server
After=network.target

[Service]
Type=simple
User=nobody
Group=nobody
ExecStart=/opt/icecast/bin/icecast -c /opt/icecast/etc/icecast.xml
ExecReload=/bin/kill -HUP $MAINPID
ExecStop=/bin/kill $MAINPID

[Install]
WantedBy=multi-user.target
EOF

Now you can enable icecast on boot and start it.

systemctl enable icecast
systemctl start icecast

If you run systemctl status icecast, you should see that the daemon is running. Also, if you check the error log (tail /opt/icecast/log/error.log), you’ll see that the daemon is running too. Ignore the SSL warning for now.
icecast runs on port 8000, so if you have a firewall, you’ll have to poke a hole.

firewall-cmd --add-port=8000/tcp --zone=public --permanent
firewall-cmd --reload

From a browser, go to your server’s IP on port 8000, e.g. http://201.202.203.24:8000 and you’ll see something like this.

If you click on Administration, you’ll be prompted to log in. Use the admin-user and admin-password that you’ve changed in icecast.xml.

ices

Now that we have the streaming server ready, let’s install the source client. The source client will provide the stream to the server. We’ll use ices for this.

cd /tmp
wget http://downloads.us.xiph.org/releases/ices/ices-2.0.2.tar.gz
tar xzvf ices-2.0.2.tar.gz
cd ices-2.0.2
yum -y install libshout-devel
./configure --prefix=/opt/ices
make && make install

ices creates some configuration files under /opt/ices/share/ices. We’ll use the ices-playlist.xml template to generate a radio station for us.

cd /opt/ices/share/ices
cp ices-playlist.xml myradio.xml

Now edit myradio.xml and change the following with a script or manually. Make sure you adjust for your needs.

<logpath> – A directory where the log file is stored.
<logfile> – The name of the log file.
<name> – The name of your radio.
<genre> – Self explanatory.
<description> – Enter a description for your station.
<password> – The password to connect to icecast. It should match the source-password in icecast.xml
<mount> – The name of the mount. This is like the URL for your station. It has to end with .ogg
<param name> – A file where the playlist for this station will be stored.

cd /opt/ices/share/ices
logpath=/opt/ices/log
logfile=myradio.log
name="Radio MyRadio"
genre="Some genre"
descr="Best Radio in the Universe and beyond"
pwd=Sup3rStr0ngP455w0rd
mount=/myradio.ogg
playlist=/opt/ices/playlists/myradio.txt
sed -i "s|<logpath>/var/log/ices|<logpath>$logpath|" myradio.xml
sed -i "s/<logfile>ices.log/<logfile>$logfile/" myradio.xml
sed -i "s/<name>Example stream name/<name>$name/" myradio.xml
sed -i "s/<genre>Example genre/<genre>$genre/" myradio.xml
sed -i "s/<description>A short description of your stream/<description>$descr/" myradio.xml
sed -i "s/<password>hackme/<password>$pwd/" myradio.xml
sed -i "s|<mount>/example1.ogg|<mount>$mount|" myradio.xml
sed -i "s|<param name=\"file\">playlist.txt|<param name=\"file\">$playlist|" myradio.xml

Let’s create two directories. One for the logs and the other for the files where we’ll store playlists. Not the music files – the playlists. The playlists tells ices where to look for your music.

cd /opt/ices
mkdir log playlists
chown -R nobody:nobody log

Create a startup script for ices as well. Look at line 10, that’s where my config file for this radio station is. Can you have multiple radio stations? Absolutely, one icecast server can handle multiple ices clients. Just invoke another ices client with a different config file and create a similar startup script with a different URL, e.g …/myradio.ogg and …/mystation.ogg.

cat << EOF > /etc/systemd/system/ices-myradio.service
[Unit]
Description=Ices Network Audio Streaming Client for MyRadio
After=icecast.service

[Service]
Type=simple
User=nobody
Group=nobody
ExecStart=/opt/ices/bin/ices /opt/ices/share/ices/myradio.xml
ExecReload=/bin/kill -HUP $MAINPID
ExecStop=/bin/kill $MAINPID
Restart=always
RestartSec=3

[Install]
WantedBy=multi-user.target
EOF

At this point you can tell ices where your music is stored. As I mentioned earlier, we’ll have to use Ogg-Vorbis files (.ogg).
So, create a folder where your music files will be stored. I’ll use /music/myradio and put some public royalty free music there.
Courtesy of Patrick de Arteaga. Please give him some credit and visit his site.

mkdir -p /music/myradio
cd /music/myradio
wget -U 'Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.6) Gecko/20070802 SeaMonkey/1.1.4' https://patrickdearteaga.com/audio/Battleship.ogg
wget -U 'Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.6) Gecko/20070802 SeaMonkey/1.1.4' https://patrickdearteaga.com/audio/Chiptronical.ogg
wget -U 'Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.6) Gecko/20070802 SeaMonkey/1.1.4' https://patrickdearteaga.com/audio/Friends.ogg

OK, so we have our music there. When the stream ends, it will start from the first song. Now we have to create the playlist and put it under the /opt/ices/conf directory.
If you remember we specified directive in the myradio.xml file referencing where the playlist is stored. Let’s create the file.

ls -d /music/myradio/*.ogg > /opt/ices/playlists/myradio.txt

Now that we have everything ready, let’s enable ices on boot and start it.

systemctl enable ices-myradio
systemctl start ices-myradio

Check if everything is OK.

systemctl status ices-myradio
tail /opt/ices/log/myradio.log

If everything looks good, you can listen to your stream at http://whateverIP:8000/myradio.ogg.
If you are satisfied with this, you can stop reading. You’ve accomplished enough. If you want to see how to convert MP3 to OGG and how to use a reverse proxy so you can stream over HTTP, then read further.

MP3 to OGG conversion (sox)

If you have a bunch of files that you want to convert to OGG, you can use sox. It’s a very powerful tool for conversion between formats. Let’s install it first.

yum -y install libmad-devel libid3tag-devel lame lame-devel flac flac-devel
cd /tmp
wget https://sourceforge.net/projects/sox/files/sox/14.4.2/sox-14.4.2.tar.gz
tar xvfz sox-14.4.2.tar.gz
cd sox-14.4.2
./configure
make -s && make install

Now you can convert the files from MP3 to OGG and vice versa. Conversion is very simple. Just specify the source and the destination file, e.g. sox file1.mp3 file1.ogg and that’s it. If you want to see the details of the file such as bit-rate, duration, sample etc, use soxi, e.g. soxi file.ogg. If you want more details on sox and it’s usage, please check their website. For soxi, check this link.
If you want to convert your files in bulk, you can use this command that will search for MP3 files in your current directory and subdirectories and convert them to OGG.

find . -type f -name "*.mp3" -exec sh -c 'sox "$1" "${1%.mp3}.ogg"' _ {} \;

nginx as reverse proxy

If you recall, we are using http://somenameorip:8000/myradio.ogg to access our station. This is fine for regular users from their home, but in any corporate environment, anything than port 80 and 443 are blocked. So, we have to stream our music over port 80. I’ll show later how to stream over 443 because it’s a requirement for Alexa. First thing first, let’s install nginx.

yum -y install nginx
systemctl enable nginx

nginx creates a configuration file under /etc/nginx called nginx.conf. Look for this snippet in the configuration file.

        location / {
        }

…and change it to this.

        location /myradio.ogg {
          proxy_set_header Host $host;
          proxy_set_header X-Real-IP $remote_addr;
          proxy_pass http://localhost:8000/myradio.ogg;
        }

You can start the reverse proxy now and verify that it’s working.

systemctl start nginx
systemctl status nginx

Because we are proxying over HTTP, we have to open the firewall too and if you want you can close port 8000. It’s not needed anymore.

firewall-cmd --add-port=80/tcp --zone=public --permanent
firewall-cmd --remove-port=8000/tcp --zone=public --permanent
firewall-cmd --reload

Now you can access your station as http://serveriporname/myradio.ogg, so there is no need to specify port 8000.

SSL certificate

If you decide to publish your station on Alexa, you’ll need a valid (not self-signed) certificate. You will also need to reconfigure both nginx and icecast to use SSL. You can’t access your server by IP because you’ll get an invalid certificate warning, so make sure you have your DNS ready to resolve your IP to a valid domain name. Get the certificates ready. You’ll need the private key, the certificate, the intermediate certificate and the root CA certificate. When you purchase a certificate all of these will be available for you (except for the private key).
Let’s create the chain. In my case, I have each certificate in a separate file and I’ll create one certificate for icecast.

mkdir /opt/icecast/ssl
cat star.iandreev.com.key star.iandreev.com.crt star.iandreev.com.inter star.iandreev.com.CA > /opt/icecast/ssl/icecast.pem
chown -R nobody:nobody /opt/icecast/ssl

Then, edit /opt/icecast/etc/icecast.xml and find the following snippet.

    <listen-socket>
        <port>8000</port>
    </listen-socket>

Copy these three lines after, so the config looks like this now. We are telling icecast to spawn itself and listen on port 8443 too.

    <listen-socket>
        <port>8000</port>
    </listen-socket>
    <listen-socket>
        <port>8443</port>
        <ssl>1</ssl>
    </listen-socket>

We also have to specify the certificate chain. Find this line in the config and uncomment it. Make sure you uncomment the line, it’s commented by default.

<ssl-certificate>/opt/icecast/ssl/icecast.pem</ssl-certificate>

Now, you have to restart icecast and ices too.

systemctl restart icecast
systemctl restart ices-myradio

And if you check the error.log (yes, error log), you’ll see that icecast is using SSL now.

tail /opt/icecast/log/error.log
[2019-10-03  22:29:23] INFO connection/get_ssl_certificate SSL certificate found at /opt/icecast/ssl/icecast.pem
[2019-10-03  22:29:23] INFO connection/get_ssl_certificate SSL using ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES

Now the nginx part. Edit /etc/nginx/nginx.conf.

– uncomment the section for “a TLS enabled server”. Remove the # from all the lines below # Settings for a TLS enabled server. Don’t uncomment this line.
– Replace location / {} with this snippet. Not the first occurrence for port 80. This is for port 443.

        location /myradio.ogg {
          proxy_set_header Host $host;
          proxy_set_header X-Real-IP $remote_addr;
          proxy_pass http://localhost:8000/myradio.ogg;
        }

– Copy your private key to /etc/pki/nginx/private/server.key and your public certificate to /etc/pki/nginx/server.crt. If the directories do not exists, create them. (cd /etc/pki && mkdir -p nginx/private). Also, make sure that the certificate (server.crt) is a chain of certificates, not just a simple server certificate. If you do curl -iv https://yoursite.com, the result for the SSL should be clear without any errors or warning. You can reuse the icecast.pem certificate for icecast and copy that file as server.crt under /etc/pki/nginx/. You can even reference the same file in the same directory, but then you have to change the config files and permissions.
– Reload nginx (systemctl reload nginx)
– Open the firewall

firewall-cmd --add-port=443/tcp --zone=public --permanent
firewall-cmd --reload

Now you can access your server with https. If you want to be even more precise, you can redirect the http to https, so you don’t have to specify the protocol in the browser. Edit nginx.conf and add line 5. Reload nginx after (systemctl reload nginx).

server {
    listen       80 default_server;
    listen       [::]:80 default_server;
    server_name  _;
    return 301 https://$host$request_uri;
    root         /usr/share/nginx/html;

Here is my /etc/nginx/nginx.conf file.

user nginx;
worker_processes auto;
error_log /var/log/nginx/error.log;
pid /run/nginx.pid;

# Load dynamic modules. See /usr/share/nginx/README.dynamic.
include /usr/share/nginx/modules/*.conf;

events {
    worker_connections 1024;
}

http {
    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';

    access_log  /var/log/nginx/access.log  main;

    sendfile            on;
    tcp_nopush          on;
    tcp_nodelay         on;
    keepalive_timeout   65;
    types_hash_max_size 2048;

    include             /etc/nginx/mime.types;
    default_type        application/octet-stream;

    # Load modular configuration files from the /etc/nginx/conf.d directory.
    # See http://nginx.org/en/docs/ngx_core_module.html#include
    # for more information.
    include /etc/nginx/conf.d/*.conf;

    server {
        listen       80 default_server;
        listen       [::]:80 default_server;
        server_name  _;
        return 301 https://$host$request_uri;
        root         /usr/share/nginx/html;

        # Load configuration files for the default server block.
        include /etc/nginx/default.d/*.conf;

        location / {
          proxy_set_header Host $host;
          proxy_set_header X-Real-IP $remote_addr;
          proxy_pass http://localhost:8000/myradio.ogg;
        }

        error_page 404 /404.html;
            location = /40x.html {
        }

        error_page 500 502 503 504 /50x.html;
            location = /50x.html {
        }
    }

# Settings for a TLS enabled server.

    server {
        listen       443 ssl http2 default_server;
        listen       [::]:443 ssl http2 default_server;
        server_name  _;
        root         /usr/share/nginx/html;

        ssl_certificate "/etc/pki/nginx/server.crt";
        ssl_certificate_key "/etc/pki/nginx/private/server.key";
        ssl_session_cache shared:SSL:1m;
        ssl_session_timeout  10m;
        ssl_ciphers HIGH:!aNULL:!MD5;
        ssl_prefer_server_ciphers on;

        # Load configuration files for the default server block.
        include /etc/nginx/default.d/*.conf;

        location /myradio.ogg {
          proxy_set_header Host $host;
          proxy_set_header X-Real-IP $remote_addr;
          proxy_pass http://localhost:8000/myradio.ogg;
        }

        error_page 404 /404.html;
            location = /40x.html {
        }

        error_page 500 502 503 504 /50x.html;
            location = /50x.html {
        }
    }

}

Alexa

Now comes the fun part. It’s much easier than you think thanks to Andy Moore. He has a great step-by-step tutorial for this. I’ll quickly go over what’s needed.
You’ll need your:

– Radio station name
– Name of your website
– URL of your stream (it has to be https)

Fun fact. I named my station Radio Andreev and whatever I said, Alexa couldn’t understand. It was looking for Radio Andrea all the time. So, do yourself a favor and name your station something that Alexa can understand. I named my station Radio Tincup, my website is https://radio.iandreev.com and the stream is at https://radio.iandreev.com/myradio.ogg. Generate the JSON from the site above or get this code and change your values. Click the (+) sign to expand.

{
  "interactionModel": {
    "languageModel": {
      "invocationName": "radio tincup",
      "intents": [
        {
          "name": "AMAZON.CancelIntent",
          "samples": [
            "Cancel"
          ]
        },
        {
          "name": "AMAZON.HelpIntent",
          "samples": [
            "Help"
          ]
        },
        {
          "name": "AMAZON.StopIntent",
          "samples": [
            "Stop"
          ]
        },
        {
          "name": "Play",
          "samples": [
            "Ask radio tincup to play radio tincup",
            "Start radio tincup",
            "Ask radio tincup to play",
            "Play radio tincup"
          ]
        },
        {
          "name": "AMAZON.NavigateHomeIntent",
          "samples": []
        },
        {
          "name": "AMAZON.PauseIntent",
          "samples": []
        },
        {
          "name": "AMAZON.ResumeIntent",
          "samples": []
        }
      ],
      "types": []
    }
  }
}

And this is your JavaScript.

const Alexa = require('ask-sdk-core');
var https = require('https');

const PlayHandler = {
	canHandle(handlerInput)
	{
		return (
			handlerInput.requestEnvelope.request.type === 'LaunchRequest' ||
			(
				handlerInput.requestEnvelope.request.type === 'IntentRequest' &&
				handlerInput.requestEnvelope.request.intent.name === 'Play'
			) ||
			(
				handlerInput.requestEnvelope.request.type === 'IntentRequest' &&
				handlerInput.requestEnvelope.request.intent.name === 'AMAZON.ResumeIntent'
			)
		);
	},
	handle(handlerInput)
	{
		return handlerInput.responseBuilder
			.addDirective({
				type: 'AudioPlayer.Play',
				playBehavior: 'REPLACE_ALL',
				audioItem:{
					stream:{
						token: '0',
						url: 'https://radio.iandreev.com/myradio.ogg',
						offsetInMilliseconds: 0
					}
				}
			})
			.getResponse();
	}
};

const PauseStopHandler = {
	canHandle(handlerInput)
	{
		return (
				handlerInput.requestEnvelope.request.type === 'IntentRequest' &&
				(
					handlerInput.requestEnvelope.request.intent.name === 'AMAZON.CancelIntent' ||
					handlerInput.requestEnvelope.request.intent.name === 'AMAZON.StopIntent'
				)
			) ||
			(
				handlerInput.requestEnvelope.request.type === 'IntentRequest' &&
				handlerInput.requestEnvelope.request.intent.name === 'AMAZON.PauseIntent'
			);
	},
	handle(handlerInput)
	{
		return handlerInput.responseBuilder
			.addDirective({
				type: 'AudioPlayer.ClearQueue',
				clearBehavior: 'CLEAR_ALL'
			})
			.getResponse();
	}
};

const HelpIntentHandler = {
	canHandle(handlerInput)
	{
		return handlerInput.requestEnvelope.request.type === 'IntentRequest' &&
			handlerInput.requestEnvelope.request.intent.name === 'AMAZON.HelpIntent';
	},
	handle(handlerInput)
	{
		const speechText = 'You can say Play, Stop or Resume. For more information please visit radio dot iandreev dot com';
		return handlerInput.responseBuilder
			.speak(speechText)
			.getResponse();
	}
};

const SessionEndedRequestHandler = {
	canHandle(handlerInput)
	{
		return handlerInput.requestEnvelope.request.type === 'SessionEndedRequest';
	},
	handle(handlerInput)
	{
		return handlerInput.responseBuilder.getResponse();
	}
};

const IntentReflectorHandler = {
	canHandle(handlerInput)
	{
		return handlerInput.requestEnvelope.request.type === 'IntentRequest';
	},
	handle(handlerInput)
	{
		const intentName = handlerInput.requestEnvelope.request.intent.name;
		const speechText = 'NO INTENT HELP TEXT';
		return handlerInput.responseBuilder
			.speak(speechText)
			.getResponse();
	}
};

const ErrorHandler = {
	canHandle()
	{
		return true;
	},
	handle(handlerInput, error)
	{
		const speechText = `Sorry, I could not understand what you said. Please try again.`;
		return handlerInput.responseBuilder
			.speak(speechText)
			.reprompt(speechText)
			.getResponse();
	}
};

exports.handler = Alexa.SkillBuilders.custom()
	.addRequestHandlers(
		PlayHandler,
		PauseStopHandler,
		HelpIntentHandler,
		SessionEndedRequestHandler,
		IntentReflectorHandler)
	.addErrorHandlers(
		ErrorHandler)
	.lambda();

Go to https://developer.amazon.com and log in (or register). Make sure you use the same account in the developer console with the same account that you have your Alexa configured. Once logged in, click on Alexa from the menu and then Alexa Skills Kit.

Click Create Skill. Enter the name of your station and the language.

Choose a Custom model.

Choose Alexa-Hosted.

Scroll up and in the top right corner click Create skill. After 30-40 seconds, you’ll be presented with a different screen. On the left side find the Interfaces menu, then click on it. Then enable the Audio Player on the right.

Scroll up and click on Save Interfaces first, then Build Model.

Click on the JSON Editor on the left, right above Interfaces. Once the editor shows up, delete everything there and paste the JSON file.

Click Save Model then Build Model from the top.

Click on Code from the top and paste the JavaScript in the editor.

Click Save then Deploy from the upper right.

Click on Test, allow access to the microphone and change Skill testing from Off to Development.

Now, with the mouse hit the microphone icon, hold it there, say Alexa Play Radio Tincup and release the button.

Here is what I was talking to. Alexa can’t understand me…or maybe my mic is bad. If Alexa doesn’t understand, just type “Alexa play Radio Tincup” in the text field.

You won’t hear Alexa playing and you won’t hear any music from the computer, but you’ll see a JSON response with the valid URL of your OGG stream.

At this point you are all set. You can play your music using Alexa. For most people this would be the end. But if you really like to publish your station to be public, then proceed. In the console, click on Distribution.

You’ll see a bunch of questions regarding the nature of your station, are you collecting customer information, are you advertising and so on. Just follow the process and hopefully, you’ll get your station published.

Cleanup

You might want to delete the tarballs for the icecast, ices and sox that you’ve downloaded.

rm -rf /tmp/ice*
rm -rf /tmp/sox*

You’ll also want to make sure that the firewall allows only port 80 and 443. Ports 8000 and 8443 can be, but they don’t have to be exposed to the Internet.

firewall-cmd --remove-port=8000/tcp --zone=public --permanent
firewall-cmd --remove-port=8443/tcp --zone=public --permanent
firewall-cmd --reload

If you have some on-prem workloads (either virtual or physical servers) and you want to migrate them to Azure, this post might be for you. I’ll describe how to migrate these servers in Azure using Azure Migrate and Azure Site Recovery. These tools (actual VMs) will have to be installed in your on-prem environment and they’ll do the heavy lifting for you. Before I begin, there are some pre-requisites. You’ll need a valid Azure subscription, supported VMware vCenter (v5.5 and above) and resources to install two VMs. On my ESXi host, using thin provisioned storage, I needed 8 CPUs, 32GB RAM and 20GB-80GB thin provisioned storage for Azure Migrate: Server Assessment and 8CPUs, 32GB RAM and 40GB disk for Azure Migrate: Server Migration tool. It will take much more space if you have a lots of VMs. I have about 15. You’ll also need a VNET(s) and subnet(s) where you’ll migrate the VMs.
I’ll configure that first. I’ll give you an example of how to migrate a two-tier Windows application (web server + MS SQL server) and a WordPress server running on two CentOS 7 servers.

Azure VNET/subnet

Log to your Azure subscription and create a resource group for the migration. I’ll name mine rgMigration.

Then create a new VNET and a subnet where you’ll migrate your VMs. You can use the same subnets as on-prem but only if you don’t have a ExpressRoute or VPN between on-prem and Azure. In my case, I have a VPN between my home-lab and Azure, so I have to choose a different subnet. I named my VNET vnetMigration and the subnet subServers.

Azure Migrate

Once completed, in the Azure portal in the middle upper search field, start typing migrate and select Azure Migrate.

You’ll be presented with different options to migrate data, SQL, servers etc. Choose this one that says migrate servers.

Click on Add tool(s).

You’ll be prompted to choose the subscription, the resource group, name the project and choose the region. Use whatever suits your needs and click Next.

There are several tools there, we’ll use the Microsoft Migrate: Server Assessment. Click on it to highlight and click Next.

For the migration tool, we’ll choose Azure Migrate: Server Migration. Select, click Next and finally click Add tool(s).

It takes about a minute to provision the tools. You’ll see two tiles on your screen, one for the Assessment tool and the other for the migration.

We’ll use the first tool to assess the on-prem servers. This tool will tell us if we have servers that can be actually moved to Azure cloud and it will recommend the size of those servers.

Server Assessment

Click on Discover first. You’ll see another screen where you can download an OVA file for your vCenter. Download the file and deploy the OVA file (v2.19.07.30). I won’t go into details how to do this, it’s super easy. Once you have your VM from the OVA file up and running, open the console for that VM, accept the EULA, change the admin password and log in as Administrator with the password that you just specified. You might also want to change the IP from DHCP to static before proceeding. In addition, disable the IE Enhanced Security Configuration from the Server Manager or you’ll get bombarded with annoying popups from IE.
On the desktop, there should be two files, one text file with the appliance version and a shortcut to Microsoft Azure Appliance Configuration Manager. Accept the license terms for the appliance.

Wait for the appliance to do the pre-flight checks and then install VMware vSphere Virtual Disk Development Kit.

Pretty much, you’ll have to download a ZIP file from VMware site, extract the ZIP and put it under C:\Program Files\VMWare\VMWare Virtual Disk Development Kit.

Click Verify and Install and Continue. Then, login to Azure portal from the appliance to register it.

Fill out the subscription, specify the migration project and enter a name for this appliance. Click Register and once successfully registered click Continue.

Specify the vCenter where your VMs reside, enter the username and password and click to Validate Connection.

Finally if everything is OK, click on Save and start discovery.
NOTE from the appliance: You will be able to review the discovered machines on the Azure portal and create as-on-premises assessments within 15 minutes. Collection of performance data will be initiated and it is recommended that you create performance-based assessments after 24-hours.
It’s important to leave the appliance running for some time so it can properly determine the usage and size the destination VM for you. If you already know what size your VM will be in Azure, you don’t have to worry about this.
Now, go back to Azure portal and find the Azure Migrate service. Click on Servers and then on Discovered servers under Assessment tools.

You’ll see a list of all servers in your vCenter and their specs. We’ll create a new assessment group for two Linux servers that I have (apache and mysql) and that are part of my local WordPress installation.

Then, create an assessment for that same group from the top menu.

Make sure you change the assessment properties. That’s where you specify the region. Just click on View all and change the settings there.

Now if you go back to the Azure Migrate, you’ll see that you have one group and one assessment.

Click on the Groups and then on the actual group. You’ll see something like this.

If you want to see what your server is doing in terms of connections to others servers over TCP/UDP, you have to install the agent. It’s not necessary, but you’ll see the dependencies. It’s useful when you migrate some servers as a group and then you realize that you need to migrate another server because there is a dependency.

Dependencies agent

Click on the link Requires agent installation and you’ll see this page. Pretty much you have to install two agents on each server and configure them. But, first you have to configure the OMS Workspace that gathers metadata from the VMs.

Click on Configure OMS workspace first. Type a name a region and click Configure at the bottom.

Linux

Download both files. You’ll get redirected to github for the first agent. Download omsagent-1.11.0-9.universal.x64.sh for a 64-bit Linux OS or whatever is the latest version. This is a bash script file with an embedded tar binary file. Transfer it to the Linux box, make sure it’s executable and run the script. Check this link for your version of Linux/Unix. Make sure you specify the Workspace ID and the Workspace Key, which you can get at the bottom of the page from the Dependencies screenshot (see the previous screenshot above).

wget https://github.com/microsoft/OMS-Agent-for-Linux/releases/download/OMSAgent_v1.11.0-9/omsagent-1.11.0-9.universal.x64.sh
chmod +x omsagent-1.11.0-9.universal.x64.sh
./omsagent-1.11.0-9.universal.x64.sh --install --enable-opsmgr -w <workspaceID> -s <workspaceKey>

You should see a message saying Shell bundle exiting with code 0.
For the second agent, download it from the Microsoft site, change the permission to execute and run.

wget http://aka.ms/dependencyagentlinux -O InstallDependencyAgent-Linux64.bin
chmod +x InstallDependencyAgent-Linux64.bin
./InstallDependencyAgent-Linux64.bin

Type YES when prompted and you should be good.

Windows

Download both files (MMASetup-AMD64.exe and InstallDependencyAgent-Windows.exe). Install on each server. For the MMA agent, check to connect the agent to Azure Log Analytics (OMS).

Enter the Workspace ID and the key and choose Azure Commericial.

Installing the dependency agent is even easier, just double-click the EXE and accept the agreement. From the Discovered servers list, click on the server where it says View dependencies and you’ll something like this.

Click on each block to see more details.

Server Migration

Once we have all the pre-requisites in place and we are all confident in the assessment based on the confidence rating, we can proceed with the migration.

Now, you can do the migration within Azure Migrate: Server Assessment tool. Just click on Discovered Servers under the tool and click Replicate from the menu.
Specify the type of the hypervisor and the on-prem appliance.

As you can see from the appliance suffix, the migration option of the assessment tool is in preview. You can proceed further. In the screenshot below, I’ll be migrating my Linux servers.

You just have to specify where you want your servers migrated.

Choose the size of the servers, the disk size and you can proceed.

This is probably the way to go, but because it’s in preview, I’ll explain the old way too.
Under the migration tool, click Discover.

Specify where do you want your VMs migrated. This is an important step. Click on Create resources.

Finish step 1. Download the OVA and install it in your vCenter. Same as with the previous OVA, log to the console, and change the IP to static. First, you’ll be prompted to name the appliance.

Then log in to Azure portal.

Configure the appliance using the Site Recovery icon on the desktop. It’s gonna ask you to log (again) to Azure and provide the subscription, resource group and the vault. Make sure you choose the vault that’s provided in the same dialog box where you downloaded the OVA. If you fail to provide the proper vault, you’ll have to deal with deleting hidden resources etc…

Next step is to agree to install MySQL server on the appliance and specify the vCenter.

You should also add the credentials for Windows and Linux servers. For example, my username has full access to all Windows VMs and root has access to all Linux servers.

Once completed, you can go to the Azure Portal and if you click on Replicate, you’ll see that our new appliance showed up.

If you are having problems finding out where to register the new appliance, go to the Replicate menu. Fill out the pre-requisites and you’ll get a warning that your appliance is not registered. Click Finalize registration from here.

As you can see, with this tool, migrate is grayed. First, we’ll have to replicate the servers.

Fill out the settings and proceed. Make sure you choose the right credentials. I’ll be replicating Linux instances, so I chose Linux-CREDS. These were defined when we configured the appliance.

Choose the VMs.

Choose the VNET, subnet etc…

Choose the rest of the requirements (disk etc…) and click on Replicate.
You can check the status from the tool. Click on Overview, then Replicating machines, then click the Other tab.

Once the replication is completed, you can do a Test migration or full migration. Click on the menu (three dots) on the right of each VM and do a Test migration first. If you a confident, you can do full migration as well.

For a test migration, you have to specify a VNET. When you do a test migration, the original VM stays up and the new VM in Azure has a -test suffix. Here I have my apache server test-migrated in Azure.

And I can access it over my VPN.

When you a done, you can clean up the test migration from the same menu above and you’ll get an option to delete the test VM. Finally, once everything is OK, you can do a full migration. Click Migrate and you’ll be all set.
NOTE: If you can’t RDP to your VM in Azure, it’s because RDP port was disabled. You can re-enable it from the console. Go to the VM menu and all the way down, click on Reset password. Do Reset configuration only and after a minute or so, you’ll be able to RDP.

And if you get this error, The remote computer requires Network Level Authentication…blah, blah, domain controller.

…then log as local administrator and check the DNS settings. Most likely the DNS settings were messed up when migrating. Here is an example of what I got from my VM in Azure.

  Default Gateway . . . . . . . . . : 192.168.10.1
  DHCP Server . . . . . . . . . . . : 168.63.129.16
  DHCPv6 IAID . . . . . . . . . . . : 352324922
  DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-25-0F-72-AF-00-50-56-B9-F7-0F
  DNS Servers . . . . . . . . . . . : 168.63.129.16

Azure assigned a DNS in Azure. Change it to your DNS and you should be OK.

Migrating a physical server

In order to migrate a physical server, you’ll have to follow these steps. In essence, you’ll have to log to the Azure Site recovery VM and go to this folder (C:\ProgramData\ASR\home\svsystems\pushinstallsvc\repository). Transfer the ASR file to each physical instance. While logged in the appliance, get your key.

C:\ProgramData\ASR\home\svsystems\bin\genpassphrase.exe -v

Don’t run the EXE on the VM yet. You’ll have to do it from a command prompt. Open up a command prompt (with admin rights) and execute these lines.

mkdir c:\temp
cd c:\<path_to_EXE>
ren Mi<hit_TAB_for_autocompletion> MobilityServiceInstaller.exe 
move MobilityServiceInstaller.exe c:\temp
cd c:\temp
MobilityServiceInstaller.exe /q /x:C:\Temp\
UnifiedAgent.exe /Role "MS" /Silent

The last command will open a new terminal window and install the agent. Wait to finish and you can exit. Then in the GUI go to c:\program files (x86)\Microsoft Azure Site Recovery\agent folder. Double-click the UnifiedAgentConfigurator.exe file and enter the IP of your Site Recovery appliance and the passphrase that you got from the command above.

After 10 seconds you should have everything ready.

Go back to the portal and in the Azure Migrate: Server Migration tool, click on Replicate. Under the Source settings tab, select that your machines are NOT virtualized. Choose the Site Recovery appliance and specify the credentials that will be used to access the physical server.

You don’t have an assessment for the physical server, so choose to specify the migrations settings manually. My physical server is called W2012R2.

Choose the subscription, VNET, subnet under Target settings. Choose automatic or specify the compute type of your instance under Compute tab and do the same for the disks under the next tab.

Click Replicate when ready. After a minute or so, you can check the status under Replicating servers.

…and same with the other VMs that were replicated, you can do a test migration and full migration. Once you power up the replicated server, make sure you uninstall any HW related software for the arrays, WMI management etc… And pretty much that’s it!

My plan was to see if I can move my blog to use containers instead of a server, so I decided to try and see if WordPress would work on AWS ECS. The result is mixed. While I was able to run WordPress without any issues, the performance wasn’t that good and I had problems figuring out when to scale in and out. I wouldn’t say that WordPress architecture is not meant to be containerized, but there were some challenges along the way. So, use this post more as a guide for ECS and how to containerize an application, not as a guide on making WordPress work as a container.

Pre-requisites

In order to make a Docker image and upload it to the AWS Docker Registry (ECR), we’ll need a Linux machine (I am using CentOS), Docker, AWS CLI and AWS ECS CLI installed. You can see how to install Docker in my other post. Same for AWS CLI, you can use one of my earlier guides. And for installing AWS ECS CLI, you can visit the official AWS page.
Make sure you get some output for all three commands.

docker ps
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES
aws --version
aws-cli/1.16.96 Python/2.7.5 Linux/3.10.0-957.5.1.el7.x86_64 botocore/1.12.86
ecs-cli --version
ecs-cli version 1.12.1 (e70f1b1)

EFS file system

We’ll use AWS EFS as a shared file system for all containers. The containers will have Apache + PHP7 on the OS partition and the WordPress will be on a NFS file share. That way all containers will write to a same WordPress instance. But before we create that, let’s create a security group that will allow access to our NFS share.
In my case, the security group looks like this.

The port 2049 is the NFS port. The source subnet 172.17.0.0/16 is the subnet for the containers. When you launch a container, its IP will be in this subnet. The second subnet 172.31.0.0/16 is the subnet of the VPC where the containers reside. Why do we need this subnet? Well, we’ll have to download the WordPress ZIP file and extract it on the NFS filesystem. Because we can’t browse the file system from the console, we’ll have to use a temp instance to transfer the files. Make sure the instance and the EFS file system are in the same AZ. So, create the security group and the EFS filesystem and make sure you assign the security group to the EFS. Mine looks like this.

Once you have the EFS ready, get its DNS name.

Spin up an instance in the same VPC where you created the EFS file system. Download the latest WordPress archive and open it.

cd /tmp
wget https://www.wordpress.org/latest.zip
unzip latest.zip

Mount the NFS and unzip the files there. Make sure you put your DNS name here.

mkdir /mnt/nfs
mount -t nfs fs-3b6XXXXX.efs.us-east-1.amazonaws.com:/ /mnt/nfs
cd /tmp
cp -R wordpress/* /mnt/nfs

The idea is to get the WordPress extracted in the root of the NFS, so it looks like this.

[root@guac nfs]# ls -l /mnt/nfs
total 204
-rw-r--r--.  1 nfsnobody nfsnobody     0 Feb  7 19:13 health.txt
-rw-r--r--.  1 nfsnobody nfsnobody   418 Feb  5 16:14 index.php
-rw-r--r--.  1 nfsnobody nfsnobody 19935 Feb  5 16:14 license.txt
-rw-r--r--.  1 nfsnobody nfsnobody  7415 Feb  5 16:14 readme.html
-rw-r--r--.  1 nfsnobody nfsnobody  6878 Feb  5 16:14 wp-activate.php
drwxr-xr-x.  9 nfsnobody nfsnobody  6144 Feb  5 16:14 wp-admin
-rw-r--r--.  1 nfsnobody nfsnobody   364 Feb  5 16:14 wp-blog-header.php
-rw-r--r--.  1 nfsnobody nfsnobody  1889 Feb  5 16:14 wp-comments-post.php

Now, we are ready to create the image.

Dockerfile

Here is my Dockerfile that I used to build the image. Make sure you put your EFS DNS in line 17.

FROM alpine:3.8

LABEL maintainer "kliment@andreev.it"

RUN apk update && apk upgrade && apk add apache2 && \
    apk add php7-fpm apache2-proxy bash php7-mysqli && \
    apk add php7-gd php7-curl nfs-utils && \
sed -i '/mod_mpm_prefork/s/^/#/' /etc/apache2/httpd.conf && \
sed -i '/^#.*mod_mpm_event/s/^#//' /etc/apache2/httpd.conf && \
sed -i '/^#.*slotmem_shm/s/^#//' /etc/apache2/httpd.conf && \
sed -i '/ServerName www/s/^#//g' /etc/apache2/httpd.conf && \
sed -i $'/<IfModule dir_module>/a \    ProxyPassMatch ^/(.*\.php(/.*)?)$ fcgi://127.0.0.1:9000/var/www/localhost/htdocs' /etc/apache2/httpd.conf && \
sed -i 's/DirectoryIndex index.html/DirectoryIndex index.php index.html/' /etc/apache2/httpd.conf && \
sed -i 's|ErrorLog logs/error.log|ErrorLog /dev/stdout|' /etc/apache2/httpd.conf && \
sed -i 's|CustomLog logs/access.log combined|CustomLog /dev/stdout combined|' /etc/apache2/httpd.conf && \
echo 'PidFile /var/run/httpd.pid' >> /etc/apache2/httpd.conf && \
echo 'fs-3b6XXXXX.efs.us-east-1.amazonaws.com:/       /var/www/localhost/htdocs    nfs     defaults 0 0' >> /etc/fstab

COPY script.sh /usr/sbin/script.sh

EXPOSE 80

CMD ["/bin/bash", "/usr/sbin/script.sh"]

I won’t go into details, the script is self explanatory. First we download the necessary packages, make some changes in httpd.conf and mount the NFS on boot. Each container will expose port 80 and it will run a script on each startup.
Here is the script. It should be in the same directory as the Dockerfile. Change the DNS EFS in line 10.

# Start the PHP-FPM process
/usr/sbin/php-fpm7 -D
status=$?
if [ $status -ne 0 ]; then
  echo "Failed to start php-fpm7: $status" >> /var/log/script.log
  exit $status
fi

# Mount the NFS share
/bin/mount -t nfs4 -o nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport fs-3bXXXXX.efs.us-east-1.amazonaws.com:/ /var/www/localhost/htdocs
status=$?
if [ $status -ne 0 ]; then
  echo "Failed to mount NFS share: $status" >> /var/log/script.log
  exit $status
fi

# Add health check file
/bin/touch /var/www/localhost/htdocs/health.txt

# Change ownership of www root
/bin/chown -R nobody:nobody /var/www/localhost/htdocs

# Start the Apache process
/usr/sbin/httpd -D FOREGROUND
status=$?
if [ $status -ne 0 ]; then
  echo "Failed to start httpd: $status" >> /var/log/script.log
  exit $status
fi

Now, you can build the image.

docker build --rm -t wordpress:1.0 .

ECR

Once we have the image ready, we can upload it to the ECR (the container registry). Replace XYZ with your AWS account number in lines 3 and 4.

$(aws ecr get-login --no-include-email)
aws ecr create-repository --repository-name wordpress
docker tag wordpress:1.0 XYZ.dkr.ecr.us-east-1.amazonaws.com/wordpress:1.0
docker push XYZ.dkr.ecr.us-east-1.amazonaws.com/wordpress:1.0

If you go to ECR, you’ll see the image there.

RDS

We’ll need a MySQL database for WordPress. But before we create the database, create a security group and allow the following subnets and ports. We’ll assign this group to the RDS database.

You can create the database now. I’ll create a MariaDB RDS. Nothing specific here, just make sure it’s not publicly accessible. I’ve created the database using CLI. In my case, I use 20GB storage, t2.small instance, the name of the instance is dbwordpress, a MariaDB SQL instance. The admin username is dbmaster with dbpassword as password. I’ve attached the security group sg-ID that I just created previously. The DB will in a single AZ and without public access. Finally, I’ll create a database called wordpress.

aws rds create-db-instance --allocated-storage 20 --db-instance-class db.t2.small --db-instance-identifier dbwordpress --engine mariadb --master-username dbmaster --master-user-password dbpassword --vpc-security-group-ids sg-ID --no-multi-az --no-publicly-accessible --db-name wordpress

CloudWatch

In my Dockerfile, I’ve changed the httpd.conf file, so all the logs are going to the console. This is the original config.

ErrorLog logs/error.log
CustomLog logs/access.log combined

And this is the modified httpd.conf config.

ErrorLog /dev/stdout
CustomLog /dev/stdout combined

In CloudWatch go to Logs and create a new Log Group called /ecs/WordPress.

ECS

Go to ECS and create a new cluster. It has to be EC2 Linux + Networking. Name the cluster and choose On-Demand Instances.

Choose the instance type, 2 instances and the key to log to the instances if needed.

Select your VPC and for a security group choose or create one that has port 80 allowed from everywhere (0.0.0.0/0). Let’s call this security group sgECS. You can also create your ECS cluster with CLI.

ecs-cli up --keypair MyKeyPair --instance-type t3.medium  --size 2 --cluster clusterWordPress --capability-iam --security-group sg-ID1 --vpc vpc-ID --subnets subnet-XY1,subnet-XY2 --verbose

Where sg-ID1 is a security group that allows port 80 from 0.0.0.0/0, vpc-ID is the ID of your VPC where the RDS and EFS are and choose two subnets from that VPC where the instances will be created. It’s recommended that the subnets you choose are the same where the RDS and the EFS are located.
Now, we have to create a task that will include the Docker image that we created. We can’t do that in the console because the NFS mount parameter requires an argument that can’t be specified there. So, we have to create a JSON file and create the task from CLI. If we would’ve run the image from a command line, we would have to specify the sys_admin parameter. This parameter can’t be specified in the task screen, but can be specified in JSON.

docker run --name wordpress --cap-add sys_admin -d wordpress:1.0

So, create the following JSON file and save it as task-wordpress.json.

{
  "containerDefinitions": [
    {
      "portMappings": [
        {
          "hostPort": 0,
          "protocol": "tcp",
          "containerPort": 80
        }
      ],
      "linuxParameters": {
         "capabilities": {
             "add": ["SYS_ADMIN"]
          }
      },
      "logConfiguration": {
          "logDriver": "awslogs",
          "options": {
              "awslogs-group": "/ecs/WordPress",
              "awslogs-region": "us-east-1",
              "awslogs-stream-prefix": "ecs"
          }
      },
      "memoryReservation": 1024,
      "volumesFrom": [],
      "image": "XYZ.dkr.ecr.us-east-1.amazonaws.com/wordpress:1.0",
      "essential": true,
      "name": "cWordPress"
    }
  ],
  "placementConstraints": [],
  "family": "taskWordPress",
  "requiresCompatibilities": [
    "EC2"
  ],
  "networkMode": "bridge",
  "volumes": []
}

Create the task from CLI.

aws ecs register-task-definition --cli-input-json file://task-wordpress.json

Line 6 maps port 0 to port 80 on each container, which means a random port on the host. We can’t have multiple containers listen on port 80.
Line 13 allows mount command to be run from the container, otherwise it will fail. We specify the CloudWatch log group in line 19. Line 24 allows 1GB soft-limit for each container. Replace XYZ in line 26 with you account number. That’s the Docker image. And we’ll use a bridge mode.
Once you complete this, you’ll have your task under Task Definitions.

ELB

Before we proceed with the ECS, we’ll have to create a load balancer. But before we create a load balancer, let’s create a new security group. Let’s call this security group sgELB. This security group should allow port 80 from everywhere. In addition, because we won’t be exposing the ECS clusters to the internet and the containers will run Apache on a random port, we have to modify the group for the ECS cluster. So, find the group (sgECS) that you specified when you created the ECS cluster (ecs-cli up command) and modify it so it looks like this. The All Traffic source is the ID of sgELB.

You can remove port 22 if you want, but the the traffic from the ELB security group has to be allowed all the traffic. The reason being that the containers can map port 80 to any random port on the host. Technically, you can change the rule from All Traffic to TCP range 1024-65535.
Now, we can create a new application load balancer. Nothing special here. Choose an Internet facing load balancer, create a listener on port 80, choose two subnets, the same where the ECS EC2 instance were created and choose the security group that allows port 80 (sgELB). For the target group an the health checks, do something like this. Make sure health.txt is configured.

Don’t choose ANYTHING for targets, just click Review and Create.

ECS Service

Almost there… Go back to ECS and select the task and choose Create Service from Actions.

Fill out the following values.

Fargate won’t work because SYS_ADMIN flag is not supported. For the Deployments and Task Placement use the defaults and click Next Step.
Choose Application Load Balancer and if you don’t have the role created (AWSServiceRoleForECS), let AWS create one for you. For the Container to load balance, you should see our container there. Just click Add to load balancer.
Choose the port and the target group that you created when creating the load balancer.

You can leave the rest as defaults and click Next Step. Allow auto-scaling by clicking on the second option (Configure Service Auto Scaling to adjust your service’s desired count). And then configure the auto-scaling policy. It’s up to you how you’ll configure it.
This is how mine looks like.

I shouldn’t be scaling based on CPU, 30% CPU is very low value. Maybe scaling based on Network Bytes In/Out is better. I didn’t have time to play with this, so this is how my scaling policy looks like.

You can ommit the Scale in policy for the test. Click Next Step and click Create Service. If it fails because of a namespace error, just go back twice and then forward to create the service.
Once that’s done, click on the Clusters, click the cluster name and then on the Services tab. Your service should have a status of Active. If you click on Tasks, you should see 4 tasks running. Finally, get the DNS name for the load balancer and go to that URL in a browser.

You should see the known WordPress initial page. When asked to configure the database, enter the values that you use when creating the RDS (dbmaster, dbpassword, wordpress and the hostname which can be found as an endpoint in the RDS console).


You should be all set now with a fully functional WordPress site. You can check the ClouwWatch for the Apache logs.

In this post I’ll describe the current procedure of migrating a domain that’s registered and hosted at 1and1.com to godaddy.com. The reason for my migration is simple. I just want to move all my registered domains to godaddy.com and consolidate them. In addition, since I purchased some VPS, I’ve decided to migrate my stuff to a full-blown server instead of renting web hosting from 1and1.com

First log to your 1and1.com domain panel and click Manage domains.

Select the domain that you want to transfer (in my case iandreev.com), click Transfers and choose Lock/Unlock option.

Select Unlock.

ICANN regulations prohibit transferring domain names (except .au) that were registered or previously transferred in the last 60 days, so if you already transferred your domain in the past two months, you won’t be able to do so.

Back in the domain panel, select the domain again and click Info.

You should see something similar to this. The most important thing here is the last line “Auth code.com” and its value.

Log to your account at go daddy.com and go to this link.

http://www.godaddy.com/domains/domain-transfer.aspx

When you see this page:

Type the domain name that you want to transfer and click Go. At the top, you’ll see the domain name, just verify it and click Proceed to Checkout.

You’ll get some offers but they are not worth it, so just skip this step and click Continue.

Review the current order and pay the transfer fees.

Once your payment is approved, usually instantly click on Domain Name image.

Within a minute or two, you’ll receive this e-mail, so make sure you have access to the mailbox that was used when your domain was registered.

Kliment Andreev, approve your transfer request.

====================================================================
DOMAIN NAME TRANSFER - Initial Authorization for Registrar Transfer
====================================================================

Re: Transfer of IANDREEV.COM

Dear Kliment Andreev,

GoDaddy received a request on December 09, 2013 for us to become the new registrar of record.

You received this message because you're listed as the Registered Name Holder or Administrative contact for this domain name. If you're not the Account Holder, or you're transferring the domain to a new owner, please forward this email to the appropriate Account Holder to complete the transfer process.

///////////////////////////////////////////////////////////
IMPORTANT: If the steps below are not completed, the domain name(s) listed above will NOT be transferred to us.
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
When authorizing this transfer, you'll be prompted to provide the following Transfer IDs:

Transaction ID: 159067416
Security Code: OYVB28941

To proceed with the transfer, follow the instructions here:
http://support.godaddy.com/help/article/1592?prog_id=GoDaddy&isc=gdbbx2&ci=83387
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

NOTE: After a domain transfer is complete, you cannot transfer it to another registrar for 60 days, apart from transferring back to the original registrar in cases where both registrars so agree or where a decision in the dispute resolution process so directs.

If you DO NOT WANT the transfer to proceed, do not respond to this message.

If you have any questions about this process, contact us by email at support@godaddy.com, or by phone at (480) 505-8877.

Regards,
GoDaddy

Search for a new domain:
http://www.godaddy.com/domains/search.aspx?prog_id=GoDaddy&isc=gdbbx2&ci=83389

Go to My Account:
https://mya.godaddy.com/myrenewals/myrenewals.aspx?shopperid=2529155&prog_id=GoDaddy&myatabs=false&isc=gdbbx2&ci=83385

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Copyright (C) 1999-2013 GoDaddy.com, LLC. All rights reserved.

Next, click on Domains, then Transfers tab and click the green Launch image.

Click on Authorization code needed.

Then click Add now.

Enter the Transaction ID and Security Code from the e-mail that you just received.

Click Next.

When prompted for the Authorization Code, enter the code from 1and1.com (Info button).

You’ll see a short notice that the domain transfer is in process, but you’ll end up with a prompt to enter the Authorization Code again.

Just hit F5 and you’ll see this.

After 2 hours I received an email from 1and1.com.

Dear Mr. Andreev,

Thank you for your transfer request for your domain iandreev.com
on 2013-12-10 04:01:39.We are happy to provide you with more
detailed information.

The current transfer status of your domain is: off.

Do you want to revoke the transfer of your domain? Simply change the
status to "Lock" in your 1&1 Control Panel. To do so, go to:

https://www.1and1.com/login

If you still want your domain to be transferred, please make sure the
status of your domain is set to "Unlock". The transfer of your domain
will then be completed automatically on 2013-12-15 04:01:39.

If your domain is locked, the transfer will be automatically canceled on
2013-12-14 04:01:39.

IMPORTANT: Please note that upon the domain transfer your domain as
well as all associated rights will be transferred to the new registrant -
thus to the new owner of the domain. This means that your domain, together
will all subdomains and e-mail accounts using this domain name, will be
removed from your contract.

Therefore, please make sure that you only agree to this domain transfer
if you have initiated it yourself or if you have already agreed on all
details with the new registrant.

Please find below a step-by-step instruction on how to lock or unlock
your domain for the transfer:

1. Log in to your 1&1 Control Panel with your customer data at
https://www.1and1.com/login.

2. Select the package containing the respective domain. Click on "Domains"
under "Domains & Web Space". You can lock or unlock your domain by selecting
the domain from the list and then clicking on "Transfers"/"Lock/Unlock".

If you cannot log in to your 1&1 Control Panel, please contact our
1&1 Customer Support via the following e-mail address:

support@1and1.com.

Please note our Terms and Conditions at https://www.1and1.com/Gtc. Please
refer to our FAQ section at http://faq.1and1.com/domains/domain_xfers/xfer_of_reg/index.html
for further information.

Yours sincerely,

1&1 Internet Inc.

The only important part in this e-mail is this “The transfer of your domain will then be completed automatically on 2013-12-15 04:01:39”. If everything goes well, after a week you’ll receive an email from godaddy.com that looks like this.

Click on Go to My Account and once you log in, click on Domains. Select the domain that you just transferred, click on the Nameservers icon and then click on Set Nameservers. 

Click on Standard to change the DNS servers to GoDaddy’s DNS servers.

Mind that when you are changing the DNS, all the sub domains that you had with 1 and 1 will be gone. You’ll have to recreate them under Go Daddy’s panel, so make sure that you have a migration plan for all of your sub domains and the data associated.

Part II, Part III, Part IV.

mysqldump -u <username>  -p <password> databasename > /somewhere/dbname.sql

mysql -u <username>  -p   <password> databasename <  /somewhere/dbname.sql

mysql -u adminusername -p
CREATE USER 'custom'@'localhost' IDENTIFIED BY 'obscure';
CREATE DATABASE databasename;
GRANT ALL PRIVILEGES ON databasename.* TO "custom"@"localhost" IDENTIFIED BY "obscure";
FLUSH PRIVILEGES;

freebsd-update fetch
freebsd-update install

portsnap fetch
portsnap update

portmaster -a

Get-Content -Path "<drive>:\Folder\FileName.extension" -Wait

tcpdump -A -s 0 'tcp port 80 and (((ip[2:2] - ((ip[0]&amp;0xf)<<2)) - ((tcp[12]&amp;0xf0)>>2)) != 0)'

tcpdump -A -s 0 'src example.com and tcp port 80 and (((ip[2:2] - ((ip[0]&amp;0xf)<<2)) - ((tcp[12]&amp;0xf0)>>2)) != 0)'

tcpdump -A -s 0 'tcp port 80 and (((ip[2:2] - ((ip[0]&amp;0xf)<<2)) - ((tcp[12]&amp;0xf0)>>2)) != 0)' -i lo

$comp=Get-ADComputer -identity <computer_name> -properties CanonicalName

$user=Get-ADUser -identity <user_name> -properties CanonicalName

<h1>Hello!</h1>

import smtplib

from email.mime.multipart import MIMEMultipart
from email.mime.text import MIMEText

fromaddr = "no-reply@somedomain.com"
toaddr = "kliment.andreev@whatever.com"
EMAIL_HOST = 'email-smtp.us-east-1.amazonaws.com'
EMAIL_HOST_USER = 'AKIAJUEQQ7DIHJUCKAVA'
EMAIL_HOST_PASSWORD = 'AlRPmyef-qAkajSzCtn43YY447rFlJ8GXCBMWyaNide'
EMAIL_PORT = 587

msg = MIMEMultipart('alternative')
msg['Subject'] = "AWS TEST"
msg['From'] = fromaddr
msg['To'] = toaddr

html = open('index.html').read()

mime_text = MIMEText(html, 'html')
msg.attach(mime_text)

s = smtplib.SMTP(EMAIL_HOST, EMAIL_PORT)
s.set_debuglevel(10)
s.starttls()
s.login(EMAIL_HOST_USER, EMAIL_HOST_PASSWORD)
s.sendmail(fromaddr, toaddr, msg.as_string())
s.quit()

toaddr = "kliment.andreev@domain1.com,klimenta@domain2.com,kandreev@domain3.com"
s.sendmail(fromaddr, msg['To'].split(','), msg.as_string())

echo | openssl s_client -showcerts -servername blog.andreev.it -connect blog.andreev.it:443 2>/dev/null | openssl x509 -inform pem -noout -text

dnscmd /clearcache

aws ec2 describe-instances --query "Reservations[*].Instances[*].PublicIpAddress" --output=text

systemctl status firewalld

firewall-cmd --zone="trusted" –-add-source=192.168.1.0/24
firewall-cmd --zone="trusted" –-add-source=11.12.99.88

firewall-cmd --zone="trusted" –add-service=ssh

firewall-cmd --zone="trusted" –list-all

firewall-cmd –-zone=public –remove-service=ssh

firewall-cmd --zone="trusted" –-add-source=192.168.1.0/24 --permanent
firewall-cmd --zone="trusted" –-add-source=11.12.99.88 --permanent
firewall-cmd --zone="trusted" –add-service=ssh --permanent
firewall-cmd –-zone=public –remove-service=ssh --permanent

Go to the download page and find the archive that you want to download. Click to accept the agreement and then get the URL of the archive.

wget --header "Cookie: oraclelicense=accept-securebackup-cookie" <URL>

Convert MP3 files to Ogg-Vorbis using sox in all subfolders

find . -name '*.mp3' -exec bash -c ' sox -V3 "$1" "${1%.mp3}.ogg"' -- {} \;

Delete all mp3 files after.

find . -name "*.mp3" -exec rm {} \;

Extract a tar archive (tarball) without the head/container directory (folder)

You have a tarball aaa.tar.gz with the following structure.

—-file1.txt
—-file2.txt
You want to extract the files to a directory without the top aaa folder.

tar xzvf aaa.tar.gz --strip 1 -C destination_folder

Samba 4.x, list Windows share, mount Windows share

sudo mount.cifs -v -o username=my_username,domain=netbios_domain_name,vers=2.1 //host.domain.local/share /mnt

If you are unable to write to the mounted folder, specify the user as -o…vers=2.1,uid=4801105,gid=4800513 which is a user that has rights to that share.

smbclient //host.domain.local/share -U my_username@domain.local -m SMB3 -W netbios_domain_name

Speed up video files x30

ffmpeg -i input.mov -vf "setpts=(PTS-STARTPTS)/30" -crf 18 output.mov

Replace pattern in file names

E.g. You want to remove [BBB] from these files 123[BBB]aaa.txt and asd[BBB]123.txt.

Get-ChildItem *.txt | ForEach { Move-Item -LiteralPath $_.Name $_.Name.Replace("[BBB]", "") }

PowerShell – create TCP listener

$Listener = [System.Net.Sockets.TcpListener]9999;
$Listener.Start();
# Test the port with telnet
# once completed execute below
$Listener.Stop();

Get the model name of the computer from BIOS

wmic csproduct get name

uptime in Windows

Download the zipped EXE here. MD5: e37822139136b6296bc58617fceb010d. Source in C.

// uptime - shows the uptime on a Windows system
// K.Andreev - 20180803 - BSD Simplified License

#include "stdafx.h"
#include <Windows.h>

int main()
{
DWORD dMilliseconds = GetTickCount();
DWORD dDays = dMilliseconds / 86400000;
DWORD dHours = dMilliseconds / 3600000 - dDays * 24;
DWORD dMinutes = dMilliseconds / 60000 - dHours * 60 - dDays * 1440;
DWORD dTemp = dDays * 86400 - dHours * 3600 - dMinutes * 60;
DWORD dSeconds = dMilliseconds / 1000 - dDays * 86400 - dHours * 3600 - dMinutes * 60;

if (dDays != 0) {
printf("up %d days, %d hours, %d minutes, %d seconds", dDays, dHours, dMinutes, dSeconds);
return 0;
}
if (dHours != 0) {
printf("up %d hours, %d minutes, %d seconds", dHours, dMinutes, dSeconds);
return 0;
}
if (dMinutes != 0) {
printf("up %d minutes, %d seconds", dMinutes, dSeconds);
return 0;
}
printf("up %d seconds", dSeconds);

return 0;
}

Replace CRLF in a file, DOS 2 UNIX text format

sed -i 's/\r//g' /tmp/script.sh