Сообщения raven_kg

subversion+apache - правила авторизации в зависимости от IP

Форум — Admin

Доброго всем времени суток. Возникла интересная задачка - нужно разграничить доступы к svn-репозиторию исходя из ip пришедшего. Т.е. изначальный конфиг следующий:

subversion.conf

                                                       
LoadModule dav_svn_module     modules/mod_dav_svn.so                                                          
LoadModule authz_svn_module   modules/mod_authz_svn.so                                                        

<Location /svn>
  DAV svn      
  SVNParentPath /home/svn
  SVNListParentPath On
  SSLRequireSSL

  AuthType Basic
  AuthName "Subversion Repository"
  AuthBasicProvider ldap
  AuthLDAPBindDN "administrator@dc.domain.tld"
  AuthLDAPBindPassword "rootpw"
  AuthLDAPURL "ldap://192.168.0.10:389/cn=Users,dc=dc,dс=domain,dc=tld?sAMAccountName?sub"
  AuthLDAPRemoteUserAttribute sAMAccountName
  AuthLDAPRemoteUserIsDN off

  AuthLDAPGroupAttributeIsDN on
  AuthLDAPGroupAttribute member

  <LimitExcept GET PROPFIND OPTIONS REPORT>
       Require ldap-group CN=svn-committers,CN=Users,DC=dc,DC=domain,DC=tld
  </LimitExcept>

</Location>

<Directory /home/svn>
        Options +ExecCGI -Includes FollowSymLinks
        php_admin_flag engine off
        AllowOverride All
        Order deny,allow
        Deny from none
        Allow from all
</Directory>

т.е. неавторизованым юзерам доступно только то, что описано в LimitExcept. На все остальное требуется авторизация. Теперь же мне нужно добавить дополнительно проверку по адресу посетителя - если пришедший не из пространства 127.0.0.1 и 192.168.0.0/24 то затребовать от него авторизацию на все, если же пришедший «свой», то применять к нему ограничения из вышеизложеного конфига.

З.Ы. Пробовал мигрировать на апач 2.4 - все работает отлично, но «затык» вскрылся в самом subverion - вместе с апачем пришлось обновить и модуль вкупе со всеми его зависимостями до версии 1.7.6 (текущая 1.6.11). Стали отваливаться локальные копии пользователей. Лекарство было найдено в виде удаления папок .svn и перезаливки их свежих версий из svn, но 1 - терялась история незакоммиченых изменений, 2 - коммиттеров слишком много, ко всем не применить. Пришлось откатить subversion до 1.6.11, apache до 2.2/

Вот тот конфиг, из которого мб будет понятнеее что конкретно я хочу:

LoadModule dav_svn_module     modules/mod_dav_svn.so
LoadModule authz_svn_module   modules/mod_authz_svn.so
LoadModule dontdothat_module  modules/mod_dontdothat.so

<Location /svn>
  DAV svn
  SVNParentPath /home/svn
  SVNListParentPath On
  SSLRequireSSL

  AuthType Basic
  AuthName "Subversion Repository"
  AuthBasicProvider ldap
  AuthLDAPBindDN "administrator@dc.domain.tld"
  AuthLDAPBindPassword "rootpw"
  AuthLDAPURL "ldap://192.168.0.10:389/cn=Users,dc=dc,dс=domain,dc=tld?sAMAccountName?sub"
  AuthLDAPRemoteUserAttribute sAMAccountName
  AuthLDAPRemoteUserIsDN off

  AuthLDAPGroupAttributeIsDN on
  AuthLDAPGroupAttribute member

  <If "-R '192.168.0.0/24'">
    <LimitExcept GET PROPFIND OPTIONS REPORT>
       Require ldap-group CN=svn-committers,CN=Users,DC=dc,DC=domain,DC=tld
    </LimitExcept>
  </If>
  <ElseIf "-R '127.0.0.1'">
    <LimitExcept GET PROPFIND OPTIONS REPORT>
       Require ldap-group CN=svn-committers,CN=Users,DC=dc,DC=domain,DC=tld
    </LimitExcept>
  </ElseIf>
  <Else>
       Require ldap-group CN=svn-committers,CN=Users,DC=dc,DC=domain,DC=tld
  </Else>

</Location>

<Directory /home/svn>
        Options +ExecCGI -Includes -FollowSymLinks
        AllowOverride All
        Require all denied
</Directory>

Сервер доступен только по https, что осложняет вариант с применением авторизации с помощью реверсных проксей.

apache, redhat, subversion

raven_kg
(07.11.12 11:10:01 MSK)

2 комментария

nginx+apaches+lighttpd - не пойму где затык

Форум — Admin

Приветствую всех! У меня собственно проблемы следующего характера - есть 4 машины с общим дисковым массивом, все с OracleLinux 6.2 на борту. 2 из них помощнее, 2 послабее. на тех что помощнее установлены nginx и apache, на тех что послабее - lighttpd. Предполагалась следующая схема - машины с лайти отдают статику, машины с апачами - динамику, на обоих машинах с apache установлен nginx чисто как балансирующий прокси-сервер (failover via heartbeat). Однако то ли руки у вашего покорного слуги растут не из того места, то ли еще что... в общем уже и не знаю на что грешить. Вот конфиг:

user nginx;

worker_processes 16;
worker_priority -10;

error_log /var/log/nginx/error.log notice;
pid /var/run/nginx.pid;

timer_resolution 100ms;
worker_rlimit_nofile 8192;

events {
worker_connections 2048;
use epoll;
}


http {
include /etc/nginx/mime.types;
default_type application/octet-stream;

log_format IP ‘$remote_addr’;

log_format main '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';
log_format upstreams '$remote_addr - $remote_user [$time_local] '
'"$request" $status $body_bytes_sent '
'"$http_referer" "$http_user_agent" '
'$upstream_addr "$upstream_status" '
'$upstream_response_time "$host" ';


access_log /var/log/nginx/access.log main;

limit_conn_zone $binary_remote_addr zone=myzone:10m;
proxy_cache_path /var/cache/nginx levels=2 keys_zone=pagecache:5m inactive=10m max_size=50m;
proxy_cache off;
proxy_connect_timeout 90;
proxy_send_timeout 90;
proxy_read_timeout 90;
client_body_buffer_size 128k;
# proxy_buffer_size 4k;
# proxy_buffers 4 32k;
proxy_buffers 16 32k;
proxy_buffer_size 64k;
proxy_busy_buffers_size 64k;
proxy_temp_file_write_size 64k;
client_header_buffer_size 16k;
client_max_body_size 2048M;
open_file_cache max=512 inactive=86400s;
open_file_cache_valid 21600s;
open_file_cache_min_uses 1;
open_file_cache_errors off;


output_buffers 32 64k;
postpone_output 1460;

lingering_time 30;
lingering_timeout 10;
reset_timedout_connection on;

client_header_timeout 90;
client_body_timeout 90;

expires 2m;
keepalive_timeout 60;
send_timeout 10m;

ignore_invalid_headers on;
# resolver dns_ip;
keepalive_requests 100;
limit_conn_zone $binary_remote_addr zone=gulag:5m;
recursive_error_pages on;
sendfile on;
server_name_in_redirect on;
server_tokens off;

tcp_nodelay on;
tcp_nopush on;

gzip off;
gzip_disable "MSIE [1-6]\.";
gzip_comp_level 3;
gzip_min_length 1100;
gzip_buffers 4 64k;
gzip_http_version 1.1;
gzip_proxied any;
gzip_types text/plain application/xml application/x-javascript text/css;

server {
server_name host www.host;
listen 0.0.0.0:80;

if ($host = 'host' ) { rewrite ^/(.*)$ http://www.host/$1 permanent; }

location ~* ^.+\.(jpg|jpeg|gif|flv|png|css|zip|tgz|gz|rar|bz2|doc|xls|exe|pdf|ppt|txt|tar|wav|bmp|rtf|js|ico|swf)$ {
access_log off;
error_log /var/log/nginx/host.kg.error.log;
root /srv/data/www/host;
# proxy_pass http://static;
# proxy_set_header Host $host;
# proxy_set_header IP $remote_addr;
# proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
# proxy_set_header X-Forwarded-Proto $scheme;
# proxy_set_header X-Real-IP $remote_addr;
}
location / {
proxy_pass http://192.168.50.1:8081;
proxy_redirect http://192.168.50.1:8081/ /;
proxy_set_header Host $host;
proxy_set_header IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Real-IP $remote_addr;
access_log /var/log/nginx/host.dyn.access.log upstreams;
}
}
upstream static {
server 192.168.50.5:8080 max_fails=3 fail_timeout=30s;
server 192.168.50.4:8080 max_fails=3 fail_timeout=30s;
server 192.168.50.1:8081 backup;
server 192.168.50.3:8081 backup;
}

upstream apaches {
server 192.168.50.1:8081 max_fails=3 fail_timeout=30s;
server 192.168.50.3:8081 max_fails=3 fail_timeout=30s;
}
}

Итак, странности:

1. Стоит включить в первом локейшне проксирование на апстрим static вместо указания корня минут через 5-10 начинаются жуткие тормоза с откликом сервера и прогрузкой страниц. Грешил на бэкенды, заменил lighttpd на nginx - разницы никакой. 2. Если включить во втором локейшне апстрим apaches, вместо явной передачи какому-либо из бэкендов, время загрузки страниц увеличивается примерно вдвое. Применение там директивы ip_hash увеличивает его еще примерно вдвое. Конфиги apache обоих серверов идентичны и сведены к минимуму - ничего лишнего! 3. Как вы наверное заметили, у меня выключены gzip и proxy_cache - при включении данных параметров начинаются ужаснейшие тормоза как и в первом случае и примерно через полчаса паботы сервер загинается в известную позу.

Уважаемые гуру, подскажите пожалуйста где затык.

P.S. использовать fpm плз не предлагать!

raven_kg
(25.03.12 16:55:16 MSK)

1 комментарий

Посыпался 6-й рейд

Форум — Admin

Приветствую весь честной красноглазый люд!

Завалился у меня рейд-массив из 14 дисков вот на этой железке: http://www.datasystems.ru/goods_EP-3164D-G1S3.htm Завалился в процессе ребилда одного из винтов - сторадж ушел в ребут. Из рейда выпало 3 винта. 2 винта целые, только помечены стораджем как free, третий немного побитый, а вот поскольку в массиве не хватает более чем 2-х дисков рейдгруппа впала в degraded и стандартными методами не позволяет вернуть винты на место. http://www.2img.ru/pictures/38b957336f7b43705d34fc61e2850b8d.png На многих enterprice стораджах имеется ручной режим управления, благодаря которому можно попытаться принудительно загнать в группу, либо же имеется возможность просканировать диск на наличие заголовков raid. На этом же творении гениев тайваньской инженерии ни того ни другого я не обнаружил. Есть предположение что там имеется некая возможность инженерного логина (типа под рутом) где есть все недостающие фичи, но что-то я в этом сомневаюсь. Уважаемые гуру пинга и отвертки может кто знает как сие зло победить?

З.Ы. Вариант с бекапами не предлагать - это по большей части и было хранилище бекапов + несколько сайтов.

raven_kg
(12.03.12 23:18:29 MSK)

5 комментариев

RSS подписка на новые темы