Wip/server permissions

[muuki88]

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]

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

[jsuereth]

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

[muuki88]

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

[muuki88]

My preferences export from eclipse: https://dl.dropboxusercontent.com/u/2654300/formatterPreferences.properties

[jsuereth]

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]

Merging this as-is for now.