Skip to content

Conversation

@cite
Copy link

@cite cite commented Jul 20, 2014

Change logic from using "chroot --userspec" (which doesn't work
with RHEL5) to using "sudo". Side effects:

  1. It's no longer possible to explictely set the group that LS
    will use (LS_GROUP variable removed).
  2. Related to Minor web form change #1, supplemental groups for logstash will now work.
  3. Due to the way that sudo behaves, I had to shift logfile
    creation to the non-privileged part, so on upgrades, if one
    doesn't explicitely chown existing logfiles, it will break.

Regarding #3: We could probably chown the logfiles to $LS_USER from
within the init script...

Change logic from using "chroot --userspec" (which doesn't work
with RHEL5) to using "sudo". Side effects:
1. It's no longer possible to explictely set the group that LS
   will use (LS_GROUP variable removed).
2. Related to #1, supplemental groups for logstash will now work.
3. Due to the way that sudo behaves, I had to shift logfile
   creation to the non-privileged part, so on upgrades, if one
   doesn't explicitely chown existing logfiles, it will break.

Regarding elastic#3: We could probably chown the logfiles to $LS_USER from
within the init script...
@elasticsearch-release
Copy link

Can one of the admins verify this patch?

@coolacid
Copy link
Contributor

NOTE: RHEL5 EOL is March 31, 2017 -- Why won't they let this DIE already?

@electrical
Copy link

I can confirm this works on centos5 and SLES 11 :-)

@jordansissel
Copy link
Contributor

Using sudo requires 'root' be in the sudoers file. Ugh. Computers are silly.

@coolacid
Copy link
Contributor

Second, this removes the chroot jail too.

@jordansissel
Copy link
Contributor

we can do sudo for user changes and chroot for chrooting, perhaps. I'll see about putting this into pleaserun

@coolacid
Copy link
Contributor

I think chroot requires root, thus, we can't sudo first.. we can't sudo after either since sudo (or required files) wouldn't be in the root directory.

Maybe work to identify EL5 and run without chroot, otherwise use #1398 ?

@cite
Copy link
Author

cite commented Sep 6, 2014

Doesn't the chroot call simply chroot to / right now?

@hcgpalm
Copy link

hcgpalm commented Mar 11, 2015

The way it's currently done using chroot / is broken and total nonsense.
But why not use plain su like everyone else, rather than sudo?

@hcgpalm
Copy link

hcgpalm commented Mar 11, 2015

I think this is a better way to do it:
#2809

@jordansissel jordansissel removed the O(1) label Jun 29, 2015
@elasticsearch-release
Copy link

Jenkins standing by to test this. If you aren't a maintainer, you can ignore this comment. Someone with commit access, please review this and clear it for Jenkins to run; then say 'jenkins, test it'.

1 similar comment
@elasticsearch-release
Copy link

Jenkins standing by to test this. If you aren't a maintainer, you can ignore this comment. Someone with commit access, please review this and clear it for Jenkins to run; then say 'jenkins, test it'.

@jordansissel
Copy link
Contributor

Is this still an issue? I forgot this was assigned to me.

The system I knew was affected by this (RHEL/CentOS 5) is EOL at this time. Newer redhat systems work with the existing scripts we have, and further, Logstash on RHEL 6 will target Upstart (not sysv init), and on RHEL 7 will target systemd (not sysv init).

@jordansissel
Copy link
Contributor

Going to close; we can reopen if this is still an issue on a non-EOL platform.

As an alternative, someone could maintain an init script that worked on these EOL'd platforms and post it here for others to use.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants