Tag: gnu/linux

Configurando sincronização de compartilhamentos remotos com rclone

gnu/linux, ptBR

Existem diversas opções fáceis de sincronização de compartilhamentos no GNU/Linux (como o InSync ou ODrive), mas estas costumam ser pagos, pois são produtos de terceiros já que o Dropbox, OneDrive ou o Google Drive não oferecem soluções nativas no sistema, infelizmente. Mas se você estiver disposto e for paciente para trabalhar a linha de comando, é possível configurar uma solução totalmente grátis usando o software livre rclone, o canivete suíço dos aplicativos de compartilhamento em nuvem (palavras do próprio). Outra vantagem do rclone é que ele suporta drive compartilhado (antes conhecido como Team Share), recurso que falta à maioria das opções, até mesmo as pagas.

Primeiro instale o aplicativo rclone que já deve estar disponível no repositório da sua distro. Para derivados do Red Hat, digite no terminal:

$ sudo dnf install rclone

Ou para derivados do Debian:

$ sudo apt install rclone

E siga os passos de instalação que aparecerem. Depois de terminada esta etapa, existem duas palavras-secretas de configuração que é aconselhável você criar para que o rclone tenha acesso a sua conta. Caso contrário ele usará um acesso compartilhado padrão entre diversos usuários e o limite de operações por segundo é compartilhado também entre todos os usuários que optaram por usar o mesmo acesso padrão, o que pode limitar o número de operações por segundo do rclone e deixá-lo lento. As palavras criadas são sequências longas de letras e números separados por hífen, então é melhor copiar e colar exatamente o que aparece no seu browser. Para criar tais palavras-secretas, acesse o Google Cloud Platform.

No lado esquerdo superior clique na caixinha Select a project. Uma janela popup abrirá com um botão no lado direito superior escrito NEW PROJECT.

Uma nova tela se abrirá perguntando o nome do projeto e a organização responsável.

Digite rclone no campo Project name para ficar mais fácil identificar que se trata do aplicativo rclone acessando o seu compartilhamento. E em seguida aperte no botão CREATE. Agora o browser deve voltar a tela inicial. Selecione agora a opção no painel lateral API & Services > Credentials. Na tela que aparecerá, clique no dropdown + CREATE CREDENTIALS no topo da tela e selecione o item OAuth client ID.

Uma nova tela aparecerá com uma combo box chamada Application type. Selecione o item Desktop app. Uma caixa de texto chamada Name aparecerá. Coloque um nome que identifique que se trata do rclone (um simples “rclone” já vai servir) e em seguida clique no botão CREATE. Um popup contendo as informações que você precisa aparecerá. Salve os dados ali em um editor de texto, pois eles serão usados depois para configurar o rclone em linha de comando. Faça download também do arquivo JSON.

Os seus dados serão obviamente diferentes. 😁

Em seguida selecione APIs and Services > Dashboard no menu lateral. Na tela nova que aparecerá, selecione o botão + ENABLE APIS AND SERVICES. Na tela de API Library, encontre no Google Workspaces a caixa onde está escrito Google Drive API e clique nela. Uma nova tela se abrirá, onde você pode ativar (botão ENABLE) esta API.

Após ativada a API do Google Drive, você deve voltar no item da barra lateral APIs & Services > OAuth consent screen e incluir o seu e-mail na lista de usuários de teste (o botão + ADD USERS) em Test users, caso contrário o Google não libera o acesso ao aplicativo. O e-mail é o mesmo do compartilhamento.

Terminada esta parte, você deve digitar o comando rclone config no console. Ele serve como um wizard de configuração, mas se ficar ainda um tanto confuso, continue lendo. Ao entrar no modo config, o rclone apresenta as seguintes opções:

e) Edit existing remote
n) New remote
d) Delete remote
r) Rename remote
c) Copy remote
s) Set configuration password
q) Quit config
e/n/d/r/c/s/q>

Crie um novo remote (que é o nome como o rclone chama o seu compartilhamento remoto) selecionando a opção n de New remote. Em seguida ele pede o nome do compartilhamento. O melhor é selecionar um nome que faça sentido pra você. Digamos que você quer sincronizar a partir da pasta Documents no Google Drive, então você poderia chamá-lo disso. A próxima pergunta é o tipo de compartilhamento e aqui você seleciona Google Drive se for o caso, mas existem muitas opções possíveis… e fora do escopo deste artigo. 😅

Em seguida, ele perguntará o client_id, que é aquela palavra-secreta que você gerou no Google Console. Copie e cole neste espaço. Faça o mesmo para a outra palavra-secreta anotada: client_secret. Em seguida, em scope, você define o tipo de acesso ao compartilhamento. O mais prático é a opção 1 que dá acesso completo de leitura e escrita. Mas podem haver outras opções interessantes ali também. Veja o que atende melhor o seu caso.

root_folder_id é um código que representa a pasta que você quer ter acesso. Deste modo, é possível criar um ponto de acesso a um diretório específico em qualquer lugar do compartilhamento, como por exemplo se você tiver no seu compartilhamento o diretório Backup/Laptop/Documents, você pode associar isso com a pasta Docs localmente e acessa todos os arquivos e diretórios lá dentro. Você consegue descobrir o código do diretório que quer compartilhar entrando no Google Drive e indo até o diretório em questão e copiando o nome que aparece na caixa de navegação depois do https://drive.google.com/drive/folders/, por exemplo:

O código 1oGzNph32h4MS0EFghWNnealE09Vpruj representa o diretório atual My_New_Folder.

A pergunta sobre o campo service_account_file poderá ser deixado em branco. Depois, o rclone perguntará se é necessário editar a configuração avançada. Você pode dizer que não.

Coragem, falta pouco agora!

Pra terminar, o rclone pergunta se pode usar auto config. Isso fará com que o aplicativo em terminal abra o browser pra acessar a sua conta do Gmail. A tela seguinte aparecerá porque o aplicativo está em modo de Teste, mas não tenha medo: é normal e seguro.

Selecione continue para aparecer a próxima tela:

Aqui você deve clicar em Continue novamente e o rclone cria um servidor web temporário para exibir a seguinte mensagem:

Essa última tela pede para você voltar para o terminal do rclone, que deve estar deste jeito:

Log in and authorize rclone for access
Waiting for code...
Got code
Configure this as a Shared Drive (Team Drive)?
y) Yes
n) No (default)
y/n>

Aqui você pode selecionar n se o ponto de acesso não for um drive compartilhado. Depois o rclone apresenta um resumo das configurações e a última pergunta é se está tudo OK. Ou você pode editar tudo de novo até arrumar a configuração. Quando você tiver terminado, ao voltar para o terminal digite sem os <>:

$ rclone mount <nome do remote>: ~/<meu diretório local> &

E você pode colocar essa linha no seu .bash_profile pra executar o rclone a cada login. Observe a presença do &, que coloca o comando em segundo plano e executá-lo como se fosse um daemon, senão ele travaria o terminal ou script eternamente. Foi trabalhoso, né? Mas pelo menos você não precisará fazer isso muitas vezes. 😁

Dica de uso: se você usa aplicativos pra criar notas localmente, como o RedNotebook, você pode colocar as notas que cria em uma pasta sincronizada do Google Drive e compartilhar essas notas entre todos os computadores e smartphones que possui.

Sincronizando seus dados com unionfs

gnu/linux, ptBR

Aviso: este artigo apenas descreve uma ideia ou dica de como resolver um problema. Não é minha responsabilidade se você testar a ideia aqui e seu computador subitamente congelar e pegar fogo. Prudência do leitor é aconselhável. Grato pela compreensão. 😉

Usando mais de uma distro de GNU/Linux em um mesmo computador, é comum nos vermos com o problema de lembrar em qual delas está um arquivo de que precisamos. Além de fazer backup do que vale a pena guardar (sempre recomendado), a triagem desses arquivos espalhados por diversos $HOMEs pode consumir muito do nosso tempo e paciência. O ideal, a curto prazo, seria manter sincronizado todo o conteúdo a que temos acesso, ou seja, tudo que está nas pastas Vídeos, Downloads, Imagens e Documentos automaticamente sincronizado entre todas as $HOMEs de todas as instalações de distros na mesma máquina. Desta forma a tarefa de backup tende a ser bem mais simples.

Para resolver esse problema, vamos usar um recurso muito popular quando trabalhamos com contêineres, mas que geralmente funciona debaixo dos panos: o unionfs. Apesar do nome, o union filesystem não é um sistema de arquivos propriamente dito, mas um serviço que se comporta como um, porque ao invés de ler e interpretar o conteúdo de uma partição (os formatos NTFS ou ext4 como exemplos), ele permite fundir dois ou mais diretórios em um único diretório. A beleza disso tudo é que esses diretórios podem estar em diversos sistemas de arquivo diferentes, o unionfs gerencia isso de forma transparente.

Para usar o unionfs como é usado neste artigo, você vai precisar instalar os pacotes do fuse (file system in userspace) e a implementação de unionfs em fuse, que deve ter um pacote com o nome unionfs-fuse ou algo parecido. Talvez exista também na sua distro um pacote chamado fuse-libs do qual fuse depende. Verifique como instalar esses pacotes na sua distribuição favorita. Concluída esta parte, o fuse permitirá que você declare suas configurações no /etc/fstab e as carregue durante o boot.

Voltando ao assunto, considere a forma como o diretório $HOME é organizado. Sabemos que arquivos de configuração criados e usados por aplicativos do usuário geralmente ficam escondidos na sua$HOME. Eles são criados com um ponto inicial (.bashrc, por exemplo) ou ficam agrupados em subdiretórios cujo nome começa com um ponto inicial (.config, por exemplo). Considerando também um bom hábito não popular o diretório $HOME com arquivos avulsos, poluindo ele e o deixando mais lento. Sempre guarde os arquivos em algum subdiretório (mais tarde você verá que esse pequeno detalhe de organização será importante para o tipo de solução que vou propor aqui).

Outra coisa importante sobre o unionfs é que ele define camadas por ordenação. O que isso quer dizer na prática é que, pra definir onde um arquivo novo vai parar quando ele é criado, a ordem de declaração dos diretórios é usada. Digamos que você tenha a seguinte configuração no seu /etc/fstab:

/A=rw:/B=rw    /C    fuse.unionfs

Ou seja, você vai unir os diretórios A e B, ambos com permissão de escrita, em um diretório C, o diretório que vem antes na definição (A) será o diretório que receberá um arquivo criado. Isto quer dizer que se você criar um arquivo em C (como o diretório C é apenas um ponto de montagem, não armazena nenhum conteúdo e tudo que está lá é virtual), tal arquivo acabará sendo criado em A. Pode-se testar isso criando um arquivo vazio em C com o comando de terminal touch e verificando onde ele está realmente:

[hal9000 /]$ cd C
[hal9000 C]$ touch arquivo
[hal9000 C]$ ls arquivo
arquivo
[hal9000 C]$ cd /A
[hal9000 A]$ ls
arquivo
[hal9000 A]$ cd /B
[hal9000 B]$ ls arquivo
ls: cannot access 'arquivo': No such file or directory

Como podemos ver, o arquivo na verdade acabou sendo criado no diretório A. Isso me levou a ideia de como usar o unionfs para fazer a sincronização dos conteúdos distribuídos.

Saindo de nosso exemplo hipotético para algo mais concreto, temos dois tipos de diretório que devemos considerar nessa organização: o diretório contendo os arquivos que queremos compartilhar entre todos as instalações de GNU/Linux e o diretório não compartilhado, que pertence apenas àquela instalação específica. Essa distinção se faz necessária porque existem arquivos que não queremos que estejam compartilhados entre mais de um sistema operacional: arquivos de configuração (sim, aqueles arquivos que começam com um ponto).

Arquivos de configuração são pertinentes apenas para os programas presentes em uma determinada instalação. Se você compartilhá-los e um outro sistema na máquina tiver uma versão diferente do mesmo aplicativo, você pode acabar esbarrando com crashes ou outros erros difíceis de detectar ao tentar executá-los. Ou, em pior caso, pode até perder suas configurações por causa de uma versão mais antiga de um programa que sobrescreveu um arquivo de configuração e ignorou dados que ele não reconheceu, mas que seriam úteis para uma versão mais nova do programa que está em outro sistema operacional na mesma máquina. Então, tenha isso em mente quando for organizar as suas configurações.

Prosseguindo com este exemplo, você pode criar uma partição extra de 1TB e usá-la para os arquivos compartilhados e montá-la em /media/extra; enquanto que o diretório com os arquivos de configuração pode ser bem menor, e ficar em /home/cfg no sistema atual. Você pode agora juntá-los para criar o diretório $HOME do usuário fulano da seguinte forma:

/home/cfg=rw:/media/extra=rw    /home/fulano    fuse.unionfs

Como /home/cfg é o diretório da primeira camada, isso garante que ele receberá todos os arquivos de configuração criados pelos aplicativos que você executar depois. E o diretório /media/extra é onde estão todos os arquivos que você deseja compartilhar em subdiretórios como Downloads, Imagens, Documentos etc. Se você sempre gravar seus arquivos em algum desses subdiretórios, você já estará automaticamente tornando esses arquivos compartilhados entre todos os outros $HOMEs que você possuir (e aí está o motivo pra você não deixar arquivos jogados na raiz da sua $HOME). Se você quiser criar um diretório novo a partir da base (ou seja, a partir de $HOME) e garantir que ele será compartilhado, você pode criá-lo diretamente em /media/extra e ver ele automaticamente replicado em /home/fulano.

Segundo o manual do unionfs-fuse, temos ainda várias opções úteis para montar o unionfs. A opção cow (copy-on-write) define quando um arquivo é efetivamente criado. Vale a pena manter essa opção ativa por questão de performance. A opção max_files define o número de arquivos abertos simultaneamente. O default é 1024. A opção allow_other permite que outros usuários acessem os arquivos naquele file system, o que é geralmente útil, especialmente se seus usuários em diversos sistemas variam em UID e GID.

Então, apesar das vantagens de organização e economia de espaço, existem alguns cuidados a se considerar:

  • Se você trabalha com IDEs grandes e pesadas como Eclipse e Android Studio que abrem muitos arquivos simultaneamente, considere usar um parâmetro max_files bem grande, como 16000 (max_files=16000) ou mais quando for criar a uniões de diretórios. Caso contrário você pode acabar tendo comportamentos imprevisíveis com essas ferramentas. O Android Studio, por exemplo, reclamava de não conseguir compilar um projeto montado em uma unidade de rede (?). Experimente brincar com esses valores de max_files até obter um comportamento aceitável e pelamordedeus, use controle de versão. 😉
  • Mesmo que arquivos de configuração sejam pequenos, lembre-se que o cache do browser e os plugins fica dentro de um subdiretório escondido (por exemplo, .mozilla) na sua $HOME, então lembre-se sempre de reservar alguns gigas para este fim.

Comentários? Dicas? Críticas? Sugestões?