From b1d1709158d808336f45d74ca501a63c7769e962 Mon Sep 17 00:00:00 2001 From: Dylan Ambauen Date: Tue, 12 Dec 2017 21:01:22 -0800 Subject: [PATCH] updated readme --- README.md | 33 +++++++++++++++++---------------- 1 file changed, 17 insertions(+), 16 deletions(-) diff --git a/README.md b/README.md index c6f8407..324d974 100644 --- a/README.md +++ b/README.md @@ -1,4 +1,4 @@ -DMR Homebrew Server with IPSC Bridge +Docker =============================== This Dockerfile packages up some great code that other people wrote. @@ -12,12 +12,10 @@ Please read more about IPSC_Bridge and HB_Bridge before attempting to use them. N0MJS makes a particular note: > The configuration file for dmrlink is in ".ini" format, and is self-documented. A warning not in the self-documentation: Don't enable features you do not undertand, it can break dmrlink or the target IPSC (nothing turning off dmrlink shouldn't fix). There are options avaialble because the IPSC protocol appears to make them available, but dmrlink doesn't yet understand them. For exmaple, dmrlink does not process XNL/XCMP. If you enable it, and other peers expect interaction with it, the results may be unpredictable. Chances are, you'll confuse applications like RDAC that require it. The advantage to dmrlink not processing XNL/XCMP is that it also cannot "brick" a repeater or subscriber, since all of these dangerous features use XNL/XCMP. -Supervisord is employed to run HB_Bridge and IPSC_Bridge, we tell Docker just to run Supervisor. - ## Why Docker? -The goal in containerizing the HB+IPSC pair is to simplify running multiple instances on a single server. You can install these applications directly. Docker is pretty cool. Once you get used to it, you may find all sorts of things to use containers for. +The goal in containerizing the HB+IPSC pair is to simplify running multiple instances on a single server. Docker has great documentation online. https://docs.docker.com @@ -31,14 +29,14 @@ Anytime you edit these config files, you'll want to build a new image. Use a dif ### Dockerfile You probably do not need to edit this file, even if you want to run multiple instances. Nor do you need to edit this file to change the port clients use to connect to your MMDVM server. -`EXPOSE /udp` in Dockerfile, should match the port where your HB_Bridge master is listening, inside the container. For example, this snippet from hblink.cfg. - -I want hotspots to connect to my MMDVM server at udp port 4567. Ok, +`EXPOSE 22222/udp` in Dockerfile, must match the port where your HB_Bridge master is listening, inside the container. ### hblink.cfg Settings for your MMDVM Server go in this file. -To run a MMDVM server, specify a Master. Leave the port at 55555, clients will never see it. You'll get to choose what port clients will connect to, later, with `docker run -p OUTSIDE:55555/udp` in the next section. +To run a MMDVM server, specify a Master. Leave the port at 22222, clients will never see it. Remember port 22222 is inside the container. You can run multiple containers, where they all listen on 22222 inside their own containers. + +You'll get to choose what port clients will connect to, later, with `docker run -p :22222/udp`. [-MMDVMServer-1] MODE: MASTER @@ -46,7 +44,7 @@ To run a MMDVM server, specify a Master. Leave the port at 55555, clients will n REPEAT: True EXPORT_AMBE: False IP: - PORT: 55555 + PORT: 22222 PASSPHRASE: changeme GROUP_HANGTIME: 1 @@ -54,12 +52,11 @@ To run a MMDVM server, specify a Master. Leave the port at 55555, clients will n ### HB_Bridge.cfg Defines the talkgroup deck. NO7RF knows more about this. -Also, defines internal ports for talking to IPSC_Bridge. -Must match the same (inverted) settings in IPSC_Bridge.cfg. Might as well leave the defaults alone. The ports are arbitrary, and entirely contained within the runtime container. You may run multiple instances of the same docker image without any port conflicts. +Also, defines internal ports for talking to IPSC_Bridge. Must match the same (inverted) settings in IPSC_Bridge.cfg. Might as well leave the defaults alone. The ports are arbitrary, and entirely contained within the runtime container. You may run multiple instances of the same docker image without any port conflicts. ### dmrlink.cfg -Defines parameters for IPSC master and peers. If you have a cBridge, use it as an IPSC peer. The software author m +Defines parameters for IPSC master and peers. ### IPSC_Bridge.cfg @@ -67,19 +64,21 @@ Don't bother editing this one. Settings paired (inverted) from HB_Bridge.cfg. HB ### supervisord.conf -edit if you wish, really just glue to running 2 programs within a container +Supervisord is employed to run HB_Bridge and IPSC_Bridge, we tell Docker just to run Supervisor. No edits required here. ## Build and Run -We're going to run two copies. We want different talkgroup decks A and B on separate HB servers. This implies two, different IPSC connections. +We're going to run two copies. We want different talkgroup decks A and B on separate HB servers. This implies two, different IPSC connections to two different cBridge managers. git clone https://github.com/KI7SBI/HomebrewDocker.git MMDVM-A git clone https://github.com/KI7SBI/HomebrewDocker.git MMDVM-B -Now, go edit your config files. +Now, go edit all your config files, in both directories. Next step is to build a docker image. `docker build -t REPOSITORY:TAG` Notice how Docker reuses cached build images to build your second version in no time at all. +And run the 2 images. `-d` daemonizes the host process, `-p` forwards an outside port to the MMDVM server running inside. The outside ports must be unique on the host system, in this example 50001 and 50002. + cd MMDVM-A sudo docker build -t mmdvm:server-a . cd ../MMDVM-B @@ -89,6 +88,8 @@ Notice how Docker reuses cached build images to build your second version in no ## Connect your hotspot -From the outside, clients can connect to 50001 or 50002. +From the outside, clients can connect to MMDVM servers on 50001 or 50002. +## Accessing log files from hblink and dmrlink +Haven't built that in yet, but you can do it with Docker. One solution might be to mount a host folder from within the container, and write the log files there. Logs are in /tmp/hblink.log and /tmp/dmrlink.log.