Package Details: unifi-video 3.10.13-2

Git Clone URL: https://aur.archlinux.org/unifi-video.git (read-only, click to copy)
Package Base: unifi-video
Description: Centralized management system for Ubiquiti UniFi surveillance cameras.
Upstream URL: https://www.ubnt.com/
Licenses: custom
Conflicts: unifi-video-beta
Submitter: fryfrog
Maintainer: torben
Last Packager: torben
Votes: 10
Popularity: 0.000000
First Submitted: 2016-04-18 17:44 (UTC)
Last Updated: 2021-12-28 10:51 (UTC)

Dependencies (6)

Required by (0)

Sources (5)

Pinned Comments

torben commented on 2023-01-04 09:20 (UTC) (edited on 2023-01-04 09:20 (UTC) by torben)

Please be aware, that Ubiquity has discontinued support for Unifi-Video..

I will keep an eye on this package while I am still using it, but please understand that without support von Ubiquity there isn't much I can do in case of problems with the app itself.

Also, I strongly recommend no longer publishing Unifi-Video unprotected on the Web. Work under the assumption, that this application can be breached.

torben commented on 2021-12-18 16:55 (UTC) (edited on 2021-12-27 14:04 (UTC) by torben)

Version 3.10.13-2 mitigates the log4j JNDI vulnerability out of the box

Be aware, that unifi-video is affected by the recent log4j JNDI Lookup vulnerabilities. As Ubiquity is no longer maintaining this piece of software, we can't expect an update.

The best mitigation (removing the JNDI Lookup Ability in log4j) for unifi-video can be found here:

https://community.ui.com/questions/Mitigating-the-Java-Log4J-exploit-in-UniFi-Video-on-Debian-Ubuntu/c59621d2-3cbf-48aa-9780-76477e0b1d39#answer/06ed75d6-113c-4230-9d44-7394e4ba2542

Basically, it removes the corresponding lookup-class from log4j-core.jar via:

zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

I strongly recommend everybody to update either to 3.10.13-2 or to fix the log4j JAR file manually.

Latest Comments

« First ‹ Previous 1 2 3 4 5 Next › Last »

mohaine commented on 2017-12-30 16:52 (UTC) (edited on 2017-12-30 16:53 (UTC) by mohaine)

after doing a system update, unifi refused to get past the "Processing update" page. It seems that mongo will not start due to an unknown cmd line argument.

I replaced the mongod sym link (/usr/lib/unifi-video/bin/mongod) with the following bash script to remove the argument and all is well.

#!/bin/bash

args=$@
delete=('--nohttpinterface')
clean=${args[@]/$delete}
exec '/usr/bin/mongod' $clean

fryfrog commented on 2017-09-20 22:05 (UTC)

Heads up, 3.8.0 adds a new port. If you're doing anything tricky, you'll need 7442 as well as the old 7443. A symptom I saw from this was that the cameras would connect after the update, do their firmware update and then never re-appear.

klden commented on 2017-07-23 04:30 (UTC)

@fryfrog @paco3346 chowning the config folder does fix the problem for the live view! Thanks for finding this out!

fryfrog commented on 2017-07-18 15:43 (UTC)

@paco3346: Sorry for not updating, I also help w/ the docker version and did that way back when 3.7.1 came out. Should have done this one too. :/ I checked inside my docker and that dir is all unifi-video:unifi-video. I'll add a chown to the packages install/update and it'll "fix" it every install/upgrade at least. Or maybe it should be a pre-run in the systemd unit file? :/

paco3346 commented on 2017-07-18 13:43 (UTC)

Also, 3.7.1 has been out for a while https://community.ubnt.com/t5/UniFi-Video-Blog/UniFi-Video-3-7-1-Release/ba-p/1947714 I've had no issues simply swapping out the version number and updating the sha256 hash.

paco3346 commented on 2017-07-18 13:41 (UTC)

No, just the first time. Once the config files are owned by the unifi-video user evostream never reverts them back to root. What user owns the config files in /usr/lib/unifi-video/conf on Ubuntu?

fryfrog commented on 2017-07-18 03:30 (UTC)

@paco3346: Interesting, I wonder why this works on Ubuntu? I *can* confirm you have to run their script as root, it complains otherwise. I can add the chown as a patch to the script they run perhaps. It'd have this problem every time it started up, right?

paco3346 commented on 2017-07-18 03:08 (UTC) (edited on 2017-07-18 03:08 (UTC) by paco3346)

@fryfrog I just installed this on another machine and had the same issue @klden described. The problem is that the evostreams binary is running as root so the first time it launches it creates a bunch of config files in /usr/lib/unifi-video/conf owned by root Since the jar file runs as unifi-video it can't ever update these files which causes the backend streaming service (Evostream) to never be able to pick up on new camera streams (which is what breaks recording and live streaming). Workaround: after you start unifi-video the first time run a chown -R unifi-video:unifi-video in /usr/lib/unifi-video/conf I've not yet tested to see if you can run the systemd unit itself as unifi-video

klden commented on 2017-07-16 14:20 (UTC) (edited on 2017-07-16 15:07 (UTC) by klden)

@fryfrog: yep it is from inside haha. I saw the logs from 1 of my camera and it couldn't connect to the unifi-server via port 6666. I'll spin up a ubuntu docker then! :D Thanks for your response! Update: Your container image is working! Thanks!!

fryfrog commented on 2017-07-15 22:37 (UTC)

@klden: Are you having this issue *inside* your own network when going to the web ui directly? Or outside via port forward or their web portal? If outside, it is probably port forwards. If inside... that was one of the handful of issues I couldn't get sorted which made me spin up an Ubuntu docker instead. :/