Por mais de uma década tenho trabalhado em um ambiente Debian completo em meu pequeno escritório (atualmente 1 servidor, 7 usuários, 3 desktops, 4 laptops). A autenticação é baseada em Kerberos, os perfis de usuário são gerenciados em LDAP e $HOME é servido a todos os clientes sobre NFSv4 com a ajuda de pam_mount ou autofs. Esta configuração é muito boa para usuários de desktop que trabalham na LAN local.
Dois anos atrás, comecei a usar a mesma configuração para usuários de laptop. A conexão WiFi causou alguma lentidão adicional e, com certeza, quando os usuários tentaram usar o laptop fora do escritório, as coisas ficaram muito lentas. Otimizar $XDG_{CACHE,DATA,CONFIG}_HOME e analisar otimizações específicas para Firefox no NFS tornou as coisas um pouco melhores.
Agora estou pensando em mover o $ HOME para os laptops+desktops. É bom que um usuário possa trocar de dispositivo se um cair, mas isso só acontece de vez em quando. Sacrificar essa flexibilidade para uma experiência de usuário mais rápida no dia-a-dia parece uma boa decisão. Se eu pudesse sincronizar bidirecionalmente o $HOME local com o servidor central na inicialização e no desligamento, provavelmente não haveria nenhuma compensação ...
- 'unison' parece ser um bom candidato para manter o $HOME local em sincronia com uma cópia central, mas parece exigir exatamente as mesmas versões entre servidor e cliente, e com as quais não posso me comprometer.
- 'lsyncd' parece ser um candidato muito bom, mas não encontro nenhuma história de usuário usando a ferramenta para seus diretórios $HOME ...
- Eu até dei uma breve olhada no 'GlusterFS', mas parece que é uma substituição não trivial. Alguém tem alguma experiência e talvez melhores práticas para compartilhar? Eu não me importo de experimentar, mas temo que estou perdendo algumas desvantagens óbvias para o acima... Thx!
Eu uso o Syncthing para configurações semelhantes a esta, tanto para diretórios pessoais completos quanto para subconjuntos de diretórios pessoais. Sincroniza arquivos, bidirecionalmente ou unidirecionalmente; é transparente se os usuários nunca fizerem alterações nos mesmos arquivos em dois lugares diferentes e, mesmo quando houver alterações conflitantes, ele consegue lidar bem com isso — não perde dados.
Funciona bem com versões distorcidas, dentro dos limites. Eu o tenho rodando em uma variedade de telefones e computadores; os telefones rastreiam a versão mais recente automaticamente, os computadores usam o que estiver na distribuição instalada. As sincronizações completas do diretório inicial só funcionam em computadores com distribuições idênticas (devido a alterações nos arquivos de configuração), mas as sincronizações parciais funcionam bem com configurações variadas.
O Syncthing funciona muito bem em LANs, mas também suporta sincronização pela Internet e é configurável para que você possa ajustá-lo a qualquer nível de confiança em que esteja interessado.
Como @marcus-müller apontou, essa funcionalidade é amplamente referenciada como 'perfis de usuário em roaming' e é construída principalmente em torno de dois pilares:
O primeiro é comumente endereçado com sistemas centralizados como LDAP+Kerberos e com SSSD no cliente. O segundo pode ser resolvido usando NFSv4 e krb5/krb5i/krb5p, mas pode resultar em lentidão se o seu cliente estiver em WiFi ou em um local remoto.
Se você deseja se afastar de um $HOME centralizado para seus usuários, mas não deseja abrir mão da flexibilidade de uma configuração centralizada, uma solução alternativa pode ser:
O GDM pode ser configurado para executar scripts no login (
/etc/gdm/PostLogin/Default) e logout (/etc/gdm/PostSession/Default). Um temporizador cronjob ou systemd pode ser configurado para as sincronizações intermitentes.Algumas ressalvas que pensei:
/EDIT: Publiquei um script de shell para ajudar a sincronizar o $HOME local com o $HOME remoto: https://github.com/zenlord/vagabond.sh - sinta-se à vontade para comentar :)
Extrair o diretório inicial de um servidor central durante o login e sincronizá-lo de volta no logout também pode ser feito com o PAM por meio de seu módulo pam-script - usando-o para chamar um comando rsync apropriado.
Você pode ter várias versões instaladas no servidor. Defina
addversionno = trueno perfil do Unison para executá-lo no servidor.unison-VERSIONVocê pode instalar várias versões no servidor. Se você não quer o incômodo de fazer suas próprias compilações, tanto os binários oficiais quanto os pacotes Debian dependem apenas da Glibc. Os pacotes oficiais são atualmente construídos no Ubuntu 18.04, mas na prática eles funcionarão mesmo em sistemas mais antigos.
Se você instalar suas próprias versões, é claro que precisará monitorar os problemas de segurança. Não me lembro de ter visto um aviso de segurança no Debian e não há um no (relativamente recente) rastreador de problemas do Github, mas isso não significa que não acontecerá.
Observe que não apenas as versões do Unison precisam corresponder, mas as versões do OCaml com as quais foram criadas podem ter que corresponder também. Por outro lado, os sistemas operacionais e a arquitetura da CPU não precisam corresponder.
Então, do ponto de vista técnico, o Unison seria bom. Não tenho certeza se é bom do ponto de vista do usuário, no entanto. Quando acontece um conflito, o usuário tem que dizer como reconciliar. Isso é inerente a qualquer sistema de sincronização bidirecional, então aqui a questão não é se deve usar o Unison, mas se deve usar a sincronização bidirecional. Se o objetivo é permitir que um usuário trabalhe em vários dispositivos de forma intercambiável, você precisa de sincronização bidirecional. Mas se o objetivo for apenas permitir um failover rápido se um dispositivo quebrar, o backup e a restauração são uma abordagem melhor.