Remapping /etc/<app> <-> /usr/share/<app>/conf symlink

[sumdog]

I've been searching the docs and issues and can't seem to find anything addressing this. Just from a Linux admin standpoint the symlink from /etc/ into /usr/share//conf seems a little strange to me. Whereas the link from /usr/share//log to /var/log/ makes a lot more sense.

Is there a way to set mappings such that /usr/share//conf links to /etc/ and not the other way around? Or is there a specific reason it's done this way and it shouldn't be changed?

[muuki88]

I can understand that confusion. The reason for this configuration is, that the universal:packageBin has a predefined conf directory ( see universal conventions ). Because of this the symlink is created the other way round.

Does this causes any problems or issues? You can workaround this by resetting the linuxPackageSymlinks (see here ). This would look something like this (no guarantee)

 linuxPackageMappings <+= (normalizedName) map {
      (name) => packageTemplateMapping("/etc/" + name)()
    },
linuxPackageSymlinks <<= (normalizedName, defaultLinuxInstallLocation) map {
      (name, install) => LinuxSymlink("/etc/" + name + "", install + "/" + name + "/etc") // "conf" maybe overriden?!
    }

[sumdog]

It doesn't really cause any issues, I just found it odd from a packaging perspective. The following sorta works:

linuxPackageMappings <+= (NativePackagerKeys.normalizedName) map {
  (name) => packageTemplateMapping("/etc/" + name)() withUser "root" withGroup "root" 
}

linuxPackageSymlinks <<= (NativePackagerKeys.normalizedName, defaultLinuxInstallLocation) map {
  (name, install) => Seq(LinuxSymlink("/etc/" + name + "", install + "/" + name + "/etc"))
}

And it seems to create the correct files and symlinks in the target directory, but it fails because it tries to set the permission of the symlink (which isn't connected to anything yet):

java.lang.RuntimeException: Error running chmod 755 /home/sumit/sensespace/BigSense/target/bigsense-0.2alpha/etc/bigsense
    at scala.sys.package$.error(package.scala:27)
    at com.typesafe.sbt.packager.chmod$.apply(FileUtil.scala:11)
    at com.typesafe.sbt.packager.debian.DebianPlugin$$anonfun$debianSettings$21$$anonfun$apply$9$$a

LinuxPackageMapping.scala has a default permission of 755. If I look through the DebainPlugin, it looks in that apply method, it's always going to do chmod; not sure if there's a way around it.

[muuki88]

I think there's no way around the chmod at this point. I'm thinkin about turning the logs file the other way round, to make it consistent. Creating /usr/share/<app>/logs and linking /var/logs/<app> to it. This way we have consistency in the packageBin tasks and the linux installations. WDYT?

[sumdog]

I'd recommend against that. Keep in mind a lot of system administrators still place /var on separate volumes. The /var path is where data that is constantly changing state should be kept, so if a database or logs end up filling a volume, it won't prevent the system from being able to get security updates.

That's kinda the same reasoning being /etc having configuration files where as /usr contains the immutable state of the applications.

I realize a lot of this is going away with Fedora combining /bin and /usr/bin and /lib with /usr/lib and that the UNIX file structure is becoming increasingly less relevant, but I still think it's important to physically keep logs in /var, mainly due to the the separate volume thing which is still pretty common.

[muuki88]

Thanks for the detailed answer. I definitely agree on the /var/logs part.

Currently a small API for easily updating the mappings is missing, why
it's so hard to change things, like the conf -> etc mapping. However if
there is a small API, it should be no problem to change the symlink
directions.

[kardapoltsev]

+1 @sumdog