This write up is something that I've been looking for. Some folks at the local Rails meetups have also told me about Dokku, which facilitates deployment for sure, but I'm left wondering what the ramifications/disadvantages of an automated process (like Dokku and I guess Heroku) vs a "proper" setup like this one described.
I can attest that the ruby-build project is a huge lifesaver. If you need to build an experimental ruby, it's the way to go. You can install it completely out of the system path. I really appreciate the effort that was put into it because it probably saved me about a week of work.
I never knew about CheckInstall: a utility that tracks all the files modified during "make install" and creates a Debian package for them. That's just great! Bonus: you can then use the package it creates to install on other machines. https://help.ubuntu.com/community/CheckInstall
Rather than installing Ruby 2.1 from source using rbenv, it is also possible to install Ruby 2.1 using APT, by using the Brightbox PPA: https://launchpad.net/~brightbox/+archive/ruby-ng
The Phusion Passenger APT packages are compatible with the Brightbox Ruby packages.
This. I'm so grateful to Brightbox for having relieved me from the rvm/rbenv madness. Same painless packages on both development and production. Priceless.
Bad firewalling advice imo. Use ubuntu's ufw. Admittedl, ufw feels more difficult if you already know iptables, but it's way more robust than the example given there.
Choose OpenBSD for your Unix needs. OpenBSD -- the world's simplest and most secure Unix-like OS. The world's most used SSH implementation OpenSSH, the world's most elegant firewall PF, the world's most elegant mail server OpenSMTPD. OpenBSD -- the cleanest kernel, the cleanest userland and the cleanest configuration syntax.
With Linux, it's lot of beating around the bush. Overcomplicated config files, a lot of disabling and removing of things one don't need, having to deal with a messy and outdated firewall. With OpenBSD, I'd just have to change a few config file lines and lo and behold have one of the most secure and well-thought out servers the world has ever seen.
Also, with the existence of Puma, I don't see why anybody would want to use Passenger.
At least with Linux I don't have to wait 6 hours for all my software to finish compiling. Think about all the trees that are unnecessarily cut down because of all that compiling. And support for Linux is much easier to get than support for OpenBSD.
TLDR: Passenger takes a more holistic and integrated approach and is a lot easier to use. It has superior management and administration tools, superior robustness features, superior security features (e.g. sandboxing through user switching), better documentation, uses less memory, etc.
OpenBSD doesn't require compiling, it has precompiled packages just like Linux.
Yes, support for Linux is much more wide-spread, but that's due to marketing and not the quality of the OSes themselves.
As for Passenger vs Puma, no management and administration tool is more superior than the Unix commandline. Plus, you don't need fancy sandboxing features assuming your OS user account is properly secured in the first place.
You mention superior this and that, but I find it all hard to swallow as I know you guys go around spamming Puma-related articles and tutorials with stuff about Passenger.
OpenBSD only has a small number of precompiled packages, and usually extremely outdated. If you want to get anything useful you have to compile ports. As for the question of whether Linux being widespread is due to marketing or quality: that is completely irrelevant. The fact that Linux is more widespread is all that matters. We don't live in a theoretical world where only theoretical technical superiority is the only thing that matters.
You are right, no management and administration tool is more superior than the Unix command line. The thing is, Puma's Unix command line tooling is almost nonexistant. All of Passenger's management and administration tools are command line tools.
You are also correct in that you don't need fancy software to do things for you when you can do all that stuff yourself. It's a bit like saying that Docker has no added value because you can setup LXC yourself. But it's not hard to imagine why so many people do find value in Docker.
As for spam: yes you are right, there have been times in the past when we were overly eager with promotion. I apologize for that, and we've since adjusted our strategy.
Having said that, our claims have always only been based on facts. For example: how do I find out what requests my Puma processes are currently handling, and how long they've been active? Where are the tools to query that information?
>OpenBSD only has a small number of precompiled packages, and usually extremely outdated. If you want to get anything useful you have to compile ports
You have absolutely no clue what you are talking about. Compiling from ports gets you exactly the same packages that are on the ftp server. Maybe try it sometime instead of just assuming it is like your experience misunderstanding freebsd once 8 years ago.
You have probably never even tried OpenBSD or you wouldn't even be saying this. You are saying factually incorrect things about OpenBSD, in fact blatantly false libelous lies. OpenBSD has a huge number of precompiled packages, the needs of the average user are probably covered with the available packages. The only thing I miss in OpenBSD is VirtualBox and the Android SDK other than that every other piece of software I used in Linux is available as a package. I can do the same things in OpenBSD as I can in Linux, music, videos, Libre Office, web browsing, programming, etc. Software is not extremely outdated, some packages do get a little outdated from release to release, this is barely noticeable and not a huge issue.
In fact I have multiple OpenBSD and FreeBSD virtual machines installed. I run them regularly to test software. But my OpenBSD installs are from several years ago so maybe things have changed nowadays. However, on FreeBSD 9, all the stuff I can get from pkg_add is old. I always end up having to compile from ports. Years ago I had a FreeBSD 6 server. Ports updates always ended up breaking things (in addition to taking forever to compile) so I switched away from FreeBSD at some point.
I'm not saying that there are no software for OpenBSD. I'm not saying that OpenBSD is not capable of running lots of stuff. I'm saying that for anything recent, you often end up having to compile software from source, which wastes CPU. I'm saying that if things go wrong then finding someone who can provide support is much harder than with Linux.
> I'm saying that for anything recent, you often end up having to compile software from source...
With regards to OpenBSD, your statement is factually incorrect. Most packages are up to date with OpenBSD. FreeBSD is not OpenBSD. Users of OpenBSD are discouaraged from compiling direclty from ports unless they have a good reason (and 99% of the time there is not a good reason.)
I have no experience with ruby / passenger / puma etc, but what you say about OpenBSD is wrong.
From the OpenBSD FAQ[1]:
"As mentioned in the introduction, packages are compiled from the ports tree. In this section we will explain how the ports tree works, when you should use it and how you can use it. "
The 'extremely outdated' part is also wrong. See ajacoutot@ answer on openbsd-misc[2]:
"
=> on -current (soon to be 5.5) you end up with the same GNOME version (and assorted \
dependencies) as with the latest Fedora.
That's a great guide! We realized that a lot of people were spending a lot of time on stuff like this, and that's why we built Cloud 66. We help you to deploy and manage your applications on any cloud (ie. DigitalOcean, AWS, Rackspace etc) - feel free to check us out http://cloud66.com
27 comments
[ 2.7 ms ] story [ 78.4 ms ] threadAlso, http://puma.io/.
Also, with the existence of Puma, I don't see why anybody would want to use Passenger.
Also, this is why anybody would want to use Passenger over Puma: https://github.com/phusion/passenger/wiki/Puma-vs-Phusion-Pa... (or vice versa, for that matter)
TLDR: Passenger takes a more holistic and integrated approach and is a lot easier to use. It has superior management and administration tools, superior robustness features, superior security features (e.g. sandboxing through user switching), better documentation, uses less memory, etc.
Yes, support for Linux is much more wide-spread, but that's due to marketing and not the quality of the OSes themselves.
As for Passenger vs Puma, no management and administration tool is more superior than the Unix commandline. Plus, you don't need fancy sandboxing features assuming your OS user account is properly secured in the first place.
You mention superior this and that, but I find it all hard to swallow as I know you guys go around spamming Puma-related articles and tutorials with stuff about Passenger.
You are right, no management and administration tool is more superior than the Unix command line. The thing is, Puma's Unix command line tooling is almost nonexistant. All of Passenger's management and administration tools are command line tools.
You are also correct in that you don't need fancy software to do things for you when you can do all that stuff yourself. It's a bit like saying that Docker has no added value because you can setup LXC yourself. But it's not hard to imagine why so many people do find value in Docker.
As for spam: yes you are right, there have been times in the past when we were overly eager with promotion. I apologize for that, and we've since adjusted our strategy.
Having said that, our claims have always only been based on facts. For example: how do I find out what requests my Puma processes are currently handling, and how long they've been active? Where are the tools to query that information?
You have absolutely no clue what you are talking about. Compiling from ports gets you exactly the same packages that are on the ftp server. Maybe try it sometime instead of just assuming it is like your experience misunderstanding freebsd once 8 years ago.
http://www.openbsd.org/
https://stable.mtier.org/
http://openports.se/
I'm not saying that there are no software for OpenBSD. I'm not saying that OpenBSD is not capable of running lots of stuff. I'm saying that for anything recent, you often end up having to compile software from source, which wastes CPU. I'm saying that if things go wrong then finding someone who can provide support is much harder than with Linux.
With regards to OpenBSD, your statement is factually incorrect. Most packages are up to date with OpenBSD. FreeBSD is not OpenBSD. Users of OpenBSD are discouaraged from compiling direclty from ports unless they have a good reason (and 99% of the time there is not a good reason.)
FreeBSD is not OpenBSD. Stop lying and pretending you've tried OpenBSD when you clearly have not and are assuming it is the same as FreeBSD.
From the OpenBSD FAQ[1]:
"As mentioned in the introduction, packages are compiled from the ports tree. In this section we will explain how the ports tree works, when you should use it and how you can use it. "
The 'extremely outdated' part is also wrong. See ajacoutot@ answer on openbsd-misc[2]: " => on -current (soon to be 5.5) you end up with the same GNOME version (and assorted \ dependencies) as with the latest Fedora.
We have the latest version of gnome, cups, gnutls, libgcrypt, ..................... We have KMS with state of the art acceleration on Intel and ATI." [1] http://www.openbsd.org/faq/faq15.html#Ports [2] http://marc.info/?l=openbsd-misc&m=139188821027488&w=2
Which makes me wonder, which is the correct way which lends itself to automation and doesn't depend on AWS/AMI?
Disclaimer: I work for Cloud 66