OpenWrt: atualizando para a versão 21.02

Mais um artigo da série sobre o OpenWrt.

Enfim temos uma nova versão do OpenWrt. Mãos a obra para atualizar!

Parece repeteco do artigo de upgrade do 19.07, mas é assim mesmo. O 19.07 seria o último com suporte para o alvo ar71xx. Agora, a migração para o ath76 é obrigatório. No 19.07 os modelos com pouca RAM e Flash poderiam apresentar problemas, mas ainda eram "suportados". Agora com o 21.02 eles não terão mais uma imagem pronta. Quem quiser e souber como fazer, deve usar o Image Builder e fazer sua própria firmware.

Para começar, o upgrade só é suportado vindo da 19.07.x. Então, se estiver saltando da 18.06.x, dê uma paradinha na 19.07 antes de prosseguir.

96,72% dos problemas com instalação/atualização com OpenWrt que ajudo é em relação a escolha incorreta da imagem da firmware. O OpenWrt tem uma página que simplifica a busca pela firmware correta, mas nada é à prova de pessoas criativas. Pegue o arquivo no download da última versão estável e nunca em um endereço qualquer, mesmo que seja em um artigo na wiki do OpenWrt (lembre-se como funciona uma wiki). Normalmente a wiki referência a versão em desenvolvimento, que não é a que você quer. As versões dentro de "(stables) releases", exceto as com o rc (release candidate) são estáveis. Pegue preferencialmente a mais nova (com número maior). Evite qualquer firmware que tenha no caminho palavras como "trunk", "snapshot" ou "rc1", "rc2"... exceto se estiver testando algo. As versões estáveis também mencionam a respectiva versão do OpenWrt no nome do arquivo como em "openwrt-21.02.0-ath79-generic-tplink_archer-c7-v4-squashfs-sysupgrade.bin", ao contrário da versão instável/em desenvolvimento "openwrt-ath79-generic-tplink_archer-c7-v4-squashfs-sysupgrade.bin".

A nomenclatura da versão é adota o formato: ano.mês.correção. O ano/mês se referem ao momento que foi criado um ramo nos fontes para o lançamento da nova versão e não propriamente quando o lançamento final ocorreu. Já o último número é apenas um sequencial de correção. Então, para quem usa uma versão 21.02.x, a próxima 21.02.x+1 deverá conter apenas bugs resolvidos (em especial, os de segurança) e deve ser considerada como recomendada. Estas versões de correção são lançadas com certa frequência. É bom acompanhar (e atualizar).

Na página principal, temos um atalho para cada versão lançada com o nome "Download a firmware image for your device (firmware selector)". Essa é a versão amigável de escolha da firmware buscando por texto. Observe sempre a versão do hardware! Para upgrades entre versões do OpenWrt, sempre use o "sysupgrade" e "factory "para instalações da firmware original de fábrica.

Finalmente, é muito importante ler a wiki do seu roteador independente se ele já funcionava na versão anterior! São poucos minutos de leitura que podem salvar horas de trabalho ou mesmo seu roteador. A wiki atual está ainda aquém do que era mas sempre vale a busca. Para modelos antigos, a antiga ainda tem seu valor.

Bem, se eu simplesmente ir na interface, fornecer a nova imagem, ele vai funcionar? Provavelmente, mas talvez não é a maneira que dê menos trabalho. A atualização pode preservar as configurações mas não os programas instalados. Se você tem raiz expandida em unidade externa, a encrenca é ainda maior.

"Mas eu nunca instalei um programa!" OK, use a interface web e provavelmente todas as configurações serão migradas sem problemas. Já testei isto em mais de um roteador e funcionou sem problemas. Mas faça o backup antes! Caso tenha instalado algum pacote, continue lendo.

Se está migrando da ar71xx para a ath79, o backup não poderá ser aplicado às cegas. Será necessário migrar manualmente ou refazer a configuração do zero. Se quiser arriscar, as configurações "incompatíveis" serão as que referenciam os LEDs (leds em system), o arranjo da rede (switches e vlans no network) e os rádios (radio em wireless). O resto é, na sua grande maioria, reaproveitável até mesmo para outras arquiteturas.

Em primeiro lugar, precisamos do plano de retorno caso a nova versão não se comporte como o esperado. Faça sempre um backup geral do seu sistema. No processo de upgrade, eu sugiro que sejam feitas as três formas diferentes de backup que eu comento no artigo sobre o tema: backup padrão gerado pelo sistema, lista de pacotes instalados e todos os arquivos do overlay. Este último serve apenas para o plano de retorno caso algo importante não funcione para você na nova versão (e para recuperar algo que não entrou no backup do sistema).

Recomendo estes backup:

# cd /tmp
# sysupgrade -o -k -u -b backup.tgz

Em resumo:

• '-u': salva tudo da /overlay, exceto aquilo que vem dos pacotes, mas inclui os arquivo de configuração modificados e os listados em /etc/sysupgrade.conf
• '-o': ignora os arquivos que são idênticos ao /rom (já estavam assim na firmware)
• '-k': inclui uma lista de pacotes instalados para reinstalação
• '-b': somente gera um backup, não atualiza o sistema

Dá até para fazer por SSH:

pc1$ ssh router sysupgrade -o -k -u -b - > backup.tgz

Mantenha seu backup.tgz em um lugar seguro, não no /tmp do roteador que se apaga ao reiniciar!

Agora, finalmente, você está pronto para enviar a nova firmware. Se você usa um armazenamento externo para expandir a raiz, leia até o final deste post antes de iniciar o processo!

Você pode optar por fazer o upgrade pela interface web ou pelo terminal. Inclusive, você pode baixar o arquivo diretamente no roteador. Só cuidado ao colar a URL. O openwrt.org usa HTTPS por padrão mas o "wget" do OpenWrt não tem suporte para HTTPS (por padrão). Se tiver problemas, remova o "s" de "https". E sempre salve no /tmp.

E pode fazer pela Wifi? Os fabricantes não recomendam usar sempre um computador "conectado por cabo"? Sim, e já tive problemas com atualização a partir da firmware do fabricante por não escutar isto. Mas não com OpenWrt. Se estiver atualizando (e não instalando a primeira vez!), pode fazer pela Wifi sem problemas. Quando a gravação for iniciada, todo o processo já está independente do computador cliente. Só não pode faltar energia 😉

Se optar pela interface Web, vá no menu para gravar a nova firmware, informe o arquivo .bin baixado. Confirme e reze. Se só tinha configurações e nada instalado a mais, a opção para preservar as configurações será suficiente. Caso contrário, poderá optar por preservar (ou não) as configurações e aplicar o backup gerado por "sysupgrade -o -k -u -b" na sequência. Se for fazer pela linha de comando, pode até usar o sysupgrade diretamente sem buscar um backup externo "sysupgrade -o -k -u openwrt-21.02-....img"

Se optar por preservar as configurações, tudo que seria guardado em um backup do sistema (os arquivos listado pelo "sysupgrade -l") será restaurado. Se você instalou algum pacote e guardou a lista do que foi instalado (lembra que eu sugeri há alguns parágrafos atrás?), esta é a hora que você reinstala os pacotes desejados. Se for instalar manualmente, procure instalar os pacotes de mais alto nível (ex: "luci-app-minidlna" antes de "minidlna"), pois eles irão, por dependência, baixar os pacotes necessários. No final do processo, é bom refazer a listagem do que está instalado e comparar com o que você tinha na versão anterior.

Caso tenha gerado o backup com "sysupgrade -o -k -u", você pode aplicá-lo depois da instalação, independentemente de ter optado por preservar as configurações durante a instalação.

Agora falta reinstalar os pacotes. A opção '-k' do backup gerou uma lista de pacotes instalados. Vamos aproveitá-la:

# opkg update
# grep "\toverlay" /etc/backup/installed_packages.txt | cut -f1 | xargs -r opkg install
# rm /etc/backup/installed_packages.txt
# reboot

Podem ser criados arquivos sufixados com "-opkg" em /etc/. Este são arquivos de configuração originais do pacote e são criados pois você modificou algo na configuração. Sugiro que verifique se não existe alguma coisa introduzida neste pacote que deveria ser adicionada no seu arquivo de configuração. Eu gosto do diff ou do "vim -d" para este trabalho comparando o arquivoconf com arquivoconf-opkg. Ao final do processo, eu gosto de apagar qualquer -opkg para deixar claro que apliquei tudo que queria.

As atualizações de segurança serão disponibilizadas por meio de atualização de pacotes (exceto as que exijam mudar o kernel). Para listar os pacotes atualizáveis:

# opkg update
# opkg list-upgradable

O maior problema é que estas atualizações de segurança, quando de pacotes embutidos oriundos na firmware instalada, ocuparão o espaço duas vezes no roteador pois ao substituir arquivos existentes na firmware inicial, ainda será preservado a versão em somente leitura para recuperação. Se for um problema para seu caso, a alternativa é esperar a próxima versão com a correção ou gerar uma nova firmware com o pacote atualizado.

Por fim, faça um novo backup geral. É sempre bom preservar o seu trabalho. Lembre-se que agora você pode gerar o backup com:

# cd /tmp
# sysupgrade -o -k -u -b backup.tgz

Só não esqueça de tirá-lo do /tmp pois ele será perdido ao desligar o roteador.

Se precisar retornar a versão anterior do OpenWrt, realize a gravação da firmware antiga, entre no modo de recuperação, monte a raiz e restaure o backup.

Se você não usa uma unidade externa para expandir o espaço interno, seu trabalho acabou. Para os demais, o processo é um pouco mais complicado. Ao atualizar o sistema, você terá um kernel novo que é incompatível com os módulos de kernel ou mesmo com as bibliotecas existentes na unidade externa, que ainda pertencentes à versão anterior. Você precisaria reinstalá-los. Esta é a sugestão de como proceder.

Em primeiro lugar, gere os backups sugeridos anteriormente. É importante preservar seu trabalho anterior. Ainda sem instalar a nova firmware, reinicie o sistema sem a unidade externa. Se você seguiu minha sugestão de manter uma configuração básica na flash interna, você ainda terá um ambiente funcional. Com isto, ele vai usar somente a flash interna (com a configuração que você tinha antes de usar a unidade externa).

Com a unidade externa conectada, faça o backup como sugerido anteriormente. Reinicie o roteaador sem a unidade externa e faça o procedimento de atualização descrito neste artigo para quem não usa raiz expandida, inclusive com a etapa de backups. Você terá que preservar os dois conjuntos de backups: com e sem a unidade externa em uso. Ao final do processo, você deverá ter a sua configuração básica restabelecida. Caso tenha optado por não preservar as configurações na gravação, você pode aproveitar o backup gerado quando a unidade externa estava desconectada (o segundo) para restaurar as configurações.

Neste momento, a unidade externa ainda está com os programas da versão anterior, que são geralmente incompatíveis com a nova versão (os módulos de kernel sempre o são). Por isto, precisamos nos livrar de todos os arquivos da versão anterior do OpenWrt presentes na unidade externa. Na unidade externa, na partição usada como overlay, remova todo o conteúdo ou mova tudo para um subdiretório (ou para outra unidade se não estiver com espaço livre) afim de que este não seja usado. Como sugestão, crie um "openwrt-versao-xxx" e mova tudo para lá. Refaça a configuração de uso de uma unidade externa (que no mínimo será reinstalar os pacotes necessários). Reinicie o sistema. Você deve estar agora com mais espaço na raiz.

Neste ponto, você ainda terá as mesmas configurações que tinha quando usou o sistema sem a unidade externa. Envie o primeiro backup da versão anterior feito com a unidade externa conectada (primeiro backup). Na sequência, reinstale os pacotes extras, assim como é feito para ambientes sem a raiz expandida. Complete o trabalho com aquele backup final.

Espero que apreciem a nova versão. De agora em diante, vou apenas focar em configurações específicas para OpenWrt 21.02, que ainda podem funcionar nas versões anteriores.

Até a próxima.

OpenWrt: atualizando para a versão 19.07

Mais um artigo da série sobre o OpenWrt.

Enfim temos uma nova versão do OpenWrt. Mãos a obra para atualizar!

No post anterior, comentei sobre o lançamento do OpenWrt 19.07. Dois pontos importantes para relembrar:

• se seu dispositivo tem 4 MBytes de flash, talvez não funcione e você terá que fazer um downgrade. Vou fazer um artigo sobre isso;
• para os usuários da plataforma ar71xx na versão 18.06, temos a opção de se manter no ar71xx (mas na versão 19.07) ou migrar para a ath76.

96,72% dos problemas com instalação/atualização com OpenWrt/LEDE que ajudo é em relação a escolha incorreta da imagem da firmware. O OpenWrt tem uma página que simplifica a busca pela firmware correta, mas nada é à prova de pessoas criativas. Pegue o arquivo no download da última versão estável e nunca em um endereço qualquer, mesmo que seja em um artigo na wiki do OpenWrt (lembre-se como funciona uma wiki). Normalmente a wiki referência a versão em desenvolvimento, que não é a que você quer. As versões dentro de "(stables) releases", exceto as com o rc (release candidate) são estáveis. Pegue preferencialmente a mais nova (com número maior). Evite qualquer firmware que tenha no caminho palavras como "trunk", "snapshot" ou "rc1", "rc2"... exceto se estiver testando algo. As versões estáveis também mencionam a respectiva versão do OpenWrt no nome do arquivo como em "openwrt-19.07.0-ath79-generic-tplink_archer-c7-v4-squashfs-sysupgrade.bin", ao contrário da versão instável/em desenvolvimento "openwrt-ath79-generic-tplink_archer-c7-v4-squashfs-sysupgrade.bin".

A nomeclatura da versão é adota o formato: ano.mês.correção. O ano/mês se referem ao momento que foi criado um ramo nos fontes para o lançamento da nova versão e não propriamente quando o lançamento final ocorreu. Já o último número é apenas um sequencial de correção. Então, para quem usa uma versão 19.07.x, a próxima 19.07.x+1 deverá conter apenas bugs resolvidos (em especial, os de segurança) e deve ser considerada como recomendada. Estas versões de correção são lançadas com certa frequência. É bom acompanhar (e atualizar).

Na página principal, temos um atalho para cada versão lançada com o nome "Download a firmware image for your device". Isso irá redirecionar uma tabela de hardware suportáveis, com filtragem dinâmica. Alternativamente, você sempre pode optar por clicar em "All firmware images" e buscar manualmente sua firmware, como ocorria com versões anteriores. Na dúvida, se você já é um usuário do OpenWrt, você pode descobrir a plataforma olhando o arquivo /etc/openwrt_release ou /etc/os-release:

root@router:~#  grep _TARGET /etc/openwrt_release 
DISTRIB_TARGET='ar71xx/generic'

root@router:~# grep _BOARD /etc/os-release
LEDE_BOARD="ar71xx/tiny"

root@router:~# grep _BOARD /etc/os-release
OPENWRT_BOARD="ramips/mt7620

OK, chegamos a uma lista enorme de firmwares! Vamos entender o que significa cada parte do nome do arquivo. Tomemos por exemplo "openwrt-19.07.0-ath79-generic-tplink_archer-c7-v4-squashfs-sysupgrade.bin":

• openwrt é o sistema operacional que você está instalando 😉
• 19.07.0 é a versão do openwrt. Em firmwares instáveis, este campo não existe!
• ath79 é a plataforma do seu dispositivo. Você descobre isso na wiki do projeto ou na tabela de hardware (ToH), campo "Target".
• generic é o subtipo do layout da flash. Normalmente será o "generic", exceto para casos especiais como roteadores com 4 MB que usam "tiny".
• tplink_archer-c7-v4 este é o modelo do seu roteador. Observe em especial a versão do HW (v4) pois ela pode mudar completamente o dispositivo, inclusive de família do SoC e se é suportado pelo OpenWrt.

"squashfs" é o tipo do armazenamento da imagem. Nesta, existe uma cópia imutável dos arquivos (ROM) e o resto da flash é usada para, de forma transparente, guardar as modificações (overlay). Tudo parece editável para o usuário. A diferença é que você pode, a qualquer momento, apagar as diferenças e restaurar o sistema pós-instalação. Existem outros formatos como o jffs2 (com escrita total sem recuperação), initram (rodar sem gravar na flash), mas normalmente são para casos marginais.

"sysupgrade" é a função da firmware. Esta é para atualizar de um OpenWrt para outro (e, em alguns casos, de outros firmwares alternativos como DD-WRT). Porém, não deve ser reconhecido pela firmware original do roteador. Para primeira instalação, ainda com a firmware original, use a variante "factory".

Finalmente, é muito importante ler a wiki do seu roteador independente se ele já funcionava na versão anterior! São poucos minutos de leitura que podem salvar horas de trabalho ou mesmo seu roteador. A wiki atual está ainda aquém do que era mas sempre vale a busca. Para modelos antigos, a antiga ainda tem seu valor.

Bem, se eu simplesmente ir na interface, fornecer a nova imagem, ele vai funcionar? Provavelmente, mas talvez não é a maneira que dê menos trabalho. A atualização pode preservar as configurações mas não os programas instalados. Se você tem raiz expandida em unidade externa, a encrenca é ainda maior.

"Mas eu nunca instalei um programa!" OK, use a interface web e provavelmente todas as configurações serão migradas sem problemas. Já testei isto em mais de um roteador e funcionou sem problemas. Mas faça o backup antes! Caso tenha instalado algum pacote, continue lendo.

Se optou por migrar da ar71xx para a ath79, o backup não poderá ser aplicado às cegas. Será necessário migrar manualmente ou refazer a configuração do zero. Se quiser arriscar, as configurações "incompatíveis" serão as que referenciam os leds (leds em system), o arranjo da rede (switches e vlans no network) e os rádios (radio em wireless). O resto é, na sua grande maioria, reaproveitável até mesmo para outras arquiteturas.

Em primeiro lugar, precisamos do plano de retorno caso a nova versão não se comporte como o esperado. Faça sempre um backup geral do seu sistema. No processo de upgrade, eu sugiro que sejam feitas as três formas diferentes de backup que eu comento no artigo sobre o tema: backup padrão gerado pelo sistema, lista de pacotes instalados e todos os arquivos do overlay. Este último serve apenas para o plano de retorno caso algo importante não funcione para você na nova versão (e para recuperar algo que não entrou no backup do sistema).

A partir da versão 19.07 (depois dela estar instalada) teremos mais opções para gerar o backup. Se estiver familizarizado com a CLI, as novas opções facilitam em muito o processo. Tudo que você precisará está no backup gerado com:

# cd /tmp
# sysupgrade -o -k -u -b backup.tgz

Em resumo:

• '-u': salva tudo da /overlay, exceto aquilo que vem dos pacotes, mas inclui os arquivo de configuração modificados e os listados em /etc/sysupgrade.conf
• '-o': ignora os arquivos que são idênticos ao /rom (já estavam assim na firmware)
• '-k': inclui uma lista de pacotes instalados para reinstalação
• '-b': somente gera um backup, não atualiza o sistema

Para atualizações da versão anterior, você pode baixar o novo sysupgrade no /tmp e usá-lo com:

# cd /tmp
# wget http://luizluca.github.io/sysupgrade
# chmod +x ./sysupgrade
# ./sysupgrade -o -k -u -b backup.tgz

E salve seu backup.tgz em um lugar seguro.

Agora, finalmente, você está pronto para enviar a nova firmware. Se você usa um armazenamento externo para expandir a raiz, leia até o final deste post antes de iniciar o processo!

Vocẽ pode optar por fazer o upgrade pela interface web ou pelo terminal. Inclusive, você pode baixar o arquivo diretamente no roteador. Só cuidado ao colar a URL. O openwrt.org usa HTTPS por padrão mas o "wget" do OpenWRT não tem suporte para HTTPS (por padrão). Se tiver problemas, remova o "s" de "https". E sempre salve no /tmp.

E pode fazer pela Wifi? Os fabricantes não recomendam usar sempre um computador "conectado por cabo"? Sim, e já tive problemas com atualização a partir da firmware do fabricante por não escutar isto. Mas não com OpenWRT. Se estiver atualizando (e não instalando a primeira vez!), pode fazer pela Wifi sem problemas. Quando a gravação for iniciada, todo o processo já está independente do computador cliente. Só não pode faltar energia 😉

Se optar pela interface Web, vá no menu para gravar a nova firmware, informe o arquivo .bin baixado. Confirme e reze. Se só tinha configurações e nada instalado a mais, a opção para preservar as configurações será suficiente. Caso contrário, poderá optar por preservar (ou não) as configurações e aplicar o backup gerado por "sysupgrade -o -k -u -b" na sequência.

Se optar por preservar as configurações, tudo que seria guardado em um backup do sistema (os arquivos listado pelo "sysupgrade -l") será restaurado. Se você instalou algum pacote e guardou a lista do que foi instalado (lembra que eu sugeri há alguns parágrafos atrás?), esta é a hora que você reinstala os pacotes desejados. Se for instalar manualmente, procure instalar os pacotes de mais alto nível (ex: "luci-app-minidlna" antes de "minidlna"), pois eles irão, por dependência, baixar os pacotes necessários. No final do processo, é bom refazer a listagem do que está instalado e comparar com o que você tinha na versão anterior.

Caso tenha gerado o backup com "sysupgrade -o -k -u -b", você pode aplicá-lo depois da instalação, independentemente de ter optado por preservar as configurações. A diferença é que o processo de reinstalação de pacotes é simplificado.

# opkg update
# grep "\toverlay" /etc/backup/installed_packages.txt | cut -f1 | xargs -r opkg install
# rm /etc/backup/installed_packages.txt
# reboot

Podem ser criados arquivos sufixados com "-opkg" em /etc/. Este são arquivos de configuração originais do pacote e são criados pois você modificou algo na configuração. Sugiro que verifique se não existe alguma coisa introduzida neste pacote que deveria ser adicionada no seu arquivo de configuração. Eu gosto do diff ou do "vim -d" para este trabalho comparando o arquivoconf com arquivoconf-opkg. Ao final do processo, eu gosto de apagar qualquer -opkg para deixar claro que apliquei tudo que queria.

As atualizações de segurança serão disponibilizadas por meio de atualização de pacotes (exceto as que exijam mudar o kernel). Para listar os pacotes atualizáveis:

# opkg update
# opkg list-upgradable

O maior problema é que estas atualizações de segurança, quando de pacotes embutidos oriundos na firmware instalada, ocuparão o espaço duas vezes no roteador pois ao substituir arquivos existentes na firmware inicial, ainda será preservado a versão em somente leitura para recuperação. Se for um problema para seu caso, a alternativa é esperar a próxima versão com a correção ou gerar uma nova firmware com o pacote atualizado.

Por fim, faça um novo backup geral. É sempre bom preservar o seu trabalho. Lembre-se que agora você pode gerar o backup com:

# cd /tmp
# sysupgrade -o -k -u -b backup.tgz

Só não esqueça de tirá-lo do /tmp pois ele será perdido ao desligar o roteador.

Se precisar retornar a versão anterior do OpenWRT, realize a gravação da firmware antiga, entre no modo de recuperação e restaure a overlay.

Se você não usa uma unidade externa para expandir o espaço interno, seu trabalho acabou. Para os demais, o processo é um pouco mais complicado. Ao atualizar o sistema, você terá um kernel novo que é incompatível com os módulos de kernel ou mesmo com as bibliotecas existentes na unidade externa, que ainda pertencentes à versão anterior. Você precisaria reinstalá-los. Esta é a sugestão de como proceder.

Em primeiro lugar, gere os backups sugeridos anteriormente. É importante preservar seu trabalho anterior. Ainda sem instalar a nova firmware, reinicie o sistema sem a unidade externa. Se você seguiu minha sugestão de manter uma configuração básica na flash interna, você ainda terá um ambiente funcional. Com isto, ele vai usar somente a flash interna (com a configuração que você tinha antes de usar a unidade externa).

Com a unidade externa conectada, faça o backup como sugerido anteriormente. Reinicie o roteaador sem a unidade externa e faça o procedimento de atualização descrito neste artigo para quem não usa raiz expandida, inclusive com a etapa de backups. Você terá que preservar os dois conjuntos de backups: com e sem a unidade externa em uso. Ao final do processo, você deverá ter a sua configuração básica restabelecida. Caso tenha optado por não preservar as configurações na gravação, você pode aproveitar o backup gerado quando a unidade externa estava desconectada (o segundo) para restaurar as configurações.

Neste momento, a unidade externa ainda está com os programas da versão anterior, que são geralmente incompatíveis com a nova versão (os módulos de kernel sempre o são). Por isto, precisamos nos livrar de todos os arquivos da versão anterior do OpenWrt presentes na unidade externa. Na unidade externa, na partição usada como overlay, remova todo o conteúdo ou mova tudo para um subdiretório (ou para outra unidade se não estiver com espaço livre) afim de que este não seja usado. Como sugestão, crie um "openwrt-versao-xxx" e mova tudo para lá. Refaça a configuração de uso de uma unidade externa (que no mínimo será reinstalar os pacotes necessários). Reinicie o sistema. Você deve estar agora com mais espaço na raiz.

Neste ponto, você ainda terá as mesmas configurações que tinha quando usou o sistema sem a unidade externa. Envie o primeiro backup da versão anterior feito com a unidade externa conectada (primeiro backup). Na sequência, reinstale os pacotes extras, assim como é feito para ambientes sem a raiz expandida. Complete o trabalho com aquele backup final.

Espero que apreciem a nova versão. De agora em diante, vou apenas focar em configurações específicas para OpenWrt 19.07, que ainda podem funcionar nas versões anteriores.

Até a próxima.

OpenWrt/LEDE: fazendo seus backups no roteador (e distribuindo-os): parte 3

Mais um artigo da série sobre o OpenWrt/LEDE. 

No primeiro artigo deste tema, comentei o que uma solução de backup deveria ter. Passei pela solução que usava anteriormente (crashplan) e uma brevíssima introdução aos recursos do borg. Depois apresentei a configuração do backup em um HD externo no seu roteador. Neste artigo, iremos implementar a sincronia entre repositórios.

Só relembrando, esse é o esquema do backup:

O computador roda o borg e copia os arquivos (amarelo) para um repositório no roteador. Esse repositório é acessado por CIFS e aponta para um HD externo conectado na USB. Em um segundo momento, um rsync sincroniza esse repositório com um destino remoto utilizando o rsync. O destino remoto também é um roteador com um HD externo conectado, mas poderia ser qualquer destino com suporte a rsync. A comunicação do rsync é feita dentro de uma VPN, que interliga o roteador de origem e destino do repositório.

Este artigo aborda a parte verde do diagrama.

Sincronizando repositórios

Já ouvi a estória do "eu tinha backup, mas perdi junto". Incêndio, roubo, descarga elétrica durante o backup, não são se preocupar em "não queimar" o HD externo do seu backup. E o backup parece ter um certo magnetismo que o atrai para próximo da fonte original da informação, em especial antes de eventos catastróficos.

Como já havia comentado na parte 1 deste assunto, distribuir geograficamente o backup de forma automatizada era um requisito. A opção foi utilizando o rsync sobre uma VPN, onde o repositório do backup, conectado no roteador (que sempre está ligado), é enviado lentamente para um outro armazenamento remoto, também conectado em outro roteador (que sempre está ligado).

A parte da VPN é assunto antigo. O rsync pode ser feito pelo SSH, com autenticação por chaves. Porém, isso exige um certo grau de confiança da ponta remota pois as mesmas chaves podem abrir uma sessão no roteador remoto. Outra opção é um serviço rsyncd. Apesar de não ter autenticação, você pode controlar pelo firewall e pela restrição do próprio rsyncd quem pode acessar esse serviço. Se somente o teu roteador puder conectar no roteador remoto, só você poderá apagar algo indevidamente.

No roteador que receberá a cópia:

roteador-remoto# opkg update

roteador-remoto# opkg install rsyncd

A configuração não foi UCIficada e deve ser feita diretamente em /etc/rsyncd.conf. Só adicionar:

/etc/rsyncd.conf:

(...)

[fulano@gmail.com]

path = /mnt/HD-externo-XYZ/backup/borg/fulano@gmail.com
read only = no
fake super = yes

O identificador fulano@gmail.com é arbitrário. Eu gosto de usá-lo pois o repositório normalmente terá mais de um cliente. E nada melhor do que o email para lembrar o nome do repositório. 

Agora, basta ativar e disparar o serviço:

roteador-remoto# /etc/init.d/rsyncd enable

roteador-remoto# /etc/init.d/rsyncd start

Opcionalmente, se já estiver usando o xinetd (por exemplo, para o scanner na rede - SANE), pode também usar o xinetd ao invés do serviço rsyncd:

service rsync 

{

disable = no

socket_type = stream

port = 873

protocol = tcp

wait = no

user = root

server = /usr/bin/rsync

server_args = --daemon

log_on_failure += USERID

}

E falta, agora, somente a rotina que envia do meu roteador-local para o roteador-remoto.

rsync --bwlimit=30k --partial --archive --delete --delay-updates --delete-after  /mnt/HD-externo-abc/borg/ roteador-remoto::fulano@gmail.com/

E se usar por cima do SSH:

rsync --bwlimit=30k --partial --archive --delete --delay-updates --delete-after  /mnt/HD-externo-abc/borg/ roteador-remoto:/mnt/HD-externo-XYZ/backup/borg/fulano@gmail.com/

A primeira opção --bwlimit limita a taxa de transferência para o rsync. Ajuste para sua realidade. Como eventualmente teremos múltiplos gigabytes para serem enviados, o processo pode durar dias. A recomendação é sempre deixar um tanto para outros fins. O --partial permite continuar o envio quando a conexão foi perdida. Eu gosto de usar o --delay-updates --delete-after para manter o repositório íntegro durante a cópia. Se espaço for um problema do outro lado e ele não aguentar armazenar a mais a diferença a ser enviada, pode usar o --inplace e --delete-before. E sempre, man é seu amigo.

Agora é só colocar na cron. Como o processo pode rodar "por dias", é importante que ele não volte a rodar se o rsync anterior ainda estiver em execução. Por isso, podemos melhorar o comando usando o comando "lock":

lock -n /tmp/rsync.lock && { bwlimit=30k --partial --archive --delete --delay-updates --delete-after  /mnt/HD-externo-abc/borg/ roteador-remoto::fulano@gmail.com/; lock -u /tmp/rsync.lock; }

Se rodar novamente este comando enquanto a execução anterior ainda estiver em curso, você vai receber um:

Can't lock /tmp/rsync.lock

E, como esperado, não teremos dois rsync em execução.

No OpenWrt, não temos os /etc/cron.* que usamos no Linux. Sendo assim, temos que usar o bom e velho 'crontab -e'. Para rodar todos os dias 1 AM:

0 1 * * * lock -n /tmp/rsync.lock && { bwlimit=30k --partial --archive --delete --delay-updates --delete-after  /mnt/HD-externo-abc/borg/ roteador-remoto::fulano@gmail.com/; lock -u /tmp/rsync.lock; }

Outra funcionalidade interessante é abortar o processo quando ele demorar muito tempo. Assim você pode manter a rotina apenas durante a madrugada. Todavia, isso só faz sentido se usar a opção "--partial". Bem, a partir deste ponto, a linha do comando vai ficar muito longa, mesmo por um costumas one-liner. É hora de fazer um script:

#!/bin/sh
# Sincroniza repositorio local com remoto
#
RSYNC_TIMEOUT=${1:?Informe o tempo maximo em segundos deste script}; shift
REPO_LOCAL=${1:?Informe o repositorio local}; shift
REPO_REMOTE=${1:?Informe o repositorio remoto}; shift
REPO_LOCK=/tmp/rsync-remote.lock

lock -n "$REPO_LOCK" || {
echo "Falha ao obter lock! Existe um rsync-backup rodando?" >&2
exit 1
}
trap "lock -u '$REPO_LOCK'" EXIT

rsync --archive --partial --delete --delay-updates --delete-after "$@" "$REPO_LOCAL" "$REPO_REMOTE" &
pid_rsync="$!"
(sleep $RSYNC_TIMEOUT; echo "Estouro de tempo ($RSYNC_TIMEOUT segundos)" >&2; kill -TERM $pid_rsync) &
pid_timeout="$!"
# Deveria ser kill -TERM -$pid_timeout... mas com o ash nao fuciona ainda
trap "lock -u '$REPO_LOCK'; kill -TERM $pid_timeout $pid_rsync 2>/dev/null" EXIT
wait $pid_rsync
err=$?
exit $err

Que ficaria na cron assim:

#  Roda todos os dias 1AM por 6 horas (21600 segundos)
0 1 * * * /caminho/para/rsync-backup.sh 21600 /mnt/HD-externo-abc/borg/ roteador-remoto::fulano@gmail.com/

E é isso. Agora você já tem um mecanismo de sincronia dos backups.

Recuperando dados

Primeiro, vamos imaginar o cenário onde você precisa recuperar os dados do repositório remoto. Você deve ter perdido os dados principais e também seu backup local. Nesta situação, é provável que você nem tenha mais o seu computador para recuperar os dados.

A primeira alternativa de recuperação é ir fisicamente onde o backup remoto está e copiar o repositório. O melhor seria primeiro reconstruir seu repositório local e depois recuperar o que você quiser com calma a partir dele.

Se o acesso físico for complicado, você pode simplesmente reconstruir seu repositório local fazendo um rsync inverso, como origem o repositório remoto e destino um caminho local. Vai demorar mas funciona.

Por fim, se precisar apenas de uma ou outra coisa, eu recomendaria testar a montagem remota em cima de rsync, como em fuse-rsync. Não testei mas deve funcionar perfeitamente.

Ah, e não se esqueça que você sempre precisa ter acesso a chave ou a senha usada na criação do repositório. E isso sem depender do próprio backup ;-)

Se pintar uma dúvida, tem sempre o fórum deste blog. Até a próxima.

OpenWrt/LEDE: fazendo seus backups no roteador (e distribuindo-os): parte 1

Mais um artigo da série sobre o OpenWrt/LEDE.

Neste artigo vou mostrar a estrutura de backup que, com o auxílio de roteadores OpenWRT/LEDE, permite o backup de arquivos na rede e o envio desse backup de forma eficiente para pontos remotos sem a necessidade de deixar o computador ligado. Como vai ficar muito longo, primeiro vou levantar os requisitos e comentar a solução selecionada. Em um segundo artigo mostro as configurações efetuadas.

Costumo dizer "não adianta rezar, só backup salva". Todo mundo sabe que é preciso fazer as cópias de segurança, que são importantes, etc, mas poucos realmente o fazem. Mesmo os "entendidos" não fazem backup por uma simples razão: dá trabalho e é chato. 

Um bom backup é feito de forma automatizada. Na maioria dos casos, só vamos lembrar dele quando precisar recuperar algo. E surpresa? Não tinha o backup!

Um bom backup não é uma simples cópia. Um bom backup deve ter versões, pois você pode levar um tempo para ver em algum momento sumiram suas fotos. Se tiver só uma cópia e ela foi feito depois do problema, não tem o que recuperar.

Um bom backup deve ser geograficamente distribuído. Mas precisa? Pense que se alguém for roubar sua casa, ele pode querer levar aquele HD externo junto com o seu computador. Pode ocorrer um pico de tensão e queimar o HD e o computador enquanto o backup era feito. Pode pegar fogo na sala onde ambos estão. Preferencialmente, nunca deixe todas as suas cópias no mesmo local. Vai copiar em um HD externo? Use dois, de forma intercalada e não deixe as duas cópias e o seu computador juntos. E dizem que sou paranoico.

Como os backups podem estar afastados do seu controle (geograficamente distribuído), um bom backup é cifrado ("criptografado"). Não precisa ser algo para enfrentar a NSA, mas algo que o custo para quebrar seja maior que o valor de seus dados. Não precisa ser muito chato neste ponto: uma senha em texto plano pode cifrar os backups e este arquivo pode ficar aberto no seu computador. Afinal, se alguém roubar essa senha no seu computador, ele vai poder abrir os arquivos no backup, que ele já teve acesso para poder ler o arquivo de senhas.

Principalmente, um bom backup deve ser recuperável. De nada adianta fazer o backup e descobrir que você não pode recuperá-lo. Ele deve, no mínimo estar íntegro.

Como posso fazer tudo isso? Pague por um serviço de backup na nuvem. Ou tenha um pouco mais de trabalho e faça você mesmo. Neste artigo vou mostrar a infraestrutura que montei para fazer backups de forma a oferecer esses recursos com o mínimo de custo computacional e de forma mais automatizada possível.

Eu usei por anos o Code42 Crashplan. Porém, eles abandonaram a versão gratuita, que permitia o backup distribuído entre amigos. Ele funcionava surpreendentemente bem, fazendo o backup de forma oportuna tanto no meu roteador (montado por CIFS) como nos meus amigos remotos. O problema era ter que deixar o computador ligado por horas (ou dias) para enviar um novo lote de fotos. Era um desperdício de energia e vida-útil do computador. A parte mais triste era que o backup já estava disponível 24/7 em um disco conectado no roteador. Só não tinha como copiar para o local remoto. O Crashplan foi desenvolvido em Java e não tinha a menor condição de rodar em um roteador com 64 MBytes de RAM.

A sincronia dos repositórios de backup com o ponto remoto também poderia ser feita usando o rsync. Contudo, o formato do repositório de backup mudava tanto a cada novo backup que o volume de dados a ser copiado superava em muito os novos arquivos salvos. A solução, em tempos e tempos, era fisicamente  levar um dos repositórios ao encontro do outro e copiar localmente os arquivos (mesmo com rsync e USB 3.0, levava horas).

Então, além dos que se espera de um bom backup, uma solução ideal deveria enviar os arquivos de forma minimamente eficiente para o roteador (ex: CIFS, SFTP). Alternativamente, também poderia ser viável utilizar um agente da solução diretamente no roteador. Todavia, portar novos programas para o ambiente do roteador nem sempre é possível.

O envio dos dados ao repositório remoto também era um requisito importante. Eu realmente queria evitar o computador ligado para enviar dados que já estão no roteador. A solução de backup, então, deve facilitar a replicação. Isto pode ser obtido se o formato do repositório for eficientemente sincronizável por rsync. Outra solução seria com o agente rodando no roteador, que dificilmente teria sucesso pelas restrições do roteador.

Nas pesquisas por uma solução de backup, encontrei o borg. Ele está disponível em algumas distribuições e também em um arquivo autossuficiente. Tem uma arquitetura bem simples. Nem configuração existe no computador. Você apenas aponta para o repositório e manda uma série de caminhos. É um software livre, que vai evitar o mesmo problema de abandono do Crashplan. Até tem uma interface web, mas realmente, estou mais interessado na linha de comando. Uma parte importante do borg é a estrutura do repositório de backup. Os dados são salvos em blocos deduplicados no repositório e um "backup" referência uma série de blocos que formam a estrutura de diretório. Novos backups só enviam a diferença. E os backups não sobrescrevem dados antigos. Assim, ele é excelente para ser sincronizado usando rsync! A impressão que toda a estrutura do repositório foi pensado com esse propósito.

A única limitação é que você deve ter um repositório por máquina. O borg guarda um cache dos blocos já copiados para agilizar novos backups. Esse cache é validado antes de fazer o backup. Se os metadados do repositórios estiverem mais novos, o cache é invalidado. Com duas máquinas usando o mesmo repositório, toda vez que a outra fizer o backup, o próximo backup não utilizará o cache e será bem mais lento pois terá que baixar todos os metadados do repositório. Mas isso não foi um limitador para meu uso.

No próximo artigo, vamos direto para a configuração do borg utilizando o roteador como destino e sincronizador de backups. Até a próxima!

Se pintar uma dúvida, tem sempre o fórum deste blog.

OpenWRT: Atualizando para versão 15.05

Mais um artigo da série sobre o OpenWRT.

Já temos a Caos Calmer (CC) 15.05. Agora vamos atualizar nossos sistemas!

Sim, este artigo repete diversos pontos do artigo de atualização anterior.

96,72% dos problemas com instalação/atualização com OpenWRT que ajudo é em relação a escolha incorreta da imagem da firmware. Como sempre, recomendo a versão squashfs, que possui modo de recuperação. Pegue o arquivo no download da Caos Calmer e nunca em um endereço qualquer, mesmo que seja na wiki do OpenWRT. Normalmente a wiki referencia a versão em desenvolvimento, que não é a que você quer. No diretório de download, navegue seguindo o caminho da "arquitetura alvo" em uso no seu roteador. Se você já é um usuário do OpenWRT, você pode vê-la olhando o arquivo /etc/openwrt_release:

root@router:~~# cat /etc/openwrt_release
DISTRIB_ID='OpenWrt'
DISTRIB_RELEASE='15.05'
DISTRIB_REVISION='r46767'
DISTRIB_CODENAME='chaos_calmer'
DISTRIB_TARGET='ar71xx/generic'
DISTRIB_DESCRIPTION='OpenWrt Chaos Calmer 15.05'
DISTRIB_TAINTS=''

A diferença entre a primeira instalação e a atualização é que não será usada a imagem "factory" e sim a "sysupgrade". Escolha o arquivo correspondente ao seu roteador (inclusive versão de hardware!). E muito importante, leia a wiki do seu roteador independente se ele já funcionava na versão anterior! São poucos minutos de leitura que podem salvar horas de trabalho ou mesmo seu roteador.

Bem, se eu simplesmente ir na interface, fornecer a nova imagem, ele vai funcionar? Provavelmente, mas talvez não é a maneira que dê menos trabalho. A atualização pode preservar as configurações mas não os programas instalados. Se você tem raiz expandida em unidade externa, a encrenca é ainda maior.

Mas eu nunca instalei um programa! OK, use a interface web e provavelmente todas as configurações serão migradas sem problemas. Já testei isto em mais de um roteador e funcionou sem problemas. Mas faça o backup antes! Caso tenha instalado algum pacote, continue lendo.

Em primeiro lugar, precisamos do plano de retorno caso a nova versão não se comporte como o esperado. Faça sempre um backup geral do seu sistema. No processo de upgrade, eu sugiro que sejam feitas as três formas diferentes de backup que eu comento no artigo sobre o tema: backup gerado pelo openwrt, lista de pacotes instalados e todos os arquivos do overlay. Este último serve apenas para o plano de retorno caso algo importante não funcione para você na nova versão.

Agora, finalmente, você está pronto para enviar a nova firmware. Se você usa um armazenamento externo para expandir a raiz, leia até o final deste post antes de iniciar o processo! Faça o upgrade pela interface web ou pelo terminal. Inclusive, você pode baixar o arquivo diretamente no roteador. Ex:

# cd /tmp

# wget http://downloads.openwrt.org/chaos_calmer/15.05/.../openwrt-15.05-...-squashfs-sysupgrade.bin

# sysupgrade openwrt...xxx....img 

Só cuidado ao colar a URL. O downloads.openwrt.org usa https por padrão mas o wget do OpenWRT não tem suporte para https (por padrão). Contudo, o downloads.openwrt.org aceita http sem problemas, só tirar o "s".

E pode fazer pela Wifi? Os fabricantes não recomendam usar sempre um computador "conectado por cabo"? Sim, e já tive problemas com atualização por não escutar isto. Mas não com OpenWRT. Se estiver atualizando (e não instalando a primeira vez!), pode fazer pela Wifi sem problemas. Quando a gravação for iniciada, todo o processo já está independente do computador cliente.

E depois do "Enter"/"Gravar", é a hora que você reza. Sempre dá um frio na barriga.

Se optar por preservar as configurações, tudo que seria guardado em um backup do sistema (listado pelo "sysupgrade -l") será restaurado. Se você instalou algum pacote e guardou a lista do que foi instalado, esta é a hora que você reinstala os pacotes desejados. Se for instalar manualmente, procure instalar os pacotes de mais alto nível (ex: "luci-app-minidlna" antes de "minidlna"), pois eles irão, por dependência, baixar os pacotes requeridos. No final do processo, é bom refazer a listagem do que está instalado e comparar com o que você tinha na versão anterior.

Não é comum no OpenWRT mas pode existir alguma atualização de segurança importante, como ocorreu com o Heartbleed. De qualquer forma, é bom listar os pacotes atualizáveis:

# opkg update
# opkg list-upgradable

O maior problema é que estas atualizações de segurança também ocupararão espaço a mais do seu roteador (overlay) pois apagar ou substituir arquivos existentes na firmware inicial não recupera o espaço usado no sistema de arquivos.

Por fim, faça um novo backup geral. É sempre bom preservar o seu trabalho.

Se precisar retornar a versão anterior do OpenWRT, realize a gravação da firmware antiga, entre no modo de recuperação e restaure a overlay.

Se você não usa uma unidade externa para expandir o espaço interno, seu trabalho acabou. Para os demais, o processo é um pouco mais complicado... Ao atualizar o sistema, você terá um kernel novo que é incompatível com os módulos de kernel existentes na unidade externa ou mesmo com as bibliotecas pertencentes à versão anterior. Você precisaria reinstalá-los. Esta é a sugestão de como proceder:

Em primeiro lugar, gere todos os backups sugeridos anteriormente. É importante preservar seu trabalho anterior. Ainda sem instalar a nova firmware, reinicie o sistema sem a unidade externa. Se você seguiu minha sugestão de manter uma configuração básica na flash interna, você ainda terá um ambiente funcional. Com isto, ele vai usar somente a flash interna (com a configuração que você tinha antes de usar a unidade externa).

Ainda com a unidade externa desconectada, faça o procedimento de atualização descrito neste artigo para quem não usa raiz expandida, inclusive com a etapa de backups. Você terá que preservar os dois conjuntos de backups: com e sem a unidade externa em uso. Ao final do processo, você deverá ter a sua configuração básica restabelecida. Caso tenha optado por não preservar as configurações na gravação, você pode aproveitar o backup gerado quando a unidade externa estava desconectada (o segundo) para restaurar as configurações.

Neste momento, a unidade externa ainda está com os programas da versão anterior, que são geralmente incompatíveis com a nova versão (os módulos de kernel sempre o são). Por isto, precisamos nos livrar de todos os arquivos da versão anterior do OpenWRT presentes na unidade externa. Na unidade externa, na partição usada como overlay, remova todo o conteúdo ou mova tudo para um subdiretório (ou para outra unidade se não estiver com espaço livre) afim de que este não seja usado. Como sugestão, crie um "openwrt-versao-xxx" e mova tudo para lá. Refaça a configuração de uso de uma unidade externa (que no mínimo será reinstalar os pacotes necessários). Reinicie o sistema. Você deve estar agora com mais espaço na raiz.

Neste ponto, você ainda terá as mesmas configurações que tinha quando usou o sistema sem a unidade externa. Envie o primeiro backup da versão anterior feito com a unidade externa conectada (primeiro backup). Na sequência, reinstale os pacotes extras, assim como é feito para ambientes sem a raiz expandida. Complete o trabalho com aquele backup final.

Espero que apreciem a nova versão. De agora em diante, vou apenas focar em configurações específicas do 15.05, que ainda podem funcionar nas versões 14.07, 12.09 e 10.03.1.

Se pintar um problema, tem sempre o fórum deste blog. Até a próxima.

OpenWRT: Fazendo Backups

Mais um artigo da série sobre o OpenWRT.

Antes de comentar como atualizar para a próxima versão do OpenWRT, achei interessante comentar sobre um assunto relacionado, mas tão importante que merece um artigo próprio: backups.

Tem gente que ainda confia em tecnologia. Brinco dizendo que não adianta rezar, só backup salva. Depois de fotos, vídeos, documentos, os roteadores são a última coisa que as pessoas se preocupam em fazer backup. Afinal de contas, para os mais simples, ele só contém o nome da rede e a senha. Porém, com o OpenWRT, seu roteador pode ser muito mais do que isto. O meu, em especial, é a central de comunicação, entreterimento e armazenamento da casa. Na prática, um servidor na rede com múltiplas funções. Como configurá-lo exige uma significativa quantidade de trabalho, sempre é bom evitar que você tenha que refazê-lo caso algo aconteça com ele.

Saindo do ambiente residencial, o tempo de restauração normalmente é crítico para ambientes empresariais. Neste caso, um backup "na mão" facilita em muito restaurar rapidamente um equipamento com defeito. Fora isto, backup podem ser utilizados para replicação "em massa", evitando o retrabalho de configurar o roteador "do zero" (para este fim, tem que recriar a entrada da ULA do IPv6).

Neste artigo, vou considerar que você conhece um básico do OpenWRT, como a estrutura que usa o squashfs com a overlay.

O OpenWRT tem backup? Sim, mas não de tudo. O backup do OpenWRT guarda somente configurações e dados selecionados do /etc. A lista do que ele copia pode ser vista com o comando "sysupgrade -l":

root@router:~~# sysupgrade -l

/etc/config/dhcp

...

/etc/sysctl.conf

/etc/sysupgrade.conf

São alguns arquivos pré-definidos, listados em /lib/upgrade/keep.d/ (pelos pacotes) ou em /etc/sysupgrade.conf, pelo usuário. Programas instalados não serão salvos, mas somente suas configurações (se estiverem em /etc/config ou forem explicitadas pelo mantenedor do pacote). É isto que é preservado quando você faz uma atualização do OpenWRT e pede para salvar as configurações. Compare isto com o conteúdo da overlay. Tudo que estiver lá foi modificado no seu sistema desde a instalação. O que estiver lá e não na listagem do sysupgrade, será perdido utilizando esta forma de backup. 

E quanto aos programas? Se você usa a firmware no formato squashfs, existem duas opções. A primeira é guardar a lista dos pacotes instalados e reinstalá-los. Para facilitar, você pode ver na /overlay:

root@router:~# ls /overlay/usr/lib/opkg/info/*control | sed -e 's%.*/%%;s/\.control//' | xargs

aiccu bind-dig bind-host bind-libs binutils block-mount coreutils-du coreutils ddns-scripts diffutils e2fsprogs...

Com a lista de pacotes salva, basta instalá-los após a restauração da configuração.

A segunda opção é guardar toda a overlay. Para salvar tudo mesmo que você fez desde a instalação do OpenWRT, é bom copiar a partição overlay. Um tar simples pode fazer o serviço. De um computador com Linux, execute:

$ ssh root@router tar -czv /overlay | dd of=backup-roteador.20150925.tgz

Isto compacta a /overlay em um tar e envia para o arquivo local backup-roteador.20150925.tgz sem criar o arquivo no roteador, que nem sempre tem espaço para isto. O WinSCP poderia copiar a overlay mas provavelmente você teria problemas com a permissão (perdida) dos arquivos. Se a overlay for pequena, você pode fazer o tar no /tmp (memória RAM) e copiar com o WinSCP:

root@router:~# tar -czvf /tmp/backup-roteador.20150925.tgz /overlay

Caso use Linux, fiz um pequeno script que faz a cópia do backup do OpenWRT, da lista de pacotes e da overlay em um único passo. Se seu roteador está em 192.168.1.1, só chamar:

$ ./fullbackup 192.168.1.1

E se eu não uso a firmware em squashfs? Primeiro você é corajoso pois se fizer algo de errado, não terá como usar a recuperação do OpenWRT. Contudo, isto não é um problema se o OpenWRT foi instalado em um PC ou VM. Para estes casos, faça o tar de todo o conteúdo. Só precisa tomar o cuidado de excluir os diretórios de dados voláteis (/proc, /sys, /tmp, /var/tmp, ...) ou simplesmente use a opção "--one-file-system" do tar para não sair da partição raíz.

E para restaurar tudo isto? Se for o backup do OpenWRT, pode ser feito pela interface web ou pelo comando sysupgrade. Se for pela overlay, recomendo entrar no modo de recuperação, zerar o roteador, montar a overlay e descompactar o conteúdo diretamente sobre a partição. Escrever na overlay enquanto ela estiver usada resulta em comportamentos incertos.

E, reforçando, não adianta rezar: só backup salva!

Se pintar um problema, tem sempre o fórum deste blog. Até a próxima.

OpenWRT: Atualizando para versão 14.07

Com o lançamento da nova versão do OpenWRT 14.07 (comentários), é chegada a hora de mais um upgrade. Prepare suas duas horas de janela de mudança, avise seus clientes da indisponibilidade do serviço internet e mão na massa.

Sim, este artigo repete diversos pontos do artigo de atualização anterior.

96,72% dos problemas com instalação/atualização com OpenWRT que ajudo é em relação a escolha incorreta da imagem da firmware. Como sempre, recomendo a versão squashfs, que possui modo de recuperação. Pegue o arquivo no download do Barrier Breaker e nunca em um endereço qualquer, mesmo que seja na wiki do OpenWRT. Normalmente a wiki referencia a versão em desenvolvimento, que não é o que você quer. No diretório de download, navegue seguindo o caminho da "arquitetura alvo" em uso no seu roteador. Você pode vê-la olhando o arquivo /etc/openwrt_release:

root@router:~# cat /etc/openwrt_release
DISTRIB_ID="OpenWrt"
DISTRIB_RELEASE="12.09"
DISTRIB_REVISION="r36088"
DISTRIB_CODENAME="attitude_adjustment"
DISTRIB_TARGET="ar71xx/generic"
DISTRIB_DESCRIPTION="OpenWrt Attitude Adjustment 12.09"

A diferença entre a primeira instalação e a atualização é que não será usada a imagem "factory" e sim a "sysupgrade". Escolha o arquivo correspondente ao seu roteador (inclusive versão de hardware!). E muito importante, leia a wiki do seu roteador independente se ele já funcionava na versão anterior! São poucos minutos de leitura que podem salvar horas de trabalho ou mesmo seu roteador.

Bem, se eu simplesmente ir na interface, fornecer a nova imagem, ele vai funcionar? Provavelmente, mas talvez não é a maneira que dê menos trabalho. A atualização pode preservar as configurações mas não os programas instalados. Se você tem disco raiz em unidade externa, a encrenca é ainda maior. Quem usa WDS para conectar dois segmentos de rede via wireless também pode ter que fazer um pequeno ajuste nos clientes, já que o BB não muda o SSID com múltiplos SID.

Mas eu nunca instalei um programa! OK, use a interface web e provavelmente todas as configurações serão migradas sem problemas. Mas faça o backup antes! Caso contrário, continue lendo.

Em primeiro lugar, precisamos do plano de retorno caso a nova versão não se comporte como o esperado. Faça um backup geral do seu sistema. Sugiro três coisas diferentes: backup gerado pelo openwrt, lista de pacotes instalados e todos os arquivos do overlay.

A primeira e mais simples é o backup que pode ser gerado pela interface WEB do OpenWRT. Este é obtido na mesma página de atualização de firmware do seu roteador. Ele contém uma seleção prévia de várias configurações, inclusive tudo que está em /etc/config. Contudo, o backup não irá manter outros arquivos modificados em /etc ou em outro lugar. Por exemplo, se você fez alguma modificação no /etc/dnsmasq.conf, ele não será preservado pois este arquivo não está selecionado para ser copiado. Se criou um script em /bin ou para os botões em /etc/hotplug.d/button, ele não será preservado. Para incluir estes e outros casos, informe o caminho destes arquivos extras em /etc/sysupgrade.conf. Na interface WEB também tem a edição deste arquivo, no mesmo local da atualização da firmware, na parte de configuração. Gere um arquivo de backup novo e verifique se tudo que você quer está lá dentro. Somente estes arquivos serão preservados em um upgrade.

Dica: olhe todo o conteúdo em /overlay. Ele terá tudo o que foi modificado. Cuide principalmente dos arquivos em /etc.

Porém, o backup do openwrt não é feito para guardar os programas instalados. Ele se limita a scripts, dados e arquivos de configuração pré-configurados e os listados em /etc/sysupgrade.conf. Programas instalados por pacotes devem ser reinstalados manualmente. Por isto a próxima sugestão.

A segunda sugestão é gerar uma listagem de todos os pacotes instalados. Ela será usada de referência para reinstalar todos os seus programas. Como os programas não serão preservados (somente suas configurações e se estiverem no backup) você terá que reinstalá-los. Em geral, é uma meia dúzia de programas. A lista dos pacotes instalados pode ser obtido pela interface web ou pelo comando "opkg list-installed". Contudo, eu prefiro observar o diretório /overlay/usr/lib/opkg/info. Como cada pacote instalado cria um arquivo de controle neste diretório e o /overlay terá somente os arquivos modificados, você terá ao menos um arquivo por novo pacote instalado. O comando abaixo lista todos estes pacotes instalados após a gravação da firmware:

find /overlay/usr/lib/opkg/info/ -name '*.control' -exec basename {} \; | sed -e 's/\.control$//' | sort

Em geral, se não souber para que serve, ignore as bibliotecas (lib*). Elas serão instaladas automaticamente quando os pacotes que dependem delas forem instalados.

A terceira sugestão é fazer um backup completo de todo o /overlay. Afinal de contas, falamos de poucos megabytes mas que são fruto de algumas horas de trabalho. A cópia pode ser feita com um tar. É provável que você não tenha espaço para criar este tar diretamente no roteador. Você terá que fazê-lo jogando em um disco externo conectado pela USB ou, a forma que eu geralmente uso, diretamente pela rede. Pela rede seria assim:

meucomputador$ ssh root@roteador tar -czv /overlay | cat > overlay.tar.gz

A vantagem deste backup é que, se esquecer de colocar algo em /etc/sysupgrade.conf, você poderá recuperá-lo do arquivo tar.gz. Também, se precisar retornar ao firmware antigo, você já teria uma partição overlay pronta. Bastaria instalar a firmware antiga e jogar o conteúdo da overlay por cima (preferencialmente em modo de recuperação!).

Agora, finalmente, você está pronto para enviar a nova firmware. Se você usa um espaço externo para expandir o disco, leia até o final deste post. Faça o upgrade pela interface web ou pelo terminal. Inclusive, você pode baixar o arquivo diretamente no roteador. Ex:

cd /tmp
wget http://downloads.openwrt.org/barrier_breaker/14.07/..../openwrt...xxx...img
sysupgrade openwrt...xxx....img 

Agora é a hora que você reza.

Se optar por preservar as configurações, tudo que seria guardado em um backup do sistema, inclusive o que está listado em /etc/sysupgrade.conf, será automaticamente levado ao novo sistema. Depois de o sistema iniciar na próxima versão e estiver funcionando, é hora de retornar os programas antigos. Se você guardou a lista dos programas instalados após a gravação da firmware que sugeri anteriormente, já terá a lista do que instalar.

A mudança nas versões dos pacotes é esperada e pode ser desconsiderada. Para facilitar, tente instalar primeiro os pacotes que dependem de outros, como os pacotes luci-app-*, antes de instalar os demais. É provável que, pela cadeia de dependências, grande parte será automaticamente instalada. Repita a geração dos programas instalados, a comparação e a instalação até estar satisfeito.

Não é comum no OpenWRT mas pode existir alguma atualização de segurança importante, como ocorreu com o Heartbleed. Na versão 14.07 apareceu uma vulnerabilidade do hostapd, que faz autenticação dos usuários. Se sua rede possui clientes não confiáveis (principalmente se você é um alvo em potencial), é bom atualizar. Os arquivos com a vulnerabilidade estão na imagem original e não foram atualizados. Para corrigir, você precisa instalar após a gravação da firmware. Esta atualização ocupará espaço a mais do seu disco (overlay) pois apagar ou substituir arquivos existentes na firmware original não recupera o espaço em disco usado.

Se quiser atualizar e estiver com espaço livre na overlay, a atualização é simples:

opkg update
opkg list-upgradable

E faça um "opkg install xxx" para os pacotes "xxx" listados. Ex:

opkg install wpad-mini hostapd-common

No futuro, novos pacotes com problemas de segurança podem ser atualizados e aparecerão no list-upgradable.

Por fim, faça um novo backup geral. É sempre bom preservar o seu trabalho.

Hum, e eu que uso um disco externo para expandir o espaço interno? É um pouco mais complicado... Ao atualizar o sistema, você terá um kernel novo que é incompatível com os módulos de kernel existentes no disco externo ou mesmo com as bibliotecas deste pertencentes à versão anterior. Você precisaria reinstalá-los. Esta é a sugestão de como proceder:

Em primeiro lugar, gere todos os backups sugeridos anteriormente. É importante preservar seu trabalho anterior. Ainda sem instalar a nova firmware, reinicie o sistema sem o disco externo. Se você seguiu minha sugestão, você ainda terá um ambiente básico funcional. Com isto, ele vai usar somente a flash interna (com a configuração que você tinha antes de usar o disco externo). Faça todos os backups novamente, preservando os anteriores.

Agora à instalação.

Ainda com o disco externo desconectado, instale a nova firmware. Faça uma configuração básica, que será o que você terá caso o roteador seja ligado sem a unidade externa. Caso tenha optado por não preservar as configurações na gravação, você pode aproveitar o backup gerado ainda na versão anterior mas com o disco desconectado.

Agora precisamos nos livrar de todos os arquivos da versão anterior do OpenWRT presentes no disco externo. No disco externo, na partição usada como overlay, remova todo o conteúdo ou mova tudo para um subdiretório (ou para outro disco se não estiver com espaço livre) afim de que este não seja usado. Como sugestão, crie um "openwrt-versao-xxx" e mova tudo para lá. Refaça a configuração de uso do disco externo (que no mínimo será reinstalar os pacotes necessários). Reinicie o sistema. Você deve estar com mais espaço em disco agora.

Neste ponto, você ainda terá as mesmas configurações que tinha quando usou o sistema sem o disco externo. Envie o primeiro backup da versão anterior feito ainda com o disco externo e siga os passos de reinstalação dos pacotes, assim como é feito para ambientes sem o disco expandido. Complete o trabalho com aquele backup final.

Espero que apreciem a nova versão. De agora em diante, vou apenas focar em configurações específicas do 14.07, que ainda podem funcionar nas versões 12.09 e 10.03.1.

Até mais.