-1

The world of package managers is a wonderful one. If one package isn't available in your Linux distributions package manager chances are that it's available in any of the language specific package managers.

But as soon as you install a package through any venue, including of course manual install, other than the distribution package manager you also take on the responsibility of keeping up to date with security advisor's and making sure that the software is up to date; something which is automatically taken care of in for example Debian with unattended upgrades installed.

So my question is this: for the below listed programming language specific package managers, is it possible to set up automatic updates. Or even better automatic updates but only if the update is a security fix.

  • PIP - Python
  • Gem - Ruby
  • Cabal - Haskell
  • Pear - PHP
  • NPM - NodeJS
  • Get - Go

Of course one will have to weigh the soundness of automatically upgrading to possibly broken packages versus running unsecured software because the operator glanced over a relevant SA in his daily deluge of emails. But that's a topic for another server fault question.

There's always the trivial solution of creating a cron job. But that would pull down every update, not just security updates.

This question is about automatic security upgrades like the functionality of Debians unattended-upgrades package. I'm asking how to best keep external packages not maintained by our Linux distribution safe on our business critical servers, how is that not on topic?

Rovanion
  • 609
  • 3
  • 7
  • 22
  • 1
    No, and you don't _want_ to, either. If you do this, you have to test your application against the upgraded libraries. You _do_ have tests, right? – Michael Hampton Jul 27 '15 at 15:19
  • 1
    @MichaelHampton Had you read the question in it's entirety you would have reached the paragraph which detailed that I'm not asking about the soundness of automatic upgrades, that is an entirely different question meriting it's own SF topic, but about whether or not it is possible for any of the listed tools. – Rovanion Jul 28 '15 at 10:41
  • In response to your justification for re-opening above: it was, and is, off-topic because you shouldn't be doing that in the first place. PERL modules installed via CPAN, python via PIP, they're all flaming disasters *because* of this lack of central maintainability. As sam notes in his answer below, most of the useful modules for these toolchains can be found in the regular repositories, and many others can be found in the reputable add-on repositories. Don't go off-piste, then ask how to make it look like the regular slope; just stay on-piste. – MadHatter Jul 29 '15 at 13:25
  • @MadHatter So all questions related to language specific package managers are off topic? – Rovanion Jul 30 '15 at 10:43
  • My personal feeling is that questions where someone has deliberately chosen not to do something in the professional way, then wants to know how to get back to the advantages of the professional way without reverting to that way, are off-topic, because that's not how to manage things in a business environment. Others, of course, may disagree, and I cannot of course comment on why the others who voted to close this question feel on the matter. If you'd like to continue this debate, may I suggest that [meta](http://meta.serverfault.com/) is a better place to do it? – MadHatter Jul 30 '15 at 16:54
  • @MadHatter Let me quote the original question: "If one package isn't available in your Linux distributions package manager chances are that it's available in any of the language specific package managers." If the package isn't available from the dist there is a hard choice the professional has to make: compile on your own or use language specific package managers. You continue by accusing me of things which you have no grounds for. I have never and will never choose a pip package over a Debian package. But to finish off: Questions about specific posts don't seem to be well received on Meta. – Rovanion Jul 31 '15 at 11:10
  • You ignore the third way, which is to look for reputable comunity-packaged repositories. My CentOS boxes, for example, widely expand the range of (eg) perl modules available to them by adding RPMForge and EPEL to `yum`. That third way gets the benefits of many more modules than the base OS supplies, but keeps centralisation in your package management - and you don't seem to address it, certainly not in the sentence you quote above. I agree that you have to make a strong argument for reopening to convince meta, but it does happen - and it is the right place for such a discussion. – MadHatter Jul 31 '15 at 20:28
  • Now we've actually come across something which could be fixed with the question, but it's a long way from off-topic to doesn't adress X. While big repos like such are quite popular in the rpm world, and perhaps Ubuntu with their extensive range of smaller PPA:s, in the Debian world they're far between. Some big projects like puppet have their own repos, but feel free to point towards any big collection of packages like RepoForge. All in all you end up stuck between a rock and a hard place, I'm sad that SF shies away from the hard questions. – Rovanion Aug 01 '15 at 06:13

1 Answers1

2

With PHP's PEAR, you can use pear upgrade without package name arguments. Simply employ a cron job to automate it. AFAIK there's no way to distinguish security-related updates in PEAR, you can only limit update channels (stable, beta, etc.).

You can also use pear list-upgrades with cron, to get automated notifications of possible upgrades.

As you mentioned Debian, I doubt this answer will really be useful for you. A majority of stable and useful PEAR packages is available in official APT repositories.

I cannot talk for other managers, as I've never used them.

sam_pan_mariusz
  • 2,133
  • 1
  • 14
  • 15