Re: Summary: the state of the karaf debian package
>>>>> Thorsten Glaser <t.glaser@tarent.de>:
> Hi Steinar,
> congratulations on getting this far, that’s a nontrivial
> amount of work!
Thanks! :-)
> On Thu, 1 Feb 2018, Steinar Bang wrote:
>> 4. lintian no longer gives any warnings on the package (I have only run
>> lintian with "lintian karaf_xxx.deb", I haven't tried with any
>> arguments)
> You want "lintian -vIiE --pedantic --color=auto karaf*.changes" normally.
Ok, I will try that.
>> 6. A karaf service is added to systemd, running as user karaf and
> Does it work without systemd?
Hm... do you mean being started from the command line, or with SYSV
script instead of systemd?
Karaf by itself works fine without being started by systemd or SYSV init
for that matter. Karaf can be started from the command line and result
in the same console one sees when SSHing in.
But the way I've packaged it the start from command line behaviour isn't
easily accessible (and also easily combined with the daemon behaviour,
ie. diretories owned by user karaf. A karaf started from the command
line is typically used for development and run as the developers user).
I don't much like systemd myself. But I just figured "if there are two
alternatives, pick one, and pick the one most likely to be used in the
future".
Switching to SYSV wouldn't be hard (copy the SYSV scripts from the
source tarball and remove the disabing of SYSV maintscript generation,
and remove the use of systemd).
What's preferred from a debian viewpoint? SYSV? Or systemd?
>> logging to /var/log/syslog and using the following directories:
>> KARAF_ETC = /etc/karaf/
>> KARAF_HOME = /usr/share/karaf/
>> KARAF_DATA = /var/lib/karaf/data/
>> all directories are owned by user karaf, group karaf
> /etc/karaf should be root-owned. If it contains secrets,
> then root:karaf 2750, otherwise root:root 755.
The directory has to be karaf-writable, because karaf allows
configuration changes from the karaf console command line as well as
from the API.
There is one file that contains secrets (and that file does not have to
be writable by karaf, I think. But it has to be readable by karaf).
Applications may create their own configuration files in this directory,
so karaf needs to be allowed to create new files here.
> /usr/share/karaf MUST be root-owned, it is NOT writable
> during normal system operation (admins MAY mount /usr as
> read-only filesystem).
Hm... that's harder. Karaf creates stuff under $KARAF_HOME/instances/
One way of doing it would be to switch KARAF_HOME to /var/lib/karaf/
But there are stuff in KARAF_HOME that are read-only: the jar files (or
symlinks to jar files) in $KARAF_HOME/lib and $KARAF_HOME/system.
Would it be proper to install these under /var/lib/karaf/? Or would it
be best to leave them where they are, under /usr/share/karaf but to
create symlinks to them from /var/lib/karaf/ ?
>> IMO I'm not sure if this is worth the effort, because the karaf jar
>> files aren't really meaningful outside of karaf, or in a version
>> independent manner
> I agree. So I guess it boils down to packaging all libraries
> used to run karaf so it doesn’t use anything that’s not in
> Debian (otherwise, it’s at best usable in the contrib suite).
Ok on that. :-)
>> Thanks in advance to anyone who will create an official debian package,
>> whether it is based on my package or not! :-)
> Why not you, as part of the team, getting help from other
> team members, and someone sponsoring your uploads? You’re
> a user, so you can actually test changes and new versions;
> the rest is just mentoring you and doesn’t use it themselves.
Ok, I will try to create an official state package, when/if the
dependencies becomes available (and maintain it going forward, if noone
else wants to).
> Also: I’m impressed with the amount of work you did to
> document this all! Hats off.
Thanks! :-)
It was actually quite fun. And also easier to use the standard debian
tools than fpm that was used to package the package I found and forked
when googling for "karaf debian package", back in November 2016.
(I guess it helped that I was familiar with make and GNUMakefile syntax
so that the debian/rules file syntax wasn't a mystery).
Reply to: