January 7, 2020 10:56 AM, "user" <5f787a at i2pmail.org> wrote:> 2020-01-06 17:50, Philipp Schafft wrote:... ...> > I'm consider to put icecast behind reverse proxy. It is not so easy as I > think before. Does anyone have experience with it?I run it behind a reverse proxy on apache, and everything works bar one thing - the links in the status and admin interface that serve up an m3u file give you file with the "wrong" URL in it. So, I have icecast on port 8000. My streams are available on http://my.url.tld:8000/jake-radio.mp3 but that 8000 gets blocked by corporate firewalls sometimes so I want to be able to get to http://my.url.tld/jakemusic instead. My apache config looks like: -------- 8< -------- ProxyPreserveHost On ProxyPass /jakemusic http://localhost:8000/jake-radio.mp3 ProxyPassReverse /jakemusic http://localhost:8000/jake-radio.mp3 -------- 8< -------- You need a ProxyPass and ProxyPassReverse to and from each mount point. I don't think you need ".mp3" but I have i. I don't bother proxying the admin interface since I can just browse to port 8000 since I control the firewall, but I don't have any reason to believe that this wouldn't work fine: -------- 8< -------- ProxyPass /admin http://localhost:8000/admin ProxyPassReverse /admin http://localhost:8000/admin -------- 8< -------- Proxying to the root "Icecast2 Status" page is doable but I've never had any luck doing something like this: -------- 8< -------- ProxyPass /status http://localhost:8000/ ProxyPassReverse /status http://localhost:8000/ -------- 8< -------- Anyway the m3u files and the "stream url" generated by the status and admin pages can't know they are behind a proxy so they still point to port 8000 : http://my.url.tld:8000/jake-radio.mp3 even though you really want: http://my.url.tld/jakemusic There are other more "correct" or more elegant options than reverse proxying, I am just a bit lazy. The best option would be to have icecast listen on port 80 and all these issues don't matter any more. You can set up a virtual interface that gets a different IP and have icecast on port 80 on that interface so you can have apache AND icecast both listen to port 80 on the same physical machine which is what I should do to be honest but again - too lazy. Jake
On Tue, Jan 07, 2020 at 08:38:41PM +0000, jake at jakebriggs.com wrote:> January 7, 2020 10:56 AM, "user" <5f787a at i2pmail.org> wrote: > > 2020-01-06 17:50, Philipp Schafft wrote: > > > > I'm consider to put icecast behind reverse proxy. It is not so easy as I > > think before. Does anyone have experience with it? > > I run it behind a reverse proxy on apache, and everything works bar one > thing - the links in the status and admin interface that serve up an m3u > file give you file with the "wrong" URL in it. >M3U playlists are (or used to be) typically downloaded by a web browser and passed to an external music player. If the M3U playlist did not contain the hostname, the music player would see a relative path and would search the playlist items in a local file system instead on the Icecast host. Therefore Icecast puts its hostname into the playlists. -- Petr -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: not available URL: <http://lists.xiph.org/pipermail/icecast/attachments/20200108/8bd41524/attachment.sig>
<div dir="auto">No I think you misunderstood me. The m3u file contains the URL with the port number in it, since as far as icecast knows that's is the URL. It doesn't (and can't) know that I want a different URL. It has http://foo.bar:8000/mountpoint but I want http://foo.bar/mountpoint<div><br></div><div>It's the wrong URL from my perspective, which is why I quoted wrong - I understand it's not wrong, it's just not the one I want.</div><div><br></div><div>It's got nothing to do with the hostname portion or the URL. The hostname in both examples (with the port and without the port) is correct - and identical.</div><div><br></div><div>Jake</div><div><br></div></div><div style="line-height:1.5"><br><br>-------- Original Message --------<br>Subject: Re: [Icecast] admin console<br>From: Petr Pisar <petr.pisar@atlas.cz><br>To: icecast@xiph.org<br>CC: <br><br><blockquote style="margin:0 0 0 0.8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Tue, Jan 07, 2020 at 08:38:41PM +0000, jake@jakebriggs.com wrote:<br>> January 7, 2020 10:56 AM, "user" <5f787a@i2pmail.org> wrote:<br>> > 2020-01-06 17:50, Philipp Schafft wrote:<br>> > <br>> > I'm consider to put icecast behind reverse proxy. It is not so easy as I<br>> > think before. Does anyone have experience with it?<br>> <br>> I run it behind a reverse proxy on apache, and everything works bar one<br>> thing - the links in the status and admin interface that serve up an m3u<br>> file give you file with the "wrong" URL in it.<br>> <br>M3U playlists are (or used to be) typically downloaded by a web browser and<br>passed to an external music player. If the M3U playlist did not contain the<br>hostname, the music player would see a relative path and would search the<br>playlist items in a local file system instead on the Icecast host. Therefore<br>Icecast puts its hostname into the playlists.<br><br>-- Petr<br><br>_______________________________________________<br>Icecast mailing list<br>Icecast@xiph.org<br>http://lists.xiph.org/mailman/listinfo/icecast<br></blockquote></div>