Como obtenho acesso ao sistema de arquivos de uma instância da AWS parada (máquina virtual)?

2

Problema: Eu tenho uma instância do AWS t2.micro (máquina virtual) (nome: webserver) configurada com o Ubuntu 14.04 LTS. A instância está inutilizável devido a um arquivo de configuração que editei incorretamente e salvei. Eu preciso ter acesso ao sistema de arquivos da máquina virtual para que eu possa corrigir o arquivo de configuração quebrado na instância (nome: webserver) e (espero) recuperar a instância (VM) para que seja novamente utilizável.

Configuração: instância AWS t2.micro (nome: webserver) configurada com o Ubuntu 14.04 LTS. Esta instância é interrompida e o volume do EBS (name: broken) contendo a instância (name: webserver) foi montado em / mnt em uma segunda instância AWS t2.micro (name: recovery) executando o Ubuntu 14.04 LTS (o mesmo sistema operacional que o instância interrompida). O comando de montagem usado foi:

sudo mount -t sysfs xvdf /mnt

Eu também tentei com outros tipos de FS (ext2, ext4, auto), nenhum funcionou.

O comando fsblk produziu esta saída:

ubuntu@ip-172-xx-xx-xxx:~$ lsblk
NAME    MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda    202:0    0   8G  0 disk
└─xvda1 202:1    0   8G  0 part /
xvdf    202:80   0  24G  0 disk
└─xvdf1 202:81   0  24G  0 part

Montando xvdf1 com o comando:

ubuntu @ ip-172-xx-xx-xxx: ~ $ sudo mount -t sysfs xvdf1 / data

produz o mesmo conteúdo em / data como no diretório / mnt, conforme descrito abaixo.

Pergunta: Como eu acesso o sistema de arquivos do Ubuntu no volume montado do EBS (nome: quebrado)? Os diretórios e arquivos que estou procurando são por esta lista, tirada do servidor (nome: recuperação).

total 84
drwxr-xr-x  22 root root  4096 Jul 27 05:35 .
drwxr-xr-x  22 root root  4096 Jul 27 05:35 ..
drwxr-xr-x   2 root root  4096 Mar 25 11:52 bin
drwxr-xr-x   3 root root  4096 Mar 25 11:52 boot
drwxr-xr-x  13 root root  4020 Jul 25 16:53 dev
drwxr-xr-x  89 root root  4096 Jul 25 21:37 etc
drwxr-xr-x   3 root root  4096 Jul 25 15:46 home
lrwxrwxrwx   1 root root    33 Mar 25 11:51 initrd.img -> boot/initrd.img-3.13.0-48-generic
drwxr-xr-x  21 root root  4096 Mar 25 11:51 lib
drwxr-xr-x   2 root root  4096 Mar 25 11:50 lib64
drwx------   2 root root 16384 Mar 25 11:53 lost+found
drwxr-xr-x   2 root root  4096 Mar 25 11:50 media
drwxr-xr-x   2 root root  4096 Mar 25 11:50 opt
dr-xr-xr-x 109 root root     0 Jul 25 15:46 proc
drwx------   3 root root  4096 Jul 25 15:46 root
drwxr-xr-x  18 root root   660 Jul 26 06:27 run
drwxr-xr-x   2 root root  4096 Mar 25 11:52 sbin
drwxr-xr-x   2 root root  4096 Mar 25 11:50 srv
drwxrwx---  13 root root     0 Jul 26 14:17 sys

Os mesmos diretórios e arquivos devem estar em algum lugar no volume montado (nome: quebrado), mas não consegui encontrá-los.

Comentário / status: Quando uso o ls -al / mnt - recebo uma lista muito boa dos diretórios e arquivos da máquina virtual, de acordo com o seguinte.

total 4
drwxrwx--- 13 root root    0 Jul 26 14:17 .
drwxr-xr-x 22 root root 4096 Jul 27 05:35 ..
drwxr-xr-x  2 root root    0 Jul 25 15:46 block
drwxr-xr-x 28 root root    0 Jul 25 15:46 bus
drwxr-xr-x 46 root root    0 Jul 25 15:46 class
drwxr-xr-x  4 root root    0 Jul 25 15:46 dev
drwxr-xr-x 16 root root    0 Jul 25 15:46 devices
drwxr-xr-x  4 root root    0 Jul 25 15:46 firmware
drwxr-xr-x  7 root root    0 Jul 25 15:46 fs
drwxr-xr-x  5 root root    0 Jul 25 21:38 hypervisor
drwxr-xr-x  7 root root    0 Jul 25 15:46 kernel
drwxr-xr-x 92 root root    0 Jul 25 15:46 module
drwxr-xr-x  2 root root    0 Jul 25 21:38 power

Esses diretórios e arquivos são todos sobre a máquina virtual que executa o Ubuntu 14.04. Tanto quanto eu posso dizer, não há nada nesta estrutura de arquivos relacionada ao próprio sistema de arquivos do Ubuntu. Eu fiz uma listagem completa de / mnt, e procurei pelos diretórios e arquivos do sistema Ubuntu - sem sucesso.

Revisei a documentação da AWS e as man pages do Ubuntu para diretórios e arquivos e para acesso a elas. Eu também procurei em SuperUser, AskUbuntu e StackOverflow (e outros fóruns). Até agora eu não consegui descobrir a resposta, então estou me voltando para os especialistas da SuperUser para obter ajuda.

Minha suspeita é que a raiz do sistema de arquivos do Ubuntu é um link, em algum lugar na estrutura / mnt; e que um comando de ligação de alguma forma me dará acesso a ele. Até agora, porém, não vejo onde / como fazer isso.

TIA para ajudar a melhorar a pergunta ou uma resposta real.

    
por dvhirst 28.07.2015 / 06:50

1 resposta

-1

OK, graças a várias pessoas neste e em outros fóruns, encontrei a resposta. A chave é conhecer o tipo de sistema de arquivos da partição de interesse. O comando lsblk mostra onde o volume (name: broken) está montado. O comando mount sem parâmetros fornece as informações necessárias sobre o tipo de sistema de arquivos, que é ext4 nesse caso. Observe que vários outros tipos de sistemas de arquivos também possuem dados, mas não são os dados necessários para corrigir o problema.

ubuntu@ip-172-31-19-121:~$ lsblk
NAME    MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda    202:0    0   8G  0 disk
└─xvda1 202:1    0   8G  0 part /
xvdf    202:80   0  24G  0 disk
└─xvdf1 202:81   0  24G  0 part
ubuntu@ip-172-31-19-121:~$ mount
/dev/xvda1 on / type ext4 (rw,discard)
proc on /proc type proc (rw,noexec,nosuid,nodev)
sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
none on /sys/fs/cgroup type tmpfs (rw)
none on /sys/fs/fuse/connections type fusectl (rw)
none on /sys/kernel/debug type debugfs (rw)
none on /sys/kernel/security type securityfs (rw)
udev on /dev type devtmpfs (rw,mode=0755)
devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620)
tmpfs on /run type tmpfs (rw,noexec,nosuid,size=10%,mode=0755)
none on /run/lock type tmpfs (rw,noexec,nosuid,nodev,size=5242880)
none on /run/shm type tmpfs (rw,nosuid,nodev)
none on /run/user type tmpfs (rw,noexec,nosuid,nodev,size=104857600,mode=0755)
none on /sys/fs/pstore type pstore (rw)
systemd on /sys/fs/cgroup/systemd type cgroup (rw,noexec,nosuid,nodev,none,name=systemd)
ubuntu@ip-172-31-19-121:~$

Agora que isso é conhecido, crie o diretório do ponto de montagem:

ubuntu@ip-172-31-19-121:~$ mkdir ./mnt

... monte o volume:

ubuntu@ip-172-31-19-121:~$ sudo mount -t ext4 /dev/xvdf1 ./mnt

... verifique se os diretórios e arquivos corretos estão disponíveis:

ubuntu@ip-172-31-19-121:~$ ls -al ./mnt
total 100
drwxr-xr-x 22 root   root    4096 Jul 25 14:32 .
drwxr-xr-x  6 ubuntu ubuntu  4096 Jul 29 07:20 ..
drwxr-xr-x  2 root   root    4096 Mar 25 11:52 bin
drwxr-xr-x  3 root   root    4096 Mar 25 11:52 boot
drwxr-xr-x  5 root   root    4096 Mar 25 11:53 dev
drwxr-xr-x 89 root   root    4096 Jul 29 06:46 etc
drwxr-xr-x  4 root   root    4096 Jul 23 02:21 home
lrwxrwxrwx  1 root   root      33 Mar 25 11:51 initrd.img -> boot/initrd.img-3.13.0-48-generic
drwxr-xr-x 21 root   root    4096 Mar 25 11:51 lib
drwxr-xr-x  2 root   root    4096 Mar 25 11:50 lib64
drwx------  2 root   root   16384 Mar 25 11:53 lost+found
drwxr-xr-x  2 root   root    4096 Mar 25 11:50 media
drwxr-xr-x  2 root   root    4096 Apr 10  2014 mnt
drwxr-xr-x  2 root   root    4096 Mar 25 11:50 opt
drwxr-xr-x  2 root   root    4096 Apr 10  2014 proc
drwx------  3 root   root    4096 Jul 22 04:40 root
drwxr-xr-x  3 root   root    4096 Mar 25 11:53 run
drwxr-xr-x  2 root   root    4096 Mar 25 11:52 sbin
drwxr-xr-x  2 root   root    4096 Mar 25 11:50 srv
drwxr-xr-x  2 root   root    4096 Mar 13  2014 sys
drwxrwxrwt  2 root   root    4096 Jul 29 06:52 tmp
drwxr-xr-x 10 root   root    4096 Mar 25 11:50 usr
drwxr-xr-x 12 root   root    4096 Mar 25 11:52 var
lrwxrwxrwx  1 root   root      30 Mar 25 11:51 vmlinuz -> boot/vmlinuz-3.13.0-48-generic

... eles estão, então agora é hora de editar o arquivo quebrado:

ubuntu@ip-172-31-19-121:~$ sudo nano ./mnt/etc/sudoers

Sim, encontrei a linha incorreta, corrigi-a e escrevi o arquivo corrigido.

Próximas etapas:

  1. desmontar o volume recuperado,
  2. interrompa a instância de recuperação,
  3. separe o volume recuperado da instância de recuperação,
  4. anexe o volume recuperado à instância original (não se esqueça de especificar o nome do dispositivo de bloco como / dev / sda1 - use qualquer outra coisa, então NÃO FUNCIONA),
  5. reinicie a instância original e confirme se ela funciona corretamente.

Eu digitei incorretamente a entrada requerida, / dev / sda1 (tentei / dev / sda, / dev / xvda, etc. - sem permissão) e não a encontrei por um tempo. Portanto, embora o volume tenha sido anexado novamente, ele não foi reconhecido como o volume de inicialização. Uma vez que eu digitei / dev / sda1 como o nome do dispositivo de bloco, ele foi aceito, reconhecido como o volume de inicialização e tudo acabou de funcionar . TÃO contente isso é feito! Foi uma experiência real de aprendizado. Espero que isso ajude alguém que enfrenta esse tipo de problema.

    
por 29.07.2015 / 10:51