- Details
- Written by: andre
- Category: Linux Server Admin Guide
- Hits: 20987
Documentation for LDAP Installation
based on
Quick_HOWTO_:_Ch31_:_Centralized_Logins_Using_LDAP_and_RADIUS
Using bytesare.us as domain name
Config files (on ubuntu 12.04)
/etc/default/slapd
/usr/share/slapd/slapd.conf
/usr/share/slapd/DB_CONFIG
Setup and configure a local LDAP server
Install packages:
root@testkraxn ~ # apt-get install slapd nss-updatedb ldap-utils
Server configuration:
root@testkraxn ~ # dpkg-reconfigure slapd Omit OpenLDAP server configuration? <No> DNS domain name: bytesare.us Organization name: BytesAreUs Database backend to use: HDB Do you want the database to be removed when slapd is purged? <No> Move old database? <Yes>
Check if your config database was created properly by firing test searches.
root@testkraxn ~ # ldapsearch -Q -LLL -Y EXTERNAL -H ldapi:/// -b cn=config dn ...
root@testkraxn ~ # ldapsearch -Q -LLL -Y EXTERNAL -H ldapi:/// -b dc=bytesare,dc=us dn: dc=bytesare,dc=us objectClass: top objectClass: dcObject objectClass: organization o: BytesAreUs dc: bytesare dn: cn=admin,dc=bytesare,dc=us objectClass: simpleSecurityObject objectClass: organizationalRole cn: admin description: LDAP administrator
Migrate current system to ldap database using migrationtools
Install the migration scripts utility package and edit its config file to match your system.
Then run the scripts to create an initial migration ldif file.
root@testkraxn ~ # apt-get install migrationtools root@testkraxn ~ # vim /etc/migrationtools/migrate_common.ph # Adjust the following lines: $DEFAULT_MAIL_DOMAIN = "bytesare.us"; $DEFAULT_BASE = "dc=bytesare,dc=us"; $DEFAULT_MAIL_HOST = "mail.bytesare.us"; $IGNORE_UID_BELOW = 1000; $IGNORE_UID_ABOVE = 9999; root@testkraxn ~ # cd /usr/share/migrationtools root@testkraxn /usr/share/migrationtools # { ./migrate_base.pl; \ ./migrate_passwd.pl /etc/passwd; \ ./migrate_group.pl /etc/group; } > ~/migrationtools.ldif
Run the ldif script to import your current users into the ldap database.
root@testkraxn ~ # ldapadd -r -h 127.0.0.1 -D "cn=admin,dc=bytesare,dc=us" \ -f ~/migrationtools.ldif Creating naming context entries... slapadd: could not add entry dn="dc=bytesare,dc=us" (line=1): txn_aborted! DB_KEYEXIST: Key/data pair already exists (-30995) Migration failed: saving failed LDIF to /tmp/nis.4809.ldif
The migrate script failed because it tried to add the dc=bytesare,dc=us entry which already exists.
Lets uncomment this first entry and add the ldif manually.
(I needed a few trial/error iterations until the command finished.
Some entries in the generated ldif are screwed up, but the error
messages are very helpful.
You can revert your ldap directory with dpkg-reconfigure slapd after a
failed import try.)
Test your server with a search for a user:
In this example the root user is looked up.
root@testkraxn ~ # ldapsearch -x -b 'ou=People,dc=bytesare,dc=us' 'uid=ldaptestuser1' root@testkraxn ~ # ldapsearch -h 127.0.0.1 -D "cn=admin,dc=bytesare,dc=us" -W -b 'ou=People,dc=bytesare,dc=us' 'uid=ldaptestuser1' root@testkraxn ~ # ldapsearch -x -b 'ou=People,dc=bytesare,dc=us' '(objectCLass=posixAccount)' dn | grep uid ldaptestuser1@testkraxn ~ % ldapsearch -h 127.0.0.1 -D "uid=ldaptestuser1,ou=People,dc=bytesare,dc=us" -W -b 'ou=People,dc=bytesare,dc=us' 'uid=ldaptestuser1'
The server is set up. Great!
You should be able to test it from a different host:
tester@differenthost ~ % ldapsearch -h 192.168.56.101 \
-b 'ou=People,dc=bytesare,dc=us' -D 'cn=admin,dc=bytesare,dc=us' 'cn=root' -W
CREATING SNAPSHOT OF VM "LDAP SERVER SET UP"
Setup and configure client authentication
Install necessary packages:
root@testkraxn ~ # apt-get install ldap-auth-config ldap-auth-client nscd
# Configuring ldap-auth-config: (cam be re-run with 'dpkg-reconfigure ldap-auth-config'
Distinguished name of the search base: dc=bytesare,dc=us
LDAP server Uniform Resource Identifier: ldap:///127.0.0.1
LDAP version to use: 3
Make local root Database admin: <Yes>
Does the LDAP database require login? <No>
Does the LDAP database require login? <No>
LDAP account for root: <cn=admin,dc=bytesare,dc=us>
LDAP root account password:
Local crypt to use when changing passwd: <crypt (default)>
Configure your client settings
root@testkraxn ~ # vim /etc/ldap/ldap.conf
BASE dc=bytesare,dc=us
HOST 127.0.0.1
TLS_CACERT /etc/ssl/certs/ca-certificates.crt
Enable ldap lookups for authentication. See also: Ubuntu Wiki Check available profiles first.
root@testkraxn /home/andre # auth-client-config -l Available profiles are: cracklib kerberos_example lac_ldap ldap_example root@testkraxn /home/andre # auth-client-config -L Available types are: nss pam-account pam-auth pam-password pam-session
root@testkraxn ~ # auth-client-config -t nss -p lac_ldap root@testkraxn ~ # pam-auth-update root@testkraxn ~ # /etc/init.d/nscd restart * Restarting Name Service Cache Daemon nscd [ OK ]
Test your ldap client configuration:
(see also: youtube)
First, create a test user that exists only in the AD using a ldif file:
root@testkraxn ~ # vim test.ldif # ldaptestuser1, People, bytesare.us dn: uid=ldaptestuser1,ou=People,dc=bytesare,dc=us uid: ldaptestuser1 cn: ldaptestuser1 objectClass: account objectClass: posixAccount objectClass: top objectClass: shadowAccount shadowMax: 99999 shadowWarning: 7 loginShell: /usr/bin/zsh uidNumber: 8000 gidNumber: 117 homeDirectory: /home/ldaptestuser1 gecos: ldaptestuser1,,, userPassword: ldaptestuser1 root@testkraxn ~ # ldapadd -h 127.0.0.1 -D "cn=admin,dc=bytesare,dc=us" -f test.ldif -W adding new entry "uid=ldaptestuser1,ou=People,dc=bytesare,dc=us" root@testkraxn ~ # ldapsearch -x -b 'ou=People,dc=bytesare,dc=us' '(cn=ldaptestuser1)' # extended LDIF # base <ou=People,dc=bytesare,dc=us> with scope subtree # filter: (cn=ldaptestuser1) # ldaptestuser1, People, bytesare.us dn: uid=ldaptestuser1,ou=People,dc=bytesare,dc=us ...
Login as the new user to verify that ldap authentication works. The user only exists in the ldap database and he is able to logon.
root@testkraxn ~ # tail -fn0 /var/log/auth.log & [1] 6221 root@testkraxn ~ # su ldaptestuser1 Apr 17 17:39:52 testkraxn su[6231]: Successful su for ldaptestuser1 by root Apr 17 17:39:52 testkraxn su[6231]: pam_unix(su:session): session opened for user ldaptestuser1 by tester(uid=0)
Remove the test user after the test:
root@testkraxn ~ # ldapdelete -h 127.0.0.1 -W -D "cn=admin,dc=bytesare,dc=us" "uid=ldaptestuser1,ou=People,dc=bytesare,dc=us"
Configure other applications to use ldap authentication
Joomla
Because joomla is written in php, we need to make sure the necessary packages are installed. If they are not installed, joomla will just serve a blank page with no error messages indicating why - troubleshooting did indeed eat a few hours.
root@testkraxn ~ # apt-get install php5-ldap
Open up the joomla administrator interface and navigate to
Extensions ->
Plugin Manager ->
Authentication - LDAP.
Configure the settings according to your server, here i will use the server described above.
Host: 127.0.0.1 Port: 389 LDAP V3: Yes Negotiate TLS: No Follow Referrals: No Authorisation Method: Bind Directly as User Base DN: dc=bytesare,dc=us Search String: uid=[search],ou=People,dc=bytesare,dc=us User's DN: uid=[username],ou=People,dc=bytesare,dc=us Connect Username: (blank) Connect Password: (blank) Map - Full Name: cn Map - email: mail Map - User ID: uid
Note: Under some circumstances, you might lock yourself out by enabling the ldap plugin.
To prevent this, always stay logged in as an administrator while playing with the
authentication plugins so you can disable the plugin anytime.
You can test the authentication apart from the admin interface, just use the
non-administrative login to verify if the plugin works.
1. Make sure that the LDAP Plugin is enabled
2. Create a ldap user in your AD like in the previous chapter.
3. Also create a user with the same name in joomla, make sure to not provide a password.
4. Try to login as ldaptestuser1 on the home page.
Voilà - The user is logged in without telling his password to joomla!
5. Delete the testuser like in the previous chapter from the AD.
- Details
- Written by: andre
- Category: Linux Server Admin Guide
- Hits: 24515
This article describes how to setup a SFTP server installation,
plus some advices from a security point of view.
The users will find themselves inside a chrooted environment, and
the file system permissions are active:
Every user may have a seperated, isolated environment.
Step 1: Prepare your system
Create a group for users that are allowed to use sftp, and add some users to it. Since those users communicate with the ssh server without needing a login shell, we will disable shell access for them by setting /bin/false as login shell.
root@testkraxn /home/tester # groupadd sftponly root@testkraxn /home/tester # cat /etc/group | tail -n 1 sftponly:x:1001: root@testkraxn /home/tester # useradd garfield -d / -g 1001 -M -N -o -u 1001 root@testkraxn /home/tester # passwd garfield Enter new UNIX password: Retype new UNIX password: passwd: password updated successfully root@testkraxn ~tester # chsh garfield Changing the login shell for garfield Enter the new value, or press ENTER for the default Login Shell [/bin/sh]: /bin/false root@testkraxn /home/tester # cat /etc/passwd | tail -n 1 garfield:x:1001:1001::/:/bin/false
Step 2: Configure the SSH Server
root@testkraxn /home/tester # cp /etc/ssh/sshd_config /etc/ssh/sshd_config.`date +%F_%T`.backup root@testkraxn /home/tester # vim /etc/ssh/sshd_config
replace line:
Subsystem sftp /usr/lib/openssh/sftp-server
with
Subsystem sftp internal-sftp
Then, append these lines at the end of the file:
Match group sftponly ChrootDirectory /var/www X11Forwarding no AllowTcpForwarding no ForceCommand internal-sftp
my whole config, to be complete here:
root@killerkraxn ~ # grep -vE '^\s*(#.*|)$' /etc/ssh/sshd_config Port 22 Protocol 2 HostKey /etc/ssh/ssh_host_rsa_key HostKey /etc/ssh/ssh_host_dsa_key UsePrivilegeSeparation yes KeyRegenerationInterval 3600 ServerKeyBits 768 SyslogFacility AUTH LogLevel INFO LoginGraceTime 120 PermitRootLogin yes StrictModes yes RSAAuthentication yes PubkeyAuthentication yes IgnoreRhosts yes RhostsRSAAuthentication no HostbasedAuthentication no PermitEmptyPasswords no ChallengeResponseAuthentication no X11Forwarding yes X11DisplayOffset 10 PrintMotd no PrintLastLog yes TCPKeepAlive yes AcceptEnv LANG LC_* Subsystem sftp internal-sftp UsePAM yes Match group sftponly ChrootDirectory /data/sftpusers X11Forwarding no AllowTcpForwarding no ForceCommand internal-sftp
Step 2: Create some test directories
I use a script like this to create a new user: (run as root)
NEW_USER=$1 echo crating user: $NEW_USER useradd $NEW_USER -d / -G sftponly -M -s /bin/false groups $NEW_USER cd /data/sftpusers echo "setting up home directories..." mkdir $NEW_USER chown root:$NEW_USER $NEW_USER chmod 750 $NEW_USER mkdir $NEW_USER/readonly chmod 755 $NEW_USER/readonly echo "you cannot change this file" > $NEW_USER/readonly/test.txt chmod 644 $NEW_USER/readonly/test.txt mkdir $NEW_USER/readwrite echo "delete me if you wish" > $NEW_USER/readwrite/test.txt chown $NEW_USER:$NEW_USER -R $NEW_USER/readwrite mkdir $NEW_USER/no-access chmod 700 $NEW_USER/no-access echo "you won't ever read this, douchebag!" > $NEW_USER/no-access/test.txt echo "you should set a password for the user: passwd $NEW_USER"
If you want to provide access to other folders to the users, you can mount
the directory into the users base dir.
In this example, i will grant access to /media/misc/foo to the user garfield:
root@testkraxn ~ # mkdir -p /data/sftpusers/garfield/media root@testkraxn ~ # mount --bind /media/misc/foo /data/sftpusers/garfield/media
Finally, the directory structure for the user looks like this:
root@killerkraxn /data/sftpusers # tree . └── garfield ├── no-access │ └── test.txt ├── readonly │ └── test.txt ├── readwrite │ └── test.txt └── misc └── foo --> mountpoint of /media/misc/foo └── foo-contents
Restart the ssh server and test the setup:
root@testkraxn ~ # service ssh restart
andre@buenosaires ~ % sftp garfield@ 192.168.56.102 garfield@ 192.168.56.102's password: Connected to 192.168.56.102. sftp> cd / sftp> pwd Remote working directory: / sftp> ls foo readonly readwrite no-access sftp> cd no-access sftp> pwd Remote working directory: /no-access sftp> ls remote readdir("/no-access"): Permission denied sftp> cd /readwrite sftp> mkdir bar sftp> ls bar test.txt sftp> cd /readonly sftp> mkdir bar Couldn't create directory: Permission denied sftp> ls test.txt sftp> cd /misc sftp> pwd Remote working directory: /misc sftp> ls foo sftp> exit
And the users do not have access to a shell when trying to connect via ssh:
andre@buenosaires ~ % ssh garfield @192.168.56.102 garfield@ 192.168.56.102's password: This service allows sftp connections only. Connection to 192.168.56.102 closed.
- Details
- Written by: andre
- Category: Linux Server Admin Guide
- Hits: 22731
My SSH command collection (Collected in the WWW)
-
Enable automatic ssh login using a keyfile
You might use the ssh-keygen program to create the keyfiles.
Create a initial ~/.ssh/config file on the client, if not yet present:
This will enable SSH authentication without needing a password.testuser@clienthost $ { echo 'Host *'; echo "IdentityFile ~/.ssh/`whoami`"; } > ~/.ssh/config && chmod 600 ~/.ssh/config
On CLIENT machine, create private/public key pair, if not yet present.
(This will create the files ~/.ssh/testuser and ~/.ssh/testuser.pub.)testuser@clienthost $ ssh-keygen -t rsa -f ~/.ssh/`whoami` && chmod 600 ~/.ssh/`whoami`
Install your public key on the REMOTE machine:testuser@clienthost $ cat ~/.ssh/`whoami`.pub \ | ssh remoteuser@remotehost 'cat >> ~/.ssh/authorized_keys'
Or
ssh-copy-id remoteuser@remotehost
Final step, add your private key to your ssh-agent. Otherwise you will get prompted to enter your passphrase every time you try to connect to the remote host.
ssh-add ~/.ssh/`whoami`
-
Create a tunneled proxy to a remote host
ssh -N -L9080:localhost:80 theremotehost
To browse to the remote machine, goto: http://localhost:9080/
-
Connect machine A to machine B through machine C
Scenario:
Host A wants to connect to host B on port 443, but they cannot speak directly.
A third host, C, can access B on port 443, and is able to ssh to host A.
On host C, ssh to host A and create a tunnel that listens on A:1234 and forwards traffic to B:443.johndoe@host_C:~$ ssh -N -R 1234:host_B:443 johndoe@host_A
On host A, localhost:1234 can now be used to access B:443 through the tunnel:
johndoe@host_A:~$ wget --spider https://localhost:1234 --no-check-certificate 2>&1 | grep 200 HTTP request sent, awaiting response... 200 OK
-
Setup port forwarding to a remote host
ssh theuser@remotehost -L 12345:localhost:80
To access the remote service through the tunnel, visit: http://localhost:12345/
(This function is not limited to http, every protocol may work) -
Compare a local file with a remote file
ssh username@remotehost1 cat /path/to/remote-file | diff /path/to/local-file -
Useful for checking if there are differences between local and remote files.
-
Mount folder/filesystem through SSH
sshfs username@remotehost1:/path/to/remotefolder /path/to/localmountpoint
See sshfs website for installation instructions and documentation.
This is very convenient, having a remote folder accessible like a local dir. -
SSH connection through host in the middle
ssh -t username@remotehost1 ssh endpointhost
This will chain the ssh connection. Useful when you are not permitted to access the endpointhost from your current host, but from remotehost1.
-
Copy from host1 to host2, through your host
ssh username1@remotehost1 "cd /somedir/tocopy/ && tar -cf - " | ssh username2@remotehost2 "cd /samedir/tocopyto/ && tar -xf -"
Good if only you have access to remotehost1 and remotehost2, but they have no access to your host and they have no direct access to each other.
-
Run a GUI tunnelled
ssh -fX username@remotehost1 xclock
The SSH server configuration requires:
X11Forwarding yes
-
Resume scp of a big file
rsync -partial -progress -rsh=ssh /path/to/localfile username@remotehost1:/path/to/remotefile
It can resume a broken/interrupted download using rsync.
-
Throttle bandwidth with cstream
tar -cj /local/file | cstream -t 123k | ssh username@remotehost1 "tar -xj -C /remote/path"
This copies a compressed folder over the network to username@remotehost1 at 123k bit/s.
- Details
- Written by: andre
- Category: Linux Server Admin Guide
- Hits: 20708
Create video files
To be compatible to almost any device and os, we will
create three converted versions of the video file using ffmpeg.
a script like this will create them:
#!/bin/bash INPUTFILE="$1" if [ "x" = "x$INPUTFILE" ] ; then echo error: you need to name an input file exit 1 fi OUTPUTFILE="$(basename $INPUTFILE | sed 's/\.[a-z0-9]*$/__converted/g')" echo $OUTPUTFILE echo echo echo now converting to MP4 format... echo avconv \ -threads 4 \ -i "$INPUTFILE" \ -i_qfactor 0.71 \ -qcomp 0.6 \ -qmin 10 \ -qmax 63 \ -qdiff 4 \ -trellis 0 \ -vcodec libx264 \ -s 720x576 \ -b:v 8000k \ -b:a 56k \ -ar 22050 \ "$OUTPUTFILE.mp4" echo echo echo now converting to OGV format... echo avconv \ -i "$INPUTFILE" \ -s 720x576 \ -qmax 63 \ -b:v 8000k \ -b:a 56k \ -ar 22050 \ -acodec libvorbis \ "$OUTPUTFILE.ogv"
Put the video onto your website
Then copy the files to the server and embed a videotag like this:
<video id="sampleMovie" width="640" height="360" preload controls> <source src="/cms/video.mp4" type='video/mp4; codecs="avc1.42E01E, mp4a.40.2"' /> <source src="/cms/video.ogv" type='video/ogg; codecs="theora, vorbis"' /> </video>
Embedded via html5 video tag:
MP4:
OGV:
MP4 + OGV:
Further references:
Very good test page
Article for video conversion
Reference for HTML5 Tags
- Details
- Written by: andre
- Category: Linux Server Admin Guide
- Hits: 24844
Step 1: Prepare your system
Install subversion, if not yet done:
root@testkraxn ~ # which svn svn not found root@testkraxn ~ # apt-get update root@testkraxn ~ # apt-get install subversion The following NEW packages will be installed: libapr1 libaprutil1 libdb4.8 libneon27-gnutls libsvn1 subversion Do you want to continue [Y/n]? y
Create a single user and run the subversion server as that user. Be sure to make the repository in the filesystem owned by the subversion user as well. From a security point of view, this keeps the repo data well isolated and protected by filesystem permissions, changeable by only the Subversion server process itself.
root@testkraxn ~ # useradd -d /home/subversion -m subversion root@testkraxn ~ # usermod -a -G subversion subversion root@testkraxn ~ # chsh subversion # to whatever you prefer
root@testkraxn ~ # cd ~subversion root@testkraxn ~ # mkdir ~subversion/svn-data root@testkraxn ~ # chown subversion:subversion -R ~subversion/svn-data
Place a link in the filesystem so we can later access with svn://host:1111/svn/projectX
root@testkraxn ~ # ln -s /home/subversion/svn-data /svn
Step 2: Create a repository
root@testkraxn ~subversion # su subversion subversion@testkraxn ~ % cd svn-data subversion@testkraxn ~/svn-data % svnadmin create projectX
Edit your svnserve.conf like this:
subversion@testkraxn ~/svn-data % vim projectX/conf/svnserve.conf subversion@testkraxn ~/svn-data % grep -vE '^\s*(#.*|)$' projectX/conf/svnserve.conf [general] anon-access = none auth-access = write password-db = passwd authz-db = authz [sasl]
Place your svn users here:
subversion@testkraxn ~/svn-data % vim projectX/conf/passwd subversion@testkraxn ~/svn-data % grep -vE '^\s*(#.*|)$' projectX/conf/passwd [users] andre = asdf27
Step 3: Start and test the svn server daemon process
subversion@testkraxn ~/svn-data % svnserve -d subversion@testkraxn ~/svn-data % sudo su root@testkraxn ~ # nmap -sS localhost PORT STATE SERVICE 22/tcp open ssh 3690/tcp open svn <-- you should see this line
Now you should be able to checkout on localhost and from other hosts:
subversion@testkraxn ~/svn-data/projectX % cd /tmp subversion@testkraxn /tmp % svn co svn://localhost/svn/projectX projectX subversion@testkraxn /tmp % cd projectX subversion@testkraxn /tmp/projectX % svn info Repository Root: svn://localhost/svn/projectX subversion@testkraxn /tmp/projectX % echo hello > test.txt subversion@testkraxn /tmp/projectX % svn add test.txt A test.txt subversion@testkraxn /tmp/projectX % svn ci -m "hello world test" subversion@testkraxn /tmp/projectX % svn update At revision 1.
or from another host:
anotheruser@anotherhost ~ % svn co svn://vbox0/svn/projectX projectX A projectX/test.txt Checked out revision 1.
Step 4: Configure svn over ssh
This will improve security and convenience, since the users do not need a separate svn user and they can authenticate with a keyfile instead of typing and storing their passwords.
The following requirements must be given:
- The authentication must use the systems unix user acconts. We do not want to manage a new user/password mapping for everybody.
- In the configuration, we need to be able control the following:
- Put users into groups and enable group based authentication rules.
- Specify separate permissions for every directory.
Example:
On our system, we have two users:
tester (the one that has readwrite access) leser (the one that cannot commit)
Both accounts are existing on the machine and are able to login via ssh.
Set file system permissions. Users not in group subversion are locked out:
root@testkraxn /etc/ssh # cd ~subversion root@testkraxn ~subversion # ls -l drwxrwxr-x 3 subversion subversion 4096 Dec 3 14:58 svn-data/ root@testkraxn ~subversion # chown subversion:subversion -R svn-data # to be sure :D root@testkraxn ~subversion # chmod o-rwx -R svn-data root@testkraxn ~subversion # ls -l drwxrwx--- 3 subversion subversion 4096 Dec 3 14:58 svn-data/
Put users to group "subversion". This will allow to access the svn repository.
root@testkraxn /etc/ssh # usermod -G subversion tester root@testkraxn /etc/ssh # groups tester tester : tester subversion
Edit your authz file like this:
subversion@testkraxn ~/svn-data % cat projectX/conf/authz [aliases] [groups] committergroup = tester readgroup = leser, tester [/] # relative to project root # allow nothing by default: * = @readgroup = r @committergroup = rw [/tags] * = committergroup = rw
After this, you should be able to use the svn repo like this:
andrer@caracas ~ svn co svn+ssh://tester@vbox0/svn/projectX/trunk rw Checked out revision 7.Tutorial
another Reference
Optional: Setup websvn viewer for your server
DRAFT
******* install web svn (http://www.websvn.info) ******** root@virtubuntu ~ # apt-get install websvn or download bin from http://websvn.tigris.org/files/documents/1380/49057/websvn-2.3.3.zip ******* setup test repo ******** root@virtubuntu /var/lib # mkdir svn root@virtubuntu /var/lib # cd svn root@virtubuntu /var/lib/svn # svnadmin create helloworld root@virtubuntu /var/lib/svn # ls -l drwxr-xr-x 6 tester tester 4096 Sep 12 20:22 helloworld/ root@virtubuntu ~ # dpkg-reconfigure websvn Apache configuration: [*] apache2 svn parent repositories: /var/lib/svn/helloworld (apache runs as root in my case, so i do not bother.) open a browser, and goto: http://localhost/websvn/
Optional: Migrate SVN projects to avoid permission problems with websvn
DRAFT
If needed with this script you can migrate your projects to the fsfs file system type.
Note on permissions
Due to a limitation in the DB format, the 'svnlook' command needs read-write access to the repository (to create locks etc).
You need to give read-write permissions to the user running your webserver on all your repositories.
Another way of avoiding this problem is by creating SVN repositories with the --fs-type=fsfs option.
Existing DB repositories can be converted to the FSFS format by using the svnadmin dump/load commands.
******* setup in filesystem ********* I want to convert all projects that are in directory "public". The target directory is "migration-stage" andre@killerkraxn /data/subversion/svn-data/andre % ls -l drwx------ 5 andre andre 4096 2013-07-30 18:41 private/ drwxrwxr-x 36 andre andre 4096 2013-02-13 18:54 public/ andre@killerkraxn /data/subversion/svn-data/andre % ./migrate.sh public # see below ******* migrate.sh script ********* #!/bin/bash sourceRootDir="$1" migratedRootDir="migration-stage" mkdir -p "$migratedRootDir" find "$sourceRootDir" -type d -mindepth 1 -maxdepth 1 \ | sort \ | while read sourceRepo do migratedRepo="${migratedRootDir}${sourceRepo#$sourceRootDir}" dumpFile="$migratedRepo.dump" echo "migrating repository $sourceRepo to $migratedRepo ..." echo "1. create new repo with correct fs type: $migratedRepo" svnadmin create --fs-type=fsfs "$migratedRepo" echo "2. create svn dump to: $dumpFile" svnadmin dump "$sourceRepo" > "$dumpFile" echo "3. drop the dump in the new repo" cat "$dumpFile" | svnadmin load "$migratedRepo" echo "done with migration of $sourceRepo"; echo done ******** example output ********* migrating repository public/web-jsf2-getstarted to migration-stage/web-jsf2-getstarted ... 1. create new repo: migration-stage/web-jsf2-getstarted 2. create svn dump to: migration-stage/web-jsf2-getstarted.dump * Dumped revision 0. * Dumped revision 1. [...] * Dumped revision 11. * Dumped revision 12. 3. drop the dump in the new repo <<< Started new transaction, based on original revision 1 * adding path : branches ... done. * adding path : tags ... done. * adding path : trunk ... done. ------- Committed revision 1 >>> <<< Started new transaction, based on original revision 2 * editing path : trunk ... done. * adding path : trunk/pom.xml ... done. * adding path : trunk/web ... done. * adding path : trunk/web/WEB-INF ... done. * adding path : trunk/web/WEB-INF/web.xml ... done. ------- Committed revision 2 >>> <<< Started new transaction, based on original revision 3 [...] <<< Started new transaction, based on original revision 11 * editing path : trunk/pom.xml ... done. ------- Committed revision 11 >>> <<< Started new transaction, based on original revision 12 * editing path : trunk/web/WEB-INF/web.xml ... done. ------- Committed revision 12 >>> done with repo public/web-jsf2-getstarted