Na página de configurações da GUI do Kibana, há uma entrada chamada "Ocultar anúncios" com o campo denominado hideAnnouncements.
O caminho do URL para esta página é/app/management/kibana/settings
Então, na documentação do arquivo de configuração YAML, há uma entrada newsfeed.enabled.
Se newsfeed.enabledestiver definido como false, a configuração de ocultar anúncios na GUI não muda.
Existe uma kibana.ymlconfiguração que controla hideAnnouncements?
No arquivo "CAPolicy.inf" onde você define [AuthorityInformationAccess]e [CRLDistributionPoint], essas seções podem usar valores dinâmicos? Por exemplo:
[CRLDistirubtionPoint]
URL="http://pki.mycompany.tld/%3%8%9.crl"
ou
[CRLDistirubtionPoint]
URL="http://pki.mycompany.tld/<CAName><CRLNameSuffix><DeltaCRLAllowed>.crl"
Pesquisei algumas respostas, mas mesmo a Microsoft não tem muitas informações sobre isso ou sobre a configuração adequada das extensões AIA e CDP em uma PKI de duas camadas.
Obrigado!
Eu tenho um arquivo personalizado com /etc/containerd/certs.d/registry.at.my.company/hosts.tomlalgumas configurações definidas para um contêiner de registro local em execução em meus servidores. Isso está funcionando bem quando eu o configuro para um CRI para Kubernetes, mas eu e meus colegas achamos frustrante termos que adicionar --hosts-dir /etc/containerd/certs.dtodos os nossos ctr image pullcomandos ao executar ctrmanualmente (fora das coisas do K8). foi muito fácil: apenas definimos a opção correta no arquivo de configuração JSON do daemon do docker ( "insecure-registry": "127.0.0.1") e funcionou bem. Mas estou tendo problemas para encontrar uma configuração equivalente para ctrse comportar de maneira semelhante. Claro, o plugin CRI está usando ohosts.tomlarquivo que configurei perfeitamente, mas gostaria de poder extrair imagens manualmente sem precisar adicionar um sinalizador extra ao comando. Existe uma maneira de configurar o containerd para que ctr image pullnão precise --hosts-dirser passado todas as vezes?
Esta é a hosts.tomlaparência desse arquivo:
server = "http://registry.at.my.company"
[host."http://registry.at.my.company"]
skip_verify = true
plain-http = true
E no /etc/containerd/config.tomlarquivo, tenho o CRI apontando para ele assim:
[plugins."io.containerd.grpc.v1.cri".registry]
config_path = "/etc/containerd/certs.d"
Mas, como supus e disse acima, isso parece afetar apenas a forma como o kubelet interage com o containerd, e não como ctro faz.
Algum contexto de fundo:
Temos esse registro local em execução com uma /etc/hostsentrada como esta: 127.0.1.1 registry.at.my.company. Junto com algumas regras de firewall, isso faz com que todos que usam nossos clusters Kubernetes tenham que enviar suas imagens registry.at.my.companye configurar seus pods para usar imagens de lá, porque nossos kubelets não serão capazes de extrair de qualquer lugar além desse domínio; e para fazer com que nosso registro não seja um SPoF, executamos esses contêineres de registro locais como espelhos somente leitura (e o próprio servidor do contêiner de registro aceita apenas conexões locais, evitando que a falta de certificados SSL seja um problema). não tenho certeza se isso é relevante para o meu problema, mas deve ajudar a explicar por que eu estava falando sobre a insecure-registryopção antiga no docker e por que eu hosts.tomluso httpem vez dehttps, para que não preocupe ninguém.
Além disso, esta é a versão 1.6.19 do containerd com a qual estou trabalhando.
Instalei o aide no Ubuntu 22.04 e deixei a configuração padrão. Depois de executado, recebi um relatório por e-mail indicando que tudo correu bem. Veja o relatório abaixo.
Os /var/lib/aide/aide.db.newe /var/lib/aide/aide.dbsão zero bytes. Há bastante espaço livre no dispositivo e não consigo encontrar nada incomum nos arquivos de log.
Alguma idéia de como procurar a causa desse problema?
AIDE returned with exit code 1. Added entries detected!
AIDE produced no errors.
******************************************************************************
* AIDE has returned long output which has been truncated in this mail *
******************************************************************************
Output is 2792556 lines, truncated to 1000.
Start timestamp: 2023-08-20 06:25:01 +0200 (AIDE 0.17.4)
AIDE found differences between database and filesystem!!
New AIDE database written to /var/lib/aide/aide.db.new
Ignored e2fs attributes: EIh
Summary:
Total number of entries: 2792523
Added entries: 2792500
Removed entries: 0
Changed entries: 0
Estou tentando configurar um proxy reverso para um aplicativo que estou construindo. O aplicativo é dividido em duas imagens docker. A primeira é uma interface de usuário da web, que pode ser acessada via https://example.com/
A segunda imagem docker tem endereços base nos quais estou interessado. A primeira é https://example.com/swagger e a segunda é https://example.com/api
Quando navego para example.com, tudo funciona conforme o esperado. Eu recebo o front-end do aplicativo. Quando navego para o link do swagger, novamente tudo está funcionando bem, recebo a página do swagger. o endereço real é https://example.com/swagger/index.html
No entanto, a terceira parte disso é que https://example.com/api é uma API Rest que desejo acessar, quando tento fazer uma chamada para isso. Ou, mais especificamente, uma solicitação POST para https://example.com/api/Authentication/login
Recebo uma resposta 307 do servidor que redireciona a chamada para http://actualserver.local:7066/api/Authentication/login
Não entendo por que está fazendo isso, pois deveria estar obtendo as informações da mesma forma que o link de arrogância está fazendo.
Aqui está meu arquivo nginx.conf que estou usando para executar o proxy reverso
worker_processes 1;
events { worker_connections 1024; }
http {
client_max_body_size 0;
sendfile on;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Host $server_name;
server {
listen 80 default_server;
server_name example.com;
# location /.well-known/acme-challenge/ {
# root /var/www/certbot;
# }
return 301 https://$host$request_uri;
}
server {
listen 443 ssl http2;
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
server_name example.com;
location /api {
proxy_pass http://actualserver.local:7066/api;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "Upgrade";
proxy_set_header X-Forwarded-Proto https;
proxy_redirect off;
}
location /swagger {
proxy_pass http://actualserver.local:7066/swagger;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "Upgrade";
proxy_set_header X-Forwarded-Proto https;
proxy_redirect off;
}
location / {
proxy_pass http://actualserver.local:3000;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "Upgrade";
proxy_set_header X-Forwarded-Proto https;
proxy_redirect off;
}
location /.well-known/acme-challenge/ {
root /var/www/certbot;
}
}
}
O que estou procurando é fazer com que o proxy reverso faça a chamada para actualserver.local, em vez de retornar um 307. Estou um pouco perdido aqui, então qualquer ajuda seria apreciada.
atualização: tentei modificar a configuração do nginx para ver se isso tem algum efeito. Aqui está o meu arquivo atualizado.
trabalhador_processos 1;
eventos { worker_connections 1024; }
http { client_max_body_size 0; enviar arquivo em;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Host $server_name;
upstream web-ui {
server actualserver.local:3000;
}
upstream web-api {
server actualserver.local:7066;
}
server {
listen 80 default_server;
server_name example.com;
return 301 https://$host$request_uri;
}
server {
listen 443 ssl http2;
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
server_name example.com;
location /api {
proxy_pass http://web-api/api;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "Upgrade";
proxy_set_header X-Forwarded-Proto https;
proxy_redirect off;
}
location /swagger {
proxy_pass http://web-api/swagger;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "Upgrade";
proxy_set_header X-Forwarded-Proto https;
proxy_redirect off;
}
location / {
proxy_pass http://web-ui;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "Upgrade";
proxy_set_header X-Forwarded-Proto https;
proxy_redirect off;
}
location /.well-known/acme-challenge/ {
root /var/www/certbot;
}
}
}
A localização relatada no 307 é
https://web-api:7066/api/Authentication/login
O único local onde existe web-api em toda a base de código é nginx.conf, não pode ser do servidor de aplicativos. Tem que ser o nginx que está fazendo isso.
Estou rodando opendmarccom postfixo Debian linux. Eu fiz a instalação padrão do Debian baseada em apt opendmarc, mas depois percebi que ele está aparentemente configurado por padrão para ser usado opendmarc-importpara salvar dados de importação em um banco de dados.
Não quero usar o banco de dados, mas não consigo encontrar nenhuma maneira de opendmarcinterromper o registro de informações nesse banco de dados.
Não vejo nada /etc/opendmarc.confque pareça controlar se opendmarc-importestá ou não configurado para ser utilizado.
Alguém poderia me indicar instruções sobre como opendmarcparar de usar opendmarc-import? Não consigo encontrar nenhuma documentação em nenhum lugar que pesquisei.
Muito obrigado antecipadamente.
PS : Acho que poderia colocar manualmente um exit(0);próximo ao topo do /usr/sbin/opendmarc-importscript perl (ou fazer alguma outra alteração apropriada nesse script), mas prefiro não confiar em um hack como esse.
Desejo importar um cliente do Windows Data Protector que usa a porta (herdada) 5555 para um Cell Server executando 11.02. Quando tento, recebo o certificado para aceitar, mas recebo um [12:1625] Import host failed.erro.
Suspeito que seja devido ao fato de que as instalações recentes usam como padrão a porta 5565.
Portanto, minha pergunta é: existe uma maneira de especificar a porta a ser usada ao importar um cliente? (Tentei adicionar a porta como ":portnr" ao nome do host, mas não foi aceito.)
Eu instalei kubelet 1.26.0no Ubuntu 22.04 usando apt install kubeleto comando, mas quando tento journalctl -xeu kubeletobtenho o seguinte resultado:
░░
░░ The unit kubelet.service has entered the 'failed' state with result 'exit-code'.
Dec 14 15:41:16 a systemd[1]: kubelet.service: Scheduled restart job, restart counter is at 86.
░░ Subject: Automatic restarting of a unit has been scheduled
░░ Defined-By: systemd
░░ Support: http://www.ubuntu.com/support
░░
░░ Automatic restarting of the unit kubelet.service has been scheduled, as the result for
░░ the configured Restart= setting for the unit.
Dec 14 15:41:16 a systemd[1]: Stopped kubelet: The Kubernetes Node Agent.
░░ Subject: A stop job for unit kubelet.service has finished
░░ Defined-By: systemd
░░ Support: http://www.ubuntu.com/support
░░
░░ A stop job for unit kubelet.service has finished.
░░
░░ The job identifier is 26301 and the job result is done.
Dec 14 15:41:16 a systemd[1]: Started kubelet: The Kubernetes Node Agent.
░░ Subject: A start job for unit kubelet.service has finished successfully
░░ Defined-By: systemd
░░ Support: http://www.ubuntu.com/support
░░
░░ A start job for unit kubelet.service has finished successfully.
░░
░░ The job identifier is 26301.
Dec 14 15:41:16 a kubelet[18015]: Flag --pod-infra-container-image has been deprecated, will be removed in 1.27. Image garbage collector will get sandbox image information from CRI.
Dec 14 15:41:16 a kubelet[18015]: I1214 15:41:16.367525 18015 server.go:198] "--pod-infra-container-image will not be pruned by the image garbage collector in kubelet and should also be set in the rem>
Dec 14 15:41:16 a kubelet[18015]: Flag --pod-infra-container-image has been deprecated, will be removed in 1.27. Image garbage collector will get sandbox image information from CRI.
Dec 14 15:41:16 a kubelet[18015]: I1214 15:41:16.371255 18015 server.go:412] "Kubelet version" kubeletVersion="v1.26.0"
Dec 14 15:41:16 a kubelet[18015]: I1214 15:41:16.371272 18015 server.go:414] "Golang settings" GOGC="" GOMAXPROCS="" GOTRACEBACK=""
Dec 14 15:41:16 a kubelet[18015]: I1214 15:41:16.371499 18015 server.go:836] "Client rotation is on, will bootstrap in background"
Dec 14 15:41:16 a kubelet[18015]: I1214 15:41:16.372757 18015 certificate_store.go:130] Loading cert/key pair from "/var/lib/kubelet/pki/kubelet-client-current.pem".
Dec 14 15:41:16 a kubelet[18015]: I1214 15:41:16.373608 18015 dynamic_cafile_content.go:157] "Starting controller" name="client-ca-bundle::/etc/kubernetes/pki/ca.crt"
Dec 14 15:41:16 a kubelet[18015]: I1214 15:41:16.399357 18015 server.go:659] "--cgroups-per-qos enabled, but --cgroup-root was not specified. defaulting to /"
Dec 14 15:41:16 a kubelet[18015]: I1214 15:41:16.399717 18015 container_manager_linux.go:267] "Container manager verified user specified cgroup-root exists" cgroupRoot=[]
Dec 14 15:41:16 a kubelet[18015]: I1214 15:41:16.399832 18015 container_manager_linux.go:272] "Creating Container Manager object based on Node Config" nodeConfig={RuntimeCgroupsName: SystemCgroupsName>
Dec 14 15:41:16 a kubelet[18015]: I1214 15:41:16.399866 18015 topology_manager.go:134] "Creating topology manager with policy per scope" topologyPolicyName="none" topologyScopeName="container"
Dec 14 15:41:16 a kubelet[18015]: I1214 15:41:16.399883 18015 container_manager_linux.go:308] "Creating device plugin manager"
Dec 14 15:41:16 a kubelet[18015]: I1214 15:41:16.399940 18015 state_mem.go:36] "Initialized new in-memory state store"
Dec 14 15:41:16 a kubelet[18015]: E1214 15:41:16.402173 18015 run.go:74] "command failed" err="failed to run Kubelet: validate service connection: CRI v1 runtime API is not implemented for endpoint \">
Dec 14 15:41:16 a systemd[1]: kubelet.service: Main process exited, code=exited, status=1/FAILURE
░░ Subject: Unit process exited
░░ Defined-By: systemd
░░ Support: http://www.ubuntu.com/support
░░
░░ An ExecStart= process belonging to unit kubelet.service has exited.
░░
░░ The process' exit code is 'exited' and its exit status is 1.
Dec 14 15:41:16 a systemd[1]: kubelet.service: Failed with result 'exit-code'.
░░ Subject: Unit failed
░░ Defined-By: systemd
░░ Support: http://www.ubuntu.com/support
░░
░░ The unit kubelet.service has entered the 'failed' state with result 'exit-code'.
lines 2547-2600/2600 (END)
Não sei qual é o problema e como posso me livrar dele?
Estou trabalhando em um projeto em https://modernamedia.no/ e estou tentando fazer várias coisas
o último está funcionando. no entanto, os dois primeiros não estão funcionando. Você pode testá-lo acessando https://www.modernamedia.no/
Também estou lutando para alcançar meu localhost por meio de uma chamada de API, mas isso pode ser um problema relacionado ao código.
server {
if ($host = www.modernamedia.no) {
return 301 https://modernamedia.no$request_uri;
} # managed by Certbot
if ($host = modernamedia.no) {
return 301 https://$host$request_uri;
} # managed by Certbot
# Redirect to the correct place, if needed
set $https_redirect 0;
if ($server_port = 80) { set $https_redirect 1; }
if ($host ~ '^www\.') { set $https_redirect 1; }
if ($https_redirect = 1) {
return 301 https://modernamedia.no$request_uri;
}
listen 80;
server_name modernamedia.no;
return 404; # managed by Certbot
}
server {
listen [::]:443 ssl http2 ipv6only=on;
listen 443 ssl http2; # managed by Certbot
server_name modernamedia.no;
location / {
proxy_pass http://localhost:4000;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection 'upgrade';
proxy_set_header Host $host;
proxy_cache_bypass $http_upgrade;
}
ssl_certificate /etc/letsencrypt/live/modernamedia.no/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/modernamedia.no/privkey.pem; # managed by Certbot
include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
# ssl_ciphers EECDH+CHACHA20:EECDH+AES128:RSA+AES128:EECDH+AES256:RSA+AES256:EECDH+3DES:RSA+3DES:!MD5;
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
}
server {
listen 80;
server_name www.modernamedia.no;
return 301 https://modernamedia.no$request_uri;
}
server {
listen 81;
server_name api.modernamedia.no;
root /var/www/ModernaMedia/DotNet;
location / {
proxy_pass http://localhost:5000;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection keep-alive;
proxy_set_header Host $host;
proxy_cache_bypass $http_upgrade;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
}
server {
listen 81;
server_name api.modernamedia.no;
root /var/www/ModernaMedia/DotNet;
location / {
proxy_pass http://localhost:5000;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection keep-alive;
proxy_set_header Host $host;
proxy_cache_bypass $http_upgrade;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
}
[Unit]
Description=ModernaMedia Net5 service
[Service]
WorkingDirectory=/var/www/ModernaMedia/DotNet
ExecStart=/usr/bin/dotnet /var/www/ModernaMedia/DotNet/ModernaMediaDotNet.dll
Restart=always
# Restart service after 10 seconds if the dotnet service crashes:
RestartSec=10
KillSignal=SIGINT
SyslogIdentifier=ModernaMedia-dotnet
User=www-data
Environment=ASPNETCORE_ENVIRONMENT=Production
Environment=DOTNET_PRINT_TELEMETRY_MESSAGE=false
[Install]
WantedBy=multi-user.target
E eu posso acessar meu servidor .NET através do curl