1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<TITLE> [Mageia-dev] lighttpd and others now require apache
</TITLE>
<LINK REL="Index" HREF="index.html" >
<LINK REL="made" HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20lighttpd%20and%20others%20now%20require%20apache&In-Reply-To=%3C4F634026.7060201%40mageia.org%3E">
<META NAME="robots" CONTENT="index,nofollow">
<META http-equiv="Content-Type" content="text/html; charset=us-ascii">
<LINK REL="Previous" HREF="013659.html">
<LINK REL="Next" HREF="012835.html">
</HEAD>
<BODY BGCOLOR="#ffffff">
<H1>[Mageia-dev] lighttpd and others now require apache</H1>
<B>Anssi Hannula</B>
<A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20lighttpd%20and%20others%20now%20require%20apache&In-Reply-To=%3C4F634026.7060201%40mageia.org%3E"
TITLE="[Mageia-dev] lighttpd and others now require apache">anssi at mageia.org
</A><BR>
<I>Fri Mar 16 14:29:10 CET 2012</I>
<P><UL>
<LI>Previous message: <A HREF="013659.html">[Mageia-dev] lighttpd and others now require apache
</A></li>
<LI>Next message: <A HREF="012835.html">[Mageia-dev] lighttpd and others now require apache
</A></li>
<LI> <B>Messages sorted by:</B>
<a href="date.html#13167">[ date ]</a>
<a href="thread.html#13167">[ thread ]</a>
<a href="subject.html#13167">[ subject ]</a>
<a href="author.html#13167">[ author ]</a>
</LI>
</UL>
<HR>
<!--beginarticle-->
<PRE>16.03.2012 11:02, Guillaume Rousse kirjoitti:
><i> Le 16/03/2012 03:01, Anssi Hannula a écrit :
</I>>>><i> So I'd rather revert the change, and make lighttpd autonomous also.
</I>>>><i> Unless someone can convince me there is an advantage having lighttpd
</I>>>><i> executing as 'apache' :)
</I>>><i>
</I>>><i> The web applications policy has files being owned by 'apache' user, and
</I>>><i> I don't see how that could work if lighttpd used a different user:
</I>>><i> <A HREF="https://wiki.mageia.org/en/Web_applications_policy">https://wiki.mageia.org/en/Web_applications_policy</A>
</I>><i> This policy was crafted with apache in mind only, not all available web
</I>><i> servers. And its explicitely refers to apache integration, not generic
</I>><i> webserver compatibility. For instance, the configuration file provided
</I>><i> is apache-specific. Even if we have compatible file permissions, and if
</I>><i> we asked packagers to also provide a default lighttpd configuration file
</I>><i> (slighly more work), that would still be mostly theorical compatibility
</I>><i> without actual testing from the packagers (many more work).
</I>><i>
</I>><i> So, rather than a potential compatibility, without documented limits,
</I>><i> should we rather not make clear than adapting our web applications
</I>><i> package to any other web server than apache is fully up to the end user ?
</I>
It is rather easy for the user to create a lighttpd configuration file
themselves etc, however it is much more difficult for the user to start
changing/guessing the needed file permissions for the larger applications.
Also, any changes would be overwritten by any upgrade, which is quite
bad IMO.
(and yes, I do have seen actual users using lighttpd with our webapp
packages)
--
Anssi Hannula
</PRE>
<!--endarticle-->
<HR>
<P><UL>
<!--threads-->
<LI>Previous message: <A HREF="013659.html">[Mageia-dev] lighttpd and others now require apache
</A></li>
<LI>Next message: <A HREF="012835.html">[Mageia-dev] lighttpd and others now require apache
</A></li>
<LI> <B>Messages sorted by:</B>
<a href="date.html#13167">[ date ]</a>
<a href="thread.html#13167">[ thread ]</a>
<a href="subject.html#13167">[ subject ]</a>
<a href="author.html#13167">[ author ]</a>
</LI>
</UL>
<hr>
<a href="https://www.mageia.org/mailman/listinfo/mageia-dev">More information about the Mageia-dev
mailing list</a><br>
</body></html>
|