Packaging scripts for linux distribution

April 11, 2017 4:36 PM

So I want to package a combination of system config files and scripts along with package dependencies for distribution on Linux (specifically Raspbian) - what's the right tool to do this? Docker? Snaps? A .deb file?

So I want to have some sort of installer that does the following things:
- installs prerequisite packages via apt-get
- creates some system config files under /etc
- adjusts some groups
- drops a script in /etc/init.d

I guess I could do this with a shell script but that seems kind of primitive. What's the best way to essentially customize existing linux packages? Docker seems like overkill but maybe it's the right thing.

posted by GuyZero to Computers & Internet (14 answers total)

Chef? Puppet? Ansible?
posted by oceanjesse at 4:51 PM on April 11, 2017

Response by poster: I do not need automated deployment or automated updates - this is just some hobby stuff that people would install manually. So I don't think I need any interoperation with chef or puppet.
posted by GuyZero at 4:53 PM on April 11, 2017

Typtically this is the purview of a configuration management system like Ansible or Chef. While an ansible playbook or a chef recipe would be a great thing to offer to those already familiar, requiring users to learn even the basics of an unfamiliar config management system is likely a non-starter. Given that you need to distribute config files and an init script, how about the old "clone a git repo, run make" (assuming you'd prefer to write a Makefile instead of a shell script, of course).

(on preview: looks like I was right about config management being overkill.)
posted by namewithoutwords at 4:54 PM on April 11, 2017

Response by poster: Yeah but I need to tweak group membership and files in /etc which seems like something I can't do with a simple git clone. But yeah, I could do it from a makefile I guess. (sorry for the threadsitting but I'm thinkin' out loud here)
posted by GuyZero at 4:57 PM on April 11, 2017

Best answer: Since you already are depending on apt-get, why not make a Debian package?
posted by advicepig at 5:07 PM on April 11, 2017 [5 favorites]

I generally use shell scripts and tarballs for this on my hobby systems. I have used chef and ansible for production systems, but IMHO they add more overhead than they're worth for small/hobby stuff. For a while I did use chef-solo; I had the cookbooks in a tarball in s3 and a small script that grabbed them and ran chef-solo at first boot. But even then I found that I was spending a lot more time futzing with chef than it would take me to achieve the same result the primitive way. For AWS systems these days I just have a custom AMI I use, and I fire up new instances from that, so they're ready to go immediately. If I need to make a change, I take a clean instance, make the tweak, build a new AMI from it, and then use that going forward.

Sometimes this kind of thing comes down to a decision about whether I want to take some extra time to do things the "right" way in order to learn and improve my skills, or if I don't care about gaining new skills and just want to get the job done with minimal headache...
posted by primethyme at 5:07 PM on April 11, 2017 [2 favorites]

Best answer: In my experience this is an install.sh script, with an optional post-install script or function to tidy up all the permissions and whatnot, and .deb files have the ability to run postinstall scripts.
posted by rhizome at 5:14 PM on April 11, 2017 [2 favorites]

Best answer: You want to create a .deb.

Simple example: https://ubuntuforums.org/showthread.php?t=910717

I guess, to be more clear: you absolutely do not want to use Ansible or Chef or Puppet. You're making something for distribution, not automation. Snap + docker are both 'okay' distribution methods, but Snaps are new and heavy weight and no one uses them. Docker is great for some niches, but not really your niche. Deb and/or RPM is the way to go.
posted by so fucking future at 5:45 PM on April 11, 2017 [4 favorites]

Best answer: so fucking future is right. This is exactly what debs do, if you're on an apt-based system.

The Maintainers' Guide might be a good starting point.
posted by fritley at 6:59 PM on April 11, 2017 [1 favorite]

Best answer: yep, a .deb package is the right way to do it.

- installs prerequisite packages via apt-get

list these in the Depends field of the control file

- creates some system config files under /etc
- drops a script in /etc/init.d

as well as installing these, you should list them in conffiles so they get proper config file handling on upgrade. (ie: when you release a new version of the package, if the user has tweaked their copies of these files they have the chance to retain their changes). the file in /etc/init.d is also a conffile, and should be handled exactly the same way as the other config files.

- adjusts some groups

addgroup and/or usermod -a -G in the postinst (assuming you're not installing files that need to be owned by a new group, in which case addgroup in the preinst)
posted by russm at 7:08 PM on April 11, 2017 [5 favorites]

Best answer: Nthing a plain package. There is a tool that makes creating Debian packages much easier than the process described in the maintainers guide, but I can't recall the name off the top of my head. I use it every time I make a package for something that isn't otherwise packaged, but it's been a good year or two so my brain isn't spitting it out.
posted by wierdo at 12:02 AM on April 12, 2017 [1 favorite]

Best answer: Note that you might prefer a systemd control file instead of the /etc/init.d script for newer versions of Debian. (Has Raspbian switched over yet)

And yes, a .deb file is definitely what you want - the package installer takes care of all sorts of edge cases for you.
posted by pharm at 12:31 AM on April 12, 2017

The way we used to do this when I was working on Solaris was to create a tarball:

1. Tar all the distributable files into a single file.

2. Create a shell-script that uncompresses the tar-file and does the copying and setting up.

3. Cat the shell-script and tar-file. Something like : cat install.sh files.tar > installer.sh.

4. Chmod +x the resulting file.

This way everything that's needed for distribution is contained within a single file. When the file is run, the install.sh can use arg-0 to get its own path and untar the distributable files. This works because the catalog for the tar-file is at the end of the tar, so prepending a script doesn't effect its functionality.
posted by veedubya at 4:55 AM on April 12, 2017

Best answer: Like everyone's said, you want a .deb package. It is designed for this purpose. If you want to share it with others you can publish it as a PPA. If it's a one-off thing for yourself that's not necessary, you can just manually copy the .deb to wherever you want to install it.
posted by Nelson at 8:47 AM on April 12, 2017 [1 favorite]