We’re using Ubuntu Linux, and this tutorial assume you’ve already installed TRAC on a global basis to your development server.

So, lets get some themes installed on our Trac 10.x installation shall we?

First, install the pre-requisites if not already installed.

# apt-get install python2.5-setuptools

We had to change a couple permissions as well so Trac and everything can read/write where it needs to

# chown -R www-data:www-data /var/www

Now we had to install WebAdmin for Trac 10.x:

# svn export http://svn.edgewall.com/repos/trac/sandbox/webadmin/
# cd webadmin
# python setup.py bdist_egg
# easy_install -Z dist/*.egg

Note that WebAdmin is included with Trac 11.x if you’re bleeding edge, you probably don’t need this.

Now we had to install ThemeEnginePlugin for Trac 10.x:

# svn checkout http://trac-hacks.org/svn/themeengineplugin
# cd themeengineplugin
# cd 0.10
# python setup.py bdist_egg
# easy_install -Z dist/*.egg

Now, lets install some themes for Trac 10.x:

# svn checkout http://trac-hacks.org/svn/pydotorgtheme/
# cd pydotorgtheme/0.10/
# python setup.py bdist_egg
# easy_install -Z dist/*.egg
# cd ../../
# svn checkout http://trac-hacks.org/svn/gamedevtheme/
# cd gamedevtheme/0.10
# python setup.py bdist_egg
# easy_install -Z dist/*.egg
# cd ../../
# svn checkout http://trac-hacks.org/svn/consultanttheme/
# cd consultanttheme/0.10
# python setup.py bdist_egg
# easy_install -Z dist/*.egg
# cd ../../

Now we added the following to our Trac.ini within the project we want the themes to be used for:

# cd /var/local/trac/trac.yourdomain.com/conf/
# nano trac.ini

Add this to the components section of your configuration file

[components]
webadmin.* = enabled
themeengine.* = enabled

Then we restarted Apache and we were able to select themes to make available, and attach to our Trac Installation. Note that with each new theme added, you will have to restart Apache in our experience.

This should get you going with installing some themes for Trac on your Ubuntu Linux server. Have Fun!

We wanted to setup LigHTTPD, however it’s not nearly as easy because of no svn-dav module available, so we stuck with Apache 2 for now.

We found a howto on doing this, however there were a few vital steps and explanations missing so we’ve re-written it in hopes it will help others the trouble of searching to find this information.

So, lets move on to the tutorial shall we.

First install the required packages on your system. We started with a clean Ubuntu JEOS 8.0.4 Install on our server.

# sudo aptitude install enscript libapache2-mod-python python-docutils trac db4.3-util libapache2-svn subversion-tools

Now create a virtual host for your SVN container.

# mkdir -p /var/local/svn/svn.yourdomain.com

Now create a development group, and add the web user to it.

# addgroup svngroup; adduser www-data svngroup

Now Add a user to the system and add them to that group

# adduser username
# passwd username

Now add that user to the group required for SVN

# adduser username svngroup

Now setup the permissions for your SVN site.

# chmod 2770 /var/local/svn/svn.yourdomain.com

Now setup the repo as you normally would

# svnadmin create /var/local/svn/svn.yourdomain.com

Remove the current password file. We’re using HTTPS (or HTTP) instead of SVNSERVE so no need for it.

# rm /var/local/svn/svn.yourdomain.com/conf/passwd
# touch /var/local/svn/svn.yourdomain.com/conf/passwd

Allow your group to write to the repo

# chmod -R g+w www-data:svngroup /var/local/svn/svn.yourdomain.com

Now set the repo access permissions.

# nano /var/local/svn/svn.yourdomain.com/conf/authz

It should look something similar to the following. If in doubt, refer to the Path-Based Auth section of Subversion.

[groups]

svngroup = username1,username2,username2

[/]
@svngroup = rw

Now, create a log directory within apache for your development site.

# mkdir /var/log/apache2/svn.yourdomain.com

Now create your virtual host.

# nano /etc/apache2/sites-available/svn.yourdomain.com

Copy the following in, editing to suit your environment. Note we’re using a self signed certificate, you can change this to a properly signed one if you have it.

<VirtualHost [server's IP address]:443>
ServerName svn.yourdomain.com
<Location />
DAV svn
AuthType Basic
AuthName “svn.yourdomain.com”
AuthUserFile /var/local/svn/svn.yourdomain.com/conf/passwd
AuthzSVNAccessFile /var/local/svn/svn.yourdomain.com/conf/authz
SVNPath /var/local/svn/svn.yourdomain.com
Require valid-user
</Location>
CustomLog /var/log/apache2/svn.yourdomain.com/access.log combined
ErrorLog /var/log/apache2/svn.yourdomain.com/error.log
SSLEngine on
SSLCertificateFile /etc/ssl/certs/selfsigned.pem
# Add this once there is a real (non self-signed) certificate.
# SSLCertificateKeyFile /etc/apache2/ssl/server.key
</VirtualHost>
<VirtualHost [server's IP address]:80>
ServerName svn.yourdomain.com
Redirect / https://svn.yourdomain.com/
</VirtualHost>

Now, enable the site

# a2ensite svn.yourdomain.com

Now, create a username and password to access the svn site.

# htpasswd /var/local/svn/svn.yourdomain.com/conf/passwd username1

Now, create your SSL certificate. Details are here if you need them.

# sudo aptitude install ssl-cert

Now, we found out that the default Ubuntu SSL cert is only for 30 days, so, we changed this to be 365 a little more sane no? Thanks for the tip Devio.

# which make-ssl-cert
/usr/sbin/make-ssl-cert
# nano /usr/sbin/make-ssl-cert

Replace the line near the bottom that looks like this

openssl req -config $TMPFILE -new -x509 -nodes -out $output -keyout $output

With a line that looks like this instead

openssl req -config $TMPFILE -new -x509 -days 365 -nodes -out $output -keyout $output

Exit and save the file. Now we’re ready to generate our final self signed SSL certificate for Apache on Ubuntu. Like this;

# make-ssl-cert /usr/share/ssl-cert/ssleay.cnf /etc/ssl/certs/selfsigned.pem

Make sure to set your “common name” to your server name – ie: svn.yourdomain.com

Now you can go ahead and restart Apache to verify your DAV enabled SVN site functions.

# /etc/init.d/apache2 restart

To verify, hit it’s url in a browser

https://svn.yourdomain.com/

If everthing was successful, you now have SVN setup, with WEB-Dav support in Apache2 on Ubuntu. Continue to setup Trac.

First we have to create the web directory for Trac.

# mkdir -p /var/local/trac/trac.yourdomain.com

Now we setup the permissions

# chmod 2770 /var/local/trac/trac.yourdomain.com

Create a Trac instance for your project

# trac-admin /var/local/trac/trac.yourdomain.com initenv

Setup the proper ownerships for the directory

# chown -R www-data:svngroup /var/local/trac/trac.yourdomain.com

Now make sure the group is added to the repo

# chmod -R g+w /var/local/trac/trac.yourdomain.com

Configure Trac where required

# nano /var/local/trac/trac.yourdomain.com/conf/trac.ini

Create a directory for log files

# mkdir /var/log/apache2/trac.yourdomain.com

Now create a virtual host for your trac instance

# nano /etc/apache2/sites-available/trac.yourdomain.com

Now, copy the following into the virtual host configuration, changing to suit your domain and configuration

# Trac Configuration
<VirtualHost [server's IP address]:80>
ServerName trac.yourdomain.com
Redirect / https://trac.yourdomain.com/
</VirtualHost>
<VirtualHost [server's IP address]:443>
ServerName trac.yourdomain.com
DocumentRoot /var/local/trac/trac.yourdomain.com/
Alias /trac/ /usr/share/trac/htdocs
<Directory “/usr/share/trac/htdocs/”>
Options Indexes MultiViews
AllowOverride None
Order allow,deny
Allow from all
</Directory>
<Location />
SetHandler mod_python
PythonHandler trac.web.modpython_frontend
PythonInterpreter main_interpreter
PythonOption TracEnv /var/local/trac/trac.yourdomain.com/
PythonOption TracUriRoot /
AuthType Basic
AuthName “trac.yourdomain.com”
# Use the SVN password file.
AuthUserFile /var/local/svn/svn.yourdomain.com/conf/passwd
Require valid-user
</Location>
CustomLog /var/log/apache2/trac.yourdomain.com/access.log combined
ErrorLog /var/log/apache2/trac.yourdomain.com/error.log
SSLEngine on
SSLCertificateFile /etc/ssl/certs/selfsigned.pem
# Add this once there is a real (non self-signed) certificate.
# SSLCertificateKeyFile /etc/apache2/ssl/server.key
</VirtualHost>

Now, enable this virtual host as well

# a2ensite trac.yourdomain.com

Configure Trac Permissions for your Trac instance.

# trac-admin /var/local/trac/trac.yourdomain.com

Use the following commands to view permissions, and set permissions.

“help permission”

We set the following permissions to one of our users from the command line

# trac-admin /var/local/trac/trac.yourdomain.com permission add username1 TRAC_ADMIN

Now you’re ready to restart Apache with your new Trac VHOST.

# /etc/init.d/apache2 restart

Now you’re ready to restart Apache and visit your Trac installation

https://trac.yourdomain.com/

Login with your user (username1) and password you setup earlier.

We hope this tutorial helps others when trying to setup SVN and Trac on Ubuntu with Virtual Hosts. Let us know if you have any other handy tips!

I think this software could replace WordPress if done correctly, it will just take some time to get a little more robust, but the guts of it is definately there.

We recently installed Habari on one of our sites, and written this quick tutorial on how to get it going on your Ubuntu server using Apache.

We assume you’ve already got Mysql, PHP, SQLite and Apache installed on your server. If not, find some Howto’s on that because we’re not discussing it here.

So, first install some pre-requisite software:

# apt-get install libmysqlclient15-dev
# pecl install pdo pdo_mysql pdo_sqlite
# apt-get install sqlite3 libsqlite3-dev php5-sqlite3
# apt-get install php5-dev subversion

Now edit your php.ini

# nano /etc/php5/apache2/php.ini

add this to the bottom of the file:

extension=pdo.so
extension=pdo_sqlite.so

Now restart apache

# /etc/init.d/apache2 restart

Now create your Apache Virtual Host as per usual for your site.

Now enter your sites directory

# cd /home/username/public_html/sitename.com/htdocs/

Create the .htaccess file

# nano .htaccess

Enter something similar to the following for the contents of the htaccess file you just created.

### HABARI START
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteBase /
RewriteRule . index.php [PT]
### HABARI END

### HABARI SQLITE START
<Files “YOURSQLLITEDATABASENAME.db”>
Order deny,allow
deny from all
</Files>
### HABARI SQLITE END

Now download the Habari SVN

# svn checkout http://svn.habariproject.org/habari/trunk/htdocs .

We are using the MPM-ITK module with Apache. This means that all our sites are running per user, instead of as a global user. This is much more secure for multiple user or site environments. It’s very easy to get going in Ubuntu. Just do this.

# apt-get install apache2-mpm-itk

Then add this to whichever vhost you’re containing Habari

<IfModule mpm_itk_module>
AssignUserId username groupname
</IfModule>

This means we don’t have to setup crazy permissions for the Habari installer to function. If you don’t want to install MPM-ITK then you can simply follow the Habari Installation Instructions.

Now, to complete the install visit your site through

http://www.yourhabarisite.com/

The settings we used are the following:

Locale:
Set as “En-US”

Database Setup:
Database Type: sqlite
Data File: yourdomain.com.db
Table Prefix: habari__

Site Configuration:
Site Name: Site Name
Username: admin
Password: Your Password
Password: Your Password Repeated
Admin Email: contact@yourdomain.com

Plugins We left Enabled:
- Core Dash Modules
- Habari Media Silo
- Pingback
- Spam Checker
- Undelete

*NOTE*

We did have an error during installation when using SQLITE3. We had to modify the default Habari database schema to remove the “IF NOT EXIST” lines. Not sure why this was needed as apparently this support was added in Sqlite 3.3 and Ubuntu comes with 3.4 but whatever, very simple fix for the problem.

*NOTE*

Once this is done you should be complete the setup of Habari and can go ahead and install some Plugins or Themes.

We hope you enjoyed this tutorial, let us know if you have any other interesting Habari tips or tricks.

Basically the problem is:

Plesk runs apache as “www-data:www-data” while the users are “username:psacln”. So, uploading via sftp or ftp will work fine, but when you go to install something from the control panel in Joomla, it will be installed as www-data:www-data. Obviously, this is a problem since joomla won’t be able to run it properly.

So, our fix was this:

1. Install mod-itk

# apt-get install apache2-mpm-itk

2. Enter your VHOST directory

# cd /var/www/vhosts/[DOMAIN]/conf

3. Edit the vhosts file

# nano vhost.conf

4. Copy the following into the file, changing the user to your domain user.

<IfModule mpm_itk_module>
AssignUserId DOMAINUSER psacln
</IfModule>

5. Restart apache like this:

# /etc/init.d/apache2 restart

Now you should have apache back up, and each time it runs it will be running as your domain user, not www-data. Problem solved, without the use of php-cgi. Sweet!

first:

# sudo nano /etc/grub/menu.lst

look for

# defoptions= quiet splash

change it to – important leave the # in the line.

# defoptions=

now just run the grub updating tool and you’ll start up without the splash

# sudo update-grub

Easy eh?

1. SSH to server running nagios/nagiosadministrator

2. Go to your nagios administrator directory, ours is /var/www/nagiosadmin

3. Now, edit the menu file

# nano apps/backend/lib/topMenu.class.php

4. Now, change the first class topMenu from this

class topMenu
{
protected static $items = array(
‘contact’ => ‘Contacts’,
‘contactgroup’ => ‘Contact Groups’,
‘os’ => ‘Operating Systems’,
‘service’ => ‘Services’,
‘hostgroup’ => ‘Host Groups’,
‘host’ => ‘Hosts’,
‘command’ => ‘Commands’,
‘template’ => ‘Templates’,
‘generator’ => ‘Generator’
);

to this

class topMenu
{
protected static $items = array(
‘contact’ => ‘Contacts’,
‘contactgroup’ => ‘Contact Groups’,
‘os’ => ‘Operating Systems’,
‘service’ => ‘Services’,
‘hostgroup’ => ‘Host Groups’,
‘host’ => ‘Hosts’,
‘command’ => ‘Commands’,
‘template’ => ‘Templates’,
‘generator’ => ‘Generator’,
‘nagios’ => ‘Go To Nagios’
);

5. Refresh the Nagios Administrator web interface, and you’ll see a fancy new button you can click on to take you right to nagios.

Enjoy!

“VCommand error: This product has expired.”

This box holds some Asterisk Development stuff and some other Dev systems that we couldn’t really have go down on us. So, we downgraded our VMWare 2.x Server to the latest 1.x branch of VMWare. Then on we went to importing Virtual Machines from Server 2.0 and Workstation 6. As soon as we started to power them on, the fun started. Of course! The VM’s weren’t compatible anymore and gave us a couple errors. Here’s how we fixed it.

The first error we received was:

“A General System Error Occurred: Unknown Error”

This happened as soon as we tried to power on the VM. This was easily fixed. We entered the Virtual Machine’s directory, and edited the .vmx file for the virtual machine, this is just plain text. Replacing the next few lines fixed it right up for us.

config.version = “8″
virtualHW.version = “6″

became

config.version = “4″
virtualHW.version = “4″

Now we could power them up. However, we now encountered another error that we couldn’t open the virtual disk we had created. The error was something about how the Virtual Disks were created in a later version of vmware, and couldn’t be mounted. We’d have to re-create them. Obviously this wasn’t an option.

In some of the Virtual Machine directories, we had a file to edit with a text editor, this was simple enough.

# nano virtualdiskname.vmxf

Then change this:

ddb.virtualHWVersion = “6″

became

ddb.virtualHWVersion = “4″

However, some of the other directories (mainly the ones created with VmWare Workstation 6) did not have a simple text file to edit, instead we had to edit the actual virtual disk using a hex editor. We chose the wonderful heme editor. Usage Instructions for Heme are here.

Basically put, do this:

# heme virtualdisk.vmdk

Now press “w” on your keyboard to search for “virtualHWVersion“. You will find it in the ascii column eventually. Hit “TAB” to enter Ascii mode, move your cursor with the arrow keys to where you need to replace the number. Replace the “8” or the “6” with a “4” and then press “s” to save the file. Answer yes to saving and then wait for it to save. Now exit the program by pressing “q“. You’ll notice it created a backup file with the “~” extension on it incase you messed up the hex editing. Leave this backup file here for now. Continue on, nothing to see here.

Now on the VMWare server, make sure that all the files in the virtual machine directory are chmodd’d properly.

# cd /virtual machine/directory/

# chown user:group *
# chmod og=rwx *

Now you should be able to start your vm without any issues.

If it all works, feel free to delete the backup .vmdk~ that heme created for you.

Good luck!

Here’s the howto:

1. Login to old server
2. scp old log files over, to the admin home directory, in /logs

   # scp -r /home/username/logs/ username@yournewserver:

3. If copying multiple directories, and you want to call them something other than logs do this:

   # scp -r /home/username/logs/ username@yournewserver:/home/username/logs_domainname/

4. Login to new server
5. Go to /home/username/logs (or /home/username/logs_domainname)
6. Make a backup of current logs

   # mkdir new_logs
   # cp access_log error_log ./new_logs

7. Make a few directories

   # mkdir old_logs
   # mkdir concat_logs

8. Enter the old logs directory, and copy the old log files over

   # cd old_logs
   # cp /home/admin/logs/* .

9. Now we’re going to concatenate all these to a new single file. Logresolvemerge.pl is part of the awstats distribution and has been copied to /usr/local/bin.

   # logresolvemerge.pl ./access_log* > access_log_overall_old
   # logresolvemerge.pl ./error_log* > error_log_overall_old

10. Now we’ll leave this directory, and enter the concat_logs directory

    # cd ..
    # cd concat_logs

11. Now we’ll copy our newly created log files over to this directory

    # cp ../old_logs/error_log_overall_old ../old_logs/access_log_overall_old .

12. Now we’ll copy in the “new” log files from the new production server. This step can be omitted if there are no stats on this server already, or they are not needed.

    # cp ../new_logs/* .
    # ls -l

    -rw-r–r– 1 root root 554 Sep 2 19:38 access_log
    -rw-r–r– 1 root root 3702368 Sep 2 19:37 access_log_overall_old
    -rw-r–r– 1 root root 115 Sep 2 19:38 error_log
    -rw-r–r– 1 root root 907085 Sep 2 19:37 error_log_overall_old

13. Here we’ll combine the old logfile, with the new logfile. This again, can be omitted if not using old stats and new stats.

    # logresolvemerge.pl ./access_log ./access_log_overall_old > access_log_final
    # logresolvemerge.pl ./error_log ./error_log_overall_old > error_log_final

14. Now we’ll either have in our directory, a final old log file, or a final combined file from this server, and the old server up to the minute.

    If you didn’t do step 11 and 12, all that’s left is:
    
    # cp ./access_log_overall_old ../access_log
    # cp ./error_log_overall_old ../error_log
    # /etc/init.d/apache restart

    If you did do step’s 11 and 12, then do this:

    # cp ./access_log_final ../access_log
    # cp ./error_log__final ../error_log
    # /etc/init.d/apache restart

15. You can now delete the old_logs, new_logs, concat_logs directories if wanted.

    # cd /home/domain/logs/
    # rm -rf concat_logs
    # rm -rf new_logs
    # rm -rf old_logs

16. To update the logs, and make them visible on the awstats interface run this:

    # /usr/lib/cgi-bin/awstats.pl -config=yourdomain.tld -update wq

17. Visit them on the web at;

    http://www.domainname.com/awstats/awstats.pl

18. Add the update line to your crontab to schedule it. You can also use updateall.pl that comes with the awstats distribution to update all sites at one time if vhosting.

19. Go have a rum and coke to celebrate!

• start vm
• # sudo mount /cdrom
• # cd /cdrom
• # cp *.tgz /tmp
• # cd /tmp
• # apt-get install build-essentials
• # apt-get install linux-headers-`uname -r`
• # tar xzvf vmtools<yourversion.tgz>
• # cd vmtools<yourver>
• # perl vmware-install.pl

That’s it. You might want to modify your console settings so you can get 1024×768 from VMWare Workstation, but it’s not really required if you’re just SSH’ing to it.