PeteAsking

I will try if no reply by tomorrow

I did like 4 posts ago.

Not sure how to contact squid from these forums I sent him a PM and it says he has logged in since but he didnt read my message. If anyone knows please let me know as I cant progress without his help

Still waiting for a reply from Squid on these forums so I guess he is away or something as he hasnt read my messages yet.

I have been speaking to the developer and he told me he has a github page here: https://github.com/11notes/docker-unifi and he will be keeping it up to date going forward so if we have issues we can open an issue there. One thing he told me is that uid and gid should be 1000. Im not 100% clear on this so I have asked @Squidbut he hasnt gotten back to me on this. I also asked if we could make a community app and test it works but will have to wait his reply. So far this isnt seeming to bad but will post any new information I get as it comes. - P

I dont mind, but I like to make sure I have everything in place before making promises. So you will have to wait a few days while I test and discuss with the developer of the actual image - because if it transpires he is not accommodating to us using the image then I would be in a position where I have made promises to you guys that I cant keep. So at this point I am more interested in checking what can be done technically and then ensuring after that this would be a workable long term solution. Then I can come back here and tell you what I have found out so you can be involved in deciding what direction is best overall. Seems like it affects a lot of people so probably best to ensure everyone had a say. Also it is certainly the case that a valid approach is the one that linuxserver.io has suggested - 2 containers which has mongodb split from the unifi container. They didnt give any detail why this is better for them so I only see one side of the story here. It might be that unraid is different to most users of the images since most users are using podman or docker compose while unraid is just simple pure docker. Hopefully @wgstarkscan get a second option up an running so then you guys can decide at least between 2 options. Either way I will continue working on a solution as well and let you know what happens but Im pretty much confident that since we have until January to decide that there is no rush and one way or another something will be created by then. It just doesn’t seem like something everyone has to panic over so lets see what people come up with and let everyone decide what they like best based on some actual testing. End of the day we all want something that doesnt break and things were working pretty well I thought up till linuxserver.io decided to depreciate the image so just want to get back to that situation where things can be deployed and not have to worry much. Hope this makes sense. Just want to reiterate Im not promising anything until I feel confident things are up to my standard so I dont let anyone down on anything.

Yes that is exactly the sort of issue that could occur and why I dont personally want to go in that direction.

Its not my image but yes its identical to what the old soon to be depreciated image is in pretty much every way which is why using it is so simple. Its just picking up where linuxserver.io left off.

Its more complex to setup and requires 2 docker containers running and communicating with each other. So generally as complexity increases there is more that can go wrong and lower reliability is expected. Also nobody has started looking at how to migrate to it but you could take a look and tell us if its super easy.

Its not a big deal @wayner I am working on an easy solution. As you are worried let me put your fears to rest and let me tell you where I have gotten up to. We will need to involve the support of a few people on this unraid forum for a final solution but I have a 7 step migration plan that will keep you working and hopefully we can flesh out a template for the "community apps" so that it can get its own official thread. I have already started testing and moved to a different container and it seems to work fine. At any rate here is a work in progress if anyone else would like to test it as an initial test (for a final solution a backup and restore similar to below will be required again and it is very easy so if you can test please do so). A user I engaged with on reddit was in the same predicament and created his own container to resolve the problem. His is also using ubuntu as a base (same as linuxserver.io image) so is pretty much identical. DO NOT UNDER ANY CIRCUMSTANCES SIMPLY EDIT YOUR CURRENT RUNNING UNIFI CONTROLLER AND JUST REPLACE THE IMAGE REPOSITORY. His container is here: https://hub.docker.com/r/11notes/unifi STEPS TO CHANGE AS AN ALPHA TEST (Should not be dangerous to do): Step 1: Login to linuxserver.io running unifi controller Step 2: Take a backup in the interface (System - backups - Download - last 7 days) Step 3: Shutdown linuxserver.io controller (leave it off and available in case you need to go back). Disable autostart. Step 4: Create new container from template (Add container - unifi controller) Step 5: Change 3 values (name change "unifi-controller" to "unifi-controllerNEW" ; repository change "lscr.io/linuxserver/unifi-controller:version-7.5.187" to "11notes/unifi:7.5.187" ; change under more settings ‘appdata path to have ‘NEW’ on the end eg: /mnt/user/appdata/unifi-controllerNEW ; leave all other settings alone. (Note if you fail to change these 3 settings you will wipe your old container.) Step 6: Hit apply (It is created from a template exactly the same as the old settings, only thing left is to restore from backup just created). Step 7: Restore from backup after logging in (eg: https://192.168.2.4:8443) and set docker to autostart on unraid. You can now login and site is restored. As always, please take a backup before just following some randos instructions on the internet. Im trying my best but not infallible, if you manage to find some way to blow up your house following the above steps, there isnt much I can do so just be logical, check you understand whats going on and so on. Benefits of this method: 1 docker container is maintained going forward, very easy to migrate to, pretty much no customization beyond giving it a new name and pointing it to a new image location since it uses all the same settings as the old template Any feedback on this idea appreciated. Currently settings are not preserved on reboots of the image so this is a test only before you revert to your old container (I think, not sure still testing this). Kind regards P

I think you have to just setup 2 new containers (one for the unifi and one separate mongodb container). What I would do is change the default management port on the existing one and then try get the new 2 containers working together and when they are working then doing a backup from the old on and shut it down, and then import to the new one. Sounds like a lot of boring effort.

If you backup your appdata I believe you should have no problem upgrading directly to 7.5.187 but will be able to roll back if you need to. In this case you can tell us if the new version is acceptable to you and I will update what is old stable and bring the versions tagged in my previous post along one extra version so everyone can update to the next version applicable to their deployment. I have just deployed 7.5.187 and have had no issues. The upgrade was very fast for me also, a couple minutes at most. I note a couple of people on the forums at unifi had to restart a device that dropped offline manually in order to have it brought online to the controller but nothing more serious than this. Let me know if it works for you and I will update. This version seems like it will be the one to stick on for a while. Kind regards Pete

A new version UniFi Network Application 7.5.187 is available. I intend to update tomorrow, it seems like an alright version. We will find out tomorrow sometime if that is true.

This question has too little information to help you. Please add more relevant information.

I believe you can export site function from your config so you would do this process so you can readopt the AP's. https://lazyadmin.nl/home-network/migrate-unifi-controller/ also: https://www.clevendo.de/hilfe/support/setting-up-and-managing-your-unifi-controller-in-the-cloud/migration-en/moving-the-unifi-controller-to-the-new-server/ I havent had to do it but this process seems logical to me. When deploying via unraid the tag you use will be like this format: lscr.io/linuxserver/unifi-controller:version-7.4.162 Please backup your docker images with : Appdata Backup plugin. Kind regards, Pete

If you are on tag 7.2.95 you could upgrade to this 7.3.83 tag, I consider this moving from "old old stable" to "old stable" on Wifi6/New Deployments. Reminder of current situation: Legacy systems: 5.14.23-ls76 or 6.5.55 versions seem fine. (AKA "old old old old stable" or "old old old stable"). Wifi6/New Deployments: 7.2.95 or 7.3.83 tags are fine. (AKA "old old stable" or "old stable"). Old stable and old old stable are the kind of stable where you upgrade and should have no issues upgrading (always backup just in case). If you require a new feature from a later deployment you can use "'stable'" which I consider to be 7.4.162 This is not for business deployments that cannot afford any downtime, stable is considered "this can run stable if you fiddle around with it and then leave it alone". If your business can live with an hour of wifi being down you can move to it and sort out any issues then get it working. Its that kind of stable. Do not use tag: "latest" unless you are an alpha tester who fixes their own problems Future version is : 7.5.174 at this time. (Using future versions is risky.) All these tags exist in the unifi docker image location here: https://hub.docker.com/r/linuxserver/unifi-controller/tags Tags available: Old safe versions for legacy hardware - 5.14.23-ls76 (old old old old stable) 6.5.55 (old old old stable) Newer safe "wifi6" versions for current hardware (old hardware might not adopt) 7.2.95 (old old stable) 7.3.83 (old stable) <--------- best version for business use if business uses current hardware not out of support Latest feature set versions 7.4.162 ('stable') 7.5.174 (future version/release candidate, YOU are an alpha tester/do not use in production/same as using "latest" tag). Kind regards Pete For reference at home I am currently on 7.4.162. I test the versions for our clients who have unifi wifi aps. No client is on any version beyond 7.3.83 at this time.

And that is why you never run the latest tag:

Thanks I will work on this.

Hello, There is a docker application that does not exist for unraid. I would like to know how to create the unraid docker and how to be a maintainer so that this project can exist on unraid. Is there anyone who has done this before who is willing to help explain the process? The app I want to use is this one: https://github.com/cp6/my-idlers "A self hosted web app for displaying, organizing and storing information about servers (VPS), shared & reseller hosting, seed boxes, domains, DNS and misc services." Just wanted to ask as it would be useful to gain an understanding how the process works. Kind regards P

I see that a new patch was released for 7.5.174 today : "Last pushed 4 hours ago by linuxserverci" So most likely they have patched the upgrade issue. Im probably not going to try again as the release has an incredible 16 pages of issues after just 7 days since it was released (it starts as an RC then was moved to an official release yesterday). https://community.ui.com/releases/UniFi-Network-Application-7-5-174/d05b091f-f00c-4ebb-8f42-b77e0adac78b?page=14 For this reason Im just going to give it a miss, I already had to roll back backups once and dont particually feel like running a version that will just be replaced with a version this is identical but has all the fixes in a few weeks time so may as well wait this one out. GL whatever decision you guys make P

Please do not upgrade to 7.5.174 at this time. It is broken.

Something strange I noticed about compression - when using multicore tar.zst the resulting backup for me was 11gb but when using normal tar.gz the backup was compressed much more resulting in only a 9GB backup. Is this to be expected? My impression is that zstd would normally result in better compression, not worse. However with this plugin it seems that using the multicore compression "newer" option has made the backup take more space than just the older style compression. Even stranger is before when using the old backup (I migrated today to this new plugin) the backups were smaller still, being only around 6GB each. Unclear what options have changed surrounding compression to have made such dramatic increases in size. Perhaps exposing the compression level to the user would be beneficial so we can set a max level 9 if desired?

Was able to upgrade without any issues from 6.11.5 I think it was before.

I think you are supposed to be on 5.14.23-ls76. Hopefully someone else can confirm. i thought if you had a usg router you didnt use this docker though. Could be wrong as I dont own one.

7.4.162 is more stable than 7.4.156. Please go directly to this version if you are not on .156. Situation: Legacy systems: 5.14.23-ls76 or 6.5.55 versions seem fine. (AKA "old old old old stable" or "old old old stable"). (Old in wall APs or other legacy APs need this?) Wifi6/New Deployments: 7.2.95 or 7.3.83 tags are fine. (AKA "old old stable" or "old stable"). (Newer APs wont adopt if not at least this?) Current (Production/Business should be fine. Hopefully): 7.4.162 ("stable") (Dont use this if your company builds rockets or does heart surgeries. You dont need it.) Future version (Only recommended for home or if your business requires a new feature missing from an old version): n/a at this time. (Using future versions is risky.) Kind regards P