All perguntas(unix)

Fiquei um pouco surpreso pelo fato de um usuário ainda poder ter acesso ssh a uma máquina Linux (Ubuntu 18.04.6 LTS) cuja conta expirou.

Configurei a data de expiração da conta com chage:

sudo chage -l xxxx
Last password change                    : Oct 10, 2024
Password expires                    : never
Password inactive                   : never
Account expires                     : Nov 05, 2024
Minimum number of days between password change      : 0
Maximum number of days between password change      : 99999
Number of days of warning before password expires   : 7

A conta expirou em 2024-11-05, mas o usuário ainda pode acessar ela por SSH.

Existe alguma configuração no servidor sshd ou PAM para impor a expiração da conta?

Até onde sei, o sshd tem UsePAM yesum PAM que deve impedir o login, mas a única coisa que ele faz é imprimir um Your account has expired; please contact your system administratorno banner ssh.

Eu recebo a mesma coisa se eu fizer sudo su xxxx, eu recebo um Your account has expired; please contact your system administratormas recebo o prompt do shell de qualquer maneira.

Tenho dois arquivos, de vários gigabytes de tamanho, que foram compactados com xz. Suspeito que os arquivos originais antes da compactação sejam idênticos, mas eles foram compactados com xzopções diferentes, então os arquivos compactados são diferentes.

Como posso verificar se os arquivos são idênticos sem descompactá-los? Como eles são muito grandes, prefiro não descompactá-los se não for preciso.

Eu sei que ele xzarmazena uma soma de verificação CRC, então pensei que seria fácil o suficiente: basta imprimir e comparar as somas de verificação CRC de cada arquivo. No entanto, o comando xz -l(e xz -l -v) apenas lista a soma de verificação como tipo "CRC64" em vez do que é a soma de verificação real.

O serviço lê sys/devices/virtual/dmi/id/product_serialem algum lugar no início e geralmente contém algum número hexadecimal típico de dez dígitos (por exemplo 01212302C5, ) com nova linha. No entanto, às vezes o conteúdo não é analisável para string - bytes em hexadecimal são f8 6a 32 6d 0ae não consigo descobrir por que e como isso acontece. O último 0aparece sugerir que ainda deveria ser texto. Acontece geralmente em CI, mas não tenho certeza se o ambiente em contêiner pode ser de alguma forma o motivo do problema.

Qual poderia ser a razão de um comportamento tão estranho?

Migrei do Mint para o Fedora, e um script que tenho não está mais funcionando:

wget -t 1 localhost:52199/MCWS/v1/Playback/PlayPause?Zone=-1&ZoneType=ID

retorna

Failed to send 233 bytes (hostname='localhost', ip=::1, errno=111)

O problema é localhost. Posso usar wget para retornar de endereços que não envolvem localhost, como www.google.com . Posso acessar o local em qualquer navegador. Não consigo acessar outros endereços localhost que configurei com SimpleHTTPServer.

Posso chegar lá substituindo "localhost" pelo meu IP inet, mas gostaria de resolver o problema, pois parece ser o tipo de coisa que causará outros problemas.

127.0.0.1:52199/MCWS/v1/Playback/PlayPause?Zone=-1&ZoneType=ID

getent parece retornar o que deveria:

name@fedora:~$ getent hosts
127.0.0.1       localhost localhost.localdomain localhost4 localhost4.localdomain4
127.0.0.1       localhost localhost.localdomain localhost6 localhost6.localdomain6
name@fedora:~$ getent hosts foo.localhost
::1             localhost

Ao olhar o tráfego no Wireshark, notei que meu computador estava enviando um pacote UDP a cada três segundos no endereço de transmissão para a porta 8765, com o conteúdo "*" (42 em ASCII). Não parece ser uma resposta a nada. A porta de origem muda a cada pacote.

Tentei descobrir o que estava emitindo esse pacote, mas não obtive sucesso. Tentei:

• Interrompendo todos os serviços não vitais que eu poderia pensar.
• Adicione uma regra iptables para descartar os pacotes (isso interrompe os pacotes, mas não me ajuda a saber o que os emite).
• Adicionei uma regra do iptables para interromper o encaminhamento e ver se de alguma forma ele foi encaminhado pelo meu computador, mas não.
• Usei auditd com vários parâmetros, mas nada combinou e nem consegui encontrar um write(*,*,1)/send(*,*,1)/sendto(*,*,1,*,*)/sendmsg/sendmmsgcom a frequência certa. No entanto, não estou familiarizado com auditd.
  • auditctl -a exit,always -F arch=b64 -S socket -F a0=2 -F a1=2para procurar a criação de soquetes UDP IPv4.
  • auditctl -a exit,always -F arch=b64 -S connectapenas para procurar por alguma conexão.
  • auditctl -a exit,always -F arch=b64 -S write -S send -S sendto -F a2=1para combinar sende writesyscalls com comprimento de 1.
  • audictl -a exit,always -F arch=b64 -S sendmsg -S sendmmsg
  • Todos os itens acima com -F arch=b32instead.
• Use netstat/ss, mas o soquete provavelmente tem vida curta, então não mostra nada.

Quais são outras maneiras de determinar o que transmite esse pacote? E se ele vier do kernel ou de um módulo do kernel? Como eu poderia saber?

Estou recebendo uma mensagem estranha do Ansible.

Em um servidor RHEL 9, posso ingressar em nosso domínio por meio da linha de comando do shell

realm join example.xyz --user=svc-ansible --computer-ou="OU=Linux Servers, OU=Servers, OU=ACME, OU=Units, DC=example, DC=xyz"

Uma vez feito isso, posso alterar o usuário com sucesso via , onde "johndoe" é um usuário definido no AD e pertencente a um grupo do AD definido no arquivo . Então a configuração parece estar funcionando.su - [email protected]simple_allow_groups/etc/sssd/sssd.conf

Depois disso, executo um realm leave example.xyz --remove -U 'svc-ansible'e realm listpreviamente para verificar se o servidor não está mais no domínio.

No entanto, quando executo via AWX um playbook Ansible definido como este

(...)

- name: Set staging_ou
  ansible.builtin.set_fact:
    staging_ou: "OU=Linux Servers, OU=Servers, OU=ACME, OU=Units, DC=example, DC=xyz"

- name: Realm join into domain
  ansible.builtin.expect:
    command: /bin/bash -c 'realm join {{ domain }} --user={{ ad_join_user }} --computer-ou="{{ staging_ou }}"'
    responses:
      Password.*: "{{ ad_join_password }}"
    timeout: 120

(...)

Recebo o seguinte erro:

TAREFA [playbook_ad_join: Ingresso do reino no domínio] ********************************** fatal: [myrhel9server]: FALHOU! => {"changed": true, "cmd": "/bin/bash -c 'realm join example.xyz --user=svc-ansible --computer-ou="OU=Linux Servers, OU=Servers, OU=ACME, OU=Units, DC=example, DC=xyz"'", "delta": "0:00:00.152467", "end": "2024-11-13 11:45:09.577079", "msg": "código de retorno diferente de zero", "rc": 1, "start": "2024-11-13 11:45:09.424612", "stdout": "realm: Já ingressou neste domínio\r\nVerifique\r\n https://red.ht/support_rhel_ad \r\npara obter ajuda para problemas comuns.", "stdout_lines": ["realm: Já ingressou neste domínio", "Verifique", " https://red.ht/support_rhel_ad ", "para obter ajuda para problemas comuns."]}

A realm listconfirma que o servidor está de fato no domínio example.xyz e retorna a mesma saída de quando executei o realm join ...comando via shell. No entanto, não posso sumais para usuários do AD: tentar fazer isso retorna um erro

su: o usuário [email protected] não existe ou a entrada do usuário não contém todos os campos obrigatórios

O link citado na mensagem de erro não ajuda.

O que pode estar errado?

EDIT 1: Executando via shell o mesmo comando executado via ansible, ou seja

/bin/bash -c 'realm join example.xyz (...) '

não muda nada em relação à corrida realm join example.xyz (...)(veja o topo do post).

As outras tarefas no manual modificam apenas alguns arquivos de configuração:

/etc/krb5.conf
/etc/sssd/sssd.conf
/usr/local/bin/sss_ssh_authorizedkeys_ad
/etc/ssh/sshd_config 

e instalar alguns pacotes. Isso não importa, pois a configuração já convergiu. Eu removi uma linha que reiniciava o realmddaemon, pois poderia ser o que estava causando o problema, mas nada mudou.

Eu quero que ele inicie automaticamente com no-cursor: startx -- -nocursorisso funcionou, mas esse é o comando... Eu quero iniciar automaticamente para o usuário: kiosk... (mas não quero usar "unclutter")

Não entendi onde posso adicionar script ou arquivo configure startx com no-cursor.. .xinitrc? ou outro arquivo configure..

eu uso o opensuse 15.6 com openbox

então eu pergunto aqui, espero encontrar seu código de ajuda.. :-)

obrigado

Por que sysv-rc-conf foi removido dos repositórios Debian? Existe, por exemplo, uma alternativa melhor com uma GUI?

Quando executo, sudo apt-get upgradeo único pacote retido é:

The following packages have been kept back:
  sysv-rc-conf

Quando executo, sudo sysv-rc-confainda consigo configurar serviços de inicialização automática no console. Acho difícil de usar, pois não é uma GUI e tem apenas números inexplicáveis ​​como colunas. No entanto, em vez de remover, gostaria de instalar alguma ferramenta de substituição que também possa configurar serviços de inicialização automática.

Description: SysV init runlevel configuration tool for the terminal
 sysv-rc-conf provides a terminal GUI for managing "/etc/rc{runlevel}.d/"
 symlinks.  The interface comes in two different flavors, one that simply
 allows turning services on or off and another that allows for more fine tuned
 management of the symlinks.  Unlike most runlevel config programs, you can
 edit startup scripts for any runlevel, not just your current one.

Provavelmente tem algo a ver com "orphan-sysvinit-scripts" aparecendo no KDE Discover e Apper para serem instalados (mas sendo instalados ou atualizados durante a atualização).

Criei uma imagem docker com gcco binutils e gdbo debugger instalados dentro.

Eu anexaria gdbdesse contêiner docker a um processo dentro de um lxccontêiner em execução no mesmo host Linux. O lxccontêiner usa seu próprio PIDnamespace, portanto, gdba execução no contêiner docker reclama que o processo de destino e o depurador não estão no mesmo PIDnamespace.

[SR-PCE-251:~]$ docker run -it --pid host --rm --cap-add=SYS_PTRACE --security-opt seccomp=unconfined carlo/ubuntu
root@e7b2db23af34:/#
root@e7b2db23af34:/# id
uid=0(root) gid=0(root) groups=0(root)
root@e7b2db23af34:/# 
root@e7b2db23af34:/# gdb -q attach 11365
attach: No such file or directory.
Attaching to process 11365
[New LWP 24283]
[New LWP 20025]
[New LWP 20024]
[New LWP 19992]
[New LWP 19991]
[New LWP 13974]
[New LWP 13970]
[New LWP 13969]
[New LWP 13968]
[New LWP 13967]
[New LWP 13962]
[New LWP 13958]
[New LWP 13957]
[New LWP 13954]
[New LWP 13952]
[New LWP 13944]
[New LWP 12078]
[New LWP 11822]
[New LWP 11543]
[New LWP 11515]
[New LWP 11489]
[New LWP 11483]
[New LWP 11482]
[New LWP 11477]
[New LWP 11476]

warning: "target:/proc/11365/exe": could not open as an executable file: Operation not permitted.

warning: `target:/proc/11365/exe': can't open to read symbols: Operation not permitted.

warning: Could not load vsyscall page because no executable was specified

warning: Target and debugger are in different PID namespaces; thread lists and other data are likely unreliable.  Connect to gdbserver inside the container.
0x00007f0bf997ac73 in ?? ()
(gdb)

Como posso me livrar disso?

Desde o Fedora 41, o seguinte comando não funciona mais:

$ sudo dnf config-manager --dump
Unknown argument "dump" for command "config-manager".

A lista de alterações entre DNF e DNF5 não menciona essa alteração.

Usando dnf, como você lista todos os valores de configuração dnf?