hey everyone. We've just released Channels DVR Server version 2024.01.08.1431 to the stable channel. This release has a major security fix that may change how you access your Channels DVR Server via your web admin or client,
Please read our official post to learn more:
I am using UptimeRobot to poll my channels DVR server to notify me when it is down. This authentication seems to have foiled the up check. I had been using a port tunnel in my router to allow ouside world access to the server:8089 port. An http access would tell if it is up, but now gets a 403 authentication error.
Very odd - i'm still in bridge on unraid and having no issues with accessing or using my channels setup
Per the official post. Then your docker implementation isn't affected. Only those that don't do reverse NAT correctly for the bridge gateway are affected.
@rgalverson You are correct we changed the status code of the unauthenticated responses. You can update your UptimeRobot to treat 403 as success:
Unfortunately, custom status check is only available to paying users of Uptimerobot. This is my only monitor so I have a free plan.
@rgalverson If you update to the latest pre-release, you can now hit /_ping and it will respond with a status code of 200.
There’s a “ping” recurring Action in OliveTin-for-Channels that does of a curl of the CDVR admin page, followed by a curl of a healthchecks.io URL. You’ll get an e-mail, text or other notification if it’s not received. Maybe this would work as a replacement?
PONG.
That works. Thanks.
@bnhf, thanks for the suggestion, but UptimeRobot is a cloud service (free to me). Running a monitor daemon locally on my only server (which also runs channels DVR) would not provide the same sort of coverage.
@eric, given that there's no provided authentication / authorization other than a cookie that expires...
how would one do an export from their channelsdvr server that is in docker to their emby server that is not in docker... without having to get a black belt in iptables, preferably.
@warrentc3 are you running a Docker setup that is now asking you to authenticate? What OS are you running? Is Emby running on the same physical server? How are you deploying the DVR in Docker?
It’s all on one physical box. One of my ChannelsDVR containers which connects to all the FAST providers like pluto, I have container attached to Gluetun, for privacy reasons.
Is there no way I could supply my subscription key or something in the header? even if i have to base64 it?
I have a Docker install on Synology and am affected by this security update. Do I need to go back and recreate the docker image all over again? I don't seem to see any place to edit the BRIDGE as noted in this update.
Yes, it does appear the container can only change the network type during creation. Please make sure you have saved a backup, made note of any of the settings and volumes you have made before you remove anything.
@warrentc3 Please describe your configuration in detail. The docker command line arguments or docker compose stanzas. Do you have one DVR running or multiple? Also, please submit diagnostics from your DVR.
@house_rs81 Here are more details:
From https://www.reddit.com/r/getchannels/comments/191tiqe/comment/kgzlk9h/
- Copy your current container settings -- note the ports and volumes you have configured. (I believe 8089 is the default port.) Consider taking screenshots of each tab in your ChannelsDVR container settings.
- Stop the existing container (when it's in between recordings).
- Change the port numbers of the existing (now stopped) container. (I added 100 to each port.) ContainerManager complained when I tried to use the same ports as the old stopped container.
- Create a NEW ChannelsDVR container.
a. Include the same ports you noted earlier (e.g. 8089).
b. Re-add any volume mappings (e.g. ChannelsDVR volume, TV/Movie recordings elsewhere on your NAS).
c. REMEMBER TO SELECT HOST NETWORKING, NOT BRIDGE.- Start the new container.
- Verify that you connect to the admin page via web browser, phone client, etc.
Not sure if you want Docker versions or are reporting this issue to Docker.
My Synology NAS is running the latest DSM Version: 7.2.1-69057 Update 3
I'm using the latest Container Manager Package Version: 20.10.23-1437
{
"Client": {
"Platform": {
"Name": ""
},
"Version": "20.10.23",
"ApiVersion": "1.41",
"DefaultAPIVersion": "1.41",
"GitCommit": "876964a",
"GoVersion": "go1.19.1",
"Os": "linux",
"Arch": "amd64",
"BuildTime": "Fri Sep 8 08:19:48 2023",
"Context": "default",
"Experimental": true
},
"Server": {
"Platform": {
"Name": ""
},
"Components": [{
"Name": "Engine",
"Version": "20.10.23",
"Details": {
"ApiVersion": "1.41",
"Arch": "amd64",
"BuildTime": "Fri Sep 8 08:18:18 2023",
"Experimental": "false",
"GitCommit": "5fcb1cf",
"GoVersion": "go1.19.1",
"KernelVersion": "4.4.302+",
"MinAPIVersion": "1.12",
"Os": "linux"
}
}, {
"Name": "containerd",
"Version": "v1.6.15",
"Details": {
"GitCommit": "b23a389d8c181697302d163356e97dec04eb8d88"
}
}, {
"Name": "runc",
"Version": "v1.1.4",
"Details": {
"GitCommit": "5af893d"
}
}, {
"Name": "docker-init",
"Version": "0.19.0",
"Details": {
"GitCommit": "ed96d00"
}
}
],
"Version": "20.10.23",
"ApiVersion": "1.41",
"MinAPIVersion": "1.12",
"GitCommit": "5fcb1cf",
"GoVersion": "go1.19.1",
"Os": "linux",
"Arch": "amd64",
"KernelVersion": "4.4.302+",
"BuildTime": "2023-09-08T08:18:18.000000000+00:00"
}
}