Archive for the ‘Uncategorized’ Category

Subversion (SVN) over SSL in 10 small steps

Friday, April 27th, 2007

I have installed SVN on Centos4 (RHEL4) following these small and short steps.

1. Check out svnbook. This is the place where all your later questions will be answered.

2. Using Centos/RHEL and still not using Dag Wieers and RPMForge’s RPM repository?

3. Install using YUM or Apt the following packages:






4. Create your SVN repository root directory and cd to there: "mkdir /var/www/svn ; cd /var/www/svn"

5. Create your new repository. I’ve used the name "projects" and I maintain the name later on. If you decide on another name, make sure to change wherever valid later: "svnadmin create projects"

6. Change ownership to Apache: "chown -R apache.apache projects"

7. Rename /etc/httpd/conf.d/subversion.conf to /etc/httpd/conf.d/subversion.conf.old

8. Edit /etc/httpd/conf/ssl.conf and add the following lines:

–Near the beginning, add these two lines:

LoadModule dav_svn_module modules/
LoadModule authz_svn_module modules/

–Just above the line saying </VirtualHost> enter the following:

<Location />

      DAV svn
      SVNParentPath /var/www/svn
      AuthType Basic
      AuthName "Company"
      AuthUserFile /etc/httpd/conf.d/passwd
      Require valid-user


9. Check Apache to verify you didn’t destroy anything. No need, by the way, to create SSL self-signed certificate, as the installation of mod_ssl creates one for you: "apachectl -t". If you get "Ok", you’re Ok.

10. Add users by using the utility "htpasswd". The first time will require the flag "-c" which tells htpasswd to create the file. Later on, no need for this flage. Exmaple: The first user will require: "htpasswd -c /etc/httpd/conf.d/passwd user1". The 2nd user will require just "htpasswd /etc/httpd/conf.d/passwd user2".

Done. All you need to do is point your SVN client to https://<IP or Name>/projects and you’re good to go (of course – as soon as you specify your username and password).

Cacti and per minute poll

Monday, April 16th, 2007

I love the tool Cacti. It’s a nice graphing tool, which helps a lot in system monitoring and management.

Its logic, however, is not always obvious. The relationship between data types, host templates and graph templates is quite complex, and if you are to implement any non-default setup using Cacti, you better understand these relationships as soon as possible.

I was using it to monitor an ERP system. I have encountered in the past a problem with monitoring Linux network traffic through SNMP, since the container is a short integer, and during 5 minutes wait it gets filled several times, if this is 1Gb/s network connection we measure.

The solution I wanted to employ was to haste the system, and measure every minute (60 seconds). This isn’t trivial using either Cacti or MRTG, because they were designed for 5 minute interval.

I have found this link in Cacti’s forums, which shows how to do it, and it works fine, as long as you follow instructions by the letter. This was done on RH4 x86, using Dag Wieers’ Home-made RPM repository as the source for Cacti.

I will attempt to export the modified templates and upload them here, to save some of the dirty work required for the process to work.


Monday, April 9th, 2007

As you can see in my previous posts, I have an NVidia card. It worked quite well while using XGL, but due to XGL’s memory consumption (it takes a lot of memory), I have decided to try for AIGLX, which is part of the system.

In my previous post you can see that (and how) it was done. However, my overall experiance is that AIGLX, at least where it comes to Xorg 7.2 and NVidia (Driver 1.0-9755) is that XGL is much much faster.

The slow responses of the system during the several hours I used AIGLX (while trying somehow to increase performance) just made me go back to XGL. AIGLX is not good enough.

I’ve read several posts about it, and still, the results are undetermined. That’s why I post my own software versions here. AIGLX may perform better when using older or newer versions of NVidia’s driver, or Xorg, or whatever, but for me now – XGL does it well.

Finally had some time today

Thursday, March 22nd, 2007

So this post is not technical by nature.

Today I gave away 14 PCs and 5 VGA screens. All are in some-not-exactly-unworking-condition, which means that you can probably mix two computers into one, or you need only add some RAM, HDD or other several components to make any of these PCs work.

All of them are either Pentium1 or Pentium2 class (I think there was one AMD K6 there).

A picture of the pile before the giveaway:

This is the pile – 14 PCs and 5 VGAs!

So I searched for anyone who was willing to take them, and found one. I was surprised at how quick the responses were. It was less than 5 hours from the time I’ve posted my give-away offer, till the computers were gone.

You can say it’s for a good cause – the person who’s got them tries to make them work and then he installs Xubuntu on them (a very lightweight distro), and give them away (or sell them in a near-zero price) to people with no computer, and usually with zero computer skills. He teaches them to use the computer for the general day-to-day needs WE all are familiar with. This is an honorable task, I must say, and I salute him. Not only adding users to the pool of the modern society, but also doing it for near-zero pay, and actually making them Linux users – plain dumb-I-dont-have-viruses computer users. Can hardly be better.

DL140 Generation 1 (G1) and LILO do not work

Wednesday, February 14th, 2007

I add to this blog all pieces of information which I might think could help other people.

One of the things I have encountered short while ago had to do with DL140 G1 system cannot boot Linux.

It’s Linux system (RedHat 4 32bit) was deployed by an external system and the system could not boot. However, when installed from CD, the system booted just fine. The symptom for this was that after booting, the screen showed:

LILO: Loading Linux…..

and that’s all. The system could have booted (and did so once) after several days, however, this is not really a desired status.

It seems to be an issue of Lilo and this specific hardware. Other systems (non DL140) were able to boot just fine using Lilo, and this same kernel version was bootable on that system through other means.

Replacing Lilo with GRUB during installation/deployment solved the isse. FYI.