4 ms·

> The installation instructions I've always followed for MongoDB start with importing a key, and adding their official repo to my source list. Going with the m

by pilif 8y ago

> The installation instructions I've always followed for MongoDB start with importing a key, and adding their official repo to my source list. Going with the maintainer's repo means that you trust the maintainer with providing security updates for the version you have installed or you trust them with providing a useable upgrade path. If you go with a distro package, you will get both the benefits of security updates for the lifetime of the OS itself and the benefits of the underlying software not changing. Of course it also means that you don't get new features for the lifetime of the OS. So depending on your target usage of MongoDB, you either would want to go with the OS packages (if MongoDB is just a dependency of a dependency and you don't really care about its functionality aside of it being there) or with the vendor packages (if you're directly depending on MongoDB and you're willing to keep up to date with feature releases). But even then, sometimes a vendor's official response to a security problem is "run apt-get upgrade to update to the latest major release" at a time when you really don't have the time to read the release notes and adopt your software to the changes in the new version. Other vendors still provide maintenance for older releases, so it really depends on the vendor, whereas if you go with the OS packages, none of this matters. Also, in this particular case, there's also the licensing issue to consider. I don't know whether it's safe for a company offering some service and/or application over the web to use current versions of MongoDB without paying for a license.

iqy 8y ago
>Going with the maintainer's repo means that you trust the maintainer with providing security updates for the version you have installed or you trust them with providing a useable upgrade path. Why should that be a problem if you use the official repo, handled by MongoDB themselves?
- sascha_sl 8y ago
  because a lot of people have support contracts with red hat now they'll be forced to also have one with mongodb (if their deployment is critical enough to already have red hat support they'll probably just caugh up the money)
- pilif 8y ago
  Because as I said later in my post, sometimes a vendor's response to a security issue is "please update to the latest major release". Let's say you're using version 1.1 of some software and you're hit by a remotely exploitable unauthenticated RCE. You want to patch it, but the vendor says that the only fix is to update to 2.0. How quickly can you adjust your software to work with that major release that might contain non-backwards compatible changes? Are you going to be quicker than the time it takes malware authors to write bots to hit that RCE? There's also a second example which is automated updates: Our infrastructure automatically applies OS package updates via `apt-get`. Thanks to Debian only ever updating packages for security reasons and only very rarely shipping new bugs, this is an actually workable practice. But once you start adding 3rd party vendors who, for example, believe that once puppet 4 is released it's totally safe to just publish puppet 4 as a replacement of puppet 3 previously in the 3rd party repo, this becomes a very dangerous practice.
  - chrisseaton 8y ago
    How does this work? How are RedHat able to reach into any of the thousands of projects in their repository and fix bugs and vulnerabilities? How do they have people on staff who understand all those codebases and algorithms? Do RedHat support engineers get tickets like 'bug in the energy minimisation algorithm of GraphViz - go in, learn that field of computer science, and fix it'?
    - quantummkv 8y ago
      It is the upstream vendor that issues fixes. What RedHat does is that it takes the commits that fix the bug and merge them into their forks and release.
      - chrisseaton 8y ago
        > It is the upstream vendor that issues fixes. So if you have a bug in a RedHat package, and you're paying $100k a year RedHat support contract, all they really do is open a GH issue with the upstream to ask them to fix it? And then you just wait hoping they fix it so RedHat can cherry pick it?
- geofft 8y ago
  It's a matter of scaling. If your job is "I want to run MongoDB," then it makes sense to track MongoDB's repo. If your job is "I want to run 100 different applications," then tracking 100 upstream repos (and dealing with their usually 80%-competent jobs of handling library dependencies, etc.) is no fun. I happen to be in the latter position. Developers at both my employer and my previous employers generally cannot just install whatever they want, mostly for longevity/support reasons (at my current employer there's a way for developers to import outside code into the monorepo, which means just this week I'm cleaning up Node 0.10 and Go 1.3 from the monorepo...). They go through a team that builds them a system they can use. And that team strongly prefers to get software from our Linux distro than from third parties, because every single team has their own preferred third parties to get software from. I do agree that for a shop that's running a single big web application with Mongo as the backend, they're probably installing it from upstream (and happier with that), but that's not the only use case.
Thaxll 8y ago
Any serious deployment know that one should never deploy mysql / mongodb / postgress with the default maintainer repo.
- nnq 8y ago
  Serious: WHY?
  - Thaxll 8y ago
    It's either not in the base repo / unmaintained quickly. I remember running MySQL on Debian / CentOS couple of years ago it was a joke how old the versions were. You should always use the official repo ( with provided RPM / deb ) for that kind of app. Example for CentOS 7.x: yum info mysql-connector-java.noarch Name : mysql-connector-java Arch : noarch Epoch : 1 Version : 5.1.25 Release : 3.el7 Size : 1.3 M Repo : base/7/x86_64 Summary : Official JDBC driver for MySQL Quick look at when was this released: https://dev.mysql.com/doc/relnotes/connector-j/5.1/en/news-5-1-25.html https://dev.mysql.com/doc/relnotes/connector-j/5.1/en/news-5... (2013-05-01) Almost 6 years old. Latest official version for 5.1.x was released 5 month ago: Changes in MySQL Connector/J 5.1.47 (2018-08-17)
diminoten 8y ago
Yeah but the point is, from a practical standpoint, nothing has changed. You were doing that before if you were using MongoDB + RHEL, so you'll still be doing that now.
- pilif 8y ago
  No. Before I could use the OS built-in MongoDB and get 10 years worth of security update for that version. Now I need to fetch the version packaged by MongoDB of which I don’t know the release cycles and years of included support. Plus, it’s an additional subscription cost and per-server license.
  - merlynn 8y ago
    Michael from MongoDB here. Are you assuming RedHat is patching MongoDB at a rate more frequently than MongoDB itself - not the case. Also, there is NO additional cost per-server-license for MongoDB Community. You should know that you can simply subscribe to the latest version (as well as older versions) of maintained packages for various os's and distributions... and these are available at no charge. More information: https://docs.mongodb.com/manual/tutorial/install-mongodb-on-red-hat/ https://docs.mongodb.com/manual/tutorial/install-mongodb-on-...
  - diminoten 8y ago
    Could? Yes. Did you? Probably not. It's not how MongoDB teaches: https://docs.mongodb.com/manual/tutorial/install-mongodb-on-red-hat/ https://docs.mongodb.com/manual/tutorial/install-mongodb-on-... And it's a blatant lie to say you don't know the supportability of MongoDB, as they publish it directly on their site: https://www.mongodb.com/support-policy https://www.mongodb.com/support-policy This means nothing, practically. It's grandstanding, and it's annoying. Stop.

by pilif 8y ago

iqy 8y ago

>Going with the maintainer's repo means that you trust the maintainer with providing security updates for the version you have installed or you trust them with providing a useable upgrade path. Why should that be a problem if you use the official repo, handled by MongoDB themselves?

sascha_sl 8y ago
because a lot of people have support contracts with red hat now they'll be forced to also have one with mongodb (if their deployment is critical enough to already have red hat support they'll probably just caugh up the money)
pilif 8y ago
Because as I said later in my post, sometimes a vendor's response to a security issue is "please update to the latest major release". Let's say you're using version 1.1 of some software and you're hit by a remotely exploitable unauthenticated RCE. You want to patch it, but the vendor says that the only fix is to update to 2.0. How quickly can you adjust your software to work with that major release that might contain non-backwards compatible changes? Are you going to be quicker than the time it takes malware authors to write bots to hit that RCE? There's also a second example which is automated updates: Our infrastructure automatically applies OS package updates via `apt-get`. Thanks to Debian only ever updating packages for security reasons and only very rarely shipping new bugs, this is an actually workable practice. But once you start adding 3rd party vendors who, for example, believe that once puppet 4 is released it's totally safe to just publish puppet 4 as a replacement of puppet 3 previously in the 3rd party repo, this becomes a very dangerous practice.
- chrisseaton 8y ago
  How does this work? How are RedHat able to reach into any of the thousands of projects in their repository and fix bugs and vulnerabilities? How do they have people on staff who understand all those codebases and algorithms? Do RedHat support engineers get tickets like 'bug in the energy minimisation algorithm of GraphViz - go in, learn that field of computer science, and fix it'?
  - quantummkv 8y ago
    It is the upstream vendor that issues fixes. What RedHat does is that it takes the commits that fix the bug and merge them into their forks and release.
    - chrisseaton 8y ago
      > It is the upstream vendor that issues fixes. So if you have a bug in a RedHat package, and you're paying $100k a year RedHat support contract, all they really do is open a GH issue with the upstream to ask them to fix it? And then you just wait hoping they fix it so RedHat can cherry pick it?
geofft 8y ago
It's a matter of scaling. If your job is "I want to run MongoDB," then it makes sense to track MongoDB's repo. If your job is "I want to run 100 different applications," then tracking 100 upstream repos (and dealing with their usually 80%-competent jobs of handling library dependencies, etc.) is no fun. I happen to be in the latter position. Developers at both my employer and my previous employers generally cannot just install whatever they want, mostly for longevity/support reasons (at my current employer there's a way for developers to import outside code into the monorepo, which means just this week I'm cleaning up Node 0.10 and Go 1.3 from the monorepo...). They go through a team that builds them a system they can use. And that team strongly prefers to get software from our Linux distro than from third parties, because every single team has their own preferred third parties to get software from. I do agree that for a shop that's running a single big web application with Mongo as the backend, they're probably installing it from upstream (and happier with that), but that's not the only use case.

Thaxll 8y ago

Any serious deployment know that one should never deploy mysql / mongodb / postgress with the default maintainer repo.

nnq 8y ago
Serious: WHY?
- Thaxll 8y ago
  It's either not in the base repo / unmaintained quickly. I remember running MySQL on Debian / CentOS couple of years ago it was a joke how old the versions were. You should always use the official repo ( with provided RPM / deb ) for that kind of app. Example for CentOS 7.x: yum info mysql-connector-java.noarch Name : mysql-connector-java Arch : noarch Epoch : 1 Version : 5.1.25 Release : 3.el7 Size : 1.3 M Repo : base/7/x86_64 Summary : Official JDBC driver for MySQL Quick look at when was this released: https://dev.mysql.com/doc/relnotes/connector-j/5.1/en/news-5-1-25.html https://dev.mysql.com/doc/relnotes/connector-j/5.1/en/news-5... (2013-05-01) Almost 6 years old. Latest official version for 5.1.x was released 5 month ago: Changes in MySQL Connector/J 5.1.47 (2018-08-17)

diminoten 8y ago

Yeah but the point is, from a practical standpoint, nothing has changed. You were doing that before if you were using MongoDB + RHEL, so you'll still be doing that now.

pilif 8y ago
No. Before I could use the OS built-in MongoDB and get 10 years worth of security update for that version. Now I need to fetch the version packaged by MongoDB of which I don’t know the release cycles and years of included support. Plus, it’s an additional subscription cost and per-server license.
- merlynn 8y ago
  Michael from MongoDB here. Are you assuming RedHat is patching MongoDB at a rate more frequently than MongoDB itself - not the case. Also, there is NO additional cost per-server-license for MongoDB Community. You should know that you can simply subscribe to the latest version (as well as older versions) of maintained packages for various os's and distributions... and these are available at no charge. More information: https://docs.mongodb.com/manual/tutorial/install-mongodb-on-red-hat/ https://docs.mongodb.com/manual/tutorial/install-mongodb-on-...
- diminoten 8y ago
  Could? Yes. Did you? Probably not. It's not how MongoDB teaches: https://docs.mongodb.com/manual/tutorial/install-mongodb-on-red-hat/ https://docs.mongodb.com/manual/tutorial/install-mongodb-on-... And it's a blatant lie to say you don't know the supportability of MongoDB, as they publish it directly on their site: https://www.mongodb.com/support-policy https://www.mongodb.com/support-policy This means nothing, practically. It's grandstanding, and it's annoying. Stop.