user53815's questions

Estou tentando alterar o diretório raiz de um serviço da Web Apache /var/www/htmlpara meu diretório personalizado /mnt/webfiles. No entanto, depois de configurar os /etc/httpd/conf/httpd.confparâmetros e reiniciar httpd, meus diretórios/arquivos de teste ainda não podem ser navegados na página da web.

Aqui está o ambiente:
SO: CentOS 7.9.2009
Versão Apache: 2.4.6
O tipo de instalação do SO: Servidor web básico

O objetivo de usar o apache web é apenas para teste e não há exigência de nome de domínio específico neste servidor, apenas endereço IP para o cliente navegar na web.

Quando eu uso o diretório padrão /var/www/htmlpara colocar arquivos de teste, como um simples .txt agindo como uma página da web simples ou um subdiretório downloadcom um arquivo para simular a página de download, tudo funciona bem. A página da web pode ser navegada via navegador.

Mas, depois de mudar DocumentRoot "/var/www/html"para Directory "/var/www"meu diretório específico /mnt/webfiles, os arquivos/diretórios de teste /mnt/webfilesnunca poderão ser acessados ​​e a mensagem de erro mostrada no navegador seria como:

Forbidden
You don't have permission to access /download/ on this server.

Somente a página padrão do Apache pode ser navegada e não afetada.

O que fiz foi seguir as instruções deste post e deste ,

A propósito, a permissão dos arquivos/diretórios desde o diretório raiz do apache web é root:roote 775, basicamente a mesma que o /var/www/html.
Acho que essa não é a causa raiz.

Alguém sabe por que isso acontece?

Estou lidando com uma configuração de firewall do servidor RHEL versão 6.4 e o objetivo é permitir que o dispositivo remoto conecte a porta tcp 6162, independentemente do tipo de serviço.

As regras do iptables são mostradas abaixo( iptables -L --line-numbers), e o serviço iptables foi reiniciado.

num  target     prot opt source               destination
1    ACCEPT     all  --  anywhere             anywhere            state RELATED,ESTABLISHED
2    ACCEPT     icmp --  anywhere             anywhere
3    ACCEPT     all  --  anywhere             anywhere
4    ACCEPT     tcp  --  anywhere             anywhere            state NEW tcp dpt:ssh
5    ACCEPT     tcp  --  anywhere             anywhere            state NEW tcp dpt:6160
6    ACCEPT     tcp  --  anywhere             anywhere            state NEW tcp dpt:patrol-coll

Chain FORWARD (policy ACCEPT)
num  target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
num  target     prot opt source               destination

Além disso, configurei a porta que desejo em sytem-config-firewall, conforme mostrado na figura abaixo.

O estranho é:

Não importa como eu configuro o firewall/iptable, a porta 6162 simplesmente não pode ser aberta. Ele foi testado com cliente telnet de hosts remotos windows/linux que residem na mesma sub-rede IP deste servidor RHEL 6.4. A conexão com a porta 6162 foi recusada, mas outras funcionaram (como a porta 6160).

A porta TCP 6162 parecia ser sempre "patrol-coll", mas estritamente falando, quero permitir que qualquer tipo de serviço conecte a porta 6162, não apenas "patrol-coll". Não sei se o tipo de serviço impacta na conexão...

Alguém pode fornecer algumas dicas para solucionar o problema do lado do sistema operacional da conexão, por favor?

Notas1: a saída de netstat -tulpné mostrada abaixo.

Proto Recv-Q Send-Q Local Address               Foreign Address             State       PID/Program name
tcp        0      0 0.0.0.0:111                 0.0.0.0:*                   LISTEN      2538/rpcbind
tcp        0      0 192.9.110.1:1521            0.0.0.0:*                   LISTEN      4806/tnslsnr
tcp        0      0 0.0.0.0:37426               0.0.0.0:*                   LISTEN      4493/ora_d000_SOGOE
tcp        0      0 0.0.0.0:22                  0.0.0.0:*                   LISTEN      2917/sshd
tcp        0      0 0.0.0.0:46775               0.0.0.0:*                   LISTEN      4686/ora_d000_SOGOL
tcp        0      0 127.0.0.1:631               0.0.0.0:*                   LISTEN      2737/cupsd
tcp        0      0 127.0.0.1:10808             0.0.0.0:*                   LISTEN      3126/veeamservice
tcp        0      0 127.0.0.1:25                0.0.0.0:*                   LISTEN      3007/master
tcp        0      0 127.0.0.1:6010              0.0.0.0:*                   LISTEN      4046/sshd
tcp        0      0 127.0.0.1:199               0.0.0.0:*                   LISTEN      2869/snmpd
tcp        0      0 0.0.0.0:37449               0.0.0.0:*                   LISTEN      2657/rpc.statd
tcp        0      0 :::111                      :::*                        LISTEN      2538/rpcbind
tcp        0      0 :::6160                     :::*                        LISTEN      2886/veeamdeploymen
tcp        0      0 :::40976                    :::*                        LISTEN      2657/rpc.statd
tcp        0      0 :::22                       :::*                        LISTEN      2917/sshd
tcp        0      0 ::1:631                     :::*                        LISTEN      2737/cupsd
tcp        0      0 ::1:25                      :::*                        LISTEN      3007/master
tcp        0      0 ::1:6010                    :::*                        LISTEN      4046/sshd
udp        0      0 0.0.0.0:111                 0.0.0.0:*                               2538/rpcbind
udp        0      0 127.0.0.1:2547              0.0.0.0:*                               4495/ora_s000_SOGOE
udp        0      0 0.0.0.0:631                 0.0.0.0:*                               2737/cupsd
udp        0      0 0.0.0.0:1017                0.0.0.0:*                               2538/rpcbind
udp        0      0 127.0.0.1:13179             0.0.0.0:*                               4660/ora_pmon_SOGOL
udp        0      0 10.50.89.26:123             0.0.0.0:*                               2925/ntpd
udp        0      0 192.9.110.1:123             0.0.0.0:*                               2925/ntpd
udp        0      0 127.0.0.1:123               0.0.0.0:*                               2925/ntpd
udp        0      0 0.0.0.0:123                 0.0.0.0:*                               2925/ntpd
udp        0      0 0.0.0.0:28426               0.0.0.0:*                               4672/ora_lgwr_SOGOL
udp        0      0 0.0.0.0:18843               0.0.0.0:*                               2657/rpc.statd
udp        0      0 0.0.0.0:161                 0.0.0.0:*                               2869/snmpd
udp        0      0 127.0.0.1:22464             0.0.0.0:*                               4688/ora_s000_SOGOL
udp        0      0 0.0.0.0:9798                0.0.0.0:*                               4479/ora_lgwr_SOGOE
udp        0      0 0.0.0.0:713                 0.0.0.0:*                               2657/rpc.statd
udp        0      0 127.0.0.1:48982             0.0.0.0:*                               4467/ora_pmon_SOGOE
udp        0      0 127.0.0.1:26208             0.0.0.0:*                               4686/ora_d000_SOGOL
udp        0      0 127.0.0.1:54112             0.0.0.0:*                               4493/ora_d000_SOGOE
udp        0      0 :::111                      :::*                                    2538/rpcbind
udp        0      0 :::1017                     :::*                                    2538/rpcbind
udp        0      0 fe80::20c:29ff:fe74:83b5:123 :::*                                    2925/ntpd
udp        0      0 fe80::20c:29ff:fe74:83bf:123 :::*                                    2925/ntpd
udp        0      0 ::1:123                     :::*                                    2925/ntpd
udp        0      0 :::123                      :::*                                    2925/ntpd
udp        0      0 :::46340                    :::*                                    2657/rpc.statd```

No momento, estou testando um backup/restauração do sistema operacional RHEL 6.4 por meio do "despejo" e "restauração" no ambiente de teste e sei que o RHEL 6.4 parecia muito desatualizado hoje em dia. Mas algumas empresas ainda estão usando essa versão do RHEL para carregar seus serviços.

Aqui está o cenário : para fazer backup do sistema e dos programas críticos em caso de evento de travamento/falha do host.

• O host RHEL 6.4 de teste para backup utiliza Windows Hyper-V VM como infraestrutura e a raiz do sistema operacional é instalada no volume lógico LVM.
• Para fazer backup do sistema, coloquei o sistema no modo de usuário único e usei o comando para fazer backup do sistema de arquivos raiz

  dump -0uf /<path_to_a_second_storage_to_store_dump>/mybackup.dump /
  

• O despejo mostrou "DUMP IS DONE" na tela e o arquivo de despejo foi criado com tamanho de cerca de 2,2 GB, portanto, acredito que o backup foi bem-sucedido.

Para simular o evento de travamento do host, reinstalei o sistema RHEL 6.4 utilizando o volume lógico LVM e inicializei o sistema no modo de usuário único antes da restauração.

No entanto, depois de restaurar o sistema de arquivos raiz usando

restore -rf /<path_to_a_second_storage_to_store_dump>/mybackup.dump

A tela mostrou kernel panic e alguns outros erros, e acabou travando.

Tentei várias vezes, mas sempre falhei.

Alguém pode me dar algumas dicas porque a restauração não pode ser concluída?

Bem, a resposta é simples - usando o comando "journalctl".

Mas deixe-me descrever o problema primeiro,

Eu encontrei um evento de travamento do servidor ubuntu e alguns arquivos log/.journal foram extraídos com sucesso, e a próxima maneira de lidar com esse evento é ler/analisar esses arquivos.

Havia 2 pedidos sendo discutidos:

A. Como ler os arquivos .journal no ambiente Windows

B. outra maneira de ler os arquivos .journal além de usar o sistema operacional Windows

A primeira é a solicitação mais importante, mas eu a pulei porque parecia muito difícil e usar outro host ubuntu com o comando "journalctl --file /path_to_the_file" pode resolver o objetivo perfeitamente. (e também exportar o conteúdo para o arquivo .txt via " >" símbolo)

Agora descobri que, quando e depois de usar o comando "cat" para ler o arquivo .journal, aparecerá uma mensagem sem sentido na tela do console e não tenho escolha a não ser reiniciar para limpar a bagunça.

O comando "vi" também não funciona.

Então, o comando "journalctl" é a única e direta maneira de navegar normalmente pelo arquivo .journal?