provide port along with the domain (internet radio station)

i have deployed my app, an internet radio station with icecast2 like server called Rocket Streaming Audio Server

in rsas.xml i have set the port to 8001, i deployed the app and i can access it via the fly generated URL. the problem is that mixx that i use on ubuntu to broadcast my music expects a port for live broadcasting and refuses to connect otherwise.

ideally i would like to do something https://mixmasters-server.fly.dev:8001 however this times out :frowning: as one might expect.
using 443 on mixx returns socket error

in theory it could be any port not just 8001 but it has to be present in the URL

any suggestions on how to tackle this?

Hi… What does fly services list show?

(The left-hand sides of the fat arrows (=>) are the options that you have for the port number, after mixmasters-server.fly.dev in the URL.)


Aside: Certain atypical services require a dedicated IP address, which isn’t the default for IPv4 (due to the extra cost).

PROTOCOL PORTS HANDLERS FORCE HTTPS PROCESS GROUP REGIONS MACHINES
TCP 80 => 8001 [HTTP] False app fra 2
TCP 443 => 8001 [HTTP,TLS] False app fra 2

i need the stream URL to have the port appended because there is also a sinatra app udner the same domain that acts as a router for a couple API endpoints
https://mixmasters-server.fly.dev:PORT/stream → streaming audio
https://mixmasters-server.fly.dev/endpoint → API

i am ok with getting a dedicated IP

Hm… It would probably help to post your complete Dockerfile and fly.toml.

(Feel free to * out any names that you consider sensitive, but show the full structure.)

I’m able to contact what looks like a streaming server (This stream is not currently broadcasting live) on https://mixmasters-server.fly.dev/stream, via curl, but I don’t see any sign of Sinatra or an API, at first glance.

Possibly all that’s needed is an additional [[services]] stanza. If you can make everything run over TLS/SSL, with SNI, then you won’t need a dedicated address.


Another thing you could try is to tunnel port 8001 across to your local development laptop/desktop via flyctl proxy. mixxx could then be pointed at localhost port 8001—as soon as you see the Proxying local port message on the terminal.

(This sidesteps any questions about whether that client really does support SSL/TLS.)

Note: leave flyctl proxy running for as long as you need the tunnel.

FROM ubuntu:24.04

# Avoid prompts during package installation
ENV DEBIAN_FRONTEND=noninteractive

# Install Ruby 3.4.3
RUN apt-get update && apt-get install -y \
    curl \
    gnupg \
    lsb-release \
    && curl -sSL https://rvm.io/mpapis.asc | gpg --import - \
    && curl -sSL https://rvm.io/pkuczynski.asc | gpg --import - \
    && curl -sSL https://get.rvm.io | bash -s stable \
    && /bin/bash -c "source /etc/profile.d/rvm.sh && rvm install 3.4.3 && rvm use 3.4.3 --default" \
    && echo 'source /etc/profile.d/rvm.sh' >> /root/.bashrc

# Install system dependencies
RUN apt-get update && apt-get install -y \
    libogg0 \
    gpg \
    build-essential \
    libssl-dev \
    libreadline-dev \
    zlib1g-dev \
    ffmpeg \
    wget \
    && apt-get clean \
    && rm -rf /var/lib/apt/lists/*

# Download and install rsas package
RUN wget https://www.rocketbroadcaster.com/streaming-audio-server/downloads/ubuntu-24.04/rsas_1.0.7-1_amd64.deb \
    && dpkg -i rsas_1.0.7-1_amd64.deb || true \
    && apt-get update \
    && apt-get install -f -y \
    && rm rsas_1.0.7-1_amd64.deb

# Set working directory
WORKDIR /app

# Create directory for rsass config if it doesn't exist
RUN mkdir -p /etc/rsas \
    && mkdir -p /var/log/rsas \
    && chmod -R 755 /var/log/rsas

# Copy application files
COPY . .

# Set up shell for RVM and install bundler
SHELL ["/bin/bash", "-c"]
RUN source /etc/profile.d/rvm.sh \
    && gem install bundler -v 2.6.8

# Install dependencies
RUN source /etc/profile.d/rvm.sh \
    && bundle install

EXPOSE 8001
EXPOSE 9292

# Make the entrypoint script executable
RUN chmod +x /app/docker-entrypoint.sh

# Use the entrypoint script
ENTRYPOINT ["/app/docker-entrypoint.sh"]

# Default command to run Puma
CMD ["bundle", "exec", "puma"]
app = 'mixmasters-server'
primary_region = 'fra'

[build]

[http_service]
  internal_port = 8001
  force_https = false
  auto_stop_machines = 'stop'
  auto_start_machines = true
  min_machines_running = 0
  processes = ['app']

[[vm]]
  memory = '512mb'
  cpu_kind = 'shared'
  cpus = 1

the docker-entrypoint just starts rsas /usr/bin/rsas -c /etc/rsas/rsas.xml
i originally deployed this to a VPS and the streaming server would show up in the domain:8001 the port defined in rsas.xml
and the sinatra API that runs with puma on port 9292 under domain/endpoint

you get 404 because i can’t connect to the server since mixxx requires a port as part of the connection info

i will give the fly proxy a try as well tomorrow

what would my services look like?
i tries something like this but the request timed out

[[services]]
  internal_port = 9292
  force_https = false
  auto_stop_machines = 'stop'
  auto_start_machines = true
  min_machines_running = 0
  processes = ['app']

[[services]]
  internal_port = 8001
  force_https = false
  auto_stop_machines = 'stop'
  auto_start_machines = true
  min_machines_running = 0
  processes = ['app']

using http_service with the puma port surfaced the API

[http_service]
  internal_port = 9292
  force_https = false
  auto_stop_machines = 'stop'
  auto_start_machines = true
  min_machines_running = 0
  processes = ['app']

now i just need a way to surface the stream as well

[[services]] blocks are a little more complicated—and need ports and handlers defined, like in the examples. (Those are implicit in the simpler [http_service] form.)

[http_service]
  internal_port = 9292
  force_https = false

[[services]]
  internal_port = 8001
  protocol = "tcp"
  [[services.ports]]
    port = 8001
    handlers = ["tls", "http"]  # see note below.

(This removes auto-stop temporarily, to keep it from clouding the debugging process.)

The main question here is the TLS handler… Were you using TLS/SSL on the VPS? Glancing at the mixxx documentation, it looks like you would be entering a password, in which case you really would want encrypted transport.

On the other hand, the socket error that you mentioned at the top, when trying port 443, suggests that the client wasn’t using TLS when connecting. I’d suggest looking in the mixxx docs and FAQ/bugs/issues sites for a definitive statement about whether it supports this or not.

One possible workaround would be to use the flyctl proxy tunnel whenever you do need to personally access things, although I don’t know how well that fits with your overall plan. (If this is only going to be broadcasting occasionally, then it would typically work out pretty well, :bluegreen_artist:.)

the config with [[services]] worked! so thank you for that :slight_smile:

Were you using TLS/SSL on the VPS?

yes i did manage to get rsas and TLS working on the VPS

a definitive statement about whether (mixxx) supports this or not.

No it doesn’t. it turns out there is an open PR

so i used butt and i was able to connect to my VPS with TLS on

this from rsas.xml

  <listen-socket>
    <port>8001</port>
    <tls>1</tls>
    <bind-address>0.0.0.0</bind-address>
  </listen-socket>

  <paths>
    <ssl-certificate>/app/certs/fullchain.pem</ssl-certificate>
    <ssl-private-key>/app/certs/privkey.pem</ssl-private-key>
  </paths>

since rsas requires the certificates to be present to be able accept secure connections. i generated a certificate with certbot certonly --manual -d mixmasters-server.fly.dev

but i am getting TLS timeout errors

the reason why i want to move this to fly is so i can future proof it since i had to install everything manually on the VPS and it is not just the packages but also nginx and rsas configs and creating the services for rsas and puma
and in order to run docker in VPS i would probably need more memory since docker alone needs around 1GB.

So one last question :slight_smile: is there a way to generate or point to a certificate?
if not i will have to stick with the VPS solution. i dont think fly proxy is going to work for this project

The Fly.io platform generally isn’t a good substitute for a VPS. It’s geared more toward people who want several Machines spread out across the globe—and/or to do elegant things with creating them dynamically via the API, etc.

Having said that, you seemed close to having this working before, and it seemed like the remaining problems were on the client side.

Were the logs that you posted from when you had the <tls>1</tls> setting in rsas.xml on the Fly.io Machine (as opposed to the VPS)? The "tls" handler in your fly.toml means that the Fly Proxy is already doing the decryption, and it expects your own server (RSAS) to speak unencrypted HTTP to it.

butt (client)  →  Fly Proxy  →  RSAS
               |             |
               |             |
             HTTPS          HTTP
         (encrypted)      (plaintext)

Generally speaking, people don’t mess with generating their own certificates, etc., although it is possible to instruct the Fly Proxy to pass the raw TCP stream directly through to you. (That would require a dedicated IPv4 address, in this case, and maybe also a custom domain name.)

Maybe the audio server’s reverse proxying tips are more what’s needed, at this point?

Were the logs that you posted from when you had the <tls>1</tls> setting in rsas.xml on the Fly.io Machine (as opposed to the VPS)?

yes.

The "tls" handler in your fly.toml means that the Fly Proxy is already doing the decryption, and it expects your own server (RSAS) to speak unencrypted HTTP to it.

i see!

well, I was able to connect to fly with TLS :tada: after removing the <tls> node from the rsas.xml but the connection keeps dropping

thanks for all your help :folded_hands:

1 Like

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.