onde colocar binários para que eles estejam sempre no caminho e possam ser encontrados facilmente


10

Estou fazendo alguns binários, scripts etc. que quero instalar facilmente (usando meus próprios rpms). Como eu os quero acessíveis a todos, minha intuição seria colocá-los em / usr / bin;

  • não há necessidade de alterar PATH

Contudo; meus executáveis ​​agora desaparecem em um pool de todos os outros; como posso encontrar de volta todos os executáveis ​​que coloquei lá de uma maneira fácil. Eu estava pensando em:

  • um subdiretório em / usr / bin (eu sei que não posso fazer isso; apenas para ilustrar meu pensamento)
  • outro diretório (/ opt / eu / bin) e vinculando cada executável a / usr / bin (muito trabalho)
  • outro diretório (/ opt / eu / bin) e vincular o diretório a / usr / bin (isso é possível?)

qual seria a "maneira melhor e mais compatível com o Linux" de fazer isso?

EDIT: tivemos uma discussão sobre isso na empresa e surgiu essa opção abaixo do ideal: colocar binários em / usr / bin / company com um link simbólico de / usr / bin. Não estou empolgado com esta solução (discussão em andamento)

Respostas:


7

Se você agrupar seus binários em seus próprios RPMs, será trivial obter uma lista do que eles são e de onde foram instalados.

Exemplo

$ rpm -ql httpd| head -10
/etc/httpd
/etc/httpd/conf
/etc/httpd/conf.d
/etc/httpd/conf.d/README
/etc/httpd/conf.d/autoindex.conf
/etc/httpd/conf.d/userdir.conf
/etc/httpd/conf.d/welcome.conf
/etc/httpd/conf.modules.d
/etc/httpd/conf.modules.d/00-base.conf

Eu sugeriria colocar seus executáveis ​​em um /usr/binou outro /usr/local/bine rodar seu próprio RPM. É bastante trivial fazer isso e, gerenciando a implantação do software usando um RPM, você poderá rotular um pacote com um número de versão, facilitando ainda mais o gerenciamento da configuração do software à medida que o implanta.

Determinando quais RPMs são "meus"?

Você pode criar seus RPMs usando algumas informações conhecidas que poderiam ser acordadas antes da construção. Costumo criar pacotes em sistemas que pertencem ao meu domínio, por isso é trivial encontrar RPMs simplesmente pesquisando todos os RPMs criados no host X.mydom.com.

Exemplo

$ rpm -qi httpd
Name        : httpd
Version     : 2.4.7
Release     : 1.fc19
Architecture: x86_64
Install Date: Mon 17 Feb 2014 01:53:15 AM EST
Group       : System Environment/Daemons
Size        : 3865725
License     : ASL 2.0
Signature   : RSA/SHA256, Mon 27 Jan 2014 11:00:08 AM EST, Key ID 07477e65fb4b18e6
Source RPM  : httpd-2.4.7-1.fc19.src.rpm
Build Date  : Mon 27 Jan 2014 08:39:13 AM EST
Build Host  : buildvm-20.phx2.fedoraproject.org
Relocations : (not relocatable)
Packager    : Fedora Project
Vendor      : Fedora Project
URL         : http://httpd.apache.org/
Summary     : Apache HTTP Server
Description :
The Apache HTTP Server is a powerful, efficient, and extensible
web server.

Essa seria a Build Hostlinha dentro dos RPMs.

O uso de / usr / bin / company?

Eu provavelmente desencorajaria o uso de um local como esse. Principalmente porque exige que todos os seus sistemas $PATHaumentem para incluí-lo e não é padrão. Personalizar as coisas sempre foi um "direito de passagem" para todos os administradores do Unix, mas eu sempre a desencorajo, a menos que seja absolutamente necessário.

O maior problema com as personalizações como essa é que elas se tornam um fardo na manutenção do ambiente e na atualização de novas pessoas sobre como usar o ambiente.

Posso apenas obter uma lista de arquivos do RPM?

Sim, você pode conseguir isso, mas serão necessárias duas chamadas para o RPM. O primeiro criará uma lista de pacotes que foram criados no host X.mydom.com. Depois de obter essa lista, você precisará chamar novamente o RPM consultando os arquivos pertencentes a cada um desses pacotes. Você pode conseguir isso usando este liner:

$ rpm -ql $(rpm -qa --queryformat "%-30{NAME}%{BUILDHOST}\n" | \
    grep X.mydom.com | awk '{print $1}') | head -10
/etc/pam.d/run_init
/etc/sestatus.conf
/usr/bin/secon
/usr/bin/semodule_deps
/usr/bin/semodule_expand
/usr/bin/semodule_link
/usr/bin/semodule_package
/usr/bin/semodule_unpackage
/usr/sbin/fixfiles
/usr/sbin/genhomedircon

e como obter uma lista de todos os binários que foram instalados por todos os rpms instalados? Felizmente, concordamos em colocar o nome da empresa nos nomes das rpm; então algo como "rpm -qa | grep empresa" listas meus rpms instalado
Chris Maes

@ ChrisMaes - veja as atualizações. Eu uso o build host para determinar quais pacotes são "meus".
Slm

obrigado pela atualização; se você poderia apenas adicionar um comando para encontrar todos os binários de propriedade de meus rpms (que têm "empresa" em seu nome) que seria fantástico
Chris Maes

@ ChrisMaes - veja a atualização, LMK, se você precisar de mais orientações.
Slm

resposta escrita muito boa; completo e bem formatado. Muito obrigado!
Chris Maes

4

Uma sugestão óbvia é nomear seus binários ou pacotes de uma maneira especial. Então, por exemplo, você pode prefixá-los com cm-, por suas iniciais, conforme indicado neste post. Se você estiver instalando rpms, eles precisam entrar /usr/bin(se forem executáveis ​​no nível do usuário), de acordo com o FHS. Eles não devem entrar /usr/local/binpor exemplo. Isso é apenas para instalações locais.

Para o registro, não acho a idéia de colocar binários em um diretório especial e vinculá-los de maneira alguma atraente, embora suponha que essas coisas às vezes sejam feitas. Lembre-se também de que, se você precisar descobrir quais binários pertencem a qual pacote, basta consultar o sistema de empacotamento.


3

Os binários que não fazem parte do sistema ou distribuição geralmente estão em

/usr/local/bin

o diretório geralmente está no padrão $PATHpara que seus binários sejam encontrados.


normalmente / usr / local / bin é para binários que existem apenas "localmente" nessa máquina; não para binários que distribuirei em outras máquinas usando uma rpm ...?
Chris Maes

2
No Linux, /usr/local/biné para executáveis ​​instalados manualmente. Executáveis ​​gerenciados pelo gerenciador de pacotes entram /usr/bin.
Gilles 'SO- stop be evil'

@Gilles, minha primeira interpretação da questão foi instalar em uma única máquina, disponibilizando os binários para todos os usuários (não instalando no $ HOME). Agora vejo que não era exatamente o que eu entendia.
Matteo
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.