[Mageia-webteam] Initial hosting requirements for maintainers db

Wed Jan 12 11:10:15 CET 2011

On 12 January 2011 09:36, Romain d'Alverny <rdalverny at gmail.com> wrote:
+> On Wed, Jan 12, 2011 at 02:36, Michael Scherer <misc at zarb.org> wrote:
+>> Le mardi 11 janvier 2011 à 23:07 +0000, Kosmas Chatzimichalis a écrit :
+>>> The initial requirements for installing the maintainers db in the
+>>> mageia server are: [...]
+>>> 1. RVM (Ruby version manager)
+>>
+>> From what I know, that would likely mean compiling our own ruby version
+>> on the server, using its own separate set of gems. In term of work, it
+>> would like adding a specific chroot, or a special vm of a different
+>> distribution just to host the application. ( different distribution
+>> since that would be totally unintegrated with the rest of the servers )
+>
+> What's the possible alternative?
+>
+By using RVM, we won't need a chroot environment for gem installation
+as installation can be done in a user's account.
+Consequent gem installations don't need sudo permission and are
+installed on user's account.
+Some information about the installation is here:
+
+http://rvm.beginrescueend.com/rvm/install/
+
+I also believe that the actual ruby installation is handled by the rvm.
+
+Alternatively, the ruby version needed is either 1.8.7 or 1.9.2, but
+that will actually depend on the rails version used.
+
+
+
+>>> 2. Rubygems (1.3.7)
+>>> 3. Rails (3.0.3)
+>>
+>> [...] This would mean for the moment rails 2.3.10
+>> and ruby-RubyGems 1.3.5.
+>
+> Kosmas, can you backport your app to these versions?
+>
+Can definitely try Romain.
+
+Just as a note dreamhost updated all their servers to 3.0.3 and
+RubyGems 1.3..6 in a matter of few weeks, and although I don't know if
+they had problems, I'm sure that they are security conscious about
+their servers as well.
+
+>> Moreover, using distribution rpm give everybody the same set of module
+>> to work with, if the need to host/develop multiple rails applications
+>> arise ( and I think we cannot exclude this possibility ) without having
+>> to have 1 set of gems per application. And again, we will not need to
+>> handle security ourself ( or at least, no need to do the hard work as
+>> this is the goal of the security team ).
+>
+> What about seeing with ruby packagers about this? (Kosmas?)
+
+I can see about that Romain, but using Rails 3 makes gem installation
+and dependency solving much easier.
+Any suggestion about who I should be contacting?
+
+>
+>>> 5. Passenger (Apache mod_rails)
+>>
+>> As I told in my answer on the git topic, could we avoid using passenger,
+>> and switch to fastcgi ?
+>
+> Kosmas, can you check this?
+
+Yes, this one shouldn't be a problem as I don't have to deal with the
+server setup, although having used fastcgi in the past, I can remember
+having issues with loading of the application and sometimes not
+responding.
+But if Michael is willing to look after that it shouldn't be a problem.
+
+Kosmas
+