Allowing changes in subversion log messages or comments

When you commit your change to a subversion repository you have an option to change the comment you use:

svn propset --revprop -r 15125 svn:log "Editing this comment with more detail, blah, blah ..."

There is a hook script template that you could use to allow this but there is a reason why the default template should not be used as is. It is dangerous to be able to affect good comments with garbage if you just make a mistake with the version number but the most dangerous of all is that you could change comments done by a different user!!! From a GUI like Eclipse or Netbeans it is harder to make a mistake like the first one of course, however you should protect subversion so log changes are restricted to the owner of the commit.

Use the below to achieve it (Linux, if Windows translate to DOS)

$ sudo vi /var/local/svn/subversion.nestorurquiza.com/hooks/pre-revprop-change
REPOS="$1"
REV="$2"
USER="$3"
PROPNAME="$4"
ACTION="$5"

owner=`svnlook author -r "$REV" "$REPOS"`
if [ "$ACTION" = "M" -a "$PROPNAME" = "svn:log" -a "$owner" = "$USER" ]; then exit 0; fi

echo "Changing revision properties other than svn:log is prohibited and you must be the owner($owner) to change $REPOS@$REV" >&2
exit 1 
$sudo chmod +x  /var/local/svn/subversion.nestorurquiza.com/hooks/pre-revprop-change

Phishing Attack: Using redirection

It has come to my attention the escalation in phishing attempts coming to my gmail account. In 4 days I got 3 emails that managed to pass the spam protection. They all claimed they were my twitter friends and that they found someone faking my account, my twitter picture, twitter avatar and what not.

I always inspect the url before clicking because I want to explore the vulnerabilities (of course the safest to do is just to report as spam anything looking suspicious) So I took a look at them and they were all referring to well known websites that are "offerring free redirection services". I hope this is just a bug in CNN.com and pepsi.com. Do not hit the urls below before reading the rest of this post. Here are the URLs:

http://pepsi.com/pepsi_redirect.php?theurl=jurism%2Ecom%2Foldweb%2Ftraffic168
http://mexico.cnn.com/redirectComplete.php?url=%2F%2Fjurism%2Ecom%2Foldweb%2Ftraffic168
http://mexico.cnn.com/redirectComplete.php?url=%2F%2Ftwitmytweets%2Eit%2Etc

Open Firefox and delete all your cookies. Failure to do that will probably compromise things like your google/gmail account.

If you take a look at the traces you will notice there were attempts to get some stuff from google.com. If you are logged into gmail or other google services your cookies for google.com will be compromised and the intruder could fake your session resulting in identity theft.

svnadmin: Couldn't perform atomic initialization database is locked

I was trying to use a CIFS (Windows) path as the svn repository but I was having locking issues:

$ sudo svnadmin load /repo/path < ~/svn_dump
<<< Started new transaction, based on original revision 1
    * adding path : projects ... done.
svnadmin: Couldn't perform atomic initialization
svnadmin: database is locked

Taking a look at man pages I gave option "nobrl" a try and that seemed to solve the problem which apparently is that our NetApp SAN does not support byte range locks.

Using the below did the trick then:

mount -t cifs //windows.box/path /mnt/local/path -o credentials=/root/cifs/cifs_credentials.txt,domain=COMPANYX,file_mode=0600,dir_mode=0700,uid=admin,gid=admin,nobrl

CIFS VFS: cifs_mount failed return code -13 0xc000006d NT_STATUS_LOGON_FAILURE

Using the following command to mount a CIFS (Windows) path:

mount -t cifs //windows.box/path /mnt/local/path -o credentials=/root/cifs/cifs_credentials.txt,domain=COMPANYX,file_mode=0600,dir_mode=0700,uid=admin,gid=admin

I was getting this error:

[307906.131366] Status code returned 0xc000006d NT_STATUS_LOGON_FAILURE
[307906.131374] CIFS VFS: Send error in SessSetup = -13
[307906.131575] CIFS VFS: cifs_mount failed w/return code = -13

While this can be caused by any permission problems sometimes the lack of more verbose log traces makes it harder to find the exact issue.

In my case this was related to the credentials file having spaces:

username = user 
password = password

Fixing it was a matter of trimming spaces out:

username=user 
password=password

FCKEditor for Mediawiki 1.17: WYSIWYG based on CKEditor

Mediawiki is not longer supporting the deprecated FCKEditor. The new CKEditor is supported through the WYSIWYG extension. I tried WYSIWYG 1.5.6 in my a new installation of Mediawiki 1.17.0 but I would get nothing everytime I would try to switch to the Rich Editor.

Debugging with Firebug I found a variable not defined error: "CKEDITOR is not defined". This was a result of addType directives in wiki/extensions/WYSIWYG/ckeditor/.htaccess. You either need to comment the lines or move the file (rename it, delete it or move it to somewhere else)

So below are the commands to get your WYSIWYG editor working in Mediawiki:

$ unzip wysiwyg-1.5.6_0.zip
$ sudo cp -R extensions/WYSIWYG /var/www/wiki/extensions/
$ sudo chown -R www-data:www-data /var/www/wiki/
$ sudo mv /var/www/wiki/extensions/WYSIWYG/ckeditor/.htaccess /var/www/wiki/extensions/WYSIWYG/ckeditor/.htaccess.old
$ sudo vi /var/www/wiki/LocalSettings.php
  require_once("$IP/extensions/WYSIWYG/WYSIWYG.php");
  $wgGroupPermissions['*']['wysiwyg']=true;

Upgrading subversion

We are using WebDAV with Apache for subversion. Below are the steps I followed to migrate an old subversion repository to a brand new Ubuntu server with latest subversion.

Note that "admin" is a user which can make administer subversion.

$ sudo apt-get install subversion libapache2-svn
$ sudo mkdir -p /var/local/svn/subversion.nestorurquiza.com
$ sudo addgroup svn
$ sudo usermod -a -G svn www-data
$ sudo usermod -a -G svn admin
$ sudo chmod 2770 /var/local/svn/subversion.nestorurquiza.com
$ sudo svnadmin create /var/local/svn/subversion.nestorurquiza.com
$ sudo vi /var/local/svn/subversion.nestorurquiza.com/conf/authz #ACL
$ sudo mkdir /var/log/apache2/subversion.nestorurquiza.com
$ sudo vi /etc/apache2/sites-available/subversion
<VirtualHost *>

 ServerName svn.nestorurquiza.com
 ServerAlias subversion.nestorurquiza.com
 DocumentRoot /var/local/svn/subversion.nestorurquiza.com

 <Location /repos/reporting>
   DAV svn
   SVNListParentPath off
   AuthType Basic
   AuthName "Subversion repository"
   SVNPath /var/local/svn/subversion.nestorurquiza.com
   AuthzSVNAccessFile /var/local/svn/subversion.nestorurquiza.com/conf/authz
   AuthUserFile /var/local/svn/subversion.nestorurquiza.com/conf/passwd
   Require valid-user
   <LimitExcept GET PROPFIND OPTIONS REPORT>
        Require valid-user
   </LimitExcept>
 </Location>

 <Directory "/var/local/svn/subversion.nestorurquiza.com">
   Options -Indexes
 </Directory>
</VirtualHost>
$ sudo cp authz /var/local/svn/subversion.nestorurquiza.com/conf/authz #assuming there is an existing svn access file. Better keep it on SVN ;-)
$ sudo cp passwd /var/local/svn/subversion.nestorurquiza.com/conf #assuming there is an existing password file. Better keep it on SVN ;-)
$ sudo htpasswd /var/local/svn/subversion.nestorurquiza.com/conf/passwd "new username here" #to create individual users
$ sudo ln -s /etc/apache2/sites-available/subversion /etc/apache2/sites-enabled/004-subversion
$ sudo svnadmin load /var/local/svn/subversion.nestorurquiza.com < ~/file_from_command_svnadmin_dump_originalRepoPath
$ sudo chown -R www-data:svn /var/local/svn/subversion.nestorurquiza.com
$ sudo chmod -R g+w /var/local/svn/subversion.nestorurquiza.com
$ sudo /etc/init.d/apache2 restart

Upgrading Bugzilla

This one was pretty straightforward (from version 2 to 4 actually)

1. If this is a new server restore your DB from current bugzilla installation
2. Uncompress the distro in your document root, commonly /var/www/bugzilla-4.0.2
3. Update apache virtual host to point to that directory
4. Replace file 'localconfig' and directory 'local' from the previous installation
5. If needed change db user and password if needed in 'localconfig'
6. If needed update urlbase 'data/params' file
7. Run the below commands from the bugzilla document root directory and make sure you get no warnings nor errors. Correct them all before considering your migration completed
   

   $ sudo ./runtests.pl 
   $ sudo ./checksetup.pl 
   

8. Restart apache and hit the bugzilla url