search

elastic / logstash

Logstash - transport and process your logs, events, or other data
https://www.elastic.co/products/logstash
Other
74 stars 3.5k forks source link

make lintian happy #2011

Closed zabbal closed 10 years ago

zabbal commented 10 years ago

Would be great to have logstash stack available straight from debian/ubuntu. This is doable but would require cleaning up packages so they adhere to commonly accepted standards like FHS. The tool to check compliance called lintian. Would be nice to see all the warnings and errors found by lintian fixed.

jordansissel commented 10 years ago

FHS is a commonly misinterpreted and very poorly written standard. Let's ignore it for this discussion :)

lintian checks for Debian packaging policy compliance, not FHS compliance. It's important to note that Debian packaging policy is specifically for packages destined for inclusion and distribution with Debian. Logstash packages are not included with Debian, so Debian packaging policy doesn't need to apply.

Would be great to have logstash stack available straight from debian/ubuntu.

Are you saying that you want to ship Logstash with Ubuntu and Debian? If so, I would strongly discourage any efforts to include Logstash in Debian.

Would be nice to see all the warnings and errors found by lintian fixed.

This I can help with! Can you list specific lintian warnings and errors? I'll address them specifically, and if possible, will fix them!

jordansissel commented 10 years ago

On the ubuntu/debian note, we already provide apt repositories so users can, once configured, very easily apt-get install logstash and go about their business.

zabbal commented 10 years ago

Certainly true for quick-and-dirty PoC. But for running software in production on highly important data it's always good to have some degree of quality assurance. Debian have reputation for precisely that. Running stuff from third-party repo - doesn't. And for a good reason: for instance right now lintian gives 15326 (sic!) errors upon package inspection. Each of those potentially a maintenance problem or worse - loss of data. Fixing those is a boring job but it's the boring job which makes software maintainable and predictable.

Few quick examples: ruby-script-but-no-ruby-dep error on each ruby file: package should have explicit dependency on ruby version so it's taken into account when ruby is updated. wrong-path-for-interpreter on opt/logstash/vendor/bundle/jruby/2.1/gems/diff-lcs-1.2.5/bin/ldiff (#!ruby != /usr/bin/ruby) - the path to ruby interpreter is hardcoded and it's wrong non-standard-dir-perm on var/lib/logstash/ - potential security risk dir-or-file-in-opt - that's obvious etc

jordansissel commented 10 years ago

always good to have some degree of quality assurance

Are you asserting that Logstash has no quality assurance, and further, that only Debian can provide it?

As I said, lintian is for auditing packages intended to comply with Debian's packaging policies. Debian packaging policies are a contract between Debian (the distribution) and Debian package maintainers.

Your lintian output:

ruby-script-but-no-ruby-dep error on each ruby file: package should have explicit dependency on ruby version so it's taken into account when ruby is updated.

What is the negative impact to you due to this? What behavior do you observe when running Logstash that is faulty due to this?

wrong-path-for-interpreter on opt/logstash/vendor/bundle/jruby/2.1/gems/diff-lcs-1.2.5/bin/ldiff (#!ruby != /usr/bin/ruby) - the path to ruby interpreter is hardcoded and it's wrong

What is the negative impact to you due to this? What behavior do you observe when running Logstash that is faulty due to this?

non-standard-dir-perm on var/lib/logstash/ - potential security risk

What is the negative impact to you due to this? What behavior do you observe when running Logstash that is faulty due to this?

dir-or-file-in-opt - that's obvious

What is the negative impact to you due to this? What behavior do you observe when running Logstash that is faulty due to this?

You said FHS, right? FHS 2.3, says this

/opt is reserved for the installation of add-on application software packages.

In this way, we are compliant with FHS. Only Debian's packaging policy complains.

Let us not worry about these poorly applied standards! I am interested specifically in what negative impact upon your operations our packaging has. If there are bugs, we will fix them. lintian complaining about things doesn't necessarily indicate a problem users will actually have.

jordansissel commented 10 years ago

Here's the full list of lintian output counted by the kind of problem; note, I have ignored all warnings because warnings are meaningless. If it is really an error, we should say it's an error. :)

Notes: I ran lintian on Ubuntu 14.04 against Logstash 1.4.2's deb.

Output below is sorted by frequency of occurence.

1 E: control-file-has-bad-permissions

No negative impact on users.

1 E: debian-changelog-file-missing

No negative impact on users.

1 E: extended-description-is-empty

No negative impact on users.

1 E: maintainer-address-malformed

No negative impact on users.

1 E: maintainer-name-missing

A bug in our build process. No negative impact on users.

1 E: misplaced-extra-member-in-deb

No negative impact on users.

1 E: no-copyright-file

Debian policy looking in the wrong place. No negative impact on users.

1 E: privacy-breach-google-adsense

E: logstash: privacy-breach-google-adsense opt/logstash/vendor/bundle/jruby/2.1/gems/nokogiri-1.6.2.1-java/test/files/tlm.html

Non-issue. This file is included with nokogiri for its testing stuff. This file is not used in logstash.

1 E: privacy-breach-twitter

E: logstash: privacy-breach-twitter opt/logstash/vendor/kibana/vendor/bootstrap/less/tests/css-tests.html

Non-issue. This file is included with Kibana's release via its dependency on Bootstrap. It is not used in Logstash.

1 E: python-script-but-no-python-dep

E: logstash: python-script-but-no-python-dep opt/logstash/vendor/bundle/jruby/2.1/gems/geoip-1.4.0/test/csvORG2dat.py

Non-issue. Another test file.

2 E: init.d-script-does-not-implement-required-option

E: logstash: init.d-script-does-not-implement-required-option etc/init.d/logstash-web force-reload E: logstash: init.d-script-does-not-implement-required-option etc/init.d/logstash force-reload

Agreed, though there is no "reload" feature. Non-issue.

4 E: file-in-etc-not-marked-as-conffile

Agreed, we should fix this. Recommend filing a separate bug about it.

4 E: shell-script-fails-syntax-check

E: logstash: shell-script-fails-syntax-check opt/logstash/vendor/bundle/jruby/2.1/bin/htmldiff

Non-issue

7 E: wrong-path-for-interpreter

Non-issue. The files referenced are not intended to be run by users.

34 E: missing-dep-for-interpreter

Non-issue. Same as previous point.

197 E: ruby-script-but-no-ruby-dep

Non-issue. We ship with JRuby in the package

14931 E: dir-or-file-in-opt

Non-issue.

jordansissel commented 10 years ago

As an amusement, I ran lintian on files in /var/cache/apt/archives. This directory is where apt-get stages .deb packages during download. There are lots of errors and warnings, and these packages ship with Debian and have been blessed by its package maintainers.

% lintian /var/cache/apt/archives/*.deb
... 
> N: 174 tags overridden (156 errors, 15 warnings, 3 info)

So, let me ask a more direct question - What problem are you experiencing? How did you arrive at using lintian to diagnose it?

zabbal commented 10 years ago

Are you asserting that Logstash has no quality assurance, and further, that only Debian can provide it?

No, but "build failed" status was hanging for days on kibana repo for a reason ;-)

Non-issue. We ship with JRuby in the package

So if security vulnerability is found in jruby and fixed in debian repo my systemd with logstash would still be vulnerable because you decided to bundle everything together instead of splitting package and using dependencies?

What problem are you experiencing? How did you arrive at using lintian to diagnose it?

1772 and #1559 in kibana, #2007 in logstash.

Don't get me wrong, elastic+logstash+kibana is awesome for quick PoC with impressive screenshots. PoC is good for convincing people but I've been already convinced after reading feature list - I'm interested in an installation which I could use in production in a secure way without wasting hours on troubleshooting and maintenance. The setup to which I could trust valuable data and be sure that it won't break upon system update. Logstash does not exist in vacuum - it's installed under particular OS. The closer the package for that OS adhere to the standards of OS - the lower the chance for maintenance headache.

Working on those packaging and maintenance bits is boring, but the commitment of developers to even boring work is the best assurance I can get for software maturity.

jordansissel commented 10 years ago

https://github.com/elasticsearch/logstash/issues/2007

This bug was fixed without relying on downstream OS distributors.

https://github.com/elasticsearch/kibana/issues/1772

This is fixed or being fixed.

https://github.com/elasticsearch/kibana/issues/1559

This is a major feature that would not be provided by any downstream OS distributor. Debian, included.

If you need help with production deployment, commercial support is available for you.

None of the issues you mentioned are solved by "have Debian ship with Logstash" so I'm confused as to the underlying problem, here.

So if security vulnerability is found

Or if a security vulnerability is introduced by a downstream vendor?

I understand your concerns, but much of your "put it in Debian" relies heavily on hope as a strategy. Hope is not a strategy. If you are not confident that we (Elasticsearch) can deliver functional and safe code, then attempting to bolster that confidence by asking an external group to provide that functionality and safety on top, you're probably going to have a bad time :(

If there are bugs, we can fix them. If we need to add features, we can add features.

The setup to which I could trust valuable data and be sure that it won't break upon system update.

This has nothing to do with whether or not apt-get install logstash works with a stock Debian system.

I recognize and acknowledge your fears, but I think you're being a bit unclear as to what causes those fears. Packaging to some mythical standard that everyone already ignores doesn't solve a problem, because those standards aren't standards in the first place.

jordansissel commented 10 years ago

As an amusing way to show that 'hope is not a strategy' - Vixie cron has been around for aaaages. Debian ships it. The Debian crontab(5) manpage says:


DIAGNOSTICS
       cron  requires  that  each  entry in a crontab end in a newline character. If the last entry in a crontab is missing a newline (ie, terminated by EOF), cron will consider the
       crontab (at least partially) broken. A warning will be written to syslog.

The older version of this manpage (2ish years ago) said:

BUGS
       Although cron requires that each entry in a crontab end  in  a  newline  character,
       neither  the  crontab  command nor the cron daemon will detect this error. Instead,
       the crontab will appear to load normally. However, the command will never run.  The
       best choice is to ensure that your crontab has a blank line at the end.

Debian's cron package ships with over 7000 lines of patches. None of which fix this small and ancient bug.

(this is no slight against Debian, I love all the Debian peoples! I am just aiming to provide evidence that "I hope Debian fixes my Logstash problems" isn't a good strategy.)

If there's a bug in Logstash, we can fix it. It's all Open Source, so let's work together :)

jordansissel commented 10 years ago

Closing this in hopes that more clear tickets can spawn from it.

Summary: