Soylent-www
Basic Information
Web front ends for SoylentNews are the servers hydrogen (198.58.127.22) and fluorine (198.58.127.45). They are load balance using a Linode NodeBalancer that is also the https endpoint for the ssl connections. The NodeBalancer's address is 198.58.121.23. The two web front ends are balanced by a third server boron (173.255.194.21) which runs the slashd daemon.
The three server are connected via a gluster file share of the /srv/soylentnews.org. This allows all three to share a live local version of the same directory. This allows for deployment from one server and having the other two get the files automatically. Also since slashd is continuously updating files, gluster keeps the two front end servers up-to-date. Gluster is preferred over a typical NSF mount as it allows for any two of the server to be turned off and services can be started on the remaining server to keep everything working.
Because gluster is a bit slow on writes with the hardware we have, the Slash logs have now been moved to /srv/soylentnews.logs/. This directory is outside of gluster and thus has fast access to the hard drive. This required a change the logdir var in Slash, and a change to slashd and ipnd init scripts to point to the correct directory to see the pid file.
Services that *should* be running:
- varnish (Cache server for web pages, front ends only)
- httpd (Slash's Apache web server running on port 2600, front ends only)
- slashd (Slash's back end maintenance daemon, running on boron only)
- ipnd (Slash daemon for processing Paypal payments, running on boron only)
- glusterd (daemon that syncs gluster blocks)
- glusterfs (mounts the gluster to appropriate mount point)
- memcached (memory cache for speeding up perl)
Note:
- Only httpd does *not* have an init script, needs to be fired manually via apachectl.
There are several scripts for deployment and maintenance of Slash. They are located in /srv/soylentnews.org/bin/. They are designed to be run as the slash user.
| Slash Scrips | |
|---|---|
|
Name |
Description |
| deploy-production-slash | Deploys Slash from /srv/soylentnews.org/src/slashcode/, then runs reload-all-webfronends. Designed to be run from boron. |
| reload-all-webfrontends | Stops ipnd and slashd, then reloads each web front end. Then starts slashd and ipnd. Designed to be run from boron. |
| reload-webfrontend | Stops httpd, clears memcache, starts httpd, then stops and starts varnish. Run on front end to be restarted. |
| stop-webfrontend | Stops httpd, clears memcache, and stops varnish. Run on front end to be stopped. |
| start-webfrontend | Clears memcamche, starts httpd, and starts varnish. Run on front end to be started. |
Varnish Config
Varnish is a caching reverse proxy that listens on port 80 and proxies traffic to the local apache running on port 2600. It does the magic that transforms the data from the NodeBalancer to get data that Slash needs, specifically transforming the X-Forward-For and X-SSL-On headers so Slash knows what IP address a user is coming from and if they are using SSL.
The varnish config file is /etc/vanish/soylentnews.vcl and is set to use memory for its cache and to use 512 MBi. It is also set to cache only static objects: css, js, gif, jpeg, etc, and specifically passes the login, comments, subscribe, and users pages uncached.
Apache Config
Listening on port 2600, there is a setting in one of the slash includes to get perl to recognize the XFF header stuff. Most of this is manage through Slash, either during the initial install or by setting one of the many Slash vars. Typically this needs no direct editing of the config file.
Slash Config
Most of Slash is configured via vars set in the Admin interface (Backslash) within the main site. There are so many settings it is crazy to list any here. One caveat is that many of the vars will not take immediate unless the Slash is reloaded using the reload-all-webfrontens script. The caches will eventually time out and the var, or other change will be seen by all users. If the change is critical, do a reload, if not just let the caches clear naturally.
Memcache Config
This caches mysql queries so fewer queries have to go back to the db. Config file is in /etc/memcached.conf and is set to use 512 Mbi of memory and to listen on port 11211 on both the loopback address and the ipv4 address of the server.