[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: HTML File ubuntu20-mising-conf-file-repro     HTML File ubuntu20-mising-conf-file-repro-reinstall    
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:

  • This DEB file does not create /var/lib/mongo, but does create /var/log/mongodb. Per 4.2 ( and this part of the live 4.4 instructions, here) both dirs are expected to be created via this DEB file. My error: Debian-based uses default dbpath of /var/lib/mongodb.
  • Ubuntu 20.04 complains of MDB service file using legacy PID file location. Just FYI. See repro.

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:

ubuntu@ip-10-122-15-57:~$ sudo apt -o Dpkg::Options::="--force-confmiss" install --reinstall mongodb-enterprise-server
Reading package lists... Done
Building dependency tree
Reading state information... Done
0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 65 not upgraded.
Need to get 20.7 MB of archives.
After this operation, 0 B of additional disk space will be used.
Get:1 http://repo.mongodb.com/apt/ubuntu focal/mongodb-enterprise/4.4/multiverse amd64 mongodb-enterprise-server amd64 4.4.0 [20.7 MB]
Fetched 20.7 MB in 1s (23.3 MB/s)
(Reading database ... 199263 files and directories currently installed.)
Preparing to unpack .../mongodb-enterprise-server_4.4.0_amd64.deb ...
Unpacking mongodb-enterprise-server (4.4.0) over (4.4.0) ...
Setting up mongodb-enterprise-server (4.4.0) ...
 
Configuration file '/etc/mongod.conf', does not exist on system.
Installing new config file as you requested.
Processing triggers for man-db (2.9.1-1) ...
ubuntu@ip-10-122-15-57:~$ systemctl status mongod.service
* mongod.service - MongoDB Database Server
     Loaded: loaded (/lib/systemd/system/mongod.service; disabled; vendor preset: enabled)
     Active: inactive (dead)
       Docs: https://docs.mongodb.org/manual
ubuntu@ip-10-122-15-57:~$ ls -la /etc/mongod.conf
-rw-r--r-- 1 root root 626 Dec 19  2013 /etc/mongod.conf
ubuntu@ip-10-122-15-57:~$ sudo systemctl start mongod.service
ubuntu@ip-10-122-15-57:~$ systemctl status mongod.service
* mongod.service - MongoDB Database Server
     Loaded: loaded (/lib/systemd/system/mongod.service; disabled; vendor preset: enabled)
     Active: active (running) since Mon 2020-08-24 19:15:46 UTC; 4s ago
       Docs: https://docs.mongodb.org/manual
   Main PID: 36513 (mongod)
     Memory: 160.7M
     CGroup: /system.slice/mongod.service
             `-36513 /usr/bin/mongod --config /etc/mongod.conf

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:

  • Install /etc/mongod.conf.rpmnew (if your RPM describes the conf file with %config(noreplace)), or
  • Move existing /etc/mongod.conf to /etc/mongod.conf.rpmsave and write new /etc/mongod.conf (if your RPM describes the conf file with %config).

If /etc/mongod.conf doesn't already exist on install attempt, then always

  • Install /etc/mongod.conf

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 ]

Hi ryan.egesdahl

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:

  1. Build fresh Ubuntu 20.04 image
  2. Install mongodb-enterprise – conf file is installed
  3. Uninstall mongodb-enterprise & delete conf file, but leave /var/lib/mongodb and /var/log/mongodb
  4. Install mongodb-enterprise again, as before – conf file is not installed
  5. Uninstall mongodb-enterprise & delete /var/lib/mongodb and /var/log/mongodb this time (conf file already doesn't exist)
  6. Install mongodb-enterprise again, as before – conf file is not installed

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:

ubuntu@ip-10-122-15-57:~$ cat /etc/apt/sources.list.d/mongodb-enterprise.list
deb [ arch=amd64,arm64,s390x ] http://repo.mongodb.com/apt/ubuntu focal/mongodb-enterprise/4.4 multiverse
ubuntu@ip-10-122-15-57:~$ sudo apt -oDebug::pkgAcquire::Worker=1 install mongodb-enterprise
...
Setting up mongodb-enterprise-shell (4.4.0) ...
Setting up mongodb-enterprise-mongos (4.4.0) ...
Setting up mongodb-enterprise-database-tools-extra (4.4.0) ...
Setting up mongodb-enterprise-cryptd (4.4.0) ...
Setting up mongodb-database-tools (100.1.1) ...
Setting up mongodb-enterprise-server (4.4.0) ...
Adding system user `mongodb' (UID 127) ...
Adding new user `mongodb' (UID 127) with group `nogroup' ...
Not creating home directory `/home/mongodb'.
Adding group `mongodb' (GID 136) ...
Done.
Adding user `mongodb' to group `mongodb' ...
Adding user mongodb to group mongodb
Done.
Setting up mongodb-enterprise-tools (4.4.0) ...
Setting up mongodb-enterprise (4.4.0) ...
Processing triggers for man-db (2.9.1-1) ...
ubuntu@ip-10-122-15-57:~$ ls -la /etc/mongod*
-rw-r--r-- 1 root root 626 Dec 19  2013 /etc/mongod.conf
-rw-r--r-- 1 root root  36 Aug 19 22:37 /etc/mongodb-build-system-id
-rw-r--r-- 1 root root   8 Aug 19 22:37 /etc/mongodb-distro-name
ubuntu@ip-10-122-15-57:~$ sudo systemctl start mongod.service
ubuntu@ip-10-122-15-57:~$ systemctl status mongod.service
* mongod.service - MongoDB Database Server
     Loaded: loaded (/lib/systemd/system/mongod.service; disabled; vendor preset: enabled)
     Active: active (running) since Thu 2020-08-20 20:02:16 UTC; 2s ago
       Docs: https://docs.mongodb.org/manual
   Main PID: 26108 (mongod)
     Memory: 61.9M
     CGroup: /system.slice/mongod.service
             `-26108 /usr/bin/mongod --config /etc/mongod.conf

Is it possible that your Vagrant image is unclean somehow? Please try looking for the presence of the following before running the install steps:

ls -la /var/lib/mongodb
ls -la /var/log/mongodb
ls -la /etc/mongod*

In addition, try running the install with the following apt command and note any errors:

sudo apt -oDebug::pkgAcquire::Worker=1 install mongodb-enterprise

Comment by Zakhar Kleyman [ 10/Aug/20 ]

I'll forward this to SDP team since this looks packaging related.
cc: acm

Comment by Andrew Feierabend (Inactive) [ 04/Aug/20 ]

User reports this also happening with Ubuntu 18.04, specifically the missing /var/lib/mongo dir.

Likely unrelated, as I was initially confusing Deb-default and RPM-default dbpaths. DIsregard.

Generated at Thu Feb 08 05:21:43 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.