search

freedomofpress / ansible-role-elk

Installs a turnkey ELK stack for log aggregation and analysis, with optional Riemann support for alerting
18 stars 13 forks source link

Install Kibana from apt repositories instead of tarball #45

Closed ageis closed 8 years ago

ageis commented 8 years ago

Updates the role to use Elastic's package repositories for installing Kibana instead of downloading the tarball, per issue #39. Removes elk_kibana_version. The new version is 4.5 instead of 4.4.1. Updates the spec tests.

ageis commented 8 years ago

There were permissions/ownership concerns with the switch to root-owned application code and the old www-data user. The .deb package runs with the user kibana and the var elk_nginx_user has been updated to reflect. I ran the playbook against the test server with these changes.

The systemd service still fails to start because of EACCES: permission denied, with the new user. It may need to be ripped out. The init script runs Kibana. I'm just confused now because I'm seeing timeouts from nginx even though that's running. Updating the user directive in /etc/nginx/nginx.conf as well does not fix the problem.

The other things you have to worry about for converting from the older version of the role: 1) Blow away the old tarball installation and symlink, but keep /config/kibana.yml. 2) Paxctld needs to be restarted to re-apply PaX flags to the new node binary. 3) Some stdout/stderr logging is now going to /var/log/kibana

ageis commented 8 years ago

Ok, got things running now... A few things to note.. kibana.service should probably just be ripped out of both /etc/systemd and /lib/systemd. Doesn't seem to play nicely with the new init script. Nginx still runs as www-data. So it doesn't like the perms on the htpasswd file. There's no need to have nginx run as kibana, as it's just a local reverse proxy. [crit] 4342#0: *1 open() "/etc/nginx/conf.d/kibana.htpasswd" failed (13: Permission denied) Kibana also didn't like the root:kibana owner+group of /var/log/kibana.log at first, but I'm unable to reproduce it again, so I can't state definitively that it's an issue.

conorsch commented 8 years ago

This is looking good now. I'm going to rebase on top of the latest master, to take advantage of the handler reorder in #46 (specifically 4a8d0b7), which is necessary to make sure the services come back up correctly after the reinstall.

I'll run a complete upgrade test again to confirm that the role moves smoothly from the tarball setup to the new apt strategy. If all the tests pass, I'll merge.

ageis commented 8 years ago

Looking great.

conorsch commented 8 years ago

Confirmed smooth upgrade path from symlink strategy. All tests passing. Merging.