summaryrefslogtreecommitdiffstats
path: root/zarb-ml/mageia-webteam/2011-January/000159.html
blob: 85611b712607f53df4981b26d10fdfa3ba7a0264 (plain)
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
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
 <HEAD>
   <TITLE> [Mageia-webteam] Forum VM needs
   </TITLE>
   <LINK REL="Index" HREF="index.html" >
   <LINK REL="made" HREF="mailto:mageia-webteam%40mageia.org?Subject=Re%3A%20%5BMageia-webteam%5D%20Forum%20VM%20needs&In-Reply-To=%3CA31E65CCB1B23F49A8B97A3A0947018D01870767%40EXCHANGE2003.ccq.org%3E">
   <META NAME="robots" CONTENT="index,nofollow">
   <META http-equiv="Content-Type" content="text/html; charset=us-ascii">
   <LINK REL="Previous"  HREF="000156.html">
   <LINK REL="Next"  HREF="000147.html">
 </HEAD>
 <BODY BGCOLOR="#ffffff">
   <H1>[Mageia-webteam] Forum VM needs</H1>
    <B>Dubeau, Patrick</B> 
    <A HREF="mailto:mageia-webteam%40mageia.org?Subject=Re%3A%20%5BMageia-webteam%5D%20Forum%20VM%20needs&In-Reply-To=%3CA31E65CCB1B23F49A8B97A3A0947018D01870767%40EXCHANGE2003.ccq.org%3E"
       TITLE="[Mageia-webteam] Forum VM needs">Patrick.Dubeau at ccq.org
       </A><BR>
    <I>Sat Jan 15 19:04:11 CET 2011</I>
    <P><UL>
        <LI>Previous message: <A HREF="000156.html">[Mageia-webteam] Forum VM needs
</A></li>
        <LI>Next message: <A HREF="000147.html">[Mageia-webteam] [Mageia-sysadm] Forum VM needs
</A></li>
         <LI> <B>Messages sorted by:</B> 
              <a href="date.html#159">[ date ]</a>
              <a href="thread.html#159">[ thread ]</a>
              <a href="subject.html#159">[ subject ]</a>
              <a href="author.html#159">[ author ]</a>
         </LI>
       </UL>
    <HR>  
<!--beginarticle-->
<PRE>

----- Message d'origine -----
De : Ma&#226;t [mailto:<A HREF="https://www.mageia.org/mailman/listinfo/mageia-webteam">maat-ml at vilarem.net</A>]
Envoy&#233; : Saturday, January 15, 2011 06:41 AM
&#192; : Mageia Web team discussion list &lt;<A HREF="https://www.mageia.org/mailman/listinfo/mageia-webteam">mageia-webteam at mageia.org</A>&gt;
Objet : Re: [Mageia-webteam] Forum VM needs

Le 13/01/2011 13:29, Michael Scherer a &#233;crit :
&gt;<i> Le mercredi 12 janvier 2011 &#224; 21:27 +0100, Ma&#226;t a &#233;crit :
</I>&gt;&gt;<i> Hi there,
</I>&gt;&gt;<i>
</I>&gt;&gt;<i> As it seems VM creation takes a little bit of time due 
</I>&gt;&gt;<i> to people being under heavy load at work Anne and misc 
</I>&gt;&gt;<i> considered the option of creation the Xen VM on one of 
</I>&gt;&gt;<i> our servers (we could migrate the VM on atalante later)
</I>&gt;<i> The exact technology should not matter much, that's also what puppet is
</I>&gt;<i> made for. Ie, unless we plan to do a migration at the system image
</I>&gt;<i> level, we could simply install the 2nd vm, put puppet, clone the
</I>&gt;<i> computer, migrate the db and ip.
</I>&gt;<i>
</I>&gt;<i> ( not that I do not like xen, but I would prefer something else ).
</I>Well I mentionned Xen because Atalante uses it... but if this is not a
problem for puppet then ok for me :)


&gt;&gt;<i> For that misc asked for Forum needs...
</I>&gt;<i> I think I didn't make myself clear. I wanted information to deploy it
</I>&gt;<i> like where is the git stored ( a url, not &quot;it is on a server&quot; ), who
</I>&gt;<i> will need what access, etc. But the information you gave are also
</I>&gt;<i> important ( and bring lots of question as you can see ).
</I>&gt;<i>
</I>Atm it's stored on Ennael's dedibox :)



&gt;&gt;<i> For the beginning i'll consider that we are going to put everything on the
</I>same machine 
&gt;&gt;<i> (DB and PHP). This is not rally brilliant to virtualize DB servers but i
</I>guess this will 
&gt;&gt;<i> not kill the VM in the first monthes as the tables will not be big.
</I>&gt;<i> AFAIK, using virtio and proper cache, this should not be much a problem.
</I>ok then

&gt;&gt;<i> So phpBB needs a LAMP Stack : Apache + PHP5 + MysSQL5 (it prefers to have
</I>MySQLi extention)
&gt;<i> No specific requirement in term of version, using 2010.1 rpm should be
</I>&gt;<i> ok, I assume ?
</I>indeed

&gt;&gt;<i> And we'll need with php the optional :
</I>&gt;&gt;<i> -- zlib compression (better having it)
</I>&gt;&gt;<i> -- remote ftp support (well... i'm not in favor even if documentation asks
</I>for it)
&gt;<i> We could drop outgoing connexion if needed.
</I>&gt;<i>
</I>&gt;<i> ( yes, php make me paranoid in term of security )
</I>&gt;<i>
</I>quite understandable :o)

&gt;&gt;<i> -- XML support (better having it)
</I>&gt;&gt;<i> -- Image Magick support (better having it)
</I>&gt;<i> php-image-magick. I do think there is a conspiration to make me have a
</I>&gt;<i> stroke. Security research by a friend of mine on ImageMagick do not make
</I>&gt;<i> feel safe to know we will use it, but if this is required, we have no
</I>&gt;<i> choice.
</I>&gt;<i>
</I>&gt;<i> Just to know, what will it be used for ( I assume this will be used to
</I>&gt;<i> resize avatar ) ?
</I>yes
&gt;&gt;<i> -- GD support (same as Image magick)
</I>&gt;<i> Does the forum support suhoshin, or various php hardening measures ?
</I>&gt;<i>
</I>Dunno... but we can check that. phpBB forum's got a few threads of errors
mentionning suhosin but i suspect they did not try very hard

&gt;<i> Did you do various testing with a hardened configuration with dangerous
</I>&gt;<i> call disabled ( mainly remote url access for a start, but i also think
</I>&gt;<i> we can use opendir restriction, etc, etc ).
</I>&gt;<i>
</I>&gt;<i> Does it have non regression testing ( so we can enable stuff and see if
</I>&gt;<i> anything break ? ) ?
</I>&gt;<i>
</I>Testing and integration envs are perfect for that :)


&gt;&gt;<i> For source management git will be used... so we'll need it too :)
</I>&gt;<i> Just git clone ?
</I>&gt;<i> I have a puppet module for this, just need tests before I commit.
</I>&gt;<i>
</I>&gt;<i> For git hosting, again, while I am in favor, there is a few questions to
</I>&gt;<i> answer and prepare it, see my previous mail about what is needed.
</I>&gt;<i>
</I>we need cloning, branch/tag switching and sync with reference repos

&gt;&gt;<i> As forum have often to face bruteforce having Fail2ban would be really
</I>great... 
&gt;&gt;<i> for every open service like ssh 
</I>&gt;<i> On ssh level, and for me, that's a vote in favor of &quot;no&quot;. We use ssh
</I>&gt;<i> keys only for admins, so fail2ban will just cause trouble.
</I>...

&gt;&gt;<i> but also for forums... i'd like to have Fail2ban 
</I>&gt;&gt;<i> parse a file of phpBB failed login to trigger a IP low level ban during a 
</I>&gt;&gt;<i> few hours or more...
</I>&gt;<i> Well, if you give us the configuration, we can see. 
</I>ok

&gt;<i> We can also use the trick that Olivier deployed on d-c to avoid numerous
</I>&gt;<i> connexions from the same IP ( in case someone decide to be smart and do
</I>&gt;<i> simultaneous attempts to log ). 
</I>ok too... i'm curious to see what the trick is :)

&gt;&gt;<i> For forum management we'll need :
</I>&gt;<i> ---- 8&lt;----
</I>&gt;<i> or for those who are not CxO-fluent ( private joke ), who is 'we', in
</I>&gt;<i> term of organisation ( ie, do we need to create a ldap group, etc ) ?
</I>&gt;<i>
</I>We = those who maintain forum at forum admin level (ash and i atm)

For integration and testing we'll prehaps need a little bit more

For production you can keep that for sysadmins i guess (till now i got to be
sysadmin &amp; forum admin so this will need a little bit of tuning to adapt
myself)

&gt;&gt;<i> -- access to sources (read/write)
</I>&gt;<i> I rather keep this automated from git, for security reasons and to avoid
</I>&gt;<i> human errors. I would even add a cron job that does a git diff or
</I>&gt;<i> something similar, to detect if someone uploaded a file manually, or
</I>&gt;<i> touched to it using apache. 
</I>&gt;<i>
</I>&gt;<i> In fact, as a security measure, I think the user that will write the
</I>&gt;<i> source should put it read only for apache. Ie, use a separate system
</I>&gt;<i> user for that.
</I>yup that's wise

but some dirs (avatars upload dir, file upload dir, emoticon uplad dir, cache
dir) will need to be writable for apache...

&gt;&gt;<i> -- access to data zones (avatars and uploaded things) (read/write)
</I>&gt;<i> You mean apache will need it, no ?
</I>indeed... apache will need it in the fist place, but sometimes there can be
need to delete an avatar, resize it, replace it with something not offensive,
make it read only to prevent user re-changing again and again...

&gt;<i> Direct access seems to me a pretty rare event, we can grant access if
</I>&gt;<i> there is a really lots of request, ie if you annoy admin enough to make
</I>&gt;<i> them give it rather than doing themselves.
</I>Well you're right we can tune organisation later... so let's say that
sysadmin will take care of low level tasks on production forum...

&gt;&gt;<i> -- access to accesslogs and errorlogs (read)
</I>&gt;<i> then this should be merged with the webmasters concept that romain
</I>&gt;<i> explained. For now, we didn't setup anything ( we didn't even split log
</I>&gt;<i> file on alamut, even if this should be trivial ).
</I>&gt;<i>
</I>indeed forum admins have obviously tasks that are close to this &quot;webmaster&quot;
concept

&gt;&gt;<i> -- ability to change php log levels
</I>&gt;<i> This can be done by php, I think.
</I>&gt;<i>
</I>if php global config allows it.

&gt;&gt;<i> -- access to php logs (read)
</I>&gt;<i> same as accesslogs
</I>yup

&gt;&gt;<i> -- console access to database(s) (i'd prefer to avoid completely
</I>phpMyadmin on the forum server)
&gt;<i> I would prefer avoid giving console access until there is a real need. I
</I>would favor then a remote 
&gt;<i> mysql access, and forcing ssl, maybe even limited by fixed ip address if
</I>you wish to avoid bruteforce.
&gt;<i>
</I>&gt;<i> ( I will not go to the point of proposing to use a vpn too, but
</I>&gt;<i> almost ).
</I>&gt;<i>
</I>&gt;<i> Maybe we could think of some kind of ssh bastion for such access ( or
</I>&gt;<i> maybe that's overkill too ).
</I>&gt;<i>
</I>well for forum administration i daily use sql CLI because that's loads more
effective than using phpBB SQL interface or uglier things like phpMyadmin :-/

&gt;&gt;<i> For performance questions : i guess forum opening will trigger a rather
</I>vast 
&gt;&gt;<i> amount of people coming (at least to register their nicks)... i'd be happy
</I>to 
&gt;&gt;<i> avoid the server being loaded to death.
</I>&gt;<i> Registration will be done on catdap from what I think we agreed on, no ?
</I>&gt;<i> ( correct me if I am wrong ). 
</I>you are right but once registered they'll go to the forum (in particular if
they came to registration form through a link on the forum)

&gt;<i> So we need to work on that part ( starting more processes, and so
</I>&gt;<i> letting us tune that with puppet ( this is hardcoded now, AFAIK ). So
</I>&gt;<i> depending on where we host the forum, we can surely avoid this effect.
</I>:<i>-/
</I>
&gt;&gt;<i> So i'm targetting at least one thousand simultaneous users being active on
</I>the 
&gt;&gt;<i> forum... that will do for apache tuning.
</I>&gt;<i> Ok so let's say 120 simultaneous process for apache, which also mean we
</I>&gt;<i> need to keep apache process as lean as possible ( ie, no unused module
</I>&gt;<i> loaded ). I assume that there is no guarantee on being thread safe from
</I>&gt;<i> php and associated library, so we will use mpm-prefork. 
</I>&gt;<i>
</I>&gt;<i> Since the server is isolated and serve only for php hosting, I guess
</I>&gt;<i> using fast-cgi will not bring much to the equation, when compared to
</I>&gt;<i> mod_php.
</I>&gt;<i>
</I>&gt;<i> Let's also assume 30 processes for forum registration on catdap ( if I
</I>&gt;<i> am not wrong on that part, of course ) ? We could surely mitigate the
</I>&gt;<i> potential overload by not announcing this on every possible channel at
</I>&gt;<i> the same time ( ie, first a mail, then a blog post, then
</I>&gt;<i> identica/twitter ).
</I>&gt;<i>
</I>&gt;<i> Should we also maybe need to tune ldap ?
</I>well nginx could be an option as Thierry said... dunno if ldap will be loaded
though


&gt;&gt;<i> For database that will mean 800 to 1200 requests per seconds...
</I>&gt;&gt;<i>
</I>&gt;&gt;<i> We'll have 2 - 3 months to see the tables grow and tune the indexes and
</I>the memory accordingly.
&gt;<i> That mean that we will have to deploy some monitoring, and we didn't
</I>&gt;<i> decided anything ( buchan proposed hobbit, I proposed munin, purely by
</I>&gt;<i> familiarity ).
</I>&gt;<i>
</I>That can be done a little bit later :)

&gt;<i> What metrics would you need so we can work on them in priority ( once we
</I>&gt;<i> start to set up something ) ?
</I>&gt;<i>
</I>the ram used by database and by the web server, the number of threads, the
cpu load, and perhaps some data from the database server (cache fill level,
number of locked requests, time taken by long requests - over 1 sec -)...

&gt;&gt;<i> But i think our needs will stabilize around 4-6 GO for RAM if the forum
</I>gets really 
&gt;&gt;<i> used (we'll have to tune mysql to keep many requests in cache)
</I>apache+mysql all 
&gt;&gt;<i> included... if we split later apache and mysql on separate machines the
</I>needs on 
&gt;&gt;<i> each machine will be obviously lower.
</I>&gt;<i> No cache ( squid, varnish ) ?
</I>&gt;<i> No php level cache too ?
</I>&gt;<i>
</I>&gt;<i> ( not that it may be requested now )
</I>we can see that  later indeed :)

&gt;&gt;<i> For app disk space code is under 50 megs... and with hundred of avatars
</I>uploader 
&gt;&gt;<i> we will not grow above 1GO
</I>&gt;&gt;<i>
</I>&gt;&gt;<i> For database disk space even after years of activity we'll remain under
</I>5GO
&gt;<i> Ok so let's allocate a 10 g partition for the db + ssthat on lvm. 
</I>&gt;<i> We should take in account logs, and logs backup ( french law requires 1
</I>&gt;<i> year of logs ). 
</I>&gt;<i>
</I>&gt;<i> How many logs are to be expected per day ?
</I>&gt;<i> The only busy webserver I can think of is d-c, but Nanar and I just
</I>&gt;<i> discovered that the configuration is not good.
</I>&gt;<i> So now, that's 5g of log, uncompressed, per month.
</I>&gt;<i>
</I>it will depend on the success of mageia but that can be rather high


&gt;&gt;<i> We'll need to set up some tables with heavy read and write accesses with
</I>InnoDB (not all) : 
&gt;&gt;<i> that would be great to have one file per table innodb option enabled
</I>&gt;<i> Ok, I guess it should be safe to enable it for all mysql db I guess.
</I>yes

&gt;&gt;<i> Nota : i'd like to use https (at least for admin accesses)... so that will
</I>mean to enable 
&gt;&gt;<i> ssl and open 443 port also
</I>&gt;<i> We did not plan to let people use their password under cleartext at all.
</I>&gt;<i> Centralized auth have been setup ( and should be used for forum too ),
</I>&gt;<i> so people will reuse their password, the same used at others part of the
</I>&gt;<i> infrastructure, and that mean svn, or bugzilla, etc. Since people with
</I>&gt;<i> access will use it, no cleartext at all when the password is sent ( or
</I>&gt;<i> over my dead body, after fighting my ghost ). 
</I>so https for all ? ok for me but that will be a little bit heavier for cpu

&gt;<i> I guess we can make exception for the cookie, as long as it is not
</I>&gt;<i> shared ( ie, we will have to rethink the scheme if we deploy SSO ). 
</I>&gt;<i>
</I>&gt;<i> That also mean that people will complain because of firefox if we do not
</I>&gt;<i> buy a certificate.
</I>&gt;<i>
</I>:<i>-(
</I>
&gt;&gt;<i> That's all for system level... i think directory structures (Which
</I>concerns apache web root config) can be dealt with later...
&gt;&gt;<i>
</I>&gt;&gt;<i> Tell me if you have got everything you need for VM creation...
</I>&gt;<i> What I needed was more information for forum deployment, not vm
</I>&gt;<i> requirements, I guess I didn't express myself clearly. The requirement
</I>&gt;<i> for the vm in term of memory/disk have been roughly drafted before. What
</I>&gt;<i> I would prefer is a deployment document.
</I>&gt;<i>
</I>ash and i are writing one atm

your mail changes some things... so let's adapt it :)

----8&lt;----

(pfeeew... sorry for the length guy)

Ma&#226;t




_______________________________________________
Mageia-webteam mailing list
<A HREF="https://www.mageia.org/mailman/listinfo/mageia-webteam">Mageia-webteam at mageia.org</A>
<A HREF="https://www.mageia.org/mailman/listinfo/mageia-webteam">https://www.mageia.org/mailman/listinfo/mageia-webteam</A>
</PRE>


<!--endarticle-->
    <HR>
    <P><UL>
        <!--threads-->
	<LI>Previous message: <A HREF="000156.html">[Mageia-webteam] Forum VM needs
</A></li>
	<LI>Next message: <A HREF="000147.html">[Mageia-webteam] [Mageia-sysadm] Forum VM needs
</A></li>
         <LI> <B>Messages sorted by:</B> 
              <a href="date.html#159">[ date ]</a>
              <a href="thread.html#159">[ thread ]</a>
              <a href="subject.html#159">[ subject ]</a>
              <a href="author.html#159">[ 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>