PeteAsking

Can you explain why you use a private ssl key and what your end goal is for doing this?

Home user tag (Stable) now available: unifi:9.0.114-unraid https://community.ui.com/releases/UniFi-Network-Application-9-0-114/35b6e9ac-f63d-46c9-bbbe-74a4a61ac95f As always a backup of your container prior to upgrade is required. P

Regards tag: that is fine. Just carry in checking in every 6 months for an update to old stable and you will be fine. Regards apps: unsure how unraid works but I can tell you it is not relevant at all. Once the docker is installed, I could literally delete the xml and remove the app front that community apps page and it would not inpact your docker one bit. The docker checks with dockerhub for any changes (eg; for dockers that use a latest tag) directly and never uses that apps page ever again. As long as you can change the tag on your docker occasionally to a new tag in the 11notes repository on dockerhub it will always work fine. So dont worry about it as its not relevant. Feb 4 was when I made some changes to the xml file so probably something happened then but I dont know and squid who might know does not respond to my messages or reply on threads when you tag him so no clue. Only he knows the inner workings.

Not sure how this happened for you as the app never existed in 2015. However it is not relevant. If it is installed, then it is working and it does not matter if your apps directory is showing some quirk. To update it just change the tag on your docker container to one of the currently supported tags that is newer than what your are running and the network application will be updated. Everything you need once it is installed is entirely contained in the docker image in your unraid box so whatever happened to the apps cache or whatever is no longer of any consequence for you. to explain: the apps directory of unraid is just reading an xml file on what to do to setup and install a docker image for you. It does not reread this xml file once the docker is running. So in your docker tab and under the docker settings the setup is done once installed and whatever the apps tab says is not relevant to the function of the docker running then on. Simply modify the docker how you want at this point forward. What is your current tag you are using?

Yeah not sure what is happening with Linuxserver.io or their images. I switched to binhex for everything. As he didnt have a unifi docker I had to make one with 11notes. 11notes has docker images for unifi based on ubuntu which you can use on non-unraid deployments. We worked together and created an unraid specific docker. Reason for this implementation was I had the following requirements: 1) Secure (reason for picking an ubuntu based image) 2) Reliable (testing is perfomed on new images prior to release announce - we do not auto build and just push them out without manual testing) 3) Ability to upgrade safely with no downtime (version changes are tested between previous tags eg: old stable ---> new version etc) 4) Was an all in one docker (I believe splitting the docker can impact 1-3). When using linuxserver.io the issues of reliability were most prominent especially between version changes. Since creating the images I believe the objective has been by in large achieved over the past 1+year. At this time there are 11notes images for either unraid or your own linux box deployments so you are not tied to any specific deployment. As I use unifi myself everything is also loaded up for you guys to use if you want to. If you find something better, feel free to use that. We have our way of achieving 1-4 and believe its the best but thats just our opinion. Some downsides to our approach: 1) Slower release time. Releases are ready when they are ready. If it takes 20 days to be happy then you just have to wait. 2) No automatic updates. You have to check in every few months and manually update as and when you can schedule in time for your deployment. 3)? probably something else I forgot. P

Unfortunately some users need to be protected from themselves.

It can be implemented. This automatic updates will never be implemented however until unraid has a system in place that guarantees a copy and safe backup of a container that is to be upgraded or tag changed by default so that if a bad update occurs, we are guaranteed to know everyone has a safe backup. Unless this is implemented you will never get an automatic tag. my official reason for not implementing a ‘latest’ tag is this: I do not feel like it. This opinion has 0% chance of changing until unraid has an auto backup feature that is on by default. If this is an issue for you please make your issues known to unraid feature requests, requesting auto backups by default of appdata containers. thanks.

11notes/unifi:9.0.108-unraid be confused no more, friend.

04/02/2025 Today marks this docker as stable. Current tags are: Stable (home user): 11notes/unifi:9.0.108-unraid Old Stable (business user): 11notes/unifi:8.6.9-unraid Old Old Stable (Zero downtime user): 11notes/unifi:8.5.6-unraid The xml for this docker has been changed today. Installing a new docker will install version Old Old stable going forward. A result of this change means there is now no supported upgrade path from the linuxserver.io image to this image. You can try it, but we no longer support it and you are on your own. Sorry if you cant migrate to this image and are still using linuxserver.io. You had over 1 year to migrate so I feel enough time was provided. Please ensure you pick a tag, make sure you are using one of the above, and check in every so often to manually upgrade to the next tag if you need to. You can expect a new Stable tag once a month or so or maybe every 2 months, and every 6 months for Old Stable. Check yearly if you use Old Old Stable. Remember to make a copy of your appdata unifi docker before upgrades (while it is stopped) somewhere for rolling back if need be and you wont have to worry about issues. Thanks P

The script I will test for the next 3 months is this. Seems to work fine and you can just copy the backed up disk back to unraid and replace the one that is already there. After a few months I will know if there are any issues. I imagine this is safer than using reflinks. virsh list --all virsh domblklist --details Pallando virsh snapshot-create-as --domain Pallando --name PallandoBack --atomic --disk-only --no-metadata --diskspec hdc,file=/mnt/btrfsprotect/domains/Pallando/PallandoBackhdc --diskspec hdd,file=/mnt/btrfsprotect/domains/Pallando/PallandoBackhdd virsh domblklist --details Pallando cp /mnt/btrfsprotect/domains/Pallando/Pallando.qcow2 /mnt/btrfsprotect/VMBackupFol/ cp /mnt/btrfsprotect/domains/Alatar/alatar1.qcow2 /mnt/btrfsprotect/VMBackupFol/ ls -asxhl /mnt/btrfsprotect/Pallando/ qemu-img info --force-share --backing-chain /mnt/btrfsprotect/domains/Pallando/PallandoBackhdc qemu-img info --force-share --backing-chain /mnt/btrfsprotect/domains/Pallando/PallandoBackhdd virsh blockcommit Pallando hdc --wait --active --pivot --delete virsh blockcommit Pallando hdd --wait --active --pivot --delete virsh domblklist --details Pallando ls -asxhl /mnt/btrfsprotect/Pallando/ virsh domblklist --details GrimaWormtongue virsh snapshot-create-as --domain GrimaWormtongue --name GrimaBack --atomic --disk-only --no-metadata --diskspec hdc,file=/mnt/btrfsprotect/domains/GrimaWormtongue/GrimaBackhdc virsh domblklist --details GrimaWormtongue cp /mnt/btrfsprotect/domains/GrimaWormtongue/grima1.img /mnt/btrfsprotect/VMBackupFol/ ls -asxhl /mnt/btrfsprotect/domains/GrimaWormtongue/ qemu-img info --force-share --backing-chain /mnt/btrfsprotect/domains/GrimaWormtongue/GrimaBackhdc virsh blockcommit GrimaWormtongue hdc --wait --active --pivot --delete virsh domblklist --details GrimaWormtongue ls -asxhl /mnt/btrfsprotect/domains/GrimaWormtongue/ virsh domblklist --details Rivendell virsh snapshot-create-as --domain Rivendell --name RivendellBack --atomic --disk-only --no-metadata --diskspec hdc,file=/mnt/btrfsprotect/domains/Rivendell/RivendellBackhdc virsh domblklist --details Rivendell cp /mnt/btrfsprotect/domains/Rivendell/rivendell1.img /mnt/btrfsprotect/VMBackupFol/ ls -asxhl /mnt/btrfsprotect/domains/Rivendell qemu-img info --force-share --backing-chain /mnt/btrfsprotect/domains/Rivendell/RivendellBackhdc virsh blockcommit Rivendell hdc --wait --active --pivot --delete virsh domblklist --details Rivendell ls -asxhl /mnt/btrfsprotect/domains/Rivendell/ virsh list --all ls -asxhl /mnt/btrfsprotect/VMBackupFol/ scp -r /mnt/btrfsprotect/VMBackupFol/ [email protected]:/mnt/314f2211-7128-498b-9d85-354132601877/Unraid/

No you do not need a copy of nvram. Also it is trivial to repair a boot record or a windows machine using an installation iso of windows. It is literally a single cmd command to rebuild. The reason is that if the unraid machine is functioning and you restore the image it will already have a valid copy. If the entire unraid machine dies you will need to boot repair the disk image if you have not kept a copy but it is not really important to do so. I believe ca appdata backup backs up libvirt if you use that. Either way a disk file like what you copy in your script can be repaired and booted even if that is the only thing you have. Im not clear what you are showing me in your code. I agree it shuts down a vm and copies the disk but this is trivial if you are able to turn off the vm. The goal I have is to create a valid 100% safe backup of a running vm. Also unclear is this part “I have started looking at VM Backups that may be included in future releases.” Future releases of what? Do you create and maintain a backup program for unraid? One thing in your scripts is you do not use pipefail… how do you monitor if a script exits abnormally in this case and then subsequently notify and do something? With regards to the commands I am looking at using in the OP they generate fails if there is a problem that can then be detected with proper scripting. If nobody uses this method to backup vm’s I will probably have to just test it myself and check it works properly.

The guest additions are not yet working for windows server 2025, however at some point they will... so this is not an immediate concern, and can be made to work eventually. I dont believe the RAM can be captured as virsh does not support memory capture of VM's that are secure boot with q35. Main reason for this mothod is it can ensure validity with the --atomic flag. A cp cannot and although extremely rare there is a technical possibility of modification during the reflinking process that can be avoided here as virsh can create a perfect snapshot and generate an error code if it cannot. This means I can be guaranteed a copy of the disk that can be booted later with certainty, at least I think so.

I have a RAID1 BTRFS pool with COW enabled on the domains shares (all shares in fact). I do not wish to use reflinks and create a crash consistent backup. Instead I wish to create a snapshot similar to how VMWARE might backup a VM and then copy the snapshot and write back the changes after the process completes to the original disk. I am using a VM that has EFI and Secure boot - ie Q35 and OVMF as a template. The memory and disk is encrypted while running. The strategy I would like to deploy is as follows: root@Tower:~# virsh list --all Id Name State --------------------------------- 1 Rivendell running 2 GrimaWormtongue running 6 Pallando running root@Tower:~# virsh domblklist --details Pallando Type Device Target Source ----------------------------------------------------------------------------- file disk hdc /mnt/btrfsprotect/domains/Pallando/Pallando.qcow2 file disk hdd /mnt/btrfsprotect/domains/Alatar/alatar1.qcow2 root@Tower:~# cd /mnt/btrfsprotect/domains/Pallando/ root@Tower:/mnt/btrfsprotect/domains/Pallando# ls Pallando.qcow2* CREATE SNAPSHOT root@Tower:/mnt/btrfsprotect/domains/Pallando# virsh snapshot-create-as --domain Pallando --name PallandoBack --atomic --disk-only --no-metadata --diskspec hdc,file=/mnt/btrfsprotect/domains/Pallando/PallandoBackhdc --diskspec hdd,file=/mnt/btrfsprotect/domains/Pallando/PallandoBackhdd Domain snapshot PallandoBack created root@Tower:/mnt/btrfsprotect/domains/Pallando# ls -asxhl total 87G 0 drwxrwxrwx 1 share users 88 Jan 24 10:20 ./ 0 drwxrwxrwx 1 nobody users 76 Jan 20 20:40 ../ 87G -rwxrw-rw- 1 root users 87G Jan 24 10:20 Pallando.qcow2* 6.0M -rw------- 1 root users 6.0M Jan 24 10:20 PallandoBackhdc 196K -rw------- 1 root users 195K Jan 24 10:20 PallandoBackhdd *NOTE CHANGES HAVE OCCURED TO FILE ABOVE (6MB of changes) At this point copy the file Pallando.qcow2 to a remote backup location, which can complete after some time. Cleanup: root@Tower:/mnt/btrfsprotect/domains/Pallando# virsh blockcommit Pallando hdc --wait --active --pivot --delete Successfully pivoted root@Tower:/mnt/btrfsprotect/domains/Pallando# virsh blockcommit Pallando hdd --wait --active --pivot --delete Successfully pivoted root@Tower:/mnt/btrfsprotect/domains/Pallando# ls -asxhl total 87G 0 drwxrwxrwx 1 share users 28 Jan 24 10:21 ./ 0 drwxrwxrwx 1 nobody users 76 Jan 20 20:40 ../ 87G -rwxrw-rw- 1 root users 87G Jan 24 10:21 Pallando.qcow2* root@Tower:/mnt/btrfsprotect/domains/Pallando# virsh list --all Id Name State --------------------------------- 1 Rivendell running 2 GrimaWormtongue running 6 Pallando running root@Tower:/mnt/btrfsprotect/domains/Pallando# Is this method likely to create a successful backup of Pallando.qcow2 that can be copied back in case of a failure?

Must be. Check if you can add logging on all your block rules and then watch the live log as you try it.

Its working for me (first time trying it) so must be something your side you have changed or blocked. I guess this is on by default:

Ate you just trying to use cloud access? Mine seems to work perfectly and dont even remember setting anything up: I am using network type bridge. This works perfectly. If your firewall blocks random things make sure there are relevant exceptions for testing.

I dont actually understand clearly what you have done or what you are trying to do. Did you setup this container from scratch and never get it working or did you try restore a backup or what?

Yes if mikrotik can run a docker you can just use 11notes directly and not even use unraid.

I have only ever needed to use the docker. I have only APs and switches. For firewall I use opnsense. People use the unifi gateway to get additional features like layer 7 blocking and so on but you can do the same thing with other firewalls. If you just use their APs and switches then a docker is fine and I dont see a benefit of using a dedicated device to manage just that.

Please note: Unifi users still using linuxserver.io who have not yet moved to this image. On 1st February 2025 we will no longer support migrations from the old unifi docker maintained by linuxserver.io. If this is a problem please move to this unraidunifireborn (this image) docker before 1st February. on 1 Feb the new installations for this docker will be tagged unifi:8.5.6-unraid. The old tag unifi:7.5.187-unraid will be deprecated and there will be no direct upgrade from linuxserver.io’s image to this image. new installs will all be tagged 8.5.6 after this date and it will be expected you run this image or later. Many thanks, P

This will never be added. Auto upgrades are unsupported and never will be for this docker. This is 100% intentional.

Do you have the following requirements? Requirements UniFi Cloud Gateway (or independent UniFi Gateway) UniFi Network Application version 9.0 or newer UniFi (Cloud) Gateway version 4.1 or newer

09 Jan 2025 New tags for all deployments as of today: Choose your own adventure tag: https://hub.docker.com/r/11notes/unifi/tags Current recommended Home User tag: 11notes/unifi:9.0.108-unraid Current Company/Corporate recommended tag: 11notes/unifi:8.6.9-unraid Current Critical Infrastructure (no downtime) tag: 11notes/unifi:8.5.6-unraid All above listed tags have no known CVEs listed against them. Please upgrade ASAP. Kind regards P Side note: This docker is expected to have 8GB RAM allocated to it. While it may typically use less - approximately 1-2GB - it is nonetheless expected to be able to expect and use 8GB if the need arises albeit temporarily. Do not configure the docker to use less than this as is can cause database issues during certain tasks. Ignoring of this warning is a decision made by you, and any consequences to be blamed, on you. It is expected that reasonable CPU and RAM is allocated to this docker for correct functioning of the Unifi and MongoDB software. Weird and extremely constrictive setups in the name of "improving performance" are beyond the scope of support.

There is a freeze on changes to this project for 2 weeks over Christmas. No changes will be made and no new versions tested or released. Thanks.