kelinger / OmniStream

Deployment and management tools for an entire streaming platform that can reside on a server (local, remote, hosted, VPS) with media files stored on cloud services like Google Drive or Dropbox.
MIT License
30 stars 8 forks source link

DNS Update - Plex #14

Closed bdschuster closed 1 year ago

bdschuster commented 1 year ago

Hello! I've had "Delete DNS" to false for some time now because Plex has issues direct playing when "Proxied" is turned on. It has worked fine when doing an "omni up", it wouldn't update the record cause it already existed, leaving it un-proxied. But with the latest update, it seems doing an "omni up" updates the record to "proxied" now. Is there any way to stop this?

kelinger commented 1 year ago

In the labels section for Plex (or most other containers) is a line like: - "omni=${PLEXNAME},${MYDOMAIN},yes,yes,yes" This translates to how OmniStream handles this particular container. I think the first two parameters are obvious (Plex name and your domain). The three "yes" fields (in this case) represent add, delete, and cache. Note that the add/delete/cache are ignored during the up/down process if it is globally disabled (that is, if you disabled deletions, it really doesn't matter if the second yes is "no").

You could change the cache to "no" (last yes) and then OmniStream will register that container without caching. Note that, by making a change to the stock container definition, this particular yaml will not get updated if a newer version of it is released (it won't block any other updates). If that ever happens, the best bet would be to disable Plex from your setup, copy the 101-plex.yaml to a personal config, such as 801-plex.yaml, and enable the 801 version. Then you could always choose to compare your version to the stock version and incorporate any changes you wish (or simply ignore them).

The changes were made this weekend because, while sometimes useful, it really was an oversight of the app ignoring those settings if the DNS entry already existed. Even worse, if the IP changed but the DNS was still registered, it wouldn't change that, either. Now, if it doesn't match what it is expecting, it will update it. If it doesn't exist, it will create it.

bdschuster commented 1 year ago

So to recap: Changing the 3rd yes to "no" will yield the same results prior to updating, but if you update the yaml, it will change back to yes? Unless of course I make it a custom yaml. Is there a way to globally define "no" for caching?

kelinger commented 1 year ago

If I update the yaml in the project, it will not overwrite changes you made to yours unless you force the update to do so (which is undocumented and unlikely to occur without you specifically telling it to do so). If you clone it to another file then updates should be unhindered in all cases.

There currently isn't a global cache on/off option. There are several reasons for this but none are that huge. I suppose it could be added as a variable in the omnistream.conf (without a menu that would likely cause more confusion to the 95% of the people not needing this or even knowing what it does) so that you could override the cache setting. I'll just need to make sure it doesn't trigger a case where it updates CloudFlare's DNS on every run because the override will take place elsewhere.

kelinger commented 1 year ago

@bdschuster - There's a new version posted that should do what we discussed above. Here's the best way to implement it right now:

cd $OMNIHOME
git pull
make-env rebuild
omni edit

Here, change the "CF_CACHE" from true to false

You may want to force the DNS changes without actually stopping OmniStream. To do this (after the above):

check-dns

If "check-dns" acts a little weird (it did for me the first time or two but I think it is because it is tracking/setting attributes that it wasn't earlier, then you may want to repeat "check-dns" until everything just says "exists" without making changes.

For just about everyone else, this shouldn't be necessary because the CF_Cache flag defaults to "true" which is the same behavior as prior versions. @bdschuster, you could also do a omni down, git pull, omni up but the above process should avoid downtime.

Changes:

There are no changes to the DNS removal processes.

bdschuster commented 1 year ago

Thanks! I'll check this out and let you know, then close this issue. I appreciate your help!

bdschuster commented 1 year ago

This works perfect! Thank you!