prodigitalson's questions

My goal is to run ruby applications under different server users with potentially different versions of ruby.

So i would have users that serve as the "hosting account" essentially. Document root/application files will live in their home directory along with ruby version(s) and gemsets managed with RVM. A user will have one or more web apps it needs to run. The virtual hosts for this user's site will point to the document root in the users home dir and webserver will also effectively run as this user:group.

Example layout:

/home/theuser
  /.rvm
  /applications
     /railsapp1
       /public
       [ other rails dirs ]
     /somephpapp (symfony, zf, etc.)
       /public
       [ other framework dirs ]
  /www
    /railsapp1.com (ln -s ../applications/railsapp1/public)
    /somestaticsite.com
    /somephpapp.com (ln -s ../applications/somephpapp/public)

So...

Question 1: I this even possible? I know passenger supports ruby versions and passenger users (i assume the passenger user equiv to specifying the user:group for fcgi, php-fpm, SuExec) at the virtual host level but all the intstuctions im finding seem to install the apache module from a specific RVM user, that seems odd. Or is it just a matter of creating a generic user to install the module from and then doing everything else on a per account basis?

Question 2: Even if this is possible is the correct way to set things up? Whats the best practice here given that:

1. The webserver/application MUST run as a given account's user:group
2. MUST have the ability to run different version of ruby on per application basis
3. Each user MUST be able to run multiple applications
4. Each application MUST be contained under a specific user's home dir
5. The user MUST be sandboxed to his/her homedir (not a sodoer)

(Note: I myself am not a ruby dev/user aside from the odd shell script here or there or using compass/zurb-foundation so Im open to options other than Passenger. Also this server is not intended as a production environment.)

UPDATE:

I never did get this figured out. Instead i ended up jsut using jailkit since there is a ton (though sometimes outdated) documentation on usage. Id still be interested in knowning how to get schroot to work though.

IVe found a ton of documentation on setting up schroot/debootstrap as well as a ton of stuff on jailing sftp and some modest instructions for creating a chrooted shell but i cant find anything on get this all working cohesively. Seems like most tutorials are geared towards creating in isolated build environment which is not what i need.

I have schroot set up with an env at /srv/chroot/systemid. That works well i can initiate a session fine with schroot -c systemid -u somejaileduser.

What i cant seem to get to work properly is chrooting an ssh session. My current configuration looks like this:

Match Group jail
   ChrootDirectory /srv/chroot/systemid
   # other stuff to out law tcpforwarding and what not

This kind of works in that i get a chrooted ssh session, but it dumps me directly in the chroot as the working directory. I think this is because a session is never actually kicked off and so /home never gets bound to /srv/chroot/systemid/home (if do ls /home in the ssh session its empty).

So are the configuration steps im missing here?

I'm aware there are various different ways to do this but I'm not sure that the "best" way would be for my particular situation:

• Each site should have its own user account (site user)
• Virtual Hosts point to a directory within the site user's home dir
• Apache executes each site as the site user's user:group
• CLI commands can be executed on the site as the site user
• Various contractors are responsible for maintaining 1 or more sites, and each contractor should have his own account user account
• Contactors will also have the account information for each site account that they mainatian. They will login in as the site user in order to maintain each site - either with ssh directly to that site account, or by logging into their contractor account and then switching users.

My first thought was using mod_fcgi since i think this is how its typically done on some of the shared server environments Ive used. I googled this set up of course but most of the guides i found were random blog posts. What I would like is something with a little more credibility (like VPS company's howto KB or a distro wiki). This way I can point the admin to it as a general guide which im sure he will adapt to how he has this particular server set up.

EDIT:

Actually, after playing with Timeline some more this is going to be a non issue. The UI is confusing because its not necessarily meant to work with multiple repos, but it does work since each project relies on the normal svn metadata for the reop URL (DUH). I dont know why i was thinking i needed to go to extremes. Ill leave the question open for a bit to ssee if this is even do able, for general reference.

I'm trying to figure out a way to integrate PxelNovel Timeline into my existing workflow because an agency ill be working with will be using it.

The problem is Timeline is based on the idea that there is a single repository which contains multiple projects, so it doesnt support multiple repositories. So what i would like to do is something like this:

Repository A (Timeline):

design-projects/
  project1/
  project2/ 
  ...

Repository B (Project 1):

project1/
  trunk/
  tags/
  branches/
  design/

So what id like to do is set up some kind of post commit hook, or a cron job that copies mirrors design-projects/project1 to project1/design with all the history and what not. Normally something like this would be cause for an svn:external, but i want all the commit info from the Timeline repo to show up in Redmine which an external will not provide.