1

I have a python app with its setup.py that's working just fine to install it through setuptools. I am then packaging it up in DEB and PKGNG using the excellent Effing package management. I've also made some quick tests with setuptools-pkg and that seems to work too.

Now I have a need to distribute the packages including init scripts to start/stop/manage the service. I have my init scripts in the source repo and, according to what seems to be best practice, I'm not doing anything with them in setuptools and I'm handling them in the os-specific packaging: for debian-based systems I use the --deb-init, --deb-upstart and --deb-systemd FPM options as needed.

How can I build a FreeBSD package that includes the correct rc.d script, using FPM or through any other means?

All the examples I've seen are adding the rc.d script when building a package through the ports collection but this is an internal app and is not going to be published to the Ports or on PyPi. I want to be able to check out the repository on a FreeBSD system, launch a command that gives me a package, distribute it to other FreeBSD systems, install it using pkg and have my init script correctly deployed to /usr/local/etc/rc.d/<myappname>. There's no need to keep using FPM for that, anything works as long as it gives me a well-formed package.

Cœur
  • 37,241
  • 25
  • 195
  • 267
Luke404
  • 10,282
  • 3
  • 25
  • 31
  • 1
    Aren't `rc.d` scripts written by hand? So you just install it as regular file and it works? – arrowd Dec 10 '17 at 11:49
  • @arrowd yes we already have our working rc.d script. If you want to know more about rc.d script take a look at the [Practical rc.d scripting](https://www.freebsd.org/doc/en_US.ISO8859-1/articles/rc-scripting/) guide. This question is not about letting it work but about the distribution part, we'd like to package it together with the app and not having to manage it explicitly. – Luke404 Dec 10 '17 at 13:27

2 Answers2

2

I would highly suggest creating your package as if it were any other port either if is going to be published or not.

One of the advantages you can inherit by doing this is that you could also include all your test and automate the deployment having out of the box the base for a continues integration/delivery setup.

Check out poudriere. You could indeed maintain a set of custom ports with your very own settings and distribute them across your environments without any hassle: 

pkg install -r your-poudriere yourpkg

In case this is probably too much or probably doesn't adapt well to your use case, you can always fallback to ansible, in where you could create a custom rc.d within a template of an ansible role.

If you just want to build and deploy something, let's say a microservice, then probably pkg is not the best tool, maybe you just need a supervisor that can work on all your platforms (sysutils/immortal) so that you could just distribute your code and have a single recipe for starting/stoping the service.

nbari
  • 25,603
  • 10
  • 76
  • 131
0

nbari's answer is probably the Right Way™ to do this and I'd probably create my own "port" and use that to build the package on a central host.

At the time of my original question I had taken a different approach that I'm reporting here for the sake of completeness.

I am still building the applications package (ie. myapp-1.0.0.txz) with fpm -s python -t freebsd, which basically uses Python's setuptools infrastructure to get the necessary informations, and I don't include any rc.d file in it.

I also build a second package which I will call myapp-init-1.0.0.txz with the source directory type (ie. fpm -s dir -t freebsd) and I only include the init script in that package.

Both packages get distributed to hosts and installed, thus solving my distribution issue.

Luke404
  • 10,282
  • 3
  • 25
  • 31