All perguntas(server)

Eu instalei o cert-manager com kubectl

kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.15.0/cert-manager.yaml

Obtive meus recursos com sucesso:

my_user@vps-b123456:~$ k get all -n cert-manager
NAME                                           READY   STATUS    RESTARTS      AGE
pod/cert-manager-5fcfc99f7-mrjrn               1/1     Running   1 (17h ago)   25h
pod/cert-manager-cainjector-75cfc9f6b7-ntwd4   1/1     Running   3 (17h ago)   25h
pod/cert-manager-webhook-74b65dbf6f-kzp7w      1/1     Running   0             4h39m
pod/curl-deployment-6f95856b88-9cln2           1/1     Running   0             96s

NAME                           TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)    AGE
service/cert-manager           ClusterIP   10.101.200.103   <none>        9402/TCP   25h
service/cert-manager-webhook   ClusterIP   10.99.166.135    <none>        443/TCP    25h

NAME                                      READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/cert-manager              1/1     1            1           25h
deployment.apps/cert-manager-cainjector   1/1     1            1           25h
deployment.apps/cert-manager-webhook      1/1     1            1           25h
deployment.apps/curl-deployment           1/1     1            1           3h24m

NAME                                                 DESIRED   CURRENT   READY   AGE
replicaset.apps/cert-manager-5fcfc99f7               1         1         1       25h
replicaset.apps/cert-manager-cainjector-75cfc9f6b7   1         1         1       25h
replicaset.apps/cert-manager-webhook-74b65dbf6f      1         1         1       25h
replicaset.apps/curl-deployment-6f95856b88           1         1         1       3h24m

Porém, quando crio um ClusterIssuer com certificado, parece que o registro do ClusterIssuer na ACME não está funcionando.

my_user@vps-b123456:~$ k logs cert-manager-5fcfc99f7-mrjrn -n cert-manager
...
I0605 21:25:21.806374       1 setup.go:225] "ACME server URL host and ACME private key registration host differ. Re-checking ACME account registration" logger="cert-manager.clusterissuers" resource_name="letsencrypt-prod" resource_namespace="" resource_kind="ClusterIssuer" resource_version="v1" related_resource_name="letsencrypt-prod-secret-key" related_resource_namespace="cert-manager" related_resource_kind="Secret"
E0605 21:25:21.842707       1 setup.go:265] "failed to register an ACME account" err="Get \"https://acme-v02.api.letsencrypt.org/directory\": dial tcp 172.65.32.248:443: connect: connection refused" logger="cert-manager.clusterissuers" resource_name="letsencrypt-prod" resource_namespace="" resource_kind="ClusterIssuer" resource_version="v1" related_resource_name="letsencrypt-prod-secret-key" related_resource_namespace="cert-manager" related_resource_kind="Secret"
E0605 21:25:21.842746       1 sync.go:62] "error setting up issuer" err="Get \"https://acme-v02.api.letsencrypt.org/directory\": dial tcp 172.65.32.248:443: connect: connection refused" logger="cert-manager.clusterissuers" resource_name="letsencrypt-prod" resource_namespace="" resource_kind="ClusterIssuer" resource_version="v1"
E0605 21:25:21.842806       1 controller.go:167] "re-queuing item due to error processing" err="Get \"https://acme-v02.api.letsencrypt.org/directory\": dial tcp 172.65.32.248:443: connect: connection refused" logger="cert-manager.clusterissuers" key="letsencrypt-prod"

Na parte inferior da saída de descrição, vejo que a conexão foi recusada com ACME.

my_user@vps-b123456:~/k8s/ingress$ k get clusterissuer -n stratonation
NAME               READY   AGE
letsencrypt-prod   False   4h19m
my_user@vps-b123456:~/k8s/ingress$ k describe clusterissuer letsencrypt-prod -n stratonation
Name:         letsencrypt-prod
Namespace:    
Labels:       <none>
Annotations:  <none>
API Version:  cert-manager.io/v1
Kind:         ClusterIssuer
Metadata:
  Creation Timestamp:  2024-06-05T17:12:30Z
  Generation:          1
  Resource Version:    160637
  UID:                 d8338116-ba4c-4f38-a8c8-e0ab6fc23d17
Spec:
  Acme:
    Email:  [email protected]
    Private Key Secret Ref:
      Name:  letsencrypt-prod-secret-key
    Server:  https://acme-v02.api.letsencrypt.org/directory
    Solvers:
      http01:
        Ingress:
          Class:  nginx
Status:
  Acme:
  Conditions:
    Last Transition Time:  2024-06-05T17:13:00Z
    Message:               Failed to register ACME account: Get "https://acme-v02.api.letsencrypt.org/directory": dial tcp 172.65.32.248:443: connect: connection refused
    Observed Generation:   1
    Reason:                ErrRegisterACMEAccount
    Status:                False
    Type:                  Ready
Events:
  Type     Reason         Age                   From                         Message
  ----     ------         ----                  ----                         -------
  Warning  ErrInitIssuer  103s (x26 over 121m)  cert-manager-clusterissuers  Error initializing issuer: Get "https://acme-v02.api.letsencrypt.org/directory": dial tcp 172.65.32.248:443: connect: connection refused

Tenho todo o tráfego aberto para meus testes.

my_user@vps-b123456:~/k8s/ingress$ sudo iptables -L --line-number
Chain INPUT (policy ACCEPT)
num  target     prot opt source               destination         
1    cali-INPUT  all  --  anywhere             anywhere             /* cali:Cz_u1IQiXIMmKD4c */
2    ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:https
3    KUBE-FIREWALL  all  --  anywhere             anywhere            

Chain FORWARD (policy ACCEPT)
num  target     prot opt source               destination         
1    cali-FORWARD  all  --  anywhere             anywhere             /* cali:wUHhoiAYhphO9Mso */
2    FLANNEL-FWD  all  --  anywhere             anywhere             /* flanneld forward */
3    ACCEPT     all  --  anywhere             anywhere             /* cali:S93hcgKJrXEqnTfs */ /* Policy explicitly accepted packet. */ mark match 0x10000/0x10000
4    MARK       all  --  anywhere             anywhere             /* cali:mp77cMpurHhyjLrM */ MARK or 0x10000

Chain OUTPUT (policy ACCEPT)
num  target     prot opt source               destination         
1    cali-OUTPUT  all  --  anywhere             anywhere             /* cali:tVnHkvAo15HuiPy0 */
2    KUBE-FIREWALL  all  --  anywhere             anywhere        

não tenho nada de interessante nos logs do coredns:

my_user@vps-b123456:~/k8s/ingress$ k logs coredns-7c959b8749-wds6f -n kube-system
.:53
[INFO] plugin/reload: Running configuration SHA512 = 1738324c9bbcf1f65e6f15ff89dc70b4233e041641c7505b9e8b59c06e2693b4ec8076bc45bb8eb5bb2486f97476db226b7ffd55fead273980ea10a477458357
CoreDNS-1.10.0
linux/amd64, go1.19.1, 596a9f9

aqui está meu ClusterIssuer:

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-prod
  namespace: stratonation
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    email: [email protected]
    privateKeySecretRef:
      name: letsencrypt-prod-secret-key
    solvers:
      - http01:
          ingress:
            class: nginx

e meu certificado:

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: my-certificate
  namespace: stratonation
spec:
  secretName: letsencrypt-prod
  duration: 2160h # 90 days
  renewBefore: 720h # 30 days
  issuerRef:
    name: letsencrypt-prod
    kind: ClusterIssuer
  commonName: exemple.com
  dnsNames:
    - exemple.com
  privateKey:
    algorithm: RSA
    size: 2048

Você tem alguma ideia?

Estou construindo um contêiner para Kubernetes que executa um controlador de domínio SAMBA Active Directory.

Estou fazendo o trabalho por meio do Ansible e o contêiner está sendo implantado em um cluster Kubernetes (K3S).

O Docker está usando os seguintes arquivos como parte de sua construção:

etc/krb5.conf
etc/bind/rndc.key
etc/bind/named.conf.local
etc/bind/db.0
etc/bind/db.255
etc/bind/db.empty
etc/bind/named.conf.options
etc/bind/db.local
etc/bind/named.conf
etc/bind/db.127
etc/bind/named.conf.default-zones
etc/supervisor/conf.d/supervisord.conf
etc/freeradius/3.0/mods-available/eap
etc/freeradius/3.0/mods-available/realm
etc/freeradius/3.0/mods-available/ntlm_auth
etc/freeradius/3.0/mods-available/mschap
etc/freeradius/3.0/clients.conf
etc/freeradius/3.0/proxy.conf
etc/freeradius/3.0/sites-available/default
etc/freeradius/3.0/sites-available/inner-tunnel
boot/init.sh
boot/kdb5_util_create.expect
Dockerfile

A ideia é que para todos os arquivos o caminho seja o mesmo dentro do container, mas /como prefixo.

No entanto, me deparei com algo estranho ao inspecionar o contêiner em execução que foi compilado como resultado.

O conteúdo de /etc/samba, /etc/binde /etc/freeradiusdefinitivamente não deveria ser o mesmo!

O conteúdo do meu Dockerfileé o seguinte:

FROM ubuntu:noble

ENV DEBIAN_FRONTEND noninteractive

# Avoid ERROR: invoke-rc.d: policy-rc.d denied execution of start.
RUN echo "#!/bin/sh\nexit 0" > /usr/sbin/policy-rc.d

VOLUME ["/var/lib/samba", "/etc/samba", "/etc/bind", "/etc/freeradius", "/SambaVolume"]

# Setup ssh and install supervisord
RUN apt-get update
RUN apt-get upgrade -y
RUN apt-get install -y openssh-server supervisor ntp mc
RUN mkdir -p /var/run/sshd
RUN mkdir -p /var/log/supervisor
RUN sed -ri 's/PermitRootLogin without-password/PermitRootLogin Yes/g' /etc/ssh/sshd_config

# Add SAMBA VolumeShare location
RUN mkdir -p /SambaVolume

# Install bind9 dns server
RUN apt-get install -y bind9 dnsutils
# Copy tweaked DNS setttings (instead of ADD, due to we want to overwrite any existing files)
COPY etc/bind/* /etc/bind/

# Install samba and dependencies to make it an Active Directory Domain Controller
RUN apt-get install -y samba smbclient winbind libpam-winbind libnss-winbind krb5-kdc libpam-krb5

# Install Freeradius so validate VPN users against samba
RUN apt-get install -y freeradius

# Copy Freeradius customised files
COPY etc/freeradius/ /etc/freeradius/

# Copy customized kerberos configuration file
COPY etc/krb5.conf /etc/

# Install utilities needed for setup
RUN apt-get install -y expect pwgen
ADD boot/kdb5_util_create.expect /root/kdb5_util_create.expect

# Install rsyslog to get better logging of ie. bind9
RUN apt-get install -y rsyslog

# Create run directory for bind9
RUN mkdir -p /var/run/named
RUN chown -R bind:bind /var/run/named

# Add supervisord and init
ADD etc/supervisor/conf.d/supervisord.conf /etc/supervisor/conf.d/supervisord.conf
ADD boot/init.sh /root/init.sh
RUN chmod 755 /root/init.sh
EXPOSE 53/tcp 53/udp 80/tcp 80/udp 88/tcp 88/udp 135/tcp 135/udp 137/tcp 137/udp 
EXPOSE 138/tcp 138/udp 389/tcp 389/udp 443/tcp 443/udp 445/tcp 445/udp 464/tcp 464/udp 
EXPOSE 636/tcp 636/udp 3268/tcp 3268/udp 3269/tcp 3269/udp 9389/tcp 9389/udp
EXPOSE 123/udp 22/tcp 22/udp
ENTRYPOINT ["/root/init.sh"]
CMD ["app:start"]

E o contêiner compilado está sendo armazenado em um registro local usando os seguintes comandos:

  docker build -t samba:latest samba/
  docker tag samba:latest registry.example.com:5000/samba:latest
  docker push registry.example.com:5000/samba:latest  

Ele está sendo implantado através do Ansible com a seguinte tarefa:

- name: Create SAMBA Deployment
  kubernetes.core.k8s:
    state: present
    definition:
      apiVersion: apps/v1
      kind: StatefulSet
      metadata:
        name: samba
        namespace: samba-system
        labels:
          app: samba
      spec:
        replicas: 1
        selector:
          matchLabels:
            app: samba
        template:
          metadata:
            labels:
              app: samba
          spec:
            volumes:
              - name: samba-config
                persistentVolumeClaim:
                  claimName: samba-config-vol

            containers:
              - name: samba
                image: registry.example.com:5000/samba:latest
                ports:
                  - containerPort: 123
                    protocol: UDP

#           ### SKIPPING ###

                 - containerPort: 9389
                    protocol: UDP
                  - containerPort: 9389
                    protocol: TCP

                volumeMounts:
                  - name: samba-config
                    mountPath: /etc/samba
                  - name: samba-config
                    mountPath: /etc/bind
                  - name: samba-config
                    mountPath: /etc/freeradius
                  - name: samba-config
                    mountPath: /var/lib/samba

                envFrom:
                  - configMapRef:
                      name: samba-environment-map

                securityContext:
                  priviledged: true
                  allowPrivilegeEscalation: true
                  readOnlyRootFilesystem: false

                  capabilities:
                    add:
                      - ALL

Estou me perguntando por que o conteúdo das pastas /etc/bindé /etc/sambao /etc/freeradiusmesmo.

Pensei ter lido em algum lugar que você poderia usar o mesmo persistentVolumeClaimpara todas as pastas.

Estou usando o recurso "Match...exec" da configuração do OpenSSH para conectar-me condicionalmente a instâncias do AWS EC2 por meio de um túnel. Tenho desenvolvido https://gist.github.com/Maks3w/de72b0160d5e6af958adc42eab014624; Eu tenho algo assim:

Match host i-* exec "aws-proxy.sh %r %h ~/.ssh/aws-proxy.%h.%r"
    IdentityFile ~/.ssh/aws-proxy.%h.%r
    ProxyCommand aws ec2-instance-connect open-tunnel --instance-id %h
    # Remove ephemeral key
    PermitLocalCommand yes
    LocalCommand rm ~/.ssh/aws-proxy.%h.%r*

Isso funciona bem para sshnão para scp. Em particular, a última linha nunca é chamada ao usar scp. Tentei chamar um script em vez de chamar rmdiretamente, para facilitar a depuração, mas o script também nunca é executado. Parece que as declarações param de ser executadas ao usar scp. Para ser claro, as duas primeiras diretivas funcionam bem scpe, portanto, scpfuncionam, mas o código de limpeza nunca é chamado. Enquanto isso, tudo funciona bem com ssh. Alguma ideia?

• Tentei o modo detalhado, mas não há saída para indicar por que as declarações param de ser executadas.
• Tentei chamar um script em vez de rmdiretamente, mas o script também nunca foi chamado.
• Comecei a escrever um script de wrapper, mas percebi que escrever um wrapper scpseria um esforço decente, então pensei em pedir ajuda primeiro...

EDIT: Acabei escrevendo um script wrapper para isso. É menos flexível, mas faz o trabalho que preciso.

No servidor Ubuntu 22.04, tenho um script bash que recarrega a configuração do nagios4. Após a recarga gostaria de verificar se o serviço está bom

#!/bin/bash
sudo systemctl reload nagios4.service

if (systemctl --quiet is-failed nagios4.service); then
    echo "Bad config!"
fi

de alguma forma não está funcionando, se a configuração não estiver ok, o serviço falha mas isso não é reconhecido pelosystemctl is-failed

se manualmente eu verificosystemctl status nagios4

× nagios4.service - nagios4
     Loaded: loaded (/lib/systemd/system/nagios4.service; enabled; vendor preset: enabled)
     Active: failed (Result: exit-code) since Wed 2024-06-05 09:20:03 CEST; 4min 27s ago

Tentei alterar meu script para usar restartem vez de reloadou executar systemctl is-failedcom sudo, mas nada muda.

o que estou perdendo?

Atualização: reloado status de retorno é 0uniforme em caso de falha

sudo systemctl reload nagios4.service
status=$?
echo $status

Estou no Fedora e configurei um servidor OpenLDAP. Não me lembro de ter definido uma senha de administrador para começar, mas estou tendo que realizar operações nas quais a senha de administrador é solicitada. Não inserir nada não funciona. Fiz uma extensa pesquisa sobre o problema e tentei o seguinte:

$ ldapmodify -Q -Y EXTERNAL -H ldapi:/// << E0F
dn: olcDatabase={1}mdb,cn=config
changetype: modify
replace: olcRootPW
olcRootPW: {SSHA}wDiv2teFapZFmOwSz04/2CMaYvpqfLvi
E0F
modifying entry "olcDatabase={1}mdb,cn=config"
ldap_modify: Insufficient access (50)

$ sudo -i
[sudo] password for User: 
[root@localhost ~]# ldapmodify -Q -Y EXTERNAL -H ldapi:/// << E0F
dn: olcDatabase={1}mdb,cn=config
changetype: modify
replace: olcRootPW
olcRootPW: {SSHA}wDiv2teFapZFmOwSz04/2CMaYvpqfLvi
E0F
modifying entry "olcDatabase={1}mdb,cn=config"
ldap_modify: Insufficient access (50)

$ ldapsearch -LLL -Y EXTERNAL -H ldapi:/// -b  cn=config olcRootDN=cn=admin,dc=com,dc=example  dn olcRootDN olcRootPW
SASL/EXTERNAL authentication started
SASL username: gidNumber=1000+uidNumber=1000,cn=peercred,cn=external,cn=auth
SASL SSF: 0
No such object (32)

$ sudo ldapsearch -H ldapi:/// -Y EXTERNAL -b 'cn=config'
[sudo] password for User: 
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
# extended LDIF
#
# LDAPv3
# base <cn=config
> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# search result
search: 2
result: 32 No such object

# numResponses: 1

$ sudo ldapmodify -Q -Y EXTERNAL -H ldapi:/// << E0F
dn: olcDatabase={1}mdb,cn=config
changetype: modify
replace: olcRootPW
olcRootPW: {SSHA}wDiv2teFapZFmOwSz04/2CMaYvpqfLvi
E0F
modifying entry "olcDatabase={1}mdb,cn=config"
ldap_modify: Insufficient access (50)

Também coloquei o acima em um arquivo e tentei o seguinte:

$ vim pw_reset.ldif
$ sudo ldapmodify -Y EXTERNAL -D 'cn=config' -H ldapi:/// -f ./pw_reset.ldif 
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
modifying entry "olcDatabase={1}mdb,cn=config"
ldap_modify: Insufficient access (50)

Portanto, o problema óbvio aqui é que não importa o que aconteça, parece que não tenho "acesso suficiente", que é o problema aqui. Preciso da senha do administrador para definir a senha do administrador. Qual é a maneira correta de fazer isso?

Eu tenho uma matriz RAID 5 na qual um banco de dados lê e grava pequenas quantidades de dados.

Em circunstâncias normais, as operações do banco de dados, incluindo a confirmação, são executadas em um tempo aceitável. No entanto, quando uma grande quantidade de dados é carregada na matriz RAID (mas não no banco de dados), a confirmação (mas não as outras operações) torna-se inaceitavelmente lenta.

Minha suposição atual é que o commit demora muito porque as informações de paridade precisam ser calculadas e/ou gravadas no disco.

Existe uma maneira de verificar minha suposição, ou seja, existe uma ferramenta que exibe a quantidade de CPU necessária para calcular as informações de paridade e se esse é o gargalo.

Além disso, estou pensando em mudar o array para RAID 10 ou RAID 1. Mas antes de fazer isso, existe uma abordagem científica que me permita estimar se vale a pena o incômodo?

Estou executando o Debian 12 com um RAID de software ( /dev/md/).

Temos um aplicativo da web .aspx de formulários da web herdado instalado em "Site padrão". É possível ativar https: apenas para este aplicativo da web? dado que existem outros aplicativos da web implantados em "Site padrão"

Todas as instruções que encontrei on-line insistem na criação de uma ligação https: no IIS na porta: 443

O desafio é: quero saber se existe alguma outra maneira possível de habilitar https: apenas para aquele aplicativo da web sem impactar os outros aplicativos?

No mundo Windows, você pode pegar uma VM, aplicar todo o seu software e atualizações do Windows a ela e salvá-la como uma nova imagem base no formato .vhd ou iso. Chamamos isso de sysprep, e é ótimo permitir que você implante VMs totalmente atualizadas e seguras na primeira inicialização.

É necessário algum trabalho para criá-los e mantê-los atualizados, mas há uma enorme recompensa na implantação de máquinas seguras.

Este também é um conceito no mundo Linux? em caso afirmativo, quais são as terminologias e tecnologias utilizadas?

Gostaria de desabilitar o uso do TLSv1.3 no apache2 e usar apenas o TLSv1.2

Tentei algumas alterações no arquivo ssl.conf, como:

• Protocolo SSL -todos +TLSv1.2
• Protocolo SSL todos -TLSv1.3
• Protocolo SSL TLSv1.2
• Protocolo SSL todos -SSLv3 -TLSv1.2 -TLSv1.3

e fiz alguns testes com o openssl s_client, todos com o mesmo resultado. O servidor continua aceitando solicitações TLSv1.3 e TLSv1.2.

Não entendo o que está errado ou o que devo configurar.

Contexto: tenho um openstack onde 2 instâncias estão conectadas a uma rede (sub-rede 172.26.20.0/24). Esta rede está conectada a um roteador virtual (gateway 172.26.20.1). O ip da instância 1 é 172.26.20.10, e o outro 172.26.20.20 Dentro dessas duas instâncias, tenho outra interface em outra sub-rede privada (essas interfaces não estão vinculadas a uma rede openstack), respectivamente 10.0.0.1/24 e 10.0.1.1/ 24

O que tento alcançar: gostaria de poder executar ping em 10.0.1.1 da instância 1 e executar ping em 10.0.0.1 da instância 2

Desenho rápido:

|------------------------|                       |-------------------------|
| VM 1                   |                       | VM 2                    |
| eth0 : 172.26.20.10/24 |     GW : 172.26.20.1  | eth0 : 172.26.20.20/24  |
| veth1 : 10.0.0.1/24    |-->| qrouter | -->     | veth1 : 10.0.1.1/24     |
|------------------------|                       |-------------------------|

VM 1 route :
10.0.1.0/24 via 172.26.20.20

VM 2 route :
10.0.0.1/24 via 172.26.20.10

On both VM net.ipv4.ip_forward=1

ping 172.26.20.10 -> 172.26.20.20 ok
ping 172.26.20.20 -> 172.26.20.10 ok
ping 10.0.0.1 -> 10.0.1.1 ko
ping 10.0.1.1 -> 10.0.0.1 ko

On openstack side : 
Router static route :
10.0.1.0/24 via 172.26.20.20
10.0.0.1/24 via 172.26.20.10

Firewall : All ICMP ingress & egress allowed

Acho que estou fechado para ter sucesso, mas não consigo entender o que perdi. Network não é minha especialidade.

Preciso dessa configuração porque preciso implantar um cluster Kubernetes e não consigo fazer a pilha de rede funcionar (o pod pode se comunicar via 172.26.20.0/24, mas não por meio da rede interna 10.0.0.0/16). Espero que esteja claro o suficiente, não hesite em pedir mais precisão/esclarecimentos

Obrigado a todos.