sysctl kern.msgbuffer capset not implemented with linux-compat jsvc

I have been working on getting a debian install running in a Jail, for which to migrate a physical installation of debian 7 with some NVR software by ubiquiti. I feel like I have a functional Jail but may be running into a limitation of the linux compatibility layer in Freebsd 10.3.

What I'm getting that is rather confusing is the following in the sysctl kern.msgbuffer:

linux: pid 59658 (jsvc): capset effective=0x4c4, permitted=0x4c4, inheritable=0x4c4 is not implemented.

Just looking for some pointers on what might be generating this error... is this the linux compatibility kernel module and how do I determine what 'is not implemented' that would be implemented in a full blown linux kernel to possibly go about submitting a bug to resolve the issue... I have done quite a bit of googling to no avail.

If you would like a more in depth view of the steps I've gone through... see the following:

https://protocolsyntax.wordpress.com/2017/06/15/install-ubiquiti-video-nvr-debian-in-freebsd-jail/

I have a theory it has something to do with the requirement to comment out echo 0x10 > /proc/self/coredump_filter as linprocfs is not writable and coredump_filter doesn't appear to exist in /proc/self.

Any assistance or guidance would be appreciated...
 
In reading through my own setup, I noticed a few lines that allowed debugging and verbose output to be returned when starting the unifi-video service... I don't know if the following provides any additional perspective, but I figured I would include it as well...

.... removed a bunch of other startup output...

Code:
Java Home located in /usr/lib/jvm/java-7-openjdk-amd64/jre
+-- DUMPING JAVA HOME STRUCTURE ------------------------
| Java Home:       "/usr/lib/jvm/java-7-openjdk-amd64/jre"
| Java VM Config.: "/usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/jvm.cfg"
| Found JVMs:      1
| JVM Name:        "server"
|                  "/usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server/libjvm.so"
+-------------------------------------------------------
Running w/ LD_LIBRARY_PATH=/usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server:/usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64
redirecting stdout to /dev/null and stderr to /dev/null
Switching umask back to 022 from 077
Attemtping to load library libcap.so
Attemtping to load library libcap.so.2
loaded cap_free from libcap.
loaded cap_init from libcap.
loaded cap_clear from libcap.
loaded cap_get_flag from libcap.
loaded cap_set_flag from libcap.
loaded cap_set_proc from libcap.
failed setting default capabilities.
set_caps(CAPS) failed for user 'unifi-video'
Service exit with a return value of 4
 failed!

noticed the set_caps(CAPS) failed for user 'unifi-video'... which seems to coincide with the error seen on the krn.msgbuffer....

thoughts??
 
After digging around, I found libcap which is referenced in the jsvc start up logs is actually a user space API for elevating a processes individual needs without superuser (root) access like listening on a port less than 1024 on a socket. It seems like this is linux specific as I cant seem to find anything in the freebsd man paged for it.

So I've been reading quite a bit about JSVC and it's inability to modify setcap on Linux boxes. I'm assuming this might be a limitation in the Linux abstraction layer for freebsd as well. Although if this is done differently on bsd hosts it may just not be capable of performing such actions.. I noted on the following link there is information regarding how to enable features within the Linux kernel. So I think I'm gonna try and look at re compiling a custom linux-compat Patch.

http://commons.apache.org/proper/commons-daemon/faq.html

in the interim I have just allowed the service to run as root within the jail. :(
 
Any progress on this?

I'm in your situation where I'd like to run that very same software on FreeBSD 11.

Was set_caps the only problem? Did the NVR run correctly if given root access?
 
ATM I'm running it under a bhyve visualization (ubuntu 16.04LTS), .. why not use bhyve instead?
 
Back
Top