Difference between revisions of "Schedules Direct URL Change"

From MythTV Official Wiki
Jump to: navigation, search
(Rewrite lede a bit for clarity)
(Add 0.28 commit & RPZ solution)
Line 5: Line 5:
 
is not SD) could 'retire' that DNS record at any time leaving MythTV SD users out of service.
 
is not SD) could 'retire' that DNS record at any time leaving MythTV SD users out of service.
  
Because of this, users of older versions of MythTV will need to make one of two changes in order to continue retrieving SD data:
+
Because of this, users of older versions of MythTV will need to make one of three changes in order to continue retrieving SD data:
  
1) Modify your MythTV sources to use a different DNS name for the Schedules Direct data source, or, if you can't easily do that,
+
* Add a line to your hosts file, which overrides the IP address returned by DNS for the name "baked" into the copy of MythTV you're running or
  
2) Add a line to your hosts file, which overrides the IP address returned by DNS for the name
+
* Run a nameserver and use RPZ, or,
"baked" into the copy of MythTV you're running.
 
  
 +
* Modify your MythTV sources to use a different DNS name for the Schedules Direct data source.
 +
 +
These solutions are detailed below. Users interested in testing the new server can use any of
 +
these right now. The more testers, the less the chance of a surprise on 11/1/2014.
  
 
== What '''must''' users do prior to November 1st, 2014? ==
 
== What '''must''' users do prior to November 1st, 2014? ==
  
 
0.27 and 0.28-pre users should keep their systems
 
0.27 and 0.28-pre users should keep their systems
up to date with current fixes. The fix for this
+
up to date with current fixes.
issue hasn't been released as of the last update of this Wiki. When released, information about it will be added here.
+
 
  
 
{| border="1" cellspacing="0" cellpadding="5" style="float: center;border-collapse:collapse; border-color:#8eabd0; background:#e7edf5"
 
{| border="1" cellspacing="0" cellpadding="5" style="float: center;border-collapse:collapse; border-color:#8eabd0; background:#e7edf5"
Line 32: Line 35:
 
|-
 
|-
 
|0.28-pre
 
|0.28-pre
|{{shortgitcommit|TBA}}
+
|{{shortgitcommit|4cb10e5}}
|TBA
+
|October 13, 2014
 
|}
 
|}
 
<br>
 
<br>
Line 41: Line 44:
 
If the above was followed, nothing.
 
If the above was followed, nothing.
  
Users running 0.26 and below should use the solution in the following section.
+
Users running 0.26 and below should choose a solution from the next three sections.
  
== Is there anything users can do to try the replacement now? ==
+
== The ''/etc/hosts'' file solution ==
  
Yes, perhaps the simplest is to make the following entry in the backend's /etc/hosts file:
+
Perhaps the simplest is to make the following entry in the backend's ''/etc/hosts'' file:
  
 
<pre>
 
<pre>
Line 51: Line 54:
 
</pre>
 
</pre>
  
The new server is working well. But the more users testing it, the better. (It would be nice to discover any problems now rather than on 11/1.)
+
Is the ''/etc/hosts'' entry a proper solution? No, because IP addresses can change.
 +
It's not a bad solution, but it's certainly not as good as running on {{CurrentRelease}}.
 +
 
 +
{{Note box|The IP address has already changed twice during beta testing.}}
 +
<br>
 +
== The nameserver/RPZ solution ==
 +
 
 +
If the following is used, be sure to remove the ''/etc/hosts'' entry.
 +
 
 +
{{Warning box|The following is of no value without ''bind'' version 9.8.1
 +
or greater installed, running and acting as the backend's nameserver.
 +
Verify the version before going further.}}
 +
 
 +
Also know that this is not intended to be a ''bind''
 +
[http://ftp.isc.org/isc/bind9/cur/9.9/doc/arm/Bv9ARM.ch06.html#options Configuration Reference]
 +
 
 +
Distributions and personal choices will likely change the names of
 +
the files in the following examples. Adjust as required.
 +
 
 +
Finally, the following was written as if the backend is running
 +
a nameserver only for itself (the appliance model.)
 +
 
 +
If a local nameserver is already utilizing Response Policy Zones
 +
(RPZ), then it is only necessary to add the last line in the following
 +
box to an existing zone file.
 +
 
 +
Otherwise, add a file named: ''/etc/bind/db.rpz.localhost''
 +
with the following:
 +
 
 +
<pre>
 +
$TTL 1h
 +
$ORIGIN rpz.localhost.
 +
@ IN SOA LOCALHOST. localhost. (
 +
                  1     ; Serial
 +
            604800    ; Refresh
 +
              86400    ; Retry
 +
            2419200    ; Expire
 +
            604800 )  ; Negative Cache TTL
 +
 +
@ IN NS  LOCALHOST.
 +
 
 +
webservices.schedulesdirect.tmsdatadirect.com CNAME dd.schedulesdirect.org.
 +
</pre>
 +
 
 +
In the file: ''/etc/bind/named.conf'', add the following inside
 +
the ''options{}'' statement:
 +
<pre>
 +
    recursion true;
 +
    allow-recursion {localhost;};
 +
    response-policy {zone "rpz.localhost";};
 +
    allow-transfer {none;};
 +
    allow-update {none;};
 +
</pre>
 +
 
 +
In the same file, add:
 +
 
 +
<pre>
 +
zone "rpz.localhost" {
 +
    type master;
 +
    allow-query {localhost;}; // omit line or adjust as desired
 +
    allow-update {none;};
 +
    file "/etc/bind/db.rpz.localhost";
 +
};
 +
</pre>
 +
 
 +
<br>
  
Is the /etc/hosts entry a proper solution? No, because IP addresses can change.
+
== Solution for users that build from source ==
It's not a bad solution, but it's certainly not as good as running on {{CurrentRelease}}.
 
  
{{Note box|The IP address has already changed twice from the original one posted here.}}
+
Locate the line to change with the following command and
 +
replace the hostname with the new one above. Be prepared to
 +
remove the change when the official commit is pushed.
 +
 
 +
<pre>
 +
git grep webservices.schedulesdirect.tmsdatadirect.com
 +
</pre>
  
 
== Are there any other sources of information about the change? ==
 
== Are there any other sources of information about the change? ==
Line 90: Line 163:
 
|SD hosted DataDirect Server
 
|SD hosted DataDirect Server
 
|}
 
|}
<br>
 
 
== Can users that build from source make a change now? ==1
 
Yes, locate the line to change with the following command and
 
replace the hostname with the new one above. Be prepared to
 
remove the change when the official commit is pushed.
 
 
<pre>
 
git grep webservices.schedulesdirect.tmsdatadirect.com
 
</pre>
 

Revision as of 16:45, 13 October 2014

As some have heard, on November 1st, 2014, the existing SD service is changing. This article is intended to be a short discussion of options for MythTV users.

Ideally, there would be a DNS change and the IP address for the existing (hard coded) hostname would be pointed to a new IP address and no action would be required by MythTV SD users. However, the owner of that hostname (which is not SD) could 'retire' that DNS record at any time leaving MythTV SD users out of service.

Because of this, users of older versions of MythTV will need to make one of three changes in order to continue retrieving SD data:

  • Add a line to your hosts file, which overrides the IP address returned by DNS for the name "baked" into the copy of MythTV you're running or
  • Run a nameserver and use RPZ, or,
  • Modify your MythTV sources to use a different DNS name for the Schedules Direct data source.

These solutions are detailed below. Users interested in testing the new server can use any of these right now. The more testers, the less the chance of a surprise on 11/1/2014.

What must users do prior to November 1st, 2014?

0.27 and 0.28-pre users should keep their systems up to date with current fixes.


Version Commit Release Date
0.27 TBA TBA
0.28-pre 4cb10e5 October 13, 2014


What must be done on November 1st.

If the above was followed, nothing.

Users running 0.26 and below should choose a solution from the next three sections.

The /etc/hosts file solution

Perhaps the simplest is to make the following entry in the backend's /etc/hosts file:

54.85.117.227 webservices.schedulesdirect.tmsdatadirect.com

Is the /etc/hosts entry a proper solution? No, because IP addresses can change. It's not a bad solution, but it's certainly not as good as running on 34.0.


Important.png Note: The IP address has already changed twice during beta testing.


The nameserver/RPZ solution

If the following is used, be sure to remove the /etc/hosts entry.

Warning.png Warning: The following is of no value without bind version 9.8.1 or greater installed, running and acting as the backend's nameserver. Verify the version before going further.

Also know that this is not intended to be a bind Configuration Reference

Distributions and personal choices will likely change the names of the files in the following examples. Adjust as required.

Finally, the following was written as if the backend is running a nameserver only for itself (the appliance model.)

If a local nameserver is already utilizing Response Policy Zones (RPZ), then it is only necessary to add the last line in the following box to an existing zone file.

Otherwise, add a file named: /etc/bind/db.rpz.localhost with the following:

$TTL 1h
$ORIGIN rpz.localhost.
@ IN SOA LOCALHOST. localhost. (
                  1     ; Serial
             604800     ; Refresh
              86400     ; Retry
            2419200     ; Expire
             604800 )   ; Negative Cache TTL
;   
@ IN NS  LOCALHOST.

webservices.schedulesdirect.tmsdatadirect.com CNAME dd.schedulesdirect.org.

In the file: /etc/bind/named.conf, add the following inside the options{} statement:

    recursion true;
    allow-recursion {localhost;};
    response-policy {zone "rpz.localhost";};
    allow-transfer {none;};
    allow-update {none;};

In the same file, add:

zone "rpz.localhost" {
    type master; 
    allow-query {localhost;}; // omit line or adjust as desired
    allow-update {none;};
    file "/etc/bind/db.rpz.localhost";
};


Solution for users that build from source

Locate the line to change with the following command and replace the hostname with the new one above. Be prepared to remove the change when the official commit is pushed.

git grep webservices.schedulesdirect.tmsdatadirect.com

Are there any other sources of information about the change?

Yes.

The announcement from SD.

List of open issues, also from SD.

The mythtv-users mailing list under the thread: Schedules Direct DataDirect replacement service testing. Or, it's archive). Please don't start new testing threads. If you make a report on the testing thread, please mention which version of MythTV you're running (if you run mythfilldatabase by hand, it will tell you, right at the beginning of its logs).

Discussions on the developer's channel.

Cast of characters (both of them.)

Abbreviated Name URL Description
TMS-DD docs.tms.tribune.com webservices.schedulesdirect.tmsdatadirect.com Tribune hosted Datadirect Server (going away)
SD-DD dd.schedulesdirect.org SD hosted DataDirect Server