Teacher's notes

by Gisle Hannemyr

Teacher's notes for preparing the course website and the USIT web host running RHEL7 for the student's at the start of the semester.

Table of contents

Introduction

USIT has set up a set up virtual machines that shall be used as web hosts for the INF5272 project teams. The service (VMWare) is delivered by USIT's Server and Storage Management Group (virt-drift@usit.uio.no). My main contact has been: Safet Amedov. In addition, for Apache support is handled by www-drift@usit.uio.no.

Each web host has the following properties:

I need to install the most of the LAMP-stack:

Since I recycle the macines each year, there is should be a full LAMP-stack i 2019.

The OS and release-track software is kept up to date by USIT/RedHat.

The 14 virtual servers set up by USIT have the host names on the form diwXX.uio.no (where XX is a two digit number between 00 and 13). Each team is given custody of one such server.

Disk use under /var/www (as reported by du -h -s .):

Configuration

The configuration files mention in this chapter are in:

The right place to define and change environment variables is ~/.bash_profile.

Files to copy to each vhost.

Setting up the LAMP stack

The procedure for setting up the LAMP stack is in the chapter for students. Links:

Course web

Checklist for a new semester:

Project groups

Permission to edit the group profile page is handled by Content Access, using "Role based access control settings".

Checklist for a new year:

Students are assigned membership in a group by being listed in the field "Medlemmer". The "Student-galleri" view get access to this through a contextual filter and a relation. Only groups with members appear on the "Student-galleri" page. The "Gruppeoversikt" need to show groups that are used for master projects to keep nunbers right.

Prepare the vhost for students

If the user students do not exist on the vhost, create it:

# useradd students
# passwd students
# cd /etc/httpd/conf
# chgrp students httpd.conf
# chmod g+w httpd.conf
# cd /var/www
# chgrp -R students .
# chmod -R g+w .
# cd /usr/share/drush
# chgrp students .
# chmod g+w .

To use sudo, you need to authenticate using the UiO password.

Adding and removing users from vhost

First remove users that shall not have access any more from groups. One of the following commands in the directory /etc will show current membership:

$ grep -e wheel -e students group
$ egrep "wheel|students" group

The following will make the user “petter” member of no group.

# usermod -G "" petter

Then to prevent login, remove the user's entry from /etc/passwd by editing the file (userdel -r?).

After removing the user from the login, you may also want to remove the user's directory under /home.

The following directories under /home should not be removed:

oracle
students
virtmgmt

To add a user to a vhost, edit the file /etc/passwd by adding the user's Ifi username prefixed by the character +. Verify that the username is a valid Ifi username, and is associated with the correct person.

Here is an excerpt from this file, where three users, named “gisle”, “idabraa” and “petter” has been added:

root:x:0:0:root:/root:/bin/bash
  :
mysql:x:27:27:MySQL Server:/var/lib/mysql:/bin/bash
+gisle
+idabraa
+petter

Users that shall have sudo privileges must be placed in wheel. The following command will add the user “petter” as a member of this group, and also add him to the group students.

# usermod -a -G wheel,students petter

Note that this command will fail if the username is not a valid Ifi username.

Important files

The file with all users:

You need to edit /etc/passwd to add and remove users.

The following two files should not bed edited directly:

File names ending with a dash (-) or tilde (~) are just backups created when these are edited by useradd, groupadd (dash) or emacs (tilde).

CFEngine

USIT uses CFEngine to monitor and manage the servers they supply. The default policy is for a user to have a single home directory across all UiO servers.

To have local home directories, USIT must add the role homedir_override for these servers.

SELinux

The USIT RHEL7 hosts are running SELinux (Security-Enhanced Linux) that provides more fine-grained access controls for Gnu/Linux. You may see the current mode of enforcement using one of these commands:

$ sestatus
$ sestatus | grep mode

To toggle the mode from enforcing to permissive and back again, use:

# setenforce 0
# setenforce 1

If you encounter permission denied problems that cannot be explained by Gnu/Linux mode bits, SELinux is the main suspect. You may verify that SELinux is responsible by toggling enforcement to permissive and see if that setting gives access.

Some of the permissions managed by SELunux are controlled by boolean flags. To see all available booleans on your system which can be changed by you, use one of these commands:

$ getsebool -a
$ semanage boolean -l

See alsoTypical permission problems caused by SELinux are files not being written or read though the web server has permissions; communications operations such as sending mail or attempting XMLRPC operations failing, although firewall permissions are OK, etc. There is a user contributed document at Drupal.org: SELinux may cause mysterious permission problems that gives more information about these problems.

To allow apache (httpd) to write to the public file area, do the following:

# chcon -R -t httpd_sys_content_rw_t /var/www/html/sites/default/files/

Remote aministration of vhost

USIT VCenter (needs Flash, so use Chrome).

Repos

To see what externals repos are subscribed:

# yum repolist

To update packages from subscribed repos:

# yum update

More about the Red Hat Subscription Manager.

Resetting Drupal to a clean install

For a new semester in INF5272, rather than cleaning out everything, I reset the virtual host to a clean and empty install with the following script. The directory /var/www/html do not need to exist.

$ sudo /home/gisle/bin/drupal_cleaninst.sh teamnumber password

The teamnumber is always two digits (e.g. 01 for team number 1). The password to put as third argument is the Drupal db user password.

This cleans out everything in the file system, including themes, modules, libraries and the upload area. The projects Devel and Security review are also installed. Open user registration is turned off.

Check the following on the new site:

The web host should now be set up and ready for use.

The script that install Drupal sets me up as user #1. I am also the root user of the MySQL databases.

Students should register on Drupal-sites with -adm suffixed to their username, and I promote the first student of each team to Administrator in a timely fashion. He/she then promotes his/her teammates.

Deleting db

Provided the database holding your Drupal installation is named “drupal7”, this sequence of commands delete the Drupal db:

$ mysql -u root -p
Enter password:
mysql> DROP DATEBASE drupal7;
Query OK, 89 rows affected (1.21 sec)

mysql> quit
Bye

This will leave the Drupal core files and your sites directory intact, but the database, holding your content and your configuration will be gone. This is usually what you want to start rebuilding a corrupted site from scratch.

You can then go ahead and create an empty database for Drupal. Use the following script:

$ ./createdb.sh drupal7 drupal password
Enter password:

The password to put as third argument is the Drupal db user password (recorded in spreadsheet, in the column “user pw”). The password asked for on the next line is the MySql root password (recorded in spreadsheet, in the column “root pw”).

Troubleshooting

Email

Outgoing email from the machines go via smtp.uio.no. If it does not allow relaying to non-uio addresses from the vhost in question, the mail will bounce with the message:

relay not permitted (in reply to RCPT TO command)

To fix this, contact postmaster@usit.uio.no and request the vhost is permitted to send email to external recipients.

Final word

[TBA]

Last update: 2015-05-05 [gh].