Instalei o SSSD no SUSE Linux para gerenciar o acesso ao AD. Mas, por algum motivo, o SSSD não inicia após ingressar no AD.

Examinei quase toda documentação disponível.

Alguém pode fornecer orientação sobre qual é a causa por trás disso?

Virtualization: amazon
Operating System: SUSE Linux Enterprise Server 15 SP3
CPE OS Name: cpe:/o:suse:sles:15:sp3
Kernel: Linux 5.3.18-150300.59.170-default
Architecture: x86-64

Status SSSD

● sssd.service - System Security Services Daemon
     Loaded: loaded (/usr/lib/systemd/system/sssd.service; enabled; vendor preset: disabled)
     Active: failed (Result: exit-code) since Tue 2024-08-20 17:47:40 UTC; 30min ago
    Process: 944363 ExecStart=/usr/sbin/sssd -i ${DEBUG_LOGGER} (code=exited, status=3)
   Main PID: 944363 (code=exited, status=3)

Aug 20 17:47:40  systemd[1]: Starting System Security Services Daemon...
Aug 20 17:47:40  sssd[944363]: Starting up
Aug 20 17:47:40  systemd[1]: sssd.service: Main process exited, code=exited, status=3/NOTIMPLEMENTED
Aug 20 17:47:40  systemd[1]: sssd.service: Failed with result 'exit-code'.
Aug 20 17:47:40  systemd[1]: Failed to start System Security Services Daemon.

Tentei o fornecimento fixo no documento abaixo.

https://access.redhat.com/solutions/4948551

ou seja, limpar cache, parar/iniciar serviço, reinstalar SSSD, reinicializar instância, verificar permissão, etc.

Observe que consegui ingressar no AD usando o comando realm join sem erros.

Pacotes SSSD instalados

 sssd-common-1.16.1-150300.23.43.1.x86_64
 sssd-ad-1.16.1-150300.23.43.1.x86_64
 sssd-1.16.1-150300.23.43.1.x86_64
 sssd-ldap-1.16.1-150300.23.43.1.x86_64
 sssd-common-32bit-1.16.1-150300.23.43.1.x86_64
 sssd-krb5-common-1.16.1-150300.23.43.1.x86_64
 sssd-tools-1.16.1-150300.23.43.1.x86_64
 python3-sssd-config-1.16.1-150300.23.43.1.x86_64

Ao tentar executar o daemon SSSD “sssd -d9 -i”

(2024-08-20 18:30:45:189066): [sssd] [main] (0x0400): NSCD socket was detected and it seems to be configured not to interfere with SSSD's caching capabilities
(2024-08-20 18:30:45:189252): [sssd] [check_file] (0x0400): lstat for [/var/run/sssd.pid] failed: [2][No such file or directory].
(2024-08-20 18:30:45:190504): [sssd] [ldb] (0x0400): server_sort:Unable to register control with rootdse!
(2024-08-20 18:30:45:192925): [sssd] [sss_confdb_create_ldif] (0x0400): Processing config section [sssd]
(2024-08-20 18:30:45:193073): [sssd] [sss_confdb_create_ldif] (0x0400): Processing attribute [config_file_version]
(2024-08-20 18:30:45:193132): [sssd] [sss_confdb_create_ldif] (0x4000): config_file_version: 2

(2024-08-20 18:30:45:193191): [sssd] [sss_confdb_create_ldif] (0x0400): Processing attribute [services]
(2024-08-20 18:30:45:193246): [sssd] [sss_confdb_create_ldif] (0x4000): services: nss, pam

(2024-08-20 18:30:45:193298): [sssd] [sss_confdb_create_ldif] (0x0400): Processing attribute [domains]

(2024-08-20 18:30:45:200131): [sssd] [confdb_ensure_files_domain] (0x0100): The implicit files domain is disabled
(2024-08-20 18:30:45:200249): [sssd] [confdb_expand_app_domains] (0x2000):  is not an app domain
(2024-08-20 18:30:45:200375): [sssd] [confdb_get_domain_internal] (0x0400): No enumeration for []!
(2024-08-20 18:30:45:200426): [sssd] [confdb_get_domain_internal] (0x0400): Please note that when enumeration is disabled `getent passwd` does not return all users by design. See sssd.conf man page for more detailed information
(2024-08-20 18:30:45:200524): [sssd] [confdb_get_domain_internal] (0x1000): pwd_expiration_warning is -1
(2024-08-20 18:30:45:200662): [sssd] [become_user] (0x0200): Trying to become user [0][0].
(2024-08-20 18:30:45:200804): [sssd] [become_user] (0x0200): Already user [0].
(2024-08-20 18:30:45:201067): [sssd] [ldb] (0x0400): server_sort:Unable to register control with rootdse!
(2024-08-20 18:30:45): [sssd] [server_setup] (0x0400): CONFDB: /var/lib/sss/db/config.ldb
(2024-08-20 18:30:45): [sssd] [confdb_get_domain_internal] (0x0400): No enumeration for []!
(2024-08-20 18:30:45): [sssd] [confdb_get_domain_internal] (0x0400): Please note that when enumeration is disabled `getent passwd` does not return all users by design. See sssd.conf man page for more detailed information
(2024-08-20 18:30:45): [sssd] [confdb_get_domain_internal] (0x1000): pwd_expiration_warning is -1
(2024-08-20 18:30:45): [sssd] [snotify_watch] (0x2000): Opened inotify fd 0
(2024-08-20 18:30:45): [sssd] [snotify_watch] (0x2000): Opened file watch 1
(2024-08-20 18:30:45): [sssd] [snotify_watch] (0x2000): Opened directory watch 2
(2024-08-20 18:30:45): [sssd] [_snotify_create] (0x0400): Added a watch for /run/netconfig/resolv.conf with inotify flags 0x8D88 internal flags 0x1 using function resolv_conf_inotify_cb after delay 1.0
(2024-08-20 18:30:45): [sssd] [sss_names_init_from_args] (0x0100): Using re [(((?P<domain>[^\\]+)\\(?P<name>.+$))|((?P<name>[^@]+)@(?P<domain>.+$))|(^(?P<name>[^@\\]+)$))].
(2024-08-20 18:30:45): [sssd] [sss_fqnames_init] (0x0100): Using fq format [%1$s@%2$s].
(2024-08-20 18:30:45): [sssd] [sysdb_domain_init_internal] (0x0200): DB File for : /var/lib/sss/db/cache_.ldb
(2024-08-20 18:30:45): [sssd] [sysdb_domain_init_internal] (0x0200): Timestamp file for : /var/lib/sss/db/timestamps_.ldb
(2024-08-20 18:30:45): [sssd] [ldb] (0x0400): asq: Unable to register control with rootdse!
(2024-08-20 18:30:45): [sssd] [sbus_new_server] (0x0020): dbus_server_listen failed! (name=org.freedesktop.DBus.Error.AddressInUse, message=Failed to bindsocket "/var/lib/sss/pipes/private/sbus-monitor": Address already in use)
(2024-08-20 18:30:45): [sssd] [watch_ctx_destructor] (0x2000): Closing inotify fd 0

Por favor ajude.

SSSD precisa ser iniciado e executado ativamente

Antes de ingressar no AD.

Antes de ingressar no AD esse era o erro em /var/log/messages

Aug 21 11:36:34  sssd[1231272]: SSSD couldn't load the configuration database [2]: No such file or directory.
Aug 21 11:36:34  systemd[1]: sssd.service: Main process exited, code=exited, status=4/NOPERMISSION
Aug 21 11:36:34  systemd[1]: sssd.service: Failed with result 'exit-code'.
Aug 21 11:36:34  systemd[1]: Failed to start System Security Services Daemon.
Aug 21 11:38:29  systemd[1]: Starting System Security Services Daemon...
Aug 21 11:38:29  sssd[1231736]: SSSD couldn't load the configuration database [2]: No such file or directory.
Aug 21 11:38:29  systemd[1]: sssd.service: Main process exited, code=exited, status=4/NOPERMISSION
Aug 21 11:38:29  systemd[1]: sssd.service: Failed with result 'exit-code'.
Aug 21 11:38:29  systemd[1]: Failed to start System Security Services Daemon.

REGISTRO SSD

(2024-08-19 17:58:39:605996): [sssd] [confdb_get_domain_internal] (0x0010): Unknown domain [DOMAIN.COM]
(2024-08-19 17:58:39:606017): [sssd] [confdb_get_domains] (0x0010): Error (2 [No such file or directory]) retrieving domain [DOMAIN.COM], skipping!
(2024-08-19 17:58:39:606021): [sssd] [confdb_get_domains] (0x0010): No properly configured domains, fatal error!
(2024-08-19 17:58:39:606025): [sssd] [get_monitor_config] (0x0010): No domains configured.
(2024-08-19 17:58:39:606040): [sssd] [main] (0x0020): SSSD couldn't load the configuration database.
(2024-08-19 18:00:56:624274): [sssd] [confdb_get_domain_internal] (0x0010): Unknown domain [DOMAIN.COM]
(2024-08-19 18:00:56:624299): [sssd] [confdb_get_domains] (0x0010): Error (2 [No such file or directory]) retrieving domain [DOMAIN.COM], skipping!
(2024-08-19 18:00:56:624305): [sssd] [confdb_get_domains] (0x0010): No properly configured domains, fatal error!
(2024-08-19 18:00:56:624310): [sssd] [get_monitor_config] (0x0010): No domains configured.
(2024-08-19 18:00:56:624327): [sssd] [main] (0x0020): SSSD couldn't load the configuration database.
(2024-08-19 18:06:32:560704): [sssd] [main] (0x0010): pidfile exists at /var/run/sssd.pid
(2024-08-21 11:33:08:242025): [sssd] [main] (0x0010): pidfile exists at /var/run/sssd.pid
(2024-08-21 11:36:34:780964): [sssd] [sss_confdb_create_ldif] (0x0020): Attribute 'domains' has empty value, ignoring
(2024-08-21 11:36:34:787373): [sssd] [confdb_expand_app_domains] (0x0010): No domains configured, fatal error!
(2024-08-21 11:36:34:787395): [sssd] [get_monitor_config] (0x0010): Failed to expand application domains
(2024-08-21 11:36:34:787427): [sssd] [get_monitor_config] (0x0010): No domains configured.
(2024-08-21 11:36:34:787456): [sssd] [main] (0x0020): SSSD couldn't load the configuration database.
(2024-08-21 11:38:29:802179): [sssd] [sss_confdb_create_ldif] (0x0020): Attribute 'domains' has empty value, ignoring
(2024-08-21 11:38:29:806933): [sssd] [confdb_expand_app_domains] (0x0010): No domains configured, fatal error!
(2024-08-21 11:38:29:806951): [sssd] [get_monitor_config] (0x0010): Failed to expand application domains
(2024-08-21 11:38:29:806989): [sssd] [get_monitor_config] (0x0010): No domains configured.
(2024-08-21 11:38:29:807013): [sssd] [main] (0x0020): SSSD couldn't load the configuration database.

Permissão de pasta

drwxr-xr-x  3 root   root         62 Aug 21 11:35 sssd

Permissão de arquivo

-rw------- 1 root root 1920 Aug 21 11:35 /etc/sssd/sssd.conf

Configuração SSSD antes de ingressar no AD

[sssd]
config_file_version = 2
services = nss, pam
domains =
# SSSD will not start if you do not configure any domains.
# Add new domain configurations as [domain/<NAME>] sections, and
# then add the list of domains (in the order you want them to be
# queried) to the "domains" attribute below and uncomment it.
; domains = LDAP

[nss]

[pam]

# Example LDAP domain
; [domain/LDAP]
; id_provider = ldap
; auth_provider = ldap
# ldap_schema can be set to "rfc2307", which stores group member names in the
# "memberuid" attribute, or to "rfc2307bis", which stores group member DNs in
# the "member" attribute. If you do not know this value, ask your LDAP
# administrator.
; ldap_schema = rfc2307
; ldap_uri = ldap://ldap.mydomain.org
; ldap_search_base = dc=mydomain,dc=org
# Note that enabling enumeration will have a moderate performance impact.
# Consequently, the default value for enumeration is FALSE.
# Refer to the sssd.conf man page for full details.
; enumerate = false
# Allow offline logins by locally storing password hashes (default: false).
; cache_credentials = true

# An example Active Directory domain. Please note that this configuration
# works for AD 2003R2 and AD 2008, because they use pretty much RFC2307bis
# compliant attribute names. To support UNIX clients with AD 2003 or older,
# you must install Microsoft Services For UNIX and map LDAP attributes onto
# msSFU30* attribute names.
; [domain/AD]
; id_provider = ldap
; auth_provider = krb5
; chpass_provider = krb5
;
; ldap_uri = ldap://your.ad.example.com
; ldap_search_base = dc=example,dc=com
; ldap_schema = rfc2307bis
; ldap_sasl_mech = GSSAPI
; ldap_user_object_class = user
; ldap_group_object_class = group
; ldap_user_home_directory = unixHomeDirectory
; ldap_user_principal = userPrincipalName
; ldap_account_expire_policy = ad
; ldap_force_upper_case_realm = true
;
; krb5_server = your.ad.example.com
; krb5_realm = EXAMPLE.COM

Ambiente Windows Server 2016, nova implantação de RDS com redirecionamento de pasta para um compartilhamento em um servidor de arquivos.

O redirecionamento de pasta é aplicado via GPO nas configurações do usuário.

As configurações definidas para "Documentos" (na verdade, para todas as pastas) são

  Target: Advanced - specify location for individual user groups
  Settings: Grant the user exclusive rights - unchecked
            Move the contents               - unchecked
            Also apply redirection ...      - unchecked

Como nenhum usuário ainda efetuou logon, não haveria conteúdo para copiar, portanto o acima "deveria" fazer sentido.

No entanto, embora crie a área de trabalho e o menu Iniciar, a pasta de documentos não é criada. A pasta de downloads também não foi criada. Curiosamente, ele cria pastas de Imagens, Vídeos e Músicas.

Tentei verificar a configuração "Mover o conteúdo...", mas isso não altera o resultado.

O que FUNCIONA é desabilitar o GPO, permitir que os usuários façam login sem redirecionamento de pasta, depois fazer logoff de todos, habilitar o redirecionamento de pasta com a opção "mover o conteúdo ..." habilitada para todas as pastas. Em seguida, faça com que os usuários façam login novamente - e todas as pastas existirão e serão redirecionadas corretamente.

Mas isso é super impraticável - esta é uma nova implantação e quero o redirecionamento desde o início.

Existem muitos tutoriais por aí e eu li muitos deles, mas nenhum menciona que isso é um problema.

Por que isso está acontecendo e como posso fazer com que o redirecionamento de pasta funcione corretamente desde o início, com todas as pastas, incluindo Documentos, aparecendo?

Tenho um pequeno cluster k3s em minha casa que hospeda alguns sites e aplicativos locais. Na maior parte, consegui organizá-lo para hospedar uma variedade de serviços, mas a funcionalidade LetsEncrypt nunca funcionou muito bem para mim. Quando funcionou, fiquei sem saber por que e com medo de mexer nele para que não quebrasse novamente.

No momento, há dois sites no cluster com suporte a TLS funcionando bem... até há anos, mas agora que estou adicionando um terceiro site, estou enfrentando os mesmos erros que recebia no passado e não tenho ideia do porquê. Espero que alguém aqui possa explicar o que perdi.

O erro parece ser uma reclamação de que quando o URL mágico é solicitado (como determino o URL que está sendo tentado?), eles obtêm HTML em vez da resposta esperada, embora não esteja claro por que está fazendo isso, ou mesmo qual serviço está construindo a resposta.

I0820 17:28:23.398812       1 service.go:43] cert-manager/challenges/http01/selfCheck/http01/ensureService "msg"="found one existing HTTP01 solver Service for challenge resource" "dnsName"="REDACTED.tld" "related_resource_kind"="Service" "related_resource_name"="cm-acme-http-solver-9qp5z" "related_resource_namespace"="my-namespace" "related_resource_version"="v1" "resource_kind"="Challenge" "resource_name"="tls-REDACTED" "resource_namespace"="my-namespace" "resource_version"="v1" "type"="HTTP-01"
E0820 17:28:23.585197       1 sync.go:190] cert-manager/challenges "msg"="propagation check failed" "error"="did not get expected response when querying endpoint, expected \"REDACTED.REDACTED\" but got: <!DOCTYPE html PUBLIC \"-... (truncated)" "dnsName"="REDACTED.tld" "resource_kind"="Challenge" "resource_name"="tls-REDACTED" "resource_namespace"="my-namespace" "resource_version"="v1" "type"="HTTP-01"
I0820 17:28:33.585741       1 pod.go:59] cert-manager/challenges/http01/selfCheck/http01/ensurePod "msg"="found one existing HTTP01 solver pod" "dnsName"="REDACTED.tld" "related_resource_kind"="Pod" "related_resource_name"="cm-acme-http-solver-5gnhm" "related_resource_namespace"="my-namespace" "related_resource_version"="v1" "resource_kind"="Challenge" "resource_name"="tls-REDACTED" "resource_namespace"="my-namespace" "resource_version"="v1" "type"="HTTP-01"
I0820 17:28:33.585898       1 service.go:43] cert-manager/challenges/http01/selfCheck/http01/ensureService "msg"="found one existing HTTP01 solver Service for challenge resource" "dnsName"="REDACTED.tld" "related_resource_kind"="Service" "related_resource_name"="cm-acme-http-solver-9qp5z" "related_resource_namespace"="my-namespace" "related_resource_version"="v1" "resource_kind"="Challenge" "resource_name"="tls-REDACTED" "resource_namespace"="my-namespace" "resource_version"="v1" "type"="HTTP-01"
E0820 17:28:33.600402       1 sync.go:190] cert-manager/challenges "msg"="propagation check failed" "error"="did not get expected response when querying endpoint, expected \"REDACTED.REDACTED\" but got: <!DOCTYPE html PUBLIC \"-... (truncated)" "dnsName"="REDACTED.tld" "resource_kind"="Challenge" "resource_name"="tls-REDACTED" "resource_namespace"="my-namespace" "resource_version"="v1" "type"="HTTP-01"

Todo o aplicativo consiste em um aplicativo web Python, um trabalhador Python, Redis e Nginx, o que resulta em muito YAML. Estou incluindo a marcação que presumo ser relevante para este caso:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
  namespace: my-namespace
spec:
  replicas: 1
  revisionHistoryLimit: 0
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: nginx:alpine
          imagePullPolicy: IfNotPresent
          resources:
            requests:
              memory: 32Mi
              cpu: 125m
            limits:
              memory: 32Mi
              cpu: 125m
          ports:
            - containerPort: 80
          volumeMounts:
            - name: public
              mountPath: "/usr/share/nginx/html"
      volumes:
        - name: public
          persistentVolumeClaim:
            claimName: public

---

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: web
  namespace: my-namespace
  annotations:
    kubernetes.io/ingress.class: traefik
    cert-manager.io/cluster-issuer: letsencrypt
    acme.cert-manager.io/http01-edit-in-place: 'true'
spec:
  rules:
    - host: REDACTED.tld
      http:
        paths:
          - path: /static
            pathType: Prefix
            backend:
              service:
                name:  nginx
                port:
                  number: 8000
          - path: /media
            pathType: Prefix
            backend:
              service:
                name:  nginx
                port:
                  number: 8000
          - path: /
            pathType: Prefix
            backend:
              service:
                name:  web
                port:
                  number: 8000
  tls:
    - secretName: tls
      hosts:
        - REDACTED.tld

---

apiVersion: v1
kind: Service
metadata:
  name: nginx
  namespace: my-namespace
spec:
  selector:
    app: nginx
  ports:
    - port: 8000
      targetPort: 80
      name: tcp

---

apiVersion: v1
kind: Service
metadata:
  name: web
  namespace: my-namespace
spec:
  selector:
    app: web
  ports:
    - port: 8000
      targetPort: 8000
      name: gunicorn

Sinto-me bastante confortável trabalhando com administração Linux "bare metal", mas o Kubernetes ainda parece "mágico" demais para mim. O texto acima foi construído seguindo os tutoriais do K3s Rocks e, como mencionado acima, de alguma forma funciona para dois outros domínios - embora não funcionassem no início e então de alguma forma começaram a funcionar.

Eu apreciaria qualquer sugestão para esse problema, bem como qualquer recomendação sobre como eu poderia/deveria fazer melhor o que foi dito acima.

Problema: Para atividades de suporte técnico, os técnicos devem fazer login nos sistemas do cliente usando credenciais fornecidas pelo cliente, mas precisamos registrar qual técnico está conectado a qual sistema para segurança e conformidade com a ISO.

Configuração atual: configurei hosts bastion ssh (Debian 12) para essas atividades de suporte ao cliente. Reforçamos o acesso aos sistemas do cliente através do(s) bastião(ões); cada técnico possui uma conta no bastião e se autentica por meio de chaves ssh.

O bastião é usado para acesso ssh e web aos sistemas do cliente. O acesso SSH é realizado por meio do recurso de salto SSH (ssh -J) e o acesso à Web é realizado por meio de proxy SSH SOCKS5.

Precisamos registrar cada conexão TCP de saída do bastião com pelo menos o nome de usuário do técnico que iniciou a conexão, o endereço IP de destino e a porta.

Fomos auditados, os logs são ingeridos em um SIEM por meio do RSyslog. A configuração de trabalho atual usa uma configuração auditada simples para registrar conexões:

auditctl -a always, exit -S connect -F success=1

Por algum motivo que ainda não entendi, quando um usuário inicia uma conexão com um sistema do cliente usando o bastião como jumphost, uma consulta DNS é registrada (com atribuição correta do usuário), mas não a conexão real com o host de destino.

Aqui está o que recebo nos logs de auditoria:

Aug 20 15:26:09 bastion1 audisp-syslog: type=SYSCALL msg=audit(**1724167569.113:16994887**): arch=c000003e syscall=42 success=yes exit=0 a0=b a1=7f49a2dfa454 a2=10 a3=7ffe86122474 items=0 ppid=3840918 pid=3840929 auid=1002 uid=1002 gid=1002 euid=1002 suid=1002 fsuid=1002 egid=1002 sgid=1002 fsgid=1002 tty=(none) ses=5005 comm="sshd" exe="/usr/sbin/sshd" subj=unconfined key=(null) ARCH=x86_64 SYSCALL=connect AUID="firstname-lastname" UID="firstname-lastname" GID="firstname-lastname" EUID="firstname-lastname" SUID="firstname-lastname" FSUID="firstname-lastname" EGID="firstname-lastname" SGID="firstname-lastname" FSGID="firstname-lastname"
Aug 20 15:26:09 bastion1 audisp-syslog: type=SOCKADDR msg=audit(**1724167569.113:16994887**): saddr=02000035080808080000000000000000 SADDR={ saddr_fam=inet **laddr=8.8.8.8 lport=53** }
Aug 20 15:26:09 bastion1 audisp-syslog: type=PROCTITLE msg=audit(**1724167569.113:16994887**): proctitle=737368643A20726F646F6C666F2D73616363616E69205B707269765D
Aug 20 15:26:09 bastion1 audisp-syslog: type=EOE msg=audit(**1724167569.113:16994887**):

Esta consulta DNS é registrada, mas não há registro sobre a conexão SSH real.

Em relação ao proxy SOCKS, o auditd não parece ser capaz de fornecer os logs que precisamos, as conexões de saída parecem ser iniciadas pelo usuário sshd.

Alguma sugestão sobre como resolver esse problema?

Obrigado

Minha conexão é perdida quando adiciono uma interface a uma bridge. Aqui eu quero adicionar eno3à bridge kvbr0:

sudo ip link add name kvbr0 type bridge
sudo ip addr del 10.120.224.70/23 dev eno3
sudo ip addr add 10.120.224.70/23 brd + dev kvbr0 
sudo ip link set eno3 master br0
sudo ip link set kvbr0 up

10.120.224.70é o endereço IP do eno3. Depois de executar o acima, não consigo mais fazer ssh neste endereço.

Isto é o que vejo nas interfaces:

kvbr0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1316
        inet 10.120.224.70  netmask 255.255.254.0  broadcast 10.120.225.255
        ether xxxxxx  txqueuelen 1000  (Ethernet)
        RX packets 12920  bytes 791021 (772.4 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 5  bytes 214 (214.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

eno3: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1316
        ether xxxxxx  txqueuelen 1000  (Ethernet)
        RX packets 29895  bytes 2308765 (2.2 MiB)
        RX errors 0  dropped 41  overruns 0  frame 0
        TX packets 1431  bytes 802466 (783.6 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device memory 0x96200000-962fffff

kvbr0tem as configurações de IP anteriores de eno3.

O servidor está executando o Rocky9 com kernel 6.1.

Eu tentei os comandos acima em uma máquina VM executando o Ubuntu, e eu consigo fazer ssh no endereço IP. Há algo que eu deva saber no servidor que possa impedir a conectividade de rede após executar esses comandos?

O servidor tem uma NIC Intel I350. O resumo do produto diz que o adaptador é "sem ponte". Isso pode estar causando o problema que estou vendo?

Digamos que eu possua dois servidores com endereços IPv4 estáticos a.a.a.ae b.b.b.b. Posso executar meus próprios servidores DNS neles, para que eu e meus amigos possamos definir a.a.a.ae b.b.b.bnas configurações de nossos resolvedores, em qualquer lugar do mundo, e ter nossa própria zona raiz DNS de brinquedo, onde podemos registrar quaisquer nomes de domínio que quisermos em qualquer nível , sem nunca depender de registradores? Algo como um DNS interno, mas sem os limites de uma rede privada. Se não, o que exatamente estaria me impedindo?

EDIT: esqueci de mencionar que ambos flutter.example.comprecisam nodejs.example.comestar disponíveis externamente - como site e serviço de API para um aplicativo móvel, respectivamente.

Edição 2: me sinto um pouco bobo, então vou ler sobre proxies reversos. Obrigado.

Eu tenho uma VM Ubuntu20:04LTE no Azure. Eu tenho dois contêineres, um executando Flutter webapp fluttere outro executando um servidor NodeJs api, ambos possuem certificados SSL instalados na máquina host usando Certbot. Ambos os contêineres estão na mesma rede docker padrão chamada bridge.

Digamos que ambos os contêineres possam ser acessados ​​por meio dos seguintes URLs:

flutter.example.comcom endereço IP local 172.17.0.4na porta5556

nodejs.example.comcom endereço IP local 172.17.0.2na porta5000

Quero que meu fluttercontêiner consuma um endpoint apilocalmente por meio da rede host sem precisar usar o https://nodejs.example.com/example/endpoint.

quando entro no meu fluttercontêiner e executo:

curl http://172.17.0.5:5555/status

Recebo uma resposta do apicontêiner, mas quando executo o mesmo comando com httpsem vez de http, recebo o seguinte erro:

OpenSSL/3.3.1: error:0A0000C6:SSL routines::packet length too long

Aqui está meu arquivo conf Nginx paraflutter

server {
  server_name flutter.example.com;

     #access_log  /var/log/nginx/host.access.log  main;

    location / {
        proxy_pass http://localhost:5556; #whatever port your app runs on
        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;
        root   /usr/share/nginx/html;
        index  index.html index.htm;
        #stub_status on;
    }

    listen 443 ssl; # managed by Certbot
    ssl_certificate /etc/letsencrypt/live/flutter.example.com/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/flutter.example.com/privkey.pem; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot

}
server {
    if ($host = flutter.example.com) {
        return 301 https://$host$request_uri;
    } # managed by Certbot


  listen 80;
  server_name flutter.example.com;
    return 404; # managed by Certbot


}

Aqui estão meus arquivos conf do Nginx paraapi

server {
    server_name  nodejs.example.com;

    #access_log  /var/log/nginx/host.access.log  main;

    location / {
        proxy_pass http://localhost:5000; #whatever port your app runs on
        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;
        root   /usr/share/nginx/html;
        index  index.html index.htm;
        #stub_status on;
    }

    
    error_page   500 502 503 504  /50x.html;
    location = /50x.html {
        root   /usr/share/nginx/html;
    }

    

    listen 443 ssl; # managed by Certbot
    ssl_certificate /etc/letsencrypt/live/nodejs.example.com/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/nodejs.example.com/privkey.pem; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot

}

server {
    if ($host = nodejs.example.com) {
        return 301 https://$host$request_uri;
    } # managed by Certbot


    listen       80;
    server_name  nodejs.example.com;
    return 404; # managed by Certbot


}

Pesquisei esse problema específico no Google e não consigo fazê-lo funcionar. As solicitações precisam ser feitas por meio do nome de domínio? Isso significa que eles já estão se comunicando localmente porque tenho o Nginx? O que estou perdendo, estou perdido.

Eu tenho um problema com os vhosts do Apache. Solicitei o redirecionamento de HTTP para HTTPS (5001=http e 5002=https). O problema é que estou enfrentando um redirecionamento de um domínio para outro, mesmo nunca tendo definido essa regra.

Alguém poderia explicar por que isso está acontecendo?

Meus VHosts

<VirtualHost *:80>
    ServerName sub2.domain.com
    ServerAlias www.sub2.domain.com

    Redirect permanent / https://sub2.domain.com/
</VirtualHost>

<VirtualHost *:443>
    DocumentRoot /var/www/sub2_domain
    ServerName sub2.domain.com
    ServerAlias www.sub2.domain.com

    SSLEngine on
    SSLCertificateFile /etc/ssl/certs/domain.crt
    SSLCertificateKeyFile /etc/ssl/private/domain.key

    <Directory /var/www/sub2_domain>
        Options Indexes FollowSymLinks
        AllowOverride All
        Require all granted
    </Directory>

    ErrorLog ${APACHE_LOG_DIR}/domain_error.log
    CustomLog ${APACHE_LOG_DIR}/sub2_domain_access.log combined
</VirtualHost>

<VirtualHost *:5001>
    ServerName sub1.domain.com
    ServerAlias www.sub1.domain.com

        Redirect permanent / https://sub1.domain.com:5002/
</VirtualHost>

<VirtualHost *:5002>
    DocumentRoot /var/www/sub1_domain
    ServerName sub1.domain.com
    ServerAlias www.sub1.domain.com

    SSLEngine on
    SSLCertificateFile /etc/ssl/certs/domain.crt
    SSLCertificateKeyFile /etc/ssl/private/domain.key

    <Directory /var/www/sub1_domain>
        Options Indexes FollowSymLinks
        AllowOverride All
        Require ip 192.168.1.0/24
    </Directory>

    ErrorLog ${APACHE_LOG_DIR}/domain_error.log
    CustomLog ${APACHE_LOG_DIR}/sub1_domain_access.log combined
</VirtualHost>

Exibição do Apache

VirtualHost configuration:
*:5001                 sub1.domain.com (/etc/apache2/sites-enabled/sub1_domain.conf:1)
*:5002                 sub1.domain.com (/etc/apache2/sites-enabled/sub1_domain.conf:8)
*:80                   sub2.domain.com (/etc/apache2/sites-enabled/sub2_domain.conf:1)
*:443                  sub2.domain.com (/etc/apache2/sites-enabled/sub2_domain.conf:8)
ServerRoot: "/etc/apache2"
Main DocumentRoot: "/var/www/html"
Main ErrorLog: "/var/log/apache2/error.log"
Mutex watchdog-callback: using_defaults
Mutex ssl-stapling-refresh: using_defaults
Mutex fcgid-proctbl: using_defaults
Mutex ssl-stapling: using_defaults
Mutex proxy: using_defaults
Mutex ssl-cache: using_defaults
Mutex default: dir="/var/run/apache2/" mechanism=default
Mutex mpm-accept: using_defaults
Mutex fcgid-pipe: using_defaults
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

Minha solicitação cUrl

C:\Users\user>curl -sv -o nul sub1.domain.com
* Host sub1.domain.com:80 was resolved.
* IPv6: (none)
* IPv4: 192.168.1.201
*   Trying 192.168.1.201:80...
* Connected to sub1.domain.com (192.168.1.201) port 80
> GET / HTTP/1.1
> Host: sub1.domain.com
> User-Agent: curl/8.7.1
> Accept: */*
>
< HTTP/1.1 301 Moved Permanently
< Date: Sat, 17 Aug 2024 19:31:10 GMT
< Server: Apache/2.4.61 (Debian)
< Location: https://sub2.domain.com/
< Content-Length: 328
< Content-Type: text/html; charset=iso-8859-1
<
{ [328 bytes data]
* Request completely sent off
* Connection #0 to host sub1.domain.com left intact

Obrigado

Eu tenho o seguinte arquivo .conf para nginx. Estou configurando a autenticação junto com um cookie.

Quando insiro a URL da página de login, ela não mostra o prompt para inserir credenciais e entra em um loop de redirecionamento infinito.

Achei que poderia separar a lógica de redirecionamento para outro bloco, mas não consigo encontrar uma maneira de pular para o bloco /login/redirection.

Tentei usar try_files, mas não funcionou.

O que posso fazer para garantir que o prompt de login sempre apareça?

http {
include       mime.types;
default_type  application/octet-stream;

#log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
#                  '$status $body_bytes_sent "$http_referer" '
#                  '"$http_user_agent" "$http_x_forwarded_for"';

#access_log  logs/access.log  main;

sendfile        on;
#tcp_nopush     on;

#keepalive_timeout  0;
keepalive_timeout  65;

#gzip  on;

server {
    listen 80;
    server_name localhost;

    location / {
        # Check if the user is authenticated by looking for the cookie
        if ($http_cookie !~ 'openhab_cookie=loggedin') {
            # Redirect to the login page if not authenticated
            return 302 http://localhost:81/login;
        }

        # If the user is authenticated, proceed to the application
        proxy_pass http://localhost:8080;
        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-Proto $scheme;
    }

    error_page 500 502 503 504 /50x.html;
    location = /50x.html {
        root html;
    }
}

server {
    listen 81;
    server_name localhost;

    location /login {
        # authentication (issue in here, it is skipped)
        auth_basic "Login Required";
        auth_basic_user_file /etc/nginx/.htpasswd;

        # Only set cookie if authenticated
        if ($http_cookie !~* "openhab_cookie=loggedin") {
            add_header Set-Cookie "openhab_cookie=loggedin; Max-Age=300; Path=/; HttpOnly";
        }

        return 302 http://localhost:80/;
    }

}

Tenho um infisical standalone em execução no meu cluster do Kubernetes e gostaria de usar o External Secrets Operator para sincronizar os segredos do infisical com os segredos do Kubernetes.

Vou mostrar muitas chaves e URLs, mas embora eu as esteja usando, elas são para fins de teste e serão substituídas assim que eu conseguir resolver o problema. Para facilitar a visualização do que é o quê (e detectar quaisquer erros, se houver), vou colocá-las aqui:

• ID do cliente: 971d8c5d-08bf-4e14-810b-901b0618b4ed
• clienteSecret: b4909f4856392612a666c0e06bb9c3c16164ff85f290f79b8e6bb692e6f95c13
• URL infisical: http://infisical-infisical-standalone-infisical.infisical.svc.cluster.local:8080
• id do projeto infisical (o projeto stb): 01630159-214a-49b8-97a2-e566b23fe3ac

O infisical está sendo executado em seu próprio namespace (infisical) e tem um projeto chamado stb com um segredo chamado TEST em todos os três ambientes padrão (Desenvolvimento, Preparação e Produção).

Do namespace stb, consigo usar um pod curl temporário para obter os segredos do infisical usando as credenciais que dei a ele. Então, tenho a confirmação de que a identidade da máquina, a url e a autenticação funcionam como visto aqui (usando a seguinte documentação https://infisical.com/docs/api-reference/endpoints/universal-auth/login ):

kubectl run curl-pod --rm -i --tty --image=curlimages/curl --namespace stb -- /bin/sh

curl --request POST --url http://infisical-infisical-standalone-infisical.infisical.svc.cluster.local:8080/api/v1/auth/universal-auth/login --header 'Content-Type: application/json' --data '{"clientId": "971d8c5d-08bf-4e14-810b-901b0618b4ed", "clientSecret": "b4909f4856392612a666c0e06bb9c3c16164ff85f290f79b8e6bb692e6f95c13"}'

Isso tem a seguinte saída (então access + auth funcionam):

{
   "accessToken":"eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpZGVudGl0eUlkIjoiMTY2YTg3OWYtNmY4YS00YzZmLWExNGItZDJiMzNhMGU0YTg5IiwiY2xpZW50U2VjcmV0SWQiOiIxZTNlODc4NS1kNTc2LTQzZjctOTJmOS1mOWZlODAyNzdkOWQiLCJpZGVudGl0eUFjY2Vzc1Rva2VuSWQiOiIxODUxNzJjZi1kMmM3LTRhYzMtOGI5OS1jNjVmNjRmZTNiZTciLCJhdXRoVG9rZW5UeXBlIjoiaWRlbnRpdHlBY2Nlc3NUb2tlbiIsImlhdCI6MTcyMzkxNjkxMSwiZXhwIjoxNzI2NTA4OTExfQ.Sdc0xlsvB8DIbOaJ__M3jGMlVBKPtPsU4cqwoL-a12I",
   "expiresIn":2592000,
   "accessTokenMaxTTL":2592000,
   "tokenType":"Bearer"
}

Usando o token, agora posso obter os segredos https://infisical.com/docs/api-reference/endpoints/secrets/list (o ID do espaço de trabalho e o ambiente desejado são consultados na URL):

curl --request GET --url "http://infisical-infisical-standalone-infisical.infisical.svc.cluster.local:8080/api/v3/secrets/raw?workspaceId=01630159-214a-49b8-97a2-e566b23fe3ac&environment=dev" --header 'Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpZGVudGl0eUlkIjoiMTY2YTg3OWYtNmY4YS00YzZmLWExNGItZDJiMzNhMGU0YTg5IiwiY2xpZW50U2VjcmV0SWQi
OiIxZTNlODc4NS1kNTc2LTQzZjctOTJmOS1mOWZlODAyNzdkOWQiLCJpZGVudGl0eUFjY2Vzc1Rva2VuSWQiOiIxODUxNzJjZi1kMmM3LTRhYzMtOGI5OS1jNjVmNjRmZTNiZTciLCJhdXRoVG9rZW5UeXBlIjoiaWRlbnRpdHlBY2Nlc3NUb2tlbiIsImlhdCI6MTcyMzkxNjkxMSwiZXhwIjoxNzI2NTA4OTExfQ.Sdc0xlsvB8DIbOaJ__M3jGMlVBKPtPsU4cqwoL-a12I'

Por sua vez, recebo a lista secreta:

{
   "secrets":[
      {
         "id":"94bf8823-227c-45e8-a8a9-bbe613069020",
         "_id":"94bf8823-227c-45e8-a8a9-bbe613069020","workspace":"01630159-214a-49b8-97a2-e566b23fe3ac",
         "environment":"dev",
         "version":2,
         "type":"shared",
         "secretKey":"TEST",
         "secretValue":"this is a test that I whant to see the value of dev",
         "secretComment":""
      }
   ],
   "imports":[]
}

Estou mostrando tudo isso para mostrar que o infisical foi configurado da forma que eu acho que está correto, pois posso acessá-lo, consultá-lo e obter o segredo. Estou batalhando com o External Secrets Operator.

Aqui está a configuração que está sendo usada (seguindo a documentação https://external-secrets.io/latest/provider/infisical/ ):

apiVersion: v1
kind: Secret
metadata:
  name: universal-auth-credentials
  namespace: stb
type: Opaque
stringData:
  clientId: "971d8c5d-08bf-4e14-810b-901b0618b4ed"
  clientSecret: "b4909f4856392612a666c0e06bb9c3c16164ff85f290f79b8e6bb692e6f95c13"
---
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: infisical-managed-secrets
  namespace: stb
spec:
  secretStoreRef:
    kind: SecretStore
    name: infisical
  target:
    name: infisical-managed-secrets
  data:
    - secretKey: TEST
      remoteRef:
        key: TEST
---
apiVersion: external-secrets.io/v1beta1
kind: SecretStore
metadata:
  name: infisical
  namespace: stb
spec:
  provider:
    infisical:
      auth:
        universalAuthCredentials:
          clientId:
            key: clientId
            namespace: stb
            name: universal-auth-credentials
          clientSecret:
            key: clientSecret
            namespace: stb
            name: universal-auth-credentials
      secretsScope:
        projectSlug: "01630159-214a-49b8-97a2-e566b23fe3ac"
        environmentSlug: dev
        secretsPath: /
      hostAPI: http://infisical-infisical-standalone-infisical.infisical.svc.cluster.local:8080

O problema, no entanto, parece ser que há um valor ausente ou um valor que não é fornecido como pretendido. Os logs do pod de segredos externos mostram o seguinte (há dois logs diferentes que se repetem muito):

"ID do ambiente ou do espaço de trabalho ausente"

{
   "level":"error",
   "ts":1723917674.332734,
   "logger":"controllers.ExternalSecret",
   "msg":"could not get secret data from provider",
   "ExternalSecret":
      {
         "name":"infisical-managed-secrets",
         "namespace":"stb"
      },
   "error":"error retrieving secret at .data[0], key: TEST, err: Missing workspace id or environment",
   "stacktrace":"github.com/external-secrets/external-secrets/pkg/controllers/externalsecret.(*Reconciler).markAsFailed\n\t/home/runner/work/external-secrets/external-secrets/pkg/controllers/externalsecret/externalsecret_controller.go:357\ngithub.com/external-secrets/external-secrets/pkg/controllers/externalsecret.(*Reconciler).Reconcile\n\t/home/runner/work/external-secrets/external-secrets/pkg/controllers/externalsecret/externalsecret_controller.go:226\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Reconcile\n\t/home/runner/go/pkg/mod/sigs.k8s.io/[email protected]/pkg/internal/controller/controller.go:114\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).reconcileHandler\n\t/home/runner/go/pkg/mod/sigs.k8s.io/[email protected]/pkg/internal/controller/controller.go:311\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).processNextWorkItem\n\t/home/runner/go/pkg/mod/sigs.k8s.io/[email protected]/pkg/internal/controller/controller.go:261\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Start.func2.2\n\t/home/runner/go/pkg/mod/sigs.k8s.io/[email protected]/pkg/internal/controller/controller.go:222"
}
{
   "level":"error",
   "ts":1723917674.33634,
   "msg":"Reconciler error",
   "controller":"externalsecret",
   "controllerGroup":"external-secrets.io",
   "controllerKind":"ExternalSecret",
   "ExternalSecret":
      {
         "name":"infisical-managed-secrets",
         "namespace":"stb"
      },
   "namespace":"stb",
   "name":"infisical-managed-secrets",
   "reconcileID":"dac2f36a-5128-416f-929b-dd7ca11511d5",
   "error":"error retrieving secret at .data[0], key: TEST, err: Missing workspace id or environment",
   "stacktrace":"sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).reconcileHandler\n\t/home/runner/go/pkg/mod/sigs.k8s.io/[email protected]/pkg/internal/controller/controller.go:324\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).processNextWorkItem\n\t/home/runner/go/pkg/mod/sigs.k8s.io/[email protected]/pkg/internal/controller/controller.go:261\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Start.func2.2\n\t/home/runner/go/pkg/mod/sigs.k8s.io/[email protected]/pkg/internal/controller/controller.go:222"
}

Estou perdido, a documentação não mostra nada que me permita resolver o problema e estou confuso se encontrei um bug, um problema com a documentação ou se simplesmente esqueci algo.