[SOLVED]Temporarily downgrade Mongodb to masked 4.0.X

[dewhite]

Hello all,

It seems I've made a little mess. I run Unifi Controller on two Gentoo systems (home and small business). I recently upgraded both setups to version 6.1.21 during World updates, which pulled in an update of Mongodb from 3.6.X to 4.2.8. After the updates, I later noticed that Unifi Controller isn't starting, and I troubleshot that to an error in /var/log/unifi/mongodb.log that reads, in part:

Code: Select all

2020-11-23T15:32:52.803-0600 F  CONTROL  [initandlisten] ** IMPORTANT: UPGRADE PROBLEM: Found an invalid featureCompatibilityVersion document (ERROR: BadValue: Invalid value for version, found 3.6, expected '4.2' or '4.0'. Contents of featureCompatibilityVersion document in admin.system.version: { _id: "featureCompatibilityVersion", version: "3.6" }. See https://docs.mongodb.com/manual/release-notes/4.2-compatibility/#feature-compatibility.). If the current featureCompatibilityVersion is below 4.0, see the documentation on upgrading at https://docs.mongodb.com/manual/release-notes/4.2/#upgrade-procedures.

Easy, right? Just read the docs and upgrade the db file. Small wrinkle - Mongodb seems to require that 3.6 be upgraded to 4.0, then 4.0 to 4.2. OK, no problem...

Wait. All 3.6.X and 4.0.X packages have been masked, because:

Code: Select all

Mask dev-db/mongodb versions which do not support python3 so we can move forward in cleaning python2 from tree. Bug #708954. We keep the ebuilds available since some of those versions are still supported by upstream. See: https://jira.mongodb.org/browse/SERVER-52687
Affected packages
<dev-db/mongodb-4.2.8
Author/Date
Alexys Jacob <ultrabug@gentoo.org> (2020-11-09 00:00:00 +0000 UTC)

Before I started monkeying around under the hood to try to bypass the masks and "downgrade" to a 4.0.X package temporarily, I thought I'd ask for any practical advice the community is willing/able to offer.

Bonus Points: I've already completed the update to Profile 17.1 on one of these systems (of course, on the system with the more elaborate and critical Unifi setup). The other is still on Profile 17.0. Not sure if that matters, but it seemed at least tangentially related...

As always - any thoughts, suggestions, questions, references, rants, etc. will be greatly appreciated.

Thanks,

Dan

[Stein0815]

Hi Dan,

I've had the same problem and solved it downloading the 4.0.21 "Linux (legacy)" MongoDB Community Server tgz from https://www.mongodb.com/try/download/community.
Unpack it to a temporary place and run the mongoDB server as unifi user:

Code: Select all

.../mongodb-linux-x86_64-4.0.21/bin $ ./mongod --noauth --dbpath /var/lib/unifi/data/db

Then open a mongoDB shell from the temporary install to perform the upgrade to 4.0 as in https://docs.mongodb.com/manual/release ... tandalone/
Afterwards you can stop the 4.0 server and startup the 4.2 server, run the 4.2 shell and upgrade as in https://docs.mongodb.com/manual/release ... tandalone/

Cheers,
Ingo

[Hu]

If you prefer to handle this through Portage, bypassing the masks should be relatively simple. Whether the resulting build will work is not guaranteed, but we can try to help you fix it if needed.

[dewhite]

Hi Dan,

I've had the same problem and solved it downloading the 4.0.21 "Linux (legacy)" MongoDB Community Server tgz from https://www.mongodb.com/try/download/community.
Unpack it to a temporary place and run the mongoDB server as unifi user:

Code: Select all

.../mongodb-linux-x86_64-4.0.21/bin $ ./mongod --noauth --dbpath /var/lib/unifi/data/db

Then open a mongoDB shell from the temporary install to perform the upgrade to 4.0 as in https://docs.mongodb.com/manual/release ... tandalone/
Afterwards you can stop the 4.0 server and startup the 4.2 server, run the 4.2 shell and upgrade as in https://docs.mongodb.com/manual/release ... tandalone/

Cheers,
Ingo

Ingo,

I see that you joined the forum and made your first post to answer my question. You are a scholar and a gentleman, Sir!

Your post put me on the right path, and after a little tinkering, my problems are resolved.

For any future souls that happen by, I thought I'd give a little more detailed description of what I needed to do:

Code: Select all

cd ~

wget https://fastdl.mongodb.org/linux/mongodb-linux-x86_64-4.0.21.tgz

tar -xvf mongodb-linux-x86_64-4.0.21.tgz

cd mongodb-linux-x86_64-4.0.21/bin

sudo -u unifi ./mongod --noauth --dbpath /var/lib/unifi/data/db

While the server is running, open a separate shell:

Code: Select all

/etc/init.d/unifi stop

/etc/init.d/mongodb stop

cd ~/mongodb-linux-x86_64-4.0.21/bin

./mongo

db.adminCommand( { getParameter: 1, featureCompatibilityVersion: 1 } )

db.adminCommand( { setFeatureCompatibilityVersion: "4.0" } )

db.adminCommand( { getParameter: 1, featureCompatibilityVersion: 1 } )

db.adminCommand({ "shutdown" : 1 })

exit

Now the db needs to be updated from 4.0 to 4.2, using the installed binaries, instead of the ones temporarily downloaded.

In the first shell, notice the lack of "./" before mongod:

Code: Select all

sudo -u unifi mongod --noauth --dbpath /var/lib/unifi/data/db

In the second shell, similar lack of "./" this time:

Code: Select all

mongo

db.adminCommand( { getParameter: 1, featureCompatibilityVersion: 1 } )

db.adminCommand( { setFeatureCompatibilityVersion: "4.2" } )

db.adminCommand( { getParameter: 1, featureCompatibilityVersion: 1 } )

db.adminCommand({ "shutdown" : 1 })

exit

Now, to clean-up, in whichever shell you like:

Code: Select all

/etc/init.d/mongodb start

/etc/init.d/unifi start

cd ~

rm -R mongodb-linux-x86_64-4.0.21*

exit

[dewhite]

If you prefer to handle this through Portage, bypassing the masks should be relatively simple. Whether the resulting build will work is not guaranteed, but we can try to help you fix it if needed.

Hu,

Thank you, also, for the offer to help. My issue appears to be resolved on one system. If I encounter different issues on the other, I will check back in for more assistance.

Thanks,

Dan

[Stein0815]

Hi Dan,

thanks for your kind words. :-) Indeed I created an account just to answer your question.

I got so frustrated with this problem I could not resist to post a possible solution ;-)
Having cleaned up the huge python 2 mess on my system recently, I was not amused to find out I'd need to roll back to MongoDB 4.0.x needing Python 2.7 when using the portage.
Hu, I'm not aware of how to bypass Python 2.x as MongoDB has no resp. USE flag?

Luckily the binary did the trick.

Regards
Ingo

[Hu]

Hu, I'm not aware of how to bypass Python 2.x as MongoDB has no resp. USE flag?

There may not be a way to eliminate the Python 2 dependency, but that does not mean we cannot get the old Mongo to build. It just makes it a bigger challenge.

[sidamos]

I have a similar problem. I am currently on masked MongoDB 3.6.17 because of Unifi.

I think, I could migrate to 4.2 by backing up the db under 3.6.17 and restoring it under 4.2 or going your route.

My main concern is: Is Unifi working OK with MongoDB 4.2?

[Akaihiryuu]

My main concern with this is that ubiquiti themselves have stated that unifi currently only supports 3.6. I don't really understand what people are doing to get it to work under 4.0 or 4.2...because according to them it doesn't work. So is this actually working?

[Akaihiryuu]

I did this and it works, omg. Despite Ubiquiti insisting it won't work with anything higher than 3.6.

Question...will this work for Mongo 4.4 too? Just follow the last part of the directions, swapping 4.4 for 4.2 and 4.2 for 4.0?

EDIT: Can't get the instructions to work for 4.4, I guess syntaxes have changed. I know next to nothing about mongodb. It "sort of" works with 4.4 but the log file looks really bizarre, showing things like $t instead of the date/time, and raw data instead of being formatted correctly.

It shouldn't matter though, 4.2 should be current and useable on Gentoo for quite awhile which solves my original problem.

[sidamos]

Another, maybe easier migration to newer MongoDB versions (given that Unifi works with it) is to backup the Unifi data from the web interface and start with a fresh MongoDB and restore the Unifi data.

[Ionen]

Despite Ubiquiti insisting it won't work with anything higher than 3.6

May want to see this comment from the ebuild maintainer saying that even the latest unstable mongodb is tested (you can use 4.4.x, not that I'm familiar with the migration process myself).

So for anyone else that hasn't, try to migrate away from 3.6.x sooner than later.

[sidamos]

OK, so I made a backup from within Unifi and reinstalled Unifi and MongoDB (4.4.1, stable for Gentoo) from scratch (deleted data files of Unifi and MongoDB) and then restored the backup. It works.
Unifi itself sets the compatibility level for MongoDB to 3.6.
So, the only problem in migrating from 3.6 to 4.4 is if one wants to migrate via the MongoDB database (without Unifi backup/restore), which means migrating over version 4.0 to 4.4.