Server upgrade, IP address changes affect some automation and metadata push users

We’re moving Spinitron to a new cluster of servers each with of 8-cores with 128 GiB memory. This is necessary to cope with the growth of database tables and search engine indexes. The IP addresses of our servers will change.

In the past changing server IP address caused some disruption to service no matter what. This time it can be avoided if you take certain steps before we shut down the old servers.

Automation systems

If you are using ENCO, iMediaTouch, WideOrbit or Skylla then you need to update the IP address it uses to send now-playling updates to Spinitron. At present it is probably configured to send to 142.44.138.121.

  • Change your automation to send to 54.39.125.196 (asap)

Your protocol and port number stays the same – only change the IP addess. Updated instructions to configure your automation systems are in Spinitron in Admin: Automation & API: Automation control panel, including the protocol, IP address and port number to use.

Metadata push

Many of you have metadata push channels sending to devices (RDS encoders, for example) behind firewalls. The firewall is usually configured with a pinhole or port forwarding rule that accepts data only from one of Spinitron’s IP address 142.44.138.121 and 142.44.138.122.

  • Change your firewall/router to accept ALSO from 54.39.125.196 (asap)

Protocols and port numbers are unchanged – only change the source IP address.

When everyone has transitioned and we cut over metadata push to send from the new address, we’ll notify you again so you can close the other two addresses.

We will gradually start using 54.39.125.196 starting Feb 20 2020 ramping up to Mar 25 at which point the old addresses will be phased out.

Warning: Very dense person.

My automation system runs with an urlbase of

spinitron.com/api/spin/create-v1

would I be changing the spinitron.com bit to the ip above or no?

–eric

Hi Eric, thanks for joining the forum!

No, the change doesn’t affect your automation.

Most automation systems including yours use the host name spinitron.com, which isn’t changing. But ENCO, iMediaTouch and WideOrbit don’t accept a host name and only accept an IP address, and that needs to change.

And thanks for asking, @WNMC_Eric. Your question showed how I could make the notice more clear.

Super. Thanks for the clarification.

–eric

Transitioning tcp:// and udp:// push channels

Today we started a gradual transition of the push service from using the old source addresses to the new one on tcp:// and udp:// push channels.

From now until Mar 25 2020 the push service will choose at random to send from the new source address 54.39.125.196 or from one of the old source addresses.

The probability of using the new address is starting at about 1% now and it will increase by roughly 3% per day until Mar 25 at which point it reaches 100%.

This applies to tcp:// and udp:// push channels only.

If you have already opened your network equipment (e.g. routers, firewalls) to accept TCP and/or UDP push messages from 54.39.125.196 then you’re all set – you don’t need to make any more changes at present.

If your network equipment is configured to accept TCP and/or UDP push messages only from the old addresses 142.44.138.121 and 142.44.138.122 then

  1. Some of these messages will be lost. The loss will be random and the rate of loss will increase steadily from now until Mar 25 at which point all messages will be lost.
  2. You should set your network equipment to accept also from the new address and then 100% of messages will get through.

If you have any questions or need any help, please contact me here or by email or phone.

Is the transition complete? My university IT department removed the firewall pin holes from the old 142.xxx addresses this past week. I’m only getting about every third song pushed to my RDS encoder from the new 54.xxx address.

Mike

Hi Mike,

Yes, the transition was completed a while back. We’re only sending on 54.39.125.196 afaik.

So we should look for other explanations. I see you have 3 channels all of which seem to be working as far as the metadata push logs can reveal. Is there any problem with the other two? I mean, do the same messages get lost on all channels or is only RDS affected?

If you want, I can put a packet monitor on the destination address and port of the RDS channel and then we can cross check that with the metadata push log. Let me know.