[Icecast] Icecast2, ezstream and reverse proxy
"Thomas B. Rücker"
thomas at ruecker.fi
Fri May 23 04:30:37 PDT 2014
On 05/23/2014 10:58 AM, Rafael Gomes wrote:
> I use a rule in iptables and solves
> iptables -A PREROUTING -t nat -p tcp -d 192.168.2.32 --dport 80 -j
> REDIRECT --to-port 8000
> iptables-save > /etc/iptables.up.rules
> echo 'pre-up iptables-restore < /etc/iptables.up.rules' >>
That is also an unnecessary and problem prone workaround.
Icecast can listen directly to port 80:
- Configure it to listen to port 80 and whatever other ports (e.g. 443
if you use SSL)
- Configure <changeowner> to switch to the proper user AND group
- Start icecast as root
Or configure your OS to allow binding to ports below 1024 by UID!=0
> Em 2014-05-23 07:44, Thomas B. Rücker escreveu:
>> On 05/23/2014 09:34 AM, Hoggins! wrote:
>>> Correct me if I'm wrong, but what you get from Icecast *is* HTTP.
>> For a listener, Icecast is just an ordinary HTTP 1.0 server.
>> For a source client Icecast used to be a non-standard extension and
>> the SOURCE method. We've deprecated this in 2.4.0 and now support PUT.
>> He's trying to connect a source through a reverse proxy.
>>> Anyway, we use proxying because on our server, some of our clients
>>> cannot connect to port 8000 without bypassing their company firewall,
>> The preferred method here is to make icecast bind to port 80.
>>> and we don't have the possibility to add another public IP.
>> That sucks, but is not an Icecast problem, dirty workarounds ensue.
>>> So with
>>> Apache, here is what we do :
>> <snip />
>> Make sure you have a _high_ number of MaxClients or your Apache will
>> throw a fit after the first few listeners connect and not serve your
>> websites anymore.
>> Also Apache is not that great at handling many long-lived connections.
>> If you really know how to set up an high performance reverse proxy, you
>> won't have to ask how to handle Icecast, everyone else should really
>> avoid this kind of setup.
>>> And it works like a charm, and allows us to benefit from the HTTP 1.1
>>> "Host" header, and use it in a virtual host.
>>> The filter simply rewrites the listening URL served by the Icecast
>>> to routable addresses and routable ports.
>> It will break some features of the web interface, unless you start
>> messing with the replies on the fly.
>> Also your Icecast logs will be mostly worthless.
>>> I would agree this is not the most elegant way to do, but we don't
>>> a choice here.
>> You have a choice, but decided to accept the trade-off. You always have
>> a choice.
>>> Cheers !
>>> Le 23/05/2014 10:59, "Thomas B. Rücker" a écrit :
>>>> On 05/21/2014 10:51 PM, David Hendry wrote:
>>>>> Ezstream is working well locally with Icecast2 on port 8000 on a
>>>>> Debian Wheezy platform. However, I use a reverse proxy (Pound) to
>>>>> pass all requests from the Internet for x.mysite.com to backend
>>>>> localhost:8000 i.e. my Icecast2 server.
>>>> The short answer is: don't put Icecast behind a reverse proxy.
>>>>> This works fine, i.e. x.mysite.com brings up the Icecast2 Status
>>>>> page. My problem is with the ezstream xml configuration <url></url>
>>>>> setting which must have a port number, and if I put
>>>>> <url>x.mysite.com:8000</url> icecast2 does not get the stream. If I
>>>>> use NAT on my router to bypass the reverse proxy, x.mysite.com:8000
>>>>> goes straight to Icecast2 and everything works; but I don't want to
>>>>> do it this way. Do you have any ideas as to what I can do to get
>>>>> ezstream working with icecast2 and my reverse proxy?
>>>> You are trying to put non-HTTP traffic through a HTTP reverse proxy,
>>>> not the least surprised that this fails.
>>>> There /might/ be a slim chance to get things working better if you
>>>> switch to Icecast 2.4.0 AND use a source client that uses PUT instead
>>>> SOURCE. But only if the reverse proxy supports PUT.
>>>> Your reverse proxy might still have problems with the long-lived TCP
>>>> connections and other things specific to Icecast.
More information about the Icecast