[Mageia-webteam] Initial hosting requirements for maintainers db

[Kosmas Chatzimichalis]

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