jedimstr

Well now that 5.10.12 is on the download page: https://www.ui.com/download/unifi/ I was expecting the latest "unstable" tag to get it, especially since I saw there was an update last night. But no, the Unstable tag does not have the fully released version yet. Can you guys push one out instead of waiting another week since it WAS on the download page before the latest Unstable tag was updated last night?

Extremely appreciated! Can't wait until 6.7 hits stable release.

Thanks! Confirmed fixed.

I'm seeing the following error for the speedtest-for-influxdb-and-grafana container in the log after the latest update and then the container stops: Traceback (most recent call last): File "/src/InfluxdbSpeedtest.py", line 9, in <module> from influxspeedtest.common import log ImportError: No module named 'influxspeedtest'

Definitely a bummer... thanks anyway. If you encounter something in the future that you may want to try, I can test. If it helps any, here's the github repo for the Absolute Series Scanner and HAMA agent with plugin and scanner install instructions: https://github.com/ZeroQI/Hama.bundle Thanks!

Barely generates anything when it errors out... This is what that log has: :/mnt/cache/appdata/NowShowingv2/logs# tail nowshowing.log I, [2018-03-28T20:51:36.777404 #1208] INFO -- : Announcement Email Sent. I, [2018-03-28T20:54:53.374364 #1213] INFO -- : Starting up NowShowing I, [2018-03-28T20:58:53.251809 #1226] INFO -- : Starting up NowShowing I, [2018-03-28T21:01:42.762540 #1239] INFO -- : Starting up NowShowing I, [2018-03-28T21:42:04.322653 #1188] INFO -- : Starting up NowShowing And the container log has this after a fresh restart and test report run: [s6-init] making user provided files available at /var/run/s6/etc...exited 0. [s6-init] ensuring user provided files have correct perms...exited 0. [fix-attrs.d] applying ownership & permissions fixes... [fix-attrs.d] 10-apply-perms: applying... [fix-attrs.d] 10-apply-perms: exited 0. [fix-attrs.d] done. [cont-init.d] executing container initialization scripts... [cont-init.d] 10-set-uidgid: executing... usermod: no changes ----------------------------------------- NowShowing ----------------------------------------- Brought to you by: Ninthwalker/GroxyPod/Limen75 ----------------------------------------- User xyz set to: 99 Group xyz set to: 100 ----------------------------------------- [cont-init.d] 10-set-uidgid: exited 0. [cont-init.d] 20-setup: executing... Advanced config file detected. Keeping existing files rm: can't remove '/etc/fail2ban/jail.d/*': No such file or directory Server ready Please go to http://hostServerIP:hostPort/admin to configure settings [cont-init.d] 20-setup: exited 0. [cont-init.d] done. [services.d] starting services [services.d] done. 2018-03-28 21:40:41: (log.c.217) server started /usr/local/sbin/combinedreport: end of file reached (EOFError)

Looks like I'm getting the same old error I used to get with the last versions of the old PlexReports and original Now Showing even with my HAMA based Anime Library excluded: /usr/local/sbin/combinedreport: end of file reached (EOFError) This shows in the log everytime I run a test. SMTP setup works with the announcement email. I'll note (just as I did sometime last year) that I used to be able to run PlexReports without issue since it ignored my HAMA agent based Anime Library, and at some point (probably same time PlexReports started having issues with empty/blank Libraries) PlexReports stopped working. Now Showing V1 and now V2 doesn't seem to fix this situation. I added my Anime Library to the Plex Settings/Libraries To Skip, but it still hits this EOFError. I even added all my personal family video libraries and other home video libraries that shouldn't be an issue to the Libraries To Skip list, only leaving Movies, TV Shows, and my music libraries (which this should be skipping anyway since they're not videos). Still no go.

Try the controller override settings detailed on the previous page of this thread (pg 23). There are screenshots of the settings you need to change. Do this in conjunction with another cycle of set-inform (you actually have to do set-inform twice on the device usually, before and after you request adoption on the controller).

Per mention on Reddit by Ubiquiti employees, this isn't entirely accurate. AP Generations: Gen 1: UAP, UAP-LR, UAP-OD, UAP-OD5, UAP-v2, UAP-LR-v2, UAP-IW, UAP-Pro, UAP-OD+ Gen 2: UAP-AC-Lite/LR/Pro/EDU/M/M-PRO/IW/IW-Pro Gen 3: UAP-HD/SHD/XG Very recently added: MTK Gen 1: UAP-nanoHD The ones EOL and not supported in 5.7 anymore: BRCM Gen 1: UAP-AC, UAP-ACv2, UAP-AC-Outdoor So basically only 3 of the 9 original Gen1 AP's have reached End of Life with 5.7.x, so its definitely not "dropping support for all their APs below the version currently being sold" since 2/3rds of the original Gen1 and all the other Gen's are still supported for now. That said, I agree that it would be good practice to have an LTS tag for the container in addition to the Stable and Unstable tags. Per the discussion above, it looks like the Stable tag is the LTS tag since latest on LTS is 5.6.36 and matches the latest update on Stable.

If you need a non-standard port for set-inform, you'll have to do it per device by SSH'ing in. If the IP set matches what the override at the controller level has, it shouldn't replace what is set on the device even if you use different ports.

Just to throw in a bit more info here... the newer controller software for some stupid reason can reset the set-inform if it thinks it knows the "correct IP". It's more aggressive than previous versions in doing this when Provisioning. That's why set-inform at the AP or Switch may not stick after awhile. Controller thinks its smarter than the devices. Also the reason for the override setting mentioned earlier.

Thanks for that... that's kinda what I asked for earlier regarding where the issues were mentioned.... With that in mind, the UniFi Wireless thread's TLDR: 1. most of the issues mentioned have to do with Wireless Uplink mode which is the pseudo-Mesh mode AP's have when disconnected from ethernet. Not one of the issues mentioned so far in the thread here or by the both of you. 2. the only mentions of adopt/disconnect issues in that thread mentioned an issue with AP's holding on to controller IPs for a container versus a cloudkey when going back and forth with bold text saying to "Ignore this Error Report". Not involved with the issues that you two or I have experienced regarding adopt/disconnect issues. And I agree with both of you that my issues in the past though similar may not be the exact same issues you had with the 5.7.20, but I only offered up there as an example that the issue symptoms aren't necessarily tied to a release, but could be indicative of a similar situation with Container/IP retention. But suffice it to say, I really don't mean to piss both of you off and all the work you guys do is extremely appreciated... but maybe a sample size of two versus what's been offered as potential more real world deployments could potentially help. But if you don't really want any logs or variations of setups from us on the unstable branch, that's your prerogative.

Well, I did mention I "may be blind" but I didn't see the threads talking about this specific to 5.7.20. The Adopt/disconnect issue threads actually go way before the beta versions of this release.

Also, just to re-iterate... I had the exact same issue with the neverending adopt/disconnected cycle, but mine happened when I upgraded the container awhile ago to 5.6.30 and whatever the previous version was. Solution for me was as I mentioned above (not just set-inform/reset hardware, etc).

Nope, not confusing anything... if some of us have cloudkey's, direct installs, and other such installation methods for the controller working on 5.7.20, then something has to be up with how it's interacting with a containerized environment. Whether that's up to people on this end of the issue or the other end of the issue to find and resolve, ¯\_(ツ)_/¯ If it's at an impasse, and it continues to work outside the container, but it continues to break inside the containers you package, and Ubiquiti doesn't do anything about it, then we all lose I guess.

So for those of us with larger multiple deployments of UniFi gear using this container... if we were to successfully deploy the unstable branch (knowing the risk, or lack there of if you know how to export UniFi Controller Configurations and Import them into brand spanking new container images regardless of version... note, there's no need to worry about appdata in this case unless you have custom JSON overrides), what sort of logs/info/docs would you need to help you figure out any issues with the release? I'm sure many of us would like to help.

I hear you and understand... but with comments like "don't want to walk people through it"... keep in mind many of us here aren't newbs either... very very far from it.

Well ok then... but did you even look at the setting I pointed out. Because that's there specifically for the issue you mentioned. Resetting won't do squat for this. You have to let the devices know about the host's IP for containerized controllers or you'll just keep sending the internal IP... which causes the Adopt/Disconnect loop. Just plain set-inform won't do it either because that gets overridden by the controller if the setting isn't active to have a manually set IP go across. Short of setting this checkbox and the manual IP in the controller settings, everything you mentioned won't do squat as you've found.

I've had this with all my AP's, two Switches and USGPro on the current 5.6.30 release, and the previous release update. I didn't fix it by downgrading though. I SSH'd to the individual devices and had to force the set-inform to my controller's specific URL (ssh to the device and type "help" for instructions on how to do manually set-inform). This is actually a common problem with containerized versions of the controller software if you have it bridged because the internal IP of the controller is different than what the devices will see. The longterm fix to this was provided by Ubiquiti in 5.6.30 under the Controller settings, but for some stupid reason isn't enabled by default. Check the checkbox in this screengrab in your controller settings and set the domain name or external host IP for your unraid server if you don't have one dedicated to the docker container. This is most definitely not a 5.7.20 issue, you just happened to encounter it with the 5.7.20 release.

Really curious... what ARE the issues people are seeing with 5.7.20? I may be blind but I'm not seeing people having problems with 5.7.20 outside of this container thread (any issues I've seen on reddit are all user specific issues). Ubiquiti isn't pulling this release like they've pulled others in the past. So what's happening? In fact, the biggest issue I see being reported are complaints that support for some of the first gen UAP units (like the square ones from 2013; includes:UAP-AC, UAP-ACv2, and UAP-AC-Outdoor) are being dropped. Some gen1 units are still supported like the UAP, UAP-LR, UAP-OD. For those of us without any 5 year old units, are there any big issues (moreso than regular releases that have warranted an updated container)? Definitely don't want my controller to update to a truly unstable release, but at the same time I hate not being able to take advantage of the new stuff like the beta ipv6 support.

meh, neither do I... that's what Reddit's for (releases get posted there quicker than UBNT's site).

They just haven't updated that page yet... https://community.ubnt.com/t5/UniFi-Updates-Blog/UniFi-5-7-20-Stable-has-been-released/ba-p/2271529 The Support page was last updated Monday this past week when 5.7.20 became a release candidate. The Community page was updated on Thursday when the 5.7.20 graduated to full stable release. Someone didn't get the support/helpdesk guys to update their FAQ page yet. I don't think we should wait for the support faq before updating the docker image to get the actual latest stable release. Especially since there was a docker container update after the stable release went out, but without that release.

So UniFi 5.7.20 stable had been released on Thursday, but the usual docker container update on Friday was still stuck on 5.6.30. When can we expect an update to the container. There are a lot of goodies in 5.7.x including IPv6 beta support, SNMPv3, IPS beta, and per client historical statistics.

Will 2.0's Library filtering also allow me to skip my HAMA plugin agent based Anime Libraries? I was an avid plexReport user, but had to stop using it and the subsequent NowShowing replacement because they just failed when encountering my non-standard Libraries.

Sounds like context switching/CPU spiking issues, you may want to check your CPU temps. You may be thermal throttling. Could be time to re-apply some thermal paste or rethink your CPU cooling setup.