Archive for February, 2010

getting a subversion server to spin (on mandriva)

Friday, February 12th, 2010

Setting up a subversion server on mandriva is relatively straight forward, but with a simple mind boggle, that cost me a few hours hence this post.

Simple stuff first:

urpmi subversion-server subversion subversion-tools xinetd

That’s it, all installed. Now create an empty repository (still basic stuff).

svnadmin create /var/svn/first_repo

Now the part that fooled me and had me entertained (not) for some hours. The file

/var/svn/first_repo/conf/svnserve.conf

contains the following by default:

### This file controls the configuration of the svnserve daemon, if you

### use it to allow access to this repository. (If you only allow

### access through http: and/or file: URLs, then this file is

### irrelevant.)

### Visit http://subversion.tigris.org/ for more information.

[general]

### These options control access to the repository for unauthenticated

### and authenticated users. Valid values are “write”, “read”,

### and “none”. The sample settings below are the defaults.

### anon-access = none

### auth-access = write

### The password-db option controls the location of the password

### database file. Unless you specify a path starting with a /,

### the file’s location is relative to the directory containing

### this configuration file.

### If SASL is enabled (see below), this file will NOT be used.

### Uncomment the line below to use the default password file.

### password-db = passwd

### The authz-db option controls the location of the authorization

### rules for path-based access control. Unless you specify a path

### starting with a /, the file’s location is relative to the the

### directory containing this file. If you don’t specify an

### authz-db, no path-based access control is done.

### Uncomment the line below to use the default authorization file.

### authz-db = authz

### This option specifies the authentication realm of the repository.

### If two repositories have the same authentication realm, they should

### have the same password database, and vice versa. The default realm

### is repository’s uuid.

### realm = some default realm

[sasl]

### This option specifies whether you want to use the Cyrus SASL

### library for authentication. Default is false.

### This section will be ignored if svnserve is not built with Cyrus

### SASL support; to check, run ’svnserve –version’ and look for a line

### reading ‘Cyrus SASL authentication is available.’

# use-sasl = true


### These options specify the desired strength of the security layer

### that you want SASL to provide. 0 means no encryption, 1 means

### integrity-checking only, values larger than 1 are correlated

### to the effective key length for encryption (e.g. 128 means 128-bit

### encryption). The values below are the defaults.

# min-encryption = 0

# max-encryption = 256

I have boldfaced the lines that tricked me

I read it as (well, skimming it) as sasl was by default disables, hence I did not need to specifically enable passwords from a passwd file. WRONG! To be able to interact with the svn server i had to uncomment the passwd line (and authz, but only if you need more fine grained access control).

Now to have the svn daemon running as a service, edit the xinetd file:

vi /etc/xinet.d/svnserve

I haven’t been able to make svnserve debug log any where, and running it by hand inside strace, did not reveal any sensible info either, so I made my way by starting with a know working configuration and then enabling cfgs one by one.

Hope this page will help some one, if found by google.

Posted in Linux, TechStuff | 2 Comments »

rsync protocol problem

Thursday, February 11th, 2010

Encountered

  note: iconv_open("UTF-8", "UTF-8") succeeded.
  rsync: connection unexpectedly closed (0 bytes received so far) [sender]
  _exit_cleanup(code=12, file=io.c, line=600): entered
  rsync error: error in rsync protocol data stream (code 12) at io.c(600) [sender=3.0.6]
  _exit_cleanup(code=12, file=io.c, line=600): about to call exit(12)

Googling did not help much. Neither did playing with -e ssh, -e ’ssh -l’, –protocol=29.

I checked version on receiving machine, and it was rsync-2.6.8-3.1.i386 on CentOS. Looking at the client with version 3.0.6, I first tried to sync with 3.0.4 and 2.6.9 which I had readily access to. Neither worked either.

Bruteforce solution was to download the 3.0.4 tar and recompile it on the target machine, and make sure it was on the path before /usr/bin/rsync. To test that it worked, I used the rsync parameter

  --rsync-path=/home/ads/rsync-3.0.4/rsync

and it worked.

Tags: , , ,
Posted in Uncategorized | 1 Comment »