Comandos de crew

Uma crew consiste em várias máquinas executando o Collie sob um lead, e seu telefone acessa o herd de cada máquina pela URL única do lead. O lead é a máquina que seu telefone acessa, todas as outras máquinas são membros e o deputy é o único membro com permissão para assumir o controle.

collie join e collie leave ainda funcionam. Eles são aliases para collie crew join e collie crew leave, usando os mesmos argumentos e códigos de saída.

collie pack também continua funcionando, para cada verbo nesta tabela. É um alias de collie crew com os mesmos argumentos e códigos de saída. collie docs pack imprime esta página, e o endereço /pack do aplicativo web redireciona para /crew. Todos os três serão removidos na versão 2.0.0 (ADR 0038).

Os comandos deputy, approve-promote e promote gerenciam o failover. Para instruções de configuração e recuperação, consulte docs/deployment.md → a porta de standby e o dia ruim.

Duas máquinas, uma crew

Dois comandos adicionam uma máquina, um para o Herdr e um para o Collie, e há um caminho manual para hosts onde o crew add não consegue acessar por SSH e para leads que servem HTTP puro.

herdr machine add --label <name> <ssh-target>   # prepare the remote host
collie crew add <ssh-host>                      # install Collie there and enroll it

herdr machine add executa na máquina em que você está. Ele instala o Herdr no host remoto e o salva na própria lista do Herdr, e não adiciona a máquina à crew. collie crew add executa no lead. <ssh-target> e <ssh-host> são o mesmo host, escrito como user@host ou como um alias de Host do seu ~/.ssh/config, e <name> apenas rotula a lista do Herdr.

collie crew add <ssh-host> instala o Collie no host remoto pelo seu próprio ssh e o registra. Ele gera o token localmente, provisiona o Collie na máquina remota e executa collie crew join lá. Ele requer o Herdr pré-instalado no host remoto, que é instalado pelo herdr machine add, portanto os dois comandos são usados juntos. Um lead que opera em HTTP simples precisa de mais uma etapa manual, pois crew add não suporta --insecure: execute collie crew join --insecure na máquina que está entrando. Use crew add ou o caminho manual para um host específico, nunca ambos. collie crew add sem destino lista os hosts que sua configuração ssh e o Herdr já conhecem, mesclados no host para o qual cada nome resolve; portanto, escolha dessa lista em vez de digitar o host de outra forma (abaixo).

crew add segue a rota indicada pelo seu próprio tipo de instalação. Um lead executado a partir de um checkout git, como na instalação do plugin Herdr, envia seu próprio commit para o membro e o compila lá; portanto, esse membro precisa de git e Bun. Um lead da instalação independente ou de um pacote não tem commit, então instala o membro a partir da release que ele mesmo executa, enviando o instalador do Collie pelo mesmo SSH; esse membro precisa de curl, tar e sha256sum ou shasum. --path indica o checkout remoto na primeira rota e a raiz de instalação na segunda. Um membro que já executa o outro tipo de instalação é recusado em vez de sobrescrito, e a recusa informa o comando para resolver o conflito. Nessa segunda rota, o próprio membro baixa a release do github.com; logo, um membro sem rota para o github.com precisa de um lead executado a partir de um checkout.

O terminal collie crew update segue as mesmas duas rotas e avalia a mesma condição para escolher uma: um lead em checkout envia seu próprio commit para cada membro, e um lead de instalação standalone ou pacote nivela cada membro para a release que ele mesmo executa. Em um lead de release, membros executando a partir de um checkout git são ignorados, exibindo na sua linha o comando para atualizá-los: collie update --to-tag v<version> nessa máquina. Em um lead de checkout, membros instalados via install.sh são ignorados pelo motivo inverso: eles usam releases, então a página Updates do telefone faz o nivelamento. Membros ignorados nunca interrompem a execução, e a confirmação os contabiliza à parte.

O caminho manual tem quatro comandos. Use-o para hosts que seu SSH não alcança ou para leads que servem HTTP puro, e não por causa do tipo de instalação do lead: qualquer tipo de lead adiciona membros com crew add. O lead é a instância que seu telefone já acessa, e a máquina integrada deve ter o Collie instalado e em execução.

1. 01
   No lead, gere o token.

   collie crew invite        # prints the token, then the join command to run

   O token tem uma única linha: <token>.<lead-fingerprint>.

1. 01
   Na máquina que está entrando, entre na crew e cole o token quando for solicitado.

   collie crew join https://lead.tail1234.ts.net

   Copie o endereço da saída do invite. Use o do seu próprio lead, não o deste exemplo.

1. 01
   No lead, reinicie-o para que o processo em execução reconheça o novo membro.

   collie restart

1. 01
   No lead, verifique se o link respondeu.

   collie crew status        # the new member, its address, and whether the link answered

Tokens são de uso único, válidos por dez minutos e exibidos uma vez. O lead armazena apenas o hash. Executar invite reinicia o processo do lead para que ele possa aceitar o registro recebido, e imprime a linha de junção com o nome do lead incluído.

A etapa 3 é uma segunda reinicialização, e o join informa isso ao finalizar. O invite reiniciou o lead para que ele pudesse aceitar o registro. O join então gravou o novo membro no disco, e o processo em execução não faz proxy de tráfego para esse membro até ser reiniciado novamente.

Em um terminal interativo, o join solicita o token. Em um script, passe - e forneça o token na stdin:

collie crew join https://lead.tail1234.ts.net -   # paste the token on stdin

Passe @<file> para ler o token do disco. Passar tokens diretamente como argumentos imprime um aviso, pois as listagens de processos expõem argumentos a todos os usuários locais (CREW_PROTOCOL.md §8.3).

Defina o endereço do lead para qualquer hostname ou host:port alcançável a partir deste nó. Um endereço sem esquema e porta resolve para https://<host>:8787, a porta à qual o listener do próprio Collie se vincula.

O que crew invite imprime depende de como o lead é publicado. No modo HTTPS padrão, o lead escuta na interface de loopback e tailscale serve o publica na porta 443. Portanto, invite imprime https://<full-tailnet-name>, que conecta na porta 443. Se você moveu a porta de entrada com COLLIE_SERVE_PORT, ele imprime <name>:<port>. Com COLLIE_SERVE_MODE=http, o listener do próprio lead responde na porta 8787 via HTTP simples, e invite imprime o nome curto, com a porta apenas se você a alterou. join solicita confirmação uma vez antes de enviar o token via HTTP simples, e --insecure confirma isso automaticamente. Um endereço http:// explícito ainda requer --insecure e não solicita confirmação.

crew add passa para o membro a mesma porta de entrada, para que o membro também conecte na porta 443. Um nome simples significaria a porta 8787, que um lead atrás de tailscale serve não expõe para a tailnet.

--address em crew join é o endereço no qual o lead conecta nesta máquina, e ele precisa de uma porta: --address <host>:8787. join recusa endereços sem porta, porque o lead tentaria conectar na porta 443. Um endereço https://host:8787 ainda é aceito e armazenado como host:8787.

A seleção do multiplexador é local para cada nó. Configure COLLIE_MUX no próprio .env desse nó, em ~/.config/collie/.env em uma instalação binária ou no diretório de configuração de plugins do Herdr em uma instalação do Herdr. O protocolo da crew, que é a comunicação de rede entre as máquinas, não contém campos específicos de multiplexador. Observe que os pares só foram testados com o Herdr na v1 (CREW_PROTOCOL.md §16).

crew add define esse valor para novos membros, pois o membro nem sempre consegue defini-lo sozinho. Um membro que executa exatamente um multiplexador é mantido como está e seleciona esse multiplexador na sua primeira inicialização. Um membro que executa vários gera uma pergunta do lead para você, e sua resposta é gravada como COLLIE_MUX no .env desse membro. Membros que já indicam um multiplexador também são mantidos como estão. Passe --mux <name> para responder antecipadamente ou para substituir o nome configurado no membro. Membros sem nenhum multiplexador em execução recebem um aviso e nada é gravado, pois a primeira inicialização é recusada até que um esteja rodando.

Máquinas do Herdr e a crew

As máquinas salvas do Herdr e uma crew do Collie são duas listas separadas, e nenhuma alimenta a outra.

Para adicionar uma máquina, veja Duas máquinas, uma crew acima.

A lista de máquinas do Herdr pertence à sua janela do Herdr. O Herdr 0.9.0 mantém destinos ssh salvos em seu cliente e abre cada um via ssh toda vez que você o utiliza. Você obtém terminais nessas máquinas, nessa janela, na máquina em que você está operando.

Uma crew é o Collie em cada máquina, e o lead alcança cada membro pelo link criptografado do próprio Collie, configurado uma vez por uma instalação que usa seu SSH. Uma crew também mostra terminais, e transporta mais do que terminais. Ela move uploads. Ela mantém o journal e o log de auditoria de cada máquina na máquina que executou o painel. Ela atualiza toda a crew a partir de uma confirmação no celular. Ela pode transferir a porta de entrada para um deputy quando o lead parar de responder. Ela funciona da mesma forma sob tmux e zellij, que não possuem nenhuma lista de máquinas.

Três fatos mantêm as duas listas separadas, e cada um deles é um motivo por si só.

O telefone nunca armazena uma chave SSH. Uma chave SSH é uma shell completa na máquina, e um telefone pode ser perdido. Em vez disso, o telefone armazena um token de emparelhamento emitido pelo lead, que abre o app e nada mais, e collie devices revoke <label> revoga esse código em tempo real, sem necessidade de reinicialização (parear um dispositivo).

Uploads, o journal e o log de auditoria ficam na máquina que executa o painel. E o crew link, que é como o Collie chama a linha criptografada entre duas máquinas, não precisa de SSH depois que um membro foi registrado.

Portanto, você não configura a mesma coisa duas vezes. Configure o ssh uma vez, e ambas as ferramentas o utilizarão. O Herdr mantém sua lista para sua própria janela, e o Collie mantém a crew para o seu telefone. Adicionar uma máquina ao Herdr não a adiciona à crew. Remover uma máquina do Herdr não a remove da crew. Um membro da crew executando tmux ou zellij nunca aparece na lista do Herdr.

collie crew add sem nenhum destino oferece candidatos de ambas as listas, para que você nunca digite um host duas vezes. Ele lê entradas Host no seu ~/.ssh/config e executa herdr machine list --json. Ele mescla as duas listas no destino ssh para o qual cada nome é resolvido. O comando segue um Include nessa configuração um nível abaixo, e apenas para caminhos sob ~/.ssh/. Ele não oferece um alias em um arquivo incluído a partir de outro arquivo incluído. Cada linha mostra de onde o nome veio: ssh config, herdr ou ambos. A linha de uma máquina que já está nesta crew traz o id desse membro em vez de um número.

Como uma crew é conectada

Apenas o lead expõe uma porta de entrada, e nenhuma outra máquina na crew expõe nada.

O lead é a porta de entrada gerenciada e serve o PWA. O celular o alcança via HTTPS em /api/* e não se comunica com mais nada. O lead alcança cada membro em /crew/v1/*, por TLS mútuo fixado transportando o segredo da crew. Um membro é um Collie completo sem porta de entrada, e mantém seus próprios agentes, journal, uploads e log de auditoria. O gerenciamento é feito inteiramente pela CLI, sem ações na UI do Herdr. A comunicação em si é especificada em CREW_PROTOCOL.md.

Um peer é uma instância do Collie, com um multiplexador de terminal e os durable agents vinculados a ele (Durable agents em uma crew). Um host com dois multiplexadores de terminal executa um peer para cada um. Cada um desses peers tem sua própria porta e diretório de estado, entra na crew de forma independente e aparece como uma máquina própria na lista.

O código trafega pelo seu próprio SSH para cada máquina. crew add instala um membro dessa forma e crew update o sincroniza. O crew link transporta dados de execução e nunca se torna um canal de distribuição.

Um deputy é um peer que o lead definiu com antecedência. Ele vincula uma porta de prontidão com três rotas, e essa porta nunca é publicada. O silêncio do lead a ativa, e sua própria credencial de pareamento a consome, permitindo que o celular alcance o deputy enquanto o lead estiver ausente.

Durable agents em uma crew

Os durable agents de um member aparecem no telefone do lead, na mesma seção Durable agents, e o próprio Collie do member responde por eles.

# on a member that runs a durable agent beside Herdr, tmux or zellij: no second instance
collie durable attach desk --socket /run/user/1000/desk/app.sock --restart
# on a durable-only member that shares its host with another peer
collie crew join <lead-address> --label desk-agents

Um Collie gerencia um multiplexador de terminal e cada durable agent vinculado a ele; portanto, uma instância do Herdr e seus durable agents formam um único peer, sem precisar de um rótulo próprio. Uma instância exclusiva para durable agents (COLLIE_MUX=durable) é um peer independente. Ela entra com o nome do host, a menos que você passe --label; portanto, defina um nome quando outro peer já usar esse host.

Um lead anterior à versão 1.21.0 ainda lista os durable agents de um member, mas sem o card de pergunta, e sua aba Terminal faz polling em um painel sem terminal. O member registra isso uma vez em seu log, e collie doctor no member mostra a linha durable-lead. Atualize o lead para corrigir.

Mensagens entre máquinas

Um agente pode enviar mensagens para um agente em outra máquina da crew, e o lead retransmite cada uma dessas mensagens.

# on the lead: every agent pane of every machine
collie walky who

Um membro envia a mensagem para o lead. O lead verifica a assinatura do membro e depois repassa a mensagem para a máquina indicada pelo endereço, e essa máquina verifica a do lead. O lead também envia o certificado do remetente, portanto essa máquina também verifica a assinatura do remetente. O próprio who de um membro lista apenas os seus próprios painéis. O lead descobre o resultado de cada mensagem e o envia de volta ao membro que a enviou. Execute collie walky status <id> na máquina do remetente ou no lead (Entre uma equipe).

No celular, um painel em um membro exibe suas mensagens assim como o próprio painel do lead exibe. O lead lê a lista a partir do log desse membro, para que os cards e a planilha Messages fiquem iguais em todas as máquinas (No celular).

Nota. Um membro precisa do Collie 1.23.0 para receber uma mensagem e para exibir suas mensagens no celular. Uma mensagem para um membro mais antigo é recusada not sent: older member, e um membro sob um lead mais antigo recebe not sent: older lead. Execute collie crew update --all para nivelar a crew (Atualizar uma crew).

Máquinas

Cada Collie monitora sua própria máquina, o lead mantém um dia desses dados para cada máquina na crew, e as páginas Machines exibem isso e contêm as regras de alerta.

Abra a lista em Configurações, Máquinas. Ela também existe em um collie que roda de forma avulsa, como uma única máquina. Em um lead com uma crew, Configurações, Sistema tem uma segunda linha para a mesma página, e o painel de um membro na página Crew vincula à página da própria máquina com Carga e alertas.

Apenas um lead, ou um collie avulso, mantém a lista. Um membro de crew aberto diretamente indica que não há lista de máquinas nele; abra a página no lead.

Cada Collie lê sua CPU, memória, discos e rede no mesmo ciclo que já monitora seus painéis, de modo que nada novo roda em segundo plano. Ele faz a leitura aproximadamente a cada 15 a 25 segundos. O lead lê os seus próprios a cada 5 segundos enquanto um telefone estiver com as páginas Machines ou a aba Crew abertas. De qualquer forma, cada minuto tem pelo menos uma leitura. Um membro envia sua última leitura junto com a resposta que já fornece ao lead. O lead mantém um ponto por minuto para cada máquina, durante 24 horas. Um Collie sem crew mantém o mesmo intervalo de um dia para a sua própria máquina.

Discos são aqueles que guardam seus arquivos. O Collie lê o sistema de arquivos que contém sua pasta pessoal, o que contém a raiz (no Windows, a unidade do sistema) e o que contém a pasta de estado do Collie. Dois deles no mesmo dispositivo contam como um só, e o Collie exibe no máximo quatro. Ele ignora sistemas de arquivos com menos de 1 GiB e aqueles somente leitura sem nenhum espaço livre. A raiz de um sistema baseado em imagens, como o Fedora Atomic, é um exemplo disso: está sempre 100% cheia e não se trata de um disco lotado. Cada disco exibe os mesmos números do df: "used" é o Used do df, e a porcentagem é o Use% do df. O total representa o que você ainda pode preencher como usuário normal; portanto, pode ficar alguns pontos percentuais abaixo do Size do df, que também contabiliza o espaço reservado para o root. O Collie lê os discos uma vez por minuto, em segundo plano. Um disco que não responde, como uma montagem de rede travada, nunca bloqueia o restante, e o Collie deixa de exibi-lo após três minutos e meio sem resposta. Nenhum durable agent é iniciado para ele.

A rede conta cada byte uma única vez. No Linux, o Collie soma as interfaces físicas, como eth0, enp3s0 e wlan0. Ele ignora todas as interfaces cujos bytes também passam por uma interface física:

• —
  Loopback: lo.
• —
  Pontes: br* (também a br-* do Docker), docker*, virbr*, lxcbr*, lxdbr*, incusbr*, podman*, cni*, flannel*, cali*, cilium*, weave*, vxlan*.
• —
  Extremidades de contêineres e VMs: veth*, vnet*, tap*.
• —
  Túneis: tailscale*, wg*, tun*, zt*. O tráfego de túnel também sai pela interface física, portanto o link da equipe é contabilizado lá.
• —
  Bonds e VLANs: bond*, team* e qualquer nome com ponto, como eth0.100.

O dia de medições fica em machine-history.json na pasta de estado do lead. O lead grava o arquivo no máximo uma vez a cada cinco minutos, apenas quando um minuto foi alterado, e mais uma vez ao parar. Um dia de uma máquina consome cerca de 46 KB no disco (54 KB quando reporta discos) e cerca de 68 KB da memória do lead. O histórico preserva o disco mais cheio de cada minuto, que é o disco monitorado por um alerta. Um membro não mantém histórico próprio, portanto o lead é o único lugar para consulta. Quando o lead está fora do ar, ninguém grava, e o gráfico exibe uma lacuna.

Uma máquina que para de responder mantém sua última leitura, com o horário em que foi feita, e não grava novos minutos. O Collie nunca mostra um zero que não mediu. Um membro que envia a mesma leitura novamente, idêntica em todos os números, não fez uma nova medição. O lead não a grava, e a leitura mantém o horário antigo. Um membro cujo coletor trava exibe, portanto, uma lacuna, não uma linha contínua.

O dia de medições e as regras permanecem em um único lead.

• —
  Um deputy que assume o controle começa sem regras de alerta e sem histórico. Ambos os arquivos ficam no lead antigo. Defina as regras novamente no novo lead.
• —
  Um collie avulso que se torna lead descarta o próprio histórico. Por conta própria, ele dá o nome local à máquina. Como lead, ele usa seu id de membro, e os pontos e regras de local são descartados.
• —
  Uma máquina removida da equipe leva seu histórico e suas regras de alerta com ela.

Um membro anterior a este recurso não envia leitura alguma e continua na equipe como antes.

Alertas para uma máquina

Você pode definir uma regra para CPU, memória e disco em cada máquina. Uma regra tem um limite, de 50% a 99%, e um tempo, de 5 a 120 minutos. A regra de disco monitora o disco mais cheio, e a notificação informa o nome desse disco. As regras ficam em machine-alerts.json no lead.

O lead envia uma notificação quando todos os minutos desse intervalo estiverem no limite ou acima dele. Ele precisa de uma leitura para pelo menos 80% desses minutos. Ele não envia mais nada enquanto o valor permanecer alto. O alerta é encerrado após cinco minutos consecutivos com pelo menos cinco pontos abaixo do limite, e a próxima alta envia uma nova notificação. Um alerta aberto é salvo com as regras, portanto reiniciar o sistema não faz o alerta ser enviado duas vezes.

Um alerta notifica apenas carga alta contínua. Ele não notifica quando uma máquina fica offline. Uma máquina que não está respondendo não inicia nem encerra um alerta. Uma pausa silencia todos os alertas, e a opção A carga da máquina continua alta em Settings desativa todos eles (quais alertas o Collie envia).

Nada sai da crew. As leituras trafegam pelo link da crew e permanecem no lead.

No celular

A página de uma máquina tem duas visualizações: Status e Alerts. O seletor fica sob o cabeçalho. Status abre primeiro, e uma notificação push sobre uma máquina também abre Status. A linha "Alert firing" em Status e em um card abre Alerts, onde a regra está. Enquanto uma regra dispara, o seletor Alerts exibe um ponto. A visualização faz parte do endereço (?tab=alerts), e alternar não adiciona uma etapa: Voltar sai da máquina e vai para onde você a abriu. Apenas Status lê o histórico; Alerts não lê nada.

Um card descreve em palavras o que está errado. Uma máquina que não está respondendo mostra sua integridade e o tempo decorrido desde sua última leitura, e nenhum número, porque um valor defasado de 12% ao lado da palavra "unreachable" parece uma máquina tranquila. Uma máquina que responde, mas não envia uma nova leitura há dois minutos, mostra seus números em cinza, com um relógio e o tempo decorrido desde a última leitura. Um membro que ainda executa uma versão do Collie anterior ao suporte a carga diz "Update this machine to see its load", e sua página não mostra gráficos. Sua visualização Alerts diz que a máquina precisa de uma atualização. Uma métrica cujo alerta está disparando deixa seu número e seu pequeno gráfico vermelhos, e o card exibe "Alert firing: CPU". A informação de disco não tem um pequeno gráfico, porque um disco se enche ao longo de dias, não de meias horas. O pequeno gráfico tem uma escala fixa de 0 a 100%, uma linha tracejada onde há uma regra definida, um ponto para a leitura atual e um espaço vazio para um minuto ausente.

As páginas só realizam leituras enquanto você as visualiza. A lista Machines é lida junto com a atualização do próprio painel. A página de uma máquina lê o dia uma vez quando abre e, depois disso, apenas os minutos mais recentes, uma vez por minuto. A aba Crew lê quando você a abre e a cada 15 segundos enquanto estiver visível na tela. Nada é lido para uma página ou aba fora da tela, nem enquanto o celular estiver bloqueado.

Os gráficos deixam em branco um minuto ausente. O histórico possui um ponto por minuto. Quando o lead foi reiniciado ou uma máquina ficou sem responder, a linha para e recomeça após a lacuna, sem passar por cima dela. A CPU desenha sua média como uma linha e seu pico como uma faixa mais clara. O limite do alerta é uma linha tracejada quando uma regra está configurada. O eixo de rede não tem topo fixo: ele segue o maior valor e exibe sua unidade. Uma máquina em uma plataforma sem contadores de rede, ou sem disco, informa isso em vez de desenhar um gráfico vazio.

Cada gráfico tem uma frase para leitores de tela. Fornece a métrica, o intervalo, o valor atual, a média e o pico. A legenda sob o gráfico identifica cada marcação, de modo que nenhum gráfico dependa apenas de cor.

Definir um alerta no celular

Defina uma regra na visualização Alerts da página dessa máquina. As regras e seus limites estão em Alertas para uma máquina acima. A regra de disco aparece apenas para uma máquina que relata seus discos.

Uma regra configurada de outra forma, com uma linha ou um horário fora dessas opções, mantém o valor e o exibe ao lado delas.

Uma nova regra começa em 90% por 10 minutos. Cada alteração envia todo o conjunto de regras dessa máquina, portanto alterar o limite de CPU nunca descarta a regra de memória ou de disco. O card exibe Salvando, Salvo ou Não foi possível salvar na sua própria linha de status e, após uma falha, mostra as regras reportadas pela bridge pela última vez.

O push vai para todos os dispositivos inscritos neste Collie. O card contém um link para Configurações, Alertas, onde você escolhe quais alertas recebe.

Iniciando algo em uma máquina

A página Novo (+ Novo no painel) possui uma seleção de Máquina quando você executa uma crew. O agente, o comando e a pasta que você escolhe pertencem à máquina escolhida, e essa máquina executa a inicialização.

• —
  Cada máquina indica quais agentes possui. Ele busca no PATH que sua shell de login usa, portanto um agente instalado via nvm ou na pasta home é considerado. Um agente que falta em uma máquina permanece na seleção, desativado, marcado como "not installed". O mesmo agente pode estar pronto em uma máquina e esmaecido na próxima.
• —
  Cada máquina lê seus próprios inicializadores. As linhas em launchers.toml, e as linhas adicionadas por um telefone lá, não são compartilhadas entre a crew (Seus próprios inicializadores). Sua lista de pastas, as linhas Recent e Favourite, também é própria dela, e a página verifica a pasta no disco daquela máquina.
• —
  Um New worktree é criado apenas no líder. Em um membro a opção permanece desativada e exibe "only on" o nome do líder.
• —
  Um membro anterior à versão 1.19.0 não inicia nada pelo nome. A página lista suas opções, desativadas, com o motivo "this machine runs an older Collie". Atualize o membro para iniciar agentes nele (Atualização, pelo celular ou pelo terminal).

Membros que não foram instalados pelo install.sh

Uma crew atualiza todos os membros pelo celular, exceto os membros cujos arquivos pertencem a outra pessoa.

collie crew update e a atualização de crew com um toque no celular preparam uma nova versão ao lado da antiga e fazem a troca. Isso funciona nas duas instalações feitas pelo script de instalação e pelo Herdr, mas não funciona em todas as instalações; então, a crew reporta as outras em vez de marcá-las como falhas.

Um membro empacotado aguarda seu gerenciador de pacotes. Onde o pacman, o nix ou o brew colocam os arquivos, esse gerenciador é o dono deles, e o Collie não substitui arquivos que não possui (uma instalação empacotada). A crew nunca envia uma atualização para ele, o exibe como "aguarda o gerenciador de pacotes" com o comando para seu prefixo onde houver um, e considera a execução concluída sem ele. Ele se alinha quando você executa esse comando nessa máquina, e a linha é limpa na próxima verificação.

Um líder empacotado ainda alinha seus membros. O lead recusa sua própria migração pelo mesmo motivo, e a recusa se resume a isso: o telefone e collie crew update nivelam todos os membros para a versão que o lead está executando agora, com uma única confirmação cobrindo todos eles. Depois que o gerenciador de pacotes atualizar o lead e você executar collie restart nele, nada é nivelado sozinho; mais uma confirmação na página Updates do telefone atualiza os membros para a nova versão do lead.

Um checkout a partir do código-fonte é um membro completo, sob um lead que também utilize um. Um membro clonado e compilado por você recebe a atualização da equipe vinda de um lead em checkout: esse lead envia o commit, recompila e reinicia o membro exatamente como faz consigo mesmo. Sob um lead sem commit, collie crew update o ignora e indica a execução de collie update --to-tag v<version> nessa máquina.

Assim, uma crew mista é uma crew normal. Um único toque alinha todos os membros que o líder consegue atualizar, lista os que ele não consegue, e a crew fica alinhada novamente assim que você executar os gerenciadores de pacotes deles.

O nome da crew

O nome de uma crew é dado de exibição, e apenas a líder o mostra. collie crew invite --name "the shed" nomeia uma crew quando ela é criada, e uma crew criada sem --name é chamada de "collie crew". Para alterá-lo mais tarde, execute collie crew rename <name> na líder. O verbo reescreve o nome no próprio crew-trust.json da líder e reinicia a bridge, de modo que collie crew status e a página da crew no telefone mostrem o novo nome imediatamente.

Nada é enviado para um membro. O nome viaja uma única vez, na resposta da líder a uma inscrição, e o membro o armazena sem nunca exibi-lo. Uma máquina que entra após a renomeação recebe o novo nome, e os membros que já estão na crew mantêm a string antiga em um campo que ninguém lê. O nome sofre trim, tem no máximo 64 caracteres e não aceita caracteres de controle. Em um peer, ou em uma máquina fora de qualquer crew, o verbo recusa a execução e informa onde rodar.

Atualizando para 1.9.0 a partir da 1.7.0 ou 1.8.x

Atualize todos os membros para a 1.8.x antes de migrar o lead para a 1.9.0. O 1.9.0 se comunica em uma versão do link de crew, e o 1.8.0 é a compilação mais antiga compatível com ela.

Você não precisa se lembrar de quais versões são essas. A partir da 1.8.0, o aviso de atualização informa quando a próxima versão altera o link da crew: na faixa, no card Updates e no push diário. Ele diz a mesma coisa em todos eles: atualize a líder primeiro, os membros em seguida.

A versão 1.8.0 renomeia os nomes que uma máquina lê. Os caminhos de rede, as duas chaves de ambiente, os três arquivos de estado e o prefixo do journal agora usam crew (ADR 0039). O link se comporta exatamente como antes, e nada do que você automatizou em scripts precisa ser migrado no mesmo dia.

O 1.8.0 manteve suporte a membros 1.7.0 por uma versão, e o 1.9.0 não. Um lead 1.8.0 também respondia aos caminhos antigos, portanto um membro ainda na 1.7.0 continuava o seguindo. O 1.9.0 removeu isso, exatamente como o ADR 0039 previa.

Um membro ainda na 1.7.0 sob um lead 1.9.0 aparece duas vezes, e nenhuma delas passa em silêncio. O preflight do lead marca a verificação version como vermelha, informando ambas as versões e o comando a ser executado, e esse vermelho bloqueia a atualização da crew em vez de iniciar uma migração que não pode ser concluída. Em collie crew status, o mesmo membro exibe incompatible, com um motivo que termina com "this build speaks 2".

Atualize esse membro diretamente em sua própria máquina. Um lead 1.9.0 não consegue mais alcançá-lo pelo link; portanto, execute collie update nele, atualize-o para a 1.8.x ou mais recente, e o lead o reconhecerá na próxima sondagem.

Os novos nomes

Renomeie as duas chaves de ambiente no seu próprio .env antes de migrar para a 1.9.0. Uma compilação 1.9.0 não lê a chave antiga nem emite avisos sobre ela.

Em um journal que abranja a atualização, use grep para ambos os prefixos:

journalctl --user -u collie | grep -E '\[(crew|pack)\]'

Uma linha gravada antes da atualização contém [pack], e uma linha gravada depois contém [crew]. Assim que toda a equipe estiver na versão 1.8.0, filtre apenas por [crew].