wfm
2.2.2
O WFM é um gerenciador de arquivos simples e baseado na Web. Você pode usá -lo como uma interface da Web para uma caixa NAS, servidor FTP, um "Cloud pessoal", site de compartilhamento de documentos ou um CMS leve. Ele permite executar operações básicas de arquivos e pastas, como download, fazer upload, renomear, mover, excluir arquivos e organizar a estrutura da árvore do diretório. Arquivos de texto, como marcação, marcação, configuração, etc, podem ser editados diretamente no navegador. O WFM também pode criar e abrir marcadores, arquivos de link e atalho, etc.
O WFM é um serviço independente com seu próprio servidor da web. Não há necessidade de Apache, Nginx, Php, etc. Ele é executado diretamente de systemd , sysvinit , launchd , rc ou Docker. O TLS / SSL é suportado com geração automática de certificados por LetS Crypt / CertBot.
Assim como Docker, Kubernetes, Hugo, etc. O WFM está escrito no idioma Go. O binário é estaticamente vinculado, totalmente independente e possui zero dependências externas. Os ícones são emojis unicode. Os certificados CA são incorporados no horário de construção. Não há necessidade de python, php, sql, javascript, nó ou qualquer outro inchaço. Saídas WFM validadas HTML 4.01 sem JavaScript. Funciona nos navegadores da Web modernos e legados que remontam ao Internet Explorer 1.x e Netscape 3.x.
O WFM expõe uma árvore de diretório por meio da interface baseada na Web. O método principal de especificar o diretório raiz é o chroot via -chroot=/dir sinalizador ou pelo seu gerenciador de serviços. Por exemplo, arquivo de serviço systemd RootDirectory= diretiva. O WFM não se destina a ser usado sem chroot.
Para alguns serviços como o Docker, um subdiretório deve ser usado, isso pode ser especificado por --prefix=/subdir:/ sinalizador. Um subdiretório não deve ser considerado seguro e você deve assumir que os usuários podem acessar arquivos acima do prefixo até o chroot.
Como qualquer outro servidor da Web, o WFM inicia o processo como root para vincular à porta 80 ou 443. Em seguida, setuid a um usuário desejado especificado com -setuid=myuser . Da mesma forma, o WFM executa o Chroot em um diretório especificado com -chroot=/datadir . Um exemplo de arquivo de serviço é fornecido aqui.
Você pode ter o Systemd ou o WFM executar chroot e setuid. Se você estiver vinculado à porta 80 (e/ou 443), precisará iniciar o WFM como raiz.
Você pode especificar Systemd User= Outro ROOT Se você também usar RootDirectory= para chroot e usar porta não privilegiada (acima de 1024, por exemplo, 8080), ou seu binário possui recursos adequados. Exemplo aqui.
Para instalar o arquivo de serviço WFM, copie -o para /etc/systemd/system/wfm.service edite a configuração e execute:
$ sudo systemctl daemon-reload
$ sudo systemctl enable --now wfmUm exemplo de arquivo de serviço Launchd é fornecido aqui.
Docker Hub: tenox7/wfm:latest
Olá mundo:
$ docker run -d -p 8080:8080 --user 1234:1234 -v /some/host/dir:/data tenox7/wfm:latest -prefix /data:/ Se não estiver usando o arquivo de senha, você também pode precisar adicionar --nopass_rw .
Se você não especificar --user no Docker Run, também pode precisar --allow_root pois o WFM estará sendo executado como ID do usuário 0 dentro do contêiner.
Implantação avançada com senhas e autocert:
$ docker run -d
--restart=always
-p 80:8080
-p 443:8443
-v /some/host/datadir:/data
-v /some/dir/wfmpasswd.json:/etc/wfmusers.json
tenox7/wfm:latest
-passwd /etc/wfmusers.json
-addr :8443
-acm_addr :8080
-acm_host www.snakeoil.com
-chroot /data
-setuid $( id -u ) : $( id -g ) A bandeira -prefix leva dois diretórios separados por um cólon. O da esquerda é um diretório de sistema de arquivos, o da direita é o caminho HTTP. O FSDIR é afetado pelo sinalizador -chroot . Se você Chroot para algum diretório, por exemplo -chroot /home/ubuntu/dir , o prefixo provavelmente deve apenas usar o ROOT DIR dessa pasta -prefix /:/ -que também é o padrão.
A peça httppath controla o sufixo da URL, por padrão, é / , no entanto, você pode movê -lo para um caminho diferente, por exemplo, "/dados" ou "/wfm" com o sinalizador -prefix=/:/httppath . Isso pode ser útil para ocultar o local padrão ou se o roteamento de outro serviço, como proxy reverso.
No futuro, o WFM deve suportar vários pares de prefixos.
Não testado, mas você precisaria de algo assim:
wfm -addr 127.0.0.1:9000 -fastcgiVocê pode usar o WFM como um servidor Web SSL / TLS / HTTPS Secure com o Lets Encrypt Auto Cert Manager. A ACM obterá automaticamente o certificado SSL para o seu site e o Keypair.
Exemplo de implantação com SSL:
ExecStart=/usr/local/sbin/wfm
-passwd=/usr/local/etc/wfmpasswd.json
-chroot=/var/www/html
-setuid=user
-addr=:443
-acm_addr=:80
-acm_file=/var/cache/wfm-certs.json
-acm_host=www.snakeoil.com
O sinalizador -addr=:443 faz WFM ouvir na porta 443 para solicitações HTTPS. Flag -acm_addr=:80 é usado para o gerente de certificação automática para obter o certificado e depois redirecionar para a porta 443/https. Flag -acm_file=/var/cache/wfm-certs.json é onde os certificados e chaves são armazenados. Este arquivo é aberto antes do Chroot. Como tal, é desejado que o WFM seja iniciado como root, depois setuid e chroot por conta própria, e não através do Systemd/Launchd.
O -acm_host= é um sinalizador repetido que adiciona hosts a uma lista de permissões. A ACM obterá apenas certificados para hosts de permissões de permissões. Se o seu site WFM tiver vários nomes no DNS, você precisará adicioná -los à lista de permissões.
Se o site HTTPS for exposto externamente fora do seu firewall, às vezes, é necessário ter um ouvinte HTTP local (não-SSL) também. Para ativar este uso -addr_extra=:8080 sinalizador.
A autenticação é realizada pela HTTP Basic Auth (no futuro, uma janela de login personalizada pode ser implementada). Se nenhum arquivo de senha for especificado ou nenhum usuário presente (em branco) e nenhuma senhas codificadas estiver presente WFM não solicitará nome de usuário/senha. O modo sem auth-in-deslear será o modo somente leitura (como um servidor da web regular), a menos que você especifique -nopass_rw sinalizador.
Para ativar a autenticação, especifique o arquivo de senha via -passwd=/path/users.json sinalizador. As senhas são lidas na inicialização e, portanto, podem ser colocadas fora do diretório chroot. As senhas também podem ser codificadas no binário no momento da compilação, SE abaixo.
Os usuários podem ser gerenciados usando uma função auxiliar interna que atende o arquivo json de senha especificada.
Observe que quaisquer alterações no arquivo de senha exigem reiniciar o daemon WFM para entrar em vigor. Isso ocorre porque o arquivo é lido uma vez na inicialização antes da execução chroot(2) .
Crie um novo arquivo de senha em branco:
$ wfm -passwd=/path/users.json user newfileAdicionar usuário:
$ wfm -passwd=/path/users.json user add myuser rwExcluir usuário:
$ wfm -passwd=/path/users.json user delete myuserAlterar a senha:
$ wfm -passwd=/path/users.json user passwd myuserO arquivo JSON pode ser editado / gerenciado manualmente.
Um arquivo de exemplo é fornecido. O formato é uma lista simples de usuários com "Usuário", "Salt", "Hash" Strings e "RW" Field Boolean. O usuário é auto -explicativo. O sal é uma corda aleatória curta usada para dificultar a quebra de senhas. Pode ser qualquer coisa, mas deve ser diferente para cada usuário. O mesmo sal também deve ser passado ao gerar a senha. Hash é uma string de hash salt + senha. O RW Boolean especifica se o usuário tiver apenas leitura ou leitura de acesso.
O arquivo de senha também pode ser codificado dentro do binário no momento da compilação. Isso pode ser útil em operações incorporadas. Para adicionar usuários codificados, adicione entradas aos users var no auth.go
O WFM monitores falhou as tentativas de login do usuário e proíbe o usuário por aumentar o período de tempo com mais tentativas ruins. Isso é ativado por padrão. Você pode desativar esse comportamento com -f2b=false . Além disso, para fins de depuração, você pode ativar um prefixo em que o banco de dados BAN será despejado, por exemplo -f2b_dump=/dumpf2b .
Usage of wfm:
-about_runtime
Display runtime info in About Dialog (default true)
-acm_addr string
autocert manager listen address, eg: :80
-acm_file string
autocert cache, eg: /var/cache/wfm-acme.json
-acm_host value
autocert manager allowed hostname (multi)
-addr string
Listen address, eg: :443 (default ":8080")
-addr_extra string
Extra non-TLS listener address, eg: :8081
-allow_root
allow to run as uid=0/root without setuid
-cache_ctl string
HTTP Header Cache Control (default "no-cache")
-chroot string
Directory to chroot to
-f2b
ban ip addresses on user/pass failures (default true)
-f2b_dump string
enable f2b dump at this prefix, eg. /f2bdump (default no)
-favicon string
custom favicon file, empty use default
-form_maxmem int
maximum memory used for form parsing, increase for large uploads (default 10485760)
-list_archive_contents
list contents of archives (expensive!)
-logfile string
Log file name (default stdout)
-nopass_rw
allow read-write access if there is no password file
-passwd string
wfm password file, eg: /usr/local/etc/wfmpw.json
-prefix string
Prefix for WFM access, /fsdir:/httppath eg.: /var/files:/myfiles (default "/:/")
-proto string
tcp, tcp4, tcp6, etc (default "tcp")
-rate_limit int
rate limit for upload/download in MB/s, 0 no limit
-robots
allow robots
-setuid string
Username or uid:gid pair to setuid to
-show_dot
show dot files and folders
-site_name string
local site name to display (default "WFM")
-txt_le string
default line endings when editing text files (default "LF")
A WFM começou sua vida por volta de 1994 como um script CGI Perl para o CERN HTTPD Server. Foi desenvolvido para permitir o upload de logs, despejos e outros dados de casos por engenheiros de suporte de campo, clientes etc. pela Web e como um front -end do servidor FTP. Posteriormente, reescrito no idioma C, quando a biblioteca CGIC e o Apache HTTPD foram lançados. Até 2015, a WFM tem sido um aplicativo comercial de código fechado usado para gerenciamento de documentos leves e suportado por alguns clientes. Desde então, foi de origem aberta. Em 2022, o WFM foi reescrito em Go como um aplicativo independente, com servidor web interno para cenários de implantação mais modernos.
