Linuxin keskitetty hallinta – Final assignment – Lighttpd (userdir enabled) and Varnish with Puppet

Lighttpd and Varnish module with Puppet (Linux)

Course homepage: http://terokarvinen.com/2012/aikataulu-linuxin-keskitetty-hallinta-ict4tn011-3

1) Introduction

This article describes a puppet module which:

  • installs lighttpd and varnish
  • enables userdir for lighttpd
  • configures lighttpd to listen to port 8080
  • configures varnish to listen to port 80

It also creates the directory /public_html and index.html inside /etc/skel, so that added users will be aware of their website capability.

2) Module structure

The module is called “lighty” and it resides in puppet/modules/lighty. It includes the following files:

  • manifests/init.pp
  • templates/lighty.erb
  • templates/main-index.erb
  • templates/user-index.erb
  • templates/varnish.erb

2.1 Module application

To apply to module, we ensure that we’re in the /puppet directory’s parent and use the following command:

sudo puppet apply --modulepath puppet/modules/ -e 'class {"lighty":}'

3) Init.pp

The manifest is fairly self-explanatory. Notes below.

class lighty {

	package { "lighttpd":
		ensure => "installed",
	}

	package { "varnish":
		ensure => "installed",
	}

	file { "/etc/lighttpd/lighttpd.conf":
		ensure => present,
		content => template("lighty/lighty.erb"),
		require => Package["lighttpd"],
		notify => Service["lighttpd"],
	}

	file { "/etc/default/varnish":
		ensure => present,
		content => template("lighty/varnish.erb"),
		require => Package["varnish"],
		notify => Service["varnish"],
	}

	service { "lighttpd":
		ensure => "running",
		require => Package["lighttpd"],
	}

	service { "varnish":
		ensure => "running",
		require => Package["varnish"],
	}

	file { "/etc/skel/public_html":
		ensure => directory,
	}

	file { "/etc/skel/public_html/index.html":
		ensure => present,
		content => template("lighty/user-index.erb"),
		require => File["/etc/skel/public_html"],
	}

	file { "/var/www/index.html":
		ensure => present,
		content => template("lighty/main-index.erb"),
		require => Package["lighttpd"],
		notify => [Service["lighttpd"], Service["varnish"]],
	}

	exec { "userdir":
		notify => Service["lighttpd"],
		command => "/usr/sbin/lighty-enable-mod userdir",
		require => Package["lighttpd"],
	}        
}

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!”.

However, main-index.erb is more interesting. It looks like this:

<doctype html>
<title>Server info</title>
<p>Server info
<p>Running <%= @operatingsystem %> <%= @operatingsystemrelease %> @ <%= @hostname %> (<%= @ipaddress %>)
<p><% if has_variable?('is_virtual') then %>
<%= "This is a " %><%= virtual %><%= " machine." %>
<% end %>

It displays a brief server info page, whose content is provided by facter facts using ruby syntax. <%= @operatingsystem %> will read as “Ubuntu”, for example.

It also has a simple if then -structure. If the variable “is_virtual” exists, it prints a line whose output could say eg. “This is a virtualbox machine” or “This is a physical machine”.

The created index.html will reside in /var/www in the puppet managed system.

5) Test

When everything is in place, we can see whether the module actually does what it’s supposed to do. Let’s start by applying it. I’ve made a bash script out of the aforementioned apply command.

xubuntu@xubuntu:~$ ./lighty.sh 
notice: /Stage[main]/Lighty/Package[lighttpd]/ensure: ensure changed 'purged' to 'present'
notice: /Stage[main]/Lighty/File[/var/www/index.html]/ensure: created
notice: /Stage[main]/Lighty/File[/etc/lighttpd/lighttpd.conf]/content: content changed '{md5}0ef8e76747a5f4ece7161da8e48f1d99' to '{md5}9e96d587d60683ed2efcf5e3bfc40668'
notice: /Stage[main]/Lighty/Package[varnish]/ensure: ensure changed 'purged' to 'present'
notice: /Stage[main]/Lighty/Exec[userdir]/returns: executed successfully
notice: /Stage[main]/Lighty/Service[lighttpd]: Triggered 'refresh' from 3 events
notice: /Stage[main]/Lighty/File[/etc/skel/public_html]/ensure: created
notice: /Stage[main]/Lighty/File[/etc/skel/public_html/index.html]/ensure: created
notice: /Stage[main]/Lighty/File[/etc/default/varnish]/content: content changed '{md5}189f82b61ddefb8fe0f0eb238f6ca239' to '{md5}07602a67180cdb0e7b1e9cbfdcebb961'
notice: /Stage[main]/Lighty/Service[varnish]: Triggered 'refresh' from 2 events
notice: Finished catalog run in 23.45 seconds

Looking good so far. No visible errors. We can now access localhost with a web browser and see whether it displays the main-index.erb server info page:

serverinfo

That one works. Next we need to test whether userdir works, and that user-index.erb gets copied properly. I’ll create a user called “kustaavaasa” and try to access localhost/~kustaavaasa:

userdir

Userdir works as well. These tests mean that the module does what it should, and can be applied without problems.

Sources used

http://awaseroot.wordpress.com/2012/04/30/puppet-module-for-lamp-installation
https://github.com/raphink/puppet-apache-1/blob/master/manifests/userdir.pp
https://groups.google.com/forum/?fromgroups=#!topic/puppet-users/8-BBEmwH1bM

 

Advertisements
Posted in Linuxin keskitetty hallinta ICT4TN011-3 | Leave a comment

Linuxin keskitetty hallinta – Homework 4 – GIT

Homework topic: GIT

Course homepage: http://terokarvinen.com/2012/aikataulu-linuxin-keskitetty-hallinta-ict4tn011-3

Main source for this exercise: http://terokarvinen.com/2012/git-from-offline-to-network

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)

Enviroment

For this exercise, I’ll be using three virtual machines:

“desktop”, running Debian 6.0.7. (192.168.1.107)

“debianserver”, running Debian 6.0.7 (192.168.1.105)

“palvelin”, running Xubuntu 12.10 (192.168.1.220)

debianserver and palvelin have git installed already.

The exercise

A local git repository

Can’t do much without installing git, so let’s start with that:

human@desktop:~$ sudo apt-get update
human@desktop:~$ sudo apt-get install git

Next, a directory for our project, aptly called “myproject”:

human@desktop:~$ mkdir myproject
human@desktop:~$ cd myproject

Now the first actual git command, git init, which will turn our directory into a repository:

human@desktop:~/myproject$ git init
Initialized empty Git repository in /home/human/myproject/.git/

Changes and commits

Let’s create some content. Namely, a file called “todo” whose contents are “expand this file’s contents”

human@desktop:~/myproject$ nano todo
human@desktop:~/myproject$ cat todo
expand this file's contents

Now that we’ve created a mons… a file, we can add it to the repository. For this, we first apply the contents of the directory and then do a commit:

human@desktop:~/myproject$ git add .
human@desktop:~/myproject$ git commit

Git wants a comment to go with the commit. On Debian (at least) it conveniently fires up the text editor nano, like so:

git-commit

Now that we’ve committed the file, let’s modify the todo file a couple of times, and commit the changes:

human@desktop:~/myproject$ nano todo
human@desktop:~/myproject$ cat todo
expand this file's contents
like so

Add and commit (comment “todo expanded”):

human@desktop:~/myproject$ git add .
human@desktop:~/myproject$ git commit

One more time for the people:

human@desktop:~/myproject$ nano todo
human@desktop:~/myproject$ cat todo
expand this file's contents
like so
wacky shenanigans

Add and commit (comment “todo expanded further”):

human@desktop:~/myproject$ git add .
human@desktop:~/myproject$ git commit

Reverting to a previous version

If we deem our changes useless, we can revert our repository to a previous version. First, let’s take a look at what has been done with git log, colour-coded for convenience:

human@desktop:~/myproject$ git log
commit 08c3e13b5c2096c3b8409caf0a9384cc370aad36
Author: human <human@desktop.vnet.local>
Date: Wed Apr 24 06:51:54 2013 -0400
todo expanded further
commit 2b89953ab4ef7552b73f31c01420c16107889e15
Author: human <human@desktop.vnet.local>
Date: Wed Apr 24 06:46:59 2013 -0400
todo expanded
commit 1379f6b29ae442668132f629ef107a5806c05093
Author: human <human@desktop.vnet.local>
Date: Wed Apr 24 06:38:12 2013 -0400
todo created

The earliest commit’s header is 1379f6b29ae442668132f629ef107a5806c05093. We use that with the git reset command to return to that version:

human@desktop:~/myproject$ git reset --hard 1379f6b29ae442668132f629ef107a5806c05093
HEAD is now at 1379f6b todo created

Copy the local repository to a server

Let’s begin by connecting to the other Debian VM with ssh:

human@desktop:~/myproject$ ssh human@192.168.1.105

Where are we?:

human@debianserver:~$ pwd
/home/human

Time to create a bare repository for future use:

human@debianserver:~$ mkdir myproject.git
human@debianserver:~$ cd myproject.git

…and initialize it:

human@debianserver:~/myproject.git$ git init --bare --shared
Initialized empty shared Git repository in /home/human/myproject.git/

We can now exit the ssh session and return to the “desktop” machine:

human@debianserver:~/myproject.git$ exit
logout
Connection to 192.168.1.105 closed.

Now, to sync the repository with the server. We will issue various configuration commands, which I’ll highlight with red text.

human@desktop:~/myproject$ git remote add origin ssh://human@192.168.1.105/home/human/myproject.git
human@desktop:~/myproject$ git push origin master
The authenticity of host '192.168.1.105 (192.168.1.105)' can't be established.
RSA key fingerprint is :::::::::::::::.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.1.105' (RSA) to the list of known hosts.
human@desktop:~/myproject$ git push origin master
human@192.168.1.105's password:
Counting objects: 3, done.
Writing objects: 100% (3/3), 235 bytes, done.
Total 3 (delta 0), reused 0 (delta 0)
To ssh://human@192.168.1.105/home/human/myproject.git
 * [new branch] master -> master

human@desktop:~/myproject$ git branch --set-upstream master origin/master
Branch master set up to track remote branch master from origin.
human@desktop:~/myproject$ git pull
human@192.168.1.105's password:
Already up-to-date.

The repository now resides on the server.

Cloning the repository

This is where the Xubuntu VM steps in. First off, I’ll create a directory for the project. (We’ll later notice that this step wasn’t necessary.):

master@palvelin:~$ mkdir myproject
master@palvelin:~$ cd myproject/

Git clone is the aptly-named command which clones a remote repository:

master@palvelin:~/myproject$ git clone ssh://human@192.168.1.105/home/human/myproject.git
Cloning into 'myproject'...
The authenticity of host '192.168.1.105 (192.168.1.105)' can't be established.
RSA key fingerprint is 81:b7:30:90:2d:56:6c:05:a4:b8:e0:7c:52:48:5d:f2.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.1.105' (RSA) to the list of known hosts.
human@192.168.1.105's password:
remote: Counting objects: 3, done.
remote: Total 3 (delta 0), reused 0 (delta 0)
Receiving objects: 100% (3/3), done.
master@palvelin:~/myproject$ git pull && git push
fatal: Not a git repository (or any of the parent directories): .git
master@palvelin:~/myproject$ ls
myproject
master@palvelin:~/myproject$ cd myproject/
master@palvelin:~/myproject/myproject$ ls
todo
master@palvelin:~/myproject/myproject$ git pull && git push
human@192.168.1.105's password:
Already up-to-date.

The green hightlight shows why I shouldn’t have created the directory manually. The orange highlight shows how I came to this conclusion and made it work.

Testing if syncing between multiple computers is set up properly

We’re still on the Xubuntu machine. Let’s edit todo:

master@palvelin:~/myproject/myproject$ nano todo
master@palvelin:~/myproject/myproject$ cat todo
expand this file's contents
the newest of edits

…and do a commit (comment “final edit”):

master@palvelin:~/myproject/myproject$ git add .
master@palvelin:~/myproject/myproject$ git commit
[master f042432] final edit

This isn’t enough, we have to do a git push (pull is also part of the workflow) to sync the changes with the server:

master@palvelin:~/myproject/myproject$ git push && git pull
human@192.168.1.105's password:
Counting objects: 5, done.
Writing objects: 100% (3/3), 283 bytes, done.
Total 3 (delta 0), reused 0 (delta 0)
To ssh://human@192.168.1.105/home/human/myproject.git
 1379f6b..f042432 master -> master
human@192.168.1.105's password:
Already up-to-date.

Moving on to the “desktop” machine to do a git pull:

human@desktop:~/myproject$ git pull
human@192.168.1.105's password:
remote: Counting objects: 5, done.
remote: Total 3 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.
From ssh://192.168.1.105/home/human/myproject
 1379f6b..f042432 master -> origin/master
Updating 1379f6b..f042432
Fast-forward
 todo | 1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

So, did it really work? We can do git log to find out:

human@desktop:~/myproject$ git log
commit f042432539e1a973a84c347bed27edf2a822d04c
Author: master <master@palvelin.(none)>
Date: Wed Apr 24 14:48:30 2013 +0300
final edit
commit 1379f6b29ae442668132f629ef107a5806c05093
Author: human <human@desktop.vnet.local>
Date: Wed Apr 24 06:38:12 2013 -0400
todo created

Looks like our “final edit” commit made its way to desktop’s repository!

A frontend for git

Now that we’ve been up to what have you in the terminal, it might be a good time to try out a graphical frontend for git. I’ll be using a program called “giggle”:

master@palvelin:~/myproject/myproject$ sudo apt-get install giggle

Since we’re already in the project directory, we can just type “giggle” to launch the program, and it’ll visualize our repository like so:

giggle

Posted in Linuxin keskitetty hallinta ICT4TN011-3 | Leave a comment

Quick steps to enable SSL for your Apache website (Debian squeeze)

Make your site use HTTPS (and force it)

This article assumes you have basic Linux knowledge and have installed Apache2.

Enable SSL

sudo a2enmod ssl
sudo service apache2 restart

Make a directory for the keys

sudo mkdir /etc/apache2/ssl

Create .key and .crt (good for 3 years)

sudo openssl req -x509 -nodes -days 1095 -newkey rsa:2048 -keyout /etc/apache2/ssl/apache.key -out /etc/apache2/ssl/apache.crt

Edit your site (in sites-available)

<VirtualHost *:80>
ServerName your.site.com
Redirect permanent / https://your.site.com/
</VirtualHost>

<VirtualHost *:443>
ServerName your.site.com
# Ye olde normal content
SSLEngine on
SSLCertificateFile /etc/apache2/ssl/apache.crt
SSLCertificateKeyFile /etc/apache2/ssl/apache.key

Restart apache2 again:

sudo service apache2 restart

Bonus: Make a directory on your site require authentication

<Directory /path/to/your/passworded/dir>

# Other options here

AuthType Basic
AuthName "password please"
AuthBasicProvider file
AuthUserFile /home/username/passwordfile
Require valid-user

</Directory>

You’ll want to create the authorization info in the passwordfile:

htpasswd -c /home/username/passwordfile username

After that you can add more users by omitting -c, otherwise it’ll overwrite the file.

Ports

Don’t forget to allow/forward ports 80 and 443

Sources

http://linux.fi/wiki/Apache_ja_HTTPS

Posted in Uncategorized | Leave a comment

Linuxin keskitetty hallinta – Homework 3 – The trifecta (Package/file/service)

Course homepage: http://terokarvinen.com/2012/aikataulu-linux-palvelimena-ict4tn003-7-ict4tn003-kevaalla-2013

Assignment

Create package/file/service modules for apache2 and sshd.

Environment

To keep things fresh, I’ll be using a Debian live CD for the first module and an installed Xubuntu system for the second one.

Debian

The system will be a Virtualbox machine and the CD image is “debian-live-6.0.7-i386-xfce-desktop.iso”. As per the live CD defaults, username is ‘user’ and computer name is ‘debian’.

Xubuntu

The system will be a Virtualbox machine running Xubuntu 12.10. The username is ‘master’ and computer name is ‘palvelin’.

Preparation

Let’s begin by setting a finnish keyboard layout, updating the sources list and installing puppet. /etc/apt/sources.list will include the live CD as a source; we’ll comment that out.

user@debian:~$ setxkbmap fi
user@debian:~$ sudo apt-get update
user@debian:~$ sudo apt-get -y install puppet

Apache module

Directories

The module will be called ‘apache’. Let’s begin by creating the necessary directories. The /templates directory will have content later on.

user@debian:~$ mkdir -p puppet/modules/apache/manifests
user@debian:~$ mkdir -p puppet/modules/apache/templates

Module

Next up is the manifest file which will contain the interesting stuff. It’ll be extended to monitor the service’s configuration file later on:

user@debian:~$ nano puppet/modules/apache/manifests/init.pp

Contents:

class apache {

    package { "apache2":
        ensure => "installed",
    }

    service { "apache2":
        ensure => "running",
        require => Package["apache2"],
    }
}

Time to apply the module:

user@debian:~$ sudo puppet apply --modulepath puppet/modules/ -e 'class {"apache":}'
notice: /Stage[main]/Apache/Package[apache2]/ensure: ensure changed 'purged' to 'present'
user@debian:~$ sudo service apache2 status
Apache2 is running (pid 3744).

The module was succesfully applied. Now that apache2 is installed, we can copy its configuration file to the module’s /templates directory and update the manifest with the file monitoring part:

user@debian:~$ cp /etc/apache2/apache2.conf puppet/modules/apache/templates/apache2.conf

We’ll update it with the added file resource:

class apache {

    package { "apache2":
        ensure => "installed",
    }

    file { "/etc/apache2/apache2.conf":
        content => template("apache/apache2.conf"),
        require => Package["apache2"],
        notify => Service["apache2"],
    }

    service { "apache2":
        ensure => "running",
        require => Package["apache2"],
    }
}

I’ll modify the current apache2.conf with a comment (“# Hello!”) and apply the module again:

user@debian:~$ sudo puppet apply --modulepath puppet/modules/ -e 'class {"apache":}'
notice: /Stage[main]/Apache/File[/etc/apache2/apache2.conf]/content: content changed '{md5}b7c18b87627ce633f4$
notice: /Stage[main]/Apache/Service[apache2]: Triggered 'refresh' from 1 events

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.

Directories

master@palvelin:~$ mkdir -p puppet/modules/sshd/manifests
master@palvelin:~$ mkdir -p puppet/modules/sshd/templates

Contents of puppet/modules/sshd/manifests/init.pp (1)

class sshd {

    package { "openssh-server":
        ensure => "installed",
    }

    service { "ssh":
        ensure => "running",
        require => Package["openssh-server"],
    }
}

Let’s apply it:

master@palvelin:~$ sudo puppet apply --modulepath puppet/modules/ -e 'class {"sshd":}'
warning: Could not retrieve fact fqdn
notice: /Stage[main]/Sshd/Package[openssh-server]/ensure: ensure changed 'purged' to 'present'
notice: Finished catalog run in 13.35 seconds

It took a while to apply, but it seems to have worked. Let’s verify that it did:

master@palvelin:~$ sudo service ssh status
ssh start/running, process 4560

Settings file monitoring

Time to copy sshd’s configuration file to puppet/modules/sshd/templates:

master@palvelin:~$ cp /etc/ssh/sshd_config puppet/modules/sshd/templates/sshd_config

We can now modify init.pp with the file resource, after which it’ll look like this:

class sshd {

    package { "openssh-server":
        ensure => "installed",
    }

    file { "/etc/ssh/sshd_config":
        content => template("sshd/sshd_config"),
        require => Package["openssh-server"],
        notify => Service["ssh"],
    }

    service { "ssh":
        ensure => "running",
        require => Package["openssh-server"],
    }
}

I’ll edit /etc/ssh/sshd_config by adding a comment (“# Moi”) and apply the module again:

master@palvelin:~$ sudo puppet apply --modulepath puppet/modules/ -e 'class {"sshd":}'
warning: Could not retrieve fact fqdn
notice: /Stage[main]/Sshd/File[/etc/ssh/sshd_config]/content: content changed '{md5}2cb2ebf3b385fb81340cc64533c0acbb' to '{md5}8caefdd9e251b7cc1baa37874149a870'
notice: /Stage[main]/Sshd/Service[ssh]: Triggered 'refresh' from 1 events
notice: Finished catalog run in 0.38 seconds

Puppet detected the change and replaced the modified sshd_config with the one from /templates. The module works.

About ensure => “running” on (X)Ubuntu

If your (X)Ubuntu 12.10 isn’t up-to-date, puppet might not be able to deduce whether a service is running. If that’s the case, refer to the handy trick mentioned here:

https://terokarvinen.com/2013/ssh-server-puppet-module-for-ubuntu-12-04

This homework uses GNU GPL 2 or later

Posted in Linuxin keskitetty hallinta ICT4TN011-3 | Leave a comment

Linuxin keskitetty hallinta – Homework 2 – Modules, templates, facter

Course homepage:

http://terokarvinen.com/2012/aikataulu-linuxin-keskitetty-hallinta-ict4tn011-3

This is piece of homework is pretty shoddy as I was taken by surprise by the earlier-than-usual deadline.

Assignment

Study:

http://docs.puppetlabs.com/learning/modules1.html

http://docs.puppetlabs.com/learning/templates.html

http://www.puppetcookbook.com/posts/list-facter-facts.html

and create example modules about each article.

Modules

Basic

Let’s create the necessary directory structure:

master@palvelin:~$ pwd
/home/master
master@palvelin:~$ mkdir -p puppet/modules/filewriter3/manifests

Next up, init.pp:

master@palvelin:~$ nano puppet/modules/filewriter3/manifests/init.pp

It looks like this:

class filewriter3 {
    file { '/home/master/writtenfile3':
        content => "This is just a file created by a module. ",
    }
}

Let’s make a shell script for testing the module:

master@palvelin:~$ nano filewriter3.sh

Which looks like this:

#!/bin/bash
sudo puppet apply --modulepath puppet/modules/ -e 'class {"filewriter3":}'

Time to run it and see if it works:

master@palvelin:~$ ./filewriter3.sh 
warning: Could not retrieve fact fqdn
notice: /Stage[main]/Filewriter3/File[/home/master/writtenfile3]/content: content changed '{md5}0cd8778e05e7ee1012eb94f8d193d0fd' to '{md5}42b89c3ab2551460fdc215029c97b22e'
notice: Finished catalog run in 0.13 seconds
master@palvelin:~$

The catalog run finished. Let’s take a look at the created file:

master@palvelin:~$ cat writtenfile3 
This is just a file created by a module. master@palvelin:~$

Hooray.

Facter

Directory for the module:

master@palvelin:~$ pwd
/home/master
master@palvelin:~$ mkdir -p puppet/modules/filewriter/manifests

Init.pp:

master@palvelin:~$ nano puppet/modules/filewriter/manifests/init.pp
class filewriter {
    file { '/home/master/writtenfile':
        content => "This machine is called ${hostname}. ",
    }
}

Script for running the module:

master@palvelin:~$ nano filewriter.sh

It looks like this:

#!/bin/bash
sudo puppet apply --modulepath puppet/modules/ -e 'class {"filewriter":}'

Let’s test it:

master@palvelin:~$ ./filewriter.sh 
warning: Could not retrieve fact fqdn
notice: /Stage[main]/Filewriter/File[/home/master/writtenfile]/content: content changed '{md5}e50c39d47ada5c42819e6b2b329f4cc5' to '{md5}d3ed13434749c34d0533cbb107f033c2'
notice: Finished catalog run in 0.13 seconds

Does it work?

master@palvelin:~$ cat writtenfile
This machine is called palvelin. master@palvelin:~$

Yes.

Template

Directories for the module. One for the manifest and one for the template:

master@palvelin:~$ pwd
/home/master
master@palvelin:~$ mkdir -p puppet/modules/filewriter2/manifests
master@palvelin:~$ mkdir -p puppet/modules/filewriter2/templates

Templates are .erb files and their syntax is different from that of puppet’s:

master@palvelin:~$ nano puppet/modules/filewriter2/templates/mallisisalto.erb

whose contents are:

This is too much content to write in the manifest, surely.
<%= @muuttuvateksti %>

Now for the manifest:

master@palvelin:~$ nano puppet/modules/filewriter2/manifests/init.pp

whose contents are:

class filewriter2 {
    $muuttuvateksti = "This is from a variable! "
        file { '/home/master/writtenfile2':
           content => template("filewriter2/mallisisalto.erb")
        }
    }

How about a script for trying it out:

master@palvelin:~$ nano filewriter2.sh

It looks like this:

#!/bin/bash
sudo puppet apply --modulepath puppet/modules/ -e 'class {"filewriter2":}'

Testing it out:

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:~$
Posted in Linuxin keskitetty hallinta ICT4TN011-3 | Leave a comment

Linuxin keskitetty hallinta – Homework 1 – Hello Puppet

Course homepage: http://terokarvinen.com/2012/aikataulu-linuxin-keskitetty-hallinta-ict4tn011-3

Updated 4.4.2013 to make use of updated module instructions at http://terokarvinen.com/2013/hello-puppet-revisited-%E2%80%93-on-ubuntu-12-04-lts

Environment

I’ve set up a virtual machine in Virtualbox, running Xubuntu 12.10, for use during the course.

  • The main user is master
  • the computer name is palvelin
  • It has a static internal IP address: 192.168.1.220 
  • ufw is enabled, allowing only TCP traffic to port 80

The host system has an Intel Core 2 Quad processor and 8GB of physical RAM and is running Windows 7 x64.

Assignment

Our first piece of homework consisted of a brief assignment in addition to reading up on Puppet basics:

Write a short puppet program using http://docs.puppetlabs.com/learning/ral.html as reference.

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

He has decided to see into using a simple puppet module to:

  • replace his strange site modifications with a stern reminder
  • install the package ‘nethack-console’ as an alternative

Walkthrough

Building the basic environment

I’ll start with a compact list of the necessary commands for building the aforementioned environment on the virtual machine. These are discussed and demonstrated in-depth in the homework entries for the previous course https://a1100320.wordpress.com/category/linux-palvelimena-ict4tn003-4/:

master@palvelin:~$ sudo apt-get update
master@palvelin:~$ sudo ufw enable
master@palvelin:~$ sudo ufw allow http
master@palvelin:~$ sudo apt-get install apache2
master@palvelin:~$ sudo a2enmod userdir
master@palvelin:~$ sudo service apache2 restart

Index.html for master

Let’s create the default webpage for master:

master@palvelin:~$ mkdir public_html
master@palvelin:~$ nano ./public_html/index.html

whose contents are:

<!doctype html>
<html>
<head>
<title>A puppet placeholder</title>
<meta charset="utf-8" />
</head>
<body>
<h1>I'm a little teapot</h1>
<p>Hear me shout</p>
</body>
</html>

which looks like this in the browser:

teapot

Awful.

Creating a puppet module

The modules’ files will reside in puppet/modules under master’s homedir. For now, we create a file called init.pp for a module called pagefix, like so:

master@palvelin:~$ mkdir -p puppet/modules/pagefix
master@palvelin:~$ nano ./puppet/modules/pagefix/init.pp

whose contents are:

class pagefix {
file { '/home/master/public_html/index.html':
ensure => present,
content => "no."
}
package { 'nethack-console':
ensure => present,
}
}

This essentially makes puppet ensure that master’s index.html exists, and replace its contents with the string “no.” It also installed the game nethack-common from the Ubuntu repositories.

Applying the module

We test the module by puppet apply which will be run as sudo, since it installs a program. It’s followed by the absolute path to the module file, like so:

master@palvelin:~$ sudo puppet apply --modulepath /home/master/puppet/modules/ -e 'class {"pagefix":}'

whose output looks like this:

warning: Could not retrieve fact fqdn
notice: /Stage[main]//Package[nethack-console]/ensure: ensure changed 'purged' to 'present'
notice: /Stage[main]//File[/home/master/public_html/index.html]/content: content changed '{md5}14895bce9da04654396bc6cf2aaeae13' to '{md5}1bfd7f653591e54b5c9c4e428c65f608'
notice: Finished catalog run in 5.55 seconds

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:

no

It certainly did. Let’s try running nethack:

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.

Posted in Linuxin keskitetty hallinta ICT4TN011-3 | Leave a comment

add database like phpmyadmin does

create user and database erkkiwp

CREATE USER 'erkkiwp'@'localhost' IDENTIFIED BY '***';

GRANT USAGE ON * . * TO 'erkkiwp'@'localhost' IDENTIFIED BY '***' WITH MAX_QUERIES_PER_HOUR 0 MAX_CONNECTIONS_PER_HOUR 0 MAX_UPDATES_PER_HOUR 0 MAX_USER_CONNECTIONS 0 ;

CREATE DATABASE IF NOT EXISTS `erkkiwp` ;

GRANT ALL PRIVILEGES ON `erkkiwp` . * TO 'erkkiwp'@'localhost';
Posted in Linux palvelimena ICT4TN003-4 | Leave a comment