Icecast Now Playing WordPress Widget Script

Before moving to WordPress from BlogEngineDotNet I had a widget that made a call to a specially created Icecast XSL file to display the current playing track title in a Widget.  This worked great, but it was static and wouldn’t update if the track changed.  Migrating to WordPress, I wanted to achieve the same track playing information but up the game with it updating to display new track information.  The latest Icecast server has built in metadata report in JSON format now so I wanted to use this over parsing an XSL file. This took me roughly about a day and a half to complete, mostly due to nearly all examples of parsing JSON with Javascript do not work and I know little Javascript. Here is an overview of the process invovled.

  • Configure Icecast headers and SSL certificates
  • Insert Javascript in headers.php
  • Insert HTML in Widget for display
Configure Icecast

You can skip this part if you are not using SSL. Also note Apache and Icecast are running on the same server. Since my site defaults to SSL (https) I have to configure Icecast for SSL.

The first step is to create the proper SSL certificate file format that Icecast uses. It requires a Public/Private keypair file. I used my Let’s Encrypt certificates and concatenated them together into one file.

cd /usr/share/icecast
cat /etc/letsencrypt/live/autonarcosis.com/cert.pem > icecast.pem
cat /etc/letsencrypt/live/autonarcosis.com/privkey.pem >> icecast.pem
chown icecast.icecast icecast.pem
chmod go-r icecast.pem

Now to edit the /etc/icecast.xml configuration file to enable an SSL port and point to the icecast.pem file. Create a second listen-socket container with a different port and enable SSL. Insert http-headers container before paths container for access control (this gives permission for the javascript to access the JSON data).  Put the ssl-certificate path setting within the existing paths container.

<listen-socket>
     <port>8002</port>
     <ssl>1</ssl>
</listen-socket>

<http-headers>
    <header name="Access-Control-Allow-Origin" value="*" />
</http-headers>
<paths>
     <ssl-certificate>/usr/share/icecast/icecast.pem</ssl-certificate>
</paths

Save the icecast.xml file. Enable the new port in the firewall.

firewall-cmd --permanent --add-port=8002/tcp
firewall-cmd --reload

Restart Icecast, which will now be listening on an SSL port.

systemctl restart icecast.service

You can view Icecast error log file /var/log/icecast/error.log to see if the SSL certificate loaded properly.  You should see something similar to this.

[2016-03-11  15:41:45] INFO connection/get_ssl_certificate SSL certificate found at /usr/share/icecast/icecast.pem
[2016-03-11  15:41:45] INFO connection/get_ssl_certificate SSL using ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA2
56:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-R
SA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SH
A384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA25
6:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:ECDHE-RSA-DES-CBC3-SHA:ECDHE-ECDSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-S
HA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-S
HA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA
Configure WordPress

Now it is time to configure WordPress.  Below is the Javascript that I hacked together to pull the Icecast metadata from the data feed in JSON format. This is WordPress modified Javascript and will not work outside WordPress.  Place this Javascript in the HEAD section of your themes headers.php.

<script type="text/javascript">
function radioTitle() {
 
jQuery.ajax({
        url: "https://www.autonarcosis.com:8002/status-json.xsl",
        //force to handle it as text
        dataType: "text",
        async: true,
        success: function(data) {
                        
        //data downloaded so we call parseJSON function 
        //and pass downloaded data
        var json = jQuery.parseJSON(data);
        //now json variable contains data in json format
        //let's display a few items
        // this is the element we're updating that will hold the track title
            jQuery('#track-title').text(json.icestats.source.title);
        // this is the element we're updating that will hold the listeners count
            jQuery('#listeners').text(json.icestats.source.listeners);            
       }
     });
   };
   
jQuery(document).ready(function(){

        setTimeout(function(){radioTitle();}, 2000);
        // we're going to update our html elements / player every 15 seconds
        setInterval(function(){radioTitle();}, 15000); 

});

</script>

Add the HTML to the widget so the information will be displayed.

<p>
</br>
Listeners: <span id="listeners">00</span></br>
Current track: <span id="track-title">LIVE</span>
</p>

That’s all there is to it. There could possibly be a better way or function to do this.

I used this blog entry as a base for figuring this out; https://linge-ma.ws/update-listeners-track-on-a-website-using-icecast-jsonp-and-jquery/

Poo Grotto Expansion Project #3

This is an announcement for the Poo Grotto Expansion Project #3.  This project consists of the removal of a bush and tree and the removal of the stumps and then back fill in the hole. This is intended to improve the current poo area and stump wood for camp fires in the summer. There will be interruptions of prime poo spots surrounding the expansion area during the project. The project is slated to start March 2016 and end April 2016.

PooGrottoExpansionProject3-1
Before Poo Grotto Expansion Project #3
PooGrottoExpansionProject3-2
Bush and Tree removed. Digging will start March 2016.

Out With The Old

Well, unfortunately within hours of updating the BlogEngineDotNet application to the latest version, it resulted in getting hacked. BlogEngineDotNet is a barely functioning Blog Application and Windows 2008 is old, so it’s time to just ditch the stupid and join the 21st Century. Yes, of course I tried running BlogEngineDotNet via Apache and mod_mono but no, it’s so poorly coded it doesn’t work on the Mono platform.  Goodbye BlogEngineDotNet, Goodbye Windows Server.

BlogEngine.Net – New Version Released!

Miracles never cease! BlogEngine.Net has been updated to v3.2. It’s not a bad update. The automated update process went a lot more smoothly, since I knew what to do from the previous one.  The Standard-28 theme was removed, so I had to pick a different default theme which is fine and the search widget appears to be missing.  I haven’t checked to see if mod_security has been enabled again. I suspect it wouldn’t be working if it has.  Now I just wonder what security issues will pop up that will never be announced or properly fixed. I just about gave up on BlogEngine.Net due to nothing happening with it for over a year. I had moved over a couple of sites to a different CMS and was learning it. This new version of BlogEngine.Net will make me want to stick out with it on this domain for a bit more. Depends on how long I want to maintain a Windows server.  Windows is fast becoming pay to play operating service which it isn’t worth it anymore.

Vanity Top Level Domains – How To Block Them Using Sendmail

Oh the joy! More spam from those stupid ass new top level domains to scam people out of their money with worthless crap. By the time you are done reading this I am sure another TLD will sprout it’s spam wings and flood your mail server with it’s nonsense. Because the world is running out of TLDs so that someone can create hundreds of millions of bogus domains every day to harass us with. Yeah, that’s a good sustainable plan. No, nothing to do with making money.

How do we get rid of this stupid shit? It’s easy with Sendmail.

#cd /etc/mail

Edit the ‘access’ file and add the below list. I’ve sorted to make it easy to add more TLDs as they flood you with spam. This will be a weekly if not daily thing so get used to it. And yes, yes there is a .wang TLD.

#TLD Reject List
accountant			REJECT
actor					REJECT
airforce				REJECT
army					REJECT
attorney				REJECT
auction				REJECT
audio					REJECT
band					REJECT
blackfriday				REJECT
christmas				REJECT
click					REJECT
club					REJECT
consulting				REJECT
dance				REJECT
date					REJECT
degree				REJECT
democrat				REJECT
dentist				REJECT
diet					REJECT
download				REJECT
enigneer				REJECT
eu					REJECT
faith					REJECT
forsale				REJECT
futbol				REJECT
gift					REJECT
gives					REJECT
guitars				REJECT
help					REJECT
hiphop				REJECT
hosting				REJECT
lawyer				REJECT
link					REJECT
market				REJECT
mortgage				REJECT
navy					REJECT
ninja					REJECT
party					REJECT
photo				REJECT
pics					REJECT
property				REJECT
rehab				REJECT
republican				REJECT
reviews				REJECT
rip					REJECT
rocks				REJECT
science				REJECT
sexy					REJECT
show					REJECT
social				REJECT
software				REJECT
tattoo				REJECT
top					REJECT
wang					REJECT
xyz					REJECT

Save the file, make the db files and restart Sendmail.

fail2ban – sendmail-auth – howto

This article is about fail2ban and preventing Sendmail brute force password attacks. Also known as fail2ban’s worthless sendmail-auth configuration.

fail2ban comes with a completely worthless sendmail-auth filter.  It looks for a failure notification from Sendmail that most likely will never happen anymore as previously the brute force attack would make one connection and issue multiple AUTH commands.  This is no longer the case. The brute force attack makes one connection, issues an AUTH command then disconnects and re-connects. This never triggers the Sendmail “possible SMTP attack: command=AUTH” string.

So, what we need to do is something, anything that actually has some sort of real world value, like it actually working? That’d be helpful, right?

#cd /etc/fail2ban/filter.d/
#cp sendmail-auth.conf sendmail-auth.local

Now edit the .local file and replace the worthless regex

failregex = ^%(__prefix_line)s\w{14}: (\S+ )?\[<HOST>\]( \(may be forged\))?: possible SMTP attack: command=AUTH, count=\d+$

With this

failregex = \[<HOST>\] .*to MTA
            \[<HOST>\] \(may be forged\)
            \[<HOST>\], reject.*\.\.\. Relaying denied

Save the file, then we want to reload fail2ban

# fail2ban-client reload

Sendmail – How To Disable IPv6 When Sending/Relaying

Well, we learned how to configure Sendmail to send to a specific IP address on a per domain basis. Google and it’s business service e-mail is now by default publishing IPv6 addresses for MX records, it’s almost impossible to do a per domain setup.  We do not want to disable IPv6 entirely on the server, but Sendmail keeps sending out via IPv6. How the hell do you make it stop!  It’s quite simple but just a refresher since this is a configuration that is out of sight and mind.  Remember that Sendmail is really two things. A Daemon (the part that listens for incoming mail) and a Client (the part that sends/relays e-mail). Naturally you have the DAEMON settings by default, but not the CLIENT settings.  So here we go.

I have only found one forum post regarding the proper solution to this problem.  It appears not to be properly documented and possibly this is changed behavior in a recent update. However, it does make sense.  Essentially you need to tell the IPv6 stack to use your IPv4 address.

Edit /etc/mail/sendmail.mc

Look for

DAEMON_OPTIONS(`Port=smtp,Addr=xxx.xxx.xxx.xxx, Name=MTA')dnl

Below the above line add this;

CLIENT_OPTIONS(`Family=inet6,Addr=::ffff:xxx.xxx.xxx.xxx')dnl

Save the file, make the db files and restart Sendmail.

Now, Sendmail will use IPv4 for it’s CLIENT operations.