RPM names do not match their contents

Elastic Stack Beats
1

filebeat RPM file names do not match their contents. Specifically, filebeat-1.2.3-x86_64.rpm should be filebeat-1.2.3-1.x86_64.rpm (is missing the release and the dot before the arch) and filebeat-5.2.1.rpm should be filebeat-5.2.1-1.x86_64.rpm (is missing release and arch).
It is the same for elasticsearch, kibana and logstash RPMs.

Running "rpm -qp --info" on an RPM file reports the .spec file information. The file name should match that information:

%{Name}%{Version}%{Release}.%{arch}.rpm

While yum and rpm will tolerate inconsistent file names, other tools may not, and it is confusing to customers and may cause them to question the integrity of the package.

2

Hello, thanks for reaching out about RPM names for filebeat. The pattern you mention holds true for the current release (filebeat-7.3.0-x86_64.rpm) as well. I'll see if there is a historical reason why the release has been omitted from RPM names.

3

Could you please provide some example tools that do not tolerate the current RPM file naming scheme? I've seen the following tools work fine with the RPMs.

  • rpm
  • yum
  • dnf
4

Hi @Michael_Madden,
Sorry for the late response.

We are using rpm or yum to install all the RPMs and there is no issue with the installation. But the problem comes when we run an automated script to check the installed version of the RPMs.
for example, we have filebeat rpm present with name "filebeat-oss-6.6.1-x86_64.rpm" and when we install and then check the rpm version by running the command "rpm -qa filebeat" it gives filebeat-6.6.1-1.x86_64.
Or when we do a "rpm -qp --info filebeat-oss-6.6.1-x86_64.rpm", it gives following output:
warning: filebeat-oss-6.6.1-x86_64.rpm: Header V4 RSA/SHA512 Signature, key ID d88e42b4: NOKEY
Name : filebeat
Version : 6.6.1
Release : 1
Architecture: x86_64
Install Date: (not installed)
Group : default
Size : 38027035
License : ASL-2.0
Signature : RSA/SHA512, Wed 13 Feb 2019 06:09:03 PM UTC, Key ID d27d666cd88e42b4
Source RPM : filebeat-6.6.1-1.src.rpm
Build Date : Wed 13 Feb 2019 04:13:41 PM UTC
Build Host : 114d60ad07ed
Relocations : /
Packager : <@114d60ad07ed>
Vendor : Elastic
URL : https://www.elastic.co/products/beats/filebeat
Summary : Filebeat sends log files to Logstash or directly to Elasticsearch.
Description :
Filebeat sends log files to Logstash or directly to Elasticsearch.

So there is a mismatch in rpm name is available(filebeat-oss-6.6.1-x86_64.rpm) and the rpm name with which it is present(filebeat-6.6.1-1.x86_64 or in info filebeat-6.6.1-1.src.rpm) after installation. Hence the script fails to find the latest version. While we have resolved this by adding some extra lines of code in the automated script but packages from Red Hat always follow the convention, and having names matched gives the user more confidence that the package is good.

Regards,
Akshat

5

@Michael_Madden
Any update on this?

Best Regards,
Akshat

6

Hi @Michael_Madden,
Do we have anything on this? It is kind of urgent for us at the moment.

Best Regards,
Akshat

7

Hi @akshatsharma, I believe the non-standard RPM names extend to products beyond Beats. Generally, all of the components for an Elastic Stack release are named consistently and released at the same time.

I'll bring up your valid point regarding the RPM names. To fix the issue, we'd likely need a coordinated change amongst all the Elastic Stack products.

1 Like
8

It is kind of urgent for us at the moment

Maybe we can help you find a workaround in the meantime? As you've noted, rpm does not require anything particular about the rpm file name itself.

Can you describe your process for how you take the output of rpm -qa ... and use it to find a special file?

As a workaround: you can rename the file if you wish giving it any name you like. Here's an example that takes an rpm file named "fancy.file" and renames it to name-version-release.arch.rpm:

% file fancy.file
fancy.file: RPM v3.0 bin i386/x86_64

% rpm -qp fancy.file
example-1.0-1.x86_64

% mv -v fancy.file "$(rpm -qp fancy.file).rpm"
renamed 'fancy.file' -> 'example-1.0-1.x86_64.rpm'

% rpm -qp example-1.0-1.x86_64.rpm
example-1.0-1.x86_64

Here's an example automatically naming filebeat however you like based on the package metadata:

% wget https://artifacts.elastic.co/downloads/beats/filebeat/filebeat-7.3.1-x86_64.rpm
...
% mv -v filebeat-7.3.1-x86_64.rpm "$(rpm -qp filebeat-7.3.1-x86_64.rpm).rpm"
renamed 'filebeat-7.3.1-x86_64.rpm' -> 'filebeat-7.3.1-1.x86_64.rpm'

Hope this helps.

1 Like
9

@Michael_Madden,
Thank you for your response!

I believe the non-standard RPM names extend to products beyond Beats

Yes, the inconsistent naming extends for all the Elastic Stack components.

I'll bring up your valid point regarding the RPM names. To fix the issue, we'd likely need a coordinated change amongst all the Elastic Stack products.

Sure, please let me know when there is any update on this.

Best Regards,
Akshat

10

@jordansissel,

Maybe we can help you find a workaround in the meantime?

Thanks a lot for providing the workaround!
I tried it, it works as expected. I'll just check with my team if this serves the purpose on application level.

However, It would be best if it is handled from Elastic side itself as there maybe other customer that might face the same issue and raise similar queries on the inconsistency of Elastic provided RPMs' name.

Best Regards,
Akshat

11

When can we expect this issue to be fixed? Any planned delivery date?

Best Regards,
Akshat

12

Hello,

Thanks for checking on this issue. I did start an internal discussion for this. While we realize this is a critical issue for you, some folks have raised the issue for potentially breaking a lot of automation that depends on the current RPM naming standard which has been used for years.

There is a similar enhancement request for Debian packages. I'll keep you updated as the internal discussion evolves.

Thanks.

1 Like
13

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.