All perguntas(server)

Configurei um vhost para um domínio na porta 80:

<VirtualHost *:80>
    ServerAdmin webmaster@localhost
    ServerName thesolentmetropolitan.com
    DocumentRoot /var/www/10/thesolentmetropolitan.com/deployment_environments/live/docroot
    ErrorLog ${APACHE_LOG_DIR}/error.log
    CustomLog ${APACHE_LOG_DIR}/access.log combined

    <Directory "/var/www/thesolentmetropolitan.com/docroot">
        Options Indexes FollowSymLinks MultiViews
        AllowOverride All
    </Directory>
</VirtualHost>

A visita ao site resulta em:

Pedido ruim

Seu navegador enviou uma solicitação que este servidor não conseguiu entender. Motivo: Você está falando HTTP simples para uma porta de servidor com SSL habilitado. Em vez disso, use o esquema HTTPS para acessar esta URL, por favor. Servidor Apache/2.4.58 (Ubuntu) em 127.0.1.1 Porta 80

Desabilitei todas as outras permutações de vhost https http, www e sem www.

Verifiquei o seguinte (não tenho certeza do que fazer com o seguinte):

sudo lsof -i -n | grep https
apache2   520640            root    6u  IPv6 4829014      0t0  TCP *:https (LISTEN)
apache2   520645        www-data    6u  IPv6 4829014      0t0  TCP *:https (LISTEN)
apache2   520662        www-data    6u  IPv6 4829014      0t0  TCP *:https (LISTEN)
apache2   520705        www-data    6u  IPv6 4829014      0t0  TCP *:https (LISTEN)
apache2   520706        www-data    6u  IPv6 4829014      0t0  TCP *:https (LISTEN)
apache2   520707        www-data    6u  IPv6 4829014      0t0  TCP *:https (LISTEN)
apache2   520708        www-data    6u  IPv6 4829014      0t0  TCP *:https (LISTEN)
apache2   520741        www-data    6u  IPv6 4829014      0t0  TCP *:https (LISTEN)
apache2   520743        www-data    6u  IPv6 4829014      0t0  TCP *:https (LISTEN)
apache2   520981        www-data    6u  IPv6 4829014      0t0  TCP *:https (LISTEN)
apache2   520982        www-data    6u  IPv6 4829014      0t0  TCP *:https (LISTEN)

e verifiquei outros vhosts.

root@server03:/etc/apache2/sites-available# apachectl -S
AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.1.1. Set the 'ServerName' directive globally to suppress this message
VirtualHost configuration:
*:443                  is a NameVirtualHost
         default server drupalsolent.dev (/etc/apache2/sites-enabled/drupalsolent.dev-le-ssl.conf:2)
         port 443 namevhost drupalsolent.dev (/etc/apache2/sites-enabled/drupalsolent.dev-le-ssl.conf:2)
         port 443 namevhost www.drupalsolent.dev (/etc/apache2/sites-enabled/drupalsolent.dev-le-ssl.conf:21)
         port 443 namevhost eval1.labs.drupalsolent.dev (/etc/apache2/sites-enabled/eval1.labs.drupalsolent.dev-le-ssl.conf:2)
         port 443 namevhost internationalgospelchoir.uk (/etc/apache2/sites-enabled/internationalgospelchoir.uk-le-ssl.conf:2)
         port 443 namevhost staging.internationalgospelchoir.uk (/etc/apache2/sites-enabled/staging.internationalgospelchoir.uk-le-ssl.conf:2)
         port 443 namevhost www.internationalgospelchoir.uk (/etc/apache2/sites-enabled/www.internationalgospelchoir.uk-le-ssl.conf:2)
*:80                   is a NameVirtualHost
         default server drupalsolent.dev (/etc/apache2/sites-enabled/drupalsolent.dev.conf:1)
         port 80 namevhost drupalsolent.dev (/etc/apache2/sites-enabled/drupalsolent.dev.conf:1)
         port 80 namevhost eval1.labs.drupalsolent.dev (/etc/apache2/sites-enabled/eval1.labs.drupalsolent.dev.conf:1)
         port 80 namevhost internationalgospelchoir.uk (/etc/apache2/sites-enabled/internationalgospelchoir.uk.conf:1)
         port 80 namevhost staging.internationalgospelchoir.uk (/etc/apache2/sites-enabled/staging.internationalgospelchoir.uk.conf:1)
         port 80 namevhost thesolentmetropolitan.com (/etc/apache2/sites-enabled/thesolentmetropolitan.com.conf:1)
         port 80 namevhost www.drupalsolent.dev (/etc/apache2/sites-enabled/www.drupalsolent.dev.conf:1)
         port 80 namevhost www.internationalgospelchoir.uk (/etc/apache2/sites-enabled/www.internationalgospelchoir.uk.conf:1)
ServerRoot: "/etc/apache2"
Main DocumentRoot: "/var/www/html"
Main ErrorLog: "/var/log/apache2/error.log"
Mutex mpm-accept: using_defaults
Mutex watchdog-callback: using_defaults
Mutex rewrite-map: using_defaults
Mutex ssl-stapling-refresh: using_defaults
Mutex ssl-stapling: using_defaults
Mutex ssl-cache: using_defaults
Mutex default: dir="/var/run/apache2/" mechanism=default
PidFile: "/var/run/apache2/apache2.pid"
Define: DUMP_VHOSTS
Define: DUMP_RUN_CFG
User: name="www-data" id=33
Group: name="www-data" id=33
root@server03:/etc/apache2/sites-available#

outras informações para análise:

root@server03:/etc/apache2/sites-available# cat drupalsolent.dev.conf
<VirtualHost *:80>
  ServerName drupalsolent.dev
  RedirectPermanent / https://drupalsolent.dev/
</VirtualHost>

Tentei o domínio em diferentes redes: fixa e móvel, o mesmo erro, então acho que deve ser algo no servidor.

O que poderia ser?

Preciso resolver esse problema porque me conecto na porta 80 para que o LetsEncrypt forneça um certificado https.

Obrigado pela ajuda.

Eu dei uma olhada em Servir a porta 443 por http cria o erro 400 Bad Request em vez de redirecionar, que tem algumas semelhanças, mas não é bem o que estou procurando.

Tenho um Synology NAS com acesso WAN usando um proxy reverso Nginx. Como o subdomínio cloud.domain.comé roteado para o Synology, todo o caminho de subpastas é gerenciado pelo aplicativo Synology.

captura de tela da interface do Synology onde /filesé atribuído

Para acessar o Gerenciador de Arquivos, eu usaria o seguinte URL:

https://cloud.example.org/files

Tenho uma pasta compartilhada no Gerenciador de Arquivos que usa um link estilo tinyURL para acesso direto. Gostaria de criar um redirecionamento que apontasse diretamente para essa pasta compartilhada com uma URL personalizada, como a seguinte:

https://cloud.example.org/public_downloads

Em outras palavras, preciso usar https://cloud.example.org/public_downloadspara acessar https://tiny.url/abcd123. Existe uma maneira de substituir um caminho de subpasta específico sem quebrar os gerenciados pela Synology como /files?

Eu revisei uma pergunta semelhante nginx Redirect subdomain and path específico , mas depois de olhar a documentação vinculada , não estou vendo como posso configurá-lo para o /pathing em vez do subdomínio. Suspeito que a chave esteja na manipulação da locationseção da configuração do Nginx para meu cloud.example.orgservidor.

Minha configuração Nginx para o Synology

## CLOUD HTTPS ##
server {
        listen [::]:443 ssl http2;
        listen 443 ssl http2;
        server_name cloud.domain.com;

                ssl_session_timeout 30m;
                ssl_protocols TLSv1.2 TLSv1.1 TLSv1;
                ssl_certificate      /usr/share/nginx/ssl/example.org-chain.pem;
                ssl_certificate_key  /usr/share/nginx/ssl/example.org-key.pem;
                ssl_session_cache shared:SSL:10m;

                        add_header X-Xss-Protection "1; mode=block" always;
                        add_header X-Content-Type-Options "nosniff" always;
                        add_header Strict-Transport-Security "max-age=2592000; includeSubdomains" always;
                        add_header X-Frame-Options "SAMEORIGIN" always;
                        proxy_hide_header X-Powered-By;
                        add_header 'Referrer-Policy' 'no-referrer';
                        add_header Content-Security-Policy "frame-ancestors example.org app.example.org;";

                location / {
                proxy_pass http://10.1.2.3:5000;
                proxy_set_header Host $host;
                proxy_set_header X-Forwarded-Host $server_name;
                proxy_set_header X-Real-IP $remote_addr;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_set_header X-Forwarded-Ssl on;
                proxy_set_header X-Forwarded-Proto $scheme;
                proxy_read_timeout  90;
                proxy_redirect http://synologyhostname:5000 https://$host/:5001;
        }
}
## END CLOUD HTTPS ##

Contexto

Tenho um script powershell que executa alguma configuração para um aplicativo em um ambiente de teste. Entre outras coisas, o script chama sqlcmdvárias vezes.

Alguns dias atrás, realizei uma restauração no banco de dados. Usei o SQL Server Management Studio 20.2 para restaurar um arquivo BAK para uma instância local do Microsoft SQL Server 2022 (todas as informações da versão abaixo). Fiz isso usando o assistente SSMS Restore Database com WITH REPLACE, WITH_RESTRICTED_USERe fechando as conexões existentes com o banco de dados.

Então, tentei executar meu script de configuração contra esse banco de dados recém-restaurado, como já fiz com sucesso centenas de vezes antes. O script começa garantindo que o sqlcmd esteja instalado e atualizado:

winget install sqlcmd

Em seguida, ele executa comandos no seguinte formato, onde $Server é .\sqlexpresse $Database pode variar (portanto, não parece ser um problema específico do banco de dados):

sqlcmd -S $Server -d $Database -E -Q "ALTER DATABASE..."

Não especifico se devo usar TCP ou pipes nomeados - apenas deixo usar o padrão.

Problema

Normalmente, cada sqlcmd termina em menos de um segundo e gera algo como Commands completed successfully.ou (7653 rows affected), mas, em vez disso, após cerca de 45 segundos, recebo a seguinte saída para cada comando (NB: a mesma linha é repetida duas vezes para uma única invocação do comando):

Timed out waiting for pipe '\\.\pipe\SQLLocal\sqlexpress' to come available
Timed out waiting for pipe '\\.\pipe\SQLLocal\sqlexpress' to come available

O que eu tentei

Além das verificações óbvias (instância do servidor SQL em execução, detalhes de conexão corretos, etc.), tentei:

• Restaurar o banco de dados novamente e fechar novamente todas as conexões existentes para garantir que pelo menos 1 conexão esteja disponível
• Reiniciando a instância do servidor SQL
• Reiniciando a máquina inteira

Tentei executar cada consulta SQL "manualmente" no SSMS, e nenhuma delas relatou erros e observou-se que tiveram o efeito desejado. No entanto, esse processo demora muito, sendo necessário copiar cada consulta e substituir nas variáveis, retornando ao PowerShell de vez em quando para executar comandos não SQL.

Questões)

O que aconteceu para causar o tempo limite do sqlcmd e o que posso alterar para garantir que ele possa ser executado como deveria/costumava ser?

Informações da versão

Informações sobre a versão do SSMS:

SQL Server Management Studio                        20.2.30.0
SQL Server Management Objects (SMO)                     17.100.40.0+f57178c95d4376485d3f597f2b829bbd6f80fd6f
Microsoft T-SQL Parser                      17.2.3.1+46115224c373754fdd41516eaae1386cabc4819e.46115224c373754fdd41516eaae1386cabc4819e
Microsoft Analysis Services Client Tools                        20.0.3.0
Microsoft Data SqlClient (MDS)                      5.1.5
Microsoft SQL Server Data-Tier Application Framework (DacFX)                        162.3.566.1+89d89fe935702c8836ebaf6a03cf61b85118f847.89d89fe935702c8836ebaf6a03cf61b85118f847
Microsoft .NET Framework                        4.0.30319.42000
Operating System                        10.0.22631

Servidor SQL ( SELECT @@VERSION):

Microsoft SQL Server 2022 (RTM-GDR) (KB5046861) - 16.0.1135.2 (X64)   Oct 18 2024 15:31:58   Copyright (C) 2022 Microsoft Corporation  Express Edition (64-bit) on Windows 10 Enterprise 10.0 <X64> (Build 22631: ) (Hypervisor) 

Extrair do Windows systeminfo:

OS Name:                   Microsoft Windows 11 Enterprise
OS Version:                10.0.22631 N/A Build 22631
OS Manufacturer:           Microsoft Corporation
OS Configuration:          Standalone Workstation
OS Build Type:             Multiprocessor Free

Tenho vários grupos de recursos e instâncias na minha conta do Azure. No entanto, a Interface de Linha de Comando (CLI) do Azure não lista nenhum grupo nem recurso na minha conta do Azure:

franck [ ~ ]$ az group list
[]
franck [ ~ ]$ az resource list
[]

Por que o Azure CLI não lista nenhum grupo nem recurso na minha conta do Azure?

Configurei o Nginx Proxy Manager no meu servidor e configurei um proxy reverso para meu domínio com SSL (Let's Encrypt). Tudo funciona bem e posso acessar meu serviço web através do meu domínio com segurança via HTTPS, mas tenho um problema: qualquer um pode acessar meu serviço via http://IP:PORT, que eu quero bloquear completamente.

Quero restringir o acesso ao meu servidor para que ele só possa ser acessado por meio de https://DOMÍNIO e não pelo endereço IP público do servidor.

Já tentei as seguintes coisas:

• Redirecionando HTTP para HTTPS e restringindo o acesso somente ao domínio. -> não é possível escrever o endereço IP no campo de domínio no NPM
• Usando código Nginx personalizado para bloquear completamente o acesso IP direto. -> então o host proxy obtém o status 'offline'
• habilitar HSTS -> ainda permite acesso por IP

Alguém já enfrentou um problema semelhante ou pode sugerir a melhor maneira de configurar isso no Nginx Proxy Manager? Eu realmente apreciaria qualquer tipo de ajuda ou sugestão.

Desde já, obrigado!

Implantei uma API C# em um cluster Kubernetes

Pelo que entendi, deveríamos ter: GET http request -> Node(30000) -> Pod(80) -> C# API(8080)

Minha imagem docker expõe a porta 8080

FROM our-registry/dotnet/sdk:8.0 AS build
WORKDIR /app

# Copy the project file and restore any dependencies (use .csproj for the project name)
COPY MyApi/MyApi/*.csproj ./
RUN dotnet restore

# Copy the rest of the application code
COPY MyApi/MyApi/. ./

# Publish the application
ARG BUILD_CONFIG=Release
RUN echo "Building with configuration: ${BUILD_CONFIG}"
RUN dotnet publish -c ${BUILD_CONFIG} -o out

# Build the runtime image
FROM our-registry/dotnet/aspnet:8.0 AS runtime
WORKDIR /app
COPY --from=build /app/out ./

# Expose the port your application will run on
EXPOSE 8080

# Start the application
ENTRYPOINT ["dotnet", "MyApi.dll"]

Meu K8 api-service.yaml está definido assim

apiVersion: v1
kind: Service
metadata:
  name: my-api-service
  namespace: somenamespace
spec:
  selector:
    app: my-api
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080
      nodePort: 30000
  type: NodePort 

Minhas configurações de inicialização da API C# configuram a porta 8080 e funcionam bem localmente em depuração/lançamento nessa porta

{
  "profiles": {
    "http": {
      "commandName": "Project",
      "launchBrowser": true,
      "launchUrl": "swagger",
        "environmentVariables": {
            ...
        },
      "dotnetRunMessages": true,
      "applicationUrl": "http://localhost:8080"
    },
    "https": {
      "commandName": "Project",
      "launchBrowser": true,
      "launchUrl": "swagger",
        "environmentVariables": {
            ...
        },
      "dotnetRunMessages": true,
      "applicationUrl": "https://localhost:7084;http://localhost:8080"
    },
    ...

No cluster, o serviço é executado

kubectl get svc -n somenamespace

NAME                  TYPE       CLUSTER-IP      EXTERNAL-IP   PORT(S)        AGE
my-api-service        NodePort   10.*.*.*   <none>        80:30000/TCP   3h56m

Naquele casulo

kubectl get pods -n somenamespace -o wide
NAME                           READY   STATUS    RESTARTS   AGE    IP             NODE                                          NOMINATED NODE   READINESS GATES
my-apipod-*********-*****   1/1     Running   0          138m   10.*.*.*   somenode   <none>           <none>

Eu verifiquei localmente dentro do pod

kubectl exec -it my-apipod-*********-***** -n somenamespace -- bash
...
root@my-apipod-*********-*****:/app# netstat -tulnp | grep LISTEN
tcp        0      0 0.0.0.0:8080            0.0.0.0:*               LISTEN      1/dotnet    

Obtendo o nó

kubectl get nodes -o wide
NAME                                          STATUS   ROLES                       AGE    VERSION           INTERNAL-IP      EXTERNAL-IP      OS-IMAGE                         KERNEL-VERSION      CONTAINER-RUNTIME
somenode   Ready    worker                      108d   v1.28.11+rke2r1   192.168.1.23   192.168.1.23  Ubuntu 20.04.6 LTS               5.4.0-200-generic   containerd://1.7.17-k3s1

Tento conectar no ip desse nó com o nodePort 30000

curl -X GET http://192.168.1.23:30000/swagger/index.html -v
Note: Unnecessary use of -X or --request, GET is already inferred.
*   Trying 192.168.1.23:30000...
* Connected to 192.168.1.23 (192.168.1.23) port 30000 (#0)
> GET /swagger/index.html HTTP/1.1
> Host: 192.168.1.23:30000
> User-Agent: curl/7.81.0
> Accept: */*
> 
* Recv failure: Connection reset by peer
* Closing connection 0
curl: (56) Recv failure: Connection reset by peer

Não tenho certeza do que mais verificar. Executei meu código de API (.NET) localmente e o swagger está funcionando e acessível.

Obrigado pela ajuda

[editar]

Conforme faço solicitações como essas no navegador:

http://192.168.1.23:30000
http://192.168.1.23:30000/swagger/index.html

Nada aparece no log

kubectl logs -f -n mynamespace my-apipod-*********-*****
warn: Microsoft.AspNetCore.Hosting.Diagnostics[15]
      Overriding HTTP_PORTS '8080' and HTTPS_PORTS ''. Binding to values defined by URLS instead 'http://0.0.0.0:8080'.
info: Microsoft.Hosting.Lifetime[14]
      Now listening on: http://0.0.0.0:8080
info: Microsoft.Hosting.Lifetime[0]
      Application started. Press Ctrl+C to shut down.
info: Microsoft.Hosting.Lifetime[0]
      Hosting environment: Production
info: Microsoft.Hosting.Lifetime[0]
      Content root path: /app

Isso aparece se eu tentar https

warn: Microsoft.AspNetCore.HttpsPolicy.HttpsRedirectionMiddleware[3]
      Failed to determine the https port for redirect.

Então a API parece funcionar bem

Recentemente, fui encarregado de gerenciar alguns servidores e um deles está se mostrando particularmente difícil. Sou relativamente novo no gerenciamento de servidores no Hyper-V e, portanto, tenho cuidado para não bagunçar nada. Tenho uma VM Hyper-V e aqui estão as propriedades

Quando acesso a pasta Discos Rígidos Virtuais, vejo isto:

Meu maior problema é que o disco do host está cheio, então a VM é pausada com o aviso "Disco sem espaço", mas dentro da VM consigo ver que há bastante espaço, como abaixo:

Meu pensamento era, eu pego um pouco de espaço do disco rígido da VM e o devolvo ao Host. Mas a VM tem pontos de verificação e quando eu acesso a aba Pontos de Verificação para tentar excluí-los, ela me diz que não pode por causa de vários pontos de verificação.

Por favor, ajude-me a descobrir como abordar isso e, ao mesmo tempo, esclarecer um pouco mais o assunto.

Fundo

Eu herdei um grupo de servidores Windows Server 2019 recentemente. A configuração não é... ideal. Eles são todos parte de um grupo de trabalho, myworkgroup, mas não há domínio envolvido. Cada um tem sua própria conta de administrador local, theadmin. Todas as theadmincontas locais têm a mesma senha. Um servidor tem uma pasta compartilhada habilitada.

O layout geral se parece com:

• ServidorA
  • Compartilhamento de arquivo: C:\Shared(nome: "Compartilhado")
  • Administrador local: ServerA\theadmin(mesma senha, por exemplo redactedpw1234)
• ServidorB
  • Administrador local: ServerB\theadmin(mesma senha, por exemplo redactedpw1234)
• Servidor C
  • Administrador local: ServerC\theadmin(mesma senha, por exemplo redactedpw1234)
• ServidorQA
  • Administrador local: ServerQA\theadmin(mesma senha, por exemplo redactedpw1234)

O desafio

Em algum momento — difícil precisar exatamente quando — a theadminconta ServerQA agora consegue ler \\ServerA\Shared, mas não consegue modificar ou excluir arquivos (observei um problema com uma tarefa agendada em execução nessa conta e depois verifiquei pelo Windows Explorer enquanto estava conectado com essa conta).

As contas do ServerB e do ServerC theadminnão parecem ter esse problema. Quando conectado na theadminconta local nessas duas máquinas, posso olhar \\ServerA\Sharede modificar/criar/excluir arquivos conforme o esperado.

Então meu desafio pode ser resumido como:

• ✅ ServerB, ServerC, e ServerQAparecem ter a mesma configuração
• ✅ ServerBpode acessar \\ServerA\Shareno Windows Explorer e criar/modificar arquivos
• ✅ ServerCpode acessar \\ServerA\Shareno Windows Explorer e criar/modificar arquivos
• ❌ ServerQAconsegue ler \\ServerA\Shareno Windows Explorer, mas recebe um erro de permissão ao tentar criar ou modificar arquivos.

Coisas que eu tentei

• Reiniciando o ServerQAservidor
• Get-SmbConnectionem todos os servidores.
  • O padrão de configuração parece ser o mesmo no ServerB, ServerC e ServerQA - O usuário é listado como [TheMachine]\theadminem cada caso, e a credencial é a mesma. Então, todos eles estão usando suas theadmincredenciais locais.
  • O dialeto é 3.1.1para todas as máquinas.
• Get-SmbMultichannelConnectionparece mostrar o mesmo padrão para todos eles.
  • Interface index [The Ethernet1 index for the server], RSS: True, RDMA: False
• Tentou remover e restabelecer o compartilhamento
  • No ServerQA,net use /delete \\ServerA\Shared
  • No ServerA Get-SmbSessione, em seguida, Close-SmbSessionpara fechar todas as sessões dessa máquina
  • No ServerQA, net use \\ServerA\Shared /user:ServerQA\theadmin redactedpw1234para restabelecer
  • No ServerQA, net usee Get-SmbConnectionpara confirmar que as coisas estão configuradas conforme o esperado
• Executei whoami /allem todos os servidores e verifiquei se todas as contas locais estão nos mesmos grupos locais.
• Verifiquei os logs de eventos SMBClient e SMBServer nos respectivos servidores. Nada se destaca.
• Verifiquei o registro. Todos os servidores têm os mesmos valores emHKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters
  • Embora eu possa estar faltando em algum outro lugar que eu deveria procurar?
• Get-SmbClientConfigurationretorna o mesmo resultado exato em todos os servidores
• Instalou o módulo powershell NTFSSecurity e executou Get-NTFSEffectiveAccess -Path \\ServerA\Sharedde todos os servidores. Todos retornaram o resultado.
• Em ServerA, correu icacls "C:\Shared". Isso retornou ServerA\theadmin como tendo acesso, mas nenhuma das outras contas de administrador específicas da máquina. Então, estou assumindo que isso não é tão relevante.
• Em ServerA, correu Get-SmbShareAccess -Name "Shared". O ServerA\theadminusuário estava nos resultados, mas nenhum dos theadminusuários das outras máquinas foi mencionado especificamente.
• Continuei e comparei os resultados. Há diferenças em privilégios, mas, até onde posso perceber, eles parecem refletir SIDs locais. Mas estou menos familiarizado com isso secedit /export /cfg c:\Windows\temp\secpol.cfg.ServerBServerQA
• Em cada servidor, executei gpresult /he comparei os arquivos HTML. Até onde posso perceber, não há diferenças.
• Por uma ótima tentativa de resposta abaixo, eu verifiquei o ServerQAregistro do servidor para ver se HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\LocalAccountTokenFilterPolicyestava definido 1como deveria. Infelizmente, já está.

Pergunta

Considerando tudo isso, como posso determinar qual é a diferença entre o acesso de ServerQAvs ServerBou ServerCnesta situação? Há alguma ferramenta adicional que eu deva considerar? Há algum ponto comum de solução de problemas que estou esquecendo para determinar a diferença entre servidores? Estou perdido.

Atualização: está mais perto?

Após reiniciar ServerA(que hospeda o compartilhamento de arquivos) e ServerQA(o cliente problemático), os sintomas pareceram desaparecer por cerca de 10 minutos. Consegui modificar arquivos e ver as tarefas agendadas sendo executadas conforme o esperado e modificando arquivos. Então os sintomas retornaram sem nenhuma ação da minha parte e permaneceram assim.

Estou usando o Terraform para gerenciar uma organização do Github. Temos um módulo padrão "repositório comum" que usamos para garantir que nossos repositórios compartilhem uma configuração comum. Gostaria de adicionar suporte para configurar páginas do GitHub, o que requer suporte para o pageselemento , que se parece com isso:

  pages {
    build_type = "legacy"
    cname = "example.com"
    source {
      branch = "master"
      path   = "/docs"
    }
  }

Tudo é opcional. Em particular, sourceé necessário somente se build_type == "legacy" || build_type == null, e o bloco inteiro pagespode ser omitido. Não consegui descobrir como fazer sourcecondicional, então acabei dividindo isso em dois dynamicblocos assim:

  # There are two `dynamic "pages"` blocks here to account for the fact that `source` is only required
  # if `build_type` is "legacy". The `for_each` at the top of each block will only enable the block when
  # the necessary conditions are met.
  dynamic "pages" {

    # enable this block if `pages` is not null and `build_type` is "legacy" (or null)
    for_each = var.pages == null ? [] : var.pages.build_type == "legacy" || var.pages.build_type == null ? ["enabled"] : []

    content {
      source {
        branch = var.pages.source.branch
        path   = var.pages.source.path
      }

      cname      = var.pages.cname
      build_type = var.pages.build_type
    }
  }

  dynamic "pages" {

    # enable this block if `pages` is not null and `build_type` is "workflow"
    for_each = var.pages == null ? [] : var.pages.build_type == "workflow" ? ["enabled"] : []

    content {
      cname      = var.pages.cname
      build_type = var.pages.build_type
    }
  }

Onde eu defini a pagesvariável no módulo assim:

variable "pages" {
  description = "Configuration for github pages"
  type = object({
    source = optional(object({
      branch = string
      path   = string
    }))
    build_type = optional(string, "legacy")
    cname      = optional(string)
  })
  default = null
}

Existe uma maneira melhor de abordar isso?

recebi uma notificação da Victoria Risk [email protected]

Novas versões do BIND estão disponíveis: 9.18.35, 9.20.7, 9.21.6

depois que baixei a imagem mais recente, o bind9 não consegue iniciar devido ao seguinte novo erro:

$ docker compose up
[+] Running 2/1
 ✔ Network bind_bind  Created                                                                                                                                                                                                                                                            0.2s
 ✔ Container bind9    Created                                                                                                                                                                                                                                                            0.0s
Attaching to bind9
bind9  | named: setgid(): Operation not permitted
bind9 exited with code 1
$ 

O bind9 funcionava bem antes de extrair a nova imagem mais recente.

meu ambiente:

$ uname -a
Linux gamma 6.1.0-26-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.112-1 (2024-09-30) x86_64 GNU/Linux
$ docker --version
Docker version 27.3.1, build ce12230
$ docker compose version
Docker Compose version v2.29.7
$

meudocker-compose

$ cat docker-compose.yml
services:
  bind:
    image: internetsystemsconsortium/bind9:9.20
    container_name: bind9
    env_file: .env
    expose:
      - 80
      - 443
      - 853
    networks:
      - default
    ports:
      - 0.0.0.0:53:53/udp
      - 0.0.0.0:53:53/tcp
      - 0.0.0.0:443:443/tcp
      - 0.0.0.0:853:853/tcp
      - 127.0.0.1:953:953/tcp
    restart: always
    volumes:
      - ./etc/bind:/etc/bind
      - ./var/cache/bind:/var/cache/bind
      - ./var/lib/bind:/var/lib/bind
      - ./var/log:/var/log

networks:
  default:
    name: bind_bind
    driver: bridge

$

named.conf:

$ cat ./etc/bind/named.conf
# Use with the following in named.conf, adjusting the allow list as needed:
key "rndc-key" {
    algorithm hmac-sha256;
    secret "XYZ";
};
#
controls {
    inet 127.0.0.1 port 953
        allow { 127.0.0.1; } keys { "rndc-key"; };
};
# End of named.conf

logging {
        channel stdout {
                stderr;
                severity debug;
#                severity info;
                print-category yes;
                print-severity yes;
                print-time yes;
        };
        category security { stdout; };
        category dnssec   { stdout; };
        category default  { stdout; };
        category queries  { stdout; };
};

tls local-tls {
    key-file "/etc/bind/letsencrypt/X.Y.Z/privkey.pem";
    cert-file "/etc/bind/letsencrypt/X.Y.Z/fullchain.pem";
};

http local-http-server {
    endpoints { "/dns-query";  };
};

options {
    allow-query-cache { any; };
        allow-recursion {
        X.X.X.X/Y;
    };
        allow-transfer {
        X.X.X.X/Y;
    };
        allow-update { none; };
        directory "/var/cache/bind";
    http-port 80;
    https-port 443;
    listen-on port 53 { any; };
    listen-on port 80 tls none http local-http-server { any; };
    listen-on port 443 tls local-tls http local-http-server { any; };
    listen-on-v6 port 53 { any; };
    listen-on-v6 port 80 tls none http local-http-server { any; };
    listen-on-v6 port 443 tls local-tls http local-http-server { any; };

        max-cache-size 100M;
        max-cache-ttl 3600;
        max-ncache-ttl 3600;

        # https://kb.isc.org/docs/bind-best-practices-authoritative#6-prepare-for-abuse-of-any-externalfacing-servers
        rate-limit {
#                slip 2; // Every other response truncated
#                window 15; // Seconds to bucket
                responses-per-second 5;// # of good responses per prefix-length/sec
#                referrals-per-second 5; // referral responses
#                nodata-per-second 5; // nodata responses
#                nxdomains-per-second 5; // nxdomain responses
#                errors-per-second 5; // error responses
#                all-per-second 20; // When we drop all
#                log-only no; // Debugging mode
#                pps-scale 250; // x / 1000 * per-second
#                // = new drop limit
#                exempt-clients { 127.0.0.1; 192.153.154.0/24; 192.160.238.0/24 };
#                ipv4-prefix-length 24; // Define the IPv4 block size
#                ipv6-prefix-length 56; // Define the IPv6 block size
#                max-table-size 20000; // 40 bytes * this number = max memory
#                min-table-size 500; // pre-allocate to speed startup
        };

    version none;
};

$

por favor, avise.

infelizmente o usuário/equipe do internetsystemsconsortium não tem uma tag específica de versão de 3º nível, o que me impede de fazer o rollback: https://hub.docker.com/r/internetsystemsconsortium/bind9/tags