First and foremost, the module ensures that lighttpd and varnish’s packages are installed, and that their services are running.

After all that is done, it copies the lighty.erb file from lighty/templates into /etc/lighttpd/lighttpd.conf. (Note: this is generally not best practice; you should work with conf.d instead) and does a similar thing with varnish’s configuration file. (Note the “require => Package[“lighttpd”]. It makes sure that lighttpd is installed before copying the file.)

The configuration files are default, except that lighttpd is set to listen to port 8080 and varnish to 80.

Also worth noting is that lighttpd’s userdir module is enabled with an exec resource. It is a viable choice in this case, since it doesn’t break anything if run multiple times. After the “/usr/sbin/lighty-enable-mod userdir” command has been executed, puppet notifies the lighttpd service which will then reload itself to reflect the changes.

4) Templates

The user-index.erb file is just a small html5 compliant webpage that says “Hi!”.

Assignment

-Make a local git repository
-Make multiple nonsensical commits and return your repository to an earlier point with git reset
-Copy your local repository to a server
-Clone your repository to another system and test that changes are synchronized successfully
-Try a git frontend (e.g. giggle)

We can see that puppet noticed the change, and replaced the modified apache2.conf with the one from /templates. Thus, we can conclude that the module works.

Summary

We created a puppet module which ensures that the apache2 web server is installed, running and that its configuration file apache2.conf matches the one in the module’s /templates directory.

SSHD module

For this one I’ll be using the Xubuntu VM from the previous homework assignment. I’ve restored an earlier snapshot, so we’ll be updating sources.list and installing puppet again. The commands are identical to the ones in the previous Debian module, so I’ll omit those.

master@palvelin:~$ ./filewriter2.sh
warning: Could not retrieve fact fqdn
notice: Finished catalog run in 0.11 seconds
master@palvelin:~$ cat writtenfile2
This is too much content to write in the manifest, surely.
This is from a variable!
master@palvelin:~$

Assignment

Scenario

The main user, master, has trouble controlling his webpage editing impulses. The system has the apache2 web server with the userdir mod enabled, which leaves him free to edit /home/master/public_html/index.html

Note the warning about not being able to retrieve fact fqdn. This could supposedly be alleviated by adding 127.0.0.1 something.or.other to the HOSTS file. The check adds an extra 5 seconds or so to the action.

Results

Let’s see if the web page changed:

It certainly did. Let’s try running nethack:

Seems to have installed just fine. Applying the module again wouldn’t modify the system further, as the resources’ desired state is the status quo.

Assignment

Environment

Sources

Everything done in this post is based on our previous class (see course homepage above).

Varnish

Varnish is a very useful reverse proxy, which can greatly improve web server performance. We make Varnish listen to TCP port 80, so that it will serve the requested websites instead of Apache. (Varnish does get them from Apache but greately reduces load.) Pages are essentially served as static websites thanks to this, which makes everything *very* fast.

Installing Varnish

The metapackage ‘varnish’ installs libvarnishapi1 and varnish, which are exactly the things I need.

sudo apt-get install varnish

I need to edit /etc/default/varnish. One of the configurations therein is uncommented by default, which is what I’ll use. DAEMON_OPTS has numerous flags and values. The only one which needs to be changed is -a, since we don’t want varnish to listen to port 6081 but port 80.

sudo nano /etc/default/varnish

See above for the changes. After that, I need to restart varnish.

sudo service varnish restart

Varnish is now set up and WordPress works once more. We’ll get to actual performance tests later, but first…

Firebug

Time to install Firebug, the Firefox addon. I open Firefox and go to Tools -> Add-ons. (Or just press Shift-Ctrl-A). There’s a search field in the upper right corner:

Typing ‘firebug’ finds the addon I’m after.

Once the addon is installed, I go to my WordPress’ “Hello world” post while having Firebug open, and take a look at how fast various parts of the page load.

HTML generally seems to load quite fast:

Images take a bit longer: (Also, what’s 0.gravatar.com?)

AB

Apache Bench is a tool for testing web server performance. It can create huge amounts of traffic, so be sure to try it out on your localhost only, unless you want to appear like you’re attempting to ddos attack a website.

Varnish was consistently faster, but moreso when it comes to PHP. Static pages are rather light to begin with, but still provides a considerable boost in performance.

Best for last: AB meets Varnish meets a WordPress post

I thought it’d be interesting to see a proper, conclusive result, so I tried benchmarking my WordPress’ performance with and without Varnish. I modify /etc/default/varnish and change its listening port, and temporarily switch off Varnish off.

(Changing the listening port might not be necessary, now that I think of it, seeing as it won’t be listening to anything anyway.)

sudo service varnish stop

And modify /etc/apache2/ports.conf to its original state, so that WordPress works normally with port 80, and restart Apache:

sudo service apache2 restart

To clarify: If one doesn’t stop Varnish first, port 80 won’t be available for apache2 to listen.

Assignment

Environment

I’m using Ubuntu 12.04 @ Virtualbox. I loaded an old snapshop in order to emulate a clean installation from a live CD. (I opted for Virtualbox to get a shared clipboard between Ubuntu and Windows.) Username is ‘antero’ during the whole exercise, seeing as how I didn’t create a separate user for WordPress.

Prerequisite steps

Time to install LAMP. Install apache2 (with mods userdir, php5 and rewrite), mysql-server and php5 and phpmyadmin. For this week’s report, I’m going to omit the usual installation logs for better readability, and concentrate on essential steps. Also, I decided to drop the “let’s/we” narrative. Also, I enable ufw before installing any servers.

Time to log in to phpmyadmin with root and the password given during install. Then, Privileges -> Add new user. I enter the information shown in the following screenshot, and make sure that “Create database with same name and grant all privileges” is checked. After clicking “Create user” I close phpmyadmin.

Provided I haven’t made a mistake somewhere, I should be all set for installing WordPress.

Installing WordPress

I extract the downloaded file with the built-in archive manager, File Roller, in the graphical file manager. It extracts to public_html/wordpress, which I deem satisfactory. If I recall correctly, the tar.gz includes proper permissions, so I won’t have to modify those. We’ll see.

I’ll be creating their DocumentRoots to /home/antero/banshee, haunter and marrow. However, if we want php to work there, we’ll need to comment out some lines in /etc/apache2/mods-available/php5.conf, after which it’ll look like this:

I’ll create an index.html (which might later be renamed to index.php) into each directory, with the site’s name as the content. Then we’ll create the sites’ files in /etc/apache2/sites-available. Result:

HTTP Status codes

Let’s see if we can generate the called-for errors 200, 403, 404 and 500. We just did 404, so that leaves 200, 403 and 500. Let’s wikipedia up what those status codes mean:

200 OKStandard response for successful HTTP requests. The actual response will depend on the request method used. In a GET request, the response will contain an entity corresponding to the requested resource. In a POST request the response will contain an entity describing or containing the result of the action

403 ForbiddenThe request was a valid request, but the server is refusing to respond to it.[2] Unlike a 401 Unauthorized response, authenticating will make no difference.[2] On servers where authentication is required, this commonly means that the provided credentials were successfully authenticated but that the credentials still do not grant the client permission to access the resource (e.g. a recognized user attempting to access restricted content).

500 Internal Server ErrorA generic error message, given when no more specific message is suitable.

The line tells the host, port and ip, time of access, method (GET), status code, browser info and OS info. That’s another one down. 403 and 500 remain. Let’s see if we get 403 if we remove all permissions for marrow’s index.html, restart apache2 (and empty Firefox’s cache):

Yes. That leaves us with code 500. Code 500 seems to be more of a “something’s wrong” type of error code. So, let’s break something. How about inserting a mishmash of garbled data into haunt.er’s .htaccess file? Source: http://httpstatus500.com/