User:Dan Nessett/Technical/How to set up a CZ clone on Ubuntu

From Citizendium
< User:Dan Nessett‎ | Technical
Revision as of 18:58, 23 December 2009 by imported>Dan Nessett (→‎Setting up the CZ database)
Jump to navigation Jump to search

This page provides instructions describing how to set up a Citizendium clone. Creating a CZ clone is useful for a number of purposes, including:

  • Storing a local copy of Citizendium on a lap-top or other device so articles are accessible when there is no available network connection.
  • Creating a local copy of Citizendium for the purpose of fixing bugs in the modified version of Mediawiki that forms its software base or developing extensions to that code.

Installing the necessary software infrastructure

CZ is implemented by a modified version of the Mediawiki software. This software relies on several software components that underly its operation, specifically:

  • PHP - an object-oriented interpreted language. Mediawiki is written in PHP and its software modules execute when accessed through a web server.
  • Apache2 - an open source industrial grade web server.
  • Postgres - an open source industrial grade database system.

Note that many Mediawiki implementations use the MySQL database system, rather than Postgres. While it might be possible to install Citizendium's wiki content using a MySQL database, doing so would represent experimental development. This how-to presumes the installer uses Postgres.

In order to install the Citizendium wiki software, the system running it must have PHP, Apache and Postgres preinstalled. So, the first step in creating a CZ clone is to install these software subsystems. There are a number of different platforms that support these and potentially any of them could be used to support a CZ clone, However, the most popular platform is Linux and the most popular of the Linux variants is Ubuntu Linux. Consequently, these instructions assume the software is installed on Ubuntu Linux (they should also work on any other Debian Linux variant). However, it is possible to install CZ's software on other Linux platforms and even on other operating systems (e.g., Mac OS X, Windows). With one exception those interested in using using a different OS platform will have to do the research necessary to accomplish that. The exception is CentOS 5.4. Instructions for installing a LAPP stack on that Linux variant are found at this location. The instructions for Ubuntu given here have been tested on a fresh install of Hardy Heron (8.04) with software updated to that available on 12/14/2009. The kernel was Linux version 2.6.24-16-generic.

Installing the LAPP stack

It is common to refer to the Apache, Postgres and PHP software infrastructure as a LAPP stack (i.e., a Linux Apache Postgres PHP stack). An infrastructure using MySQL instead of Postgres is referred to as a LAMP stack). These instructions assume the reader is using Ubuntu, specifically Ubuntu Hardy Heron (8.04LTS). Furthermore, they assume the Ubuntu installation is standard (i.e., it includes all of the standard application software components).

Many of the following instructions direct the installer to enter a command into a terminal window. On Ubuntu a terminal window is created as follows:

Ubuntu Hardy Heron terminal selection screenshot.png

Updating the apt-get database

To ensure the LAPP stack installation uses the most up-to-date software, the installer should first update the apt-get database using the following command at a terminal command-line prompt: 

sudo apt-get update

Install Postgres, Apache2 and PHP

After updating the apt-get database, install postgres. 

sudo apt-get install postgresql-8.3 php5-pgsql

Then install the Apache2 web server and PHP. 

 sudo apt-get install apache2 libapache2-mod-php5 php5-gd

Configuring the LAPP stack

Once the LAPP stack is installed, the installer must configure it.

Configure Postgres

The first thing to do is assign a password to the postgres user of the postgres database. This step may be somewhat confusing to a novice user of postgres, so some explanation is in order. On the operating system that runs postgres is a user named postgres. This user is also listed as a Login Role for the postgres database system. The next step uses a feature of postgres that stipulates if you access the database (through the utility psql) as a particular user, you are automatically logged into postgres as that user. So, the first step is to use sudo to login as root and then change the user identity with the -u parameter. The command executed by sudo will use psql to connect to the postgres database (which, while having the same name, is different than the postgres Login Role). Once psql is connected to the postgres database using the Login Role postgres, it is possible to change the password for (the Login Role) postgres. Execute the following command at a terminal prompt: 

sudo -u postgres psql postgres

This should result in a welcome message, followed by some command hints and then followed by the prompt: 

postgres=#

At this prompt type: 

\password

psql will prompt you for a password and then prompt you to reenter it (remember this password, because you will need it later). If you successfully enter the same password twice, psql returns a new prompt. Type "\q" (without the quotes), which should return you to a Ubuntu command prompt.

The above instructions use the term postgres in three different ways. There is the postgres database system, which is the software that implements postgres. There is the postgres database, which is a collection of tables managed by the postgres database system. Finally, there is the postgres Login Role, which is an identify used by the postgres database system to make access control decisions. It is necessary to keep these distinctions in mind. Later in these configuration instructions, we willl create a cz Login Role and a cz database.

For the novice, using postgres can be a frustrating experience. The main command line utility for interacting with postgres is "psql". Psql has two sets of commands. The first always begin with the character '\' (the backslash, not the slash). The second are SQL commands. Frequently, when using the second category of commands, a new user fails to enter the required semicolon (";") at the end. (The semicolon is not used at the end of the first category of commands). After entering an SQL command, psql returns a prompt and the user thinks the command has been executed. However, it hasn't. A semicolon must be entered (it can be entered after the command on the subsequent prompt). To make things even more confusing, psql uses a "query buffer". This concatenates all input until the requisite semicolon is typed. This also makes things difficult for the novice user, since many times he/she will type multiple commands and then remember to type one with a semicolon. This almost always results in an error. It is good practice to clean out the query buffer using the command "\r" (without the quotes) before entering a new SQL command. It is recommended that those unfamiliar with psql read this good tutorial on its use.

A GUI for accessing postgress databases, pgAdmin III, can help the novice user avoid many of the frustrations experienced when using psql. To install pgAdmin III, use Ubuntu's Add/Remove application facility. This is accessed by clicking at the top left of the desktop on the "Applications" tag (Postgres Figure 1). Select All available applications in the Show drop down menu and type postgres in the Search box (Postgres Figure 2). When the search finishes, scroll down to the bottom and select the pgAdmin III application by checking the box to the left. Then click on Apply Changes. This will install pgAdmin III on your system. (The system may request you to enable community applications. If so, click "Enable"). You will also have to enter your superuser password in a prompt window.

Installing pgAdmin III

Postgres figure 1

Postgres figure 2

Postgres Figure 1

Postgres Figure 2

Once installed, pgAdmin III requires configuration. Start pgAdmin III (it should appear in the Applications menu under System Tools. If you have come to these instructions from the CentOS LAPP installation page, pgAdmin III may appear under Programming). The application window appears. In the left window pane is an icon labeled Servers(0). It is necessary to connect to a postgres server in order for the tool to operate. Under the File menu, select Add Server. A New Server Registration window pops up (Postgres Figure 3).

We are going to use the tool to connect to the database server on the local system. So, fill in the Name field with an appropriate name (e.g., Local Host) and fill in the Host field with the value localhost. The Username field is filled in by default to postgres. We will use this identity to access the database system until we have other Login Roles established. So, it is necessary to fill in the password created for the postgres Login Identity previously. Once this is filled in (leave all other selections at their default values), the OK button becomes active. Click it. You may see a hint displayed. If you find these annoying, there is a check box that turns them off. The result of this is a new entry under Servers(1) appears called Local Host (note the number of servers has changed from 0 to 1). Click on the + sign to the left of Local Host and a number of other labels appear.

We will use pgAdmin III to create two new Login Roles. The first is a role corresponding to your user name. This will allow you to use psql from your user account without specifying a username and password. Click on Local Host so it is highlighed and then click on the Edit menu and select New Object. A pop out menu appears to the right. Select New Login Role.... Fill in the form as follows (Postgres Figure 4):

  • Role name - your user name on the system. For example if you login to Ubuntu as jdoe, fill in jdoe into the Role name field.
  • Password - enter a password for your postgres Login Role.
  • Password (again) - enter the same password.
  • Role Privileges - click all of the boxes. This gives you all privileges for database administration.

Click on OK.

Configuring pgAdmin III

Postgres figure 3

Postgres figure 4

Postgres Figure 3

Postgres Figure 4

To check that you successfully created a Login Role with the same username as your Ubunutu name, type the following command at a terminal window prompt (don't close pgAdmin III. We will use it again below): 

psql postgres

This should result in the postgres welcome message, command hints and then the prompt: postgres=>. Type \q to exit psql (if you wish, you can stay in psql rather than quitting, since we will return to it after some more work in pgAdmin III).

Going back to pgAdmin III, we will create another Login Role as well as a new database. To create the Login Role follow the steps given above, except use the Role Name cz and leave the password fields blank. While it is unnecessary to give the cz Login Role all privileges, this clone of CZ will be used by only you and it is therefore convenient to do so. If you were creating an installation of CZ that would be accessed by others, you would spend much more time configuring it so it is secure. How to configure a CZ installation so it is secure in a multi-user environment is outside the scope of these instructions.

We nave to modify the cz role and using psql is the easiest way to do so. In a terminal window at a prompt type: 

psql postgres

This should result in the postgres welcome message, command hints and then the prompt: postgres=#. Now enter the following information at the postgres prompt. (note: you can simply copy and past the information below into the terminal window). 

ALTER ROLE cz SET "TimeZone" TO 'GMT';
ALTER ROLE cz SET search_path TO mediawiki, public;
ALTER ROLE cz SET "DateStyle" TO ISO, YMD;
ALTER ROLE cz SET client_min_messages TO 'error';

If you enter this information one line at a time, you will have to type a return each time (don't forget the semicolon after each line). If you copy and paste the information, you will need to type a return after the last line. As each line is executed, psql will return ALTER ROLE. To check that these commands executed correctly, use pgAdmin III to navigate to the cz Login Role (i.e, expand the + sign next to Login Roles). Double click on cz. A pop-up window should appear with the information for cz. Select the Variables tab and the variable values set by psql should display (Postgres Figure 5). You may need to refresh the information displayed by pgAdmin III by selecting Refresh from the View menu. You can exit psql by typing "\q".

Now that a cz Login Role is established with the correct initialization information, it is possible to create a cz database. In the main pgAdmin III window right click on Databases so it is highlighted and either right click on it and select New Database or from the Edit Menu select New Database (in some versions of pgAdmin III New Database is a selection in the New Object submenu). Fill in the Name field with cz. Select cz using the right hand down-arrow of the Owner field (Postgres Figure 6). Click OK. The Databases field should change from Databases(1) to Databases(2). Click on the + sign to the left of the Databases field and two databases should be displayed: 1) postgres, and 2) cz (Postgres Figure 7).

Finishing Postgres configuration

Postgres figure 6

Postgres figure 5

Postgres Figure 5

Postgres Figure 6

Final Postgres configuration

Postgres figure

Postgres Figure 7

There is one last bit of configuration necessary to set up postgres as the wiki's backend database server. (Note: If you came to this point via the CentOS 5.4 thread, skip to the next section. You have already configured pg_hba.conf.) We have to modify the postgres authentication configuration data so it trusts commands executed from the local server. In a terminal window execute: 

sudo su - postgres
cd /etc/postgresql/8.3/main
gedit pg_hba.conf &

An edit window should appear. Scroll to the end of the file and find the entry with the comment "local" is for Unix domain socket connections only. The next entries control access when connections to the postgres server come from the local host. Copy the text below and replace the corresponding text. The entry should now look like the following: 

# "local" is for Unix domain socket connections only
#local   all         all                               ident sameuser
local   all         all 				trust
# IPv4 local connections:
#host    all         all         127.0.0.1/32          md5
host    all         all         127.0.0.1/32          trust

Save the file and exit the editor. Now restart the postgres server with the following command: 

sudo /etc/init.d/postgresql-8.3 restart

This completes the configuration of postgres. We will return to postgres when we cover how to import the CZ dump data into the installation.

Configure Apache2

Configuring the apache2 web server requires less sophisticated tools than those used to configure postgres. Basically, a text editor is all that is required. These instructions use gedit, which is a nice GUI editor that comes pre-configued on Ubunutu. However, the directories used in an Ubuntu installation are slightly different than those used in a CentOS 5.4 installation. The instructions covers both cases, providing the Centos 5.4 instructions second.

Configuration of the original apache server required editing one large file (httpd.conf). Fortunately, the apache2 server software has separated the configuration information into several files, which makes configuration much easier. On Ubuntu, the main configuration file is located in /etc/apache2. It is named apache2.conf. There is no need to edit this file when setting up a CZ clone. In fact, no configuration of the apache2 server is necessary to enable the LAPP stack. To test that the apache2 server and PHP are correctly installed, in a terminal window execute (Note: if you have followed the instructions for installing LAPP on CentOS 5.4, it isn't necessary to execute these commands. The file they create already exists. Otherwise, CentOS 5.4 installers should cd to /var/www/html, rather than /var/www): 

cd /var/www
sudo gedit phpinfo.php

This will pop an edit window. Enter the following text into the file: 

<?php
phpinfo();
?>

Then save the file. Now restart the apache2 server to ensure it has read the installed configuration files: 

sudo apache2ctl restart

On CentOS 5.4 restart apache2 using: 

sudo /etc/init.d/httpd restart

In a web browser, create a new tab or a new window. In the url field at the top enter: 

http://localhost/phpinfo.php

If the apache2 server and PHP are correctly installed, a page of information about PHP should display. At the top will be the PHP Version and in the subsequent graphical boxes will be information about PHP and the PHP extensions installed. It is useful to keep the phpinfo.php file in this location because occasionally it is helpful to test the apache2/PHP installation to ensure it retains integrity.

Some additional configuration of the apache2 server is necessary to utilize the CZ software that implements the wiki. There are two ways to configure the apache2 server for the CZ clone. One way is to assume there is only one copy of the CZ software on the machine. This is normally true for those who are cloning CZ for personal use. The other way is to assume multiple copies of the CZ software exist on the machine. This is normally the case if the CZ clone is used for software development. While setting up the machine for multiple copies of the CZ software is unnecessary for a local use clone, it really doesn't introduce any overhead to do so. Consequently, these instructions describe how to set up the apache2 server to access more than one copy of the CZ software.

The CZ software will be stored in subdirectories of /usr/local/src. The first step is to cd to that directory and create a subdirectory called mediawiki. Change the permissions on mediawiki to 777 (i.e., in /usr/local/src execute sudo chmod 777 mediawiki). In a production environment, the adminstrator would use more careful access control permissions. However, since this CZ clone is intended for local use, making the software world r/w is an acceptable configuration strategy. Change directories to mediawiki and create a CZ_1_13_2 subdirectory. Also make this directory world r/w. The commands are: 

cd /usr/local/src
sudo mkdir mediawiki
sudo chmod 777 mediawiki
cd mediawiki
sudo mkdir CZ_1_13_2
sudo chmod 777 CZ_1_13_2

If the CZ clone is used for development purposes, the developer would create additional subdirectories of the /usr/local/src/mediawiki directory to hold different versions of the CZ software. In fact, it is possible to host copies of the non-modified mediawiki software by downloading them into subdirectories of mediawiki. For example, if it is desirable to download a copy of the mediawiki software on which CZ is based, the developer could create a subdirectory of mediawiki, say MW_1_13_2, and use it to hold the non-modified version.

Once this directory structure is created, it is possible to make the changes to the apache2 configuration information necessary to support the CZ software. In a terminal window exectute: 

cd /etc/apache2/sites-enabled
sudo gedit 000-default

(Note: If you have come to these instructions from the installing a LAPP stack on CentOS 5.4 page, you must edit the file /etc/httpd/conf/httpd.conf, rather than /etc/apache2/sites-enabled/000-default, and add the indicated information to its end. When viewing the result, no </VirtualHost> statement will display).

This will open an edit window displaying the contents of the sites-enabled file. At the end of this file right before the </VirtualHost> delimiter, enter the following information: 

    Alias /mediawiki/ "/usr/local/src/mediawiki/"
    <Directory "/usr/local/src/mediawiki/">
		Options FollowSymLinks
		AllowOverride None
    </Directory>

    Alias /CZ_1_13_2 "/usr/local/src/mediawiki/CZ_1_13_2/phase3/index.php"

After doing so the end of the file should contain the following text: 

    Alias /mediawiki/ "/usr/local/src/mediawiki/"
    <Directory "/usr/local/src/mediawiki/">
		Options FollowSymLinks
		AllowOverride None
    </Directory>

    Alias /CZ_1_13_2 "/usr/local/src/mediawiki/CZ_1_13_2/phase3/index.php"

</VirtualHost>

Now restart the apache2 server by executing: 

sudo apache2ctl restart

On CentOS 5.4 restart apache2 using: 

sudo /etc/init.d/httpd restart

We can't test whether the apache2 server properly executes the CZ software because that software isn't installed yet. However, we can test the configuration changes we just made. In a terminal window type: 

sudo su
cd /usr/local/src/mediawiki/CZ_1_13_2
mkdir phase3
chmod 777 phase3
cd phase3
cp /var/www/phpinfo.php .
mv phpinfo.php index.php
chmod 777 index.php
exit

On CentOS 5.4 first su to root and then use: 

cd /usr/local/src/mediawiki/CZ_1_13_2
mkdir phase3
chmod 777 phase3
cd phase3
cp /var/www/html/phpinfo.php .
mv phpinfo.php index.php
chmod 777 index.php
exit

The first command moves the terminal session to the root identity. We do this because there are a lot of commands that require root access and typing sudo before each is inefficient. The last command exit takes the session back to your Ubunutu identity.

These commands make a copy of the phpinfo.php file in /usr/local/src/mediawiki/CZ_1_13_2/phase3 and rename it index.php. When we install the CZ software we will have to remove this file before loading it, since there is already an index.php file in the CZ software distribution.

Now we are prepared to test the new apache2 server configuration. Open a browser and either open a new tab or a new browser window. In the URL field enter: 

http://localhost/mediawiki/CZ_1_13_2/phase3/index.php

The same PHP configuration information should appear as before. Now enter in the URL field: 

http://localhost/CZ_1_13_2

Again the PHP configuration information should appear. If either of these tests fail, recheck the edits and the directory structure created above. In the latter case, the directories /usr/local/src/mediawiki, /usr/local/src/mediawiki/CZ_1_13_2 and /usr/local/src/mediawiki/CZ_1_13_2/phase3 should exist with 777 permissions.

Installing the CZ wiki software

Download the CZ wiki software

Installing the CZ wiki software requires access to the main CZ repository. In this repository is stored various versions of the software including the currently deployed version and others undergoing development. The version control system used to manage these versions is Subversion. We must install the Subversion software in order to access the repository.

Create a terminal window and enter the following command (Note: those following the CentOS 5.4 path have already installed subversion, so they should skip this step): 

sudo apt-get install subversion

Once the installation completes, we can download the current CZ software release. But, first we have to clean up some detritus left from testing the apache2 configuration. Execute the following commands in a terminal window: 

sudo su
cd /usr/local/src/mediawiki/CZ_1_13_2
rm -fr phase3
exit

This removes the phase3 directory and everything in it. Now we have to find out which release version we will checkout. Execute: 

svn list http://m-aurelius.citizendium.org/czrepo/tags

The result is a list of releases for the CZ software. These instructions assume the latest version is called CZ_1_13_2_0.

The next step is to checkout this version. For those new to version control, a checkout from a repository makes a local copy of whatever branch is specified. This local copy retains information about where it comes from in the repository, but the repository itself keeps no state about the local copy. Consequently, you can do anything you want with the local copy, even delete it. The repository is unaware of these changes until you attempt to check in the local copy.

To checkout CZ_1_13_2_0 into the directory CZ_1_13_2 (which is where will configure the apache2 server to find it), execute: 

cd /usr/local/src/mediawiki
svn checkout http://m-aurelius.citizendium.org/czrepo/tags/CZ_1_13_2_0 CZ_1_13_2

The result of this command is a very large number of lines starting with the letter A (which stands for Add). After the command completes, there is a copy of the latest CZ released software in /usr/src/local/mediawiki/CZ_1_13_2.

Setting up the CZ database

The next step is to create the database schema. In an unmodified version of the mediawiki software the schema is created using a utility called update.php. However, CZ runs a modified version of the mediawiki software and so this utility doesn't correctly setup the database. So, we must use psql to import the schema.

The directory /usr/src/local/mediawiki/CZ_1_13_2 has two subdirectories: 1) database, and 2) phase3. The latter contains the PHP modules that implement the wiki. The former contains information specific to the wiki database. In particular, it contains a dump of the CZ database schema. We will use psql to import this into the cz database.

In a terminal window execute: 

cd /usr/local/src/mediawiki/CZ_1_13_2/database
psql -d cz -U cz -f schema_1_13_2.pg

If an error occurs with the following text: 

FATAL: Ident authentication failed for user cz

then you haven't correctly changed the file pg_hba.conf. Go back and ensure that both local and host entries are specified as trust.

Before configuring the CZ wiki software, we will make one modification to the CZ database. It isn't clear why this change is necessary, but if it isn't executed, the database import will not work.

Start pgAdmin III. Double click the localhost icon and if they are not already expanded, click on the + button to the left of the cz icon and then on the + button to the left of the Schemas icon and then on the + button to the left of the mediawiki icon. Under mediawiki click on the + button to the left of the Tables icon. Scroll down to the mwuser entry. Single click mwuser and then click on the icon that looks like a table at the top of the window shown in Postgres Figure 8.

Changing the mwuser table

Postgres figure 8

Postgres figure 9

Postgres Figure 8

Postgres Figure 9

In the first row under user_id, enter the integer 0. In the next column, user_name, enter the text "dummy" (without the quotes). Select File in the upper left-hand corner and then select save. The result should look like Postgres Figure 9. These actions create a dummy user that cannot be used to login to the wiki, since it has no password associated with it. Close pgAdmin III.

Configuring the CZ wiki software

Most configuration of the CZ wiki software occurs through edits to the file LocalSettings.php. In a non-modified version of the Mediawiki (MW) software, after an initial software install using Subversion, the installer access the wiki through a web browser and a special PHP routine guides him/her through the steps necessary to achieve an intial configuration. However, since the CZ wiki uses a different database schema than MW, the CZ software distribution comes with a copy of LocalSettings.php that is already properly configured. It is only necessary to get a copy of LocalSettings.php into the phase3 directory of the CZ software distribution. In a terminal window execute: 

cd /usr/local/src/mediawiki/CZ_1_13_2/phase3
cp config/LocalSettings.php .

Now, open a browser window and in the URL field type: 

http://localhost/CZ_1_13_2

The wiki main page should appear. If so, congratulations! You have successfully installed the CZ wiki software. If you wish, you can bookmark this URL and save it under a more informative title, such as "CZ clone" or "Local CZ clone". If the main page did not appear, go back and review the instructions in this section to ensure you executed them correctly.

Notes

Directory Files Blank Lines Comments PHP code statements
CZ phase 3 1005 56590 69544 460125
CZ includes 321 14769 33313 97375
CZ extensions 142 3769 6742 27350
CZ includes+extensions 463 18583 40055 124725
  • Using importDump.php in /maintenance I populated a version of CZ as a local development environment. The Statistics special page showed in excess of 129,000 pages. The import reported populating 116,400 pages (looking at the pages table, the exact number is 116,486). This checks out, since the daily dump of CZ does not include histories. There are approximately 12,700 live articles, each of which would have a history page. Noting, 116,500 + 12,700 = 129,200, it appears all content pages were loaded. However, it took in excess of 3 1/2 days (about 80 hours) to import the content. This suggests looking at more efficient import strategies (e.g., using mwdumper or converting to SQL with xml2sql and importing directly into the database).
  • Had trouble getting skins to work. I needed to set $wgScriptPath to /mediawiki/CZ_1_13_2/phase3. Originally had it set to $IP. But, that expands to /usr/local/src/mediawiki/CZ_1_13_2/phase3, which is not accessible through the apache2 server. The correct value uses the /mediawiki apache2 alias.
I now need to run maintenance/runJobs.php. The statistics page shows 272,975 queued jobs, so running all queued jobs is going to take a while. Dan Nessett 22:39, 23 November 2009 (UTC)
  • Had trouble getting texvc to work:
  • The message "failed to parse cannot write to or create math temp directory" signals problems with permissions on the images directory in phase3.
  • Need to ensure images directory has both a /math and /tmp subdirectory with read/write access and the images directory is accessible to the apache2 server (I simply chmod 777 both of them).
  • Originally had $wgUploadPath to "$IP/images". This is incorrect. This variable must be set to a URL prefix that is accessible to the apache2 server. Set it to "$wgScriptPath/images" and TeX math worked.
  • Ran into a strange problem where no matter how I changed the permissions on images/math and images/tmp, the message "failed to parse cannot write to or create math temp directory" appeared. Somehow this message stopped showing up. I don't know exactly why, but perhaps you need to clear the browser cache.
  • I tried putting the directories/files in images into the www-data subgroup and owned by www-data and then changing permissions on everything below images to 775. However, subversion needs to get to locks in this directory tree (even when images has the svn:ignore property). So, while math rendering worked, when I committed changes to the repository, subversion failed on attempting to create a lock in images/.svn. So, I finally gave up and executed sudo chmod -R 777 images. This seems to fix all math rendering and subversion problems, but it is very insecure.
  • Had trouble getting email to work. Since the installation is intended for local development, I chose to set up only local email. Therefore, every user must have an email address of <username>@localhost. When Ubuntu is installed, the exim4 MTA/MDA is installed by default. It is only necessary to set up an email client to receive emails. I used GNOME evoution (which is also installed by default). In order to set up evolution to receive local email, I had to set up the configuration as follows:
  • Account name: Local Email Account
  • Full Name: Dan Nessett
  • Email Address dnessett@localhost
  • Server Type: Local delivery
  • Configuration (path): /var/mail/dnessett
  • Server Type: Sendmail
  • When we have a CZ repository set up, need to exclude some directories in phase3 from version control.
  • In order to exclude all images in phase3/images from version control (other than those preloaded in icons), set property svn:ignore * on that directory.
  • Svn copy LocalSettings.php into config (after potentially locally deleting any existing version of that file there). Then svn delete LocalSettings.php in phase3. Set properties on phase3 to include "svn:ignore LocalSettings.php". Commit these changes. Then locally (not using svn) copy LocalSettings.php from config to phase3. This effectively removes LocalSettings.php from version control. So, local developers can make modifications to it and commit other changes without saving LocalSettings.php to the repository. If it ever becomes necessary to change the repository version of LocalSettings.php, the developer should merge changes in phase3/LocalSettings.php into config/LocalSettings.php and then commit the changes.
  • When ftp transferring a file created by svnadmin dump, make sure the transfer type is set to binary. Otherwise, when you attempt to import it, you will get an error like, "svnadmin: Dump stream contains a malformed header (with no ':') at:" Also when loading the dump, use svadmin load --ignore-uuid /path/to/repository < dumpfile. This will ensure the UUID specified in the dump file does not clobber the repository's existing UUID (this will happen if the repository being loaded has no revisions in it).
Retrieved from "https://citizendium.org/wiki/index.php?title=User:Dan_Nessett/Technical/How_to_set_up_a_CZ_clone_on_Ubuntu&oldid=707480"