[ale] OT: ruby/redmine/apache

[JD]

On 05/09/2012 08:38 AM, mike at trausch.us wrote:
> Virtualenv or RVM is great, and I think that every language should have
> the ease of installation and management that Python at least does with
> virtualenv.  I don't use ruby, so I can't speak to it.

RVM is Ruby's version manager.

PerlBrew is Perl's environment manager - though relatively new, it has taken
over completely. Having 15 different perl environments is trivial.
http://perlbrew.pl/  - the creator of perlbrew left a comment on my blog. It was
nice.

> Though, that said, I remember having to do an awful lot of hokey pokey
> to get my Redmine working.  It hasn't broken since, other than the fact
> that it uses way too much RAM, so I don't remember what voodoo I had to
> do to get it working.  I do remember it was hell, though, and I cannot
> wait until I can get rid of it.

I've played with ruby development. That background helps. Redmine seems about
normal for a RoR app. It wasn't hard to get working under thin + nginx + ssl as
I recall, though it was complex enough I'd never let it share a VM with any
other application.

What I'm reading in these messages are developers and sysadmins arguing over
which way is best to maintain packages. That has been happening since before I
started programming and it will continue.  I've been a developer for 20+ years
and an admin since 1996, so I see both sides.

Developers often don't understand the issues, since many are just happy to have
a working app - until there's a break-in, everything is perfect.  Their app is
only available internally anyway, right?  No app should need root anymore, even
for installation. None. If they do, it is poor design or lazy vendors /
developers.  Let the reverse proxy run on a high port and put the app on some
strange port(s) as needed.

Admins are trained to be paranoid, which is also good, but they often simplify
the dependency requirements or don't understand them.  If I had to maintain 100+
servers, I might not want to deal with problem app-support teams either.
Commercial software often demands really ass-backwards libraries. I've seen some
demand that we run a 2 yr old kernel if we wanted support, in the contract.
Contracts are seldom reviewed by technical people, so after some finance person
signs without understanding all the rules, then IT has little choice.

These days, I find it fortunate that admins will not stop devs from installing
updated tools and packages without admin rights. It is just uses disk storage -
though that's a concern for lots of reasons.

If the 3rd party security scanners aren't constantly updated to check for these
non-OS managed tools, then those are failing and should be corrected.
Conscientious admins will work with their dev teams to ensure timely patches of
non-OS managed tools and libraries.  Actually, the main reasons I use those
other tools is to have quicker access to patches, so we are on the same page as
the admins.

Many more developers do care about security first, but we certainly are not the
rule ... yet. Security is hard.