Como posso descobrir de onde veio uma RPM?

1

Eu tenho um RPM que está em um servidor que herdei. No servidor, há um RPM necessário para um dos aplicativos que ele executa.

xmlrpc-epi-0.54.2-1.x86_64.rpm

Em vez de usar este rpm misterioso, quero encontrar o pacote equivalente na epel. yum search xmlrpc retorna mais de uma dúzia de resultados.

Como posso descobrir de onde esse RPM veio , ou pelo menos verificar se é o mesmo pacote que existe em um dos repositórios comuns (epel).

A maior quantidade de informações que posso encontrar é com rpm --query :

[root@us-devops-build02 tmp]# rpm --query --info -p xmlrpc-epi-0.54.2-1.x86_64.rpm
Name        : xmlrpc-epi                   Relocations: /
Version     : 0.54.2                            Vendor: none
Release     : 1                             Build Date: Wed 23 Oct 2013 09:08:24 PM UTC
Install Date: (not installed)               Build Host: foo.bar
Group       : default                       Source RPM: xmlrpc-epi-0.54.2-1.src.rpm
Size        : 1060096                          License: unknown
Signature   : (none)
Packager    : <[email protected]>
URL         : http://example.com/no-uri-given
Summary     : no description given
Description :
no description given

Editar1
Raciocínio:
O administrador anterior tinha um script que usaria esse RPM. Eu não sei porque ele usou este floco de neve especial em vez de usar um pacote da epel. Eu estou movendo o script para o fantoche, então eu gostaria de usar fontes oficiais o máximo possível.

Edit2
rpm -kv mostra o seguinte

rpm --checksig --verbose xmlrpc-epi-0.54.2-1.x86_64.rpm
xmlrpc-epi-0.54.2-1.x86_64.rpm:
    Header SHA1 digest: OK (2f2f1619cd1e251cc37675b57656f1394c74024e)
    MD5 digest: OK (656e5696da9f259a47725dacd38b9697)

Editar3

Aqui estão todos os pacotes 'xmlrpc' no epel

sems-xmlrpc2di.x86_64 : XMLRPC interface for SEMS
xmlrpc-c-c++.i686 : C++ libraries for xmlrpc-c
xmlrpc-c-c++.x86_64 : C++ libraries for xmlrpc-c
xmlrpc-c-client.i686 : C client libraries for xmlrpc-c
xmlrpc-c-client.x86_64 : C client libraries for xmlrpc-c
xmlrpc-c-client++.i686 : C++ client libraries for xmlrpc-c
xmlrpc-c-client++.x86_64 : C++ client libraries for xmlrpc-c
xmlrpc-c-devel.i686 : Development files for xmlrpc-c based programs
xmlrpc-c-devel.x86_64 : Development files for xmlrpc-c based programs
xmlrpc3-javadoc.noarch : Javadoc for xmlrpc3
erlang-xmlrpc.x86_64 : HTTP 1.1 compliant XML-RPC library for Erlang
koji-hub.noarch : Koji XMLRPC interface
lua-xmlrpc.noarch : Lua package to access and provide XML-RPC services
php-ZendFramework2-XmlRpc.noarch : Zend Framework 2: XML-RPC Component
php-xmlrpc.x86_64 : A module for PHP applications which use the XML-RPC protocol
python-offtrac.noarch : Trac xmlrpc library
python-wordpress-xmlrpc.noarch : WordPress XML-RPC API Integration Library
trac-xmlrpc-plugin.noarch : Allows Trac plugins to export their interface via XML-RPC
xmlrpc-c.i686 : A lightweight RPC library based on XML and HTTP
xmlrpc-c.x86_64 : A lightweight RPC library based on XML and HTTP
xmlrpc-c-apps.x86_64 : Sample XML-RPC applications
xmlrpc3-client.noarch : XML-RPC client implementation
xmlrpc3-client-devel.noarch : Source for XML-RPC client implementation
xmlrpc3-common.noarch : Common classes for XML-RPC client and server implementations
xmlrpc3-common-devel.noarch : Source for common classes of XML-RPC
xmlrpc3-server.noarch : XML-RPC server implementation
xmlrpc3-server-devel.noarch : Source for XML-RPC server implementation
    
por spuder 24.01.2014 / 06:25

2 respostas

2

Você pode usar:

rpm -Kv xmlrpc-epi-0.54.2-1.x86_64.rpm

para exibir a assinatura do pacote (se houver). A partir disso, você poderia tentar rastrear o originador do pacote.

O pacote em si (sem assinatura) poderia ter sido reconstruído por qualquer pessoa. Se não estiver assinado, tentaria (a partir dos dados do campo rpm genérico) para ver se ele foi construído na própria máquina. Você também pode tentar os logs se eles voltarem a outubro do ano passado para descobrir quando o arquivo foi copiado para a máquina se ela não foi compilada (pode ter sido scp -ed).

    
por 24.01.2014 / 07:52
0

Melhor não confie em software com origens duvidosas. Veja se você encontra uma fonte respeitável para isso.

O que depende deste pacote? Se for um pacote RHEL ou EPEL, apenas instalando isso deve pegar as dependências.

    
por 24.01.2014 / 18:45

Tags