Estou procurando descomissionar completamente meu serviço SMBA e substituí-lo por um serviço WebDav.
Todas as pesquisas do google até o momento apontaram para o uso do Apache / Webdav. Isto é perto do que eu preciso, mas tanto quanto eu li requer Apache para ter acesso aos arquivos do meu usuário e pior; se criar um arquivo, o novo arquivo será de propriedade do Apache (não do usuário). Observe que ter arquivos com a propriedade e as permissões corretas do Unix é um requisito, pois alguns usuários têm acesso SSH direto.
Por isso, estou simplesmente procurando uma maneira de fazer o Apache / Webdav funcionar "corretamente" com vários usuários (ou seja, alterar o usuário do Unix para o usuário conectado antes de tentar exibir o arquivo. ) ou encontre uma alternativa completa ao Apache / Webdav.
Até agora, as pesquisas não transformaram nada.
Tendo pesquisado por um longo tempo, eu simplesmente não consegui encontrar um. Existem muitos servidores multi-usuário, mas não consegui encontrar um que fosse executado como usuário do sistema.
Então, eu mesmo escrevi um. Isso só é testado até onde eu posso testá-lo sozinho. Mas quanto vale a pena, o código fonte está aqui:
Isso pode valer a pena ler: Outra entrada: várias pastas de usuários e uma pasta compartilhada link
Eu usei este como guia para configurar o webdav: link
sim, o Apache é o grupo (www-data no Debian) mas você pode adicionar usuários a esse grupo, então eu adicionei um usuário. Não testei porque você não pode adicionar outros usuários .... O servidor webdav usando, em princípio, esta configuração é executado agora por 3 anos no meu lugar e meus filhos (para 2 servidores idênticos para o trabalho do meu filho). Debian 6 é desde alguns meses a versão LTS (até fev-2016).
Em comparação com Bernaerts eu adaptei no arquivo Apache: / etc / apache2 / sites-available / default esta parte da configuração.
Alias /webdav1 /data/webdav1
<Location /webdav1>
DAV on
Authtype Basic
Authname "webdav1"
AuthUserFile /var/www/web1/passwd1.dav
Require valid-user
</location>
Então, meus arquivos não estão mais em www, mas em / data / webdav1 (por meio do alias webdav1 para mantê-lo curto) Para cada disco rígido, criei uma seção desse tipo e o webdav1 se torna o webdav2 para o segundo disco rígido nessa seção. Podemos construir no máximo 10 discos rígidos nesses servidores, então 10 dessas seções nesse arquivo de configuração. Eu adicionei o usuário ao www-data, davfs2 e davfs, para que o usuário possa acessar a (s) pasta (s) webdav. Assim, o usuário precisa fazer o login e será solicitado o nome de usuário e a senha. No fstab, todos os discos de dados do webdav são listados para que a montagem seja executada automaticamente. Essa parte do fstab:
/dev/sda3 /data/webdav1 ext3, user,auto 0 0
Você já tentou OwnCloud ? Ainda estou apenas testando, mas parece que ele preenche seus requisitos: o webdav funciona imediatamente.
Hy,
Eu estava procurando a mesma coisa e finalmente reuni uma solução usando o apache2. Eu tentei a solução de nó usando npm webdav-server e descobri que nem tudo funcionou tão bem, em seguida, usando o módulo do apache. Então eu tentei um npm dav-server baseado no jsDAV que poderia fazer melhor e poderia ser uma solução, mas como eu tive que lidar com uma péssima conexão 3G prefiro o apache e descobri sobre vários scripts de instâncias.
Então, aqui eu compartilho minha experiência.
Eu executo uma instância por usuário webdav ... não é muito escalável, mas trabalhar em uma equipe pequena é bom o suficiente.
Substitua myUser pelo seu usuário.
No Ubuntu 14.04
sh /usr/share/doc/apache2/examples/setup-instance myUser
Portanto, executo um processo do apache como usuário myUser definido em / etc / apache2-myUser / envars
export APACHE_RUN_USER=myUser
export APACHE_RUN_GROUP=myUser
Edite o ports.conf
# If you proxy with nginx as I did better to limit to local interface
listen localhost:8080
# listen 8080
Eu não consegui fazer com que o PAM auth no ubuntu 14.04 funcione, portanto, é necessário usar a autenticação básica para que eu a envolva em https com nginx
htpasswd -c /etc/apache2/htpasswd myUser
Então /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>
então o proxy nginx tem um truque com o cabeçalho Destination A passagem da pasta de ícones permite que o webdav faça um bom downgrade nos navegadores
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;
}
Não há nenhuma obrigação de usar o nginx como proxy, o apache pode muito bem fazer o https, mas quando eu esbarrei no problema de destino do proxy, achei que valeu a pena mencioná-lo.
Também estou procurando uma solução semelhante.
Solução 1: Seu ambiente de trabalho (Gnome, KDE) pode ter widgets para expor uma determinada pasta pelo WebDAV. Isso será executado enquanto o ambiente da área de trabalho estiver em execução e não for uma solução de daemon.
Solução 2: Nada impede que você execute o Apache sob sua própria ligação de usuário em portas não privilegiadas acima de 1024. Basta gravar um arquivo de configuração ou copiar os pacotes incluídos em sua distribuição para seu $ HOME / etc / httpd (apenas um exemplo), adicionar configuração relacionada a DAV e execute-o como seu próprio usuário não root, como:
$ httpd -f $ HOME / etc / httpd
Executar como seus usuários garante que o Apache crie arquivos como você.