[Icecast] Icecast2, ezstream and reverse proxy

["Thomas B. Rücker"]

Hi,

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' >> 
> /etc/network/interfaces

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

Thomas

> Em 2014-05-23 07:44, Thomas B. Rücker escreveu:
>> Hi,
>>
>> On 05/23/2014 09:34 AM, Hoggins! wrote:
>>> Hello,
>>>
>>> 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 
>> used
>> 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 
>>> pages
>>> 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 
>>> have
>>> a choice here.
>> You have a choice, but decided to accept the trade-off. You always have
>> a choice.
>>
>>
>> Cheers
>>
>> Thomas
>>
>>> 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, 
>>>> I'm
>>>> 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 
>>>> of
>>>> 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.
>>>>