Archive for the 'Software' category

Trac on Ubuntu

published on January 27, 2009.
Heads-up! You're reading an old post and the information in it is quite probably outdated.

Today I was messing around with Trac, installing it and doing some basic configuration. While my dev machine gets updated, I want to share my process of installing Trac.

What is Trac?

As said on the Trac homepage:

Trac is an enhanced wiki and issue tracking system for software development projects.

It’s free, it’s open source, it comes under the BSD license and it’s really awesome. You can write a wiki with it, have a ticket system, connect it with SVN, so you can browse the sources from the browser and see all the commit messages, when was something changed, added… It can support one project, it can support multiple projects. It can be viewable/editable by anyone, or you can close it down for your little team…

Trac is big. It has lots of plug-ins, so you can extend and customize your Trac. I haven’t played with them yet, but as soon as I will, you’ll get notified ;)

It’s written in Python. It can run on it’s own server, or it can run under Apache (where there are also several options). It can use SQlite, PostrgeSQL or MySQL databases. Currently it can connect only to SVN.

I’ll show you how to setup a basic Trac 0.11-dot-something-dot-something. It will run under Apache with mod_wsgi, use a SQlite database, connect to the SVN repository and require user authentication.

Installing Trac

Before anything, I want to say that my machine where I installed Trac has LAMP and SVN configured like this. So, this post is kinda the next part of that post.

First, I installed a Python tool, called Easy Install. It’s here to make our installation process easier. Lovely. Go to http://pypi.python.org/pypi/setuptools/, scroll down to the downloads section and choose a Python egg to download (match it to your currently installed Python version — I have Python 2.5 so I downloaded “setuptools-0.6c9-py2.5.egg”).

Fire up a console and type:

sudo sh setuptools-0.6c9-py2.5.egg

Of course, you need to match this to your own setuptools file.

Next, type:

sudo easy_install Trac

EasyInstall will now locate Trac and it’s dependencies, download and install them.

Download the mod_wsgi:

sudo apt-get install libapache2-mod-wsgi

It will install and enable mod_wsgi. And, in my case, it only tried to restart Apache, but for an unknown reason it fails to do so. If that happens, just do a quick:

sudo /etc/init.d/apache2 restart

If you want Subversion with your Trac, you’ll need the python-subversion package:

sudo apt-get install python-subversion

If you have it already, it’ll just skip it. If you want SVN, but you don’t have this package, later on it will show an error message like: Unsupported version control system “svn”.

Now to make a folder for Trac, where it will keep all the Trac projects and stuff.

sudo mkdir /var/trac /var/trac/sites /var/trac/eggs /var/trac/apache
sudo chown -R www-data /var/trac

Under /var/trac/sites will be the files for Trac projects. The /var/trac/eggs folder will be used as a cache folder for Python eggs. /var/trac/apache will hold a wsgi script file.

The wsgi script is actually a Python script, but with the .wsgi extension, used by mod_wsgi. With this script, Trac will be able to run as a WSGI application.
File: /var/trac/apache/trac.wsgi

import sys
sys.stdout = sys.stderr

import os
os.environ['TRAC_ENV_PARENT_DIR'] = '/var/trac/sites'
os.environ['PYTHON_EGG_CACHE'] = '/var/trac/eggs'

import trac.web.main

application = trac.web.main.dispatch_request

With this kind of script, one single Trac installation will be able to manage multiple projects (you can see here some other scripts).

Configure Apache, add this to your httpd.conf file:

WSGIScriptAlias /trac /var/trac/apache/trac.wsgi

<Directory /var/trac/apache>
    WSGIApplicationGroup %{GLOBAL}
    Order deny,allow
    Allow from all
</Directory>

Restart Apache:

sudo /etc/init.d/apache2 restart

If you go to http://localhost/trac/ in your browser, you should see an empty list of Available Projects. It’s empty, cause we haven’t added any project yet.

Now, let’s asume that we have a project called “testProject” with it’s source located in /var/www/testProject and a SVN repo located in /var/svn/repos/testProject. I’ll show how to add that project to Trac.

In console type:

sudo trac-admin /var/trac/sites/testProject initenv

Note that you need to provide the full path to /var/trac/sites, cause it will create a Trac project in the current folder you’re in.

It will ask you now a few things:

  • Project Name — the name of the project, e.g. “Trac testing project”
  • Database connection string — leave it empty, and it will use SQlite
  • Repository type — leave it empty, and it will use SVN
  • Path to repository — path to the project repo, e.g. /var/svn/repos/testProject

It will start to print out a bunch of lines, about what is it doing. In the end you’ll get a message like “Project environment for ‘testProject’ created.” and a few more lines. One more thing. We need to add the whole project to www-data user, so it can manage the files:

sudo chown -R www-data /var/trac/sites/testProject

If you direct your browser again to http://localhost/trac/, you will now see a link for the testProject. Click it. There, a fully working basic Trac environment for your project. A wiki, a ticket/bug tracking system, a repo browser in only a few minutes. How cool is that? Very.

This Trac environment can now be accessible by everyone. If we do not want that, we need to add this to the httdp.conf file:

<Location /trac>
    AuthType Basic
    AuthName "Trac login"
    AuthUserFile /var/trac/.htpasswd
    Require valid-user
</Location>

Create the .htpasswd file:

sudo htpasswd -bcm /var/trac/.htpasswd your_username your_password

All set. You’ll now have to login to Trac to be able to work on it. As I’m the big boss on my localhost, I gave myself some super-power privileges for Trac: TRAC_ADMIN. It’s like root on *NIX.

sudo trac-admin /var/trac/sites/testProject permission add robert TRAC_ADMIN

Read more about privileges.

That would be it. With this kind of setup, for now, it’s working perfectly for me. For Trac that’s available from the whole Internet, more security measures are needed, but this is only on localhost, so this is enough for me.

Comments, thoughts, ideas?

Happy hacking!

LAMP and SVN on Ubuntu 8.10

published on November 24, 2008.
Heads-up! You're reading an old post and the information in it is quite probably outdated.

This post is a rewrite of one of my older posts, Ubuntu as a dev machine, but this time I’ll explain also how to setup a basic SVN besides the LAMP.

Ubuntu 8.10 was released bout a month ago and today I wasn’t in the mood of doing any coding so I decided to try out the new Ubuntu. Once again, I’m installing it under VirtualBox (VB), cause it seems that they still haven’t fixed the bug related to the rtl8187 chipset. Oh well…

Be sure to use VB v2.x.x. (v2.0.6. is the latest now), cause it’s recognizing the correct screen resolution, not like VB v.1.6.4, whit which I had to configure manually the xorg.conf file…

Setting up LAMP

Here are the commands:

sudo apt-get install apache2
sudo apt-get install php5 libapache2-mod-php5
sudo /etc/init.d/apache2 restart
sudo apt-get install mysql-server
sudo apt-get install libapache2-mod-auth-mysql php5-mysql phpmyadmin
sudo /etc/init.d/apache2 restart
sudo a2enmod rewrite
sudo /etc/init.d/apache2 restart

If mod_rewrite doesn’t work, do the following:

sudo gvim /etc/apache2/sites-available/default

And change AllowOverride None to AllowOverride All.

Setting up SVN

I’m not gonna explain how SVN works or the terms, this is just how to set it up. If you are not familiar with versioning and Subversion, read this book: Version Control with Subversion. It’s free, available for download and contains probably everything you need to know about SVN. Be sure to learn the commands like commit, import, export, checkout, add, info, etc…

There are 2 ways for setting up SVN: as an Apache module or to use svnserve which is designed for SVN. As I already have Apache installed, the best solution is to use Apache for SVN. It’s using a module called mod_dav_svn.

The setup presented here is very basic, it has no authentication and probably is insecure, but it’s good for my needs on localhost.

The commands:

sudo apt-get install subversion
sudo a2enmod dav
sudo /etc/init.d/apache2 restart
sudo apt-get install libapache2-svn
sudo /etc/init.d/apache2 restart

Now we have all packages installed, only the configuration left.

First, I create a folder called svn under the var folder:

sudo mkdir /var/svn

Now I need to create a folder under the svn folder where all my repositories will be:

sudo svnadmin create /var/svn/repos

We use the svnadmin create command to create the repository; mkdir is not good for this.

Next, open up the httpd.conf file and add the following lines to it:

<Location /repos>
    DAV svn
    SVNPath /var/svn/repos
</Location>

I’ve seen people creating a new user and group for SVN. I think (I haven’t looked into it detailed) that’s for the authentication stuff. I did a much simpler thing: I added the ownership over /var/svn to www-data (Apache user):

sudo chown -R www-data /var/svn

This is probably a big security hole, but again: I use it only on localhost so I can live with that.

We are now ready to import a project into SVN, i.e. to add a project to the repository:

svn import -m "First import to SVN" /import/from/here/project file:///var/svn/repos/project/trunk

To start working on that project we need to checkout it:

svn checkout http://localhost/repos/project/trunk /var/www/project

Now the “project” is under SVN which should ease the development process. Since I’m using SVN I have no more backups of projects all over the place; if something goes wrong I know it’s under SVN and I can revert to any older working version of my project.

Cheers!

TickTweet WordPress plug-in

published on November 21, 2008.
Heads-up! You're reading an old post and the information in it is quite probably outdated.

Few weeks ago @imjustcreative mentioned on Twitter that he would like a WordPress plug-in that would scroll (tick) tweets where “soultweet” is mentioned. As I wanted to do a plug-in for some time, but never had any good ideas, I told him that I’ll take up the job. So I started to work on this in my free time.

Before I even started looking at anything, I decided that I want this plug-in to be fast, to work with smallest possible data to save bandwidth and to keep the number of calls towards Twitter low.

First I looked into the Twitter Search API documentation, to see how data can be retrieved from Twitter — in Atom or in JSON.

The first idea...

As a JSON document is smaller than an XML document, I decided to retrieve data in JSON. Of course, once retrieved it would be cached locally in a file for some time (5 minutes is my default).

I also wanted to avoid the possibility of the page waiting to retrieve the data from Twitter, so I figured that it would be the best to call it up with Ajax. That way, when the plug-in is called up, it sends an Ajax request to himself, the page continues loading normally and in the background runs the Ajax request.

The draft was there, I looked at the WordPress writing a plug-in page and in a week or so the first version of the plug-in was ready to go out.

I tested it locally on my Windows machine (a basic WAMP setup) and on my Ubuntu machine (a basic LAMP setup), on this server and on another one which has a ton of security limitations (server of my College). I was glad to see that it worked like a charm on all 4 servers. I put up a TickTweet page, and let it out in the wild through Twitter.

The retweet madness started immediately. @imjustcreative, @jonimueller and @bishop1073 downloaded it right away. Soon as they enabled the plug-in, the short and exciting life of TickTweet started to end. Errors, bugs… Joni’s server is running on PHP 4, and I had a few PHP 5 only functions. My bad. On Graham’s and Bishop’s server who knows what went wrong. Graham helped me a lot tracing down the bugs, a few of them were found and squashed, but that was not enough. So I decided to pull back TickTweet, rethink it and possibly rewrite it.

The second idea...

OK, this JSON — Ajax thingy won’t work. Back to the paper. I started looking at the WordPress core to see what functions and/or classes are available in it for this kind of task… Didn’t took me long to find the fetch_rss() function. Man I was happy to find that! It’s using the MagpieRSS and the Snoopy classes to retrieve the data. I figured, those are included in WP’s core, they’re gonna do the job just fine. So I’ve rewritten it.

Testing again. The College’s server was dropped out right away, no way around that security. On others it worked fine. I tested for a couple of days just to make sure. When I thought it was OK, I’ve let it go once again. I contacted Joni, Graham and Bishop to tell them that the new rewritten version is out. On Joni’s site it worked. Awesome. On Bishop’s site worked. Kinda. On Graham’s site didn’t work. He tried it on another site. Worked. Cool. Finally it works. I was happy.

But not for long. The next day I saw that on my site it’s ticking some ol’ tweets. What?! Then started the bug hunting again. I looked at each line of code, var_dumped every variable. No luck. Somehow, all of a sudden, my server is not getting the data from Twitter. No changes on the server configuration, no change in the code, but it just won’t work.

The third idea...

The third idea is to leave this “plug-in” as—is, and to stop working on it. It just doesn’t pay off. Sure, I could trace down where it hangs on my server, going backwards through the code, but it’s just not worth it. Those who are interested in this plug-in, you can find it at the TickTweet page, use it, rewrite it, change it, trash it.

Cheers!

Powered by WordPress 2.7 beta 1

published on November 04, 2008.
Heads-up! You're reading an old post and the information in it is quite probably outdated.

I’ve decided to upgrade to WordPress 2.7 beta 1, just for fun. For now, no major problems occurred, just a few smaller ones, all which are caused by my hacking of the WordPress core — I wasn’t keeping track of all hacks I did, so there were some random errors, but everything should be fine now.

I don’t recommend to no one upgrading to this version, unless you are OK with possible problems caused by this beta version. And even if you decide to upgrade now, do a backup of your database! Heck, do 2 backups!

First I did was backing up… No, I lie. First I did was start copying files of the wp-admin folder up to the server, when it came to my mind that I forgot to backup the database. Silly me. While it was copying I did a backup. Then I copied the contents of the wp-includes folder and then the files under the root folder of my blog. I haven’t uploaded nothing from the wp-content folder.

Oh yeah. Under the root folder, skip copying one file (if it’s there): the wp-config.php file, just to prevent overriding the configurations.

I tried to login to the dashboard. A message waited me, saying something like the database needs to be upgraded, blablabla, with a big a button. So I pressed the button. And everything went well. I logged in to the dashboard, to find out that I can finally find my way around the dashboard. It’s soooo much better now!! Errmm… I even saw a screenshot of it some where on the Internet… Meh. Can’t find it now.

After fixing those little errors I saw that my custom made template is working just fine and the plugins too — all 3 of them.

So there. My blog is now powered with WordPress 2.7 beta 1. I thought to write a tutorial on upgrading from WP 2.6.x to WP 2.7 but as it all comes down to uploading the files and hitting that “Upgrade database” there is no need for a tutorial.

Oh, and in case you missed it: do a bloody backup first!

Cheers!

P.S.: If someone finds some errors or the blog starts misbehaving let me know! Thanks!

Tags: blog, upgrade, wordpress.
Categories: Blablabla, Free time, Software.

A Zend_Captcha example

published on October 22, 2008.
Heads-up! You're reading an old post and the information in it is quite probably outdated.

Update: I made an error in the example code, regarding the CAPTCHA image URL. I’m sorry for any troubles caused by this mistake.

Update #2: Here’s an example of using Zend_Captcha without the whole Zend Framework stuff.

Update #3: There was an unintentional error in the captchaAction() method, Adam warned me about it in the comments. The error is fixed now. Thanks Adam.

OK, this was a bit tricky and I found no examples about it, so I thought to blog it. I’ll just show a quick example how to implement Zend_Captcha into a Zend_Form, may be useful for someone. There are several CAPTCHA types in ZF, like the Image, Figlet and Dumb. I use Image.

First of all, we’ll use sessions, so we need to change the bootstrap file a little:

<?php
// Put this line somewhere after the Zend_Loader::registerAutoload(); line
Zend_Session::start();

We need to start the session to use it, putting it close to the top will assure that there will be no “Headers already sent by…” errors caused by a wrongly placed session start.

Next we need a folder which has a 777 permission on it (Windows users, you can skip this… Or start using GNU/Linux) where we will put our captcha images for a while… This folder must be in the public folder somewhere. So create one.

How does this work? When a captcha is generated, it generates a unique ID (e.g. 539e517b0c0f4e32ef634dae92f07f77) and the word on the image. That unique ID is used for the file name of the image and for the session namespace (the namespace is like: Zend_Form_Captcha_uniqueId), so it knows which image belongs to which session. Also, the generated word is placed inside it’s own session. That ID is placed on the form in a hidden field, so when the submission is received, we can access the ID and recreate the correct session namespace and access the data in it: the word on the image.

Awesome. Now, to the fun part. I use the Zend_Form_Element_Captcha class, so no additional fooling around is needed to put the captcha in the form. Here’s the code:

<?php
public function indexAction()
{
// Our form object...
$form = new Zend_Form();
// And here's our captcha object...
$captcha = new Zend_Form_Element_Captcha(
        'captcha', // This is the name of the input field
        array('label' => 'Write the chars to the field',
        'captcha' => array( // Here comes the magic...
        // First the type...
        'captcha' => 'Image',
        // Length of the word...
        'wordLen' => 6,
        // Captcha timeout, 5 mins
        'timeout' => 300,
        // What font to use...
        'font' => '/path/to/font/FontName.ttf',
        // Where to put the image
        'imgDir' => '/var/www/project/public/captcha/',
        // URL to the images
        // This was bogus, here's how it should be... Sorry again :S
        'imgUrl' => 'http://project.com/captcha/',
)));
// Add the captcha element to the form...
$form->setAction('/index/captcha/')
        ->setMethod('post')
        // Add the captcha to the form...
        ->addElement($captcha)
        ->addElement('submit','Submit')
// Pass the form to the view...
$this->view->form = $form;
}

On the other side, it goes something like this:

<?php
public function captchaAction()
{
  $request = $this->getRequest();
  // Get out from the $_POST array the captcha part...
  $captcha = $request->getPost('captcha');
  // Actually it's an array, so both the ID and the submitted word
  // is in it with the corresponding keys
  // So here's the ID...
  $captchaId = $captcha['id'];
  // And here's the user submitted word...
  $captchaInput = $captcha['input'];
  // We are accessing the session with the corresponding namespace
  // Try overwriting this, hah!
  $captchaSession = new Zend_Session_Namespace('Zend_Form_Captcha_'.$captchaId);
  // To access what's inside the session, we need the Iterator
  // So we get one...
  $captchaIterator = $captchaSession->getIterator();
  // And here's the correct word which is on the image...

  $captchaWord = $captchaIterator['word']
  // Now just compare them...
  if($captchaInput == $captchaWord)
  {
  // OK
  }
  else
  {
  // NOK
  }
}

Easy, ain’t it?

Happy hacking :)

Tip: Using a monospace or a serif font for the words on the image (like FreeMono.ttf found by default on Ubuntu), makes the word quite unreadable — with the FreeMono.ttf about 8 out of 10 is UNreadable — so use a sans-serif font.

Robert Basic

Robert Basic

Software engineer, consultant, open source contributor.

Let's work together!

If you require outsourcing or consulting help on your projects, I'm available!

Robert Basic © 2008 — 2019
Get the feed