[web-team] Volunteer

[Josef Grosch]

On 01/28/2015 07:12 PM, Rick Moen wrote:
> Quoting Josef Grosch (jgrosch at gmail.com):
> 
>> My thought on this is to use my existing DNS infrastructure for the
>> domain that way we don't have to use memory and cpu cycles in the VM for
>> running a DNS server.
> 
> I think this is a no-go for SVLUG.  We have...
> 
> root at gruyere:~ # grep 'zone:' /etc/nsd3/nsd.conf | wc -l
> 16
> root at gruyere:~ # 
> 
> ...16 zones for which we do primary nameservice.  Of those....
> 
> root at gruyere:~ # grep primary /etc/nsd3/nsd.conf | wc -l
> 3
> root at gruyere:~ # grep secondary /etc/nsd3/nsd.conf | wc -l
> 13
> root at gruyere:~ # 
> 
> 13 are secondary/slave nameservice, and 3 are primary/master
> nameservice.  SVLUG has found it convenient to have ability to arrange
> nameservice for arbitrary domains on its own nameserver.  The amount of
> bandwidth consumed by this is trivial (as is typical of DNS), and here's
> a snapshot of RAM usage:
> 
> root at gruyere:~ # ps auxw | grep nsd3 | grep -v grep
> nsd       4809  0.0  0.0   5120   784 ?        S     2014   0:22 /usr/sbin/nsd -c /etc/nsd3/nsd.conf
> nsd       4810  0.0  0.0   5488   744 ?        S     2014   2:09 /usr/sbin/nsd -c /etc/nsd3/nsd.conf
> nsd      20994  0.0  0.0  11728  1020 ?        S     2013   1:31 /usr/sbin/nsd -c /etc/nsd3/nsd.conf
> root at gruyere:~ # 
> 
> You're probably thinking of BIND levels of resource consumption, but
> this is NSD:  Total resident set size is probably just over 1MB, given 
> overlapping code routines among the three processes running.


OK, you have given good, logical reasons for NSD on the virtual machine.
Consider the discussion closed, we will go with NSD on the new VM.


>> I'm not a big fan of php, it's a crappy language that looks like it was
>> thrown together, not thought out and all it's bad "features" have become
>> enshrined.
> 
> As I've been saying, my biggest problem with it is the enormous increase
> in attack surface, on any system where the PHP interpreter is used
> inline to produce Web pages.  The extra RAM _was_ an unwelcome surprise
> back when we had 80MB total RAM to play with, but those days are happily
> gone.  
> 
> As you'll see, on www.svlug.org, even after the minor RAM spending spree
> involved in converting to PHP, we're still small potatoes.
> 
> root at gruyere:~ # free
>              total       used       free     shared    buffers     cached
> Mem:       1024884     448288     576596          0     107684     228900
> -/+ buffers/cache:     111704     913180
> Swap:       262140          0     262140
> root at gruyere:~ # 
> 
> Here's total RAM usage on the lists.svlug.org host:
> 
> svlug:~# free
>              total       used       free     shared    buffers     cached
> Mem:        513336     496536      16800          0     111504     237400
> -/+ buffers/cache:     147632     365704
> Swap:      2578128      64056    2514072
> svlug:~# 
> 
> On lists.svlug.org, the biggest RAM-consumer is multiple instances of spamd
> (SpamAssassin in daemon mode).
> 
> svlug:~# ps auxw | grep spamd | grep -v grep
> nobody    5876  0.0  5.4 28544 28200 ?       S    18:05   0:01 /usr/sbin/spamd --username=nobody --max-children 24 --helper-home-dir=/var/spool/spamassassin/ --nouser-config --max-conn-per-child=100 -d --pidfile=/var/spool/spamassassin/spamd.pid
> nobody    5877  0.0  5.7 29688 29424 ?       S    18:05   0:01 spamd child
> nobody    5878  0.0  5.4 28544 28200 ?       S    18:05   0:00 spamd child
> nobody    5879  0.0  5.4 28544 28200 ?       S    18:05   0:00 spamd child
> nobody    5880  0.0  5.4 28544 28200 ?       S    18:05   0:00 spamd child
> nobody    5881  0.0  5.4 28544 28200 ?       S    18:05   0:00 spamd child
> nobody    5882  0.0  5.4 28544 28200 ?       S    18:05   0:00 spamd child
> nobody    5883  0.0  5.4 28544 28200 ?       S    18:05   0:00 spamd child
> nobody    5884  0.0  5.4 28544 28200 ?       S    18:05   0:00 spamd child
> nobody    5885  0.0  5.4 28544 28200 ?       S    18:05   0:00 spamd child
> nobody    5886  0.0  5.4 28544 28200 ?       S    18:05   0:00 spamd child
> nobody    5887  0.0  5.4 28544 28200 ?       S    18:05   0:00 spamd child
> nobody    5888  0.0  5.4 28544 28200 ?       S    18:05   0:00 spamd child
> nobody    5889  0.0  5.4 28544 28200 ?       S    18:05   0:00 spamd child
> nobody    5890  0.0  5.4 28544 28200 ?       S    18:05   0:00 spamd child
> nobody    5891  0.0  5.4 28544 28200 ?       S    18:05   0:00 spamd child
> nobody    5892  0.0  5.4 28544 28200 ?       S    18:05   0:00 spamd child
> nobody    5893  0.0  5.4 28544 28200 ?       S    18:05   0:00 spamd child
> nobody    5894  0.0  5.4 28544 28200 ?       S    18:05   0:00 spamd child
> nobody    5895  0.0  5.4 28544 28200 ?       S    18:05   0:00 spamd child
> nobody    5896  0.0  5.4 28544 28200 ?       S    18:05   0:00 spamd child
> nobody    5897  0.0  5.4 28544 28200 ?       S    18:05   0:00 spamd child
> nobody    5898  0.0  5.4 28544 28200 ?       S    18:05   0:00 spamd child
> nobody    5899  0.0  5.4 28544 28200 ?       S    18:05   0:00 spamd child
> nobody    5900  0.0  5.4 28544 28200 ?       S    18:05   0:00 spamd child
> svlug:~# 

Yes, spamassassin is a memory hog but I would not even think of running
an email server without it. I have tried to use dspam in the past but it
is just too problematic setting up and running.

I agree that php is a huge security hole but the site as it sits uses
php. Re-coding it to be static pages generated out of a scripting
language is more secure but still a project, one that I can help with.
Since you seem to better versed in php security, (don't say that too
loudly, it will come back to haunt you), I'll let you guide us.

I don't think we are in disagreement about anything important. I'm
looking forward to this.



Josef


-- 
Josef Grosch       |  Another day closer  |
jgrosch at gmail.com  |  to Redwood Heaven   |  Berkeley, Ca.