[SERVER-50100] Ubuntu 20.04 DEB service file expects mongod.conf, does not install it Created: 04/Aug/20 Updated: 27/Oct/23 Resolved: 24/Aug/20 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Packaging |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Critical - P2 |
| Reporter: | Andrew Feierabend (Inactive) | Assignee: | Ryan Egesdahl (Inactive) |
| Resolution: | Works as Designed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
|
| Operating System: | ALL |
| Steps To Reproduce: | Install MDB via apt per Install Doc, try to start it with sudo systemctl start mongod Repro steps attached in ubuntu20-mising-conf-file-repro |
| Sprint: | Dev Platform 2020-08-24, Dev Platform 2020-09-07 |
| Participants: |
| Description |
|
The Ubuntu 20.04 MDB Enterprise 4.4 DEB file does not install a conf file at /etc/mongod.conf, but expects that file to be there in the /lib/systemd/system/mongod.service file it does install. This means that a user installing MDB per our live instructions, in the same way they installed MDB 4.2, will not be able to start the MDB 4.4 binary they just installed without some sysadmin knowledge / SO research / troubleshooting. Also noticed:
Repro steps for MDB 4.4 Ubuntu 20.04 attached in ubuntu20-mising-conf-file-repro. I suspect this applies to Community as well, and possibly to other DEB files, but do not have the time to presently test any further. Please extend research for this issue to the other DEB files for 4.4. |
| Comments |
| Comment by Andrew Feierabend (Inactive) [ 24/Aug/20 ] | |||||||||||||||||||||||||||||||||||||||
|
The above does indeed work for me, replacing the missing /etc/mongod.conf file, matching your output exactly. So, if this is working as designed then, feel free to close this ticket. Thanks very much for your work digging into this! | |||||||||||||||||||||||||||||||||||||||
| Comment by Ryan Egesdahl (Inactive) [ 24/Aug/20 ] | |||||||||||||||||||||||||||||||||||||||
|
After some discussion with the rest of the SDP team, we have determined that this is in fact correct behavior. It is possible to specify a configuration file that creates data files which are incompatible with the default configuration and which risk data loss if those data files are accessed by a mongod instance running it. If we were to automatically replace a missing configuration with the default, we could end up with users who have accidentally deleted their configuration while mongod is running getting their data corrupted on the next upgrade (which could be unattended). This is actually why Debian does not automatically replace configuration files, in fact, and seasoned Debian admins already know about the behavior: https://askubuntu.com/questions/66533/how-can-i-restore-configuration-files For instances where you know you can use the default configuration provided by the package, apt (and also apt-get) provides a way for you to forcibly reinstall it:
Would you please try the above and make sure it also works for you? | |||||||||||||||||||||||||||||||||||||||
| Comment by Andrew Feierabend (Inactive) [ 24/Aug/20 ] | |||||||||||||||||||||||||||||||||||||||
|
Got it. Happy to hear guidance as well. I guess I was expecting the RPM approach: If /etc/mongod.conf exists on install attempt, either:
If /etc/mongod.conf doesn't already exist on install attempt, then always
If seasoned DEB administrators all already know to run apt purge, then I'd say this ticket is even less of a priority. I can share, also, that we haven't had any more negative feedback to the Docs regarding the Ubuntu 20.04 or 18.04 install procedure since that first day of 4.4 GA launch, so it seems like our users either already know this, or haven't yet uninstalled & reinstalled. Either way, no rush. And thanks for looking into this! | |||||||||||||||||||||||||||||||||||||||
| Comment by Ryan Egesdahl (Inactive) [ 23/Aug/20 ] | |||||||||||||||||||||||||||||||||||||||
|
andrew.feierabend What you are describing is just the way Debian packaging works. If you want to completely remove a package and tell the package manager to also delete configuration files, you would run apt purge mongodb-enterprise to do that. A reinstall after that should work then. There is, however, a way to ensure that a configuration file is always written on installation if it does not exist regardless of package configuration state, and it's used by some packages such as openssh-server{{}}. Let me confer with greater minds and see if it's an option for us. | |||||||||||||||||||||||||||||||||||||||
| Comment by Ryan Egesdahl (Inactive) [ 21/Aug/20 ] | |||||||||||||||||||||||||||||||||||||||
|
OK, your update makes a bit more sense to me and matches what I would have expected to be the case after reading the packaging files. It basically represents an unclean uninstall and the fact that we're not properly marking /etc/mongod.conf as a configuration file. | |||||||||||||||||||||||||||||||||||||||
| Comment by Andrew Feierabend (Inactive) [ 21/Aug/20 ] | |||||||||||||||||||||||||||||||||||||||
|
I built a fresh Ubuntu 20.04 image, and you're right: /etc/mongod.conf is installed correctly. However, upon removing and reinstalling mongodb-enterprise, the /etc/mongod.conf file is not installed with the re-install. I have attached repro steps in the file ubuntu20-mising-conf-file-repro-reinstall Specifically:
Guess: logic for "should I install conf file" checks for previous installation, and does not install if some leftovers are present. Perhaps mongodb user (which I did not alter once initial install created it)? Since this only seems to occur on re-installation, I agree that this is much less of a priority. Regarding the /var/lib/mongodb directory, I was mistaken in my earlier post – I was checking for /var/lib/mongo erroneously, the default dbpath for RHEL-based, not Debian-based. My mistake there. | |||||||||||||||||||||||||||||||||||||||
| Comment by Andrew Feierabend (Inactive) [ 20/Aug/20 ] | |||||||||||||||||||||||||||||||||||||||
|
Sure, I'll double check. | |||||||||||||||||||||||||||||||||||||||
| Comment by Ryan Egesdahl (Inactive) [ 20/Aug/20 ] | |||||||||||||||||||||||||||||||||||||||
|
The fact that the log directory exists and /var/lib/mongodb does not is perplexing, since both are created by the package postinst script. I think there might be something going on with the Vagrant image you were testing on. I tried the same sequence of steps in an Ubuntu 20.04 instance spun in Evergreen, and it worked just fine for me:
Is it possible that your Vagrant image is unclean somehow? Please try looking for the presence of the following before running the install steps:
In addition, try running the install with the following apt command and note any errors:
| |||||||||||||||||||||||||||||||||||||||
| Comment by Zakhar Kleyman [ 10/Aug/20 ] | |||||||||||||||||||||||||||||||||||||||
|
I'll forward this to SDP team since this looks packaging related. | |||||||||||||||||||||||||||||||||||||||
| Comment by Andrew Feierabend (Inactive) [ 04/Aug/20 ] | |||||||||||||||||||||||||||||||||||||||
|
Likely unrelated, as I was initially confusing Deb-default and RPM-default dbpaths. DIsregard. |