einpoklum's questions

Em um script que estou escrevendo, quero criar algo temporário no meu sistema de arquivos, mas não está lá, /tmpmas em outro lugar, e pode não ser um arquivo nem um diretório (por exemplo, talvez seja um pipe nomeado ou um link simbólico). A questão é que terei que criar tudo sozinho. Agora, quero usar um nome de arquivo exclusivo para o meu temporário, para que futuras invocações do utilitário, além de qualquer outro código em execução, não tentem usar o mesmo nome.

Se eu estivesse apenas criando um arquivo ou diretório temporário em /tmp, eu poderia usar mktemp. Mas o que eu faço quando quero apenas gerar o nome?

Em um sistema SLES 15 SP1, adicionei um usuário ao wheelgrupo:

wheel:x:1003:joeuser

no entanto, quando joeuserloga como eles mesmos, então tenta su(se tornar root), eles são solicitados a digitar sua senha. Por que isso pode estar acontecendo?

Aqui está /etc/pam.d/su:

#%PAM-1.0
auth     sufficient     pam_wheel.so trust
auth     sufficient     pam_rootok.so
auth     include        common-auth
account  sufficient     pam_rootok.so
account  include        common-account
password include        common-password
session  include        common-session
session  optional       pam_xauth.so

Fundo

A convenção Unix e o padrão Linux Filesystem Hierarchy definem vários caminhos sob os quais os processos procuram por certas informações, ou usam para escrever certas informações. Quando alguém precisa configurar um ambiente específico do usuário, como um usuário não root - a maioria desses locais são inacessíveis, ou legíveis, mas sem a capacidade de escrever em arquivos ou criar novos. Então, alguém deve usar alternativas.

Em princípio, poderíamos tratar o diretório inicial de um usuário como outro /; no entanto, isso não é uma prática comum.

Também existe o costume de criar um $HOME/.my_appdiretório. A maioria dos aplicativos que os criam os usam para configuração, mas alguns também para outros tipos de dados (Eclipse, Firefox, Thunderbird vêm à mente como esconder montes de dados ali). Mas isso significa que podemos ter dezenas, se não centenas, .somethingno diretório home, o que é bastante indecoroso.

Por fim, também se tornou comum para alguns aplicativos gravar em $HOME/.locale $HOME/.config, o que não "suja" o diretório inicial em si: $HOME/.configpode ser visto como um equivalente de /etce $HOME.localde /usr; portanto, bastante útil, mas - não abrange /vare seus subdiretórios.

Pergunta atual

Onde, sob o diretório home de um usuário, nós, ou um programa que escrevemos, deveríamos armazenar os dados que um programa de nível de sistema armazenaria em /var, ou subdiretórios de /var? Ou seja: "arquivos cujo conteúdo deve mudar continuamente durante a operação normal do sistema, como logs [e] arquivos de spool..." (para citar o FHS), bem como cache, bancos de dados não estáticos, arquivos de bloqueio, arquivos de execução e arquivos de log?

Suponha que estou em uma máquina Linux, em uma sessão shell, e desejo obter a lista de opções que teria se fizesse login graficamente e tivesse que escolher um ambiente de desktop/tipo de sessão. Espero uma lista com itens como "kde", "gnome", "xfce4", "canela" etc.

Notas:

• Eu esperaria uma solução independente de distribuição, mas se você precisa conhecer a distribuição - suponha que seja baseada em RHEL ou Centos.
• Não sou exigente quanto ao esquema de nomenclatura exato, os nomes podem ser mais longos/curtos, um por linha ou outro, isso realmente não importa.

Estou trabalhando em uma máquina Linux sem acesso (direto) à Internet. Eu quero pip install fooalgum pacote pypi foo, mas - obviamente, isso não funcionará. Tenho, claro, outras máquinas que estão conectadas à Internet.

Como eu determinaria quais arquivos precisam ser baixados, baixando-os e instalando-os quando estiverem na máquina isolada?

Notas:

• Prefiro obter uma resposta independente da versão do Python, mas se for dependente da versão, vamos assumir o Python 3.6 ou posterior.
• Esta pergunta parece a mesma, mas na verdade trata-se da instalação do próprio pip.

Estou escrevendo um script envolvendo um determinado comando do Linux. Agora, esse comando, quando eu o uso diretamente na linha de comando, tem algum comportamento de preenchimento automático. Por exemplo, se eu digitar o nome do comando, depois espaço, depois uma string e pressionar Tab - ele será concluído no nome de um executável no caminho. No entanto, o script wrapper não parece ter esse comportamento. Como posso fazer com que o bash use o mesmo preenchimento automático para meu wrapper e para o comando original?

Para tornar as coisas mais concretas: O comando é which. Estou escrevendo um wrapper que o invoca e, se não falhar, é executado readlink -fno resultado de which. Gostaria que o preenchimento automático encontrasse o executável no caminho, como acontece com o which.

O findprograma possui uma -quitopção cmdline, que diz para ele sair imediatamente após encontrar uma correspondência e executar comandos especificados anteriormente (como -print). Isso é muito útil, mas e se eu estiver findem vários diretórios raiz e quiser a primeira correspondência em cada uma das raízes?

Existe uma maneira de dizer algo como:

find foo bar baz -print -continue-with-next-root

? Alguns códigos de shell estão ok, mas eu gostaria de evitar uma findinvocação separada para cada pasta raiz.

Em distribuições do tipo Debian/baseadas em apt, em vez de instalar o Python empacotado em todo o sistema com pip install --system, usamos pacotes APT. Aqui:

Instale um pacote Python no Debian/Devuan quando o apt não tiver nenhum pacote para ele

é uma discussão sobre como fazer isso. Infelizmente, isso falha quando tento com o pacote gdown :

# mkdir /tmp/gdown
# cd /tmp/gdown
# py2dsp --build gdown
W: py2dsp cache:67: cannot load cache (_load_package_names:():{}): unpackb() got an
unexpected keyword argument 'encoding'
E: py2dsp py2dsp:172: 'build-system'

isso é um bug do py2dsp? De alguma forma, um problema com meu próprio sistema?

Suponha que eu queira instalar um pacote Python em todo o sistema em um sistema Debian/Devuan. Alguns pacotes PyPI têm pacotes DEB disponíveis através das fontes apt do repositório, com nomes de pacotes prefixados por python3-(ou python-, dependendo da versão Debian). Mas - nem todos o fazem. Agora, sempre posso lançar meu próprio pacote DEB , mas - como posso saber se meu pacote de interesse é:

• realmente faltando;
• disponível, mas com outro nome (formato mais curto, formato mais longo, nome tradicional agora alterado no PyPI etc.); ou
• disponível, mas empacotado com outros pacotes PyPI

? Existe uma regra de mapeamento simples ou algum lugar que eu possa consultar com um nome de pacote PyPI e obter o nome do pacote apt?

Quero instalar alguns pacotes Python pandasqlem todo o sistema, em um sistema Devuan (ou Debian). Está no Índice de Pacotes Python, mas - não parece haver um pacote (dpkg) para ele; vamos supor que realmente não exista.

Agora, se eu tentar pip install pandasql, recebo uma mensagem sugerindo que eu use um ambiente virtual:

× This environment is externally managed
╰─> To install Python packages system-wide, try apt install
    python3-xyz, where xyz is the package you are trying to
    install.
    
    If you wish to install a non-Debian-packaged Python package,
    create a virtual environment using python3 -m venv path/to/venv.
    Then use path/to/venv/bin/python and path/to/venv/bin/pip. Make
    sure you have python3-full installed.
    
    If you wish to install a non-Debian packaged Python application,
    it may be easiest to use pipx install xyz, which will manage a
    virtual environment for you. Make sure you have pipx installed.
    
    See /usr/share/doc/python3.11/README.venv for more information.

... mas ambientes virtuais não são o que eu quero fazer: quero instalar fooem todo o sistema. Como eu posso fazer isso?

Notas :

• Se possível, responda de forma mais geral do que apenas em relação a pandasql?
• Devuan Excalibur (~= Debian Trixie), Python 3.11.6, máquina x86_64

(Esta não é uma pergunta "qual distribuição é melhor"!)

GNU GUIX e NixOS são duas distribuições Linux baseadas no gerenciador de pacotes NixOS.

Percebo que o GUIX parece usar o Guile para definir pacotes/dependências ou outros usos de metadados; e acho que tudo no GUIX é GPL, embora talvez nem tudo no NixOS seja ... mas essas parecem mais diferenças superficiais.

O que espero entender é se essas duas distribuições têm diferenças arquitetônicas significativas.

Comprei e conectei um adaptador WiFi USB, um UGreen AC650 . É suposto suportar Linux 5.x...

bem, lsusb diz:

Bus 001 Device 038: ID 0bda:c811 Realtek Semiconductor Corp. 802.11ac NIC

Então, até certo ponto, é reconhecido. No entanto, não aparece com ip link show.

Eu executei o wireless-info-script, e os resultados estão aqui ; mas observe que meu sistema tem outro adaptador wifi, on-board, que está funcionando bem (mas não utilizado); e uma conexão Ethernet ativa, portanto, não confunda esses ( eth0, wlan0) com o adaptador USB WiFi ausente.

Minha pergunta: Posso obter o adaptador USB WiFi totalmente reconhecido e configurado? Se sim, como?

Eu prefiro usar a linha de comando para isso. Vou mencionar que por alguns anos eu me acostumei a redes wi-fi "apenas trabalhando", e não lembro mais o que fazer com ip, iwliste amigos. (Eu tenho o gerenciador de rede canela, mas mais tarde pretendo usar este adaptador em outras máquinas que não terão isso.)

Também devo mencionar que este dongle USB tem o que parece ser uma luz indicadora - mas não acende.

cauda de /var/log/messages:

Mar 20 09:25:27 myhostname kernel: [292007.468991] usb 1-9: new high-speed USB device number 48 using xhci_hcd
Mar 20 09:25:27 myhostname kernel: [292007.617381] usb 1-9: New USB device found, idVendor=0bda, idProduct=c811, bcdDevice= 2.00
Mar 20 09:25:27 myhostname kernel: [292007.617387] usb 1-9: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Mar 20 09:25:27 myhostname kernel: [292007.617391] usb 1-9: Product: 802.11ac NIC
Mar 20 09:25:27 myhostname kernel: [292007.617394] usb 1-9: Manufacturer: Realtek
Mar 20 09:25:27 myhostname kernel: [292007.617396] usb 1-9: SerialNumber: 123456
Mar 20 09:25:27 myhostname mtp-probe: checking bus 1, device 48: "/sys/devices/pci0000:00/0000:00:14.0/usb1/1-9"
Mar 20 09:25:27 myhostname mtp-probe: bus: 1, device: 48 was not an MTP device
Mar 20 09:25:27 myhostname mtp-probe: checking bus 1, device 48: "/sys/devices/pci0000:00/0000:00:14.0/usb1/1-9"
Mar 20 09:25:27 myhostname mtp-probe: bus: 1, device: 48 was not an MTP device

cauda de dmesg:

Mar20 09:25] usb 1-9: new high-speed USB device number 48 using xhci_hcd
[  +0.148390] usb 1-9: New USB device found, idVendor=0bda, idProduct=c811, bcdDevice= 2.00
[  +0.000006] usb 1-9: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  +0.000004] usb 1-9: Product: 802.11ac NIC
[  +0.000003] usb 1-9: Manufacturer: Realtek
[  +0.000002] usb 1-9: SerialNumber: 123456

Estou trabalhando em um sistema CentOS 7.9 GNU/Linux. Eu construí e instalei uma versão mais recente do git (2.34.1 em vez de 1.8.3.1 que vem junto com a distribuição) em /opt/git/2.34.1, com um link simbólico para esse diretório em /opt/git/current; e adicionei esse diretório com link simbólico (no início de) minha $PATHvariável.

Infelizmente, quando tento fazer o checkout de um repositório com uma URL HTTPS, recebo alguns erros

$ git clone https://github.com/eyalroz/cuda-api-wrappers.git
Cloning into 'cuda-api-wrappers'...
git: 'remote-https' is not a git command. See 'git --help'.

clonagem com a versão antiga do git - funciona.

Por que isso acontece e o que posso fazer para resolver?

Estou usando o SLES 2015. Quero tornar a associação ao grupo wheel suficiente para acesso com privilégios de root via su.

Nas distribuições Debian, estou acostumado a descomentar o comando:

auth       sufficient pam_wheel.so trust

em /etc/pam.d/su. Mas - isso não existe no /etc/pam.d/suarquivo do SLES. Entrei manualmente, após os outros authcomandos, mas - não funciona. Também fiz o mesmo /etc/pam.d/su-lpara uma boa medida, mas sem ajuda.

O que devo fazer para evitar a verificação de senha?

Notas:

• Não estou interessado sudonesse aspecto.
• Eu tenho acesso root à máquina, obviamente.

Estou usando o CentOS 8 (build 1905) em alguma máquina e gostaria de instalar o CUDA nela. Parece que além de um download manual de RPM, há também um repositório YUM - para RedHat Enterprise Linux (RHEL) 8, não CentOS 8: este .

Posso usá-lo com segurança como um repositório para minha instalação do CentOS? Usá-lo, mas com certas ressalvas/problemas? Ou - não usá-lo em tudo?

Acabei de instalar o CentOS GNU/Linux (versão 8 build 1905) em uma máquina; esta não foi a minha escolha de distribuição - eu mesmo sou um homem Debian.

De qualquer forma, quando eu faço SSH nesta máquina (como um usuário não root), ele me diz:

Ative o console web com: systemctl enable --now cockpit.socket

O que este console web terá? Em qual porta ele escutará e para quem? Os usuários não root podem simplesmente ativá-lo quando quiserem? Estou um pouco confuso com isso, pois não estou acostumado com o CentOS.

Meu syslog está repleto do seguinte:

Oct 28 23:35:01 myhost CRON[17705]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1)
Oct 28 23:45:01 myhost CRON[18392]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1)

e também alguns

Oct 28 23:59:01 myhost CRON[19251]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 60 2)

Agora, obviamente, eles vêm de cron jobs, em /etc/cron.d/sysstat:

# Activity reports every 10 minutes everyday
5-55/10 * * * * root command -v debian-sa1 > /dev/null && debian-sa1 1 1

# Additional run at 23:59 to rotate the statistics file
59 23 * * * root command -v debian-sa1 > /dev/null && debian-sa1 60 2

Preciso fazer isso com tanta frequência? Não parece fazer muito quando eu o executo manualmente. Posso/devo apenas desligar o cron job ou desinstalar o sysstat?

Ao inicializar meu sistema, recebo a seguinte mensagem:

[Sat Oct 26 20:34:25 2019] Calgary: detecting Calgary via BIOS EBDA area
[Sat Oct 26 20:34:25 2019] Calgary: Unable to locate Rio Grande table in EBDA - bailing!

• O que é "Calgary"?
• O que é a "mesa Rio Grande"?
• Por que ele precisa estar localizado no EBDA e, dado que precisa - por que meu kernel está falhando em fazê-lo?
• Quais são as consequências dessa falha?

Estou executando o Devuan 3 (Beowulf) em uma CPU i5-7600K em uma placa-mãe MSI Z170 PRO GAMING.

Quando executo aplicativos X a partir da linha de comando (por exemplo, leafpad; a maioria dos aplicativos), recebo o seguinte aviso no console:

 ... dbind-WARNING **: ... Couldn't register with accessibility bus: Did
not receive a reply. Possible causes include: the remote application did 
not send a reply, the message bus security policy blocked the reply, the 
reply timeout expired, or the network connection was broken.

(linha quebrada para ajustar a largura da coluna.)

Por que estou recebendo esta mensagem e o que posso fazer a respeito? Os aplicativos que o emitem parecem estar funcionando bem.

Isso aparece no Ubuntu 18.04 e no Devuan 3.0 Beowulf (~= Debian Buster)

Para o Debian, você pode obter imagens do instalador ISO geradas semanalmente da versão de "teste" atual, aqui . Mas para o Devuan, só consegui encontrar imagens de instalação para as versões estável e oldstable ( aqui ).

Existem imagens de instalação do Devuan "testing" em algum lugar?

_{No momento, isso seria o Devuan 3.0 "Beowulf".}