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

Wip/server permissions #174

Merged
merged 3 commits into from Feb 28, 2014

Conversation

Projects
None yet
3 participants
@muuki88
Copy link
Contributor

commented Feb 23, 2014

DONE

This is a follow up to #170 discussions. The current state of the pull request contains

  • Replacing all traces of appUser and appGroup with daemonUser and daemonGroup
  • Using the new MappingsHelper
  • Added defaultLinuxConfigLocation

TODO

Think of a way to create a permissions-table like this

Folder User Permissions Purpose
/usr/share/package-name root 755 / (655) static, non-changeable files
/etc/default/package-name.conf root 644 default config file
/etc/package-name root 644 config folder -> link to /usr/share/package-name/conf
/var/run/package-name daemonUser 664 if the application generates a pid on its own
/var/log/package-name daemonUser 664 log folder -> symlinked from /usr/share/package-name/log

Option 1: mapping-files-changer

A small API to change permissions for already-created mappings.

Pro Contra
Add-in, currenty behaviour doesn't need to be changed LinuxPackageMappings may need to be split, as they contain a sequence of mappings
easy API, e.g. changePermissions(for = "/usr/share", LinuxFileMetaData(user = "daemonUser")) No place to lookup _defaults

Option 2: creating a permissions table

The idea is to define a setting, which can be queried for default permissions, like

val meta: LinuxFileMetaData = permissionsFor "/usr/share"
Pro Contra
defaults can be easily overidden checked before each mapping is created
one place for defaults permission table for dirs, files and maybe more

Discussion

@aparkinson, @jsuereth, @kardapoltsev . What do you think?

@kardapoltsev

This comment has been minimized.

Copy link
Member

commented Feb 25, 2014

Since mostly we want default root:root 644 I think the first option will be fine.

@muuki88 muuki88 referenced this pull request Feb 28, 2014

Merged

Wip/rpm server archetype #176

for((file, name) <- manPages)
yield file -> (name + ".gz")
for ((file, name) <- manPages)
yield file -> (name + ".gz")

This comment has been minimized.

Copy link
@jsuereth

jsuereth Feb 28, 2014

Member

WDYT of using Scalariform, which although not my favorite style, will help prevent all of us from whitespace-line changing each other?

This comment has been minimized.

Copy link
@muuki88

muuki88 Feb 28, 2014

Author Contributor

I think I'm already using it through Eclipse (at least that's what the scalariform page says). However an integration in the build with sbt-scalariform would be helpful as everbody uses another IDE

This comment has been minimized.

Copy link
@muuki88
val (path, permissions) = loader match {
case Upstart => ("/etc/init/" + name + ".conf", "0644")
case SystemV => ("/etc/init.d/" + name, "0755")
}
for {
s <- script.toSeq
} yield LinuxPackageMapping(Seq(s -> path), LinuxFileMetaData(owner, ownerGroup, permissions, "true"))
} yield LinuxPackageMapping(Seq(s -> path), LinuxFileMetaData(Users.Root, Users.Root, permissions, "true"))

This comment has been minimized.

Copy link
@jsuereth

jsuereth Feb 28, 2014

Member

Hmm.... someone did request the ability to modify these before though, right?

I think the direction we're taking is correct, but I'm still curious how this pans out with our audience. You can always drop down and specify mappings directly. I think you may be right we need to provide a convenient way to filter mappings successfully after the fact.

This comment has been minimized.

Copy link
@muuki88

muuki88 Feb 28, 2014

Author Contributor

There was a long discussion in #170 which I summed up in this #174 pull request.

This comment has been minimized.

Copy link
@jsuereth

jsuereth Feb 28, 2014

Member

Right. I guess I'm not fully convinced this is the right path, but it's the best option right now, most likely. I think if we open one of your two suggested options, the point becomes moot as well. This will be a documentation problem, though :)

@jsuereth

This comment has been minimized.

Copy link
Member

commented Feb 28, 2014

SO in terms of option 1 vs. Option 2, I'm on the fence. Both have desirable attributes. I'm leaning towards 2 though, for sbt.

rawLinuxPackageMappings as a key that you could then safely filter. I.e. all archetypes feed directly into rawLinuxPackageMappings and then we have a simple:

linuxPackageMappings in Linux := (rawLinuxPackageMappings in Linux).value
@jsuereth

This comment has been minimized.

Copy link
Member

commented Feb 28, 2014

Merging this as-is for now.

jsuereth added a commit that referenced this pull request Feb 28, 2014

@jsuereth jsuereth merged commit 676d72c into master Feb 28, 2014

1 check passed

default The Travis CI build passed
Details

@jsuereth jsuereth deleted the wip/server-permissions branch Feb 28, 2014

muuki88 added a commit that referenced this pull request Mar 2, 2014

jsuereth added a commit that referenced this pull request Mar 3, 2014

Merge pull request #178 from sbt/wip/linux-server-permissions
Implementing permissions as described in #174
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.