preventing mythtv.cnf updates??

[marcw]

In the short period I've had my stand alone v.31 BE running, every single myth update (3 so far) has updated my /etc/mysql/conf.d/mythtv.cnf file and apt update shouldn't be doing that. The updates insist on commenting the first line like this:

[mysqld]
#bind-address=0.0.0.0
max_connections=100

So after each update I have to go back and uncomment that line or myth can't connect to the database. How do I prevent that file from being "updated"?

[bill6502]

Change the bind address from 0.0.0.0 (any IPv4 addresses) to * (any IPv4 or IPv6 addresses).

I'm not sure why more folks aren't finding this. Or, maybe they are just dealing with it and not
reporting.

In any case, the only check I see happens when ^bind-address=0.0.0.0$ is found
and it gets commented out. But there is supposed to be a prompt (popup) that
asks if remote connections are to be allowed.

[white_haired_uncle]

Change the bind address from 0.0.0.0 (any IPv4 addresses) to * (any IPv4 or IPv6 addresses).

I'm not sure why more folks aren't finding this. Or, maybe they are just dealing with it and not
reporting.

In any case, the only check I see happens when ^bind-address=0.0.0.0$ is found
and it gets commented out. But there is supposed to be a prompt (popup) that
asks if remote connections are to be allowed.

After rebooting the backend today, I could not start mythbackend, or connect via mythtv-setup, or connect to mysql remotely via the mysql client.

Eventually, I found that mysql was only listening on tcp6/3306.

/etc/mysql/conf.d/mythtv.cnf (with mod date 03/23/2023, the date of my last mythtv upgrade) contained: bind-address=::
Setting this to bind-address=0.0.0.0 (or =* or commenting it out completely) made everything work again. I hadn't restarted mysql since well before 3/23, so I suspect the mythtv upgrade made a change that effected mysql and I just didn't run into it until now.

Version: 2:33.1+fixes.202303140136.7f288be61b~ubuntu22.04.1

After a little testing, it turns out that commenting that line out, or setting it to =* causes mysql to listen on both IPv4 and IPv6. Setting to 0.0.0.0 and mysql listens only on IPv4, and =:: mysql listens only on IPv6.

mariadb Version: 1:10.6.12-0ubuntu0.22.04.1

According to the mysql docs I can find, it sounds like my system isn't working correctly (=:: should be the same as =*, even though the way it works now makes a lot more sense to me, =:: looks like IPv6 and NOT IPv4 to me). But I'll throw this out there in case others encounter the same issue.

I also have to question whether either of the mythtv.cnf should be installed by default. Those are "global" settings, if I understand correctly (effect mysql as a whole, not just myth's usage of it). Sure, most users probably aren't sharing mysql on the backend with a lot of other users/apps, but it kind of rubs me the wrong way to think myth could break other applications by changing their database access. And I wonder what happens if another app, or setting by the SA, conflicts with the myth supplied settings (could be interesting to debug, if we assume that since we set these values explicitly then they will actually be used). Maybe I'm way off base here, but it just doesn't seem right to me.

[paulh]

The way the MySQL config works is the last config file to set a setting wins - all the previous attempts to set a setting are ignored.

So while there is a set order in which the config files are parsed the end result can be a bit random depending on what packages you have installed that modify the MySQL config and the placement and alpanumeric name of the many config files.

I believe the MythTV packages attempts to modify the bind-address because when the default behaviour was changed in MySQL some time ago to only listen for local connections it broke many MythTV installs with remote frontends because they obviously require MySQL to listen for connections from remote connections.

It's a case of you are damned if you do and you are damned if you don't. You either attempt to make it work for most MythTV users with local and remote FE's but possibly annoy some users who don't want MySQL to be forcibly told to listen on all address with the possible but very small security risk involved or you leave it alone were it may or may not work depending on whatever the default setting may be on the day you install MariaDB or MySQL or what other packages have done to change the default config.

Now whether we do or do not modify the MySQL config to help MythTV users and what we should be using for the bind-address setting I'll leave to the MariaDB and MySQL experts to thrash that one out Personally I always use a real IP address like 192.168.1.123 rather than a wild card, I don't have IPv6 so that works for me and may be a little more secure but I'm no expert it's just my personal preference

[bill6502]

@white_haired_uncle, also, some users have created (for example) a zzzmythtv.cnf file which is
last in the lexicographical order. Files names are parsed that way and that doesn't prevent the
updates, which is the subject here, but it can override them. Be sure to observe the !includedir
order in my.cnf under /etc/mysql.

But he 1st post here mentions a "stand alone v.31 BE" and it's SQL server would only need to listen
on localhost, so it sounds like you've got remote frontends or the like.

I agree that "*" is the proper value for both and I updated my year old response above.

[white_haired_uncle]

I do have remote frontend and such, but even so the backend (also the DB host) itself would not start. localhost (and the hostname) resolve to IPv4 addresses, and mysql was no longer listening on IPv4 and so mythbackend could not connect to the local database.

Anyway, I just wanted to get this out there, as there are probably others who will see mythbackend suddenly unable to start, but not until they restart mysql and so not immediately think to associate the change with the update.

[Note: curiously, my backend is the only machine I have where /etc/hosts does not contain a localhost entry for ::1. Perhaps this is why I see an issue and others don't/won't]

[PhilB]

You could make it immutable.
See chattr and lsattr.
Remember though that this will need unsetting if you ever want to reinstall ubuntu.
Phil