Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Trouble using *daemonUser* and *daemonGroup* settings for RPM #856

Closed
craigwblake opened this issue Jul 29, 2016 · 7 comments
Closed

Trouble using *daemonUser* and *daemonGroup* settings for RPM #856

craigwblake opened this issue Jul 29, 2016 · 7 comments

Comments

@craigwblake
Copy link

craigwblake commented Jul 29, 2016

I have a build generating an RPM where the daemon user has to be a particular existing user on the target machine. I've tried using the daemonUser and daemonGroup settings but they are not working as I expect they should be. I'm setting them with:

daemonUser in Rpm := "hadoop"
daemonGroup in Rpm := "hadoop"

When I inspect the generated RPM file, the directory in /var/run is created with the daemonUser and daemonGroup ownership, while the /var/log directory is not.

Even so, when installing the RPM the /var/run ownership is apparently ignored, and the resulting daemon does not run as the daemonUser but rather as a new user created to match the project name, like typical.

Any ideas what's going on or what I'm missing?

Thanks.

@muuki88 muuki88 added the rpm label Jul 29, 2016
@muuki88
Copy link
Contributor

muuki88 commented Jul 29, 2016

Thanks for your report. Can you give some more information to clarify this issue

  • Which native-packager version are you using
  • Which system-loader do you use ( SystemV, Upstart or Systemd)
  • Can you post a minimal build.sbt to reproduce this

@zoosky
Copy link
Contributor

zoosky commented Aug 1, 2016

This bug comes with 1.2 refactoring. D I had it with rpm and systemv.

@craigwblake
Copy link
Author

craigwblake commented Aug 2, 2016

Which native-packager version are you using

This is with version 1.1.1 of native packager.

Which system-loader do you use ( SystemV, Upstart or Systemd)

I did not set one explicitly, but the target system is SystemV style and that's what the package appears to have generated.

Can you post a minimal build.sbt to reproduce this

I'll see what I can do.

@MojoJojo
Copy link

I am not sure if this is related but I also noticed that when the rpm is installed, it creates a group and a user matching the project name. I would have thought these two would have matched daemon group and daemon user setting respectively?

@muuki88 muuki88 added the bug label Aug 22, 2016
@sheinbergon
Copy link

Still a pesky bug in April 2017. daemonUser and daemonGroup are ignored in-favor of user/group name matching the project name. Any word on how to overcome this issue ?

@keirlawson
Copy link
Contributor

I found I was able to set them in the Linux scope and it worked for my RPM, ie

daemonUser in Linux := "someuser"

@muuki88
Copy link
Contributor

muuki88 commented Apr 22, 2017

@keirlawson is correct. You have to scope the daemonUser to in Linux. This is the reason of a not very well scaling design.

The linuxScriptReplacements are being produced by tasks & settings that are scoped to in Linux. There are no linuxScriptReplacements in Rpm. The current implementation isn't suited for this, because it's

  • a Seq[(String,String)], not a Map or another easily mergable data structure
  • never scoped
  • named for linux
  • keys are an implementation detail in the LinuxPlugin

The whole script generating process needs a big overhaul. I started this 1-2 years a go and did some cleanup, but haven't really touched the architecture itself.

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

No branches or pull requests

6 participants