diff options
| author | Nicolas Vigier <boklm@mageia.org> | 2013-04-14 13:46:12 +0000 |
|---|---|---|
| committer | Nicolas Vigier <boklm@mageia.org> | 2013-04-14 13:46:12 +0000 |
| commit | 1be510f9529cb082f802408b472a77d074b394c0 (patch) | |
| tree | b175f9d5fcb107576dabc768e7bd04d4a3e491a0 /zarb-ml/mageia-webteam/2011-January/000133.html | |
| parent | fa5098cf210b23ab4f419913e28af7b1b07dafb2 (diff) | |
| download | archives-master.tar archives-master.tar.gz archives-master.tar.bz2 archives-master.tar.xz archives-master.zip | |
Diffstat (limited to 'zarb-ml/mageia-webteam/2011-January/000133.html')
| -rw-r--r-- | zarb-ml/mageia-webteam/2011-January/000133.html | 151 |
1 files changed, 151 insertions, 0 deletions
diff --git a/zarb-ml/mageia-webteam/2011-January/000133.html b/zarb-ml/mageia-webteam/2011-January/000133.html new file mode 100644 index 000000000..19b614070 --- /dev/null +++ b/zarb-ml/mageia-webteam/2011-January/000133.html @@ -0,0 +1,151 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> +<HTML> + <HEAD> + <TITLE> [Mageia-webteam] Initial hosting requirements for maintainers db + </TITLE> + <LINK REL="Index" HREF="index.html" > + <LINK REL="made" HREF="mailto:mageia-webteam%40mageia.org?Subject=Re%3A%20%5BMageia-webteam%5D%20Initial%20hosting%20requirements%20for%20maintainers%20db&In-Reply-To=%3C1294796195.32187.210.camel%40akroma.ephaone.org%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="000132.html"> + <LINK REL="Next" HREF="000134.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-webteam] Initial hosting requirements for maintainers db</H1> + <B>Michael Scherer</B> + <A HREF="mailto:mageia-webteam%40mageia.org?Subject=Re%3A%20%5BMageia-webteam%5D%20Initial%20hosting%20requirements%20for%20maintainers%20db&In-Reply-To=%3C1294796195.32187.210.camel%40akroma.ephaone.org%3E" + TITLE="[Mageia-webteam] Initial hosting requirements for maintainers db">misc at zarb.org + </A><BR> + <I>Wed Jan 12 02:36:35 CET 2011</I> + <P><UL> + <LI>Previous message: <A HREF="000132.html">[Mageia-webteam] Initial hosting requirements for maintainers db +</A></li> + <LI>Next message: <A HREF="000134.html">[Mageia-webteam] Initial hosting requirements for maintainers db +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#133">[ date ]</a> + <a href="thread.html#133">[ thread ]</a> + <a href="subject.html#133">[ subject ]</a> + <a href="author.html#133">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>Le mardi 11 janvier 2011 à 23:07 +0000, Kosmas Chatzimichalis a écrit : +><i> The initial requirements for installing the maintainers db in the +</I>><i> mageia server are: +</I> +Again I am sorry to be harsh and quite direct, but the requirements +seems rather "too much". + +I do not think it would be wise for us to host a full environment for +each application based on every coder preference, especially when taking +in account that our main product is a Linux distribution, ie basically a +environnement that serve as a base for running other softwares. + +So bypassing this seems rather odd. I would maybe do it for a business +critical complex application whose fate of my company depend on, but I +do not think this project belong on this category for the moment, nor +that it couldn't be fulfilled by what we offer in the distribution so +far. + +><i> 1. RVM (Ruby version manager) +</I> +><i>From what I know, that would likely mean compiling our own ruby version +</I>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 ) + +I am sorry to say that I do not really see this as a good idea, because +that put the burden of taking care of the environnement on sysadmin +(especially security wise), and totally bypass the collaboration system +that we have setup ( ie puppet + svn + integrated shared hosting ). + +><i> 2. Rubygems (1.3.7) +</I>><i> 3. Rails (3.0.3) +</I> +Again, I would rather use the package given by the distribution used on +the server ( ie a Mandriva 2010.1 for the moment, soon to be upgraded to +the first Mageia release ). This would mean for the moment rails 2.3.10 +and ruby-RubyGems 1.3.5. + +A small minor backport would be of course ok ( ie for rubygems ), but a +full update of the rails stack is likely be more work, especially since +it would requires others updates ( like the various active-* parts ). + +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 ). + +So far, we were perfectly able to do it for every perl web application +we wrote ( be it epoll, mga-mirrors, catdap ), and also for external +applications in python and perl ( sympa, bugzilla, transifex ). + +><i> 4. MySQL or PostgreSQL (if everything else is using it). +</I> +I would strongly support Postgresql, as we do have a server running, and +that everything is using it on the web server so far ( ie, the 5 +database enabled application use it, and wiki should also ). + +Given the fact that the maintainer db is basically a simple CRUD web +application, I doubt that this will change much for you as I do not +expect any advanced mysql features, except the old "autoincrement vs +trigger" trick. But I also hope that modern ORM used nowadays are able +to hide that sort of low level details. + +Again, if there is no other way but to use mysql, we could, but I do not +think this is the case. + +><i> 5. Passenger (Apache mod_rails) +</I> +As I told in my answer on the git topic, could we avoid using passenger, +and switch to fastcgi ? + +Otherwise, the web server will likely suffer of bloat since each process +will bundle perl interpreter + modules (due to bugzilla installation +that requires mod_perl) and a ruby interpreter + modules. And I think we +should avoid this for performance reasons, since processes are reused +between each request by apache ( standard mpm-prefork, as I am not sure +that everything will be thread safe ). + +We also use fastcgi to be able to finely tune application, by deciding +how much server should be started per web application. And so far, every +application we use are able to do it, except bugzilla who requires +mod_perl for the moment. + +I know that rails support it too, and we will take care of using static +mode to avoid the issue of slow startup of the server, problem which is +basically the same for catalyst, who is used on 3 of our applications +( epoll, catdap, mga-mirrors ) at the moment, the same for django, used +for transifex . + +-- +Michael Scherer + +</PRE> + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="000132.html">[Mageia-webteam] Initial hosting requirements for maintainers db +</A></li> + <LI>Next message: <A HREF="000134.html">[Mageia-webteam] Initial hosting requirements for maintainers db +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#133">[ date ]</a> + <a href="thread.html#133">[ thread ]</a> + <a href="subject.html#133">[ subject ]</a> + <a href="author.html#133">[ author ]</a> + </LI> + </UL> + +<hr> +<a href="https://www.mageia.org/mailman/listinfo/mageia-webteam">More information about the Mageia-webteam +mailing list</a><br> +</body></html> |