ShaYmez/HomebrewDocker
1
0
Fork 0
mirror of https://github.com/ShaYmez/HomebrewDocker.git synced 2024-11-25 17:29:01 -05:00
Code Issues Projects Releases Wiki Activity

updated readme

Browse Source
This commit is contained in:
Dylan Ambauen 2017-12-12 21:01:22 -08:00
parent 3787449f61
commit b1d1709158
1 changed files with 17 additions and 16 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

33
README.md
View File

@ -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 <port>/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 <OUTSIDE-PORT>:22222/udp`.
[<YOURCALL>-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.