DEV Community: Raphael Borges

Como Resolver Erro no Boot de uma VM na OCI Devido a Problemas no fstab e Usuário Root Bloqueado

Raphael Borges — Thu, 07 Aug 2025 13:17:10 +0000

Um problema que me ocorreu ao trabalhar com máquinas virtuais na Oracle Cloud Infrastructure (OCI) é a falha no boot devido a erros no arquivo fstab, combinados com a impossibilidade de acessar o usuário root no modo de emergência/recuperação. Este artigo descreve um procedimento detalhado para corrigir essa situação utilizando o modo de usuário único via GRUB.

Cenário do Problema

A VM não inicializa corretamente porque o arquivo fstab contém um erro de digitação na configuração (defalits em vez de defaults). Além disso, o usuário root está bloqueado, impedindo acesso via modo de emergência/recuperação para corrigir o problema. Para resolver, é necessário iniciar a VM em modo de usuário único.

Passos para Resolver

Acessar o Console da VM na OCI

Conectar ao Shell Console pela interface da OCI para gerenciar a máquina diretamente.
Pare a VM utilizando a opção de Stop forçado.
Reinicie a VM utilizando a opção de Start.

Modificar o GRUB para Iniciar em Modo de Usuário Único

Durante o boot, pressione rapidamente a tecla 'e' para interromper o boot e acessar as opções do GRUB.
Com o cursor sobre opção de boot, pressione ‘e’ novamente para editar a Entrada do GRUB.

Alterar os parâmetros da linha que começa com linux para incluir:

rw (para montar o sistema com permissão de leitura e escrita).
init=/bin/bash (para iniciar o shell diretamente).

Exemplo atualizado:

linux ($root)/vmlinuz-5.15.0-210.163.7.el9uek.x86_64 root=/dev/mapper/ocivolume-root rw quiet LANG=en_US.UTF-8 console=tty0 console=ttyS0,115200 init=/bin/bash

Pressione Ctrl+x ou F10 para inicializar a máquina com as alterações realizadas.

Corrigir o Arquivo fstab

Após o boot em modo usuário único, promova-se a root:
```
sudo su -
```
Criar um Backup do fstab:
```
cp /etc/fstab /etc/fstab.bkp
```

Editar o Arquivo fstab:
Recrie o arquivo fstab utilizando comandos echo:

echo "/dev/mapper/ocivolume-root / xfs defaults 0 0" > /etc/fstab
echo "UUID=<UUID> /boot xfs defaults 0 0" >> /etc/fstab
echo "UUID=<UUID> /boot/efi vfat defaults,uid=0,gid=0,umask=077,shortname=winnt 0 2" >> /etc/fstab
echo "/dev/mapper/ocivolume-oled /var/oled xfs defaults 0 0" >> /etc/fstab
echo "tmpfs /dev/shm tmpfs defaults,nodev,nosuid,noexec 0 0" >> /etc/fstab
echo "UUID=<UUID> /mnt/logs xfs defaults 0 0" >> /etc/fstab
echo "/.swapfile none swap sw,comment=cloudconfig 0 0" >> /etc/fstab

Reiniciar a VM
Após corrigir o fstab, reinicie a máquina para verificar se o problema foi resolvido:
```
reboot
```

Conclusão:

Seguindo este procedimento, é possível corrigir o erro no fstab e outros problemas, recuperando o acesso à máquina virtual. Utilizando o modo de usuário único via GRUB em situações onde o acesso ao root está bloqueado e o sistema não inicializa corretamente.

Do you already know Digestabot?

Raphael Borges — Wed, 27 Dec 2023 14:32:05 +0000

In summary, Digestabot is a GitHub Action developed by Chainguard to keep your images always up-to-date, minimizing the risks of CVEs (Common Vulnerabilities and Exposures).

Using the 'tag+digest' pattern, the Action opens a Pull Request (PR) to update the image in use, and the user only needs to approve the merge with the most recent version(s), not only from Chainguard but also from any other registry used in the repository.

Consider the following configurations when utilizing Digestabot:

Your images must follow the <repo>:<tag>@sha256:<digest> pattern. For example, cgr.dev/chainguard/nginx:latest@sha256:81bed54c9e507503766c0f8f030f869705dae486f37c2a003bb5b12bcfcc713f.
You need to authorize GitHub Actions to create Pull Requests in the Settings -> Actions tab by selecting the option 'Allow GitHub Actions to create and approve pull requests.'

Now let's create the digestabot.yml file in the .github/workflows directory.

name: Image digest update

on:
  workflow_dispatch:
  schedule:
    # Every day at 00:00 UTC
    - cron: "0 0 * * *"

jobs:
  image-update:
    name: Image digest update
    runs-on: ubuntu-latest

    permissions:
      contents: write # Write access to the repository
      pull-requests: write # Permission to create pull requests
      id-token: write # It's necessary to create the `JWT` token

    steps:
    - uses: actions/checkout@v4
    - uses: chainguard-dev/digestabot@v1.0.2
      with:
        token: ${{ secrets.GITHUB_TOKEN }}
        signoff: true # Add the email field to the commit
        author: update-bot # Set the author of the commit
        committer: update-bot@example.com # Set the committer email
        labels-for-pr: automated pr, kind/cleanup, release-note-none # Set the labels for the PR
        branch-for-pr: update-digests # Set the branch name for the PR
        title-for-pr: Update images digests # Set the PR title
        commit-message: Update images digests # Set the commit message

For more information about Digestabot, please access the Action's link on the Marketplace or the official repository on GitHub.

Você já conhece o Digestabot?

Raphael Borges — Mon, 18 Dec 2023 13:00:00 +0000

Em resumo, o Digestabot é uma GitHub Action desenvolvida pela Chainguard para manter suas imagens sempre atualizadas, com o objetivo de minimizar os riscos de CVE (Vulnerabilidades Comuns e Exposições, do inglês "Common Vulnerabilities and Exposures").

Utilizando o padrão "tag+digest", a Action atualiza a imagem em uso e abre um Pull Request (PR) para que o usuário faça o merge com a(s) versão(ões) mais recente(s) da(s) imagem(ns) nao só da Chainguard, mas também de qualquer outro registry utilizado no repositório.

Algumas configurações às quais você deve estar atento ao usar o Digestabot:

Suas imagens devem seguir o padrão <repo>:<tag>@sha256:<digest>. Por exemplo, cgr.dev/chainguard/nginx:latest@sha256:81bed54c9e507503766c0f8f030f869705dae486f37c2a003bb5b12bcfcc713f.
É necessário autorizar o GitHub Actions para criar Pull Requests na aba Settings -> Actions marcando a opção Allow GitHub Actions to create and approve pull requests.

Para utilizar o Digestabot, vamos criar o arquivo digestabot.yml em .github/workflows

name: Image digest update

on:
  workflow_dispatch:
  schedule:
    # Agendado para rodar todos os dias as 00:00
    - cron: "0 0 * * *"

jobs:
  image-update:
    name: Image digest update
    runs-on: ubuntu-latest

    permissions:
      contents: write # Permissão para escrever no repositório
      pull-requests: write # Permissão para abrir PRs
      id-token: write # Necessário para solicitar o JWT (JSON Web Token)

    steps:
    - uses: actions/checkout@v4
    - uses: chainguard-dev/digestabot@v1.0.2
      with:
        token: ${{ secrets.GITHUB_TOKEN }}
        signoff: true # Adiciona o campo email ao commit  
        author: update-bot # Define o autor do commit
        committer: update-bot@example.com # Define o email do autor do commit
        labels-for-pr: automated pr, kind/cleanup, release-note-none # Define as labels do PR
        branch-for-pr: update-digests # Define o nome da branch do PR
        title-for-pr: Update images digests # Define o título do PR
        commit-message: Update images digests # Define a mensagem do commit

Para mais informações sobre o Digestabot acesse o link da Action no Marketplace ou o repositório oficial no GitHub..

A custom action to deploy mdBook

Raphael Borges — Tue, 23 May 2023 15:37:35 +0000

What I built

I built a Github action for automating the deployment of a compiled book.

Category Submission:

DIY Deployments - DevOps & CI/CD

App Link

https://github.com/Rapha-Borges/mdBook-action

Screenshots

Description

This Github action is designed to be triggered when a push occurs on the "main" branch of a repository. It performs a series of steps within a job named "build" on the latest version of the Ubuntu operating system.

The action utilizes a Docker container with the image "raphaelborges/mdbook:1.0.2" to compile a book located at the path "/github/workspace/book". It then executes a shell script named "copy.sh".

The "copy.sh" script creates a worktree, sets Git configuration, deletes and clears the "gh-pages" branch, copies files from specified directories, commits the changes, and pushes them to the "gh-pages" branch on the remote repository.

This action automates the process of compiling the book and deploying it to a designated location using custom settings, simplifying the workflow for users.

Link to Source Code

https://github.com/Rapha-Borges/mdBook-action

Permissive License

MIT License

Background (What made you decide to build this particular app? What inspired you?)

I built this Github action to automate the deployment of ebooks using customized configurations that better meet the needs of the projects I am involved in. The motivation behind creating this action was to streamline the process and eliminate manual steps required for ebook deployment.

How I built it (How did you utilize GitHub Actions or GitHub Codespaces? Did you learn something new along the way? Pick up a new skill?)

To build this Github action, I leveraged the power of GitHub Actions, which provides a flexible and robust platform for automating workflows. I utilized the "actions/checkout@v3" action to perform repository checkout and the "docker://" syntax to use a specific Docker container for compiling the book. The shell script, "copy.sh," was developed to handle the file copying and Git operations required for deployment.

During the development process, I gained valuable experience in utilizing GitHub Actions to orchestrate CI/CD workflows. I learned about Docker integration within GitHub Actions, enabling seamless execution of tasks in isolated environments.

Additional Resources/Info

For more information about this project, please refer to the official repository at [https://github.com/Rapha-Borges/mdBook-action].

Additionally, you can find examples of usage and implementation at the following links: [https://github.com/badtuxx/DescomplicandoPrometheus], [https://github.com/rochacbruno/py2rs].

Um servidor DNS Recursivo rápido, seguro e escalável

Raphael Borges — Mon, 01 May 2023 21:06:36 +0000

O que é o Unbound?

O Unbound é um servidor DNS recursivo que tem a capacidade de pesquisar informações de DNS em nome de seus clientes, permitindo que nomes de domínio sejam traduzidos em endereços IP. Projetado para ser rápido, seguro e escalável, o Unbound é uma solução de software livre que é frequentemente usado para melhorar a privacidade e segurança online. Além disso, ele possui uma arquitetura modular e pode ser configurado para suportar várias extensões, tornando-o altamente personalizável e flexível.

Algumas das principais características e funcionalidades do Unbound incluem:

Segurança: O Unbound é projetado para ser resistente a ataques de DNS spoofing e cache poisoning. Ele utiliza criptografia DNSSEC para garantir que as respostas DNS recebidas sejam autênticas e não foram modificadas durante a transmissão.

Velocidade: O Unbound é otimizado para alto desempenho e baixa latência. Ele usa técnicas de caching e pre-fetching para minimizar o tempo de resposta e reduzir a sobrecarga do servidor.

Escalabilidade: O Unbound é capaz de lidar com grandes volumes de consultas DNS simultâneas e pode ser facilmente escalado adicionando mais servidores.

Flexibilidade: O Unbound é altamente configurável e pode ser personalizado para atender às necessidades específicas de um ambiente de rede. Ele suporta vários tipos de consultas DNS, incluindo consultas recursivas e consultas diretas.

Fácil integração: O Unbound é compatível com vários sistemas operacionais, como Linux, FreeBSD, macOS e Windows. Ele também pode ser integrado com outros servidores DNS, como BIND e PowerDNS.

Como o Unbound funciona:

Recebimento de consultas: O Unbound recebe consultas DNS de seus clientes (usuários finais ou outros servidores DNS). Essas consultas incluem um nome de domínio que precisa ser resolvido em um endereço IP.
Resolução recursiva: O Unbound inicia o processo de resolução recursiva, onde ele envia a consulta DNS para o servidor raiz (root server) responsável pelo domínio de nível superior (TLD) correspondente ao nome de domínio. O servidor raiz responde com uma lista de servidores DNS autoritativos para o TLD correspondente.
Consulta aos servidores autoritativos: O Unbound envia a consulta DNS para um dos servidores DNS autoritativos listados pelo servidor raiz. O servidor autoritativo responde com um registro de recurso (RR) que contém informações sobre o nome de domínio, como um registro A (endereço IP) ou um registro MX (servidor de e-mail).
Caching: O Unbound armazena em cache a resposta DNS recebida do servidor autoritativo para acelerar consultas futuras para o mesmo nome de domínio. Isso ajuda a reduzir o tempo de resposta e a carga no servidor.
Retorno da resposta: O Unbound retorna a resposta DNS ao cliente que iniciou a consulta original. O cliente agora tem o endereço IP correspondente ao nome de domínio que estava tentando resolver.

No diagrama acima, o cliente faz uma consulta DNS para o servidor Unbound. O servidor Unbound, em seguida, inicia o processo de resolução recursiva, enviando a consulta DNS para o servidor raiz responsável pelo TLD correspondente. O servidor raiz responde com uma lista de servidores DNS autoritativos para o TLD correspondente, que o servidor Unbound usa para consultar um servidor autoritativo específico. O servidor autoritativo responde com a resposta DNS contendo as informações solicitadas, que o servidor Unbound, em seguida, retorna ao cliente.

É importante destacar que durante todo esse processo de resolução recursiva, o servidor Unbound utiliza seu cache local para armazenar as respostas de consultas anteriores. Isso significa que se o servidor Unbound já tiver a resposta em seu cache local, ele não precisará passar por todo o processo de consulta recursiva, o que torna o processo de resolução de consultas DNS muito mais rápido.

DNSSEC (Domain Name System Security Extensions)

O DNSSEC é uma extensão de segurança do DNS que foi projetada para proteger o DNS contra ataques de falsificação de DNS. O DNSSEC utiliza criptografia de chave pública para assinar digitalmente os registros DNS, permitindo que os clientes possam verificar se os registros DNS recebidos são autênticos e não foram adulterados.

O Unbound pode verificar a autenticidade dos registros DNS usando DNSSEC. Quando um cliente faz uma consulta DNS, o Unbound envia a consulta para o servidor raiz responsável pelo TLD correspondente, que responde com uma lista de servidores DNS autoritativos para o TLD e chaves de assinatura DNSSEC. O Unbound usa as chaves de assinatura para verificar a autenticidade dos registros DNS recebidos dos servidores autoritativos.

Se o registro DNS não for autêntico ou não puder ser verificado, o Unbound não irá retornar o registro para o cliente, garantindo a integridade e autenticidade das informações DNS. Isso ajuda a proteger os usuários contra ataques de falsificação de DNS e aumenta a segurança e confiabilidade do sistema de resolução de nomes de domínio.

Instalação do Unbound

O Unbound pode ser configurado de três maneiras:

Como um DNS de cache recursivo simples, usando a porta UDP 53 sem criptografia.
Como um DNS sobre TLS, com cache recursivo DNS, usando a porta TCP 853 ENCRYPTED.
Como um DNS autoritativo, validador e de cache recursivo.

Para maior segurança, neste exemplo, utilizaremos a terceira configuração. O Unbound consultará recursivamente qualquer nome de host dos servidores DNS raiz dos quais não possui uma cópia em cache e validará as consultas usando DNSSEC e bits aleatórios codificados em 0x20 para evitar tentativas de falsificação. Além disso, esse servidor podera ser o DNS autorizado para alguns nomes de host em sua LAN.

Para iniciar, algumas etapas de configuração são necessárias. Primeiramente, é preciso obter uma cópia atualizada da lista de servidores DNS raiz, denominada root.hints. Em seguida, é necessário obter a configuração da chave confiável raiz DNSSEC. Por fim, é preciso configurar quaisquer nomes de host e endereços IP de sua LAN.

Instalando o Unbound

O Unbound está disponível nos repositórios oficiais do Ubuntu. Para instalar o Unbound, execute o seguinte comando:



sudo apt install unbound

Configurando o Unbound

O arquivo de configuração padrão do Unbound é /etc/unbound/unbound.conf. Caso queira aprender mais sobre todas as opções de configuração disponíveis, o arquivo de configuração padrão vem com muitos comentários que explicam o que cada opção faz.

Para este exemplo, vamos utilizar o arquivo de configuração unbound.conf que ficará no diretório /etc/unbound/unbound.conf.d/



sudo nano /etc/unbound/unbound.conf.d/unbound.conf

Obtendo a lista de servidores DNS raiz

A lista de servidores DNS raiz é um arquivo chamado root.hints que contém os endereços IP dos servidores raiz. O Unbound usa esse arquivo para iniciar o processo de resolução recursiva.

O arquivo root.hints pode ser obtido no site do IANA (Internet Assigned Numbers Authority) em https://www.iana.org/domains/root/servers.



wget https://www.internic.net/domain/named.root -O /var/lib/unbound/root.hints

Obtendo a configuração da chave confiável raiz DNSSEC

O Unbound usa a configuração da chave confiável raiz DNSSEC para verificar a autenticidade dos registros DNS recebidos dos servidores DNS raiz. A configuração da chave confiável raiz DNSSEC pode ser obtida no site do IANA em https://www.iana.org/dnssec/files mas essa chave não é atualizada com frequência então você pode usar os valores abaixo ou verificar se existe uma versão mais atualizada em https://data.iana.org/root-anchors/root-anchors.xml.



IN DS 19036 8 2 49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5
IN DS 20326 8 2 E06D44B80B8F1D39A95C0B0D7C65D08458E880409BBC683457104237C7F8EC8D

Crie o arquivo root.key e adicione os valores acima.



sudo nano /etc/unbound/root.key

Certifique-se de que o arquivo root.key é de propriedade do usuário com o qual o daemon do Unbound está sendo executado, neste exemplo estamos utilizando o usuário unbound.



sudo chown unbound:unbound /etc/unbound/root.key

Habilite e reinicie o serviço do Unbound.



sudo systemctl enable unbound
sudo systemctl restart unbound

Zonas atendidas localmente

O Unbound pode ser configurado para atender localmente a determinadas zonas. Isso é útil para nomes de host que não são resolvidos corretamente pelos servidores DNS raiz. Por exemplo, se você tiver um servidor de arquivos chamado files.example.com, poderá configurar o Unbound para atender localmente a esse nome de host. Isso significa que o Unbound não precisará consultar os servidores DNS raiz para resolver esse nome de host.

No exemplo, é configurado o nome de host fileserver.home.lan resolvendo para o endereço IP 10.2.2.1. Além disso, é configurada uma pesquisa reversa para permitir que 10.2.2.1 resolva de volta para o nome do host fileserver.home.lan.

Isso pode ser feito adicionando as seguintes linhas no arquivo /etc/unbound/unbound.conf.d/unbound.conf:




# locally served zones can be configured for the machines on the LAN.

    local-zone: "home.lan." static

    local-data: "fileserver.home.lan.  IN A 10.2.2.1"

    local-data-ptr: "10.2.2.1  fileserver.home.lan"

Testando o Unbound

Para testar se o Unbound está funcionando corretamente e com o DNSSEC habilitado, execute o seguinte comando:



dig com. SOA +dnssec

Se o Unbound estiver funcionando corretamente, você verá a flag ad no resultado:

Resolvendo problemas

Resolvendo nomes de host localmente

Para que o servidor que está rodando o Unbound possa resolver nomes de host, pode ser necessário configurar o arquivo /etc/resolv.conf para que o Unbound seja o servidor DNS padrão.



sudo nano /etc/resolv.conf

Adicione a linha abaixo no arquivo /etc/resolv.conf para que o Unbound seja o servidor DNS padrão.



nameserver 127.0.0.1

Após isso desative o serviço systemd-resolved para que o arquivo /etc/resolv.conf não seja sobrescrito.



sudo systemctl disable systemd-resolved

Reinicie o sistema para que as alterações tenham efeito.



sudo reboot

Resolvendo nomes de host em outra rede ou sub-rede

Para que os dispositivos de outra rede ou sub-rede possam resolver nomes de host, pode ser necessário adicionar a interface de rede no arquivo /etc/unbound/unbound.conf.d/unbound.conf.



sudo nano /etc/unbound/unbound.conf.d/unbound.conf

Adicione a linha abaixo no arquivo /etc/unbound/unbound.conf.d/unbound.conf para que o Unbound possa resolver nomes de host em outra rede ou sub-rede.



interface: xxx.xxx.xxx.xxx

Além disso, pode ser necessário adicionar o endereço IP de rede ou do dispositivo no arquivo /etc/unbound/unbound.conf.d/unbound.conf. Para isso adicione a linha abaixo no arquivo /etc/unbound/unbound.conf.d/unbound.conf para que o Unbound possa resolver nomes de host em outra rede ou sub-rede.



access-control: xxx.xxx.xxx.xxx/xx allow

Reinicie o sistema para que as alterações tenham efeito.



sudo reboot