News

7 Mar 2022

[Blog] MistServer and Secure Reliable Transport (SRT)

Hello everyone, this article is about using Haivison SRT together with MistServer. What is Secure Reliable Transport (SRT)? Secure Reliable Transport, or SRT for short, is a method to send stream data over unreliable network connections. Do note that it is...

Hello everyone, this article is about using Haivison SRT together with MistServer.

What is Secure Reliable Transport (SRT)?

Secure Reliable Transport, or SRT for short, is a method to send stream data over unreliable network connections. Do note that it is meant for server traffic, there are no SRT players. The main advantage of SRT is that it allows you to push a playable stream over networks that otherwise would not work properly. However, keep in mind that for "perfect connections" it would just add unnecessary latency. So it is mostly something to use when you have to rely on public internet connections.

How to use SRT in MistServer

SRT is implemented to behave like srt-live-transmit, so using SRT under MistServer should feel familiar if you’re familiar with the usage of srt-live-transmit. Filling in a host on one side implies caller mode while leaving the host out implies listener mode.

The only difference is that you do not set up the input or output side depending on how you’re using SRT. You will only need to set up one side of the connection as the other side will be implied by the usage. If you can also overwrite any “default” setting by using ?mode=listener/caller

General information

Not setting a host will imply Listener mode for the input/output Setting a host will imply Caller mode for the input/output You can always overwrite a mode by using ?mode=caller/listener as a parameter Not setting a host will default the bind to: 0.0.0.0

SRT INPUTS

Both caller/listener inputs are set up through setting up a new stream through the stream panel.

SRT LISTENER INPUT

This input is set up by creating/editing a new stream and setting the following source:

srt://:port

By leaving out the host you will imply Listener mode, thus instructing MistServer to look at all available addresses on the given port for SRT stream data. Another method would be:

srt://[host]:port?mode=listener

This will force MistServer to open the given address/port as listener mode (host is optional, if left out 0.0.0.0 will be used).

If no SRT data is given it will behave like other MistServer inputs, if set to “always on” it will keep on trying and trying. If set to “default” it will try for about 20 seconds, then retry once a new viewer tries to open the stream.

SRT CALLER INPUT

This input is set up by creating/editing a new stream and setting the following source:

srt://host:port

By setting the host you will put the SRT input in caller mode, thus instructing it to connect to the given address/port and look for SRT data to receive.

Another method would be:

srt://[host]:port?mode=caller

Though not recommended you could use this to set up caller mode. The reason why it’s unrecommended is that giving a host already implies caller mode and leaving host out will default to 0.0.0.0 which is nonsensical for a caller mode.

SRT Outputs

Both Styles are available through the push panel, Listener output is available through the protocol panel as well.

SRT LISTENER OUTPUT

Two methods to set this up, a “sort of” temporarily through the push panel and a more permanent one through the protocol panel.

Push panel style

Setting up SRT LISTENER output through the push panel is done through the Push panel and setting up a push stream with target:

srt://:port

Alternatively

srt://[host]:port?mode=listener

This will set up MistServer to push out the stream and accept incoming connections. Those that connect will jump to the current live point of the stream, whether it’s Live or VoD. There is no starting from the beginning here. The push will stop once it reaches the stream end or the source input disappears.

Protocol Panel Style

Setting up SRT Listener output through the protocol panel is done by selecting TS over SRT and setting up the following:

  • Set up the source input by filling in the stream name.
  • Choose a port (optional: Host too)

This will start the input and make the stream available for viewers. VoD files will always start at the beginning of the VoD file, while Live streams will go to the most live point.

SRT CALLER OUTPUT

This is only done through the push panel, set up a new push and use the following target:

srt://host:port

Alternatively

srt://[host]:port?mode=caller

Again, the alternative mode is not recommended as it does not make much sense. Setting an SRT output in caller mode will connect to an SRT listener and start pushing if it makes a connection. VoD will always start at the beginning and live will start at the most live point. If there is no connection made within ~10 seconds it will close down and only start up if it is an automatic push with retry enabled.

All SRT over a single Port

SRT can also be set up to work through a single port using the ?streamid parameters. Within the MistServer Protocol panel you can set up SRT (default 8889) to accept connections coming in, out or both.

If set to incoming connections, this port can only be used for SRT connections going into the server. If set to outgoing the port will only be available for SRT connections going out of the server. If set to both, SRT will try to listen first and if nothing happens in 3 seconds it will start trying to send out a connection when contact has been made. Do note that we have found this functionality to be buggy in some implementations of Unix (Ubuntu 18.04) or highly unstable connections.

Once set up you can use SRT in a similar fashion as RTMP or RTSP. You can pull any available stream within MIstServer using SRT and push towards any stream that’s setup to receive incoming pushes. It makes the overall usage of SRT a lot easier as you do not need to set up a port per stream.

Pushing towards SRT using a single port

You can push towards a MistServers incoming SRT connection port using:

srt://host:port?streamid=streamname

Do note that the stream has to be set up to accept incoming pushes.

Pulling SRT from MistServer using a single port

You can pull from a MistServer using it’s outgoing SRT connection port:

srt://host:port?streamid=streamname

Known issue in some of the Linux OSs (like Ubuntu 18.04)

The SRT library we use for the native implementation has one issue in some Linux distros. Our default usage for SRT is to accept both incoming and outgoing connections. Some Linux distro have a bug in the logic there and could get stuck on waiting for data while they should be pushing out when you're trying to pull an SRT stream from the server. If you notice this you can avoid the issue by setting a port for outgoing SRT connections and another port for incoming SRT connections. This setup will also win you ~3seconds of latency when used. The only difference is that the port changes depending on whether the stream data comes into the server or leaves the server.

Recommendations and best practices

The most flexible method of working with SRT is using SRT over a single port. Truly using a single port brings some downsides in terms of latency and stability however. Therefore we recommend setting up 2 ports, one for input and one for output and then using these together with ?streamid parameters.

Getting SRT to work better

There are several parameters (options) you can give to any SRT url to set up the SRT connection better, anything using the SRT library should be able to handle these parameters. These are often overlooked and forgotten as most first users tend to just fill in the urls and see it does not work how they would like it to and stop trying there and then. Now understand that the default settings of any SRT connection cannot be optimized for your connection from the get go. The defaults will work under good network conditions, but are not meant to be used as is in unreliable connections.

A full list of options you can use can be found in the SRT documentation. Using these options is as simple as setting a parameter within the url, making them lowercase and stripping the SRTO_ part. For example SRTO_STREAMID becomes ?streamid= or &streamid= depending on if it’s the first or following parameter.

We highly recommend starting out with the parameters below as these make all the difference in the world for stream quality especially with bad connections where SRT should be used.

Latency

latency=miliseconds

This is what we consider the most important parameter to set for unstable connections. Simply put, it is the time SRT will wait for other packets coming in before sending it on. As you might understand if the connection is bad you will want to give the process some time. It’ll be unrealistic to just assume everything got sent over correctly at once as you wouldn’t be using SRT otherwise! Haivision themselves recommend setting this as:

RTT_Multiplier * RTT

RTT = Round Time Trip, basically the time it takes for the servers to reach each other back and forth. If you’re using ping or iperf remember you will need to double the ms you get.

RTT_Multiplier = A multiplier that indicates how often a packet can be sent again before SRT gives up on it. The values are between 3 and 20, where 3 means perfect connection and 20 means 100% packet loss.

Now what Haivision recommends is using their table depending on your network constraints, however if you are anything like me and do not want to spend time on such calculations I would recommend using the following and going up a step whenever you see it is still not working properly:

1:  4 x RTT
2:  8 x RTT
3: 12 x RTT
4: 16 x RTT
5: 20 x RTT 

While it is not the best setting, it does get the job done. You might lose out on latency, but our priority with SRT is ensuring stream stability, not latency.

Packetfilter

packetfilter=fec-options

This option enables forward error correction, which in turn can help stream stability. A very good explanation on how to tackle this is available here. Important to note here is that it is recommended that one side has no settings and the other sets all of them. In order to do this the best you should have MistServer set no settings and any incoming push towards MistServer set the forward error correction filter.

Our personal default setting is:

?packetfilter=fec,cols:8,rows:4

We start with this and have not had to switch it yet if mixed together with a good latency filter. Now optimizing this is obviously the best choice, but using “something” is already better than nothing in this case.

Combining multiple parameters

To avoid confusion, these parameters work like any other parameters for urls. So the first one always starts with a ? while every other starts with an &.

Example:

srt://mistserveraddress:8890?streamid=streamname&latency=16000&packetfilter=fec,cols:4,rows:4

Conclusion

Hopefully this should've given you enough to get started with SRT on your own. Of course if there's any questions left or you run into any issues feel free to contact us and we'll happily help you!

read moreless
14 Feb 2022

[Blog] Migration instructions between 2.X and 3.X

With the release of 3.0, we are releasing a version that has gone through extensive rewrites of the internal buffering system. Many internal workings have been changed and improved. As such, there was no way of keeping compatibility between running previous...

With the release of 3.0, we are releasing a version that has gone through extensive rewrites of the internal buffering system.

Many internal workings have been changed and improved. As such, there was no way of keeping compatibility between running previous versions and the 3.0 release, making a rolling update without dropping connections not feasible.

In order to update MistServer to 3.0 properly, step one is to fully turn off your current version. After that, just run the installer of MistServer 3.0 or replace the binaries.

Process when running MistServer through binaries

  • Shut down MistController
  • Replace the MistServer binaries with the 3.0 binaries
  • Start MistController

Process when running MistServer through the install script

Shut down MistController Systemd:

systemctl stop mistserver

Service:

service mistserver stop

Start MistServer install script:

curl -o - https://releases.mistserver.org/is/mistserver_64Vlatest.tar.gz 2>/dev/null | sh

Process for completely uninstall MistServer and installing MistServer 3.0

Run:

curl -o - https://releases.mistserver.org/uninstallscript.sh 2>/dev/null | sh

Then:

curl -o - https://releases.mistserver.org/is/mistserver_64Vlatest.tar.gz 2>/dev/null | sh

Enabling new features within MistServer

You can enable the new features within MistServer by going to the protocol panel and enabling them. Some other protocols will have gone out of date, like OGG (to be added later on), DASH (replaced by CMAF) and HSS (replaced by CMAF, as Microsoft no longer supports HSS and has moved to CMAF themselves as well). The missing protocols can be removed/deleted without worry. The new protocols can be added manually or automatically by pressing the “enable default protocols” button

Rolling back from 3.0 to 2.x

Downgrading MistServer from 3.0 to 2.x will also run into the same issue that it is unable to keep connections active, which means you will have to repeat the process listed above with the end binaries/install link being the 2.x version. If you deleted the old 2.X protocols during the 3.X upgrade, you will have to re-add them using the same “enable default protocols” method as well. It is safe to have both sets in your configuration simultaneously if you switch between versions a lot, or need a single config file that works on both.

read moreless
14 Feb 2022

[Blog] Why is all of MistServer open source?

Hey there! This is Jaron, the lead developer behind MistServer and one of its founding members. Today is a very special day: we released MistServer 3.0 under a new license (Public Domain instead of aGPLv3) and decided to include all...

Hey there! This is Jaron, the lead developer behind MistServer and one of its founding members. Today is a very special day: we released MistServer 3.0 under a new license (Public Domain instead of aGPLv3) and decided to include all the features previously exclusive to the "Pro" edition of MistServer as well. That means there is now only one remaining version of MistServer: the free and open source version.

You may be wondering why we decided to do this, so I figured I'd write a blog post about it.

First some history! The MistServer project first started almost fifteen years ago, with a gaming-focused live streaming project that was intended to be a rival to the service that would later become known as Twitch. At the time, we relied on third-party technology to make this happen, and internet streaming was still in its infancy in general. Needless to say, that project failed pretty badly.

During a post-mortem meeting for that failed project, the live streaming tech we relied on came up as one of the factors that caused the project to fail. In particular how this software acted like a black box, and made it very tricky to integrate something innovative with it. The question came up if we could have done better, ourselves. We figured we probably could, and decided to try it. After all, how hard could it be to write live streaming server software, right..?

What we thought would be a short and fun project, quickly turned into something much bigger. The further we got, the more we discovered that video tech was - back then especially - a very closed off industry that is hard to get into. As we worked on the software, we came up with the idea that we wanted to change this. Open it up to newcomers, like we ourselves had tried, and make it possible for anyone with a good idea to make a successful online media service. There were several popular free and open source web server software packages, like Apache and Nginx - but all the media server software was closed (and usually quite expensive, as well). We wanted to do the same thing for media server software: create something open, free, and easy to use for developers of all backgrounds to enable creativity to flourish.

However, we also had people working on this software full-time that most definitely needed to be paid for their efforts. So while the first version of MistServer was already partially open source, we made a few hard decisions: we kept the most valuable features closed source, and the parts that were open were licensed under the aGPLv3. That license is an "infectious" open source license: it requires anyone communicating over a network with the software to get the full source code of the whole project. That would make it almost impossible to use in a commercial environment - both because of the missing features as well as the aggressive license.

That allowed us to then sell custom licensing and support contracts, while staying true to the ideas behind open source. Our plan was to eventually - as we had built up enough customer base and could afford to make this decision - release the whole software package as open source and solely sell support and similar services contracts. As we were funded by income from license sales, our growth was fairly restricted and thus slow and organic. We built up a good reputation, but were nowhere near being able to proceed with the plan we made at the start.

Over the years, we slowly did release some of the closed parts as open, but we had to be careful not to "give away" too much. To non-commercial users, we made available a very cheap version of the license without support. Our license and support contracts over time evolved to be mostly about support, and licensing itself more of an excuse to start discussing support terms. From my own interactions with our customers it has become clear that they stay with us because of the support we offer, and consider that the most valuable part of their contracts with us. However, the constrained growth did mean we were not able to fully commit to a business model that did not involve selling licenses.

Until, last October, Livepeer came along. They have a similar goal and mindset as the MistServer team did and does, which meant they not only understood our long-term plan, but believed that with the increased funding flow they brought to us, it could now finally be executed!

So, it may seem like a sudden change of course for us to release the full software as open source today, but nothing could be further from the truth. It's something we've believed in and have been wanting to do right from the start of the project. Words are lacking to describe how it feels to finally be able to come full circle and complete a plan that has been so long in the making. It's an extremely exciting moment for us, and I speak for the whole team when I say we're looking forward to continuing to improve and share MistServer with the world.

read moreless
1 Mar 2020

[Blog] Skins for the MistServer Meta-player

Hi there! In January 2019 we released MistServer 2.15, which included our reworked meta-player: a player that selects the best streaming protocol and player for the used stream and browser. New in this rework is just how much it can be...

Hi there! In January 2019 we released MistServer 2.15, which included our reworked meta-player: a player that selects the best streaming protocol and player for the used stream and browser. New in this rework is just how much it can be customised - change just a few colours, add your logo or completely overhaul the look and feel: everything is possible.
In this post I, Carina, would like to highlight a few of these skinning capabilities.

I will assume you already have some knowledge of how to embed the player on your page, and of how HTML, Javascript and CSS works.

Let's transform the appearance of the meta-player from its default look of this:

..to this:

I'll take you through the steps one by one, so that you'll be able to use what you want for your own project.
You can find the files I used for this example here.

The basics

So, how do we change the way the player looks? Well, the bit of Javascript that builds the player, mistPlay(), accepts options, and one of those is the skin option.
You can read more about all the possibilities in our manual in chapter 5.4.

The entire skin can be defined in the options that are given to mistPlay(), or it can be defined elsewhere and the skin name can be passed to mistPlay() instead. It'll look something like this:

mistPlay(streamname,{
  skin: {
    colors: { accent: "red"; }
  }
});

or

MistSkins.custom = {
  colors: { accent: "red"; }
};
mistPlay(streamname,{
  skin: "custom"
});

The key thing to remember when defining a skin is that your settings are parsed as changes to the default skin. That means you don't have to build everything from scratch, you can just change what you'd like to see differently. Should you want to base your work on another skin, you can specify it like this:

MistSkins.even_more_custom = {
  inherit: "custom"
}

1) Change a colour

Let's start small.
Suppose I have this awesome website, and I've used red accents to spice things up or highlight certain features. Wouldn't it be nice if the player also used this same colour? We could change other colours too, but they are more neutral so let's leave those alone.

The skin object would become:

MistSkins.step1 = {
  colors: {
    accent: "red"
  }
};

Of course, you don't have to use a named colour. You can use any colour definition that CSS would understand.

Now, the player looks like this:

2) Add a CSS rule

The default skin has a rather pronounced background. Say we'd like to see something more subtle. What about a gradient? That'd be pretty cool right?
If we use the web inspector to inspect the control bar, we can see that the element with class mistvideo-main has the background colour. That means we should probably add a CSS rule to override it.
CSS rules for a skin are taken from a file. This is how you add a new one:

MistSkins.step2 = {
  inherit: "step1",
  css: { custom: "myskin.css" }
};

The file itself can contain pure CSS, but it can also have variables, marked with a dollar sign. These are replaced with the values that are defined within the colors object. (We don't use CSS variables because they are not supported in older browsers that the player does need to support)

To set a background gradient, let's put in this:

.mistvideo-main {
  background: linear-gradient(to top, $background ,transparent);
}

Now the control bar background will be the black background colour (inherited from the default skin) fading to transparent.

While I'm there, I'm going to give the buttons a bit more breathing room, and I've also decided I'd like to see our red accent colour a bit more often.

.mistvideo-main > * {
  margin-right: 0.5em;
}

.mistvideo-controls svg.mist.icon:hover .fill,
.mistvideo-controls svg.mist.icon:hover .semiFill,
.mistvideo-volume_container:hover .fill,
.mistvideo-volume_container:hover .semiFill {
  fill: $accent;
}
.mistvideo-controls svg.mist.icon:hover .stroke,
.mistvideo-volume_container:hover .stroke {
  stroke: $accent;
}

The player now looks like this:

3) Adding a logo

To further personalise the player, let's add a logo to the top right of the video.

We can override parts of the way the elements are arranged in the DOM through the structure object. In this case we're looking for the part that's called videocontainer.

It's probably easiest to steal the videocontainer structure from the default skin, and then add the logo to it. To do this, open the web inspector on a page where the Meta-player is active, go to the console and type MistSkins.default.structure.videocontainer.

You should get this as an answer: {type: "video"}

That means that the videocontainer structure currently consists of one element, represented by an object with type: "video". It's referring to what we call a blueprint named video, that will return a DOMelement containing the video tag. We'll want to change the videocontainer to a div, that contains both our logo and the video element. This is how:

MistSkins.step3 = {
  inherit: "step2",
  structure: {
    videocontainer: {
      type: "container",
      children: [
        {type: "video"},
        {
          type: "logo",
          src: "//mistserver.org/img/MistServer_logo.svg"
        }
      ]
    }
  }
}

I'll add some styling to the CSS as well. An element generated by a blueprint will always receive mistvideo-<BLUEPRINT TYPE> as a class.

.mistvideo-logo {
  position: absolute;
  width: 10%;
  top: 1em;
  right: 1em;
  filter: drop-shadow(#000a 1px 1px 2px) brightness(1.2);
}

And tadaa, here's the logo!

4) Change the structure

There's a bunch of buttons on the control bar, some of which might not make sense for the video's you're streaming. Let's clean it up a bit!

This time we'll need to adapt the controls structure. This one is quite a bit more complicated than the videocontainer one.. Let's retrieve the default one again. To get something copy-paste-able, use this:
JSON.stringify(MistSkins.default.structure.controls,null,2)

I've put the progress bar at the bottom as it was floating around in mid air a little, I've moved the currentTime and totalTime blueprints to the right of the control bar, the volume control to the left, and I've removed the loop, fullscreen and track switcher controls.
That gives me this:

MistSkins.step4 = {
  inherit: "step3",
  structure: {
    controls: {
      type: "container",
      classes: ["mistvideo-column", "mistvideo-controls"],
      children: [
        {
          type: "container",
          classes: ["mistvideo-main","mistvideo-padding","mistvideo-row","mistvideo-background"],
          children: [
            {
              type: "play",
              classes: ["mistvideo-pointer"]
            },
            {
              type: "container",
              children: [
                {
                  type: "speaker",
                  classes: [
                    "mistvideo-pointer"
                  ],
                  style: {
                    "margin-left": "-2px"
                  }
                },
                {
                  type: "container",
                  classes: [
                    "mistvideo-volume_container"
                  ],
                  children: [
                    {
                      type: "volume",
                      mode: "horizontal",
                      size: {
                        height: 22
                      },
                      classes: [
                        "mistvideo-pointer"
                      ]
                    }
                  ]
                }
              ]
            },
            {
              type: "container",
              classes: ["mistvideo-align-right"],
              children: [
                {type: "currentTime"},
                {type: "totalTime"}
              ]
            }
          ]
        },
        {
          type: "progress",
          classes: ["mistvideo-pointer"]
        }
      ]
    }
  }
};

The player now looks like this:

5) Changing an icon

But we can do more than just moving elements around. We can also change the way something looks. Let's say we want to change the way the volume is displayed to a simple horizontal slider with a circle.

The volume blueprint constructs the element from the icon library. It can be overridden like this:

MistSkins.step5 = {
  inherit: "step4",
  icons: {
    volume: {
      size: {
        width: 100,
        height: 50
      },
      svg: `
        <rect y="21" width="100%" height="15%" fill-opacity="0.5" class="backgroundFill"/>
        <rect y="21" width="50%" height="15%" class="slider horizontal fill"/>
        <g transform=translate(10,0)>
          <svg width="50%" height="100%" class="slider horizontal">
            <g transform=translate(-10,0)>
              <circle cx="100%" cy="25" r="10" class="fill"/>
            </g>
          </svg>
        </g>
      `
    }
  }
};

It now contains a full length black rectangle.
On top of that, there's another rectangle with the class "slider horizontal". The volume blueprint will change the width of this element to display the volume level.
Lastly, there's a nested svg containing the circle marking the end of the volume level indicator.

Because the tooltip is rather big for this more minimalistic volume bar, I've added some CSS rules to our file:

.mist.icon .backgroundFill {
  fill: $background;
}
.mistvideo-volume .mistvideo-tooltip {
  bottom: auto !important;
  top: -2.5px !important;
  left: 2.5px !important;
  font-size: 0.8em;
  padding: 0;
  background: none;
}
.mistvideo-volume .mistvideo-tooltip .triangle {
  display: none;
}

Now, our player looks like this:

6) Using a hoverWindow blueprint

The last thing I'm not happy with is that the volume slider is always visible. There's really no need, it's okay if it only shows up when the cursor is above the speaker icon. To achieve that, we can put the volume slider inside a blueprint that's called a hoverWindow. The hoverWindow accepts a structure object as a 'button'. When the cursor hovers over that element, the structure object that's defined as the 'window' is shown.

MistSkins.step6 = {
  inherit: "step5",
  structure: {
    controls: {
      type: "container",
      classes: ["mistvideo-column", "mistvideo-controls"],
      children: [
        {
          type: "container",
          classes: ["mistvideo-main","mistvideo-padding","mistvideo-row","mistvideo-background"],
          children: [
            {
              type: "play",
              classes: ["mistvideo-pointer"]
            },
            {
              type: "hoverWindow",
              mode: "right",
              transition: {
                show: "opacity: 1",
                hide: "opacity: 0",
                viewport: "overflow: hidden"
              },
              classes: ["mistvideo-volume_container"],
              button: {
                type: "speaker" //mute/unmute button
              },
              window: {
                type: "volume", //volume slider
                mode: "horizontal",
                size: {height: 22}
              }
            },
            {
              type: "container",
              classes: ["mistvideo-align-right"],
              children: [
                {type: "currentTime"},
                {type: "totalTime"}
              ]
            }
          ]
        },
        {
          type: "progress",
          classes: ["mistvideo-pointer"]
        }
      ]
    }
  }
};

All done! The player now looks like this:

Conclusion

I hope that's shown you just how customizable our Meta-player is. Did you get ideas for your own projects? We'd love to see what you've made! Also feel free to contact us if there's something you're stuck on which you can't find in the manual, or if you have any suggestions.

Bye for now, and see you next time!

read moreless
28 Oct 2019

[Blog] Easy SSL for MistServer through Certbot (Linux-specific)

Hello everyone! This post we wanted to highlight a new feature in the latest MistServer builds (since version 2.17). This version not only added an integration with CertBot for Let’sEncrypt SSL certificates, but also added all SSL functionality to the...

Hello everyone! This post we wanted to highlight a new feature in the latest MistServer builds (since version 2.17). This version not only added an integration with CertBot for Let’sEncrypt SSL certificates, but also added all SSL functionality to the Open Source edition of MistServer.

Before we start: if you're using MistServer together with a webserver (as in running MistServer on the same server that is hosting your website) we recommend using a reverse proxy. It just makes more sense to have a single SSL certificate, and this will also allow you to run MistServer on the same port as your website which looks more professional. So, this guide is only useful for setups that run MistServer “standalone”, without a webserver on the same machine. That said, let's dig into it!

With version 2.17 of MistServer we added a new tool in your MistServer install called “MistUtilCertbot”. This tool takes care of Certbot integration, meaning the entire setup can now be done with just a single command! (After both MistServer and Certbot are installed first, of course.)

Install Certbot Certbot is a *Nix only tool that's meant for easy SSL certificate management. It's a package in most distributions of Linux, so we recommend using your distribution’s package manager to install it. More information on Certbot can be found here, and distribution-specific instructions can be found here.

Run MistUtilCertbot through Certbot Once installed you can have Certbot set up your MistServer HTTPS certificate by running the following command (run this command as the same user you would usually run certbot as; it does not matter what user MistServer is running as):

certbot certonly --manual --preferred-challenges=http --manual-auth-hook MistUtilCertbot --deploy-hook MistUtilCertbot -d DOMAIN01 -d DOMAIN02 -d ETC

You'll have to change the DOMAIN01,DOMAIN02,ETC part into your own domain(s), other than that there’s no need to make changes.

Set up auto-renewing of CertBot certificates This differs per distribution, so we recommend following the “Set up automatic renewal” step on certbot’s instructions page. There is no need to follow any of the other steps, as the rest is taken care of by our integration.

Done That's it! Your MistServer now has SSL enabled and it will be auto-renewing monthly!

Note: Currently a bug can appear where the last step does not activate certbot correctly and no HTTPS protocol appears within MistServer. If you're experiencing this you can solve this by running the following command:

 RENEWED_LINEAGE=/etc/letsencrypt/live/DOMAIN01/ MistUtilCertbot -g 10

Replace DOMAIN01 with the first given domain from your original certbot command.

We'll have this bug sorted and remove this notice when it's no longer relevant.

read moreless
Latest 2022 2021 2020 2019 2018 2017 2016 2015 2014 2013 2012