search

mail-in-a-box / mailinabox

Mail-in-a-Box helps individuals take back control of their email by defining a one-click, easy-to-deploy SMTP+everything else server: a mail server in a box.
https://mailinabox.email/
Creative Commons Zero v1.0 Universal
14.02k stars 1.44k forks source link

Create .deb package for Debian and Ubuntu #183

Closed ipartola closed 8 years ago

ipartola commented 10 years ago

As per multiple requests from Hacker News, I think it'd be great to package mailinabox as a .deb package hosted on launchpad.net. Having looked at the scripts, I think I can do this as follows:

  1. Create a basic debian/control file which would list out all the package dependencies. These can still be repeated in the setup/*.sh files as apt-get is idempotent.
  2. Place all setup scripts, conf, etc. into /var/lib/mailinabox/.
  3. Create an executable at /usr/bin/mailinabox-setup which would be equivalent to running sh setup/start.sh.
  4. Optionally, run maininabox-setup after the package installs.
  5. Build out the rest of debian/* files, and make it easy to package mailinabox using launchpad.net for various Debian/Ubuntu releases.

Let me know if this sounds good/necessary and if I'm missing something.

JoshData commented 10 years ago

Interesting idea. I've never built a .deb before. How complex is this?

Some feedback:

  1. Why not /usr/lib?
  2. Nice idea. Can just be /usr/bin/mailinabox that symlinks to start.sh.
  3. Makes sense. This can always be disabled by DEBIAN_FRONTEND=noninteractive presumably.
  4. What goes into that?
ipartola commented 10 years ago

It's not a complex process. Basically, you create a directory called debian/ where you describe what the package should look like. debian/control contains things like the package name, description, build-time and runtime dependencies, etc. Other files under debian/* include pre and post install/uninstall scripts, copyright notice, additional files and directories, description of any documentation, etc. There is also a changelog file here, and all versioning is based on it. In the past I've based this on the git commit logs or just filled it in manually for every release.

  1. You are right, it should go under /usr/lib. /var/lib should contain package data, not this code.
  2. Symlink works, though we might want to either modify start.sh to tell you to run it as root, provide a --version flag, etc.
  3. I believe I can make it such that when you run apt-get interactively it will ask you all the questions. If you run it as a part of a script, it can run non-interactively, or not run /usr/bin/mailinabox at all.
  4. Basically, filling in lots of boilerplate in debian/*. To get it to build on launchpad.net is a bit interesting because you have to support various releases. I'd probably create a script that for the most part automates the build process.
JoshData commented 10 years ago

Gotcha.

For (4), we only need to support 14.04.

Also see #182 for discussion about other distros.

ipartola commented 10 years ago

Sounds good. Only supporting 14.04 makes it easier. Other than that, anything else I should be aware of? If not, I'll get started as soon as I have a bit of time.

JoshData commented 10 years ago

I can't think of anything else!

chuckpeters commented 10 years ago

I would expect to find the configuration files in /etc/mailinabox and perhaps some configuration options in /etc/default/mailinabox.

I would also expect the find the various package files conforming to FHS or Filesystem Hierarchy Standard. https://wiki.debian.org/FilesystemHierarchyStandard http://www.pathname.com/fhs/

JoshData commented 10 years ago

All user-configurable state is segregated from the system and stored in the STORAGE_ROOT (as set in /etc/mailinabox.conf). The idea is that this directory can get moved from machine to machine in order to migrate easily.

jmar71n commented 10 years ago

Rather than a deb made I'd prefer a docker image built off of the ubuntu base so I could grow and migrate the server much easier.

JoshData commented 10 years ago

Please see #112 for Docker. I would prefer that too (!) but the solution has eluded everyone that's tried so far.

chuckpeters commented 10 years ago

I think it would be a good idea to create a mailinabox team in Launchpad and it's probably best if Joshua is the team owner. It might make it a bit easier, say for example I wanted to update dnscrypt, mailman, roundcube or whatever we wouldn't need to point users to another Launchpad PPA.

MythTV can be updated with the stable+fixes routinely and the build process is automated, we could do something similar with mailinabox. Igor, are you going to automate the git pull, build and publish packages in Launchpad?

JoshData commented 10 years ago

Can we start with just creating a .deb and see how that works?

ipartola commented 10 years ago

First off, sorry for the delay.

I have finished up the initial "debianization" process and pushed it to my forked repo at https://github.com/ipartola/mailinabox. I have also uploaded a test .deb file to my PPA at https://launchpad.net/~ridgebit/+archive/ubuntu/ppa. I will continue working on ironing out the details, but wanted to check in on my progress so far.

Note on the details: I added a Makefile which is needed to actually install the package. Ideally, we want some way to uninstall mailinabox completely from the system, which could be a part of this Makefile or just another script that removes all the files that setup/start.sh installs.

JoshData commented 9 years ago

Closing due to inactivity and because I don't think right now this is the right approach to deploying Mail-in-a-Box.

JoshData commented 9 years ago

Reopening because now I think this is the right approach, and since #400/#406 I know more about how to actually make PPAs. :-P (also see #250, #566)

Hooloovoo commented 8 years ago

I don't pretend to be an expert, but my sense is that a Juju charm bundle would be better than a .deb - see: https://bugs.launchpad.net/charms/+bug/1313803 as a general statement, Juju charms are more about system setup and configuration, whereas debs are more about applications.

Note that Jorge Castro, who reported and commented on that issue, heads up the Juju team at Canonical IIRC, so I expect he would know.

Charms explicitly support linking together two applications to work together and distributing tools (actions) with the relevant application. Using Juju charms would certainly be more reusable, as any work to link applications or harden applications would be used by other bundles including those applications.

Hooloovoo commented 8 years ago

https://jujucharms.com/ https://jujucharms.com/docs/stable/authors-intro

JoshData commented 8 years ago

Closing again because while all this sounds great, this just isn't important enough to worry about.

gitacticia commented 8 years ago

It is, in the way, beeing a part of debian, you could gain multiply by (a huge number here) the users of MIAB, thus discovering new partners. The way to be a part of debian "main" is just a long long a incredibly strict way, but a large selection of best packages as achieved ....

bronson commented 8 years ago

Package sponsors actually make it pretty easy to get packages into Debian. The hard part is creating the .deb.

That said, I don't think that including a mail-in-a-box package in Debian is a very good idea. They take so long to stabilize a release that their packages are always grotesquely out of date. Also, lots of people would understandably apt-get install a mail-in-a-box onto any random host. (if you thought the forum is full of "how do I run PHP" posts now, just wait until people are apt-getting it onto their workstations!)

So, I agree with the conclusion... It doesn't seem like there's much to be gained by packaging it. Not enough to warrant the trouble anyway.

tabbyrobin commented 8 years ago

There's also a middle ground solution, going the torbrowser-launcher route. This would be a deb package that basically just includes the PGP signing pubkey and a couple of commands to pull down MIAB from the canonical location (git clone and git verify-*).

The benefits to ease of installation are relatively minimal -- going from 3-4 lines on the terminal to one. But the benefits to security could be pretty significant, since this would pin the MIAB signing key to the root of trust that is the distro repos.

This should(?) be implementable via any of the strategies discussed above:

For PPAs, Launchpad generates a signing key for you and automatically imports it when you do add-apt-repository. So there's a 3-step Ubuntu key -> PPA key -> JoshData's key, but this is all automated.

It seems like Juju would fit best conceptually with the deployment of MIAB, however juju is not installed by default on Ubuntu and this would add a level of unnecessary infrastructure to the process.

bronson commented 8 years ago

That's true. Piping to sudo'd bash is definitely smelly and end-to-end signature checks would be nice.

Hooloovoo commented 6 years ago

While Juju would likely be the best conceptual fit, a quick alternative that would much improve things over the bash command would be to package a snap: https://snapcraft.io/ These days that is normally the preferred alternative on Ubuntu (and other platforms) to a .deb in a PPA for good reason.

This would have the added two advantages for MIAB that: (1) It is built on a stable core, so you do not need to rebase each LTS. (2) The snap application is self-contained, separate from the system. No complex dependencies, and no interfering with each other.

I have been meaning to have a go at this to make a PoC for you, but have not found the time yet.