-
Notifications
You must be signed in to change notification settings - Fork 443
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
/var/log/app_name permissions fixed #111
Conversation
I was wrong in my previous PR. |
// create empty var/log directory | ||
val d = target / logsDir | ||
d.mkdirs() | ||
LinuxPackageMapping(Seq(d -> s"$logsDir/$name"), LinuxFileMetaData(user, user)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice. This now makes sense to me.
Another question: IS this something we'd need for RPM packages too? I'd like to try to port your init.d stuff for RPM as well, if I can get a local CentOS machine running in time for testing before the next sbt-native-packager release.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't know much about RPM. But I could check this tomorrow.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does string interpolation work in this build? On my system the build is set to scala 2.9.x?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think no. I forgot about 2.9. Excuse me, I'll fix
Regards, Alexey
On Dec 18, 2013 9:17 PM, "Muki" notifications@github.com wrote:
In
src/main/scala/com/typesafe/sbt/packager/archetypes/JavaServerApplication.scala:@@ -62,9 +62,13 @@ object JavaServerAppPackaging {
s <- script.toSeq
} yield LinuxPackageMapping(Seq(s -> path)).withPerms(permissions)
},
// TODO the /var/log should be generalized like defaultLinuxInstallLocation
linuxPackageMappings in Debian <+= (normalizedName) map {
name => packageTemplateMapping("/var/log/" + name)()
// TODO should we specify daemonGroup in configs?
linuxPackageMappings in Debian <+= (normalizedName, defaultLinuxLogsLocation, target in Debian, daemonUser in Debian) map {
(name, logsDir, target, user) =>
// create empty var/log directory
val d = target / logsDir
d.mkdirs()
LinuxPackageMapping(Seq(d -> s"$logsDir/$name"), LinuxFileMetaData(user, user))
Does string interpolation work in this build? On my system the build is
set to scala 2.9.x?—
Reply to this email directly or view it on GitHubhttps://github.com//pull/111/files#r8438638
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
DOH, good catch @muuki88. Still too many 0.12 users for us to mirate off of it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've already fix this in #110 )
Thanks much for the fixes! |
/var/log/app_name permissions fixed
@@ -63,6 +63,7 @@ trait GenericPackageSettings | |||
|
|||
// Default place to install code. | |||
defaultLinuxInstallLocation := "/usr/share", | |||
defaultLinuxLogsLocation := "/var/log", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Somebody fixing my TODOs. Thanks :)
Most of work will be in renaming classes and methods. All of this was done only for Debian. I think I could try to add system V support for RPM, but I have no machine to test it. object JavaServerAppPackaging {
import ServerLoader._
def settings: Seq[Setting[_]] = JavaAppPackaging.settings ++ debianSettings |
Yeah, this is something I'd like to have on RPM as well. Right now, all my VMs are toast from a recent lost hard drive. Once I get my dev setup again for CentOS-latest, I can give it a shot, unless you have a chance to look at it before then. |
No description provided.