Tenho uma instância do Apache em execução onde 150 clientes usam long polling em alguns scripts PHP para receber atualizações sobre novos arquivos que foram enviados. Isso, é claro, cria 150 threads do Apache. Agora parece que o servidor web está no seu limite (é uma máquina de 10 anos) e não quero carregar essa bagagem para um novo servidor.

Estou pensando em usar um servidor WebSocket que lidaria com o caso de uso de forma mais eficiente, mas me pergunto se 150 clientes acessando o Apache que encaminha as solicitações para meu servidor WebSocket também produziriam tantos threads do Apache ou se há uma maneira mais eficiente de lidar com isso.

Não posso substituir o Apache, talvez apenas com nginx porque ele também tem que fornecer uma homepage. Não posso usar outra porta para o servidor WebSocket porque isso significaria que eu teria que discutir regras de atualização de firewall com cerca de 100 clientes. Isso é solucionável?

Habilitei o SSL no meu banco de dados PostgreSQL e o apliquei usando pg_hba.confa seguinte linha:

hostssl all all 0.0.0.0/0 md5

A partir dos logs de conexão do PostgreSQL e do tráfego de rede capturado via tcpdump, parece que conexões SSL estão sendo feitas:

2024-10-20 10:12:16.140 UTC [63] LOG:  connection authenticated: identity="user" method=md5 (/etc/postgresql/pg_hba.conf:136)
2024-10-20 10:12:16.140 UTC [63] LOG:  connection authorized: user=user database=db SSL enabled (protocol=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384, bits=256)

No entanto, como o Dovecot e o PostgreSQL estão sendo executados em máquinas diferentes e o certificado e sua CA não são confiáveis ​​na máquina dovecot, eu esperava que o Dovecot, que se conecta ao PostgreSQL, sinalizasse um problema com o certificado autoassinado, mas não há reclamações. Isso me leva a acreditar que o certificado não está sendo validado corretamente, tornando a conexão vulnerável a ataques como MITM (Man-in-the-Middle).

Há alguma configuração extra ou etapa que estou esquecendo para impor a validação do certificado? Como posso garantir que as conexões sejam seguras e que o certificado esteja sendo validado corretamente?

Quero que meu docker nginx seja capaz de fazer proxy_pass dinamicamente, de qualquer forma, usando uma configuração simples.

Atualmente, uso essa configuração para três aplicativos, mas gostaria de fazê-la funcionar dinamicamente para que eu também pudesse usá-la com /xyz_987, que passa automaticamente para http://xyz_987:3000:

server {
    listen 3000;
    server_name _;

    location /user1/ {
        proxy_pass http://user1:3000;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;
    }

    location /user2/ {
        proxy_pass http://user2:3000;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;
    }

    location /user3/ {
        proxy_pass http://user3:3000;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;
    }
}

Eu tentei isso, mas sempre resulta em um 502 Bad Gateway:

server {
    listen 3000;
    server_name _;

    location ~ ^/(?<username>[\w]+)/ {
        proxy_pass http://$username:3000;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;
    }

    # Fallback for root path
    location / {
        return 404;
    }
}

Isso começou depois de instalar o Google Chrome (para funcionalidade de navegador headless). Estou concluindo que tem algo a ver com o Chrome. Nas primeiras horas após a instalação, eu estava construindo um script de curta duração chamando o Chrome em um navegador remoto.

2 lados da questão. É aceitável que o systemd seja executado continuamente e, se sim, como os alertas podem ser suprimidos?

Tenho recebido os relatórios abaixo há dias para as 2 contas de revendedor (4 no total a cada hora). Observe que o tempo do processo está em "dias".

Time:         Sat Oct 19 08:44:54 2024 -0400
Account:      accountname
Resource:     Process Time
Exceeded:     376436 > 1800 (seconds)
Executable:   /usr/lib/systemd/systemd
Command Line: (sd-pam)
PID:          35343 (Parent PID:35342)
Killed:       No

e

Time:         Sat Oct 19 08:44:54 2024 -0400
Account:      accountname
Resource:     Process Time
Exceeded:     376436 > 1800 (seconds)
Executable:   /usr/lib/systemd/systemd
Command Line: /lib/systemd/systemd --user
PID:          35342 (Parent PID:35342)
Killed:       No

Depois de adicionar as 4 linhas a seguir ao csf.piginore e reiniciar o LFD, os alertas continuam chegando.

pcmd: /usr/lib/systemd/systemd
pexe: /usr/lib/systemd/systemd
cmd: (sd-pam)
cmd: /lib/systemd/systemd --user

** Editar ** adicionando imagens para a resposta do grawity.

Infelizmente, não tenho muita experiência com administração de sistemas e configuração de sistemas Linux, então, por favor, não seja tão duro comigo; ainda estou aprendendo ;)

Configuração de rede:

172.21.0.1 - o servidor com modelagem de tráfego.

172.21.0.2 - o segundo servidor que armazena arquivos solicitados pelos clientes via HTTP.

172.21.0.6 e 172.21.0.7 - dois dispositivos clientes.

Estou tentando configurar a modelagem de tráfego para clientes WireGuard:

tc qdisc add dev wg0 parent root handle 1:0 hfsc default 10

# Root class
tc class add dev wg0 parent 1: classid 1:1 hfsc sc rate 1gbit ul rate 1gbit

# Reserved traffic
# Guaranteed bandwidth of 500 Mbit/s and a maximum of 1 Gbit/s
tc class add dev wg0 parent 1:1 classid 1:10 hfsc sc rate 500mbit ul rate 1gbit

# Client traffic
# Guaranteed bandwidth of 500 Mbit/s and a maximum of 1 Gbit/s
tc class add dev wg0 parent 1:1 classid 1:20 hfsc sc rate 500mbit ul rate 1gbit

# Shaping for individual client 6
tc class add dev wg0 parent 1:20 classid 1:3006 hfsc sc rate 100kbit ul rate 100kbit
tc filter add dev wg0 protocol ip parent 1:0 prio 1 u32 match ip dst 172.21.0.6/32 flowid 1:3006

# Shaping for individual client 7
tc class add dev wg0 parent 1:20 classid 1:3007 hfsc sc rate 100kbit ul rate 100kbit
tc filter add dev wg0 protocol ip parent 1:0 prio 1 u32 match ip dst 172.21.0.7/32 flowid 1:3007

tc -pretty filtro mostra dev wg0

filter parent 1: protocol ip pref 2 u32 chain 0
filter parent 1: protocol ip pref 2 u32 chain 0 fh 800: ht divisor 1
filter parent 1: protocol ip pref 2 u32 chain 0 fh 800::801 order 2049 key ht 800 bkt 0 *flowid 1:3006 not_in_hw
  match IP dst 172.21.0.6/32
filter parent 1: protocol ip pref 2 u32 chain 0 fh 800::802 order 2050 key ht 800 bkt 0 *flowid 1:3007 not_in_hw
  match IP dst 172.21.0.7/32

tc -graph classe mostra dev wg0

+---(1:) hfsc
     +---(1:1) hfsc sc m1 0bit d 0us m2 1Gbit ul m1 0bit d 0us m2 1Gbit
          +---(1:10) hfsc sc m1 0bit d 0us m2 500Mbit ul m1 0bit d 0us m2 1Gbit
          +---(1:20) hfsc sc m1 0bit d 0us m2 500Mbit ul m1 0bit d 0us m2 1Gbit
               +---(1:3007) hfsc sc m1 0bit d 0us m2 100Kbit ul m1 0bit d 0us m2 100Kbit
               +---(1:3006) hfsc sc m1 0bit d 0us m2 100Kbit ul m1 0bit d 0us m2 100Kbit
          |
     |    |

Ao tentar baixar um arquivo de ambos os clientes ao mesmo tempo, apenas um obtém 100 kbit, enquanto o outro obtém 0 kbit :(

O que estou fazendo errado? Servidor: Debian 12 rodando em KVM.

PS: O limite de 100 kbit/s é apenas para testar a funcionalidade do modelador de tráfego.

Eu também apreciaria sugestões sobre como reescrever a configuração. Talvez eu esteja fazendo isso completamente errado, e pode haver uma maneira mais otimizada (como configurar uma única classe para toda a sub-rede, para que todos os clientes WireGuard tenham um limite individual de 100 kbit).

Preciso de ajuda para redirecionar o tráfego na minha máquina virtual Ubuntu rodando em parallels para a porta 443 com uma URL de túnel para a porta 1111 na mesma máquina Ubuntu. Uma vez que isso for bem-sucedido, o servidor em 1111 deve encaminhar a solicitação para a URL do túnel. Por algum motivo, quando tento usar iptables e HAProxy, não funciona

No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 20.04.2 LTS
Release:    20.04
Codename:   focal

Para IPTables

Tentei definir ip_forward config flag to 1se é assim que você chama.

Tentei definir a configuração de pré-roteamento para o seguinte:

sudo iptables -t nat -A PREROUTING -p tcp -d rnqhc-adas-ads-ed01-cb00-sada-asdds-asdd-iii.a.free.pinggy.link --dport 443 -j DNAT --to-destination 127.0.0.1:1111

Then I've masqueraded it.

E acrescentou

sudo iptables -t nat -A OUTPUT -p tcp --dport 443 -d rnqhc-adas-ads-ed01-cb00-sada-asdds-asdd-iii.a.free.pinggy.link -j ACCEPT

Também vi respostas de: O redirecionamento de tráfego do IPTables não está funcionando , mas não ajudou.

Para HAProxy eu tentei:

frontend https_front
    bind *:443 ssl crt /home/devhouse/Developer/mycert_combined.pem
    acl host_mydomain hdr(host) rnqhc-adas-ads-ed01-cb00-sada-asdds-asdd-iii.a.free.pinggy.link
    use_backend my_backend if host_mydomain

backend my_backend
    server local_proxy 127.0.0.1:1111

Acho que estou esquecendo de alguma coisa

Não sei mais como solucionar esse problema. Espero encontrar ajuda.

Quando excluo um serviço de computação com: openstack compute service delete a04910ef-1441-4949-8ffb-6393c22141b2, posso reiniciá-lo nova-computena máquina com sudo systemctl restart nova-computepara obter o serviço novamente no OpenStack.

Entretanto, o nó não está mais listado em openstack hypervisor list( os-compute03.maas , por exemplo, no meu caso):

$ openstack compute service list --service nova-compute
+--------------------------------------+--------------+-------------------+------+----------+-------+----------------------------+
| ID                                   | Binary       | Host              | Zone | Status   | State | Updated At                 |
+--------------------------------------+--------------+-------------------+------+----------+-------+----------------------------+
| d1fadd40-6035-4f76-b8c1-5b981d003832 | nova-compute | os-compute08.maas | nova | disabled | down  | 2024-09-25T14:02:55.000000 |
| 7e02a0bd-0e53-45bc-9680-99a33d98c05b | nova-compute | os-compute04.maas | nova | enabled  | up    | 2024-10-18T11:43:12.000000 |
| 7f47d65e-b041-44dc-927e-085effdf0ec9 | nova-compute | os-compute09.maas | nova | enabled  | up    | 2024-10-18T11:43:07.000000 |
| 3a7527b3-3664-4ae1-ac90-ac04e835ee5b | nova-compute | os-compute03.maas | nova | enabled  | up    | 2024-10-18T11:43:13.000000 |
+--------------------------------------+--------------+-------------------+------+----------+-------+----------------------------+

$ openstack hypervisor list
+----+---------------------+-----------------+----------+-------+
| ID | Hypervisor Hostname | Hypervisor Type | Host IP  | State |
+----+---------------------+-----------------+----------+-------+
|  1 | os-compute08.maas   | QEMU            | 10.0.1.8 | down  |
|  2 | os-compute04.maas   | QEMU            | 10.0.1.4 | up    |
|  3 | os-compute09.maas   | QEMU            | 10.0.1.9 | up    |
+----+---------------------+-----------------+----------+-------+

^ não os-compute03.maas

$ sudo nova-manage cell_v2 list_hosts
                                                                                                                                     
Modules with known eventlet monkey patching issues were imported prior to eventlet monkey patching: urllib3. This warning can usually be ignored if the caller is only importing and not executing nova code.
Deprecated: Option "logdir" from group "DEFAULT" is deprecated. Use option "log-dir" from group "DEFAULT".
+-----------+--------------------------------------+-------------------+
| Cell Name |              Cell UUID               |      Hostname     |
+-----------+--------------------------------------+-------------------+
|   cell1   | d3dfd353-b4ee-4293-b362-1e0175ebe337 | os-compute04.maas |
|   cell1   | d3dfd353-b4ee-4293-b362-1e0175ebe337 | os-compute08.maas |
|   cell1   | d3dfd353-b4ee-4293-b362-1e0175ebe337 | os-compute09.maas |
+-----------+--------------------------------------+-------------------+

$ sudo nova-manage cell_v2 discover_hosts --verbose
Modules with known eventlet monkey patching issues were imported prior to eventlet monkey patching: urllib3. This warning can usually be ignored if the caller is only importing and not executing nova code.
Deprecated: Option "logdir" from group "DEFAULT" is deprecated. Use option "log-dir" from group "DEFAULT".
Found 2 cell mappings.
Skipping cell0 since it does not contain hosts.
Getting computes from cell 'cell1': d3dfd353-b4ee-4293-b362-1e0175ebe337
Found 0 unmapped computes in cell: d3dfd353-b4ee-4293-b362-1e0175ebe337

Tentei igualmente reiniciar o controlador nova:

$ sudo systemctl restart nova-scheduler
$ sudo systemctl restart nova-conductor

Ao reiniciar o controlador nova, os logs dizem o seguinte:

2024-10-18 11:53:44.939 630048 INFO nova.scheduler.host_manager [None req-eb8c8117-136c-4a13-ac57-d32d4099388a - - - - - -] Received a sync request from an unknown host 'os-compute09.maas'. Re-created its InstanceList.
2024-10-18 11:53:44.939 630046 INFO nova.scheduler.host_manager [None req-eb8c8117-136c-4a13-ac57-d32d4099388a - - - - - -] Received a sync request from an unknown host 'os-compute09.maas'. Re-created its InstanceList.
2024-10-18 11:53:44.940 630045 INFO nova.scheduler.host_manager [None req-eb8c8117-136c-4a13-ac57-d32d4099388a - - - - - -] Received a sync request from an unknown host 'os-compute09.maas'. Re-created its InstanceList.
2024-10-18 11:53:44.968 630047 INFO nova.scheduler.host_manager [None req-eb8c8117-136c-4a13-ac57-d32d4099388a - - - - - -] Received a sync request from an unknown host 'os-compute09.maas'. Re-created its InstanceList.
2024-10-18 11:54:02.539 630048 INFO nova.scheduler.host_manager [None req-ad410200-f99f-4dc7-896d-637dd9620568 - - - - - -] Received a sync request from an unknown host 'os-compute04.maas'. Re-created its InstanceList.
2024-10-18 11:54:02.541 630047 INFO nova.scheduler.host_manager [None req-ad410200-f99f-4dc7-896d-637dd9620568 - - - - - -] Received a sync request from an unknown host 'os-compute04.maas'. Re-created its InstanceList.
2024-10-18 11:54:02.542 630046 INFO nova.scheduler.host_manager [None req-ad410200-f99f-4dc7-896d-637dd9620568 - - - - - -] Received a sync request from an unknown host 'os-compute04.maas'. Re-created its InstanceList.
2024-10-18 11:54:02.543 630045 INFO nova.scheduler.host_manager [None req-ad410200-f99f-4dc7-896d-637dd9620568 - - - - - -] Received a sync request from an unknown host 'os-compute04.maas'. Re-created its InstanceList.
2024-10-18 11:55:06.432 630048 INFO nova.scheduler.host_manager [None req-53ac9845-afb5-48ec-b24f-344d2afcfc3f - - - - - -] Host mapping not found for host os-compute03.maas. Not tracking instance info for this host.
2024-10-18 11:55:06.432 630048 INFO nova.scheduler.host_manager [None req-53ac9845-afb5-48ec-b24f-344d2afcfc3f - - - - - -] Received a sync request from an unknown host 'os-compute03.maas'. Re-created its InstanceList.
2024-10-18 11:55:06.435 630047 INFO nova.scheduler.host_manager [None req-53ac9845-afb5-48ec-b24f-344d2afcfc3f - - - - - -] Host mapping not found for host os-compute03.maas. Not tracking instance info for this host.
2024-10-18 11:55:06.435 630046 INFO nova.scheduler.host_manager [None req-53ac9845-afb5-48ec-b24f-344d2afcfc3f - - - - - -] Host mapping not found for host os-compute03.maas. Not tracking instance info for this host.
2024-10-18 11:55:06.436 630045 INFO nova.scheduler.host_manager [None req-53ac9845-afb5-48ec-b24f-344d2afcfc3f - - - - - -] Host mapping not found for host os-compute03.maas. Not tracking instance info for this host.
2024-10-18 11:55:06.436 630047 INFO nova.scheduler.host_manager [None req-53ac9845-afb5-48ec-b24f-344d2afcfc3f - - - - - -] Received a sync request from an unknown host 'os-compute03.maas'. Re-created its InstanceList.
2024-10-18 11:55:06.437 630045 INFO nova.scheduler.host_manager [None req-53ac9845-afb5-48ec-b24f-344d2afcfc3f - - - - - -] Received a sync request from an unknown host 'os-compute03.maas'. Re-created its InstanceList.
2024-10-18 11:55:06.436 630046 INFO nova.scheduler.host_manager [None req-53ac9845-afb5-48ec-b24f-344d2afcfc3f - - - - - -] Received a sync request from an unknown host 'os-compute03.maas'. Re-created its InstanceList.

E particularmente: Host mapping not found for host os-compute03.maas. Not tracking instance info for this host.Acho que é quando o nó deve ser adicionado na nova cell_v2? E esse não é o caso.

Acredito que os seguintes registros no banco de dados dizem respeito aos nós de computação:

mysql> SELECT hypervisor_hostname, host_ip FROM nova.compute_nodes;
+---------------------+----------+
| hypervisor_hostname | host_ip  |
+---------------------+----------+
| os-compute08.maas   | 10.0.1.8 |
| os-compute04.maas   | 10.0.1.4 |
| os-compute09.maas   | 10.0.1.9 |
| os-compute03.maas   | 10.0.1.3 |
+---------------------+----------+
4 rows in set (0.00 sec)

os-compute03.maas não está listado na nova_api.host_mappingstabela:

SELECT * FROM nova_api.host_mappings;
+---------------------+------------+----+---------+-------------------+
| created_at          | updated_at | id | cell_id | host              |
+---------------------+------------+----+---------+-------------------+
| 2024-07-02 21:23:10 | NULL       |  1 |       2 | os-compute08.maas |
| 2024-07-02 21:23:11 | NULL       |  2 |       2 | os-compute04.maas |
| 2024-07-02 21:23:11 | NULL       |  3 |       2 | os-compute09.maas |
+---------------------+------------+----+---------+-------------------+

Não tentei adicionar o host manualmente nesta tabela. Suponho que isso deva ser feito automaticamente, mas quando? O que eu perdi?

Como podemos depurar melhor essa situação?

Contexto

Estou executando um sistema Red Hat Enterprise Linux versão 8.5 em uma VM em um VMWare ESXI.

Eu precisava de mais espaço em um volume lógico preciso chamado lv_pmpnaquela VM:

$ lsblk
NAME                         MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda                            8:0    0   80G  0 disk
├─sda1                         8:1    0  600M  0 part /boot/efi
├─sda2                         8:2    0    1G  0 part /boot
└─sda3                         8:3    0 78,4G  0 part
  ├─VGslash-lv_root          253:0    0 19,5G  0 lvm  /
  ├─VGslash-lv_swap          253:1    0    4G  0 lvm  [SWAP]
  ├─VGslash-lv_usr           253:2    0    8G  0 lvm  /usr
  ├─VGslash-lv_srv           253:3    0    2G  0 lvm  /srv
  ├─VGslash-lv_home          253:4    0    2G  0 lvm  /home
  ├─VGslash-lv_opt           253:5    0    4G  0 lvm  /opt
  ├─VGslash-lv_tmp           253:6    0    4G  0 lvm  /tmp
  ├─VGslash-lv_var_log_audit 253:7    0  512M  0 lvm  /var/log/audit
  ├─VGslash-lv_var_log       253:8    0    1G  0 lvm  /var/log
  ├─VGslash-lv_vartmp        253:9    0 10,4G  0 lvm  /var/tmp
  ├─VGslash-lv_var           253:10   0    3G  0 lvm  /var
  └─VGslash-lv_pmp           253:11   0   20G  0 lvm  /pmp
sr0                           11:0    1 1024M  0 rom

Então redimensionei o disco da VM para 500G nas propriedades do VSphere que apareceram na sdaparte:

$ lsblk
NAME                         MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda                            8:0    0  500G  0 disk
├─sda1                         8:1    0  600M  0 part /boot/efi
├─sda2                         8:2    0    1G  0 part /boot
└─sda3                         8:3    0 78,4G  0 part
  ├─VGslash-lv_root          253:0    0 19,5G  0 lvm  /
  ├─VGslash-lv_swap          253:1    0    4G  0 lvm  [SWAP]
  ├─VGslash-lv_usr           253:2    0    8G  0 lvm  /usr
  ├─VGslash-lv_srv           253:3    0    2G  0 lvm  /srv
  ├─VGslash-lv_home          253:4    0    2G  0 lvm  /home
  ├─VGslash-lv_opt           253:5    0    4G  0 lvm  /opt
  ├─VGslash-lv_tmp           253:6    0    4G  0 lvm  /tmp
  ├─VGslash-lv_var_log_audit 253:7    0  512M  0 lvm  /var/log/audit
  ├─VGslash-lv_var_log       253:8    0    1G  0 lvm  /var/log
  ├─VGslash-lv_vartmp        253:9    0 10,4G  0 lvm  /var/tmp
  ├─VGslash-lv_var           253:10   0    3G  0 lvm  /var
  └─VGslash-lv_pmp           253:11   0   20G  0 lvm  /pmp
sr0                           11:0    1 1024M  0 rom

Em seguida, redimensionei o sda3volume físico para corresponder ao espaço em disco recém-adicionado com

$ resizepart /dev/sda 3 1000000000
$ pvresize /dev/sda3

$ lsblk
NAME                         MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda                            8:0    0   500G  0 disk
├─sda1                         8:1    0   600M  0 part /boot/efi
├─sda2                         8:2    0     1G  0 part /boot
└─sda3                         8:3    0 476,9G  0 part
  ├─VGslash-lv_root          253:0    0  19,5G  0 lvm  /
  ├─VGslash-lv_swap          253:1    0     4G  0 lvm  [SWAP]
  ├─VGslash-lv_usr           253:2    0     8G  0 lvm  /usr
  ├─VGslash-lv_srv           253:3    0     2G  0 lvm  /srv
  ├─VGslash-lv_home          253:4    0     2G  0 lvm  /home
  ├─VGslash-lv_opt           253:5    0     4G  0 lvm  /opt
  ├─VGslash-lv_tmp           253:6    0     4G  0 lvm  /tmp
  ├─VGslash-lv_var_log_audit 253:7    0   512M  0 lvm  /var/log/audit
  ├─VGslash-lv_var_log       253:8    0     1G  0 lvm  /var/log
  ├─VGslash-lv_vartmp        253:9    0  10,4G  0 lvm  /var/tmp
  ├─VGslash-lv_var           253:10   0     3G  0 lvm  /var
  └─VGslash-lv_pmp           253:11   0    20G  0 lvm  /pmp
sr0                           11:0    1  1024M  0 rom

Aumentei o lv_pmptamanho do volume lógico:

$ lvextend /dev/mapper/VGslash-lv_pmp -l+100%FREE

E atualizou o sistema de arquivos para que ele detectasse o novo tamanho:

$ xfs_growfs /dev/mapper/VGslash-lv_pmp

Até agora tudo bem, obtive o tamanho que esperava no lv_pmpvolume lógico:

$ lsblk
NAME                         MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda                            8:0    0   500G  0 disk
├─sda1                         8:1    0   600M  0 part /boot/efi
├─sda2                         8:2    0     1G  0 part /boot
└─sda3                         8:3    0 476,9G  0 part
  ├─VGslash-lv_root          253:0    0  19,5G  0 lvm  /
  ├─VGslash-lv_swap          253:1    0     4G  0 lvm  [SWAP]
  ├─VGslash-lv_usr           253:2    0     8G  0 lvm  /usr
  ├─VGslash-lv_srv           253:3    0     2G  0 lvm  /srv
  ├─VGslash-lv_home          253:4    0     2G  0 lvm  /home
  ├─VGslash-lv_opt           253:5    0     4G  0 lvm  /opt
  ├─VGslash-lv_tmp           253:6    0     4G  0 lvm  /tmp
  ├─VGslash-lv_var_log_audit 253:7    0   512M  0 lvm  /var/log/audit
  ├─VGslash-lv_var_log       253:8    0     1G  0 lvm  /var/log
  ├─VGslash-lv_vartmp        253:9    0  10,4G  0 lvm  /var/tmp
  ├─VGslash-lv_var           253:10   0     3G  0 lvm  /var
  └─VGslash-lv_pmp           253:11   0 418,4G  0 lvm  /pmp
sr0                           11:0    1  1024M  0 rom    

Problema

O problema surge assim que reinicio o sistema: ele parece perder as alterações de tamanho que fiz no sda3volume físico, o que consequentemente impede que o lv_pmpvolume lógico seja montado (pois ele assume que não há espaço suficiente no PV pai):

$ lsblk
NAME                         MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda                            8:0    0   500G  0 disk
├─sda1                         8:1    0   600M  0 part /boot/efi
├─sda2                         8:2    0     1G  0 part /boot
└─sda3                         8:3    0  76,9G  0 part
  ├─VGslash-lv_root          253:0    0  19,5G  0 lvm  /
  ├─VGslash-lv_swap          253:1    0     4G  0 lvm  [SWAP]
  ├─VGslash-lv_usr           253:2    0     8G  0 lvm  /usr
  ├─VGslash-lv_srv           253:3    0     2G  0 lvm  /srv
  ├─VGslash-lv_home          253:4    0     2G  0 lvm  /home
  ├─VGslash-lv_opt           253:5    0     4G  0 lvm  /opt
  ├─VGslash-lv_tmp           253:6    0     4G  0 lvm  /tmp
  ├─VGslash-lv_var_log_audit 253:7    0   512M  0 lvm  /var/log/audit
  ├─VGslash-lv_var_log       253:8    0     1G  0 lvm  /var/log
  ├─VGslash-lv_vartmp        253:9    0  10,4G  0 lvm  /var/tmp
  └─VGslash-lv_var           253:10   0     3G  0 lvm  /var
sr0                           11:0    1  1024M  0 rom 

Solução alternativa

É possível colocá-lo de volta em forma executando os seguintes comandos manualmente após a reinicialização:

### Re-apply physical volume changes
$ resizepart /dev/sda 3 1000000000
$ pvresize /dev/sda3
### Re-scan logical volumes
$ vgscan --mknodes -v
$ vgchange -a y

Pergunta

Por que isso está acontecendo? E o que posso fazer para evitar isso?

Não sei se isso está relacionado ao próprio sistema operacional, ao ambiente da VM ou a algum outro fator que não controlo. Qualquer conselho a esse respeito também ajudaria.

A solução alternativa acima não é realmente satisfatória, mesmo que eu pudesse colocá-la em um script na inicialização, ter que executar essa ação a cada inicialização não parece certo: não faz sentido para mim que uma alteração no tamanho do volume não persista após uma reinicialização.

Preciso me livrar de squirrelmail/uma parte do caminho que o usuário vê.

Meu .conf:

location / {
    rewrite /squirrelmail/(.*) /$1 last;
    proxy_pass https://internal.domain.tld:8081/squirrelmail/;

    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Host $host:$server_port;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Forwarded-Server $host;
    proxy_set_header X-Real-IP $remote_addr;
}

Espero que meu aplicativo esteja disponível para usuários no caminho raiz /, em vez de adicioná-lo constantemente squirrelmail/ao caminho do usuário final.

Então, quando o usuário vai até https://mail.domain.tldele, o proxy passa corretamente o aplicativo real localizado https://internal.domain.tld:8081/squirrelmail/sem adicionar squirrelmail/ao caminho do usuário (por exemplo https://mail.domain.tld/squirrelmail/)

ATUALIZAÇÃO:

Sem reescrever, depois que o usuário acessa, https://mail.domain.tldele adiciona squirrelmail/parte às seguintes solicitações (como navegar para outra aba, abrir e-mail e etc.) por aplicativo, então para o usuário agora parece assim, https://mail.domain.tld/squirrelmail/?some=paramsmas para o aplicativo agora é https://internal.domain.tld:8081/squirrelmail/squirrelmail/?some=paramso que causa HTTP 404.

Tenho usado a abordageminternal-sftp de subsistema desde 2021 sem problemas para permitir SFTP, mas não permitir SSH.

O código do meu arquivo ssh_config é:

ForceCommand internal-sftp
Subsystem  sftp   sftp-server.exe -d \%
ChrootDirectory \%

PermitTunnel no
AllowAgentForwarding no
AllowTcpForwarding no
X11Forwarding no
AllowUsers sftpuser

Assim como outros , no fim de semana após as atualizações do Windows de outubro de 2024, não consegui me conectar ao servidor via SSH.

No servidor, o servidor SSH OpenSSH não inicia e recebo um erro 1067.

Conforme recomendado, quando excluo a pasta \ssh, o serviço agora pode ser reiniciado com sucesso, mas a nova pasta ssh criada automaticamente tem o código de arquivo ssh_config padrão:

Match Group administrators
       AuthorizedKeysFile __PROGRAMDATA__/ssh/administrators_authorized_keys

Quando substituo esse código pelo internal-sftpcódigo acima, recebo novamente o erro 1067.

Querendo saber o que torna esse código incompatível com as novas atualizações.