4 ms·

too bad the unifi controller requires the use of a ridiculously outdated version of mongodb, to the extent that installing it to self host unifi on a debian sys

too bad the unifi controller requires the use of a ridiculously outdated version of mongodb, to the extent that installing it to self host unifi on a debian system becomes more of a pain in the ass every year. ubnt patched this because it's a huge highly publicized hole. but the software stack that runs under the rest of unifi is a real mess. people have said to me: "oh, okay, so they're trying to force people to buy their unifi security appliance or cloudkey thing, right?" but the same very old stuff runs on those as well, if you poke around under the hood

ComputerGuru 5y ago
Tell me about it. Any time the Debian machine I have running as a Unifi appliance loses power (on an XFS filesystem on a disk with write caching disabled), the mongodb database is absolutely hosed (despite no xfs corruption at all) and I need to wipe the data directory and restore from backup because mongo 3 is just such garbage. (I mean, mongodb is still garbage but it's improved a tiny bit in some reliability metrics.)
- jd_mongodb 5y ago
  I would be curious to learn more about your setup. MongoDB should be able to recover in these situations...
  - ComputerGuru 5y ago
    Standard from packages. After the power failure the database is unusable and I get mongo startup errors ending with “newer versions of mongo may be able to fix errors like this automatically” and it dies.
    - jd_mongodb 5y ago
      Which package? Are you running a replica set or a single node? What specific version? Also which storage engine? 3.0 is a pretty old version. Most 3.x versions are end of life or unsupported.
      - ComputerGuru 5y ago
        Latest 3.6, single node, WiredTiger storage engine. The fact that it’s severely outdated is exactly the point we are making. I don’t know if it’s possible to override the version of a Debian package’s specified dependency - although I also don’t know if mongodb 5 is drop-in backwards compatible with a client written and released against v3.6.
        jd_mongodb 5y ago
        Can you share the command line and/or the config you use to start up. We don't support any single node use of MongoDB in production BTW. It can't recover as you have found out...
        ComputerGuru 5y ago
        To clarify again, I'm not the one starting it - Unifi ships its network appliance as a debian package that depends on mongod and starts it up itself (and it's absolutely a single node configuration). Maybe you guys should have a talk with them :) This is what monogd.log contains when started: 2020-09-24T21:18:54.231-0500 I CONTROL [initandlisten] MongoDB starting : pid=7531 port=27117 dbpath=/usr/lib/unifi/data/db 64-bit host=unifi 2020-09-24T21:18:54.231-0500 I CONTROL [initandlisten] db version v3.6.20 2020-09-24T21:18:54.231-0500 I CONTROL [initandlisten] git version: 39c200878284912f19553901a6fea4b31531a899 2020-09-24T21:18:54.231-0500 I CONTROL [initandlisten] OpenSSL version: OpenSSL 1.1.1d 10 Sep 2019 2020-09-24T21:18:54.231-0500 I CONTROL [initandlisten] allocator: tcmalloc 2020-09-24T21:18:54.231-0500 I CONTROL [initandlisten] modules: none 2020-09-24T21:18:54.231-0500 I CONTROL [initandlisten] build environment: 2020-09-24T21:18:54.231-0500 I CONTROL [initandlisten] distmod: debian92 2020-09-24T21:18:54.231-0500 I CONTROL [initandlisten] distarch: x86_64 2020-09-24T21:18:54.231-0500 I CONTROL [initandlisten] target_arch: x86_64 2020-09-24T21:18:54.231-0500 I CONTROL [initandlisten] options: { net: { bindIp: "127.0.0.1", port: 27117, unixDomainSocket: { pathPrefix: "/usr/lib/unifi/run" } }, processManagement: { pidFilePath: "/usr/lib/unifi/run/mongod.pid" }, storage: { dbPath: "/usr/lib/unifi/data/db" }, systemLog: { destination: "file", logAppend: true, logRotate: "reopen", path: "/usr/lib/unifi/logs/mongod.log" } } 2020-09-24T21:18:54.231-0500 I STORAGE [initandlisten] wiredtiger_open config: create,cache_size=256M,cache_overflow=(file_max=0M),session_max=20000,eviction=(threads_min=4,threads_max=4),config_base=false,statistics=(fast),compatibility=(release="3.0",require_max="3.0"),log=(enabled=true,archive=true,path=journal,compressor=snappy),file_manager=(close_idle_time=100000),statistics_log=(wait=0),verbose=(recovery_progress),
ireflect 5y ago
I know right? Each time I have to fight to get this working on linux (or pfSense/opnsense) I dream of making a small opensource Unifi controller replacement written in Go. Just something basic to manage my access points (no USG, etc.) Somebody started doing this. Shame they chose PHP though. https://github.com/imperian-systems/unifi-controller https://github.com/imperian-systems/unifi-controller
- deleted 5y ago
  [deleted]
- Nextgrid 5y ago
  OpenWISP (https://openwisp.org https://openwisp.org) tries to do this and it's Python and Django based. Last time I checked it out, it seems like they keep configuration in an intermediate format that is then translated to manufacturer-specific formats, so it should be possible to build a Unifi converter for that.
cglodt 5y ago
In case you're not aware of it, I'd like to point out https://hub.docker.com/r/linuxserver/unifi-controller https://hub.docker.com/r/linuxserver/unifi-controller, which makes running it self-hosted bearable.

ComputerGuru 5y ago

Tell me about it. Any time the Debian machine I have running as a Unifi appliance loses power (on an XFS filesystem on a disk with write caching disabled), the mongodb database is absolutely hosed (despite no xfs corruption at all) and I need to wipe the data directory and restore from backup because mongo 3 is just such garbage. (I mean, mongodb is still garbage but it's improved a tiny bit in some reliability metrics.)

jd_mongodb 5y ago
I would be curious to learn more about your setup. MongoDB should be able to recover in these situations...
- ComputerGuru 5y ago
  Standard from packages. After the power failure the database is unusable and I get mongo startup errors ending with “newer versions of mongo may be able to fix errors like this automatically” and it dies.
  - jd_mongodb 5y ago
    Which package? Are you running a replica set or a single node? What specific version? Also which storage engine? 3.0 is a pretty old version. Most 3.x versions are end of life or unsupported.
    - ComputerGuru 5y ago
      Latest 3.6, single node, WiredTiger storage engine. The fact that it’s severely outdated is exactly the point we are making. I don’t know if it’s possible to override the version of a Debian package’s specified dependency - although I also don’t know if mongodb 5 is drop-in backwards compatible with a client written and released against v3.6.
      - jd_mongodb 5y ago
        Can you share the command line and/or the config you use to start up. We don't support any single node use of MongoDB in production BTW. It can't recover as you have found out...
        ComputerGuru 5y ago
        To clarify again, I'm not the one starting it - Unifi ships its network appliance as a debian package that depends on mongod and starts it up itself (and it's absolutely a single node configuration). Maybe you guys should have a talk with them :) This is what monogd.log contains when started: 2020-09-24T21:18:54.231-0500 I CONTROL [initandlisten] MongoDB starting : pid=7531 port=27117 dbpath=/usr/lib/unifi/data/db 64-bit host=unifi 2020-09-24T21:18:54.231-0500 I CONTROL [initandlisten] db version v3.6.20 2020-09-24T21:18:54.231-0500 I CONTROL [initandlisten] git version: 39c200878284912f19553901a6fea4b31531a899 2020-09-24T21:18:54.231-0500 I CONTROL [initandlisten] OpenSSL version: OpenSSL 1.1.1d 10 Sep 2019 2020-09-24T21:18:54.231-0500 I CONTROL [initandlisten] allocator: tcmalloc 2020-09-24T21:18:54.231-0500 I CONTROL [initandlisten] modules: none 2020-09-24T21:18:54.231-0500 I CONTROL [initandlisten] build environment: 2020-09-24T21:18:54.231-0500 I CONTROL [initandlisten] distmod: debian92 2020-09-24T21:18:54.231-0500 I CONTROL [initandlisten] distarch: x86_64 2020-09-24T21:18:54.231-0500 I CONTROL [initandlisten] target_arch: x86_64 2020-09-24T21:18:54.231-0500 I CONTROL [initandlisten] options: { net: { bindIp: "127.0.0.1", port: 27117, unixDomainSocket: { pathPrefix: "/usr/lib/unifi/run" } }, processManagement: { pidFilePath: "/usr/lib/unifi/run/mongod.pid" }, storage: { dbPath: "/usr/lib/unifi/data/db" }, systemLog: { destination: "file", logAppend: true, logRotate: "reopen", path: "/usr/lib/unifi/logs/mongod.log" } } 2020-09-24T21:18:54.231-0500 I STORAGE [initandlisten] wiredtiger_open config: create,cache_size=256M,cache_overflow=(file_max=0M),session_max=20000,eviction=(threads_min=4,threads_max=4),config_base=false,statistics=(fast),compatibility=(release="3.0",require_max="3.0"),log=(enabled=true,archive=true,path=journal,compressor=snappy),file_manager=(close_idle_time=100000),statistics_log=(wait=0),verbose=(recovery_progress),

ireflect 5y ago

I know right? Each time I have to fight to get this working on linux (or pfSense/opnsense) I dream of making a small opensource Unifi controller replacement written in Go. Just something basic to manage my access points (no USG, etc.) Somebody started doing this. Shame they chose PHP though. https://github.com/imperian-systems/unifi-controller https://github.com/imperian-systems/unifi-controller

deleted 5y ago
[deleted]
Nextgrid 5y ago
OpenWISP (https://openwisp.org https://openwisp.org) tries to do this and it's Python and Django based. Last time I checked it out, it seems like they keep configuration in an intermediate format that is then translated to manufacturer-specific formats, so it should be possible to build a Unifi converter for that.

cglodt 5y ago

In case you're not aware of it, I'd like to point out https://hub.docker.com/r/linuxserver/unifi-controller https://hub.docker.com/r/linuxserver/unifi-controller, which makes running it self-hosted bearable.