Окружение разработки: Redmine + Git + ownCloud

Данная статья появилась с целью обобщить довольно длительные попытки собрать удобное окружение для работы над проектами. Несомненно, существует множество сервисов готовых предоставить схожую функциональность, но их использование не всегда удобно и по различным причинам, может быть неприемлемо. Если возникла такая ситуация, надеюсь, представленная в статье конфигурация окажется полезной.

Сценарий использования данной связки, можно кратко описать следующим образом:

• Файлы проекта хранятся в Git репозитории;
• Репозиторий содержит настройки, исходники и другие файлы проекта, наличие которых удобно и допустимо в коллективном репозитории;
• В корне расположена директория cloud, исключенная в .gitignore, в которую через WebDAV монтируется ownCloud папка, для остальных файлов;
• Содержимое Git репозитория отслеживается в системе управления проектами Redmine.

План развертывания системы включает настройку следующих сервисов:

1. OpenLDAP — единая учётная запись для всех сервисов;
2. Redmine — запуск в Docker контейнере, создание и привязка Git репозитория, LDAP аутентификация;
3. NGINX — доступ к Git репозиторию через HTTPS и LDAP аутентификация;
4. ownCloud — LDAP аутентификация и монтирование папки через davfs2.

Жёсткой привязки к дистрибутиву и операционной системе, здесь нет. Однако у меня на сервере Linux дистрибутив Gentoo, на клиенте — Kubuntu, поэтому некоторые примеры будут иметь специфические особенности.

Для удобства воспроизведения часть примеров содержит предустановленные пароли. Поэтому настоятельно рекомендую вместо метки [ВНЕШНИЙ_IP] использовать локальный IP, не доступный извне, либо сразу менять пароли на надёжные.

OpenLDAP

LDAP — это протокол доступа к данным, организованным в виде директорий. Здесь будет рассмотрена его реализация — OpenLDAP. Данный сервис представляет собой по сути базу данных оптимизированную для хранения древовидных структур, таких как каталоги. В данном случае важно, что LDAP хорошо подходит для хранения данных пользователя и является стандартом, который так или иначе поддерживает большинство сервисов работающих с учетными записями пользователей.

Минимально необходимая конфигурация:

# /etc/openldap/slapd.conf  include		/etc/openldap/schema/core.schema include		/etc/openldap/schema/cosine.schema include		/etc/openldap/schema/inetorgperson.schema include		/etc/openldap/schema/nis.schema  # Необходимо разрешить чтение записи cn=Subschema для всех. access to dn.base="" by * read access to dn.base="cn=Subschema" by * read  # Разрешение на чтение для cn=manager,dc=example,dc=com. # Нужно, чтобы не использовать rootdn при настройке сторонних сервисов. access to dn.regex=".+,dc=example,dc=com$" 	by self write 	by dn.exact="cn=manager,dc=example,dc=com" read 	by anonymous auth  # Всем остальным разрешить только авторизацию и изменение своих записей. access to * 	by self write 	by anonymous auth 	by * none  pidfile		/var/run/openldap/slapd.pid argsfile	/var/run/openldap/slapd.args  # Бинарное поле задающие уровень отладочной информации в логах. # Обычно хватает 1 или 2, в тяжелых случаях - 256 (максимум 2048). loglevel 0  modulepath    /usr/lib64/openldap/openldap  # Сертификаты для поддержки LDAPS. TLSCertificateFile	/etc/ssl/openldap/server.pem TLSCertificateKeyFile	/etc/ssl/openldap/server.key  ### Основная база данных  database	hdb # Директория должна существовать и иметь права 700 и владельца ldap:ldap. directory	/var/lib/openldap-data # Суффикс запросов, предназначенных этой базе. suffix		"dc=example,dc=com" # DN (Distinguished Name) на которую не распространяются ограничения в правах. # Физическое наличие в БД этой записи не обязательно. rootdn		"cn=admin,dc=example,dc=com" # Пароль к rootdn, создается с помощью slappasswd -s [пароль] # Здесь для примера использован пароль: passwd rootpw		{SSHA}70m8+2axDu++Adp6EOLPVpISPxbMVPFv  # Оверлей для добавление к записи пользователя атрибута memberOf с DN группы, в которой он упомянут. moduleload memberof.la overlay memberof memberof-group-oc groupOfUniqueNames memberof-member-ad uniqueMember memberof-refint true  # Оверлей для поддержания ссылочной целостности. # При удалении пользователя, записи о нем в группах, также удаляются. moduleload refint.la overlay refint refint_attributes uniqueMember # Пустая группа не допустима. Очевидное решение, добавить администратора. refint_nothing "cn=admin,dc=example,dc=com"  # Индексы для базы данных. index   objectClass                             eq index   uid,uidNumber,gidNumber,memberUid       eq 

Для наглядности конфигурация здесь записана в файле slapd.conf, однако начиная с OpenLDAP версии 2.4 данный файл объявлен устаревшим. Новый формат называется OLC (on-line configuration) и представлен в виде базы данных config. Удобен он тем, что изменение настроек больше не требует перезагрузки сервиса.

Для миграции на OLC необходимо в конец файла slapd.conf добавить:

### База данных с настройками  # Изменять настройки разрешено только суперпользователю (root) через сокет. # Ex: ldapadd/ldapmodify -Q -Y EXTERNAL -H ldapi:/// -f [config_update].ldif database config access to * 	by dn.exact="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" manage 	by * none 

И выполнить команды:

mkdir -p /etc/openldap/slapd.d # Если slapd ещё не запускался, ошибку об отсутствии файла базы данных можно игнорировать. slaptest -f /etc/openldap/slapd.conf -F /etc/openldap/slapd.d chown ldap:ldap -R /etc/openldap/slapd.d /var/lib/openldap-data /etc/openldap/slapd.conf chmod 750 /etc/openldap/slapd.d && chmod 640 /etc/openldap/slapd.conf 

Настройки будут записаны в указанную папку, по прежнему в текстовом виде, но редактировать вручную их уже не стоит.

Далее необходимо изменить параметры запуска демона, чтобы он читал настройки из базы данных вместо файла. В Gentoo для этого нужно изменить файл /etc/conf.d/slapd:

# /etc/conf.d/slapd  # Читать настройки из файла. #OPTS_CONF="-f /etc/openldap/slapd.conf" # Читать настройки из базы данных. OPTS_CONF="-F /etc/openldap/slapd.d" # Сервис доступен извне по протоколу ldaps; локально - ldap либо через сокет (%2f - так нужно). OPTS="${OPTS_CONF} -h 'ldaps://[ВНЕШНИЙ_IP]:636 ldap://127.0.0.1:389 ldapi://%2fvar%2frun%2fopenldap%2fslapd.sock'" 

Теперь можно запустить сервис и добавить данные:

ldapadd -x -D 'cn=admin,dc=example,dc=com' -w 'passwd' -f backup.ldif 

Для того, чтобы использовать свои пароли необходимо заменить значение полей userPassword. Новые можно получить командой:

slappasswd -s [пароль] 

При восстановлении из резервной копии важно убедиться, что записи для добавления групп расположены после записей для добавления пользователей, а лучше в самом конце скрипта, иначе оверлей memberof не сможет их корректно обработать.

Проверить, что OpenLDAP корректно настроен и работает как было задумано, можно командой:

ldapsearch -D 'cn=manager,dc=example,dc=com' -w 'passwd' -b 'ou=people,dc=example,dc=com' '(uid=example)' memberOf 

Ответ должен быть следующим:

… dn: uid=example,ou=people,dc=example,dc=com memberOf: cn=developers,ou=groups,dc=example,dc=com  # search result search: 2 result: 0 Success … 

Кроме тестового пользователя, здесь был также добавлен cn=manager,dc=example,dc=com, который будет использован в дальнейшем для доступа к базе данных. Права его должны быть минимально необходимыми, а пароль отличаться от пароля cn=admin,dc=example,dc=com, так как его придётся указывать чистым текстом в файлах настроек. Здесь использован пароль passwd, что несомненно является плохим примером.

Работа с записями в OpenLDAP далеко не самое удобное и очевидное дело, но Apache Directory Studio может существенно с этим помочь.

Redmine

Для управления проектами очень хорошо подходит веб приложение Redmine. Однако его установка требует большого числа зависимостей языка Ruby. Моя деятельность не связана с Ruby или Rails, поэтому установка на сервер дополнительных 76 пакетов, которые требовал ebuild, была не желательна. Приемлемый вариант нашёлся очень быстро — Docker контейнер sameersbn/docker-redmine.

Контейнеры удобно настраивать и запускать с помощью docker-compose. Данная утилита позволяет объединить параметры командной строки Docker в один конфигурационный файл и управлять запущенными контейнерами.

Возможности настройки docker-redmine очень широкие и работу с ним лучше сразу начать с официальной документации. Приведённый ниже пример, лишь один из вариантов, который оказался удобным в моём случае:

# /var/www/redmine.example.com/docker-compose.yml  redmine:   image: quay.io/sameersbn/redmine:3.2.0-2   # Автоматически запускать при старте системы и перезапускать в случае падения   restart: always   environment:     - TZ=Europe/Moscow     # Использовать в контейнере uid:gid локального пользователя, чтобы      # владелец файлов, на хосте в смонтированных томах, был предсказуем.     - USERMAP_UID=[NGINX_UID]     - USERMAP_GID=[NGINX_GID]     - DB_TYPE=postgres     # Docker-у требуется существенное время, чтобы поднять bridge IP (172.17.0.1), и лучше     # с ним не связывать сервисы запускаемые при старте системы. Выставлять сервис наружу,     # без крайней необходимости, тоже плохая идея. Можно добавить на сетевой интерфес IP,     # который не маршрутизируется наружу и обращаться к нему из контейнеров.     - DB_HOST=10.0.10.10     - DB_USER=redmine     - DB_PASS=[ПАРОЛЬ]     - DB_NAME=redmine_production     - REDMINE_HTTPS=true     - REDMINE_PORT=10083     - SMTP_ENABLED=true     - SMTP_OPENSSL_VERIFY_MODE=none     # Локальная MTA доверяет подсети Docker-а 172.17.0.0/16, что в данном случае приемлемо.     - SMTP_HOST=[ВНЕШНИЙ_IP]     - SMTP_PORT=25     - IMAP_ENABLED=false   ports:     - "127.0.0.1:10083:80"   volumes:     - /var/www/redmine.example.com/data:/home/redmine/data     # Чтобы далеко не ходить за логами.     - /var/www/redmine.example.com/logs:/var/log/redmine 

Запуск контейнера производится командой:

docker-compose -f /var/www/redmine.example.com/docker-compose.yml up -d 

Для того, чтобы Redmine автоматически создавал учётные записи на базе аккаунтов из OpenLDAP и использовал его механизм аутентификации необходимо добавить соответствующий метод в Administration → LDAP authentication → New authentication mode:

Name *: Example.com LDAP Host *: [ВНЕШНИЙ_IP] Port *: 636; LDAPS: x Account: cn=manager,dc=example,dc=com Password: passwd Base DN *: ou=people,dc=example,dc=com LDAP filter: (&(objectClass=person)(memberOf=cn=developers,ou=groups,dc=example,dc=com)) Timeout (in seconds): On-the-fly user creation: x  Login attribute *: uid Firstname attribute: givenName Lastname attribute: sn Email attribute: mail 

В Redmine проект можно добавлять только уже существующие Git репозитории, поэтому папка с репозиториями должна быть доступна из контейнера. Поскольку в данном случае нужно отслеживать только локально расположенные репозитории, можно ограничиться монтированием в контейнер папки с репозиториями, но это не удобно. Если потребуется подключить внешний репозиторий, то его клон придётся размещать в директории с собственными репозиториями, кроме этого монтировать в контейнер системную директорию не красиво.

В итоге у меня получились следующий набор скриптов для работы с локальными репозиториями:

#!/bin/bash set -e  # /var/git/create_repo.sh  LOCAL_GIT_DIR="/var/git" SCRIPT_NAME=`basename $0` E_OPTERROR=65  function usage() { 	echo "USAGE:" 	echo "    $SCRIPT_NAME [repo_name]" 	echo "OPTIONS:" 	echo "    repo_name - name of the new Git repository." 	exit $E_OPTERROR }  function fatal_error() { 	echo "$1" > /dev/stderr 	exit 1 }  # Проверить входные параметры. if [ $# -ne 1 ]; then 	echo "Wrong number of arguments specified." 	usage fi  REPO_NAME=$1  cd ${LOCAL_GIT_DIR} if [ -d "${REPO_NAME}" ]; then 	fatal_error "Error: the repository already exists!" fi  # Создать чистый репозиторий. mkdir ${REPO_NAME} cd ${REPO_NAME} git --bare init git update-server-info -f  # Установить хук синхронизирующий Redmine копию репозитория с данным. cd .. cp ./post-update "${REPO_NAME}/hooks/" chmod 755 "${REPO_NAME}/hooks/post-update" chown -R nginx:nginx ${REPO_NAME}  echo "Git repository successfully created." exit 0 

#!/bin/bash set -e  # /var/git/migrate_repo.sh  LOCAL_GIT_DIR="/var/git" REDMINE_GIT_DIR="/var/www/redmine.example.com/data/git" SCRIPT_NAME=`basename $0` E_OPTERROR=65  function usage() { 	echo "USAGE:" 	echo "    $SCRIPT_NAME [repo_name]" 	echo "OPTIONS:" 	echo "    repo_name - name of the existing Git repository." 	exit $E_OPTERROR }  function fatal_error() { 	echo "$1" > /dev/stderr 	exit 1 }  # Проверить входные параметры. if [ $# -ne 1 ]; then 	echo "Wrong number of arguments specified." 	usage fi  REPO_NAME=$1  if [ ! -d "${LOCAL_GIT_DIR}/${REPO_NAME}" ]; then 	fatal_error "Error: the repository does not exists!" fi  # Проверить, что ничего не будет сломано. if [ -f "${LOCAL_GIT_DIR}/${REPO_NAME}/hooks/post-update" ]; then 	fatal_error "Error: post-update hook already exists! The repository already migrated or should be migrated manually." fi  if [ -d "${REDMINE_GIT_DIR}/${REPO_NAME}" ]; then 	fatal_error "Error: redmine already contains the repository with the same name!" fi  # Установить хук синхронизирующий Redmine копию репозитория с данным. cp "${LOCAL_GIT_DIR}/post-update" "${LOCAL_GIT_DIR}/${REPO_NAME}/hooks/" chown nginx:nginx "${LOCAL_GIT_DIR}/${REPO_NAME}/hooks/post-update" chmod 755 "${LOCAL_GIT_DIR}/${REPO_NAME}/hooks/post-update"  # Создать Redmine копию репозитория. cd "${REDMINE_GIT_DIR}" git clone --mirror "${LOCAL_GIT_DIR}/${REPO_NAME}" ${REPO_NAME}  echo "Git repository successfully migrated." exit 0 

#!/bin/bash  # /var/git/post-update  # Запускается на сервере после того, как git push успешно отработает в локальном репозитории.  REDMINE_GIT_DIR="/var/www/redmine.example.com/data/git" REPO_PATH=${PWD} REPO_NAME=$(basename "${REPO_PATH}") LOG_FILE="/var/log/nginx/git_hooks_log"  function log_message() { 	echo `date '+%d-%m-%y %H:%M:%S'` "$1" >>"${LOG_FILE}" }  if [ -d "${REDMINE_GIT_DIR}" ]; then 	cd "${REDMINE_GIT_DIR}" 	if [ -d "${REPO_NAME}" ]; then 		# Если копия репозитория уже создана, загрузить изменения. 		cd "${REPO_NAME}" 		log_message "UPDATED: ${PWD}" 		exec git fetch -q --all -p &>>"${LOG_FILE}" 	else 		# Иначе создать клон репозитория. 		log_message "NEW: ${REPO_PATH} : ${REPO_NAME} : ${PWD}" 		exec git clone -q --mirror ${REPO_PATH} ${REPO_NAME} &>>"${LOG_FILE}" 	fi fi 

В случае необходимости подключить внешний репозиторий, например GitHub, его также необходимо будет клонировать в папку /var/www/redmine.example.com/data/git, затем установить задачу в cron для периодической синхронизации Redmine копии с удаленным репозиторием.

NGINX

Далее необходимо открыть доступ к репозиториям по HTTPS. К сожалению, из коробки NGINX не поддерживает LDAP авторизацию, для этого его необходимо собрать со сторонним модулем kvspb/nginx-auth-ldap.

В Gentoo для этого достаточно скопировать ebuild в локальный portage (PORTDIR_OVERLAY) и добавить в него данный модуль. В официальном ebuild подключается множество модулей, добавить ещё один не составит труда. Для актуальной на данный момент версии NGINX, у меня получился следующий патч:

--- nginx-1.8.0.ebuild	2015-08-05 14:31:19.000000000 +0300 +++ nginx-1.8.0.ebuild.new	2015-08-07 08:19:35.899578187 +0300 @@ -126,6 +126,12 @@  HTTP_MOGILEFS_MODULE_URI="http://www.grid.net.ru/nginx/download/nginx_mogilefs_module-${HTTP_MOGILEFS_MODULE_PV}.tar.gz"  HTTP_MOGILEFS_MODULE_WD="${WORKDIR}/nginx_mogilefs_module-${HTTP_MOGILEFS_MODULE_PV}"   +# http_auth_ldap (https://github.com/kvspb/nginx-auth-ldap, ??? license) +HTTP_AUTH_LDAP_MODULE_PV="master" +HTTP_AUTH_LDAP_MODULE_P="ngx_http_auth_ldap-${HTTP_AUTH_LDAP_MODULE_PV}" +HTTP_AUTH_LDAP_MODULE_URI="https://github.com/kvspb/nginx-auth-ldap/archive/${HTTP_AUTH_LDAP_MODULE_PV}.tar.gz" +HTTP_AUTH_LDAP_MODULE_WD="${WORKDIR}/nginx-auth-ldap-${HTTP_AUTH_LDAP_MODULE_PV}" +  inherit eutils ssl-cert toolchain-funcs perl-module flag-o-matic user systemd versionator multilib    DESCRIPTION="Robust, small and high performance http and reverse proxy server" @@ -148,7 +154,8 @@  	nginx_modules_http_security? ( ${HTTP_SECURITY_MODULE_URI} -> ${HTTP_SECURITY_MODULE_P}.tar.gz )  	nginx_modules_http_push_stream? ( ${HTTP_PUSH_STREAM_MODULE_URI} -> ${HTTP_PUSH_STREAM_MODULE_P}.tar.gz )  	nginx_modules_http_sticky? ( ${HTTP_STICKY_MODULE_URI} -> ${HTTP_STICKY_MODULE_P}.tar.bz2 ) -	nginx_modules_http_mogilefs? ( ${HTTP_MOGILEFS_MODULE_URI} -> ${HTTP_MOGILEFS_MODULE_P}.tar.gz )" +	nginx_modules_http_mogilefs? ( ${HTTP_MOGILEFS_MODULE_URI} -> ${HTTP_MOGILEFS_MODULE_P}.tar.gz ) +	nginx_modules_http_auth_ldap? ( ${HTTP_AUTH_LDAP_MODULE_URI} -> ${HTTP_AUTH_LDAP_MODULE_P}.tar.gz )"    LICENSE="BSD-2 BSD SSLeay MIT GPL-2 GPL-2+  	nginx_modules_http_security? ( Apache-2.0 ) @@ -180,7 +187,8 @@  	http_push_stream  	http_sticky  	http_ajp -	http_mogilefs" +	http_mogilefs +	http_auth_ldap"    IUSE="aio debug +http +http-cache ipv6 libatomic luajit +pcre pcre-jit rtmp  selinux ssl userland_GNU vim-syntax" @@ -220,7 +228,8 @@  	nginx_modules_http_auth_pam? ( virtual/pam )  	nginx_modules_http_metrics? ( dev-libs/yajl )  	nginx_modules_http_dav_ext? ( dev-libs/expat ) -	nginx_modules_http_security? ( >=dev-libs/libxml2-2.7.8 dev-libs/apr-util www-servers/apache )" +	nginx_modules_http_security? ( >=dev-libs/libxml2-2.7.8 dev-libs/apr-util www-servers/apache ) +	nginx_modules_http_auth_ldap? ( net-nds/openldap )"  RDEPEND="${CDEPEND}  	selinux? ( sec-policy/selinux-nginx )  " @@ -440,6 +449,11 @@  		myconf+=" --add-module=${HTTP_MOGILEFS_MODULE_WD}"  	fi   +	if use nginx_modules_http_auth_ldap; then +		http_enabled=1 +		myconf+=" --add-module=${HTTP_AUTH_LDAP_MODULE_WD}" +	fi +  	if use http || use http-cache; then  		http_enabled=1  	fi 

Вариант конфигурации NGINX для хоста git.example.com:

# /etc/nginx/conf.d/git.example.com.ssl.conf  # Сокет сервиса fcgiwrap, должен быть доступен на запись пользователю nginx:nginx. upstream fastcgi-server { 	server unix:/run/fcgiwrap.sock-1; }  ldap_server ldap_git_users { 	# ldap[s]://hostname:port/base_dn?attributes?scope?filter 	url "ldap://127.0.0.1:389/ou=people,dc=example,dc=com?uid?sub?(objectClass=person)"; 	# DN с ограниченными правами. 	binddn "cn=manager,dc=example,dc=com"; 	binddn_passwd passwd; 	# Поиск пользователей непосредственно в группе без использования memberOf оверлея. 	group_attribute uniqueMember; 	# Атрибут должен содержать полный DN участника группы. 	group_attribute_is_dn on; 	# satisfy any; 	require group "cn=developers,ou=groups,dc=example,dc=com"; }  # Связь репозитория с пользователем в LDAP. # $repo - репозиторий полученный из URL в location; $repo_login - авторизованный пользователь. map $repo $repo_login { 	default ""; 	# Можно разрешить доступ одному пользователю к нескольким репозиториям. 	"example.com" "example"; }  # Редирект на HTTPS server { 	listen [ВНЕШНИЙ_IP]:80;  	server_name git.example.com; 	return 301 https://git.example.com$request_uri; }  # HTTPS server { 	listen [ВНЕШНИЙ_IP]:443 ssl;  	add_header Strict-Transport-Security max-age=2592000;  	server_name git.example.com; 	charset utf-8;  	ssl_certificate /etc/ssl/nginx/git.example.com.pem; 	ssl_certificate_key /etc/ssl/nginx/git.example.com.key; 	ssl_protocols TLSv1 TLSv1.1 TLSv1.2;  	access_log /var/log/nginx/nginx_git.example.com-ssl_access_log main; 	error_log /var/log/nginx/nginx_git.example.com-ssl_error_log info;  	# Директория по умолчанию для аутентифицированных пользователей. 	# Если пользователь не авторизован для доступа в репозиторий, в этой папке он и останется. 	root /var/git/empty;  	# Статичные файлы Git репозитория. 	location ~ "^/(?<repo>[^/]+)/objects/([0-9a-f]{2}/[0-9a-f]{38}|pack/pack-[0-9a-f]{40}\.(pack|idx))$" { 		auth_ldap "git::repository"; 		auth_ldap_servers ldap_git_users; 		# значение переменной $repo_login получается сопоставлением в map переменной $repo 		if ($remote_user = $repo_login) { 			root /var/git; 		} 	}  	# Запросы к репозиторию, которые необходимо направить на git-http-backend. 	location ~ "^/(?<repo>[^/]+)/(HEAD|info/refs|objects/info/[^/]+|git-(upload|receive)-pack)$" { 		auth_ldap "git::repository"; 		auth_ldap_servers ldap_git_users;  		fastcgi_param SCRIPT_FILENAME /usr/libexec/git-core/git-http-backend; 		fastcgi_param PATH_INFO $uri; 		fastcgi_param GIT_HTTP_EXPORT_ALL ""; 		fastcgi_param GIT_PROJECT_ROOT /var/git; 		fastcgi_param REMOTE_USER $remote_user; 		include fastcgi_params;  		if ($remote_user = $repo_login) { 			fastcgi_pass fastcgi-server; 		} 	}  	# Если репозиторий не найден вернуть 404. 	location / { 		return 404; 	} } 

ownCloud

Облачное хранилище ownCloud уже содержит всё необходимое для работы с LDAP. Достаточно зайти в Apps → Not enabled найти «LDAP user and group backend» и нажать Enable. В результате в настройках появится пункт LDAP. Нужно перейти на него и, в закладке Server, указать уже привычные настройки:

SERVER: 127.0.0.1; Port: 389 DN: cn=manager,dc=example,dc=com PASS: passwd BASEDN: ou=ou=people,dc=example,dc=com 

Для того, чтобы на следующей закладке заработал выбор группы, нужно зайти в Advanced → Directory Settings и изменить следующие настройки:

Group Display Name Field: cn Base Group Tree: ou=groups,dc=example,dc=com Group-Member association: uniqueMember 

Однако даже после этого у меня нашлась только одна posixGroup, что было явно не достаточно. Поскольку настройки позволяют указать все фильтры вручную, то проще и надёжнее воспользоваться именно этой функцией. Для этого на закладке Server желательно включить настройку «Manually enter LDAP filters», затем прописать все фильтры вручную:

Users: (&(objectClass=person)(memberOf=cn=developers,ou=groups,dc=example,dc=com)) Login Attributes: (&(objectClass=person)(memberOf=cn=developers,ou=groups,dc=example,dc=com)(uid=%uid)) Groups: здесь ничего указывать не нужно, эта настройка добавляет в ownCloud дополнительные группы пользователей. 

Закончив с этим, можно перейти в Users и убедиться, что все необходимые пользователи присутствуют в списке.

Для монтирования ownCloud папки с помощью davfs2, необходимо на стороне клиента добавить следующие строки в файлы:

/etc/davfs2/davfs2.conf

use_locks 0 

/etc/davfs2/secrets

/home/<user>/workspace/example/cloud example "passwd" 

/etc/fstab

https://cloud.example.com/remote.php/webdav /home/<user>/workspace/example/cloud davfs user,noauto 0 0 

И, наконец, пример альяса wo (work on) для активации рабочего окружения на примере Django проекта:

# ~/.bashrc  alias wo=" \     mkdir -p ~/workspace/example/cloud && \     (mountpoint -q ~/workspace/example/cloud || mount ~/workspace/example/cloud) && \     cp -u ~/workspace/example/cloud/deploy/settings_local.py ~/workspace/example/src/project/settings_local.py && \     source ~/VEnvs/example/bin/activate && \     cd ~/workspace/example/src \ " 

Все файлы конфигураций и скрипты, использованные в статье, можно найти на GitHub.

ссылка на оригинал статьи http://habrahabr.ru/post/274187/