Teleport: Package the Installer for Common OS's

[andrewl3wis]

It would make my life easier if the Installer were packaged for various Linux Distro's, but I am actually after it being added to Homebrew so that it'd be easier for my end users to install. It's something that I can tackle, but would prefer that it was integrated by you guys so that it doesn't fall out of date if I miss a release a cycle.

[kontsevoy]

@Punkbob agreed. Right now we're a bit short of resources, how about you land us a hand getting this going, but we'll integrate your builds into our cycle?

[andrewl3wis]

A quick and dirty solution using fpm

OS X: fpm -verbose -s dir -t osxpkg -n teleport -v 1.0.5 ./teleport=/usr/local/bin/teleport /var/lib/teleport/ ./tsh=/usr/local/bin/tsh ./tctl=/usr/local/bin/tctl ./app/=/usr/local/share/teleport/app ./index.html=/usr/local/share/teleport/index.html

deb: fpm -verbose -s dir -t deb -n teleport -v 1.0.5 ./teleport=/usr/local/bin/teleport ./tsh=/usr/local/bin/tsh ./tctl=/usr/local/bin/tctl ./app/=/usr/local/share/teleport/app ./index.html=/usr/local/share/teleport/index.html

rpm should be just switching out rpm for deb.

Both of the compiled packages installed and seem to work, but I haven't done any extensive testing. Also neither are signed, but that tooling is pretty easy to setup.

[kontsevoy]

@Punkbob Thanks!

[molovo]

I have tried creating a homebrew formula for teleport, but ran into a wall because the binaries are trying to access the /var/lib/teleport directory internally, and I couldn't find a way of changing this. Would be better if there was a way of moving this to /usr/local/var/lib/teleport (possibly with an environment variable) so that it can play nicely with homebrew (and then not need sudo for the install), but I'm not familiar enough with the project to know how easy/hard this would be to implement.

[kontsevoy]

@molovo awesome, that will be easy to do. That location is configurable, perhaps we'll adjust the default behavior slightly. Quick q: can you drop a default teleport.yaml config file during installation? Where should Teleport look for it under brew?

Do you want to attach your formula to this ticket please? We also have community-submitted recipes for deb/yum, so hopefully we'll do them all at the same time for the next release.

This is awesome, thank you @molovo and @guanana

[molovo]

Yeah, that would be easy. Is it worth including the YAML file in the archive itself though? I imagine most package managers could make use of this.

The safe way of looking for the location would be to run $(brew --prefix teleport)/teleport.yml which will return the path. On a standard installation this would be /usr/local/opt/teleport/teleport.yml but the prefix locatoin can be configured by the user (plus in it's linuxbrew form the path would be under ~/.linuxbrew), so I wouldn't rely on a hardcoded path.

If we're including a config file, I can grab the prefix after the install and sed the correct path into the config file as part of the post_install step - plenty of other packages do exactly that.

class Teleport < Formula
  desc ""
  homepage ""
  url "https://github.com/gravitational/teleport/releases/download/v1.1.0/teleport-v1.1.0-darwin-amd64-bin.tar.gz"
  version "1.1.0"
  sha256 "04d44d63dc0e9d30397a5160181014f4aeb668a5c407b96f8d0a1abb7baf59e2"

  def install
    prefix.install Dir["*"]

    bin.install_symlink prefix/"tctl"
    bin.install_symlink prefix/"teleport"
    bin.install_symlink prefix/"tsh"

    share.install_symlink prefix/"app"
  end
end

@kontsevoy Above is all there is to the formula at the moment - it's quite an easy one. Once the formula's working I'll post a link to the pull request against homebrew.

[guanana]

I created a pull request with one script to create the RPM package, you just need to call it after the binary compilation. It generate automatically the SPEC file, untar and tar again the tarball with the expected structure and call the rpmbuild. Also I provide with the package a basic init.d and systemd scripts (check the system and install the proper one), also a basic teleport.yaml and post instructions to generate the certificate needed to the proxy server.

https://github.com/gravitational/teleport/pull/551

[kontsevoy]

@molovo can you please add the brew stuff with some instructions into build.assets/pkg/brew? @guanana just added rpm stuff in there, so we'll try to integrate native package building into our release process for the next version.

[bcg62]

Has there been a PR in to homebrew yet?

[bcg62]

Accepted into homebrew https://github.com/Homebrew/homebrew-core/pull/10854

[klizhentas]

@bcg62 👏 thanks!!!

[Omeryl]

Still wishing for Debian/Ubuntu/CentOS packages, this would make my life a ton easier. It seems most golang-based projects neglect this part :(.

[bcg62]

@Omeryl there are chef cookbooks and puppet modules for teleport which may help you.

https://github.com/johnbellone/teleport-cookbook
https://github.com/jaxxstorm/puppet-teleport

also here is a basic spec file for building teleport rpms, it's lacking systemd/init scripts

https://gist.github.com/bcg62/d3c4245d39c2ee7342b0b4fd756eb978

I don't have much to offer for Debian/Ubuntu as I don't use them.

[shaharmor]

What about init.d scripts? Anyone has one?

[bcg62]

the puppet module has a template you could use

https://github.com/jaxxstorm/puppet-teleport/blob/master/templates/teleport.init.erb

[Orad]

The lack of a package management support stops me from using this. how does one get security updates for something so crucial such as SSH server?
Am I missing something ?

[Omeryl]

@Orad Nope, not missing anything, they still expect us to package everything ourselves.

[aberoham]

I have had two offline requests for RPMs recently, in both cases for smaller deployments where the admins do not have an established internal build / packaging pipeline and expect an upstream .spec if not an actual dnf (yum) compatible repository. One asked for RHEL7 and another asked for Amazon Linux RPMs. (Not sure if they run https://aws.amazon.com/amazon-linux-2/ w/systemd)

[aberoham]

Another out-of-band request for RPMs, saving here for posterity --

Y'all _really_ ought to have RPMs available. The release tarballs have a script to generate an RPM, that doesn't work out-of-the-box [...] and the quality of that rpm is spotty at best. Installing to /opt, then symlinking and making /etc/teleport at such in the postinstall step? Bad form. Please consider an rpm spec file like the attached for CentOS / RHEL 7.x"

teleport.spec.txt

[jclusso]

So will this ever happen? Would be super helpful.

[aberoham]

@jclusso take a peek at https://github.com/gravitational/repo

[Omeryl]

@aberoham is that a private repo...?

[aberoham]

Ah, yes, sorry! Let me ping the team to see about moving the bits to a public repo

[Omeryl]

@aberoham any news?

[jclusso]

@aberoham still waiting for someone to hopefully make that repo public! :)

[dreamcat4]

This is an interesting topic. Have been hacking at a rather limited shell script for distributing installing teleport to target nodes. My conclusions are (it being only half finished):

• fpm seems like a good idea for generating those packages which it supports.
• However there may also be other platforms / targets not supported by fpm AND teleport is just a few statically compiled (fully contained) binaries. So it aught to still be easy to distribute even without a proper package.

It seems that the tool makeself is the most commonly cited tool for making a linux self extracting installer.

What I have done myself is getting my script to generate a custom .tar.gz archive on the fly. Which also contains within it the target node's teleport.yaml file, and also the initial registration token. I then rename the archive file to include the expiry date of that token as a part of it's filename and copy the archive over to the target node, unzip it. And then run a simple little script that symlinks the teleport binaries in /var/lib/teleport/bin/ folder to also appear within /usr/local/bin/. So that they will appear on the system's default "$PATH".

The same initialization script then also detects the systems external ip. Writes that to advertise-ip: in the teleport.yaml. (for some specific reason or bug #2770 it seems to be necessary to manually configure the external IP on a per-node basis). Anyhow after doing that little bit of necessary setup, a systemd service file is then installed for teleport. And it is immediately started via systemd.

I think my approach could be improved by using makeself as a fallback. Instead using a .deb file (or rpm, .pkg / whatever). If the distro supports a proper package manager.

Also my script only supports systemd. Which ofc is not going to work for OSes that don't use systemd (macos, alpine linux, android, etc...). So it is far from being complete.

I think I want to do makeself first of all. SO that there is a decent generic fallback mechanism. Then after that consider adding an option for getting fpm to make a .deb. However fpm is written in ruby, so that is an extra dependancy for running this tool in that mode.

I suppose if people really like this sort of approach is all well and good. For everyone to use it, and contribute back support for those missing platforms for which I cannot test myself. But it's all shell script. Maybe a better official solution for this project would be to rewrite that all natively in go. So that it could be included as a self provisioning feature into one of the main existing teleport binaries.

BTW my solution is meant to be run on the cluster (to generate the short lived token). So it always assumes that you want the same version of teleport running on target nodes as the cluster. For best compatibility. By just copying whatever the teleport binaries are first found on the search path with $(which teleport) and $(which tctl) etc. So it's all pretty dumb in that regards.

Also for upgrading. Thing is: if your nodes are already up and running. Then we can run commands on them. Then it should be possible to an in-place upgrade to them, with a single command. Which then in turn poses bigger questions about how to properly handle that in the most robust way possible. (assuming this is something that enterprises will want to use for their deployments). For example: what happens if you find there is an issue with the latest version, and then want an option to roll back to the previous version?

Currently my folder structure looks like this:

/var/lib/teleport/
/var/lib/teleport/teleport.yaml
/var/lib/teleport/bin/
/var/lib/teleport/bin/teleport-install
/var/lib/teleport/bin/teleport
/var/lib/teleport/bin/tsysinfo
/var/lib/teleport/bin/tctl
/var/lib/teleport/bin/tsh
/var/lib/teleport/systemd/
/var/lib/teleport/systemd/teleport.service

Then after unpacking everthing to live under /var/lib/teleport. Is when the post-install script either copies or symlinks to the distro-specific locations (for the binaries to be on $PATH, and for the systemd service file). The reason it does things that way, is to be more broadly inter-compatible for all target platform(s). Regardless of their' different and conflicting conventions / fs-hierachy requirements. Since assuming distro A by definition would make the archive incompatible with distro B.

Perhaps I should do some more basic work on this. So many glaringly bad things about it. For example I should rename teleport-install to teleport-post-install. Or whatever. Might just have to be rewriting a lot of it anyhow. Thing is: if i do that. Then why not do it in GO instead? Well personally I don't know GO, so it is likely that somebody else would be far better suited to that task. Just rambling at this point.

[kontsevoy]

@dreamcat4 thank you for this! we'll definitely use your help when we get around to implementing this.

[dreamcat4]

@kontsevoy Hey there! Thank you for the kind words.

Since then I have been working to produce a better packaging shell script. That tries its best to address as many (as I can!) of those issues I had previously mentions about earlier. (but still all as sh shell script I'm afraid) You guys will then basically have a working protoype tool, to see which features people actualy care about and use (or not!). Like a menu of the types of features you might want to pick and choose from. If you ever want to be re-implementing any of it as go code, to integrate back into the main project.

I plan to release all my work very soon as a separate contrib repository, called teleport-sh-extras. Unless you have any other type of preferences for it / wish me to do otherwise then please say so. All my teleport helper scripts will be released under the exact same apache 2 license (as your project), and I will mark the copyright for them as being under public domain copyright. So you guys will have no restrictions whatsoever as to how you wish to make use of any such code or helper scripts going forwards. You will be free to copy / take from them however you wish.

[dreamcat4]

Hello again !
Comprehensive packaging / deployment 3rd party script tdeploy. Now has been released today. Plus some other extras are now uploaded and available at:

https://github.com/dreamcat4/teleport-sh-extras

It's got full documentation in the readme ^^ fwiw. Enjoy!

If you need to build rpms, or other types of packages (for MacOS or other less common platforms). Then you will need to contribute and fill in the stubs code with that is missing. Again, full explanation about all that is also fully documented in the readme file over there. Kind Regards.

[webvictim]

I've written build scripts and added Makefile support for producing Teleport RPM/DEB packages on Linux (using fpm) and PKG packages on Mac. This is in the process of being tested and having support added to the web portals that host our downloads - I am hopeful that we will start building and hosting Teleport packages for public download as of Teleport v4.1.

@dreamcat4 Thanks for all your work on this. We've gone our own way with packaging for now, but I'll take a look at everything you added for the future.

[webvictim]

Teleport 4.1.0 was released today, and with this release comes something we've been waiting a long time for...

We now build 32- and 64-bit RPM and DEB packages for Linux, in addition to 64-bit .pkg files for Mac. These downloads are available to both OSS and Enterprise users.

The OSS packages are available for download here: https://gravitational.com/teleport/download

I'm very pleased to be able to close this one out and hope that the packages make your lives easier!

:boom: