• We value your experience with Plesk during 2024
    Plesk strives to perform even better in 2025. To help us improve further, please answer a few questions about your experience with Plesk Obsidian 2024.
    Please take this short survey:

    https://pt-research.typeform.com/to/AmZvSXkx
  • The Horde webmail has been deprecated. Its complete removal is scheduled for April 2025. For details and recommended actions, see the Feature and Deprecation Plan.
  • We’re working on enhancing the Monitoring feature in Plesk, and we could really use your expertise! If you’re open to sharing your experiences with server and website monitoring or providing feedback, we’d love to have a one-hour online meeting with you.

Ruby Support

N

nshb

Guest
I want to see Ruby, more specifically Ruby on Rails support with Plesk.
 
I would really like to see Plesk support Ruby on Rails.




Andrew
 
you guys should do a search on the linux forums here, we already discussed a way to install ruby. it's a bit painful but it works.

and I can see why SWS doesn't yet support it - too little momentum to gain...
 
Too little at the moment, but looks like Rails must have hired a Public Relations person, I've recently seen several online publications as well as some of my local newspapers tech sections promoting the use of Ruby....

Wow, yet another package for me to add to my 'to-do' list.... ;)
 
No Momentum????

If you think Ruby and even Rails doesn't have momentum, then I think you need to check again :)

Rails has spun off more replica environments than I can shake a stick at. There's PHP, Java, Python, Perl, and well.. that's pretty much the other top 4 lanauges out there, I haven't run across a .Net implementation yet, but I am sure there is one as well.

Ruby on Rails is going to be a key stone to deploying my customers applications hence forth, and I need a solution to accomodate that. Hopefully Plesk will pick up its socks and step up to the challenge, I know others are getting ready to.
 
it has momentum, but not enough (yet) to warrant that the devs look into it, I think.

besides, mod_ruby doesn't work all that well...
 
use fastcgi, not mod_ruby

I have deployed the fastcgi version quite successfully.

These are the simple steps I took.

After fcgi, ruby, gems then rails was installed, I simply create a new subdomain in my case right now, run these commands:

cd /home/httpd/vhosts/example.com/subdomain/ruby/
rails rails-project
vi conf/vhost.include

add the line:
DocumentRoot /home/httpd/vhosts/example.com/subdomains/ruby/rails-project/public

Modify the .htaccess file to use the .fcgi extension instead of the default cgi extension. And presto, rails is installed.

The major problem with this case study is that when doing any modification to the Rails database.yml file, I need to restart the entire web server. This is a pain, to put it bluntly. All clients suffer for this lack of support.

What would be ideal is this. Each client gets there own sandbox instance of lighttpd with fcgi installed and configured. The apache2 vhost.conf uses the proxy tools it has natively with Plesk and ports through to whatever port is configured within the lighttpd configuration. Although each client would need its own local port for this to work well, this will still be a much more practical solution when it comes time for modifying things such as the database.yml file.

At this point, a start/restart/stop tool would need to be provided to each client to be able to manage their own lighttpd installation.

In addition, the rails-project directory needs to be owned by the ftpuser:psaserv user/group, otherwise FTP will not work. In my case I need to install Rails by hand for each client.

Rails is completely geared towards lighttpd, so support within Plesk should have this, but it is not required.

I am positive cPanel will be coming out with this feature within the next month or so, and I would be interested at adopting it if Plesk shows no immediate interest in looking at such a challenge.
 
I asked a friend at SWsoft about this several weeks ago, I'll ask again as I really think this would be a valuable addition to Plesk.
 
I've implemented Rails on a number of plesk servers. The problem isn't getting it to work, thats the easy part.

If someone want's to develop locally and then upload their rails files to your plesk server then they'll have no problem.

The problem lies in the fact that Rails requires a lot of high level access through SSH to take advantage of all the tools it has. There is no way in Plesk to allow users to access these tools in a chrooted environment unless you want to open yourself up to a major vulnerability.

So basically, Plesk needs to rewrite the way they handle SSH under a chrooted environment to allow users limited access to important system libraries and tools to make Rails work correctly. The fact is, this would take a LOT of work, so I'm sure it's not something they can knock out in the next version.
 
Although I haven't found out where the SSH client is, there is just an option within the administration of my Control Panel.

From within each domain, I can see a SSH button which is greyed out.

This would lead me to believe that a chroot'ed environment would be able to be setup, if that option is enabled that would provide each customer with the opportunity to use the scripts in each rails distribution.
 
Originally posted by acidbox
So basically, Plesk needs to rewrite the way they handle SSH under a chrooted environment to allow users limited access to important system libraries and tools to make Rails work correctly. The fact is, this would take a LOT of work, so I'm sure it's not something they can knock out in the next version.

chrooted environments and logins are supported without problems by Plesk in the FreeBSD version.
 
I am wondering if acidbox's comment about 'a LOT of work' means that the admin has to decide which system binaries to copy into the chroot directories of the domain.

On RedHat systems, Plesk creates the dirs /etc, /var, /usr, /bin, /tmp but mostly does not pre-populate them (a few items, yes). As long as the chroot option is selected in the domain setup, and the admin decides what binaries will be needed, then copies those into the domain dirs, then the chroot works fine, although we have not tested with Ruby

NSHB - If you check the domain setup option "Shell access to server with FTP user's credentials", please verify that it is set for "/bin/bash (chrooted)" and then the SSH button should not be greyed out.
 
Originally posted by ShadowMan
I am wondering if acidbox's comment about 'a LOT of work' means that the admin has to decide which system binaries to copy into the chroot directories of the domain.

On RedHat systems, Plesk creates the dirs /etc, /var, /usr, /bin, /tmp but mostly does not pre-populate them (a few items, yes). As long as the chroot option is selected in the domain setup, and the admin decides what binaries will be needed, then copies those into the domain dirs, then the chroot works fine, although we have not tested with Ruby

NSHB - If you check the domain setup option "Shell access to server with FTP user's credentials", please verify that it is set for "/bin/bash (chrooted)" and then the SSH button should not be greyed out.

For instance, try copying the libraries over to a chrooted environment and the scaffolding with Rails. You will get a mysql error. Why? Because Rails uses a direct connection to the db to scaffold.

Even hardlinking the mysql.sock file wont work (although it does work for python).

You are on the right path though. I just have a .sh script that runs every time a new domain is created and copies all the libraries to the local environment.
 
Back
Top