All perguntas(server)

Tenho meu calendário publicado no Exchange 2010, de modo que tenho links que posso usar para obter anonimamente os detalhes do calendário como um ICS, com todos os detalhes disponíveis, que uso para acessar meu calendário a partir de meus próprios aplicativos e sistemas privados.

O que eu gostaria de fazer é também ter um par separado de links que eu possa disseminar mais amplamente, que contenham apenas informações de livre/ocupado. Embora esta seja uma das opções, não consigo gerar links adicionais, pois o calendário já está compartilhado com detalhes, ou seja, parece que só consigo compartilhar o calendário em uma configuração, não em várias:

Há algo que estou esquecendo aqui que permitiria que fosse compartilhado de várias maneiras diferentes? No outlook.com/Office365 online, é possível fazer isso, mas não encontrei nenhuma documentação que diga que não pode ser feito nas versões locais (mostrado abaixo, eu já tenho um link "todos os detalhes" publicado, e tenho a opção de compartilhá-lo novamente, com livre/ocupado):

É possível compartilhar um calendário em cada configuração possível com o Exchange 2010, como acontece com o outlook.com/Exchange Online, ou apenas uma configuração por vez é possível?

Estou ciente de ferramentas de proxy iCal como https://github.com/scy/calproxy que podem fornecer uma visualização filtrada de livre/ocupado, mas parece muito trabalhoso configurar algo assim se houver uma maneira de fazer isso nativamente.

Tenho um cluster EKS em execução em uma VPC com tráfego de rede corporativa apenas. Tenho meu aplicativo exposto com um ALB (usando AWS Load Balancer Controller com k8s Service + Ingress) usando TLS. Tenho outra VPC com acesso público. As 2 VPCs têm uma conexão de peering.

Quais são as melhores práticas para criar um LB dentro da VPC pública para que ele aponte para o aplicativo na VPC privada? O LB público deve ter um domínio DNS, enquanto o LB privado deve ter outro.

Procurando por conselhos gerais. Até agora, tenho uma solução muito ruim, onde tenho um ALB na VPC pública e ele aponta diretamente para o IP do Kubernetes Service dentro da VPC privada.

Obrigado pela ajuda!

Veja este manifesto yaml:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: myserviceaccount
  namespace: default
---
apiVersion: v1
kind: Secret
metadata:
  name: myserviceaccount-token
  namespace: default
  annotations:
    kubernetes.io/service-account.name: myserviceaccount
type: kubernetes.io/service-account-token

Eu aplico este manifesto no meu cluster k8s:

$ kubectl apply -f myserviceaccount.yaml

Quando tento este comando:

$ kubectl -n default get service account/myserviceaccount

-> Vejo 0 segredos contados

Eu deveria ver pelo menos 1 segredo para myserviceaccount-token. Por que não vejo esse segredo?

Obrigado

Na minha LAN de pilha dupla, um servidor de vinculação resolve domínios locais ( *.something.internal) para registros A e AAAA:

# bind zone file db.internal
webserver1.something      IN      AAAA    2001:908:532:bca0:211:32ff:fee5:8627 
webserver1.something      IN      A       192.168.78.93

e todos os servidores web LAN escutam em IPv4 e IPv6. Ao acessar os servidores, o IPv6 é priorizado (como esperado), exceto para meu cliente local (que também atua como um servidor web) no Firefox e Safari. O Chrome usa endereços IPv6 para todos os servidores. Usei a aba Network das ferramentas do desenvolvedor em todos os três navegadores para comparar e verificar o comportamento.

Também usei o about:networking#dnslookuptoolrecurso no Firefox, e o Firefox inverte consistentemente a ordem dos IPs IPv4/IPv6 somente para meu cliente.

Como próximo passo, verifiquei com curl e vi (quase) a mesma coisa. O curl resolve o IPv6 primeiro, mas depois passa a usar o endereço IPv4 para a máquina local:

# This is my local client and webserver
curl -Iv https://static.something.internal/
* Host static.something.internal:443 was resolved.
* IPv6: 2001:908:532:bca0:10e0:6db1:72f1:9c2f
* IPv4: 192.168.78.55
*   Trying 192.168.78.55:443...
* Connected to static.something.internal (192.168.78.55) port 443

# This is another webserver on the LAN
curl -Iv https://nuc.something.internal/
* Host nuc.something.internal:443 was resolved.
* IPv6: 2001:908:532:bca0:1e69:7aff:feaf:7455
* IPv4: 192.168.78.42
*   Trying [2001:908:532:bca0:1e69:7aff:feaf:7455]:443...
* Connected to nuc.something.internal (2001:908:532:bca0:1e69:7aff:feaf:7455) port 443

Por que o Firefox, Safari e curl priorizam IPv4 para a máquina local (ao contrário do Chrome)? Poderia ter algo a ver com o fato de que a solicitação é enviada do mesmo endereço IPv6 que o domínio resolve (mesmo que o curl use esse endereço sem problemas quando forçado a usar com curl -Iv -6 https://static.something.internal)?

Observação: se eu preencher /etc/hostsa máquina local (usando 127.0.0.1e ::1para seus domínios) em vez de usar meu servidor DNS, todos os aplicativos priorizarão o IPv6 (o seguinte teste curl foi repetido com o Firefox e o Safari):

curl -Iv https://static.something.internal/
* Host static.something.internal:443 was resolved.
* IPv6: ::1
* IPv4: 127.0.0.1
*   Trying [::1]:443...
* Connected to static.something.internal (::1) port 443

Estou fazendo um script padrão: atualizar a configuração do nginx pelo crontab e recarregar a configuração

11 11 * * * /root/change.sh>> /root/script.log

#!/usr/bin/env bash

# do changes

echo "reload started"
service nginx reload
#nginx -s reload
echo "reload done"

Vejo uma execução de script no syslog, mas a configuração do nginx permanece sem recarregar.

31 de agosto 11:13:01 t2 CRON[1073432]: (root) CMD (/root/change.sh >> /root/script.log)

E nenhuma nova entrada no log do serviço nginx.

Atualizar

systemctl em vez do comando service funciona como esperado. Mas por quê?

systemctl recarregar nginx

No processo de migração do meu servidor de e-mail para um novo host. Uma das minhas dificuldades é que o OpenDKIM não está assinando e-mails de saída (não internos). Atualmente, meu TrustedHostsarquivo é o seguinte:

127.0.0.1
::1
localhost
*.example.com

(Onde example.com é meu domínio de e-mail.)

Estou enviando e-mail do meu cliente IMAP do meu telefone. Se eu adicionar o IP do meu telefone, a mensagem assina corretamente.

Vários tutoriais que vi executam esse layout, e é o que eu configurei até a migração. Eu realmente devo usar curinga em todos os hosts? Qual é a configuração recomendada?

Instalei uma máquina centos no Azure e seu endereço IP é 10.5.0.4. Depois, instalei uma máquina openVPN no Azure e seu endereço privado é 10.6.0.4. Fiz o peering entre as redes centOS e openVPN e funcionou bem, então posso fazer ping um no outro.

Quando eu conecto o openVPN com meu computador, meu computador local recebe o endereço IP privado 10.6.0.2. Eu posso fazer ping de 10.6.0.2 para 10.6.0.4, isso é bom, mas eu não posso fazer ping de 10.6.0.2 para 10.5.0.4. Eu acho que o openVPN não roteia o tráfego de 10.6.0.2 para 10.5.0.4. Como eu posso fazer esse roteamento?

Ao executar, terraform applyrecebi este erro:

Error: parsing old engine_version: Malformed version: 7.x
│ 
│   with module.redis_cluster.aws_elasticache_replication_group.replication_group,
│   on ../../../../modules/redis/main.tf line 11, in resource "aws_elasticache_replication_group" "replication_group":
│   11: resource "aws_elasticache_replication_group" "replication_group" {
│ 

Este parece ser o problema descrito em hashicorp/terraform-provider-aws#32252 , e há uma solução alternativa detalhada em um comentário :

1. Tínhamos algumas instâncias do Redis configuradas no Terraform usando a sintaxe curinga:6.x
2. Alguém atualizou manualmente os mecanismos Redis na interface do usuário do console da AWS para7.0.*
3. Após a atualização, o código foi atualizado 7.xmanualmente. Funcionou bem com o provedor AWS 4.37.0.
4. Quando comecei a trabalhar no mesmo repositório, atualizei o provedor AWS de 4.37.0para 5.9.0e enfrentei o problema: nem o 7.xvalor nem 7.0funcionou. Era o erro Redis versions must match <major>.<minor>...or Error: parsing old engine_version: Malformed version: 7.x.

A solução alternativa prossegue descrevendo a edição do estado remoto para corrigir o problema. Existe uma maneira mais fácil de resolver isso além dessa solução alternativa?

Estou instalando uma VM Windows usando LXD seguindo estas instruções: https://ubuntu.com/tutorials/how-to-install-a-windows-11-vm-using-lxd#1-overview . Elas funcionaram bem para mim até agora.

No entanto, não consigo compartilhar uma unidade com minha VM do Windows 11.

Eu tentei os seguintes comandos:

lxc config device add win11 foobar disk source=/home/foo/test/ path=C:\\Users\\bar\\Desktop\\test

e:

lxc config device add win11 foo disk source=/home/foo/test/ path=/c/Users/david/Desktop/test

Isso deve funcionar, pois o kernel é compartilhado.

Informações adicionais

lxc config showretorna o seguinte após os comandos acima:

architecture: x86_64
config:
  limits.cpu: "4"
  limits.memory: 8GiB
  volatile.cloud-init.instance-id: xxx
  volatile.eth0.host_name: xxxxxxxxxxx
  volatile.eth0.hwaddr: xxx
  volatile.last_state.power: RUNNING
  volatile.uuid: xxx
  volatile.uuid.generation: xxx
  volatile.vsock_id: "xxxxxxxxxx"
devices:
  foobar:
    path: C:\Users\janedoe\Desktop\test
    source: /home/johndoe/test/
    type: disk
  foo:
    path: /c/Users/janedoe/Desktop/test
    source: /home/johndoe/test/
    type: disk
  root:
    path: /
    pool: default
    size: 80GiB
    type: disk
  vtpm:
    path: /dev/tpm0
    type: tpm
ephemeral: false
profiles:
- default
stateful: false
description: ""

Essas são minhas primeiras experiências com LXD/LXC. Portanto, instruções para iniciantes absolutos seriam muito apreciadas.

Se eu tiver example.comna minha lista de pesquisa de sufixo DNS e eu abrir um navegador e digitar, wwwo navegador se comunicará com o sistema operacional, que se comunicará com o DNS; se wwwnão conseguir resolver, meu sistema operacional anexará os itens da minha lista de pesquisa de sufixo até que um seja bem-sucedido; www.example.comse for bem-sucedido, obtenho um IP para o qual minha solicitação será enviada.

No entanto, olhando para a solicitação que meu navegador envia, o cabeçalho do host é definido wwwcomo o que foi digitado na barra de endereços, mesmo que esse não seja o FQDN que foi eventualmente resolvido para o IP. Isso significa que se o servidor web usar a vinculação de nome de host, ele tem que ouvir wwwtambém o FQDN de www.example.com, ou ele não reconhecerá a solicitação como sendo uma que ele deveria manipular.

Algum navegador tem funcionalidade para obter automaticamente o FQDN resolvido de volta do SO / há alguma configuração que possa ser ajustada para habilitar isso? Se não houver tal funcionalidade, há um motivo (por exemplo, talvez o SO não exponha informações sobre o FQDN que foi resolvido com sucesso por algum motivo de segurança?), ou esse cenário é muito específico para qualquer um implementar?