FoxxMD

@klausagnoletti I'm sorry but I can't help you with your specific issues, I don't run an ELK stack and don't have experience with logstash/kibana. You probably aren't finding what you're looking for because: 1. ELK is an orchestration of services. Unraid lets you run individual dockers (docker-compose is not available) so an ELK stack can't be easily packaged up and deployed as "one docker" for unraid. 2. Unraid's apps are basically just templates/configuration presets for docker images from dockerhub. There is nothing special about docker images run on unraid other than the app creator can provide some convenience to other unraid users. These templates don't provide any extra functionality not already found in the docker image from dockerhub. Having said that you can easily run any docker image from dockerhub, as you have discovered. I suspect your issue is an unfamiliarity with the ELK stack, not docker -- as docker is usually pretty transparent. If you can setup an ELK stack in a regular environment you shouldn't have much trouble doing it with docker containers. Some tips that might help you though with template configuration for docker containers in unraid: variable - an environmental variable provided to the docker container. Elasticsearch requires the variable discovery.type to be provided so you would created variable named discovery.type and put its value to single-node directory/folder mapping -- provides mapping from a local directory (in your array) to a directory of your choosing in the docker container. If the ELK stack requires shared files between the services you could setup a folder /mnt/user/appdata/elk that is mapped to all three dockers. port - a local port (on the host machine) mapped to a port in the docker container. If need to point docker container A to docker container B you would give it the host IP + local (mapped) port of container B. EX elasticsearch exposes port 9200. port mapping could be 9200 (docker) -> 8200 (local). If kibana needed to access elasticsearch you would map a variable elastic_endpoint to 192.168.0.1:8200 (or whatever your host IP is)

Unraid has been the perfect balance of a turnkey JBOD server solution and configurability. I love that I didn't have to do anything have a dashboard, network sharing administration, and docker/vm usage -- but at the same time any time something in unraid isn't totally cutting it I can easily dive into the terminal or create a user script. Oh and of course CA has been absolutely intrumental in turning my hardware into something useful.

@yayitazale @craig_read Here are the contents of my various files. I think maybe the repo author hasn't updated the samples in awhile. Maybe these will help you: fr24feed.ini receiver="dvbt" fr24key="your_key_here" bs="yes" raw="yes" logmode="1" mpx="no" mlat="yes" mlat-without-gps="yes" procargs="--net --write-json /usr/lib/fr24/public_html/data" the last argument, procargs, is what actually feeds data into the map. its important that it exists piaware.conf # This file configures piaware and related software. # You can edit it directly or use piaware-config from the command line # to view and change settings. # # If /boot/piaware-config.txt also exists, then settings present in # that file will override settings in this file. flightaware-user FoxxMD flightaware-password myPass feeder-id myId allow-mlat yes mlat-results yes My config.js is essentially the same and upinair.json is optional (and specific to your location)

Yes, you need an antenna and a USB SDR, like this, in order to run this software.

@khile Check the instructions. You need to go to the FR24 website, register an account, and apply for a key.

@yayitazale from the logs you posted you can see piaware is not staying up 2019-07-07 20:27:35,450 INFO exited: piaware (exit status 4; not expected) Taking a look at the piaware source we see that exit code 4 is used when login fails. I'm guessing the container becomes unresponsive because supervisord is constantly trying to restart the process.

@yayitazale The first block you quoted about config is specific to setting up shinysdr. In that post you only need to follow through Step 5 in order to passthrough the device. I have not had the time to create templates for @ShoGinn's dockers yet. Can you post a more complete container log? It's hard to tell what is going on from the excerpt you gave. My guess is that you are missing some configuration or have not correctly passed through the device to the container.

@vw-kombi elasticsearch is just a backend service. It does not provide a UI but rather is used by other applications to query for data. When you are visiting the HTTP port you are making a simple API request and ES sends a response in the same format it would send all other data in -- so the text you got back in your first post is basically a sample of how all data returned from ES will look. There are a few web-based frontends for querying and viewing this data: https://www.elastic.co/guide/en/sense/current/introduction.html https://github.com/appbaseio/dejavu But from your description of what you want I have a feeling that's not what you are looking for. I did find this tutorial for a simple full-text search https://github.com/triestpa/Guttenberg-Search but you would have to write a new Dockerfile for it and publish it to DockerHub to make it useable on unraid.

@vw-kombi no that's it! It's up and working correctly.

Glad you got it figured out! I'm not sure about that downloader, I'm pretty new to the booru scene myself. I'm using this one as a private meme library without much other functionality ¯\_(ツ)_/¯

I don't know about automatically running it but you could put a script in CA User Scripts that makes it a one-click operation after the container is running. I haven't test this but it should be close to working: #!/bin/bash # Return name of docker container with elasticsearch in it -- assuming only one container for elasticsearch is present con="$(docker ps --format "{{.Names}}" | grep -i elasticsearch)" # execute command inside container docker exec -i "$con" /usr/share/elasticsearch/bin/elasticsearch-plugin install --batch ingest-attachment

Glad I could get you hooked! Fortunately its a relatively cheap hobby at least until you want to start transmitting... 😬 I'm using the same configuration right now -- one receiver/antennae for dump1090-piaware-etc. and one beefier receiver/antennae for use with my ShinySDR container for messing around. On that note ethough, @PSYCHOPATHiO let me know if you run into any issues passing through both devices, I'm struggling with my second device. P.S. @ShoGinn I'm still planning on writing templates for your dockers! I have been in the process of moving these last two weeks so haven't had much spare time..

I'd be happy to write these for you and add them to my repo if you'd like!

@darvvyn the docker maintainer has just updated the image with a plugin that supports decoding digital voice. I won't be able to test that this works until later next week but if you can check it out and report back!

@ShoGinn thanks for the insight! I'd much rather be running dump1090/fa/fr as separate dockers and yours look very clean. Please let me know when you get to multi-arch!

I'm not sure about driver support but both this container and another CA app I templated use software sourced from OsmoSDR -- their software supports a large number of sdr chipsets/products and far as I can tell they have good coverage on upstream repos. Edit: This container in particular blacklists the default driver (which I believe is present in unraid, dvb_usb_rtl28xxu) and compiles rtl_sdr from source. I'm not sure how shinysdr does it but since it installs gnuradio-dev I'm sure it's doing something similar.

Application Name: fr24feed-piaware Application Site: https://www.flightradar24.com/share-your-data https://uk.flightaware.com/adsb/piaware/ https://github.com/mutability/dump1090 Github Repo: https://github.com/Thom-x/docker-fr24feed-piaware-dump1090-mutability Docker Hub: https://hub.docker.com/r/thomx/fr24feed-piaware Template Repo: https://github.com/FoxxMD/unraid-docker-templates Overview This image contains: Piaware (Flightaware ADS-B and MLAT ground station software/feed) fr24feed (FlightRadar24 ADS-B software feed) Dump1090 for receiving and parsing data to the above software Simple HTTP Server to display received data (aircraft positions/track) on a real-time map It sets up the above software with your RTL-SDR device (RTL2832) so that you can receive ADS-B/MLAT data through your antennae and transmit it to Flightaware/FlightRadar24. Additionally it serves a simple OpenStreetMap map with overlays of aircraft position/track that your device is receiving. Installation Follow the provided instructions on the docker github repository, most of the configuration file bindings are provided in the unraid template. Just follow the README instructions, copy the samples and edit as necessary, and fill in the host paths in the config entries in the template. Terrain-limit rings are not included in the template. Simply add a path binding to your upinair.json file at the given container path if you want to include it. Instructions on how to passthrough your RTL-SDR USB device to the container can be found here. Usage After starting the container feed activity can be seen in the container log. The aircraft map overlay can be found at http://IP:httpPort/gmap.html

I'm sorry but I can't help with that. This is the official docker container by elasticsearch, not mine. Additionally I could not find that executable anywhere in the container.

The passthrough process is super simple, but not well documented on the unraid wiki or forums...I will add the instructions below to the OP as well. Passthrough a USB Device 1. Open a terminal window on unraid and enter the command: lsusb The output should look something like this: Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 002 Device 006: ID 0bda:2838 Realtek Semiconductor Corp. RTL2838 DVB-T Bus 002 Device 003: ID 0781:5571 SanDisk Corp. Cruzer Fit Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 005 Device 002: ID 051d:0002 American Power Conversion Uninterruptible Power Supply Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 009 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 008 Device 002: ID 2109:3431 VIA Labs, Inc. Hub Bus 008 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub 2. Find the device you want to passthrough. In this case I am looking RTL2838 DVB-T. If your device isn't obvious do some googling of your product and usb description to find it. 3. Note the Bus and Device numbers for your device. 4. Verify your device is accessible on the host (unraid) by finding it in corresponding device folder in the /dev root folder 4a. USB devices on unraid are located at /dev/bus/usb/[busNumber/[deviceNumber] 4b. EX my device from above is located at /dev/bus/usb/002/006 5. Passthrough the device to the container by using that path as the value for the Radio field And that's it! Your device will be passed through to the container (and is found under the same path in the container filesystem). For this container the only additional step that is needed is adding the generic device to the config file and it will work automagically. Gotchas: A device can only be passed through to one docker container or VM at a time. If you unplug/reconnect the device or restart the host (unraid) the device location will likely be different. You will need to go through the above steps to determine the correct bus/device and reconfigure your containers when this happens. _______________ (everything below is specific to this container) _______________ @darvvynn I also have a NooElec brand dongle, they are a good company. For my RTL-SDR device adding the following line to the config file got it working: config.devices.add(u'osmo', OsmoSDRDevice('rtl=0')) In regards to your usage (police scanner) it may be slightly more complicated. Many public safety departments in the US use the P25 protocol IE digital talk radio and shinysdr does not have a P25 demodulator plugin so all you would hear it noise that isn't static if you were listening to their frequencies. There are plenty of resources for using rtl-sdr to decode p25 transmissions so you may have better luck with a VM and using a more complete software package that can do that out of the box. It's on my todo list to see how difficult it would be to write the plugin for shinysdr

Ah sorry I described that incorrectly -- BIOS did see 32G on the last attempt but I was expecting unraid to still show 24G, but it showed 32G!

Application Name: shinysdr Application Site: https://shinysdr.switchb.org Github Repo: https://github.com/kpreid/shinysdr Docker Hub: https://hub.docker.com/r/jeffersonjhunt/shinysdr Template Repo: https://github.com/FoxxMD/unraid-docker-templates Overview ShinySDR is the software component of a software-defined radio receiver. When combined with suitable hardware devices such as the RTL-SDR, HackRF, or USRP, it can be used to listen to or display data from a variety of radio transmissions. This docker includes additional plugins courtesy of the maintainer: python-libhamlib2 -- Controlling external hardware radios gr-air-modes -- ADS-B, aircraft transponders rtl_433 -- Miscellaneous telemetry (remote temperature sensors) gr_radioteletype -- radioteletype (RTTY and modern PSK31 IE real-time keyboard-to-keyboard chat over radio) WSJTX -- weak-signal digital communication gr-dsd -- Digital Speech Decoder (Unencrypted signals for formats like P25 Phase 1, D-STAR, etc.) multimon-ng -- Decoding for more digital transmission modes How To Use A config file -- config.py -- in the Config path host directory is necessary in order to run this container! Create one using the instructions below or bring your own Using Sample Config I have provided a default configuration below. It is slightly opinionated as it assumes you want stereo sound and no root_cap url prefix. It is probably best to generate a new config from fresh code as my sample may become outdated so YMMV. Creating New Config File From Unraid Switch to Advanced View in the template and add the following to Post Arguments --init start /config/myConfig Make sure you have the Config path mapped in your template Apply changes and start the container Edit the container Remove the contents of Post Arguments Set Config mapping to the subfolder created in Step 1 Apply changes Note: You MUST remove the Post Arguments command on next start or the container will stop on error b/c it will not overwrite an existing config file. From CLI (advanced) Run the following command, substituting the host container path for your own, after you have installed the container: docker run --rm -v /mnt/user/shinysdr/config:/config jeffersonjhunt/shinysdr init /config/myConfig Make sure to change your Config path mapping in your unraid template to the subfolder created after running it! Container URL The URL for the container is suffixed with the value of root_cap from config.py EX http://yourIP:port/rootCapValue To access the container at the URL without the suffix set root_cap=None in config.py USB Device Passthrough See my post below on how to passthrough your USB dongle to the container. Additional Notes There are known issues with audio not starting on launch. From my own experience the site does not play well with browsers that have audio autoplay disabled. If you do not get sound check that your browser or extensions are not blocking autoplay. The default configuration generated only adds a simulated RF source device. User configuration to add actual devices is necessary. See the manual for more information. Sample Configuration Below I have provided my configuration (config.py) which does the following: Sets the URL to be accessible without a suffix Enables stereo output (requires more processing power than default mono) # This is a ShinySDR configuration file. For more information about what can # be put here, read the manual section on it, available from the running # ShinySDR server at: http://localhost:8100/manual/configuration from shinysdr.devices import AudioDevice from shinysdr.plugins.osmosdr import OsmoSDRDevice from shinysdr.plugins.simulate import SimulatedDevice # OsmoSDR generic driver; handles USRP, RTL-SDR, FunCube Dongle, HackRF, etc. # To select a specific device, replace '' with 'rtl=0' etc. # config.devices.add(u'osmo', OsmoSDRDevice('')) # For hardware which uses a sound-card as its ADC or appears as an # audio device. # config.devices.add(u'audio', AudioDevice(rx_device='')) # Locally generated RF signals for test purposes. config.devices.add(u'sim', SimulatedDevice()) config.features.enable('stereo'); config.serve_web( # These are in Twisted endpoint description syntax: # <http://twistedmatrix.com/documents/current/api/twisted.internet.endpoints.html#serverFromString> # Note: ws_endpoint must currently be 1 greater than http_endpoint; if one # is SSL then both must be. These restrictions will be relaxed later. http_endpoint='tcp:8100', ws_endpoint='tcp:8101', # A secret placed in the URL as simple access control. Does not # provide any real security unless using HTTPS. The default value # in this file has been automatically generated from 128 random bits. # Set to None to not use any secret. root_cap=None, # Page title / station name title='ShinySDR')

Quick update... I powered down the machine, removed one stick, and powered it on, checking BIOS each time and observing usable memory in unraid after restart. Rinse and repeat for each slot... Usable would drop to 16GB until I got to slot 4 at which point usable was reporting 24GB (so sticks in slots 1-3). I put a spare stick in slot 4 and got the same result so I thought it was bad slot (even though BIOS still reports fine and preliminary memtest showed no issues)... At this point I had given up so I put all sticks back in the machine, but sticks from slots 3 and 4 swapped -- fully expecting to see 24GB after boot but just going to keep all sticks in the machine so I don't misplace the last stick -- and unraid reported 32GB usable 🤪 Soooo, I have no idea what fixed it. Maybe the slot 4 stick just needed to be reseated? Or maybe the slot truly is going bad and it happened to work on this boot. I haven't restarted since then so I'm not getting my hopes this will stay fixed. But ive got full memory...for now.

Hi @GoodOlCap, glad it worked for you! The mapping you listed is for the build directory in the intermediate layer. Instead overwrite the copied favicon in the final layer like this: Container Path: /var/www/img/favicon.png Host Path: /mnt/user/Docker/appdata/szurubooru/img/favicon.png You may then need to flush the favicon cache for your browser if restarting the browser doesn't work: https://www.stirtingale.com/guides/2018/01/how-to-favicon-flush

Tried underclocking but it didn't make a difference...oh well. I will try some different stick configurations again next time I can get some server downtime in to re-verify everything. Thanks for trying @Benson

@Clay Smith thanks for checking out the container! So a file in the container at /opt/app/config.yaml would override default production settings. If the path configuration contains a valid config.yaml file on the host then it isn't a problem but I forgot to test in your scenario (coming in with no config.yaml) -- and its not possible to mount at the /opt/app level because then it overwrites the main app folder, doh! I have updated the template to remove the default config/volume and instead now include directions on how to add a config.yaml mapping. That should fix a clean install scenario. Thanks!