[mythtv-commits] Ticket #10763: Network Control Socket fails to bind to proper interface on remote front end
MythTV
noreply at mythtv.org
Sat May 26 21:59:47 UTC 2012
#10763: Network Control Socket fails to bind to proper interface on remote front
end
-------------------------------------------------+-------------------------
Reporter: Gern Blanston <mythtv@…> | Owner:
Type: Bug Report - General | Status: closed
Priority: minor | Milestone: unknown
Component: MythTV - General | Version:
Severity: medium | 0.25-fixes
Keywords: frontend, network control socket, | Resolution: Invalid
serverpool | Ticket locked: 0
-------------------------------------------------+-------------------------
Changes (by wagnerrp):
* status: new => closed
* resolution: => Invalid
Comment:
The code is designed such that if you specify the BackendServerIP for that
host, it will only listen on that address and localhost (127.0.0.1 or
::1). If you do not specify anything, it will poll the addresses defined
on that system, and listen on any
[http://tools.ietf.org/html/rfc1918#page-4 RFC1918] private network
address. That means anything in the 10.0.0.0/8, 172.16.0.0/12, or
192.168.0.0/16 address ranges, things that would be used were you running
a system behind a NAT router.
There are only three reasons to define BackendServerIP on a host:
* You are running a backend on that host, and the backend needs that
address defined, both for proper configuration, and so clients on the
network know how to access it.
* You want to limit the frontend from listening everywhere, and only want
to allow access on a specific IP address, or only localhost.
* You are operating without NAT, directly on an internet routeable
address, and need to force the frontend to listen there, when it will by
default ignore it as it is not an RFC1918 private address.
In MythTV, the hostname is simply a key for selecting configuration and
storage defined in the database. By default, MythTV will use the system's
hostname for that key, whatever you get when you run `hostname` on the
command line. If for whatever reason you want to override that value, you
can do so with the LocalHostName parameter in mysql.txt. In 0.26, that
file has been removed, and the value can instead be defined using
Configuration/LocalHostName in config.xml. There are only a handful of
reasons you might want to do this:
* You want to run a configuration set from another machine, but you only
want to do so temporarily, so you don't want to use the database restore
script to migrate the settings to the new hostname.
* You are running multi-head, and want to run two frontends
simultaneously, or at different times, with different configurations.
* You want to have separate shared settings for multiple applications
running on that host.
This last one is where you're getting confused. Since all backends
require BackendServerIP be set to function, a frontend on the same host
would be constrained to only listen on the same address. Specifying a
custom LocalHostName would allow the frontend to use an independent
configuration, or no configuration and autoselect the addresses.
My guess of what is going on here is that you didn't understand the
purpose of BackendServerIP, and on your remote frontend, set it to the
address of your master backend. That value is a local setting, for the
configuration of services running locally on that host. MasterServerIP is
what is supposed to be used to define the master. When you set
BackendServerIP to that of a remote machine, you told the frontend to only
listen on that address and localhost, and since that address was not its
own, it refused, and dropped to localhost only.
--
Ticket URL: <http://code.mythtv.org/trac/ticket/10763#comment:1>
MythTV <http://code.mythtv.org/trac>
MythTV Media Center
More information about the mythtv-commits
mailing list