[Support] - Unifi-Controller: Unifi. Unraid. Reborn.


Recommended Posts

On 11/4/2023 at 1:41 PM, PeteAsking said:

The important information at a glance section:

---------------------------------------------------------------------------------------------------------------------------------------------------------

Development status of community app:

Canary: 31/10/2023 - 04/11/2023 [COMPLETE]

Alpha: 04/11/2023 - [STILL IN ALPHA]

Beta: n/a

Delta: n/a

Stable: n/a

 

Canary - Dev build only, not public use.

Alpha - Testing only, not suitable for home or production use. Request for community to help to test if able.

Beta - Suitable home use only.

Delta - Suitable home or production use, requires specific steps to be followed to function.

Stable - Suitable all deployments, easy deploy ready.

---------------------------------------------------------------------------------------------------------------------------------------------------------

Docker tags of unifi builds:

Alpha: This ‘latest’ tag is now currently disabled as we are not currently testing and does not exist at this time. 

Stable: 11notes/unifi:7.5.187-unraid

Old Stable: n/a

Old Old Stable: n/a

 

VERY IMPORTANT NOTE, CRITICAL: In the repository there are 2 types of image. version-unraid and just version. eg: 7.5.187-unraid vs 7.5.187.

the pure version numbers run the docker in 1000:1000 and require special changes to the appdata directory permissions to function. If you use the latest tag, you will need to make these changes.

If however you are a normal non alpha tester, you can use the version-unraid tag which correctly sets the user as 99:100 eg: 7.5.187-unraid

When selecting a new tag to upgrade to, always use the version-unraid tag. These are tested specifically for Unraid. The other tags are for pure docker deployments.

 

Alpha (latest tag, do not use) : This tag is either "latest" or has been released by unifi and reverted back to release candidate due to issues. Do not use except for specific reasons understood by you (do not complain to me when deployment breaks, its on you to fix).

Stable: Latest stable build vetted by community for home use only. Newest features present, that are stable.

Old Stable: Latest stable build in production vetted by community for home or production use.

Old Old stable: Production builds that lag behind to avoid issues. Updated less often and skips low quality builds, has fewest new features by design.

---------------------------------------------------------------------------------------------------------------------------------------------------------

 

Unifi-Controller: Unifi. Unraid. Reborn.

277435263-1b01facd-1b15-4ba7-9495-e709c2

https://github.com/pallebone/UnifiUnraidReborn

The how to section:

 

This docker expects you to use tags to move between builds. When you install the docker you will note that a specific tag has been chosen for you on deployment.

Do not use "latest" tag. Using latest tag means we cannot and will not support or help you on this thread. You are considered the fixer/expert if you use latest.

To choose a desired tag review the tags here: https://hub.docker.com/r/11notes/unifi/tags

 

To install this docker

 

Instructions include moving from a different docker image/community app however these steps can be ignored if not appropriate.

 

1) Login to current running controller web interface and take a backup of 7 days on current controller. You will obtain a backup file such as: network_backup_02.11.2023_08-10_v7.5.187.unf

Make sure old version of unifi controller is the same version you will be migrating to. Unifi is difficult if the versions are different. 

 

2) Stop old Unraid controller/Other controller and turn off autostart/disable from self starting. You can leave this old deployment alone at this point in case you ever need it again.

 

3) Go to apps and install new controller (unraid-controller-reborn). Avoid changing random values you dont understand/cant fix yourself in the template.

 

4) Start container and set to autostart. Restore your backup, it will require you to manually start it again after backup is restored.

Note: When you restore, there is no confirmation the restore completes. After a minute or so  the docker simply stops on unraid (refresh docker page on unraid ui) and the unifi web page just hangs on restoring. You must manually start the docker image again when its stops.

 

The container should now be running normally at this point. If not check steps again and ask for help.

---------------------------------------------------------------------------------------------------------------------------------------------------------

 

Notes:

I will add notes here when appropriate.

 

Removed install instructions no longer needed:

3) Set directory permissions for new container (can be done after deploying image in step 4, see and read instructions).

To do this prior to deploying the app, use command such as:

 

install -d -m 777 -o 99 -g 100 /mnt/user/appdata/unifi-controller-reborn

 

Commands must be used via ssh or the web terminal (little icon in top right of unraid web interface).

 

If you deploy the image first by following step 4 without doing this, and let it create the docker appdata directory, then you will need to stop the docker then run these commands and start it again afterwards:

 

mkdir /mnt/user/appdata/unifi-controller-reborn

chmod 777 /mnt/user/appdata/unifi-controller-reborn

chown nobody /mnt/user/appdata/unifi-controller-reborn

chgrp users /mnt/user/appdata/unifi-controller-reborn

 

The entire point of this is that if you do a 'ls -l' on the directory with your docker containers you will see the permissions are set as:

drwxrwxrwx 1 nobody users   0 Nov  3 16:41 unifi-controller-reborn/

 

By default if you do not do this, the permissions will be drwxr-xr-x and the docker app will not be able to run and write files to this directory.

 

If I'm reading this correctly. You want us to use the unraid tag so change repository from 11notes/unifi:7.5.187 to 11notes/unifi:7.5.187-unraid

 

getting ready to move tag container to remain in stable branch.

 

 

 

  • Like 1
Link to comment
5 minutes ago, bmartino1 said:

 

If I'm reading this correctly. You want us to use the unraid tag so change repository from 11notes/unifi:7.5.187 to 11notes/unifi:7.5.187-unraid

 

getting ready to move tag container to remain in stable branch.

 

 

 

 

so moving tags broke the custum xml edits for extra pamerters :(

 

image.thumb.png.ddc5efa3a30a02c1a6d83791b3963b2d.png

 

image.thumb.png.78e870a6b7e5e2fc719758dc2362a0ec.png

 

I can't use tag -unraid.

 

Copied the back and firmware folder out to have a backup, went to controller to download another backup to restore.

 

Click add container to click the template and clit the x at the top to remove the template.

 

Went to apps tab to install docker keeping previous appdata

(Will attempt fresh with no app data... next)

 

and failure to load webpage.

 

The only edit change i'm doing that should work for any docker is:

image.png.49f84e324688013ad953b5f4cbfff583.png

Lowering the ram req from 8 to 4 

adding custom macvlan info to docker for networking:

--memory=4G --mac-address 02:42:C0:A8:01:5B --hostname UNIFI-DOCKER

 

and changing the docker network type:

image.thumb.png.a183c92d484622dd11dd45f0002dbf60.png

 

If a docker is using bridge, the Custom br0 should be working....

 

Will report back findings.

Link to comment

Purged folders in appdata. Removed docker and images. Removed template:

 

image.thumb.png.60c667a023ae3202e14c38637bd11414.png

 

*Kept old img of working to restore to for testing as this is also a test for updates to come in the future.

 

To the app install page:

image.thumb.png.59b6fb596f212fbc2e09eac2e19af4ac.png

 

 

image.thumb.png.08a8f34fd7f5a84b33cb23eb713ed93b.png

 

with my added changes to add mac hostname and use custom br0 instead of bridge gets me a webpage:

 

image.thumb.png.778cda349df7f3eba95a163e6f7fb2ca.png

image.png.a825294df856d14cd17cdbbab80cc17a.png

 

Will now test for restore.

image.thumb.png.1e7216c95c2ca6506b8e261f89cf2298.png

 

Restore stilll breaks and stops docker:

image.thumb.png.a751d8f53bbaa3aa0259317e495bb01f.png

 

lets see if it restored?

Rstore sucessfull:

 

image.thumb.png.939ba34e002cc5ae467aa85bc879abb0.png

 

so in changing tags / updates may need to do the backup restore method to move. If editing outside the XML!

 

now to stop docker and readded old firmware and backups.

image.thumb.png.31f8d97711af0749107ed19d9cd8ed3e.png

 

and it boots and I see my backups and firmware...

 

image.thumb.png.13a2a9c6271b5a8201ce291bc4d4bde3.png

 

so now the question if there is existing data for future build release and updates how to maintain and update to move?

 

 

  • Like 1
Link to comment
13 minutes ago, PeteAsking said:

@bmartino1It is not clear to me why you have ‘privilege = true’ in your setup. This is not default in the setup. 

 

it to enforcer docker root access to write when starting a new docker. it is not always needed. it more permission setting and controls. Will need to re look at squids info on that option for more info.

 

https://github.com/binhex/documentation/blob/master/docker/faq/unraid.md

 

more to grant the docker otehr host access such as network devices or gCards need for other use within the docker

 

unRAID Docker FAQ

Q1. What does the Privileged check-box do?

A1. The Privileged checkbox allows the Docker Container to perform certain privileged activities, these are typically required for additional networking functions, such as creating/editing virtual adapters

Edited by bmartino1
add data
  • Like 1
Link to comment

Interesting. This docker is designed to avoid at all costs using root in any way whatsoever so most likely enabling this (privileged) option is breaking things. The image is built under the assumption root will not be used, its possible enabling this is causing the issues you are seeing and everything should function without that option. 

Edited by PeteAsking
Link to comment
54 minutes ago, bmartino1 said:

 

Restore stilll breaks and stops docker:

 

lets see if it restored?

Rstore sucessfull:

 

 

The restore is designed to work this way for some reason by unifi. So it doesn’t break, it just works like that. If that’s incorrect then unifi would have to fix how it works. 

Edited by PeteAsking
Link to comment
23 hours ago, PeteAsking said:

The restore is designed to work this way for some reason by unifi. So it doesn’t break, it just works like that. If that’s incorrect then unifi would have to fix how it works. 

 

I highly appreciate you and your work, as it is hard to maintain and create stable dockers.

 

Having ran the older jar file of this unfi controller, literary xp era v0.6. Coming from other networking deployments with multiple ISP with unifi equipment and deployments.... This also isnt' the first nor will it be the last time for unraid /ubquityi / unifi like dockers to do this weird drop deprecate and resync.

Old example is this old stable docker: https://hub.docker.com/r/jacobalberty/unifi

their last unifi version is 7.1.68 the current unfi version is v 7.5.187

 

Jacobalberty has not updated in quite some time. As such, it considered unmaintained as it's not running the latest version. Depending on ubiquity equipment, running an older version isn't a problem. You risk CVE and other by not staying up-to-date. This is harder when running a web server.

 

I can tell you that a restore should not error out the docker. a Action with the webgui should not have a force close due execution with in the web app. per the last error message, what did the restore due to the config file unifi system.properties to cause the error?

 

While I agree that this is more a unify issues, that fact that we have a java error explaining that a thread exception happened. This may be due to a misconfiguration with the JRE and tells me that there is more to the error than just Unfi issue with the restore process.

 

Having finished my testing for a stable production move. My documentation is on the other forum for support for the deprecated unifi docker for transfer. This docker atm is too unstable for me to continue testing for production use cases.

 

Having did a restore in the old deprecated docker and the new one, I can confirm that the restore doesn't kill the docker. (So what setting or action is that docker doing that allows it to continue to run? The restart process, maybe?)

 

I assume some other docker setting may be need like option stop unless restart or other there may be a setting somewhere passed that is enabled by your default configuration.

 

A side explanation Example similar to me adding a custom hostname option to the docker run. I have seen issues within dockers that now the hostname is changed and the hostname is being called and not able to respond as there is a conflict with a hostname within the docker due to the option set.

 

I can't pinpoint it, but the error is clearing, states it was expected a installation or configuration that is not there. That java error due to default docker protection force close a docker for host data protection.

*Not a Hughes problem, especially if it still completes the desired outcome with is a restore of the unifi system.

 

But that leaves a potential vulnabertiy and question for the future and evolution when unify changes to their next production release.

 

When testing it was at least stable, but if I have to delete my docker appdata do a backup restore for each revision. Sorry. I'm out, that's not stable in my book. I will glady help test to try and assist when able and can. Furthermore, I do hope your maintenance and continuation on this continues.

Link to comment
2 hours ago, PeteAsking said:

Unclear what you mean 'by each revision'. To upgrade to a later tag you just change the tag and the database auto upgrades. The restore option is if you are moving from another container.

 

I agree but that didn't work fore me see above post with web error:

Had to do a fresh delete to get working again. Was unable to do a in-place upgrade.

 

Moving from

11notes/unifi:7.5.187 to 11notes/unifi:7.5.187-unraid

 

Link to comment
16 hours ago, bmartino1 said:

 

I agree but that didn't work fore me see above post with web error:

Had to do a fresh delete to get working again. Was unable to do a in-place upgrade.

 

Moving from

11notes/unifi:7.5.187 to 11notes/unifi:7.5.187-unraid

 

That would not be supported as the images are build in different ways, it would be only from one unraid version to the next.

Link to comment

I also just install (/unifi:7.5.187-unraid) per directions.  All was fine, but I needed to adjust Port: 1900 as it was being used to my Plex docker.  It took a `sudo netstat -pna | grep 900` for me to realize 1901 was already snagged by mosquitto, so 1902 it was!

 

Opened the WebUI, restored the backup, and after a docker-page-refresh, it already showed as stopped, so, restarted it, opened the WebUI and followed the prompts to re-add it to my ui.com site. Not sure how I went to the ui.com site - maybe it was a typo/mis-click on my end - but upon re-visiting my local url site, I logged in as before and everything was there (no adoption needed).

 

Great Job, thank you.

  • Like 1
Link to comment
1 hour ago, ssjucrono said:

sorry, trying to figure out how this is better than the other docker containers? Very curious to give it a try but I want to understand the difference first? 

 

thank you

 

Pretty much what @JonathanMsaid. I realise this is not well known, but the linuxserver.io one is being deprecated in its current form and this is being developed as a replacement that is similar to how that one worked. 

To continue with linuxserver.io going forward will require 2 dockers to be configured and maintained and communication between them at all times which is very different to the current single docker solution they provide. 

Edited by PeteAsking
Link to comment

trying out this container now.

 

I am having a conflict with port 1900. Plex is also using that port and I do not see an option in the Plex Template to change it. I changed on the unifi reborn but then it wasn't adopting my unifi devices. So I turned plex off and tried using port 1900 on Unifi Reborn and it is still saying it can't bind to 1900 as plex is using it though it is powered off.

 

 

Edited by ssjucrono
Link to comment
1 hour ago, ssjucrono said:

trying out this container now.

 

I am having a conflict with port 1900. Plex is also using that port and I do not see an option in the Plex Template to change it. I changed on the unifi reborn but then it wasn't adopting my unifi devices. So I turned plex off and tried using port 1900 on Unifi Reborn and it is still saying it can't bind to 1900 as plex is using it though it is powered off.

 

 

What do you have set for “network type”? Should be bridge.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.