The entry or revision was not found in the repository.

След кратка справка в log директорията на redmine, се оказа че имам един нов log файл – scm.stderr.log. Ето и грешките от него:

/libexec/ld-elf.so.1: Cannot open „/usr/local/lib/libdb-4.2.so.2″
/libexec/ld-elf.so.1: Cannot open „/usr/local/lib/libdb-4.2.so.2″
/libexec/ld-elf.so.1: Cannot open „/usr/local/lib/libdb-4.2.so.2″
/libexec/ld-elf.so.1: Cannot open „/usr/local/lib/libdb-4.2.so.2″
/libexec/ld-elf.so.1: Cannot open „/usr/local/lib/libdb-4.2.so.2″
/libexec/ld-elf.so.1: Cannot open „/usr/local/lib/libdb-4.2.so.2″

Всички проблеми изчезнаха след изпълняването на:
chmod -R a+rX /usr/local/lib/db42

Application error
Rails application failed to start properly

А ето и какво показваше error лога на apache-то:

Request exceeded the limit of 10 internal redirects due to probable configuration error. Use ‘LimitInternalRecursion’ to increase the limit if necessary. Use ‘LogLevel debug’ to get a backtrace

Проблема се оказа в .htaccess файла на redmine, който беше заменен с нов такъв след upgrade-a. Решението e да се коментира всичко свързано с fastcgi и cgi и да остане само fcgid. Ето и кое точно коментирах аз на две места в този файл – в началото:

# General Apache options
#< IfModule mod_fastcgi.c >
# AddHandler fastcgi-script .fcgi
#< /IfModule >
< IfModule mod_fcgid.c >
AddHandler fcgid-script .fcgi
< /IfModule >
#< IfModule mod_cgi.c >
# AddHandler cgi-script .cgi
#< /IfModule >
Options +FollowSymLinks +ExecCGI

И в края:

RewriteCond %{REQUEST_FILENAME} !-f
#< IfModule mod_fastcgi.c >
# RewriteRule ^(.*)$ dispatch.fcgi [QSA,L]
#< /IfModule >
< IfModule mod_fcgid.c >
RewriteRule ^(.*)$ dispatch.fcgi [QSA,L]
< /IfModule >
#< IfModule mod_cgi.c >
# RewriteRule ^(.*)$ dispatch.cgi [QSA,L]
#< /IfModule >


След тези дребни модификации по .htaccess файла в redmine грешката в apache лог файла вече се промени на следното:

mod_fcgid: error reading data, FastCGI server closed connection
Premature end of script headers: dispatch.fcgi

За да разберем какво точно се случва можем да стартираме през конзолата dispatch.fcgi от redmine/public директориятя. Ето и резултата от изпълнението:

[root@redmine/public]# ./dispatch.fcgi
./../config/../vendor/rails/railties/lib/rails/gem_dependency.rb:119:Warning: Gem::Dependency#version_requirements is deprecated and will be removed on or after August 2010. Use #requirement

Оказа се, че част от библиотеките необходими за стартирането на redmine и намиращи се в /usr/local/lib/ruby са без необходимите права. Решението е да дадем права на всеки един потребител да чете и изпълнява тези файлове:

chmod -R a+rx /usr/local/lib/ruby/

След тази последна намеса redmine заработи както обикновенно.

[root@myserver /usr/ports]# cd /usr/ports/devel/subversion
[root@myserver /usr/ports/devel/subversion]# make install clean

Тук всичко би трябвало да мине безпроблемо. Ще ми се да отбележа, че Subversion зависи от sqlite3, а той „отказва“ да се компилира с -ffast-math. За инсталирането на sqlite, временно махнах тази опция от /etc/make.conf и след това отново я върнах обратно. След като приключим с инсталацията, създаваме svn потребител и група.

[root@myserver /var]# adduser
Username: svn
Full name: SVN Repository
Uid (Leave empty for default):
Login group [svn]:
Login group is svn. Invite svn into other groups? []:
Login class [default]:
Shell (sh csh tcsh bash rbash nologin) [sh]: bash
Home directory [/home/svn]: /var/svn
Home directory permissions (Leave empty for default):
Use password-based authentication? [yes]: no
Lock out the account after creation? [no]:
adduser: INFO: Successfully added (svn) to the user database.

Home директорията, на този потребител всъщност е директорията, в която ще съхраняваме хранилищата. Аз избрах това да е /var/svn. Трябва да променим правата за достъп до тази директорията, така че всички от svn групата да имат пълен достъп до нея. Идеята е, всеки който принадлежи към svn групата, да има достъп до хранилищата.

[root@myserver /var]# chmod g+rwx svn
[root@myserver /var]# chmod o-rwx svn
drwxrwx— 2 svn svn 512 Nov 27 17:18 svn

Последно, трябва да променим и umask на svn потребителя. По подразбиране, той е 022. Ще го направим 007, така че групата да има пълен достъп до файловете. Понеже за shell избрахме bash, файлът в който трябва да направим това, ще бъде .bashrc. За целта, като svn потребител създаваме .bashrc и добавяме вътре „umask 0007″.

[root@myserver /var]# su svn
[svn@myserver /var]$ cd
[svn@myserver ~]$ touch .bashrc

Ето как би трябвало да изглежда .bashrc след тази промяна.

[svn@myserver ~]$ cat .bashrc
# Change umask
umask 0007

Трябва да добавим всички потребители, които искаме да достъпват хранилищата към svn групата, за целта редактираме /etc/group. Аз добавих само себе си към тази група. Ето как изглежда при мен реда със svn групата.

svn:*:1003:saiman

За да достъпвам по-лесно svn хранилищата, направих връзка от /svn към /var/svn.

[root@myserver /var]# ln -s /var/svn/ /svn

Последно, отново като svn потребител, създаваме хранилище.

[svn@myserver /svn]$ svnadmin create repo

За да се уверя, че всичко работи реших да се свържа към сървъра посредством ssh, изтегля хранилището и добавя един тестов файл.

saiman@mylaptop:/media/sda2/home/saiman/svnroot$ svn co svn+ssh://myserver.com/svn/repo
Checked out revision 0.
saiman@mylaptop:~/svnroot/repo$ svn add test.txt
A test.txt
saiman@mylaptop:~/svnroot/repo$ svn ci
Adding test.txt
Transmitting file data .svn: Commit failed (details follow):
svn: attempt to write a readonly database
svn: attempt to write a readonly database
svn: Your commit message was left in a temporary file:
svn: ‘/media/sda2/home/saiman/svnroot/repo/svn-commit.tmp’

Явно не работеше, така както очаквах. Оказа се, че repo/db/rep-cache.db, който се създава от svnadmin е без права за писане на групата. За да заработят нешата, трябва да променим правата на групата за този файл.

[svn@myserver /svn]$ chmod g+rwx repo/db/rep-cache.db

След тази последна намеса от наша страна, всичко би трябвало да заработи нормално.

<VirtualHost *:80>
ServerAdmin my@email.com
DocumentRoot /www/saiman.thefreeart.com/httpd/
ServerName www.saiman.thefreeart.com
ServerAlias saiman.thefreeart.com

<Directory /www/saiman.thefreeart.com/httpd/ >
php_admin_value open_basedir „/www/saiman.thefreeart.com/httpd/:/var/tmp/“

Options Indexes MultiViews
AllowOverride None
Order allow,deny
allow from all
</Directory>
</VirtualHost>

В заключение искам да кажа, че посредством open_basedir не се решават всички проблеми свързани със сигурността, safe_mode също не е достатъчно надежден, а и в php 6 ще бъде премахнат, остава Suhosin Patch, който според мен е задължителен за инсталиране.