Linux için çok kullanıcılı bir webdav sunucusu var mı?


9

SMBA hizmetimi tamamen devre dışı bırakmak ve bir WebDav hizmetiyle değiştirmek istiyorum.

Tüm google aramaları beni Apache / Webdav kullanmaya yönlendirdi. Bu ihtiyacım olana yakın ama okuduğum kadarıyla Apache'nin kullanıcı dosyalarına erişmesini ve daha kötüsünü gerektiriyor; bir dosya oluşturursa yeni dosya Apache'ye aittir (kullanıcıya değil). Bazı kullanıcıların doğrudan SSH erişimi olduğu için doğru Unix sahipliğine ve izinlerine sahip dosyalara sahip olmanın bir gereklilik olduğunu unutmayın.

Bu yüzden oldukça basit bir şekilde ya çok kullanıcılarla Apache / Webdav'un ​​"doğru" çalışmasını sağlamanın bir yolunu arıyorum (bu, dosyayı sunmaya çalışmadan önce giriş yapan kullanıcıya unix kullanıcısını değiştirmek ) veya Apache / webdav.

Şimdiye kadar yapılan aramalar hiçbir şey getirmedi.


Webdav HTTP protokolüne dayandığından, bir HTTP sunucusu formu dışında mevcut olmadığını söyleyebilirim. Ve webdav trhey sunan ürün bulursanız genellikle bundan daha fazlasını sunacak
Kiwy

MPM ITK'nın son sürümünde umut verici bir şey olabilir gibi görünüyor. mpm-itk.sesse.net Bunu deneyeceğim ve AssignUserIDExprgiriş yapan kullanıcıyı kabul edip etmeyeceğimi göreceğim . O zamandan beri AssignUserIDkullanıcı kimlik doğrulaması yapmadan devreye girmiş gibi görünmeyebilir.
Philip Couling

Apache gerektirmeyen code.google.com/p/opendav gibi bağımsız webdav sunucuları veya PyWebDAV gibi kütüphaneler vardır.
Ocak

@jan Bu en iyi cevap olabilir. Apache zaten sunucuda çalışıyor ve webdav sitenin bir alt dizini olmalı, ancak bunu bir proxy geçişi olarak ayarlayabilir ve şifrelemeyi sağlamak için Apache'nin SSL'sini kullanabilirim.
Philip Couling

1

Yanıtlar:


2

Kullanıcı adınız ve / veya kullanıcı adınız varsa, bunu nginx + lua + luarocks ljsyscall ile yapabilirsiniz.

Debian sisteminde şu şekilde yapılandırılmıştır:

apt-get -y install nginx libnginx-mod-http-dav-ext libnginx-mod-http-lua luarocks
luarocks install ljsyscall

Ve nginx şu şekilde yapılandırıldı:

user  root;
worker_processes  1;

load_module modules/ngx_http_dav_ext_module.so;
load_module modules/ndk_http_module.so;
load_module modules/ngx_http_lua_module.so;

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


events {
    worker_connections  1024;
}


http {
    sendfile        on;
    keepalive_timeout  65;
    gzip  on;

    server {
        listen      80;
        listen [::]:80;

        location / {
            rewrite ^ http://$host$request_uri?; # permanent;
        }
    }

    server {
        listen      443           ssl http2;
        listen [::]:443           ssl http2;

        ssl                       on;    
        # [ SSL Sections Omitted ]

        # Set the maximum size of uploads
        client_max_body_size 200m;

        # Default is 60, May need to be increased for very large uploads
        client_body_timeout 120s; 

        # other configs
        location /webdav/ {
            autoindex              on;
            alias                  /data/www/;
            client_body_temp_path  /data/client_temp;

            dav_methods PUT DELETE MKCOL COPY MOVE;
            dav_ext_methods PROPFIND OPTIONS;

            create_full_put_path   on;
            # Not sure if you want to tweak this
            # dav_access             group:rw  all:r;

            # Let's assume you have an auth subrequest that can set X-UID
            auth_request  /auth
            auth_request_set $auth_status $upstream_status;
            auth_request_set $saved_remote_user $upstream_http_REMOTE_USER;
            auth_request_set $saved_remote_uid $upstream_http_X_UID;

            # Per-Request Impersonation
            access_by_lua_block {
                # Boilerplate because ljsyscall doesn't have setfsuid implemented directly
                local syscall_api = require 'syscall'
                local ffi = require "ffi"
                local nr = require("syscall.linux.nr")
                local sys = nr.SYS
                local uint = ffi.typeof("unsigned int")
                local syscall_long = ffi.C.syscall -- returns long
                local function syscall(...) return tonumber(syscall_long(...)) end 
                local function setfsuid(id) return syscall(sys.setfsuid, uint(id)) end
                -- If you only have ngx.var.saved_remote_user, install luaposix and do this ...
                -- local pwd = require 'posix.pwd'
                -- local new_uid = pwd.getpwnam(ngx.saved_remote_user).pw_uid
                local new_uid = tonumber(ngx.var.saved_remote_uid)
                ngx.log(ngx.NOTICE, "[Impersonating User #" .. new_uid .. "]")
                local previous = setfsuid(new_uid)
                local actual = setfsuid(new_uid)
                if actual ~= new_uid then
                    ngx.log(ngx.CRIT, "Unable to impersonate users")
                    ngx.exit(ngx.HTTP_INTERNAL_SERVER_ERROR)
                end
            }
        }

        location = /auth {
            internal;
            proxy_pass              http://localhost:8080/auth;
            proxy_pass_request_body off;
            proxy_set_header        Content-Length "";
            proxy_set_header        X-Original-URI $request_uri;
            proxy_set_header        X-Original-Method $request_method;
        }
    }
}

Bu, nginx çalışanının hizmet verdiği her istekte setfsuid yürütür. Ne yazık ki, şu anda çalışması için nginx'i root olarak çalıştırmanız gerekiyor gibi görünüyor. İşlemin kök olarak başlatılması, farklı bir kullanıcıya bırakılması, CAP_SETUID korunması (belgelere bakın capsh) ve useryönerge nginx yapılandırma dosyasında olmaması şartıyla bunun farklı bir kullanıcı ile çalışabileceğine inanıyorum .

Grup kimliklerini potansiyel olarak ayarlamanız da gerekebilir.

Http://man7.org/linux/man-pages/man7/capability.7.html adresindeki "Kullanıcı kimliği değişikliklerinin yetenekler üzerindeki etkisi" konusuna bakın.


Bu umut verici görünüyor. Onu ben kontrol edecegim.
Philip Couling

0

Bu okumaya değer olabilir: Başka bir girdi: birden fazla kullanıcı klasörü ve bir paylaşılan klasör http://hexeract.wordpress.com/2011/02/25/configure-a-webdav-enabled-webserver-for-multiple-user-folders -ve-bir-paylaşımlı klasör /


Bu, diğer cevabınızla aynı soruna sahiptir. Bazı kullanıcılar ssh erişimine sahiptir. Dosyalara UNIX dosya izinleri ve sahipliği (hem kullanıcı hem de grup) doğru verilmelidir ZORUNLU (web sunucusunun kendilerine değil).
Philip Couling

0

Bunu webdav kurulumu için rehber olarak kullandım: http://bernaerts.dyndns.org/linux/75-debian/62-debian-webdav-share

evet, Apache gruptur (Debian altında www-data), ancak bu gruba kullanıcılar ekleyebilirsiniz, bu yüzden bir kullanıcı ekledim. Neden diğer kullanıcıları eklemek olmayabilir test etmedi .... Prensip olarak bu kurulum kullanarak webdav sunucu şimdi benim ve oğullarım yerde (oğlum çalışması için 2 özdeş sunucuları) 3 yıl boyunca çalışır. Debian 6 bazı aylardan beri LTS versiyonudur (Şubat 2016'ya kadar).

Bernaerts ile karşılaştırıldığında Apache dosyasına uyarladım: / etc / apache2 / sites-available / varsayılan yapılandırma bu kısmı.

Alias /webdav1 /data/webdav1

<Location /webdav1>
DAV on
Authtype Basic
Authname "webdav1"
AuthUserFile /var/www/web1/passwd1.dav
Require valid-user
</location>

Yani dosyalarım artık www altında değil / data / webdav1 içinde (kısa tutmak için webdav1 takma adı aracılığıyla) Her sabit disk için böyle bir bölüm oluşturdum ve webdav1 bu bölümdeki 2. sabit disk için webdav2 olur. Bu sunucularda en fazla 10 sabit disk oluşturabiliriz, dolayısıyla bu bölümün 10'u bu yapılandırma dosyasındadır. Kullanıcıyı webdav klasörlerine erişebilmesi için kullanıcıyı www-data, davfs2 ve davfs'e ekledim. Bu yüzden kullanıcının giriş yapması gerekir ve kullanıcı adı ve şifre istenir. Fstab içinde tüm webdav veri diskleri listelenir, böylece montaj otomatik olarak devam eder. Fstab'ın o kısmı:

/ dev / sda3 / data / webdav1 ext3, kullanıcı, otomatik 0 0


1
Ne yazık ki bu sorunu hiç çözmüyor. Bu sorunun odak noktası çok kullanıcılıydı. Bu çözümle, giriş yapan kullanıcı değil apache kullanıcısı olarak yeni dosyalar oluşturulacaktır. Apache'nin çalışması için tüm dosyaların o gruba okuma / yazma izinlerine sahip www-veri grubu olması gerekir. Her kullanıcının bu grupta olması gerektiğinden, her kullanıcının diğer kullanıcıların dosyalarını okuma / yazma erişimi olması gerekir. Bu çözüm birden fazla kullanıcı için uyanmıyor.
Philip Couling

0

OwnCloud'u denediniz mi? Yine de kendim test ediyorum, ancak gereksinimlerinizi karşıladığı anlaşılıyor: webdav kutudan çıkar çıkmaz çalışıyor.


1
Evet Owncloud örneğim var ama aradığım şey bu değil çünkü owncloud kullanıcısı (apache) tüm dosyalara sahip.
Philip Couling

0

Uzun bir süre aradıktan sonra sadece bir tane bulamadım. Çok sayıda çoklu kullanıcı sunucusu var ancak sistem kullanıcısı olarak çalıştırılan bir sunucu bulamadım.

Ben de kendim bir tane yazdım. Bu sadece kendim test edebildiğim kadarıyla test edildi. Ama değeri için kaynak kodu burada:

https://github.com/couling/WebDAV-Daemon


0

Hy,

Aynı şeyi arıyordum ve sonunda apache2 kullanarak bir çözüm buldum. Ben npm webdav-server kullanarak düğüm çözümü denedim ve tüm apache modülü kullanarak güzel olarak çalıştı öğrendim. Sonra daha iyi yapabilir ve bir çözüm olabilir jsDAV dayalı bir npm dav-sunucusu denedim, ama berbat 3g bağlantısı ile uğraşmak zorunda kaldım gibi apache tercih ve birden çok örnek komut dosyaları hakkında öğrendim.

Burada deneyimimi paylaşıyorum.

http://helpcenter.epages.com/Doc/doc/apache2/README.multiple-instances

Webdav kullanıcısı başına bir örnek çalıştırıyorum ... çok ölçeklenebilir değil, ancak küçük bir ekipte çalışmak yeterince iyi.

MyUser öğesini kullanıcınızla değiştirin.

Ubuntu Üzerinde 14.04

sh /usr/share/doc/apache2/examples/setup-instance myUser

Bu yüzden / etc / apache2-myUser / envars içinde tanımlanan kullanıcı myUser olarak bir apache işlemi çalıştırıyorum

export APACHE_RUN_USER=myUser
export APACHE_RUN_GROUP=myUser

Port.conf dosyasını düzenleyin

# If you proxy with nginx as I did better to limit to local interface
listen localhost:8080
# listen 8080

Ben ubuntu 14.04 üzerinde PAM auth alamadım bu yüzden temel kimlik ile kandırmak gerekir sonra ben nginx ile https sarın

htpasswd -c /etc/apache2/htpasswd myUser

Sonra /etc/apache2-myUser/sites-available/000-default.conf

<VirtualHost *:8080>

DocumentRoot /var/www/html

Alias /${APACHE_RUN_USER} /home/${APACHE_RUN_USER}
<Directory /home/${APACHE_RUN_USER}>
    Require all granted
    Options +Indexes
</Directory>

<Location /${APACHE_RUN_USER}>
      DAV On
      AuthType Basic
      AuthName "Restricted Area"
      AuthUserFile /etc/apache2/htpasswd
      Require valid-user
</Location>

DavLockDB /home/${APACHE_RUN_USER}/.DavLock
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

o zaman nginx proxy üstbilgi ile bir hile vardır Hedef geçen simgeler klasörü webdav tarayıcılarda güzel düşürmek sağlar

server {
listen 443 ssl http2;
server_name exemple.com;

location ~ ^/(myUser|icons)/ {

    proxy_pass http://dav-myUser;

#         auth_basic "Restricted Content";
#         auth_basic_user_file /etc/nginx/htpasswd;

#         proxy_set_header Authorization $http_authorization;

    proxy_pass_header  Authorization;
    proxy_pass_request_headers on;

    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-Host $http_host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-Proto $scheme;

    port_in_redirect off;

    # to avoid 502 Bad Gateway:
    # http://vanderwijk.info/Members/ivo/articles/ComplexSVNSetupFix
    set $destination $http_destination;

    if ($destination ~* ^https(.+)$) {
        set $destination http$1;
    }

    proxy_set_header Destination $destination;

    proxy_read_timeout     300;
    proxy_connect_timeout  5;

    # Default is HTTP/1, keepalive is only enabled in HTTP/1.1
    proxy_http_version 1.1;

    # Remove the Connection header if the client sends it,
    # it could be "close" to close a keepalive connection
    proxy_set_header Connection "";
}

ssl on;
ssl_certificate /etc/letsencrypt/live/exemple.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/exemple.com/privkey.pem;

include /etc/letsencrypt/options-ssl-nginx.conf;

}

Nginx'i proxy olarak kullanma zorunluluğu yoktur, apache https'yi çok iyi yapabilirdi, ancak proxy Hedef sorununa çarptığımda bahsetmeye değer olduğunu hissettim.


-1

Ben de benzer bir çözüm arıyorum.

Çözüm 1: Masaüstü ortamınızda (Gnome, KDE) WebDAV tarafından belirli bir klasörü göstermek için widget'lar olabilir. Bu, masaüstü ortamınız çalıştığı sürece çalışır ve bir daemon çözümü değildir.

Çözüm 2: Hiçbir şey Apache'yi 1024'ün üzerindeki ayrıcalıklı bağlantı noktalarında kendi kullanıcı bağlantınız altında çalıştırmanızı engellemez. Sadece bir yapılandırma dosyası yazın veya dağıtımınızda paketlenmiş olanları $ HOME / etc / httpd'nize kopyalayın (sadece bir örnek), DAV- ilgili yapılandırma ve kendi kök olmayan kullanıcı gibi çalıştırın:

$ httpd -f $ HOME / etc / httpd

Kullanıcılarınız olarak çalıştırmak Apache'nin sizin gibi dosyalar oluşturmasını sağlar.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.