$ su -
2) Create the directory i.e. mount point:# mkdir -p /mnt/disk
3) Use mount command as follows to mount iso file called disk1.iso:# mount -o loop disk1.iso /mnt/disk
4) Change directory to list files stored inside an ISO image:# cd /mnt/disk
# ls -l
Para que não ocorra mais estas quedas nas conexões, podemos usar o recurso de Keep Alive, que traduzindo para português significa "Manter Vivo". O Keep Alive é um conceito que existe em diversas aplicações e consiste em um pequeno pacote descartável e sem nenhuma importância, que é mandado para o servidor de tempos em tempos. Isso faz com que a conexão TCP continue aberta e não feche por ociosidade ou outra razão.
Para o nosso problema, podemos configurar os clientes SSH para mandar os pacotes de Keep Alive em intervalos de por exemplo, 30 segundos.
Em sistemas Linux e semelhantes, geralmente utilizamos o cliente de SSH chamado OpenSSH. O arquivo de configuração do cliente do SSH é:
Então edite-o e adicione a seguinte linha no final do arquivo:
1 | ServerAliveInterval 30 |
Pronto. Das próximas vezes que você se conectar via comando ssh em servidores remotos, o OpenSSH irá mandar os pacotes de Keep Alive de 30 em 30 segundos, e assim sua conexão não irá cair por TCP Timeout.
Se você estiver com pressa e não quiser editar um arquivo de configuração, pode fazer isso na própria linha de comando quando for executar o ssh, adicionando a opção "-o TCPKeepAlive=yes", exemplo:
ssh -o TCPKeepAlive=yes servidor.remoto.com.br |
No Windows, acho que 99,9% das pessoas que acessam servidores remotos via SSH utilizam o cliente PuTTY. Neste caso, para habilitar os pacotes de Keep Alive, basta preencher o campo mostrado na imagem abaixo:
Situação normal no Linux é executar um comando direcionando sua saída para um arquivo (ou outro comando, como less) e ver que os erros não são direcionados corretamente, embora apareçam na tela. Por que isso acontece e como resolver?
Existem três streams de dados padrão em todo ambiente Linux:
Os programas recebem dados na stdin toda vez que você direciona algo para ele usando o pipe (comando | outro_comando) ou direciona o conteúdo de um arquivo (comando < arquivo.txt).
O resultado da execução de um programa em geral é jogado na saída padrão (stdout) e os erros na stderr. Embora apareça tudo na tela, na verdade saem por canais diferentes que desembocam no console.
Só que quando você usa direciona a saída usando um pipe ou ">" apenas a stdout é direcionada, a strerr continua indo para a tela. Para modificar esse fluxo, podem ser usados os artifícios abaixo:
| Ação | Comando |
|---|---|
| Redirecionar saída (stdout) para arquivo | comando > saida.txt |
| Redirecionar stderr para stdout | comando 2>&1 |
| Redirecionar stderr para stdout e então para arquivo | comando 2>&1 > saida.txt |
| Redirecionar stderr e stdout direto para arquivo | comando &> arquivo.txt |
Esse tipo de redirecionamento pode ser particularmente útil em scripts que rodam no cron, em que a saída stdout é direcionada para /dev/null mas stdout continua indo para o e-mail do administrador.
Found a fix for this problem. The following will force it to fix itself
sudo vmware-modconfig --console --install-all