10 ms·

Debops (2014)

190 points by chei0aiV 11y ago

stephenr 11y ago
I like this a lot, and I love the term DebOps. The way developers somehow think DevOps is (or should be) an abbreviation of "Developers doing/replacing Operations" is terrifying to me. I'm also in the same boat as the author, in that I recommend and target Debian Stable + Backports (and some vendor/community repos when required).
- quanticle 11y ago
  The problem with targeting Debian Stable + Backports is that your packages are going to perpetually out of date unless you go to the trouble of packaging up your dependencies as .debs and running your own apt server. Targeting Debian stable is fine if you can get away with using three year old libraries. But for a lot of languages, like Python, 3 year old libraries are at a significant feature disadvantage when compared to their current counterparts.
  - calpaterson 11y ago
    Debian stable includes pip and virtualenv. If you want to manage your python dependencies for yourself that road is definitely open to you.
    - icebraining 11y ago
      Mixing pip and debs loses some of the advantages of having a standard system, though. I think you're better off producing deb packages from PyPI in your build server.
      - chei0aiV 11y ago
        There are some tools to help out with that: https://wiki.debian.org/AutomaticPackagingTools https://wiki.debian.org/AutomaticPackagingTools https://summit.debconf.org/debconf15/meeting/257/automatic-packaging/ https://summit.debconf.org/debconf15/meeting/257/automatic-p...
      - justizin 11y ago
        I typically rec installing virtualenv systemwide, if a reasonable version is available by package, and managing per-app dependencies in a requirements.txt that's platform agnostic. The Debian ecosystem is great, but I would never recommend a developer marry an app to it.
        icebraining 11y ago
        But there's no reason you can't have the cake and eat it too; you can create a virtualenv from a requirements.txt file on your build server, then package it up in a deb package that installs those files in a custom directory (not in the shared Python modules path). That way, you get static artifacts you can deploy (instead of deploying using pip, which requires compiling any non-pure-python package on the server), you get to use apt's dependencies for non-Python packages, like system libraries, and you can easily rollback by simply pushing the previous version of the deb package, which is cleaner than rolling back with pip, in my experience.
  - annnnd 11y ago
    When you say "out of date", you probably mean feature wise, not security and stability wise? For me that is an acceptable tradeoff for most of the packages. Most of the stuff doesn't evolve at such pace that I should have the latest and greatest (I am talking about core libs and similar). And the packages where I miss some new functionality, I can just upgrade them manually. Take Firefox for instance - if you don't like/trust Iceweasel, you can just install FF to /opt/ and trust Mozilla for upgrades. For me this is win-win situation. You have a stable and secure foundation and you put bleeding edge stuff on it when you need it.
    - tankenmate 11y ago
      Indeed, for myself I prefer stable releases (Debian, Ubuntu LTS, etc) and use apt pinning so that I can use newer versions of apps that I need to use. Very rarely will I have a problem; in fact the few times there is a problem it is normally solved by apt-get source ; dpkg-buildpackage.
      - stephenr 11y ago
        Do you just use pinning straight out the gate, or do you check backports (or whatever equivalent Ubuntu has) first?
        tankenmate 11y ago
        It depends, normally in order of preference LTS, LTS backports, then latest release. So then if you want the newer version you can do apt-get install <package>/<release>. I typically use Apt::Default-Release "<release>" in a separate apt.conf.d file.
    - XorNot 11y ago
      Just yesterday I had a problem which was some combination of Debian Jessie's incredibly outdated Python CFFI library (0.8.6) and its interaction with OpenSSL which took a script from taking milliseconds to launch to over 1.5 seconds, purely due to that import.
- bbrazil 11y ago
  A bit over a year ago I researched what "Devops" means, and the answer seemed to be Developers being able to push code to production without having to involve Operations. This sounds like a good goal to have (presuming you've got good unittests etc.) as it removes an unnecessary friction for developers. What it doesn't include is all the higher-value work the people on the Operational side tend to provide, like thinking about rollbacks, machine failure, network failure, provisioning, capacity planning, change/configuration management, security, monitoring etc - which is not to say that all developers don't think about these things, their focus tends to be on developing product rather than these non-functional requirements. I'm presently in a world of Ubuntu LTS+a few manual backports for similar reasons as the authors. My home systems are ansible managed, giving me things like wireshark installed everywhere if I need it and new machines automatically hooked into Prometheus monitoring (which is much easier with my debs). I've seen what happens if you try to manually manage machines, and know that a small bit of upfront work will bring dividends later. Writing the core code is just one critical step in running software long term, let's not forget the rest of the critical steps to keep it running in a sane way in the future.
  - chei0aiV 11y ago
    https://packages.debian.org/prometheus https://packages.debian.org/prometheus
    - bbrazil 11y ago
      http://deb.robustperception.io/ http://deb.robustperception.io/ is my nightly build. It's one of the few things I want to run on the very bleeding edge of.
  - stephenr 11y ago
    Many people have different interpretations of the term 'DevOps', but what you're describing in that first paragraph is Continuous Deployment. Yes, it's related to (in that it's often a beneficial result of) but it's not explicitly the same as DevOps, by any definition I've seen, good or bad.
- skarap 11y ago
  > The way developers somehow think DevOps is (or should be) an abbreviation of "Developers doing/replacing Operations" is terrifying to me. And what about the way management thinks that's when you don't have to pay Operations people (those guys who always try to stop progress in your company)?
  - stephenr 11y ago
    Sounds like another way of saying the same thing to me, no? No one says "we don't need someone to setup/maintain our servers". DevOps is, in every interpretation I've seen, about who/how it's done.
    - skarap 11y ago
      > No one says "we don't need someone to setup/maintain our servers". Of course they do. And there are a lot of products which are marketed using that idea: "AWS Elastic Beanstalk is the fastest and simplest way to get an application up and running on AWS. Developers can simply upload their application code and the service automatically handles all the details such as resource provisioning, load balancing, auto-scaling, and monitoring." The configuration management/orchestration tools also help with that (you don't need anyone to provision the servers, take care of dependencies etc., you can just include these 15 Chef cookbooks, and everything will be done automatically). Btw: I'm not saying configuration management tools are bad - they are a must-have, I'm just saying - nothing will replace a person who knows what they are doing.
      - stephenr 11y ago
        > Developers can simply upload their application code and the service automatically handles all the details In this situation, you've basically traded your own Ops staff for a combination of your developers and whatever support AWS provides you - so you're back to a managed service like every man and his dog was using in the 90s.
saurik 11y ago
> I build my software targeting Debian Stable + Backports. At FOSDEM I noticed that some people consider it uncool. I was perplexed. I am also perplexed... what are these other people doing?
- Sphax 11y ago
  Deploy on CoreOS maybe.
- chei0aiV 11y ago
  They are doing stuff like this: https://news.ycombinator.com/item?id=9952356 https://news.ycombinator.com/item?id=9952356
  - chei0aiV 11y ago
    To the downvoters: the comments on that post mention a lot of deployment methods that people not doing Debops are using.
KaiserPro 11y ago
Yes, working smart not hard. The value of going home on time each night, because there is a wealth of google searches to expose and workaround known bugs should never be underestimates.
Sphax 11y ago
How do you not bundle in dependencies when coding in, say, Java ? The Java packages on Debian are for the most part outdated. It's way more practical to just use Maven, build a fat jar and be done with it.
- chei0aiV 11y ago
  To not bundle dependencies, use the Java packages in Debian stable and if you find one with a missing feature or unfixed bug, then backport that from Debian unstable or from upstream.
  - bbrazil 11y ago
    Debs and Rpms are fine for configuring the machine, as soon as you have it where machines and application services aren't a 1:1 relationship that will lead you in the direction of dependency hell. As each application will want slightly different versions you'd have to be very careful which version you installed. You can cheat a little. For example I am using some system debs for python packages, but if there were more than a handful of python utility packages that can get unmanageable fast. That leads naturally to the fat jar/virtualenv/static binary approach with manually managed dependencies which gives you isolation between applications, and all the associated costs.
    - chei0aiV 11y ago
      Why do applications want different versions of libraries instead of being portable?
      - bbrazil 11y ago
        It's very common to have breaking changes that you need to carefully manage in a company's internal code, and where managing that as a full-on deprecation isn't worth the effort. Moving faster is often the better choice compared to never refactoring and improving the codebase.
        11y ago
skarap 11y ago
Never understood why debian ended as the distribution of choice of the DevOps-related movements. Ubuntu is understandable - developers used it on their desktops so when they orderer their first VPS, they chose ubuntu. But why debian? Also why it looks like RHEL family is completely out of fashion? Is it considered too "enterprisy"?
- juliangregorian 11y ago
  Why Ubuntu? If you're not writing GUIs, Ubuntu is just a less-stable Debian.
  - jnbiche 11y ago
    > Why Ubuntu? PPAs.
    - duggan 11y ago
      PPA's are a seriously killer feature. Easily one of the most important parts of the Ubuntu ecosystem. Not enough people realize it.
      - chei0aiV 11y ago
        What is the killer part of PPAs? It is pretty easy to setup your own repo on a server using reprepro or aptly. Is it the build-machines-as-a-service aspect? Or the ease of adding a PPA to your system? Or the fact anyone can dump some stuff into a repo and have Launchpad/Canonical/Ubuntu bless them?
        erikb 11y ago
        I think it's the part of having bleeding edge packages easily linked into your system. Other options might be available but people simply don't know about it. And developers themselves might already provide the PPAs which means there are many PPAs available. Might be the worst solution but is the most well known.
Kabacaru 11y ago
So I develop PHP. The reason I don't use Debian stable is because the latest version of PHP on there is 5.4.41, which is behind the "old stable version". That means security fixes only. No bug fixes that resolve problems, or modern functionality (that release is over a year old), and will be EOLd in 1 month. That means a big delta of change that will be needed to handled when debian finally does get round to upgrading. Large deltas of change mean lots of risk. It's much better to stay further up the crest of the wave and handle more regular updates, to minimise the size of the risk I'm bringing into my code at each release, than it is to stick to an old version and not handle the stream of new functionality that's coming in as it arrives.
- 0x0 11y ago
  Debian Stable has 5.6.9 at the moment, https://packages.debian.org/jessie/php5 https://packages.debian.org/jessie/php5 - and shipped with 5.6.7 initially. Security updates for php5 in Debian seem to have changed from backporting security fixes to staying up to date on any given upstream minor branch, including other fixes. https://security-tracker.debian.org/tracker/source-package/php5 https://security-tracker.debian.org/tracker/source-package/p...
  - Kabacaru 11y ago
    Gah, well there's that argument out the window. We tend to use docker on CoreOS here, so it's not much of an issue. Maybe next time I stand up a real VM I'll look at using Debian stable then.
- stephenr 11y ago
  For more up to date PHP packages on Debian, try http://dotdeb.org http://dotdeb.org
  - gog 11y ago
    +1 for DotDeb. For Jessie I would use the stock packages.
    - 11y ago
zufallsheld 11y ago
There's also DebOps[0], a collection of ansible playbooks a " Debian-based data center in a box". [0]https://github.com/debops/debops https://github.com/debops/debops
- nickjj 11y ago
  I remember going over with the author on what we should name the domain[0]. I figured it was pretty unique. [0]http://debops.org http://debops.org
olgeni 11y ago
I recently had to develop an Erlang application targeting Debian "stable". It was humiliating at best. Countless hour were wasted trying to get around bugs in prehistoric packages, or building new (and working) packages from scratch. Never again.
- gog 11y ago
  Debian Jessie just came out 2 months ago and as far as I can tell the packages in it are pretty recent. Were you targeting Wheezy?
  - olgeni 11y ago
    Yes - in the beginning. If you look here https://github.com/erlang/otp/releases https://github.com/erlang/otp/releases you'll see that - even on Jessie - 17.1 is unfortunately way behind.
    - gog 11y ago
      Jessie is using 17.3.4 (if I am reading the version correctly), see https://packages.debian.org/jessie/erlang https://packages.debian.org/jessie/erlang 17.3.4 was released on 4th of November 2014, according to the link you provided. Jessie "freeze" happened on 5th of November ( https://lists.debian.org/debian-devel-announce/2014/11/msg00003.html https://lists.debian.org/debian-devel-announce/2014/11/msg00... ), so I even wonder that they are shipping that version. In my opinion that is not "way behind". If you need bleeding edge you should move to unstable or testing releases, move to a rolling release distribution like Arch or build your own.
      - stephenr 11y ago
        I tried to work this out as well. It is indeed using 17.3.x but its hard to nail down which point release, as the Debian changelog doesn't mention when they pull a new upstream version (vs fixing an issue in the package itself) I figured I would just install the package and use a -v or --version arg to get the exact build version. I cannot find any way to get a patch version out of Erlang. The `OTP_VERSION` file simply says 17.3, and the most I can get from `erl` or `erlc` is "17".
nvarsj 11y ago
Using Debian isn't a panacea. Neither is any particular distribution. Anecdotally, the only personal server I've had hacked was running Debian - due to it using an old openssh version (the issue was not present in later versions). It was fixed quickly, but I got 0dayed.
- stephenr 11y ago
  The only server's I've seen (and subsequently replaced, with Debian) breached were old CentOS boxes. The key thing here is not "Debian is bad" or "CentOS is bad" it's that you need to keep up to date with security patches. For Debian that usually means a combination of using the Security Apt repo, and for things like OpenSSH, using the Backports Apt repo. I do agree that Debian isn't a silver bullet, but in my experience it's much easier to work with from a setup/management point of view than CentOS, particularly for small shops that are't heavily invested in a full-blown CM tool - shell scripts and/or Debian config packages [1] can be used to fully provision one server or fifty. [1] http://debathena.mit.edu/config-packages/ http://debathena.mit.edu/config-packages/
HeXetic 11y ago
Am I the only one who finds this style of usually-just-one-sentence-per-paragraph almost completely unreadable on a visual level?
ecesena 11y ago
Please edit title with (2014)
throwaway0189 11y ago
Related to this: Outsourcing your webapp maintenance to Debian https://feeding.cloud.geek.nz/posts/outsourcing-webapp-maintenance-to-debian/ https://feeding.cloud.geek.nz/posts/outsourcing-webapp-maint...

Debops (2014)

190 points by chei0aiV 11y ago

I like this a lot, and I love the term DebOps. The way developers somehow think DevOps is (or should be) an abbreviation of "Developers doing/replacing Operations" is terrifying to me. I'm also in the same boat as the author, in that I recommend and target Debian Stable + Backports (and some vendor/community repos when required).

quanticle 11y ago
The problem with targeting Debian Stable + Backports is that your packages are going to perpetually out of date unless you go to the trouble of packaging up your dependencies as .debs and running your own apt server. Targeting Debian stable is fine if you can get away with using three year old libraries. But for a lot of languages, like Python, 3 year old libraries are at a significant feature disadvantage when compared to their current counterparts.
- calpaterson 11y ago
  Debian stable includes pip and virtualenv. If you want to manage your python dependencies for yourself that road is definitely open to you.
  - icebraining 11y ago
    Mixing pip and debs loses some of the advantages of having a standard system, though. I think you're better off producing deb packages from PyPI in your build server.
    - chei0aiV 11y ago
      There are some tools to help out with that: https://wiki.debian.org/AutomaticPackagingTools https://wiki.debian.org/AutomaticPackagingTools https://summit.debconf.org/debconf15/meeting/257/automatic-packaging/ https://summit.debconf.org/debconf15/meeting/257/automatic-p...
    - justizin 11y ago
      I typically rec installing virtualenv systemwide, if a reasonable version is available by package, and managing per-app dependencies in a requirements.txt that's platform agnostic. The Debian ecosystem is great, but I would never recommend a developer marry an app to it.
      - icebraining 11y ago
        But there's no reason you can't have the cake and eat it too; you can create a virtualenv from a requirements.txt file on your build server, then package it up in a deb package that installs those files in a custom directory (not in the shared Python modules path). That way, you get static artifacts you can deploy (instead of deploying using pip, which requires compiling any non-pure-python package on the server), you get to use apt's dependencies for non-Python packages, like system libraries, and you can easily rollback by simply pushing the previous version of the deb package, which is cleaner than rolling back with pip, in my experience.
- annnnd 11y ago
  When you say "out of date", you probably mean feature wise, not security and stability wise? For me that is an acceptable tradeoff for most of the packages. Most of the stuff doesn't evolve at such pace that I should have the latest and greatest (I am talking about core libs and similar). And the packages where I miss some new functionality, I can just upgrade them manually. Take Firefox for instance - if you don't like/trust Iceweasel, you can just install FF to /opt/ and trust Mozilla for upgrades. For me this is win-win situation. You have a stable and secure foundation and you put bleeding edge stuff on it when you need it.
  - tankenmate 11y ago
    Indeed, for myself I prefer stable releases (Debian, Ubuntu LTS, etc) and use apt pinning so that I can use newer versions of apps that I need to use. Very rarely will I have a problem; in fact the few times there is a problem it is normally solved by apt-get source ; dpkg-buildpackage.
    - stephenr 11y ago
      Do you just use pinning straight out the gate, or do you check backports (or whatever equivalent Ubuntu has) first?
      - tankenmate 11y ago
        It depends, normally in order of preference LTS, LTS backports, then latest release. So then if you want the newer version you can do apt-get install <package>/<release>. I typically use Apt::Default-Release "<release>" in a separate apt.conf.d file.
  - XorNot 11y ago
    Just yesterday I had a problem which was some combination of Debian Jessie's incredibly outdated Python CFFI library (0.8.6) and its interaction with OpenSSL which took a script from taking milliseconds to launch to over 1.5 seconds, purely due to that import.
bbrazil 11y ago
A bit over a year ago I researched what "Devops" means, and the answer seemed to be Developers being able to push code to production without having to involve Operations. This sounds like a good goal to have (presuming you've got good unittests etc.) as it removes an unnecessary friction for developers. What it doesn't include is all the higher-value work the people on the Operational side tend to provide, like thinking about rollbacks, machine failure, network failure, provisioning, capacity planning, change/configuration management, security, monitoring etc - which is not to say that all developers don't think about these things, their focus tends to be on developing product rather than these non-functional requirements. I'm presently in a world of Ubuntu LTS+a few manual backports for similar reasons as the authors. My home systems are ansible managed, giving me things like wireshark installed everywhere if I need it and new machines automatically hooked into Prometheus monitoring (which is much easier with my debs). I've seen what happens if you try to manually manage machines, and know that a small bit of upfront work will bring dividends later. Writing the core code is just one critical step in running software long term, let's not forget the rest of the critical steps to keep it running in a sane way in the future.
- chei0aiV 11y ago
  https://packages.debian.org/prometheus https://packages.debian.org/prometheus
  - bbrazil 11y ago
    http://deb.robustperception.io/ http://deb.robustperception.io/ is my nightly build. It's one of the few things I want to run on the very bleeding edge of.
- stephenr 11y ago
  Many people have different interpretations of the term 'DevOps', but what you're describing in that first paragraph is Continuous Deployment. Yes, it's related to (in that it's often a beneficial result of) but it's not explicitly the same as DevOps, by any definition I've seen, good or bad.
skarap 11y ago
> The way developers somehow think DevOps is (or should be) an abbreviation of "Developers doing/replacing Operations" is terrifying to me. And what about the way management thinks that's when you don't have to pay Operations people (those guys who always try to stop progress in your company)?
- stephenr 11y ago
  Sounds like another way of saying the same thing to me, no? No one says "we don't need someone to setup/maintain our servers". DevOps is, in every interpretation I've seen, about who/how it's done.
  - skarap 11y ago
    > No one says "we don't need someone to setup/maintain our servers". Of course they do. And there are a lot of products which are marketed using that idea: "AWS Elastic Beanstalk is the fastest and simplest way to get an application up and running on AWS. Developers can simply upload their application code and the service automatically handles all the details such as resource provisioning, load balancing, auto-scaling, and monitoring." The configuration management/orchestration tools also help with that (you don't need anyone to provision the servers, take care of dependencies etc., you can just include these 15 Chef cookbooks, and everything will be done automatically). Btw: I'm not saying configuration management tools are bad - they are a must-have, I'm just saying - nothing will replace a person who knows what they are doing.
    - stephenr 11y ago
      > Developers can simply upload their application code and the service automatically handles all the details In this situation, you've basically traded your own Ops staff for a combination of your developers and whatever support AWS provides you - so you're back to a managed service like every man and his dog was using in the 90s.

saurik 11y ago

> I build my software targeting Debian Stable + Backports. At FOSDEM I noticed that some people consider it uncool. I was perplexed. I am also perplexed... what are these other people doing?

Sphax 11y ago
Deploy on CoreOS maybe.
chei0aiV 11y ago
They are doing stuff like this: https://news.ycombinator.com/item?id=9952356 https://news.ycombinator.com/item?id=9952356
- chei0aiV 11y ago
  To the downvoters: the comments on that post mention a lot of deployment methods that people not doing Debops are using.

KaiserPro 11y ago

Yes, working smart not hard. The value of going home on time each night, because there is a wealth of google searches to expose and workaround known bugs should never be underestimates.

Sphax 11y ago

How do you not bundle in dependencies when coding in, say, Java ? The Java packages on Debian are for the most part outdated. It's way more practical to just use Maven, build a fat jar and be done with it.

chei0aiV 11y ago
To not bundle dependencies, use the Java packages in Debian stable and if you find one with a missing feature or unfixed bug, then backport that from Debian unstable or from upstream.
- bbrazil 11y ago
  Debs and Rpms are fine for configuring the machine, as soon as you have it where machines and application services aren't a 1:1 relationship that will lead you in the direction of dependency hell. As each application will want slightly different versions you'd have to be very careful which version you installed. You can cheat a little. For example I am using some system debs for python packages, but if there were more than a handful of python utility packages that can get unmanageable fast. That leads naturally to the fat jar/virtualenv/static binary approach with manually managed dependencies which gives you isolation between applications, and all the associated costs.
  - chei0aiV 11y ago
    Why do applications want different versions of libraries instead of being portable?
    - bbrazil 11y ago
      It's very common to have breaking changes that you need to carefully manage in a company's internal code, and where managing that as a full-on deprecation isn't worth the effort. Moving faster is often the better choice compared to never refactoring and improving the codebase.
      - 11y ago

skarap 11y ago

Never understood why debian ended as the distribution of choice of the DevOps-related movements. Ubuntu is understandable - developers used it on their desktops so when they orderer their first VPS, they chose ubuntu. But why debian? Also why it looks like RHEL family is completely out of fashion? Is it considered too "enterprisy"?

juliangregorian 11y ago
Why Ubuntu? If you're not writing GUIs, Ubuntu is just a less-stable Debian.
- jnbiche 11y ago
  > Why Ubuntu? PPAs.
  - duggan 11y ago
    PPA's are a seriously killer feature. Easily one of the most important parts of the Ubuntu ecosystem. Not enough people realize it.
    - chei0aiV 11y ago
      What is the killer part of PPAs? It is pretty easy to setup your own repo on a server using reprepro or aptly. Is it the build-machines-as-a-service aspect? Or the ease of adding a PPA to your system? Or the fact anyone can dump some stuff into a repo and have Launchpad/Canonical/Ubuntu bless them?
      - erikb 11y ago
        I think it's the part of having bleeding edge packages easily linked into your system. Other options might be available but people simply don't know about it. And developers themselves might already provide the PPAs which means there are many PPAs available. Might be the worst solution but is the most well known.

Kabacaru 11y ago

So I develop PHP. The reason I don't use Debian stable is because the latest version of PHP on there is 5.4.41, which is behind the "old stable version". That means security fixes only. No bug fixes that resolve problems, or modern functionality (that release is over a year old), and will be EOLd in 1 month. That means a big delta of change that will be needed to handled when debian finally does get round to upgrading. Large deltas of change mean lots of risk. It's much better to stay further up the crest of the wave and handle more regular updates, to minimise the size of the risk I'm bringing into my code at each release, than it is to stick to an old version and not handle the stream of new functionality that's coming in as it arrives.

0x0 11y ago
Debian Stable has 5.6.9 at the moment, https://packages.debian.org/jessie/php5 https://packages.debian.org/jessie/php5 - and shipped with 5.6.7 initially. Security updates for php5 in Debian seem to have changed from backporting security fixes to staying up to date on any given upstream minor branch, including other fixes. https://security-tracker.debian.org/tracker/source-package/php5 https://security-tracker.debian.org/tracker/source-package/p...
- Kabacaru 11y ago
  Gah, well there's that argument out the window. We tend to use docker on CoreOS here, so it's not much of an issue. Maybe next time I stand up a real VM I'll look at using Debian stable then.
stephenr 11y ago
For more up to date PHP packages on Debian, try http://dotdeb.org http://dotdeb.org
- gog 11y ago
  +1 for DotDeb. For Jessie I would use the stock packages.
  - 11y ago

zufallsheld 11y ago

There's also DebOps[0], a collection of ansible playbooks a " Debian-based data center in a box". [0]https://github.com/debops/debops https://github.com/debops/debops

nickjj 11y ago
I remember going over with the author on what we should name the domain[0]. I figured it was pretty unique. [0]http://debops.org http://debops.org

olgeni 11y ago

I recently had to develop an Erlang application targeting Debian "stable". It was humiliating at best. Countless hour were wasted trying to get around bugs in prehistoric packages, or building new (and working) packages from scratch. Never again.

gog 11y ago
Debian Jessie just came out 2 months ago and as far as I can tell the packages in it are pretty recent. Were you targeting Wheezy?
- olgeni 11y ago
  Yes - in the beginning. If you look here https://github.com/erlang/otp/releases https://github.com/erlang/otp/releases you'll see that - even on Jessie - 17.1 is unfortunately way behind.
  - gog 11y ago
    Jessie is using 17.3.4 (if I am reading the version correctly), see https://packages.debian.org/jessie/erlang https://packages.debian.org/jessie/erlang 17.3.4 was released on 4th of November 2014, according to the link you provided. Jessie "freeze" happened on 5th of November ( https://lists.debian.org/debian-devel-announce/2014/11/msg00003.html https://lists.debian.org/debian-devel-announce/2014/11/msg00... ), so I even wonder that they are shipping that version. In my opinion that is not "way behind". If you need bleeding edge you should move to unstable or testing releases, move to a rolling release distribution like Arch or build your own.
    - stephenr 11y ago
      I tried to work this out as well. It is indeed using 17.3.x but its hard to nail down which point release, as the Debian changelog doesn't mention when they pull a new upstream version (vs fixing an issue in the package itself) I figured I would just install the package and use a -v or --version arg to get the exact build version. I cannot find any way to get a patch version out of Erlang. The `OTP_VERSION` file simply says 17.3, and the most I can get from `erl` or `erlc` is "17".

nvarsj 11y ago

Using Debian isn't a panacea. Neither is any particular distribution. Anecdotally, the only personal server I've had hacked was running Debian - due to it using an old openssh version (the issue was not present in later versions). It was fixed quickly, but I got 0dayed.

stephenr 11y ago
The only server's I've seen (and subsequently replaced, with Debian) breached were old CentOS boxes. The key thing here is not "Debian is bad" or "CentOS is bad" it's that you need to keep up to date with security patches. For Debian that usually means a combination of using the Security Apt repo, and for things like OpenSSH, using the Backports Apt repo. I do agree that Debian isn't a silver bullet, but in my experience it's much easier to work with from a setup/management point of view than CentOS, particularly for small shops that are't heavily invested in a full-blown CM tool - shell scripts and/or Debian config packages [1] can be used to fully provision one server or fifty. [1] http://debathena.mit.edu/config-packages/ http://debathena.mit.edu/config-packages/

HeXetic 11y ago

Am I the only one who finds this style of usually-just-one-sentence-per-paragraph almost completely unreadable on a visual level?

ecesena 11y ago

Please edit title with (2014)

throwaway0189 11y ago

Related to this: Outsourcing your webapp maintenance to Debian https://feeding.cloud.geek.nz/posts/outsourcing-webapp-maintenance-to-debian/ https://feeding.cloud.geek.nz/posts/outsourcing-webapp-maint...