Я пытаюсь добавить HTTP-доступ только для чтения к существующему svn репозиторий, при этом разрешая доступ на запись через svn+ssh.
Я установил Apache, mod_dav_svn и т. Д. И указал Apache на svn репозиторий, но когда я пытаюсь получить доступ к репо через HTTP, я получаю следующую ошибку:
Could not open the requested SVN filesystem
Когда я смотрю error_log для Apache, я вижу, что он не может открыть format файл в моем репозитории. Этот файл доступен для чтения всем, но никто не может его записать, и, похоже, он работает для svn+ssh доступ. Как я могу решить проблему для Apache, не влияя на svn+ssh доступ для разработчиков?
Спасибо.
ОБНОВИТЬ: Похоже, это не ограничивается существующим репо. Я только что создал новое тестовое репо, запустил chown -R apache:apache на нем, и у меня все еще та же проблема. Я подтвердил, что apache пользователь делает иметь права на выполнение для каждого каталога на пути к format и прочтите разрешения на format. Однако, если я создаю тестовое репо где-нибудь в дереве каталогов, которое Apache использует в качестве корня документа, все работает нормально. Апач chrooted (или аналогичный) на CentOS 5.3? Если да, могу ли я это обойти? Еще раз спасибо.
Я думаю, вы можете добиться этого, создав svn group и размещение всех ваших пользователей, а также пользователя apache (или www-run, или любого другого пользователя, под которым работает apache) в группу. Затем вы можете изменить разрешения репозитория, чтобы он принадлежал svn группа.
При этом я думаю, что предпочтительным путем было бы перенести все на WebDAV. Причина здесь в том, что для работы svn + ssh пользователи должны иметь прямой доступ для записи в репозиторий, а также доступ SSH к серверу. Это создает большой потенциал для повреждения репозитория, а также другие потенциальные риски безопасности.
С помощью WebDAV пользователи могут выполнять операции только через сервер WebDAV. У этого подхода есть много преимуществ, включая, помимо прочего, детальный контроль доступа, дополнительные параметры аутентификации, аудит и т. Д.
Похоже на проблему с SELinux ... есть ли у вас отказы в /var/log/audit/audit.log?