From me at alexhackney.com  Sun Feb  2 14:38:55 2020
From: me at alexhackney.com (Alex Hackney)
Date: Sun, 2 Feb 2020 09:38:55 -0500
Subject: [Icecast] Load balancing Icecast - aggregated logs
In-Reply-To: <CAKCymP2vFbTve=grXHuypwsCxvH0kzYNsSwBAY5Wt41w9YFXqA@mail.gmail.com>
References: <CALiD=zxqf=dJ3U0m36mepAxk3cHb8jBhtWcBPp_nbtdDuUyuQg@mail.gmail.com>
 <2EE20324-39B4-407A-AEC3-6FD95D72A49F@xs4all.nl>
 <CAKCymP1hhrjZ_-50ZHEZngGGCEJyXu3LykYm0wc0VA=rCjzJMg@mail.gmail.com>
 <CALiD=zzpCtLyXd+NnKmqd1Ymq=7eTOreDGWzYByP1jMicj3T0Q@mail.gmail.com>
 <CAKCymP2vFbTve=grXHuypwsCxvH0kzYNsSwBAY5Wt41w9YFXqA@mail.gmail.com>
Message-ID: <CALiD=zxiMDJP-saNwByq=mNU7BfEtqfeBOWJGsC9GvZrd8yMVw@mail.gmail.com>

Both. They are different and independent systems.

On Mon, Jan 20, 2020 at 8:43 AM Chip <chiapas at aktivix.org> wrote:

> On Mon, 20 Jan 2020 at 13:16, Alex Hackney <me at alexhackney.com> wrote:
>
>> I built a system for handling all the data, songs, listeners, royalties,
>> etc. It's all in the docs.
>>
>
> Thanks.
>
> Which docs? Icecast docs or Route 53 docs?
>
> Chip
>
> On Tue, Jan 14, 2020, 17:57 Chip <chiapas at aktivix.org> wrote:
>>
>>> On Tue, 14 Jan 2020 at 19:32, Michel van Dop <mvandop at xs4all.nl> wrote:
>>>
>>>> We use a dns failover solution include roundrobin. Its not super fast
>>>> but in 120 seconds the solution work. So thats a good backup solution for
>>>> the most radio stations.
>>>> Have anyone on php load balancing solution working on a webserver?
>>>>
>>>
>>> That sounds a resilient solution, Michel.
>>>
>>> Can you please tell me more about how you provide your users wiht
>>> listenr stats from across two or more servers?
>>>
>>> Many thanks and all the best for now
>>>
>>> Chip Scooter
>>>
>>> _______________________________________________
>>> Icecast mailing list
>>> Icecast at xiph.org
>>> http://lists.xiph.org/mailman/listinfo/icecast
>>>
>> _______________________________________________
> Icecast mailing list
> Icecast at xiph.org
> http://lists.xiph.org/mailman/listinfo/icecast
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20200202/4f4abecf/attachment.htm>

From henk.vande.ridder at solcon.nl  Wed Feb  5 17:53:24 2020
From: henk.vande.ridder at solcon.nl (Henk van de Ridder)
Date: Wed, 5 Feb 2020 18:53:24 +0100
Subject: [Icecast] Icecast streaming https
Message-ID: <000001d5dc4d$29dfe830$7d9fb890$@solcon.nl>

I am struggling to get icecast running with https, but I cannot get it working

My environment is: Debian 10 (Buster)

 

I tried the standard debian package but there is no SSL capability at all.

 

So I compiled the icecast-2.4.4.tar.gz contents with ./configure --with-curl --with-openssl; make; make install

 

I always get the error: [2020-02-05  17:35:36] INFO connection/get_ssl_certificate No SSL capability on any configured ports

 

The parts of the icecast.xml are:

 

   <listen-socket>

        <port>8780</port>

    </listen-socket>

    <listen-socket>

        <port>9780</port>

        <ssl>1</ssl>

    </listen-socket>

 

  <paths>

        <ssl_certificate>/etc/icecast2/letsencrypt.pem</ssl_certificate> 

     </paths>

 

The letsencrypt.pem is combined out of the certificate (cert.key) and private key file.

The letsencrypt.pem is readeable for the icecast user

I allready tried other pem?s but nothing solves the problem.

 

(Just for reference I already have https running on debian 7 (wheezy) with the icecast-kh-icecast-2.4.0-kh7 version.

 

Does anyone realised met the same problem with a solution for this ? 

Have you some advices for me ?

 

Many thanks in advice

 

Henk van de Ridder

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20200205/f5d20db7/attachment.htm>

From chiapas at aktivix.org  Wed Feb  5 18:52:22 2020
From: chiapas at aktivix.org (Chip)
Date: Wed, 5 Feb 2020 18:52:22 +0000
Subject: [Icecast] Icecast streaming https
In-Reply-To: <000001d5dc4d$29dfe830$7d9fb890$@solcon.nl>
References: <000001d5dc4d$29dfe830$7d9fb890$@solcon.nl>
Message-ID: <CAKCymP2bJ-sMUbUhj9SJWxn1aumdwXE-18iPKv_eXJi+DCrhcQ@mail.gmail.com>

Here you go:

   - https://serverok.in/centovacast-enable-ssl-on-icecast

No problem, you're welcome!

Chip Scooter


On Wed, 5 Feb 2020 at 18:41, Henk van de Ridder <henk.vande.ridder at solcon.nl>
wrote:

> I am struggling to get icecast running with https, but I cannot get it
> working
>
> My environment is: Debian 10 (Buster)
>
>
>
> I tried the standard debian package but there is no SSL capability at all.
>
>
>
> So I compiled the icecast-2.4.4.tar.gz contents with ./configure
> --with-curl --with-openssl; make; make install
>
>
>
> I always get the error: [2020-02-05  17:35:36] INFO
> connection/get_ssl_certificate No SSL capability on any configured ports
>
>
>
> The parts of the icecast.xml are:
>
>
>
>    <listen-socket>
>
>         <port>8780</port>
>
>     </listen-socket>
>
>     <listen-socket>
>
>         <port>9780</port>
>
>         <ssl>1</ssl>
>
>     </listen-socket>
>
>
>
>   <paths>
>
>         <ssl_certificate>/etc/icecast2/letsencrypt.pem</ssl_certificate>
>
>      </paths>
>
>
>
> The letsencrypt.pem is combined out of the certificate (cert.key) and
> private key file.
>
> The letsencrypt.pem is readeable for the icecast user
>
> I allready tried other pem?s but nothing solves the problem.
>
>
>
> (Just for reference I already have https running on debian 7 (wheezy) with
> the icecast-kh-icecast-2.4.0-kh7 version.
>
>
>
> Does anyone realised met the same problem with a solution for this ?
>
> Have you some advices for me ?
>
>
>
> Many thanks in advice
>
>
>
> Henk van de Ridder
>
>
>
>
>
> _______________________________________________
> Icecast mailing list
> Icecast at xiph.org
> http://lists.xiph.org/mailman/listinfo/icecast
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20200205/cce754e9/attachment.htm>

From relen at brideswell.com  Wed Feb  5 21:49:46 2020
From: relen at brideswell.com (Richard Elen)
Date: Wed, 5 Feb 2020 21:49:46 +0000
Subject: [Icecast] Icecast streaming https
In-Reply-To: <CAKCymP2bJ-sMUbUhj9SJWxn1aumdwXE-18iPKv_eXJi+DCrhcQ@mail.gmail.com>
References: <000001d5dc4d$29dfe830$7d9fb890$@solcon.nl>
 <CAKCymP2bJ-sMUbUhj9SJWxn1aumdwXE-18iPKv_eXJi+DCrhcQ@mail.gmail.com>
Message-ID: <175874ca-82e8-b051-901c-2f120bf3de21@brideswell.com>

That's a useful site! Thanks for that!

R

On 05-Feb-20 18:52, Chip wrote:
> Here you go:
>
>   * https://serverok.in/centovacast-enable-ssl-on-icecast
>
> No problem, you're welcome!
>
> Chip Scooter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20200205/04e06d7d/attachment.htm>

From chiapas at aktivix.org  Wed Feb  5 22:56:37 2020
From: chiapas at aktivix.org (Chip)
Date: Wed, 5 Feb 2020 22:56:37 +0000
Subject: [Icecast] Icecast streaming https
In-Reply-To: <175874ca-82e8-b051-901c-2f120bf3de21@brideswell.com>
References: <000001d5dc4d$29dfe830$7d9fb890$@solcon.nl>
 <CAKCymP2bJ-sMUbUhj9SJWxn1aumdwXE-18iPKv_eXJi+DCrhcQ@mail.gmail.com>
 <175874ca-82e8-b051-901c-2f120bf3de21@brideswell.com>
Message-ID: <CAKCymP07X8CBAH4G9Nc7o3z+HDu0AeTWsQ7RWM6d3aOxLgqx_A@mail.gmail.com>

Of course...

Best print it to PDF in case it ever disappears!

All the best

Chip Scooter

On Wed, 5 Feb 2020 at 22:07, Richard Elen <relen at brideswell.com> wrote:

> That's a useful site! Thanks for that!
>
> R
> On 05-Feb-20 18:52, Chip wrote:
>
> Here you go:
>
>    - https://serverok.in/centovacast-enable-ssl-on-icecast
>
> No problem, you're welcome!
>
> Chip Scooter
>
> _______________________________________________
> Icecast mailing list
> Icecast at xiph.org
> http://lists.xiph.org/mailman/listinfo/icecast
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20200205/ad3b1261/attachment.htm>

From jeffares.robert at gmail.com  Wed Feb  5 23:42:36 2020
From: jeffares.robert at gmail.com (Robert Jeffares)
Date: Thu, 6 Feb 2020 12:42:36 +1300
Subject: [Icecast] Stream Monitoring Service
Message-ID: <a4a0a20e-a26e-3f70-14bf-e0bc600ab942@gmail.com>

Hi All!

anyone interested in an external service that will listen to your 
internet stream and send you a message when it goes down, or when the 
audio fails?

Have been looking for such a service without success, and have set 
something up that can handle a few additional stations.

regards

Robert



From albert.santoni at oscillicious.com  Wed Feb  5 23:57:43 2020
From: albert.santoni at oscillicious.com (Albert Santoni)
Date: Wed, 5 Feb 2020 18:57:43 -0500
Subject: [Icecast] Stream Monitoring Service
In-Reply-To: <a4a0a20e-a26e-3f70-14bf-e0bc600ab942@gmail.com>
References: <a4a0a20e-a26e-3f70-14bf-e0bc600ab942@gmail.com>
Message-ID: <CAEbLzA_0Y+v+4PqbKxXQUB2TB2yXjq2e6R+jtg7pYTo4SKmV=Q@mail.gmail.com>

Hi Robert,

Our Radio Mast platform provides such a service:
https://www.radiomast.io/solutions/stream-monitoring
We support basic uptime monitoring, silence detection, and sending
notifications via email, Slack, and webhooks. We also support multiple
alerting policies/contacts, so you can set up escalation.

If anyone has any questions, please let me know or feel free to reach out
off-list.

Thanks,
Albert


On Wed, Feb 5, 2020 at 6:42 PM Robert Jeffares <jeffares.robert at gmail.com>
wrote:

> Hi All!
>
> anyone interested in an external service that will listen to your
> internet stream and send you a message when it goes down, or when the
> audio fails?
>
> Have been looking for such a service without success, and have set
> something up that can handle a few additional stations.
>
> regards
>
> Robert
>
> _______________________________________________
> Icecast mailing list
> Icecast at xiph.org
> http://lists.xiph.org/mailman/listinfo/icecast
>


-- 
Albert Santoni
Founder, Lead Developer | Oscillicious
Delicious Audio Tools and Plug-ins
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20200205/4a57e09c/attachment.htm>

From artuch at speedy.com.ar  Thu Feb  6 03:23:03 2020
From: artuch at speedy.com.ar (=?ISO-8859-1?Q?Jos=E9?= Luis Artuch)
Date: Thu, 06 Feb 2020 00:23:03 -0300
Subject: [Icecast] Icecast streaming https
In-Reply-To: <000001d5dc4d$29dfe830$7d9fb890$@solcon.nl>
References: <000001d5dc4d$29dfe830$7d9fb890$@solcon.nl>
Message-ID: <94c8992094c152f9e97b38a64b8187649c2a5f43.camel@speedy.com.ar>

Hi Henk,

El mi?, 05-02-2020 a las 18:53 +0100, Henk van de Ridder escribi?:
> > I am struggling to get icecast running with https, but I cannot get
> > it working
> > My environment is: Debian 10 (Buster)
> >  
> > I tried the standard debian package but there is no SSL capability
> > at all.
> >  
> > So I compiled the icecast-2.4.4.tar.gz contents with ./configure --
> > with-curl --with-openssl; make; make install
> >  
> > I always get the error: [2020-02-05  17:35:36] INFO
> > connection/get_ssl_certificate No SSL capability on any configured
> > ports
> >  
> > The parts of the icecast.xml are:
> >  
> >    <listen-socket>
> >         <port>8780</port>
> >     </listen-socket>
> >     <listen-socket>
> >         <port>9780</port>
> >         <ssl>1</ssl>
> >     </listen-socket>
> >  
> >   <paths>
> >        
> > <ssl_certificate>/etc/icecast2/letsencrypt.pem</ssl_certificate>
> >      </paths>
> >  
> > The letsencrypt.pem is combined out of the certificate (cert.key)
> > and private key file.
> > The letsencrypt.pem is readeable for the icecast user
> > I allready tried other pem?s but nothing solves the problem.
> >  
> > (Just for reference I already have https running on debian 7
> > (wheezy) with the icecast-kh-icecast-2.4.0-kh7 version.
> >  
> > Does anyone realised met the same problem with a solution for this
> > ?
> > Have you some advices for me ?
> >  
> > Many thanks in advice
> >  
> > Henk van de Ridder

On Debian Stretch it works very well following this steps indicated by
Thomas B. R?cker:
http://lists.xiph.org/pipermail/icecast/2018-August/014317.html

On Debian Buster I only achieved HTTPS with a work around (proxy), but
I checked this alert by Thomas:
https://stackoverflow.com/questions/50525044/restream-a-mp3-stream-over-https-with-ssl
"Another word of warning. Traditional web servers are not designed for
continuous streams. You'll waste a lot of incoming bandwidth (each
client connection causes one connection to the origin), but also memory
consumption. Also more than a hand full of client connections might
make the server seize. (depending on default limits) ? TBR"

Regards.
Jos? Luis

> >  
> >  
> 
> _______________________________________________
> Icecast mailing list
> Icecast at xiph.org
> http://lists.xiph.org/mailman/listinfo/icecast



From 5f787a at i2pmail.org  Thu Feb  6 19:20:45 2020
From: 5f787a at i2pmail.org (user)
Date: Thu,  6 Feb 2020 19:20:45 +0000 (UTC)
Subject: [Icecast] admin console
In-Reply-To: <20200108095942.B90F640F1A@smtp.postman.i2p>
References: <20200106102443.D5EC841736@smtp.postman.i2p>
 <20200106175045.E2C5941986@smtp.postman.i2p>
 <20200106215643.3F7F941990@smtp.postman.i2p>
 <20200108095942.B90F640F1A@smtp.postman.i2p>
Message-ID: <20200206192045.C124141695@smtp.postman.i2p>

2020-01-08 09:59, Marvin Scholz wrote:
> >> On Mon, 2020-01-06 at 10:24 +0000, user 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?
> 
> In general putting Icecast behind a reverse proxy is not the best idea as
> some webservers are not really made out of the box to easily deal with the
> kind of usage Icecast will usually produce (long running connections
> serving a continuous stream). Additionally Icecast is not really capable
> currently do deal with being reverse-proxied properly so some things will
> break when doing that.
> 
> So unless you want to shoot yourself in the foot and run into various
> issues I would not recommend to do it.

Expectation on malicious activity force me to put icecast behind reverse
proxy. It was not easy, but works very well.

-- 



From chiapas at aktivix.org  Fri Feb  7 17:15:58 2020
From: chiapas at aktivix.org (Chip)
Date: Fri, 7 Feb 2020 17:15:58 +0000
Subject: [Icecast] Icecast streaming https
In-Reply-To: <f46cd26034e9498d753c7c67c83b1aaee571b661@ssw.solcon.nl>
References: <f46cd26034e9498d753c7c67c83b1aaee571b661@ssw.solcon.nl>
Message-ID: <CAKCymP2cyT5vbpx7rWuay0rYkY+1PpmGQCFtcGCraXjgfSTajA@mail.gmail.com>

Hi

These instructions are very useful, as previously shared:

   - https://serverok.in/centovacast-enable-ssl-on-icecast

However, I think this step caused me problems using Letsencrypt (LE) and
the icecast.pem file might have been in error:

Paste your SSL in following order
1) Your private key
2) Your SSL cert
3) CA Bundle

I don't think LE creates a 'CA Bundle'. Following some other instructions I
was making the *.pem file like this:

cat cert.pem privkey.pem > icecast.pem   *<= this is not a good method*

Test your stream using this:

curl -v https://example.com:8001/mountpoint

If curl is not happy with your SSL cert it will throw an error like this:

[chip at machine ~]$  curl -v https://example.com:8001/mountpoint

    About to connect() to example.com port 8001 (#0)

    Trying 192.168.1.50? connected

    Connected to example.com (192.168.1.50) port 8001 (#0)

    Initializing NSS with certpath: sql:/etc/pki/nssdb

    CAfile: /etc/pki/tls/certs/ca-bundle.crt
    CApath: none

    Peer?s certificate issuer is not recognized: ?CN=Let?s Encrypt
Authority X3,O=Let?s Encrypt,C=US?

    NSS error -8179

    Closing connection #0

    Peer certificate cannot be authenticated with known CA certificates
    curl: (60) Peer certificate cannot be authenticated with known CA
certificates
    More details here: http://curl.haxx.se/docs/sslcerts.html

    curl performs SSL certificate verification by default, using a "bundle"
of Certificate Authority (CA) public keys (CA certs). If the default bundle
file isn't adequate, you can specify an alternate file using the --cacert
option. If this HTTPS server uses a certificate signed by a CA represented
in the bundle, the certificate verification probably failed due to a
problem with the certificate (it might be expired, or the name might not
match the domain name in the URL). If you'd like to turn off curl's
verification of the certificate, use the -k (or --insecure) option.

If you are using LE then this, IMHO, is a *better way* to make the
icecast.pem file:

cat privkey.pem fullchain.pem > icecast.pem

The above creates a more 'correct' SSL cert which, for example, Alexa
devices are able to stream.

And you can check your SSL stream here:

   - https://check-your-website.server-daten.de/?q=

Thanks

Chip Scooter

On Thu, 6 Feb 2020 at 07:58, H. van de Ridder <hvdridder at solcon.nl> wrote:

> Thanks a lot.
> This manual solves my problem.
>
> Kind regards,
> Henk
> ------------------------------
>
> ------------------------------
>
>
> ----- Original Message ----
> From: Chip <chiapas at aktivix.org>
> To: Icecast streaming server user discussions <icecast at xiph.org>
> Sent: Woe, 05 Feb 2020 23:57
> Subject: Re: [Icecast] Icecast streaming https
>
> Of course...
>
> Best print it to PDF in case it ever disappears!
>
> All the best
>
> Chip Scooter
>
> On Wed, 5 Feb 2020 at 22:07, Richard Elen <relen at brideswell.com> wrote:
>
>> That's a useful site! Thanks for that!
>>
>> R
>> On 05-Feb-20 18:52, Chip wrote:
>>
>> Here you go:
>>
>>    - https://serverok.in/centovacast-enable-ssl-on-icecast
>>
>> No problem, you're welcome!
>>
>> Chip Scooter
>>
>> _______________________________________________
>> Icecast mailing list
>> Icecast at xiph.org
>> http://lists.xiph.org/mailman/listinfo/icecast
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20200207/98db7856/attachment.htm>

From sergei.shablovsky at gmail.com  Mon Feb 10 12:19:05 2020
From: sergei.shablovsky at gmail.com (Sergei Shablovsky)
Date: Mon, 10 Feb 2020 04:19:05 -0800
Subject: [Icecast] admin console
In-Reply-To: <20200206192045.C124141695@smtp.postman.i2p>
References: <20200106102443.D5EC841736@smtp.postman.i2p>
 <20200106175045.E2C5941986@smtp.postman.i2p>
 <20200106215643.3F7F941990@smtp.postman.i2p>
 <20200108095942.B90F640F1A@smtp.postman.i2p>
 <20200206192045.C124141695@smtp.postman.i2p>
Message-ID: <B7940785-5F6E-4D1C-9470-3F82A9BC4BA6@gmail.com>


> On Feb 6, 2020, at 11:20 AM, user <5f787a at i2pmail.org> wrote:
> 
> 2020-01-08 09:59, Marvin Scholz wrote:
>>>> On Mon, 2020-01-06 at 10:24 +0000, user 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?
>> 
>> In general putting Icecast behind a reverse proxy is not the best idea as
>> some webservers are not really made out of the box to easily deal with the
>> kind of usage Icecast will usually produce (long running connections
>> serving a continuous stream). Additionally Icecast is not really capable
>> currently do deal with being reverse-proxied properly so some things will
>> break when doing that.
>> 
>> So unless you want to shoot yourself in the foot and run into various
>> issues I would not recommend to do it.
> 
> Expectation on malicious activity force me to put icecast behind reverse
> proxy. It was not easy, but works very well.
> 

Please explain in details how You doing this.


From 5f787a at i2pmail.org  Mon Feb 10 16:50:27 2020
From: 5f787a at i2pmail.org (user)
Date: Mon, 10 Feb 2020 16:50:27 +0000 (UTC)
Subject: [Icecast] admin console
In-Reply-To: <20200210121947.E5E64411D3@smtp.postman.i2p>
References: <20200106102443.D5EC841736@smtp.postman.i2p>
 <20200106175045.E2C5941986@smtp.postman.i2p>
 <20200106215643.3F7F941990@smtp.postman.i2p>
 <20200108095942.B90F640F1A@smtp.postman.i2p>
 <20200206192045.C124141695@smtp.postman.i2p>
 <20200210121947.E5E64411D3@smtp.postman.i2p>
Message-ID: <20200210165027.44D60416FB@smtp.postman.i2p>

2020-02-10 12:19, Sergei Shablovsky wrote:
> 
> > On Feb 6, 2020, at 11:20 AM, user <5f787a at i2pmail.org> wrote:
> > 
> > 2020-01-08 09:59, Marvin Scholz wrote:
> >>>> On Mon, 2020-01-06 at 10:24 +0000, user 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?
> >> 
> >> In general putting Icecast behind a reverse proxy is not the best idea as
> >> some webservers are not really made out of the box to easily deal with the
> >> kind of usage Icecast will usually produce (long running connections
> >> serving a continuous stream). Additionally Icecast is not really capable
> >> currently do deal with being reverse-proxied properly so some things will
> >> break when doing that.
> >> 
> >> So unless you want to shoot yourself in the foot and run into various
> >> issues I would not recommend to do it.
> > 
> > Expectation on malicious activity force me to put icecast behind reverse
> > proxy. It was not easy, but works very well.
> > 
> 
> Please explain in details how You doing this.

No.
-- 


From lion at lion.leolix.org  Mon Feb 10 18:10:23 2020
From: lion at lion.leolix.org (Philipp Schafft)
Date: Mon, 10 Feb 2020 18:10:23 +0000
Subject: [Icecast] admin console
In-Reply-To: <20200206192045.C124141695@smtp.postman.i2p>
References: <20200106102443.D5EC841736@smtp.postman.i2p>
 <20200106175045.E2C5941986@smtp.postman.i2p>
 <20200106215643.3F7F941990@smtp.postman.i2p>
 <20200108095942.B90F640F1A@smtp.postman.i2p>
 <20200206192045.C124141695@smtp.postman.i2p>
Message-ID: <1581358223.2179.194.camel@lion.leolix.org>

Good evening,

On Thu, 2020-02-06 at 19:20 +0000, user wrote:
> 2020-01-08 09:59, Marvin Scholz wrote:
> > >> On Mon, 2020-01-06 at 10:24 +0000, user 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?
> > 
> > In general putting Icecast behind a reverse proxy is not the best idea as
> > some webservers are not really made out of the box to easily deal with the
> > kind of usage Icecast will usually produce (long running connections
> > serving a continuous stream). Additionally Icecast is not really capable
> > currently do deal with being reverse-proxied properly so some things will
> > break when doing that.
> > 
> > So unless you want to shoot yourself in the foot and run into various
> > issues I would not recommend to do it.
> 
> Expectation on malicious activity force me to put icecast behind reverse
> proxy. It was not easy, but works very well.

So, what kind of "malicious activity" exactly? And what exact HTTP level
software is more robust against those activities than Icecast?

I'm fully in support that active components on lower levels can be
helpful in some situations. But I would love to hear about any analysis
indicating specific request patterns that would be better handled by
external software. If you would share your information rather than
keeping us in the dark about specifics it would enable us to improve
Icecast for all users including you. :)

With best regards,

-- 
Philipp.
 (Rah of PH2)


From lion at lion.leolix.org  Thu Feb 13 13:46:34 2020
From: lion at lion.leolix.org (Philipp Schafft)
Date: Thu, 13 Feb 2020 13:46:34 +0000
Subject: [Icecast] admin console
In-Reply-To: <20200211134015.D9CEE40E43@smtp.postman.i2p>
References: <20200106102443.D5EC841736@smtp.postman.i2p>
 <20200106175045.E2C5941986@smtp.postman.i2p>
 <20200106215643.3F7F941990@smtp.postman.i2p>
 <20200108095942.B90F640F1A@smtp.postman.i2p>
 <20200206192045.C124141695@smtp.postman.i2p>
 <20200210182014.C8C2F411D3@smtp.postman.i2p>
 <20200211134015.D9CEE40E43@smtp.postman.i2p>
Message-ID: <1581601594.2179.243.camel@lion.leolix.org>

Good afternoon,

please have a look into your MUA setup. You keep breaking threading for
this thread (In-Reply-To header is set incorrectly).


On Tue, 2020-02-11 at 13:40 +0000, user wrote:
> > On Thu, 2020-02-06 at 19:20 +0000, user wrote:
> > > 2020-01-08 09:59, Marvin Scholz wrote:
> > > Expectation on malicious activity force me to put icecast behind reverse
> > > proxy. It was not easy, but works very well.
> > 
> > So, what kind of "malicious activity" exactly? And what exact HTTP level
> > software is more robust against those activities than Icecast?
> > 
> > I'm fully in support that active components on lower levels can be helpful
> > in some situations. But I would love to hear about any analysis indicating
> > specific request patterns that would be better handled by external
> > software. If you would share your information rather than keeping us in
> > the dark about specifics it would enable us to improve Icecast for all
> > users including you. :)
> > 
> > With best regards,

Thank you for your answer. I very much appreciate it.


Sadly I do not see an answer to my question "So, what kind of 'malicious
activity' exactly?". And the answer to that question is what all the
rest depend on. Without it any discussion is basically voided.


Still some thoughts on your points:

> 1. First of all I would like to deny access to everything except
> "/stream.ogg" depends on client IP.

Icecast will request requests for any unknown target anyway. If you
don't like access to the static files in web/ you can just delete them
or set <webroot> to an empty path.

admin/ is protected, so unauthed clients will get a reject anyway.


I don't really see a reason for a reverse proxy here. Icecast already
rejects those requests. Plus I hardly see harm that could be caused
beside a bit of extra traffic.

allow/deny rules for IPs can be defined with <allow-ip> and <deny-ip>.
Plus if you really have a list of "malicious" clients you should likely
block them on your border gateway or firewall anyway.


> 2. Deny everything depends on User-Agent value and User-Agent length.

Without an answer to my question above you can hardly discuss this. But
I don't see much point in this generally as the user agent string is
basically a freeform user setting. So an attacker can change it at will.

At best it would be helpful to do some matches to avoid getting hits by
misbehaving clients. But that is a totally different class than
attacking clients.

Also, such a check could be implemented in Icecast as well. Depending on
your version in different ways.


> 3. Deny HTTP 1.0 protocol.

Which is a bad idea as Icecast 2.4.x (stable) IS a HTTP/1.0 server. So
if you disable that protocol and you still can connect your filter does
not work anyway.


> Application-Layer DDoS Attack Protection with
> HAProxy: "A number of attacks use HTTP/1.0 as the protocol version because
> that's the version supported by some bots."

While we move away from Icecast there is nothing inherently wrong with
HTTP/1.0 in Icecast context. And again, those bots could be easily
updated to use HTTP/1.1 by setting the version to HTTP/1.1 and adding a
Host:-header (which they likely send already).


> 4. Turn on/off anti-DoS protection depends on connection rate.

This is clearly a common firewall feature. Limiting rate or request rate
can be done with any firewall. And is totally done best there as it will
filter out traffic before it even hits your server.


Here is another point you should add to your consideration:
A reverse proxy adds an additional, complex component to your setup. It
therefore increases the attack surface (it has it's own bugs, it's own
flaws, ...).
A reverse proxy need to process the HTTP level messages an additional
time. This requires additional CPU power and time.
It also requires additional system resources like sockets, file
descriptors, I/O-buffers, scheduling slots, ...

So a reverse proxy always amplifies any *DoS kind of attack as
significant more resources are required per request.


From a business perspective it will add more costs: system resources,
maintenance, more skilled admins, ... For a single hour of admin time
you can book a VPS at a random provider for a complete year that can
handle 10k simultaneous connections or 10k simultaneous "malicious"
connections.

With best regards,

-- 
Philipp.
 (Rah of PH2)


From rondejavu at gmail.com  Thu Feb 13 14:01:15 2020
From: rondejavu at gmail.com (Rondejavu)
Date: Thu, 13 Feb 2020 09:01:15 -0500
Subject: [Icecast] admin console
In-Reply-To: <1581601594.2179.243.camel@lion.leolix.org>
References: <1581601594.2179.243.camel@lion.leolix.org>
Message-ID: <D81014AB-66B6-480E-B0A7-A4EF53DDEBB6@gmail.com>

Remove

-Pete

> On Feb 13, 2020, at 8:46 AM, Philipp Schafft <lion at lion.leolix.org> wrote:
> 
> ?Good afternoon,
> 
> please have a look into your MUA setup. You keep breaking threading for
> this thread (In-Reply-To header is set incorrectly).
> 
> 
> On Tue, 2020-02-11 at 13:40 +0000, user wrote:
>>>> On Thu, 2020-02-06 at 19:20 +0000, user wrote:
>>>>> 2020-01-08 09:59, Marvin Scholz wrote:
>>>>> Expectation on malicious activity force me to put icecast behind reverse
>>>>> proxy. It was not easy, but works very well.
>>> 
>>> So, what kind of "malicious activity" exactly? And what exact HTTP level
>>> software is more robust against those activities than Icecast?
>>> 
>>> I'm fully in support that active components on lower levels can be helpful
>>> in some situations. But I would love to hear about any analysis indicating
>>> specific request patterns that would be better handled by external
>>> software. If you would share your information rather than keeping us in
>>> the dark about specifics it would enable us to improve Icecast for all
>>> users including you. :)
>>> 
>>> With best regards,
> 
> Thank you for your answer. I very much appreciate it.
> 
> 
> Sadly I do not see an answer to my question "So, what kind of 'malicious
> activity' exactly?". And the answer to that question is what all the
> rest depend on. Without it any discussion is basically voided.
> 
> 
> Still some thoughts on your points:
> 
>> 1. First of all I would like to deny access to everything except
>> "/stream.ogg" depends on client IP.
> 
> Icecast will request requests for any unknown target anyway. If you
> don't like access to the static files in web/ you can just delete them
> or set <webroot> to an empty path.
> 
> admin/ is protected, so unauthed clients will get a reject anyway.
> 
> 
> I don't really see a reason for a reverse proxy here. Icecast already
> rejects those requests. Plus I hardly see harm that could be caused
> beside a bit of extra traffic.
> 
> allow/deny rules for IPs can be defined with <allow-ip> and <deny-ip>.
> Plus if you really have a list of "malicious" clients you should likely
> block them on your border gateway or firewall anyway.
> 
> 
>> 2. Deny everything depends on User-Agent value and User-Agent length.
> 
> Without an answer to my question above you can hardly discuss this. But
> I don't see much point in this generally as the user agent string is
> basically a freeform user setting. So an attacker can change it at will.
> 
> At best it would be helpful to do some matches to avoid getting hits by
> misbehaving clients. But that is a totally different class than
> attacking clients.
> 
> Also, such a check could be implemented in Icecast as well. Depending on
> your version in different ways.
> 
> 
>> 3. Deny HTTP 1.0 protocol.
> 
> Which is a bad idea as Icecast 2.4.x (stable) IS a HTTP/1.0 server. So
> if you disable that protocol and you still can connect your filter does
> not work anyway.
> 
> 
>> Application-Layer DDoS Attack Protection with
>> HAProxy: "A number of attacks use HTTP/1.0 as the protocol version because
>> that's the version supported by some bots."
> 
> While we move away from Icecast there is nothing inherently wrong with
> HTTP/1.0 in Icecast context. And again, those bots could be easily
> updated to use HTTP/1.1 by setting the version to HTTP/1.1 and adding a
> Host:-header (which they likely send already).
> 
> 
>> 4. Turn on/off anti-DoS protection depends on connection rate.
> 
> This is clearly a common firewall feature. Limiting rate or request rate
> can be done with any firewall. And is totally done best there as it will
> filter out traffic before it even hits your server.
> 
> 
> Here is another point you should add to your consideration:
> A reverse proxy adds an additional, complex component to your setup. It
> therefore increases the attack surface (it has it's own bugs, it's own
> flaws, ...).
> A reverse proxy need to process the HTTP level messages an additional
> time. This requires additional CPU power and time.
> It also requires additional system resources like sockets, file
> descriptors, I/O-buffers, scheduling slots, ...
> 
> So a reverse proxy always amplifies any *DoS kind of attack as
> significant more resources are required per request.
> 
> 
> From a business perspective it will add more costs: system resources,
> maintenance, more skilled admins, ... For a single hour of admin time
> you can book a VPS at a random provider for a complete year that can
> handle 10k simultaneous connections or 10k simultaneous "malicious"
> connections.
> 
> With best regards,
> 
> -- 
> Philipp.
> (Rah of PH2)
> _______________________________________________
> Icecast mailing list
> Icecast at xiph.org
> http://lists.xiph.org/mailman/listinfo/icecast


From 5f787a at i2pmail.org  Thu Feb 13 14:59:30 2020
From: 5f787a at i2pmail.org (user)
Date: Thu, 13 Feb 2020 14:59:30 +0000 (UTC)
Subject: [Icecast] admin console
In-Reply-To: <20200213140150.52E574196D@smtp.postman.i2p>
References: <1581601594.2179.243.camel@lion.leolix.org>
 <20200213140150.52E574196D@smtp.postman.i2p>
Message-ID: <20200213145930.6FBC641986@smtp.postman.i2p>

Philipp Schafft, who allow you to publish my private message?

> Remove
> 
> -Pete
> 
> > On Feb 13, 2020, at 8:46 AM, Philipp Schafft <lion at lion.leolix.org> wrote:
> > 
> > ???Good afternoon,
> > 
> > please have a look into your MUA setup. You keep breaking threading for
> > this thread (In-Reply-To header is set incorrectly).
> > 
> > 
> > On Tue, 2020-02-11 at 13:40 +0000, user wrote:
> >>>> On Thu, 2020-02-06 at 19:20 +0000, user wrote:
> >>>>> 2020-01-08 09:59, Marvin Scholz wrote:
> >>>>> Expectation on malicious activity force me to put icecast behind reverse
> >>>>> proxy. It was not easy, but works very well.
> >>> 
> >>> So, what kind of "malicious activity" exactly? And what exact HTTP level
> >>> software is more robust against those activities than Icecast?
> >>> 
> >>> I'm fully in support that active components on lower levels can be helpful
> >>> in some situations. But I would love to hear about any analysis indicating
> >>> specific request patterns that would be better handled by external
> >>> software. If you would share your information rather than keeping us in
> >>> the dark about specifics it would enable us to improve Icecast for all
> >>> users including you. :)
> >>> 
> >>> With best regards,
> > 
> > Thank you for your answer. I very much appreciate it.
> > 
> > 
> > Sadly I do not see an answer to my question "So, what kind of 'malicious
> > activity' exactly?". And the answer to that question is what all the
> > rest depend on. Without it any discussion is basically voided.
> > 
> > 
> > Still some thoughts on your points:
> > 
> >> 1. First of all I would like to deny access to everything except
> >> "/stream.ogg" depends on client IP.
> > 
> > Icecast will request requests for any unknown target anyway. If you
> > don't like access to the static files in web/ you can just delete them
> > or set <webroot> to an empty path.
> > 
> > admin/ is protected, so unauthed clients will get a reject anyway.
> > 
> > 
> > I don't really see a reason for a reverse proxy here. Icecast already
> > rejects those requests. Plus I hardly see harm that could be caused
> > beside a bit of extra traffic.
> > 
> > allow/deny rules for IPs can be defined with <allow-ip> and <deny-ip>.
> > Plus if you really have a list of "malicious" clients you should likely
> > block them on your border gateway or firewall anyway.
> > 
> > 
> >> 2. Deny everything depends on User-Agent value and User-Agent length.
> > 
> > Without an answer to my question above you can hardly discuss this. But
> > I don't see much point in this generally as the user agent string is
> > basically a freeform user setting. So an attacker can change it at will.
> > 
> > At best it would be helpful to do some matches to avoid getting hits by
> > misbehaving clients. But that is a totally different class than
> > attacking clients.
> > 
> > Also, such a check could be implemented in Icecast as well. Depending on
> > your version in different ways.
> > 
> > 
> >> 3. Deny HTTP 1.0 protocol.
> > 
> > Which is a bad idea as Icecast 2.4.x (stable) IS a HTTP/1.0 server. So
> > if you disable that protocol and you still can connect your filter does
> > not work anyway.
> > 
> > 
> >> Application-Layer DDoS Attack Protection with
> >> HAProxy: "A number of attacks use HTTP/1.0 as the protocol version because
> >> that's the version supported by some bots."
> > 
> > While we move away from Icecast there is nothing inherently wrong with
> > HTTP/1.0 in Icecast context. And again, those bots could be easily
> > updated to use HTTP/1.1 by setting the version to HTTP/1.1 and adding a
> > Host:-header (which they likely send already).
> > 
> > 
> >> 4. Turn on/off anti-DoS protection depends on connection rate.
> > 
> > This is clearly a common firewall feature. Limiting rate or request rate
> > can be done with any firewall. And is totally done best there as it will
> > filter out traffic before it even hits your server.
> > 
> > 
> > Here is another point you should add to your consideration:
> > A reverse proxy adds an additional, complex component to your setup. It
> > therefore increases the attack surface (it has it's own bugs, it's own
> > flaws, ...).
> > A reverse proxy need to process the HTTP level messages an additional
> > time. This requires additional CPU power and time.
> > It also requires additional system resources like sockets, file
> > descriptors, I/O-buffers, scheduling slots, ...
> > 
> > So a reverse proxy always amplifies any *DoS kind of attack as
> > significant more resources are required per request.
> > 
> > 
> > From a business perspective it will add more costs: system resources,
> > maintenance, more skilled admins, ... For a single hour of admin time
> > you can book a VPS at a random provider for a complete year that can
> > handle 10k simultaneous connections or 10k simultaneous "malicious"
> > connections.
> > 
> > With best regards,
> > 
> > -- 
> > Philipp.
> > (Rah of PH2)
> > _______________________________________________
> > Icecast mailing list
> > Icecast at xiph.org
> > http://lists.xiph.org/mailman/listinfo/icecast
> _______________________________________________
> Icecast mailing list
> Icecast at xiph.org
> http://lists.xiph.org/mailman/listinfo/icecast

-- 



From lion at lion.leolix.org  Thu Feb 13 16:14:58 2020
From: lion at lion.leolix.org (Philipp Schafft)
Date: Thu, 13 Feb 2020 16:14:58 +0000
Subject: [Icecast] Why I responded publicly [WAS: admin console]
In-Reply-To: <20200213145930.6FBC641986@smtp.postman.i2p>
References: <1581601594.2179.243.camel@lion.leolix.org>
 <20200213140150.52E574196D@smtp.postman.i2p>
 <20200213145930.6FBC641986@smtp.postman.i2p>
Message-ID: <1581610498.2179.259.camel@lion.leolix.org>

Good evening,


On Thu, 2020-02-13 at 14:59 +0000, user wrote:
> Philipp Schafft, who allow you to publish my private message?

I could also ask who allowed you to send me unwanted private messages?

In fact I did not notice it was sent privately until after my reply. It
was totally unexpected to be private as it did not contain any hints for
that nor any sensitive information. And it was clearly an reply to an
question I posted on a public list wich clearly asked for a public
reply.

Even more as not replying to the list but privately is a common mistake
I didn't thought much about it. Also keeping in mind that you break
threading. Like here:

> > Remove
> > -Pete

This is not from my mail. So I thought it was just another tiny mistake.


What I feel discomfort about is that this is getting away from the
actual discussion. I don't think the public list is interested in this.
However more interested in your comments on my questions.

I hope that we can get back on-topic. I would be happy to hear from you
about the actual questions and will ignore future meta mails.
If you want to complain about me, feel free to contact
<icecast-owner at xiph.org>.


> [...] 

With best regards and best hopes for this thread,

-- 
Philipp.
 (Rah of PH2)


From chiapas at aktivix.org  Thu Feb 13 22:44:46 2020
From: chiapas at aktivix.org (Chip)
Date: Thu, 13 Feb 2020 22:44:46 +0000
Subject: [Icecast] Possible CORS issue
Message-ID: <CAKCymP0nJ+6KEVZr9BU5R-TJJKEQ21b84QcMGytCdE4ebjeAFQ@mail.gmail.com>

Hi

I'm clutching at straws here.

I have a user who requires access to a status-json.xsl to publish now
playing data for an Alexa skill and this can be accessed via a browser at:

   - http://example.com:8000/status-json.xsl

He says that now his PHP script cannot access the file.

I know that Alexa requires *streams* to be served over https but this has
previously worked and his skill is curerently failing at accessing the
status-json.xsl file.

This is successful:

curl http://example.com:8000/status-json.xsl

But this:

curl -I http://example.com:8000/status-json.xsl

gives a Bad Request:

HTTP/1.0 400 Bad Request

I'm wondering if this might be a CORS issue:

   - https://enable-cors.org/server.html

If that is so, what would be the appropriate solution from the above to
remedy the problem?

With many thanks in advance

Chip Scooter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20200213/49e62c14/attachment.htm>

From epirat07 at gmail.com  Thu Feb 13 22:51:09 2020
From: epirat07 at gmail.com (Marvin Scholz)
Date: Thu, 13 Feb 2020 23:51:09 +0100
Subject: [Icecast] Possible CORS issue
In-Reply-To: <CAKCymP0nJ+6KEVZr9BU5R-TJJKEQ21b84QcMGytCdE4ebjeAFQ@mail.gmail.com>
References: <CAKCymP0nJ+6KEVZr9BU5R-TJJKEQ21b84QcMGytCdE4ebjeAFQ@mail.gmail.com>
Message-ID: <5D7077B9-0639-4A44-AA5C-D75CA311C7CF@gmail.com>

On 13 Feb 2020, at 23:44, Chip wrote:

> Hi
>
> I'm clutching at straws here.
>
> I have a user who requires access to a status-json.xsl to publish now
> playing data for an Alexa skill and this can be accessed via a browser at:
>
>    - http://example.com:8000/status-json.xsl
>
> He says that now his PHP script cannot access the file.
>
> I know that Alexa requires *streams* to be served over https but this has
> previously worked and his skill is curerently failing at accessing the
> status-json.xsl file.
>
> This is successful:
>
> curl http://example.com:8000/status-json.xsl
>
> But this:
>
> curl -I http://example.com:8000/status-json.xsl
>
> gives a Bad Request:
>
> HTTP/1.0 400 Bad Request
>
> I'm wondering if this might be a CORS issue:
>
>    - https://enable-cors.org/server.html
>

Hi,

If they are using a PHP script I fail to see how CORS would involved here
as that would be only relevant with JavaScript.

The reason curl -I fails is because it does a HEAD request which is not
supported.

> If that is so, what would be the appropriate solution from the above to
> remedy the problem?
>

You can add additional headers in the Icecast config:

    <http-headers>
        <header name="Access-Control-Allow-Origin" value="*" />
    </http-headers>

See the documentation for more info:

http://icecast.org/docs/icecast-2.4.1/config-file.html#global-headers

In Icecast 2.5 more advanced CORS handling will be possible.

> With many thanks in advance
>
> Chip Scooter
> _______________________________________________
> Icecast mailing list
> Icecast at xiph.org
> http://lists.xiph.org/mailman/listinfo/icecast


From 5f787a at i2pmail.org  Fri Feb 14 08:40:27 2020
From: 5f787a at i2pmail.org (user)
Date: Fri, 14 Feb 2020 08:40:27 +0000 (UTC)
Subject: [Icecast] Why I responded publicly [WAS: admin console]
In-Reply-To: <20200213161541.B056E416FB@smtp.postman.i2p>
References: <1581601594.2179.243.camel@lion.leolix.org>
 <20200213140150.52E574196D@smtp.postman.i2p>
 <20200213145930.6FBC641986@smtp.postman.i2p>
 <20200213161541.B056E416FB@smtp.postman.i2p>
Message-ID: <20200214084027.310914173F@smtp.postman.i2p>

> On Thu, 2020-02-13 at 14:59 +0000, user wrote:
> > Philipp Schafft, who allow you to publish my private message?
> 
> I could also ask who allowed you to send me unwanted private messages?

At this point any message from Philipp Schafft to me becomes absolutely
unwanted.

> In fact I did not notice it was sent privately until after my reply. It

Notice can be found on third string of the quoted header. There is no other
recipients, only Philipp Schafft, who trying to talk about security, but
does not respect privacy as we see now.

 Date: Tue, 11 Feb 2020
 From: user <5f787a at ...>
 To: Philipp Schafft <lion at lion.leol...>
 Subject: Re: [Icecast] admin console
 
 > Good evening,
 > 
 > On Thu, 2020-02-06 at 19:20 +0000, user wrote:
 > > 2020-01-08 09:59, Marvin Scholz wrote:
 > > > >> On Mon, 2020-01-06 at 10:24 +0000, user 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?
 > > > 
 > > > In general putting Icecast behind a reverse proxy is not the best idea
 > > > as some webservers are not really made out of the box to easily deal
 > > > with the kind of usage Icecast will usually produce (long running
 > > > connections serving a continuous stream). Additionally Icecast is not
 > > > really capable currently do deal with being reverse-proxied properly
 > > > so some things will break when doing that.
 > > > 
 > > > So unless you want to shoot yourself in the foot and run into various
 > > > issues I would not recommend to do it.
 > > 
 > > Expectation on malicious activity force me to put icecast behind reverse
 > > proxy. It was not easy, but works very well.
 > 
 > So, what kind of "malicious activity" exactly? And what exact HTTP level
 > software is more robust against those activities than Icecast?
 > 
 > I'm fully in support that active components on lower levels can be helpful
 > in some situations. But I would love to hear about any analysis indicating
 > specific request patterns that would be better handled by external
 > software. If you would share your information rather than keeping us in
 > the dark about specifics it would enable us to improve Icecast for all
 > users including you. :)
 > 
 > With best regards,
 
 1. First of all I would like to deny access to everything except
...





From epirat07 at gmail.com  Fri Feb 14 14:53:59 2020
From: epirat07 at gmail.com (Marvin Scholz)
Date: Fri, 14 Feb 2020 15:53:59 +0100
Subject: [Icecast] Why I responded publicly [WAS: admin console]
In-Reply-To: <20200214084027.310914173F@smtp.postman.i2p>
References: <1581601594.2179.243.camel@lion.leolix.org>
 <20200213140150.52E574196D@smtp.postman.i2p>
 <20200213145930.6FBC641986@smtp.postman.i2p>
 <20200213161541.B056E416FB@smtp.postman.i2p>
 <20200214084027.310914173F@smtp.postman.i2p>
Message-ID: <51D3E4A0-CCB1-4990-8785-89F88B2044AE@gmail.com>

On 14 Feb 2020, at 9:40, user wrote:

>> On Thu, 2020-02-13 at 14:59 +0000, user wrote:
>>> Philipp Schafft, who allow you to publish my private message?
>>
>> I could also ask who allowed you to send me unwanted private 
>> messages?
>
> At this point any message from Philipp Schafft to me becomes 
> absolutely
> unwanted.
>
>> In fact I did not notice it was sent privately until after my reply. 
>> It
>
> Notice can be found on third string of the quoted header. There is no 
> other
> recipients, only Philipp Schafft, who trying to talk about security, 
> but
> does not respect privacy as we see now.
>
>  Date: Tue, 11 Feb 2020
>  From: user <5f787a at ...>
>  To: Philipp Schafft <lion at lion.leol...>
>  Subject: Re: [Icecast] admin console
>

Sorry but did you only came to this ML to troll? If so, please do that 
somewhere
else.

Claiming you reverse proxy Icecast for ?security reasons? you fail 
to further detail
and then when asked about your reverse proxy setup refuse to give any 
information
whatsoever and just replied ?No? is just quite a troll behavior.

If you are not interested in helping improving things, discuss things 
publicly
and help others out, I don?t really see why you even write to this 
list at all.

>> Good evening,
>>
>> On Thu, 2020-02-06 at 19:20 +0000, user wrote:
>>> 2020-01-08 09:59, Marvin Scholz wrote:
>>>>>> On Mon, 2020-01-06 at 10:24 +0000, user 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?
>>>>
>>>> In general putting Icecast behind a reverse proxy is not the best 
>>>> idea
>>>> as some webservers are not really made out of the box to easily 
>>>> deal
>>>> with the kind of usage Icecast will usually produce (long running
>>>> connections serving a continuous stream). Additionally Icecast is 
>>>> not
>>>> really capable currently do deal with being reverse-proxied 
>>>> properly
>>>> so some things will break when doing that.
>>>>
>>>> So unless you want to shoot yourself in the foot and run into 
>>>> various
>>>> issues I would not recommend to do it.
>>>
>>> Expectation on malicious activity force me to put icecast behind 
>>> reverse
>>> proxy. It was not easy, but works very well.
>>
>> So, what kind of "malicious activity" exactly? And what exact HTTP 
>> level
>> software is more robust against those activities than Icecast?
>>
>> I'm fully in support that active components on lower levels can be 
>> helpful
>> in some situations. But I would love to hear about any analysis 
>> indicating
>> specific request patterns that would be better handled by external
>> software. If you would share your information rather than keeping us 
>> in
>> the dark about specifics it would enable us to improve Icecast for 
>> all
>> users including you. :)
>>
>> With best regards,
>
>  1. First of all I would like to deny access to everything except
> ...


From chiapas at aktivix.org  Fri Feb 14 20:46:40 2020
From: chiapas at aktivix.org (Chip)
Date: Fri, 14 Feb 2020 20:46:40 +0000
Subject: [Icecast] Possible CORS issue
In-Reply-To: <CAMhwV+7fm_5ecROdNwgpR7GaL_A8DDrdO0wGS7yEeO=1OyJojA@mail.gmail.com>
References: <CAKCymP0nJ+6KEVZr9BU5R-TJJKEQ21b84QcMGytCdE4ebjeAFQ@mail.gmail.com>
 <5D7077B9-0639-4A44-AA5C-D75CA311C7CF@gmail.com>
 <CAMhwV+7fm_5ecROdNwgpR7GaL_A8DDrdO0wGS7yEeO=1OyJojA@mail.gmail.com>
Message-ID: <CAKCymP36FS+OcjuCGJpbPrOt1Sd3_GPWQnvNGQF4j50-bEE5=g@mail.gmail.com>

> ---------- Marvin wrote ---------
> From: Marvin Scholz <epirat07 at gmail.com>
> Date: Thu, 13 Feb 2020 at 22:51
>
> On 13 Feb 2020, at 23:44, Chip wrote:
> >
> > This is successful:
> >
> > curl http://example.com:8000/status-json.xsl
> >
> > But this:
> >
> > curl -I http://example.com:8000/status-json.xsl
> >
> > gives a Bad Request:
> >
> > HTTP/1.0 400 Bad Request
>
> Hi,
>
> If they are using a PHP script I fail to see how CORS would involved here
> as that would be only relevant with JavaScript.
>
> The reason curl -I fails is because it does a HEAD request which is not
> supported.
>
> > If that is so, what would be the appropriate solution from the above to
> > remedy the problem?
> >
>
> You can add additional headers in the Icecast config:
>
>     <http-headers>
>         <header name="Access-Control-Allow-Origin" value="*" />
>     </http-headers>
>
> See the documentation for more info:
>
> http://icecast.org/docs/icecast-2.4.1/config-file.html#global-headers
>
> In Icecast 2.5 more advanced CORS handling will be possible.
>

Thanks.

Perhaps it's not a CORS issue. I'm drowning and catching hold of anything
to try to stay afloat.

Forget CORS then.

It appears that Icecast might be mangling the headers of the
status-json.xslt file.

Curiously, if I serve the file over https from another Icecast server, I do
not get a 400 Bad Request error:

[chip at machine ~]# curl -I https://example2.com:8001/status-json.xsl
HTTP/1.0 200 OK
Content-Type: application/json
Content-Length: 983
Content-Disposition: attachment; filename="file.json"
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate
Pragma: no-cache
Connection: Keep-Alive
Access-Control-Allow-Origin: *
Access-Control-Allow-Headers: Origin, Accept, X-Requested-With, Content-Type
Access-Control-Allow-Methods: GET, OPTIONS, HEAD

The above appears to add some Access-Control elements.

Serving over https is actually irrelevant:

[chip at machine ~]# curl -I http://example2.com:8000/status-json.xsl
HTTP/1.0 200 OK
Content-Type: application/json
Content-Length: 1010
Content-Disposition: attachment; filename="file.json"
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate
Pragma: no-cache
Connection: Keep-Alive
Access-Control-Allow-Origin: *
Access-Control-Allow-Headers: Origin, Accept, X-Requested-With, Content-Type
Access-Control-Allow-Methods: GET, OPTIONS, HEAD

The second version above works because Icecast is configured differently to
the first example - indeed, they're different versions:

This doesn't work:

[chip at machine]# icecast -v
Icecast 2.3.3-kh11-20150225150031

This one works with curl nicely:

[chip at machine2]# icecast -v
Icecast 2.4.0-kh12-8-gc6e5d83

How easy is it to upgrade Icecast mid-flight on a production server? Can it
be done seamlessly or what sort of downtime am I looking at?

Many thanks for your help

Chip
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20200214/7ac99e46/attachment.htm>

From epirat07 at gmail.com  Fri Feb 14 22:36:55 2020
From: epirat07 at gmail.com (Marvin Scholz)
Date: Fri, 14 Feb 2020 23:36:55 +0100
Subject: [Icecast] Possible CORS issue
In-Reply-To: <CAKCymP36FS+OcjuCGJpbPrOt1Sd3_GPWQnvNGQF4j50-bEE5=g@mail.gmail.com>
References: <CAKCymP0nJ+6KEVZr9BU5R-TJJKEQ21b84QcMGytCdE4ebjeAFQ@mail.gmail.com>
 <5D7077B9-0639-4A44-AA5C-D75CA311C7CF@gmail.com>
 <CAMhwV+7fm_5ecROdNwgpR7GaL_A8DDrdO0wGS7yEeO=1OyJojA@mail.gmail.com>
 <CAKCymP36FS+OcjuCGJpbPrOt1Sd3_GPWQnvNGQF4j50-bEE5=g@mail.gmail.com>
Message-ID: <017B4BE8-3B8D-4402-B893-D13E0AEB56D0@gmail.com>



On 14 Feb 2020, at 21:46, Chip wrote:
>
> [?]
>
> The second version above works because Icecast is configured 
> differently to
> the first example - indeed, they're different versions:
>
> This doesn't work:
>
> [chip at machine]# icecast -v
> Icecast 2.3.3-kh11-20150225150031


Hi,
you are using Icecast-kh, this is quite different from the
?normal? Icecast and we can not offer help for it, as we are
no familiar with it.

You might want to either switch to the ?official? Icecast
or maybe file a bug with the Icecast-kh project instead.

>
> This one works with curl nicely:
>
> [chip at machine2]# icecast -v
> Icecast 2.4.0-kh12-8-gc6e5d83
>

I assume thats probably because Icecast-kh 2.4 might have added HEAD 
support?

> How easy is it to upgrade Icecast mid-flight on a production server? 
> Can it
> be done seamlessly or what sort of downtime am I looking at?
>

You will eventually need to restart the Icecast server (or rather, stop 
the ?old?
one and start the ?new? one) so there will be a short downtime.

> Many thanks for your help
>
> Chip


From chiapas at aktivix.org  Fri Feb 14 22:48:08 2020
From: chiapas at aktivix.org (Chip)
Date: Fri, 14 Feb 2020 22:48:08 +0000
Subject: [Icecast] Possible CORS issue
In-Reply-To: <017B4BE8-3B8D-4402-B893-D13E0AEB56D0@gmail.com>
References: <CAKCymP0nJ+6KEVZr9BU5R-TJJKEQ21b84QcMGytCdE4ebjeAFQ@mail.gmail.com>
 <5D7077B9-0639-4A44-AA5C-D75CA311C7CF@gmail.com>
 <CAMhwV+7fm_5ecROdNwgpR7GaL_A8DDrdO0wGS7yEeO=1OyJojA@mail.gmail.com>
 <CAKCymP36FS+OcjuCGJpbPrOt1Sd3_GPWQnvNGQF4j50-bEE5=g@mail.gmail.com>
 <017B4BE8-3B8D-4402-B893-D13E0AEB56D0@gmail.com>
Message-ID: <CAKCymP3VHpizDwaR1xzHsJ82fiGxGMcxPgxnhihKFJaXf4MwSQ@mail.gmail.com>

Thanks Marvin.

On Fri, 14 Feb 2020 at 22:37, Marvin Scholz <epirat07 at gmail.com> wrote:

>
> Hi,
> you are using Icecast-kh, this is quite different from the
> ?normal? Icecast and we can not offer help for it, as we are
> no familiar with it.
>

Ok, thanks. I see.

[...]

I assume thats probably because Icecast-kh 2.4 might have added HEAD
> support?
>

Does icecast 2.4.4 not have HEAD support  ?

[...]

You will eventually need to restart the Icecast server (or rather, stop
> the ?old? one and start the ?new? one) so there will be a short downtime.
>

Thank you very much. I'll do this in a few hours time.

All the best for now

Chip
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20200214/27d9344f/attachment.htm>

From lion at lion.leolix.org  Sat Feb 15 14:21:37 2020
From: lion at lion.leolix.org (Philipp Schafft)
Date: Sat, 15 Feb 2020 14:21:37 +0000
Subject: [Icecast] Possible CORS issue
In-Reply-To: <CAKCymP3VHpizDwaR1xzHsJ82fiGxGMcxPgxnhihKFJaXf4MwSQ@mail.gmail.com>
References: <CAKCymP0nJ+6KEVZr9BU5R-TJJKEQ21b84QcMGytCdE4ebjeAFQ@mail.gmail.com>
 <5D7077B9-0639-4A44-AA5C-D75CA311C7CF@gmail.com>
 <CAMhwV+7fm_5ecROdNwgpR7GaL_A8DDrdO0wGS7yEeO=1OyJojA@mail.gmail.com>
 <CAKCymP36FS+OcjuCGJpbPrOt1Sd3_GPWQnvNGQF4j50-bEE5=g@mail.gmail.com>
 <017B4BE8-3B8D-4402-B893-D13E0AEB56D0@gmail.com>
 <CAKCymP3VHpizDwaR1xzHsJ82fiGxGMcxPgxnhihKFJaXf4MwSQ@mail.gmail.com>
Message-ID: <1581776497.2179.283.camel@lion.leolix.org>

Good morning,


On Fri, 2020-02-14 at 22:48 +0000, Chip wrote:
> Thanks Marvin.
> 
> On Fri, 14 Feb 2020 at 22:37, Marvin Scholz <epirat07 at gmail.com> wrote:
> Does icecast 2.4.4 not have HEAD support  ?

No, official Icecast does not support HEAD requests as they are largely
useless in Icecast context.

HEAD requests are meant for cache validation. So they only apply to
static files basically. For Icecast, beside a few boring files in web/
the answer to "is my copy still valid" is always "no". So by not
supporting HEAD the client will retry with GET. Which... the client
would need to do anyway IF we would reply with a positive status code
for HEAD.

Also (ab)using HEAD for monitoring is hardly useful:
The stress to the server is the same for answering a non-stub* response
to HEAD than to GET as in both cases the client must be attached to the
source. Even a stub response ("endpoint exists" or "not found") would
require most steps. It requires finding the endpoint, running its auth
and applying its ACLs. That is more than half way thru the attach
process.


Hope that helps you. :)

With best regards,

* Non-stub results are hardly useful as HTTP is stateless anyway. The
standard acknowledges that by making all information about the actual
resource beside its existence optional.

-- 
Philipp.
 (Rah of PH2)


From chiapas at aktivix.org  Sun Feb 16 07:58:29 2020
From: chiapas at aktivix.org (Chip)
Date: Sun, 16 Feb 2020 07:58:29 +0000
Subject: [Icecast] Possible CORS issue
In-Reply-To: <1581776497.2179.283.camel@lion.leolix.org>
References: <CAKCymP0nJ+6KEVZr9BU5R-TJJKEQ21b84QcMGytCdE4ebjeAFQ@mail.gmail.com>
 <5D7077B9-0639-4A44-AA5C-D75CA311C7CF@gmail.com>
 <CAMhwV+7fm_5ecROdNwgpR7GaL_A8DDrdO0wGS7yEeO=1OyJojA@mail.gmail.com>
 <CAKCymP36FS+OcjuCGJpbPrOt1Sd3_GPWQnvNGQF4j50-bEE5=g@mail.gmail.com>
 <017B4BE8-3B8D-4402-B893-D13E0AEB56D0@gmail.com>
 <CAKCymP3VHpizDwaR1xzHsJ82fiGxGMcxPgxnhihKFJaXf4MwSQ@mail.gmail.com>
 <1581776497.2179.283.camel@lion.leolix.org>
Message-ID: <CAKCymP1VdOVm8H4WE3M1oeyU-0NfxGo6GKhGdbCzj4AHay43Aw@mail.gmail.com>

Good morning

On Sat, 15 Feb 2020 at 14:30, Philipp Schafft <lion at lion.leolix.org> wrote:

>
> No, official Icecast does not support HEAD requests as they are largely
> useless in Icecast context.
>
> HEAD requests are meant for cache validation. So they only apply to
> static files basically. For Icecast, beside a few boring files in web/
> the answer to "is my copy still valid" is always "no". So by not
> supporting HEAD the client will retry with GET. Which... the client
> would need to do anyway IF we would reply with a positive status code
> for HEAD.
>
> Also (ab)using HEAD for monitoring is hardly useful:
> The stress to the server is the same for answering a non-stub* response
> to HEAD than to GET as in both cases the client must be attached to the
> source. Even a stub response ("endpoint exists" or "not found") would
> require most steps. It requires finding the endpoint, running its auth
> and applying its ACLs. That is more than half way thru the attach
> process.
>
> Hope that helps you. :)
>
> With best regards,
>
> * Non-stub results are hardly useful as HTTP is stateless anyway. The
> standard acknowledges that by making all information about the actual
> resource beside its existence optional.
>

 Unfortunately, I don't yet understand most of that - but I will read and
re-read.

However using Icecast 2.4.4, is there an alternative method for my client
to access status-json.xsl so that they can access "now playing" data?

My client is using this for an Alexa skill which can positively respond to
questions such as "Alexa, what is now playing on Radio Blah-Blah?" - which
sounds pretty cool to me. They could have worked around this by uploading
"now playing" data via FTP but status-json.xsl had been working fine
previously.

For the moment, I've implemented Icecast-KH and my client is happy but I'd
like to explore the options using 'official Icecast'.

Many thanks for the learning and best regards

Chip
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20200216/7c60fc71/attachment.htm>

From james at switchbladeuk.com  Sun Feb 16 09:57:04 2020
From: james at switchbladeuk.com (James Turner)
Date: Sun, 16 Feb 2020 09:57:04 -0000
Subject: [Icecast] Icecast SSL endpoint timeout issue
Message-ID: <003801d5e4af$7153e170$53fba450$@switchbladeuk.com>

Hi team,

Please accent my apologies if this is NOT the place/distro list to be
raising this. I had major dramas with the standard forum - registration and
decided this may be a better route. 

My current instance icecast server has been built with  --with-curl
--with-openssl  options as outlined within this post:
https://weekly-geekly.github.io/articles/350236/index.html and the build
version is 2.4.99.2

I'm using a valid certificate from letsencrypt on a Ubuntu 18 server hosted
by AWS. Icecast recognizes this without issue.

I'm having issues disconnecting  my source client  from Icecast when the
connections is via SSL. Non SSL source clients work as intended, connecting
and disconnecting without issues and Icecast shuts down the mount points
after client drop-outs as intended. See the logs outlined below for details.
Using an SSL connection and once the client connection drops (for whatever
reason) Icecast does not recognize this and keeps the mount point active
forever - even when there's no data being sent by the client.  On a
reconnect try  the client gets a 'mount point already in use' message. To
get over this state I either have to restart the Icecast service OR manually
kill the source from the admin interface. Once done. I can reconnect
again.repeating the process

Frustratingly, this (SSL) works (source>icecast>listener) - just about -
but I'd dearly like to understand the issue with the ssl connection and
mountpoint not being released. I would expect a source timeout to occur, as
defined in the Icecast config file thus releasing the mount point. However,
not to be. 

Connecting to unencrypted Icecast port (8000)

Access.log
xx.xx.xx.xxx- - [09/Feb/2020:17:56:50 +0000] "SOURCE /acdc.ogg HTTP/1.0" 401
777 "-" "libshout/2.4.1" 0
Error.log
[2020-02-09  17:56:50] EROR connection/_handle_authed_client Client
(role=anonymous, username=(null)) not allowed to use this request method on
/acdc.ogg
[2020-02-09  17:56:50] EROR util/util_http_select_best Input string does not
parse as KVA. Selecting first option.
[2020-02-09  17:56:50] WARN reportxml/reportxml_database_build_report No
matching definition for "25387198-0643-4577-9139-7c4f24f59d4a"
[2020-02-09  17:56:50] INFO connection/_handle_source_request Source logging
in at mountpoint "/acdc.ogg" using "SOURCE" from xx.xx.xx.xxx as role
legacy-global-source
[2020-02-09  17:56:50] INFO source/source_main listener count on /acdc.ogg
now 0
[2020-02-09  17:56:50] INFO format-opus/initial_opus_page seen initial opus
header

Source client disconnects.
Access.log
xx.xx.xx.xxx- source [09/Feb/2020:17:56:57 +0000] "SOURCE /acdc.ogg
HTTP/1.0" 200 324 "-" "libshout/2.4.1" 7

Error.log
[2020-02-09  17:53:12] INFO source/get_next_buffer End of Stream /acdc.ogg
[2020-02-09  17:53:12] INFO source/source_shutdown Source from xx.xx.xx.xxx
at "/acdc.ogg" exiting


Connection by source client Using SSL (port 8444):
Connect:
Access.log
xx.xx.xx.xxx- source [09/Feb/2020:18:00:25 +0000] "GET /admin/metadata
HTTP/1.1" 200 481 "-" "Mozilla/5.0" 0
Error.log

[2020-02-09  18:00:24] INFO connection/_handle_source_request Source logging
in at mountpoint "/acdc.ogg" using "SOURCE" from xx.xx.xx.xxx as role
legacy-global-source
[2020-02-09  18:00:24] WARN format/format_get_type Unsupported or legacy
stream type: "audio/mpeg". Falling back to generic minimal handler for best
effort.
[2020-02-09  18:00:25] INFO source/source_main listener count on /acdc.ogg
now 0
[2020-02-09  18:00:25] INFO admin/admin_handle_request Received admin
command metadata on mount '/acdc.ogg'
[2020-02-09  18:00:25] INFO util/util_conv_string converting metadata from
utf-8 to ISO8859-1
[2020-02-09  18:00:25] INFO admin/command_metadata Metadata on mountpoint
/acdc.ogg changed to " - "

Source disconnects here.
.	No log entries - no source timeouts.
.	Mountpoint (here acdc.ogg) still active and visible in the admin
interface
.	Source client cannot reconnect - see message below:


Action: Source client tries to reconnect (port 8000 or 8444)

Access.log
xx.xx.xx.xxx- - [09/Feb/2020:18:03:53 +0000] "SOURCE /acdc.ogg HTTP/1.0" 401
777 "-" "libshout/2.4.1" 1
xx.xx.xx.xxx- source [09/Feb/2020:18:03:53 +0000] "SOURCE /acdc.ogg
HTTP/1.0" 409 706 "-" "libshout/2.4.1" 0

Error.log

[2020-02-09  18:03:52] EROR connection/_handle_authed_client Client
(role=anonymous, username=(null)) not allowed to use this request method on
/acdc.ogg
[2020-02-09  18:03:52] EROR util/util_http_select_best Input string does not
parse as KVA. Selecting first option.
[2020-02-09  18:03:52] WARN reportxml/reportxml_database_build_report No
matching definition for "25387198-0643-4577-9139-7c4f24f59d4a"
[2020-02-09  18:03:53] INFO connection/_handle_source_request Source logging
in at mountpoint "/acdc.ogg" using "SOURCE" from xx.xx.xx.xxx as role
legacy-global-source
[2020-02-09  18:03:53] EROR util/util_http_select_best Input string does not
parse as KVA. Selecting first option.
[2020-02-09  18:03:53] WARN reportxml/reportxml_database_build_report No
matching definition for "c5724467-5f85-48c7-b45a-915c3150c292"
[2020-02-09  18:03:53] WARN connection/source_startup Mountpoint /acdc.ogg
in use


Any pointers very welcome.

Here is the config.xml file for the server used:

<icecast>
    <!-- location and admin are two arbitrary strings that are e.g. visible
         on the server info page of the icecast web interface
         (server_version.xsl). -->
    <location>earth</location>
    <admin>icemaster at localhost</admin>

    <!-- IMPORTANT!
         Especially for inexperienced users:
         Start out by ONLY changing all passwords and restarting Icecast.
         For detailed setup instructions please refer to the documentation.
         It's also available here: http://icecast.org/docs/
   -->

    <limits>
        <clients>100</clients>
        <sources>2</sources>
        <queue-size>524288</queue-size>
        <client-timeout>30</client-timeout>
        <header-timeout>15</header-timeout>
        <source-timeout>10</source-timeout>
        <!-- If enabled, this will provide a burst of data when a client 
             first connects, thereby significantly reducing the startup 
             time for listeners that do substantial buffering. However,
             it also significantly increases latency between the source
             client and listening client.  For low-latency setups, you
             might want to disable this. -->

        <!-- same as burst-on-connect, but this allows for being more
             specific on how much to burst. Most people won't need to
             change from the default 64k. Applies to all mountpoints  -->
        <burst-size>65535</burst-size>
    </limits>

    <authentication>
        <!-- Sources log in with username 'source' -->
        <source-password>hackme57</source-password>
        <!-- Relays log in with username 'relay' -->
        <relay-password>hackme58</relay-password>

        <!-- Admin logs in with the username given below -->
        <admin-user>admin</admin-user>
        <admin-password>ITJShKNE0pRg</admin-password>
    </authentication>

    <!-- set the mountpoint for a shoutcast source to use, the default if
not
         specified is     /stream but you can change it here if an
alternative is
         wanted or an extension is required
    <shoutcast-mount>/live.nsv</shoutcast-mount>
    -->

    <!-- Uncomment this if you want directory listings -->
    <!--
    <directory>
        <yp-url-timeout>15</yp-url-timeout>
        <yp-url>http://dir.xiph.org/cgi-bin/yp-cgi</yp-url>
    </directory>
    -->

    <!-- This is the hostname other people will use to connect to your
server.
         It affects mainly the urls generated by Icecast for playlists and
yp
         listings. You MUST configure it properly for YP listings to work!
    -->
    <hostname>localhost</hostname>

    <!-- You may have multiple <listener> elements -->
    <listen-socket>
           <port>8000</port>
           <ssl>0</ssl>
        <!-- <bind-address>127.0.0.1</bind-address> -->
        <!-- <shoutcast-mount>/stream</shoutcast-mount> -->
    </listen-socket>
    <!--
    <listen-socket>
        <port>8080</port>
    </listen-socket>
    -->

    <listen-socket>
           <port>8444</port>
        <ssl>1</ssl>
    </listen-socket>


    <!-- Global header settings 
         Headers defined here will be returned for every HTTP request to
Icecast.

         The ACAO header makes Icecast public content/API by default
         This will make streams easier embeddable (some HTML5 functionality
needs it).
         Also it allows direct access to e.g. /status-json.xsl from other
sites.
         If you don't want this, comment out the following line or read up
on CORS. 
    -->
    <http-headers>
        <header name="Access-Control-Allow-Origin" value="*" />
    </http-headers>


    <!-- Relaying:
         You don't need this if you only have one server.
         Please refer to the config for a detailed explanation.
    -->
    <!--<master-server>127.0.0.1</master-server>-->
    <!--<master-server-port>8001</master-server-port>-->
    <!--<master-update-interval>120</master-update-interval>-->
    <!--<master-password>hackme</master-password>-->

    <!-- setting this makes all relays on-demand unless overridden, this is
         useful for master relays which do not have <relay> definitions
here.
         The default is 0 -->
    <!--<relays-on-demand>1</relays-on-demand>-->

    <!--
    <relay>
        <server>127.0.0.1</server>
        <port>8080</port>
        <mount>/example.ogg</mount>
        <local-mount>/different.ogg</local-mount>
        <on-demand>0</on-demand>

        <relay-shoutcast-metadata>0</relay-shoutcast-metadata>
    </relay>
    -->


    <!-- Mountpoints
         Only define <mount> sections if you want to use advanced options,
         like alternative usernames or passwords
    -->

    <!-- Default settings for all mounts that don't have a specific <mount
type="normal">.
    -->
    <!--
    <mount type="default">
        <public>0</public>
        <intro>/server-wide-intro.ogg</intro>
        <max-listener-duration>3600</max-listener-duration>
        <authentication type="url">
                <option name="mount_add"
value="http://auth.example.org/stream_start.php"/>
        </authentication>
        <http-headers>
                <header name="foo" value="bar" />
        </http-headers>
    </mount>
    -->

    <!-- Normal mounts -->

    <mount type="normal">
        <mount-name>/acdc.ogg</mount-name>

        <!--username>othersource</username>
        <password>hackme_1666</password-->

        <max-listeners>1</max-listeners>
        <!--dump-file>/tmp/dump-example1.ogg</dump-file-->
        <burst-size>65536</burst-size>
        <!--fallback-mount>/example2.ogg</fallback-mount>
        <fallback-override>1</fallback-override>
        <fallback-when-full>1</fallback-when-full>
        <intro>/example_intro.ogg</intro-->
        <hidden>0</hidden>
        <public>0</public>
        <authentication type="htpasswd">
             <option name="filename" value="/var/log/icecast2/password"/>
                <option name="allow_duplicate_users" value="0"/>
        </authentication>
        <http-headers>
                <header name="Access-Control-Allow-Origin"
value="http://webplayer.example.org" />
        </http-headers>
        <!--on-connect>/home/icecast/bin/stream-start</on-connect>
        <on-disconnect>/home/icecast/bin/stream-stop</on-disconnect-->
    </mount>


    <fileserve>1</fileserve>

    <paths>
        <!-- basedir is only used if chroot is enabled -->
        <basedir>./</basedir>

        <!-- Note that if <chroot> is turned on below, these paths must both
             be relative to the new root, not the original root -->
        <logdir>/var/log/icecast2</logdir>
       <webroot>/usr/local/share/icecast/web</webroot>
       <adminroot>/usr/local/share/icecast/admin</adminroot>
        <!-- <pidfile>/usr/share/icecast/icecast.pid</pidfile> -->

        <!-- Aliases: treat requests for 'source' path as being for 'dest'
path
             May be made specific to a port or bound address using the
"port"
             and "bind-address" attributes.
          -->
        <!--
        <alias source="/foo" destination="/bar"/>
        -->
        <!-- Aliases: can also be used for simple redirections as well,
             this example will redirect all requests for http://server:port/
to
             the status page
        -->
        <alias source="/" destination="/status.xsl"/>
        <!-- The certificate file needs to contain both public and private
part.
             Both should be PEM encoded.
    -->
        <ssl-certificate>/var/log/icecast2/icecast.pem</ssl-certificate>
    </paths>

    <logging>
        <accesslog>access.log</accesslog>
        <errorlog>error.log</errorlog>
        <!-- <playlistlog>playlist.log</playlistlog> -->
        <loglevel>3</loglevel> <!-- 4 Debug, 3 Info, 2 Warn, 1 Error -->
        <logsize>10000</logsize> <!-- Max size of a logfile -->
        <!-- If logarchive is enabled (1), then when logsize is reached
             the logfile will be moved to
[error|access|playlist].log.DATESTAMP,
             otherwise it will be moved to [error|access|playlist].log.old.
             Default is non-archive mode (i.e. overwrite)
        -->
        <!-- <logarchive>1</logarchive> -->
    </logging>

    <security>
        <chroot>0</chroot>
        
        <changeowner>
            <user>icecast</user>
            <group>icecast</group>
        </changeowner>
        
    </security>
</icecast><?xml version="1.0" encoding="utf-8"?>






From lion at lion.leolix.org  Sun Feb 16 15:29:45 2020
From: lion at lion.leolix.org (Philipp Schafft)
Date: Sun, 16 Feb 2020 15:29:45 +0000
Subject: [Icecast] Possible CORS issue
In-Reply-To: <CAKCymP1VdOVm8H4WE3M1oeyU-0NfxGo6GKhGdbCzj4AHay43Aw@mail.gmail.com>
References: <CAKCymP0nJ+6KEVZr9BU5R-TJJKEQ21b84QcMGytCdE4ebjeAFQ@mail.gmail.com>
 <5D7077B9-0639-4A44-AA5C-D75CA311C7CF@gmail.com>
 <CAMhwV+7fm_5ecROdNwgpR7GaL_A8DDrdO0wGS7yEeO=1OyJojA@mail.gmail.com>
 <CAKCymP36FS+OcjuCGJpbPrOt1Sd3_GPWQnvNGQF4j50-bEE5=g@mail.gmail.com>
 <017B4BE8-3B8D-4402-B893-D13E0AEB56D0@gmail.com>
 <CAKCymP3VHpizDwaR1xzHsJ82fiGxGMcxPgxnhihKFJaXf4MwSQ@mail.gmail.com>
 <1581776497.2179.283.camel@lion.leolix.org>
 <CAKCymP1VdOVm8H4WE3M1oeyU-0NfxGo6GKhGdbCzj4AHay43Aw@mail.gmail.com>
Message-ID: <1581866985.2179.287.camel@lion.leolix.org>

Good afternoon,

On Sun, 2020-02-16 at 07:58 +0000, Chip wrote:
> On Sat, 15 Feb 2020 at 14:30, Philipp Schafft <lion at lion.leolix.org> wrote:
> > No, official Icecast does not support HEAD requests as they are largely
> > useless in Icecast context.
> >
> > HEAD requests are meant for cache validation. So they only apply to
> > static files basically. For Icecast, beside a few boring files in web/
> > the answer to "is my copy still valid" is always "no". So by not
> > supporting HEAD the client will retry with GET. Which... the client
> > would need to do anyway IF we would reply with a positive status code
> > for HEAD.
> >
> > Also (ab)using HEAD for monitoring is hardly useful:
> > The stress to the server is the same for answering a non-stub* response
> > to HEAD than to GET as in both cases the client must be attached to the
> > source. Even a stub response ("endpoint exists" or "not found") would
> > require most steps. It requires finding the endpoint, running its auth
> > and applying its ACLs. That is more than half way thru the attach
> > process.
> >
> > Hope that helps you. :)
> >
> > With best regards,
> >
> > * Non-stub results are hardly useful as HTTP is stateless anyway. The
> > standard acknowledges that by making all information about the actual
> > resource beside its existence optional.
> >
> 
>  Unfortunately, I don't yet understand most of that - but I will read and
> re-read.
> 
> However using Icecast 2.4.4, is there an alternative method for my client
> to access status-json.xsl so that they can access "now playing" data?

HEAD is not the right method for this anyway. To get the data you must
send a GET. HEAD will would never send the actual content of the
resource.


> My client is using this for an Alexa skill which can positively respond to
> questions such as "Alexa, what is now playing on Radio Blah-Blah?" - which
> sounds pretty cool to me. They could have worked around this by uploading
> "now playing" data via FTP but status-json.xsl had been working fine
> previously.
> 
> For the moment, I've implemented Icecast-KH and my client is happy but I'd
> like to explore the options using 'official Icecast'.

Maybe it would be possible that we arrange a test session on IRC? That
way could have a closer look at what is going on and why it doesn't
work. I really don't see what the problem could be from what you
describe here.


With best regards,


-- 
Philipp.
 (Rah of PH2)


From lion at lion.leolix.org  Sun Feb 16 20:15:29 2020
From: lion at lion.leolix.org (Philipp Schafft)
Date: Sun, 16 Feb 2020 20:15:29 +0000
Subject: [Icecast] Icecast SSL endpoint timeout issue
In-Reply-To: <003801d5e4af$7153e170$53fba450$@switchbladeuk.com>
References: <003801d5e4af$7153e170$53fba450$@switchbladeuk.com>
Message-ID: <1581884129.2179.297.camel@lion.leolix.org>


Good evening,

first of all thank you for the very good report. :)


On Sun, 2020-02-16 at 09:57 +0000, James Turner wrote:
> Hi team,
> 
> Please accent my apologies if this is NOT the place/distro list to be
> raising this. I had major dramas with the standard forum - registration and
> decided this may be a better route. 

This is the *perfect* place beside opening a ticket on gitlab. :)


> My current instance icecast server has been built with  --with-curl
> --with-openssl  options as outlined within this post:
> https://weekly-geekly.github.io/articles/350236/index.html and the build
> version is 2.4.99.2

I only had a quick look at that link. I think it is better than most but
it has some oddities. I would generally recommend to have a look at:
https://wiki.xiph.org/Icecast_Server/Installing_latest_version_(official_Xiph_repositories)

If you *really* want to build your own Icecast:
https://wiki.xiph.org/Icecast_Server/Git_workflow

However those two are "just" the install part, not the setup part.


> I'm using a valid certificate from letsencrypt on a Ubuntu 18 server hosted
> by AWS. Icecast recognizes this without issue.

I wouldn't recommend AWS with Icecast as several of my clients had
problems with their border gateways. However if it works for you that
sounds fine.


> I'm having issues disconnecting  my source client  from Icecast when the
> connections is via SSL. Non SSL source clients work as intended, connecting
> and disconnecting without issues and Icecast shuts down the mount points
> after client drop-outs as intended. See the logs outlined below for details.
> Using an SSL connection and once the client connection drops (for whatever
> reason) Icecast does not recognize this and keeps the mount point active
> forever - even when there's no data being sent by the client.  On a
> reconnect try  the client gets a 'mount point already in use' message. To
> get over this state I either have to restart the Icecast service OR manually
> kill the source from the admin interface. Once done. I can reconnect
> again.repeating the process
> 
> Frustratingly, this (SSL) works (source>icecast>listener) - just about -
> but I'd dearly like to understand the issue with the ssl connection and
> mountpoint not being released. I would expect a source timeout to occur, as
> defined in the Icecast config file thus releasing the mount point. However,
> not to be. 
> [...]

You are totally right here. In fact it's a bug we currently hunt. Had a
debugging session yesterday about it. We are currently considering what
the best route is to fix this.

What would help me is if you could provide your exact OpenSSL version:
$ openssl version
$ dpkg -l libssl-dev

Thank you very much. I expect that we fix this within the next week.

With best regards,

-- 
Philipp.
 (Rah of PH2)


From james at switchbladeuk.com  Mon Feb 17 10:59:39 2020
From: james at switchbladeuk.com (James Turner)
Date: Mon, 17 Feb 2020 10:59:39 -0000
Subject: [Icecast] Icecast SSL endpoint timeout issue
In-Reply-To: <1581884129.2179.297.camel@lion.leolix.org>
References: <003801d5e4af$7153e170$53fba450$@switchbladeuk.com>
 <1581884129.2179.297.camel@lion.leolix.org>
Message-ID: <000201d5e581$599645a0$0cc2d0e0$@switchbladeuk.com>

Hi Philipp,

Thank you for the prompt reply - really appreciated. 

Here is the output from the commands you requested:


$ openssl version

	OpenSSL 1.1.1  11 Sep 2018


$ dpkg -l libssl-dev

	Desired=Unknown/Install/Remove/Purge/Hold
	| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
	|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
	||/ Name           Version      Architecture Description
	+++-==============-============-============-=================================
	ii  libssl-dev:amd 1.1.1-1ubunt amd64        Secure Sockets Layer toolkit - de


If I can help you folks any further in this hunt please say. 

Kind regards,

James

-----Original Message-----
From: Icecast [mailto:icecast-bounces at xiph.org] On Behalf Of Philipp Schafft
Sent: 16 February 2020 20:15
To: Icecast streaming server user discussions <icecast at xiph.org>
Subject: Re: [Icecast] Icecast SSL endpoint timeout issue


Good evening,

first of all thank you for the very good report. :)


On Sun, 2020-02-16 at 09:57 +0000, James Turner wrote:
> Hi team,
> 
> Please accent my apologies if this is NOT the place/distro list to be 
> raising this. I had major dramas with the standard forum - 
> registration and decided this may be a better route.

This is the *perfect* place beside opening a ticket on gitlab. :)


> My current instance icecast server has been built with  --with-curl 
> --with-openssl  options as outlined within this post:
> https://weekly-geekly.github.io/articles/350236/index.html and the 
> build version is 2.4.99.2

I only had a quick look at that link. I think it is better than most but it has some oddities. I would generally recommend to have a look at:
https://wiki.xiph.org/Icecast_Server/Installing_latest_version_(official_Xiph_repositories)

If you *really* want to build your own Icecast:
https://wiki.xiph.org/Icecast_Server/Git_workflow

However those two are "just" the install part, not the setup part.


> I'm using a valid certificate from letsencrypt on a Ubuntu 18 server 
> hosted by AWS. Icecast recognizes this without issue.

I wouldn't recommend AWS with Icecast as several of my clients had problems with their border gateways. However if it works for you that sounds fine.


> I'm having issues disconnecting  my source client  from Icecast when 
> the connections is via SSL. Non SSL source clients work as intended, 
> connecting and disconnecting without issues and Icecast shuts down the 
> mount points after client drop-outs as intended. See the logs outlined below for details.
> Using an SSL connection and once the client connection drops (for 
> whatever
> reason) Icecast does not recognize this and keeps the mount point 
> active forever - even when there's no data being sent by the client.  
> On a reconnect try  the client gets a 'mount point already in use' 
> message. To get over this state I either have to restart the Icecast 
> service OR manually kill the source from the admin interface. Once 
> done. I can reconnect again.repeating the process
> 
> Frustratingly, this (SSL) works (source>icecast>listener) - just about 
> - but I'd dearly like to understand the issue with the ssl connection 
> and mountpoint not being released. I would expect a source timeout to 
> occur, as defined in the Icecast config file thus releasing the mount 
> point. However, not to be.
> [...]

You are totally right here. In fact it's a bug we currently hunt. Had a debugging session yesterday about it. We are currently considering what the best route is to fix this.

What would help me is if you could provide your exact OpenSSL version:
$ openssl version
$ dpkg -l libssl-dev

Thank you very much. I expect that we fix this within the next week.

With best regards,

--
Philipp.
 (Rah of PH2)
_______________________________________________
Icecast mailing list
Icecast at xiph.org
http://lists.xiph.org/mailman/listinfo/icecast



From db76 at riseup.net  Sat Feb 22 14:17:00 2020
From: db76 at riseup.net (Damian)
Date: Sun, 23 Feb 2020 00:17:00 +1000
Subject: [Icecast] Cannot update xiph repository
Message-ID: <0A07F799-346C-44BD-A338-1CBCB61611D4@riseup.net>

Hi,

I apologise for the naiveness of this question, but I experienced an error when running apt-get update on Debian 9.
It?s telling me that it can?t update the xiph repository.

Not sure if I should be asking for help about this here, but if not? please let me know where I should take this issue.
Any help is appreciated.

Damian



Get:1 http://security.debian.org/debian-security stretch/updates InRelease [94.3 kB]                                                                                         
Ign:2 http://ftp.us.debian.org/debian stretch InRelease                                                                                                                      
Hit:3 http://ftp.us.debian.org/debian stretch-updates InRelease                                                                                                              
Hit:4 http://ftp.us.debian.org/debian stretch Release                                                                                        
Hit:6 http://www.deb-multimedia.org stretch InRelease                                          
Get:5 http://download.opensuse.org/repositories/multimedia:/xiph/Debian_9.0 ./ InRelease [1,526 B]
Err:5 http://download.opensuse.org/repositories/multimedia:/xiph/Debian_9.0 ./ InRelease
  The following signatures were invalid: EXPKEYSIG 77EC2301F23C6AA3 multimedia OBS Project <multimedia at build.opensuse.org>
Reading package lists... Done
W: GPG error: http://download.opensuse.org/repositories/multimedia:/xiph/Debian_9.0 ./ InRelease: The following signatures were invalid: EXPKEYSIG 77EC2301F23C6AA3 multimedia OBS Project <multimedia at build.opensuse.org>
E: The repository 'http://download.opensuse.org/repositories/multimedia:/xiph/Debian_9.0 ./ InRelease' is no longer signed.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20200223/e1c23cb1/attachment.htm>

From chiapas at aktivix.org  Sun Feb 23 13:16:55 2020
From: chiapas at aktivix.org (Chip)
Date: Sun, 23 Feb 2020 13:16:55 +0000
Subject: [Icecast] Cannot update xiph repository
In-Reply-To: <0A07F799-346C-44BD-A338-1CBCB61611D4@riseup.net>
References: <0A07F799-346C-44BD-A338-1CBCB61611D4@riseup.net>
Message-ID: <CAKCymP3NOFk9q7xPBeK41=aHTL6s9TmrzFFcOaxovP5bz_Bp3g@mail.gmail.com>

On Sat, 22 Feb 2020 at 14:17, Damian <db76 at riseup.net> wrote:

> Hi,
>
> I apologise for the naiveness of this question, but I experienced an error
> when running apt-get update on Debian 9.
> It?s telling me that it can?t update the xiph repository.
>
> Not sure if I should be asking for help about this here, but if not?
> please let me know where I should take this issue.
> Any help is appreciated.
>
> Damian
>
>
>
> Get:1 http://security.debian.org/debian-security stretch/updates
> InRelease [94.3 kB]
>
> Ign:2 http://ftp.us.debian.org/debian stretch InRelease
>
>
> Hit:3 http://ftp.us.debian.org/debian stretch-updates InRelease
>
>
> Hit:4 http://ftp.us.debian.org/debian stretch Release
>
> Hit:6 http://www.deb-multimedia.org stretch InRelease
>
> Get:5
> http://download.opensuse.org/repositories/multimedia:/xiph/Debian_9.0 ./
> InRelease [1,526 B]
> Err:5
> http://download.opensuse.org/repositories/multimedia:/xiph/Debian_9.0 ./
> InRelease
>   The following signatures were invalid: EXPKEYSIG 77EC2301F23C6AA3
> multimedia OBS Project <multimedia at build.opensuse.org>
> Reading package lists... Done
> W: GPG error:
> http://download.opensuse.org/repositories/multimedia:/xiph/Debian_9.0 ./
> InRelease: The following signatures were invalid: EXPKEYSIG
> 77EC2301F23C6AA3 multimedia OBS Project <multimedia at build.opensuse.org>
> E: The repository 'http://download.opensuse.org/repositories/multimedia:/xiph/Debian_9.0
> ./ InRelease' is no longer signed.
> N: Updating from such a repository can't be done securely, and is
> therefore disabled by default.
> N: See apt-secure(8) manpage for repository creation and user
> configuration details.
>

What have you searched for?

What have you tried so far?

Searching around, I found this - which might help

   -
   https://askubuntu.com/questions/650032/gpg-errorthe-following-signatures-were-invalid-keyexpired
   -
   https://chrisjean.com/fix-apt-get-update-the-following-signatures-couldnt-be-verified-because-the-public-key-is-not-available/

Chip
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20200223/c5728438/attachment.htm>

From thomas.zumbrunnen at gmail.com  Sun Feb 23 13:34:51 2020
From: thomas.zumbrunnen at gmail.com (Thomas Zumbrunnen)
Date: Sun, 23 Feb 2020 14:34:51 +0100
Subject: [Icecast] Cannot update xiph repository
In-Reply-To: <0A07F799-346C-44BD-A338-1CBCB61611D4@riseup.net>
References: <0A07F799-346C-44BD-A338-1CBCB61611D4@riseup.net>
Message-ID: <008001d5ea4e$06abaac0$14030040$@gmail.com>

Hi Damian

 

The main reason for this issue is the expired Multimedia signing key expired for openSUSE OBS Multimedia ? aka xiph repository. The documentation has not been updated as mentioned in Step 2 : https://wiki.xiph.org/index.php?title=Icecast_Server/Installing_latest_version_(official_Xiph_repositories) <https://wiki.xiph.org/index.php?title=Icecast_Server/Installing_latest_version_(official_Xiph_repositories)&mobileaction=toggle_view_desktop> &mobileaction=toggle_view_desktop (btw. The let?s encrypt Cert on wiki.xiph.org expired as well February 18th 2020 ? just ignore the message in your browser). There is already a new key available  as mentioned  in https://gitlab.xiph.org/xiph/icecast-server/issues/2381

 

 

The workaround to solve your issue :

1.	Open a shell and become root
2.	wget -qO - https://download.opensuse.org/repositories/multimedia:/xiph/CentOS_8/repodata/repomd.xml.key | sudo apt-key add - 



If you dont use sudo, remove this command.

 

After adding the new signing key, you should be able to install Icecast2 from the xiph repository.

 

Regards

Thomas

 

Von: Icecast <icecast-bounces at xiph.org> Im Auftrag von Damian
Gesendet: Samstag, 22. Februar 2020 15:17
An: icecast at xiph.org
Betreff: [Icecast] Cannot update xiph repository

 

Hi,





I apologise for the naiveness of this question, but I experienced an error when running apt-get update on Debian 9.

It?s telling me that it can?t update the xiph repository.





Not sure if I should be asking for help about this here, but if not? please let me know where I should take this issue.

Any help is appreciated.





Damian













Get:1 http://security.debian.org/debian-security stretch/updates InRelease [94.3 kB]                                                                                          

Ign:2 http://ftp.us.debian.org/debian stretch InRelease                                                                                                                       

Hit:3 http://ftp.us.debian.org/debian stretch-updates InRelease                                                                                                               

Hit:4 http://ftp.us.debian.org/debian stretch Release                                                                                        

Hit:6 http://www.deb-multimedia.org stretch InRelease                                          

Get:5 http://download.opensuse.org/repositories/multimedia:/xiph/Debian_9.0 ./ InRelease [1,526 B]

Err:5 http://download.opensuse.org/repositories/multimedia:/xiph/Debian_9.0 ./ InRelease

  The following signatures were invalid: EXPKEYSIG 77EC2301F23C6AA3 multimedia OBS Project <multimedia at build.opensuse.org <mailto:multimedia at build.opensuse.org> >

Reading package lists... Done

W: GPG error: http://download.opensuse.org/repositories/multimedia:/xiph/Debian_9.0 ./ InRelease: The following signatures were invalid: EXPKEYSIG 77EC2301F23C6AA3 multimedia OBS Project <multimedia at build.opensuse.org <mailto:multimedia at build.opensuse.org> >

E: The repository 'http://download.opensuse.org/repositories/multimedia:/xiph/Debian_9.0 ./ InRelease <http://download.opensuse.org/repositories/multimedia:/xiph/Debian_9.0%20./%20InRelease> ' is no longer signed.

N: Updating from such a repository can't be done securely, and is therefore disabled by default.

N: See apt-secure(8) manpage for repository creation and user configuration details.





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20200223/e2b5f70f/attachment.htm>

From epirat07 at gmail.com  Sun Feb 23 15:23:22 2020
From: epirat07 at gmail.com (Marvin Scholz)
Date: Sun, 23 Feb 2020 16:23:22 +0100
Subject: [Icecast] Cannot update xiph repository
In-Reply-To: <008001d5ea4e$06abaac0$14030040$@gmail.com>
References: <0A07F799-346C-44BD-A338-1CBCB61611D4@riseup.net>
 <008001d5ea4e$06abaac0$14030040$@gmail.com>
Message-ID: <FC7690C3-921B-4D8F-BE43-E283C74D6170@gmail.com>

Hello,

On 23 Feb 2020, at 14:34, Thomas Zumbrunnen wrote:

> Hi Damian
>
> The main reason for this issue is the expired Multimedia signing key 
> expired for openSUSE OBS Multimedia ? aka xiph repository. The 
> documentation has not been updated as mentioned in Step 2 : 
> https://wiki.xiph.org/index.php?title=Icecast_Server/Installing_latest_version_(official_Xiph_repositories) 
> <https://wiki.xiph.org/index.php?title=Icecast_Server/Installing_latest_version_(official_Xiph_repositories)&mobileaction=toggle_view_desktop> 
> &mobileaction=toggle_view_desktop (btw. The let?s encrypt Cert on 
> wiki.xiph.org expired as well February 18th 2020 ? just ignore the 
> message in your browser).

I?ve updated the certificate, it should work fine now again.

> There is already a new key available  as mentioned in 
> https://gitlab.xiph.org/xiph/icecast-server/issues/2381

Sorry for this, I forgot to update the key on the website, it should be 
up to date now!

>
> [...]
>


From db76 at riseup.net  Sun Feb 23 22:34:35 2020
From: db76 at riseup.net (Damian)
Date: Mon, 24 Feb 2020 08:34:35 +1000
Subject: [Icecast] Cannot update xiph repository
Message-ID: <4A90E007-749F-41D7-B00C-38B7ADB7D73F@riseup.net>

?Thanks Marvin and Thomas,

After Marvin updated the key, I tried again (without having to use Thomas? suggested workaround). All is working properly again. 

Thanks for the help guys ?

Regards
Damian 

> On 24 Feb 2020, at 01:23, Marvin Scholz <epirat07 at gmail.com> wrote:
> 
> ?Hello,
> 
>>> On 23 Feb 2020, at 14:34, Thomas Zumbrunnen wrote:
>> Hi Damian
>> The main reason for this issue is the expired Multimedia signing key expired for openSUSE OBS Multimedia ? aka xiph repository. The documentation has not been updated as mentioned in Step 2 : https://wiki.xiph.org/index.php?title=Icecast_Server/Installing_latest_version_(official_Xiph_repositories) <https://wiki.xiph.org/index.php?title=Icecast_Server/Installing_latest_version_(official_Xiph_repositories)&mobileaction=toggle_view_desktop> &mobileaction=toggle_view_desktop (btw. The let?s encrypt Cert on wiki.xiph.org expired as well February 18th 2020 ? just ignore the message in your browser).
> 
> I?ve updated the certificate, it should work fine now again.
> 
>> There is already a new key available  as mentioned in https://gitlab.xiph.org/xiph/icecast-server/issues/2381
> 
> Sorry for this, I forgot to update the key on the website, it should be up to date now!
> 
>> [...]
> _______________________________________________
> Icecast mailing list
> Icecast at xiph.org
> http://lists.xiph.org/mailman/listinfo/icecast



From alexandru.ort at gmail.com  Sat Feb 29 13:25:13 2020
From: alexandru.ort at gmail.com (Alexandru Matei)
Date: Sat, 29 Feb 2020 15:25:13 +0200
Subject: [Icecast] Chrome not allowing mixed content anymore
Message-ID: <CACg6BWLz7FE4Vc9rCnqZDARsLFfY002hbOmUGac=RACxqpnPRg@mail.gmail.com>

Hi.

With its 80th version, Chrome stopped serving non-secure resources on https
pages. This affected the icecast server I run also. I enabled SSL, the
issue with Chrome not playing audio got fixed, but I noticed a major drop
in the number of listeners. As far as I figured out, the listeners that
have the http url in a playlist - listening in winamp, vlc etc. - could
listen no more. Those using internet radio devices were affected also.

Does icecast support streaming both http and https on the same port?
Is there such a feature in the version 4.5beta2?
Is there a release date planned for the new version of icecast?

This will affect many listeners and the administrators of those radios
servers. What would you do?

Thank you.

Alex G.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20200229/25e3367d/attachment.htm>

From mikel at 20comunicacion.com  Sat Feb 29 13:57:26 2020
From: mikel at 20comunicacion.com (=?UTF-8?Q?Mikel_Sanz_=7C_20_Comunicaci=C3=B3n?=)
Date: Sat, 29 Feb 2020 14:57:26 +0100
Subject: [Icecast] Chrome not allowing mixed content anymore
In-Reply-To: <CACg6BWLz7FE4Vc9rCnqZDARsLFfY002hbOmUGac=RACxqpnPRg@mail.gmail.com>
References: <CACg6BWLz7FE4Vc9rCnqZDARsLFfY002hbOmUGac=RACxqpnPRg@mail.gmail.com>
Message-ID: <CAOx_OQ8t6rfdfX0ng_6OSuGhnQEvPnJVrmkW-whLh-X2d-PLJA@mail.gmail.com>

Yes, I also think that 6 years of Beta is too much and now it's too late...

El s?b., 29 feb. 2020 14:25, Alexandru Matei <alexandru.ort at gmail.com>
escribi?:

> Hi.
>
> With its 80th version, Chrome stopped serving non-secure resources on
> https pages. This affected the icecast server I run also. I enabled SSL,
> the issue with Chrome not playing audio got fixed, but I noticed a major
> drop in the number of listeners. As far as I figured out, the listeners
> that have the http url in a playlist - listening in winamp, vlc etc. -
> could listen no more. Those using internet radio devices were affected also.
>
> Does icecast support streaming both http and https on the same port?
> Is there such a feature in the version 4.5beta2?
> Is there a release date planned for the new version of icecast?
>
> This will affect many listeners and the administrators of those radios
> servers. What would you do?
>
> Thank you.
>
> Alex G.
> _______________________________________________
> Icecast mailing list
> Icecast at xiph.org
> http://lists.xiph.org/mailman/listinfo/icecast
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20200229/c1c4328f/attachment.htm>

From yahav.shasha at gmail.com  Sat Feb 29 15:11:30 2020
From: yahav.shasha at gmail.com (Yahav Shasha)
Date: Sat, 29 Feb 2020 17:11:30 +0200
Subject: [Icecast] Chrome not allowing mixed content anymore
In-Reply-To: <CAOx_OQ8t6rfdfX0ng_6OSuGhnQEvPnJVrmkW-whLh-X2d-PLJA@mail.gmail.com>
References: <CACg6BWLz7FE4Vc9rCnqZDARsLFfY002hbOmUGac=RACxqpnPRg@mail.gmail.com>
 <CAOx_OQ8t6rfdfX0ng_6OSuGhnQEvPnJVrmkW-whLh-X2d-PLJA@mail.gmail.com>
Message-ID: <CABuab=RZmwRoCaKn5gCa6CVJbCZMeMC-g_ndJcHsMpqRpRWUWA@mail.gmail.com>

This is a real problem that needs to be addressed.
Anyone has figured a way to mitigate this?

On Sat, Feb 29, 2020 at 4:29 PM Mikel Sanz | 20 Comunicaci?n <
mikel at 20comunicacion.com> wrote:

> Yes, I also think that 6 years of Beta is too much and now it's too late...
>
> El s?b., 29 feb. 2020 14:25, Alexandru Matei <alexandru.ort at gmail.com>
> escribi?:
>
>> Hi.
>>
>> With its 80th version, Chrome stopped serving non-secure resources on
>> https pages. This affected the icecast server I run also. I enabled SSL,
>> the issue with Chrome not playing audio got fixed, but I noticed a major
>> drop in the number of listeners. As far as I figured out, the listeners
>> that have the http url in a playlist - listening in winamp, vlc etc. -
>> could listen no more. Those using internet radio devices were affected also.
>>
>> Does icecast support streaming both http and https on the same port?
>> Is there such a feature in the version 4.5beta2?
>> Is there a release date planned for the new version of icecast?
>>
>> This will affect many listeners and the administrators of those radios
>> servers. What would you do?
>>
>> Thank you.
>>
>> Alex G.
>> _______________________________________________
>> Icecast mailing list
>> Icecast at xiph.org
>> http://lists.xiph.org/mailman/listinfo/icecast
>>
> _______________________________________________
> Icecast mailing list
> Icecast at xiph.org
> http://lists.xiph.org/mailman/listinfo/icecast
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20200229/19061427/attachment.htm>

From albert.santoni at oscillicious.com  Sat Feb 29 15:30:40 2020
From: albert.santoni at oscillicious.com (Albert Santoni)
Date: Sat, 29 Feb 2020 10:30:40 -0500
Subject: [Icecast] Chrome not allowing mixed content anymore
In-Reply-To: <CABuab=RZmwRoCaKn5gCa6CVJbCZMeMC-g_ndJcHsMpqRpRWUWA@mail.gmail.com>
References: <CACg6BWLz7FE4Vc9rCnqZDARsLFfY002hbOmUGac=RACxqpnPRg@mail.gmail.com>
 <CAOx_OQ8t6rfdfX0ng_6OSuGhnQEvPnJVrmkW-whLh-X2d-PLJA@mail.gmail.com>
 <CABuab=RZmwRoCaKn5gCa6CVJbCZMeMC-g_ndJcHsMpqRpRWUWA@mail.gmail.com>
Message-ID: <CAEbLzA9WoR+X1WK=z5WrYW6TykpnSMtfmnLpSkGxUYy_ig_OHQ@mail.gmail.com>

Hi all,

Can you explain the use case here a bit more? I think I'm missing something
in my understanding.

If you enable TLS/HTTPS, you should enable it on a different port (eg. 443)
and keep your existing HTTP port for Icecast so that your stations will
continue to work in external players (Winamp, playlists, VLC, etc.).
However, you should update all embedded links to your stream on your
website(s) and point them to the new HTTPS port.

Is the problem that your streams are embedded on many websites outside of
your control?

Thanks,
Albert




On Sat, Feb 29, 2020 at 10:11 AM Yahav Shasha <yahav.shasha at gmail.com>
wrote:

> This is a real problem that needs to be addressed.
> Anyone has figured a way to mitigate this?
>
> On Sat, Feb 29, 2020 at 4:29 PM Mikel Sanz | 20 Comunicaci?n <
> mikel at 20comunicacion.com> wrote:
>
>> Yes, I also think that 6 years of Beta is too much and now it's too
>> late...
>>
>> El s?b., 29 feb. 2020 14:25, Alexandru Matei <alexandru.ort at gmail.com>
>> escribi?:
>>
>>> Hi.
>>>
>>> With its 80th version, Chrome stopped serving non-secure resources on
>>> https pages. This affected the icecast server I run also. I enabled SSL,
>>> the issue with Chrome not playing audio got fixed, but I noticed a major
>>> drop in the number of listeners. As far as I figured out, the listeners
>>> that have the http url in a playlist - listening in winamp, vlc etc. -
>>> could listen no more. Those using internet radio devices were affected also.
>>>
>>> Does icecast support streaming both http and https on the same port?
>>> Is there such a feature in the version 4.5beta2?
>>> Is there a release date planned for the new version of icecast?
>>>
>>> This will affect many listeners and the administrators of those radios
>>> servers. What would you do?
>>>
>>> Thank you.
>>>
>>> Alex G.
>>> _______________________________________________
>>> Icecast mailing list
>>> Icecast at xiph.org
>>> http://lists.xiph.org/mailman/listinfo/icecast
>>>
>> _______________________________________________
>> Icecast mailing list
>> Icecast at xiph.org
>> http://lists.xiph.org/mailman/listinfo/icecast
>>
>
> _______________________________________________
> Icecast mailing list
> Icecast at xiph.org
> http://lists.xiph.org/mailman/listinfo/icecast
>


-- 
Albert Santoni
Founder, Lead Developer | Oscillicious
Delicious Audio Tools and Plug-ins
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20200229/e77d4374/attachment.htm>

From mikel at 20comunicacion.com  Sat Feb 29 16:06:00 2020
From: mikel at 20comunicacion.com (=?UTF-8?Q?Mikel_Sanz_=7C_20_Comunicaci=C3=B3n?=)
Date: Sat, 29 Feb 2020 17:06:00 +0100
Subject: [Icecast] Chrome not allowing mixed content anymore
In-Reply-To: <CAEbLzA9WoR+X1WK=z5WrYW6TykpnSMtfmnLpSkGxUYy_ig_OHQ@mail.gmail.com>
References: <CACg6BWLz7FE4Vc9rCnqZDARsLFfY002hbOmUGac=RACxqpnPRg@mail.gmail.com>
 <CAOx_OQ8t6rfdfX0ng_6OSuGhnQEvPnJVrmkW-whLh-X2d-PLJA@mail.gmail.com>
 <CABuab=RZmwRoCaKn5gCa6CVJbCZMeMC-g_ndJcHsMpqRpRWUWA@mail.gmail.com>
 <CAEbLzA9WoR+X1WK=z5WrYW6TykpnSMtfmnLpSkGxUYy_ig_OHQ@mail.gmail.com>
Message-ID: <CAOx_OQ90BXVqoK-qWRgooKuSEqKKUcXfCovtY7wRXM92zhodOA@mail.gmail.com>

For example, in my case, we use several servers with Centovacast, with
several Icecast2 services. Version 2.5 of Icecast2, allows to respond to
http and https connections from the same port, but takes years in beta.
Centovacast does not update its panel, waiting for the final version of
Icecast 2.5 to be released.

Chrome has been warning for months that this would happen in February, but
no one has advanced anything to fix this.

Therefore, we have to enable manually service by service a new secondary
port that responds via https, and contact client by client to update their
Websites, when everyone could be massively enabled by the same port if the
new version of Icecast was already available.

Why is this improvement not already implemented in Icecast2? In Icecast KH
it has been available for months...


El s?b., 29 feb. 2020 a las 16:31, Albert Santoni (<
albert.santoni at oscillicious.com>) escribi?:

> Hi all,
>
> Can you explain the use case here a bit more? I think I'm missing
> something in my understanding.
>
> If you enable TLS/HTTPS, you should enable it on a different port (eg.
> 443) and keep your existing HTTP port for Icecast so that your stations
> will continue to work in external players (Winamp, playlists, VLC, etc.).
> However, you should update all embedded links to your stream on your
> website(s) and point them to the new HTTPS port.
>
> Is the problem that your streams are embedded on many websites outside of
> your control?
>
> Thanks,
> Albert
>
>
>
>
> On Sat, Feb 29, 2020 at 10:11 AM Yahav Shasha <yahav.shasha at gmail.com>
> wrote:
>
>> This is a real problem that needs to be addressed.
>> Anyone has figured a way to mitigate this?
>>
>> On Sat, Feb 29, 2020 at 4:29 PM Mikel Sanz | 20 Comunicaci?n <
>> mikel at 20comunicacion.com> wrote:
>>
>>> Yes, I also think that 6 years of Beta is too much and now it's too
>>> late...
>>>
>>> El s?b., 29 feb. 2020 14:25, Alexandru Matei <alexandru.ort at gmail.com>
>>> escribi?:
>>>
>>>> Hi.
>>>>
>>>> With its 80th version, Chrome stopped serving non-secure resources on
>>>> https pages. This affected the icecast server I run also. I enabled SSL,
>>>> the issue with Chrome not playing audio got fixed, but I noticed a major
>>>> drop in the number of listeners. As far as I figured out, the listeners
>>>> that have the http url in a playlist - listening in winamp, vlc etc. -
>>>> could listen no more. Those using internet radio devices were affected also.
>>>>
>>>> Does icecast support streaming both http and https on the same port?
>>>> Is there such a feature in the version 4.5beta2?
>>>> Is there a release date planned for the new version of icecast?
>>>>
>>>> This will affect many listeners and the administrators of those radios
>>>> servers. What would you do?
>>>>
>>>> Thank you.
>>>>
>>>> Alex G.
>>>> _______________________________________________
>>>> Icecast mailing list
>>>> Icecast at xiph.org
>>>> http://lists.xiph.org/mailman/listinfo/icecast
>>>>
>>> _______________________________________________
>>> Icecast mailing list
>>> Icecast at xiph.org
>>> http://lists.xiph.org/mailman/listinfo/icecast
>>>
>>
>> _______________________________________________
>> Icecast mailing list
>> Icecast at xiph.org
>> http://lists.xiph.org/mailman/listinfo/icecast
>>
>
>
> --
> Albert Santoni
> Founder, Lead Developer | Oscillicious
> Delicious Audio Tools and Plug-ins
> _______________________________________________
> Icecast mailing list
> Icecast at xiph.org
> http://lists.xiph.org/mailman/listinfo/icecast
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20200229/eb6c9f1b/attachment.htm>

From yahav.shasha at gmail.com  Sat Feb 29 16:20:23 2020
From: yahav.shasha at gmail.com (Yahav Shasha)
Date: Sat, 29 Feb 2020 18:20:23 +0200
Subject: [Icecast] Chrome not allowing mixed content anymore
In-Reply-To: <CAOx_OQ90BXVqoK-qWRgooKuSEqKKUcXfCovtY7wRXM92zhodOA@mail.gmail.com>
References: <CACg6BWLz7FE4Vc9rCnqZDARsLFfY002hbOmUGac=RACxqpnPRg@mail.gmail.com>
 <CAOx_OQ8t6rfdfX0ng_6OSuGhnQEvPnJVrmkW-whLh-X2d-PLJA@mail.gmail.com>
 <CABuab=RZmwRoCaKn5gCa6CVJbCZMeMC-g_ndJcHsMpqRpRWUWA@mail.gmail.com>
 <CAEbLzA9WoR+X1WK=z5WrYW6TykpnSMtfmnLpSkGxUYy_ig_OHQ@mail.gmail.com>
 <CAOx_OQ90BXVqoK-qWRgooKuSEqKKUcXfCovtY7wRXM92zhodOA@mail.gmail.com>
Message-ID: <CABuab=Q0RiYQ5GFyEK+MBeqisiayuU4BND2JcPPNEKo8Ps--ZQ@mail.gmail.com>

@Mikel
You could use Centova's port 80 proxy meanwhile couldn't you?
Also. Centova Cast doesn't have an SSL setting for the servers unless
you're manually overwriting the server config files.. or is it?


On Sat, Feb 29, 2020 at 6:13 PM Mikel Sanz | 20 Comunicaci?n <
mikel at 20comunicacion.com> wrote:

> For example, in my case, we use several servers with Centovacast, with
> several Icecast2 services. Version 2.5 of Icecast2, allows to respond to
> http and https connections from the same port, but takes years in beta.
> Centovacast does not update its panel, waiting for the final version of
> Icecast 2.5 to be released.
>
> Chrome has been warning for months that this would happen in February, but
> no one has advanced anything to fix this.
>
> Therefore, we have to enable manually service by service a new secondary
> port that responds via https, and contact client by client to update their
> Websites, when everyone could be massively enabled by the same port if the
> new version of Icecast was already available.
>
> Why is this improvement not already implemented in Icecast2? In Icecast KH
> it has been available for months...
>
>
> El s?b., 29 feb. 2020 a las 16:31, Albert Santoni (<
> albert.santoni at oscillicious.com>) escribi?:
>
>> Hi all,
>>
>> Can you explain the use case here a bit more? I think I'm missing
>> something in my understanding.
>>
>> If you enable TLS/HTTPS, you should enable it on a different port (eg.
>> 443) and keep your existing HTTP port for Icecast so that your stations
>> will continue to work in external players (Winamp, playlists, VLC, etc.).
>> However, you should update all embedded links to your stream on your
>> website(s) and point them to the new HTTPS port.
>>
>> Is the problem that your streams are embedded on many websites outside of
>> your control?
>>
>> Thanks,
>> Albert
>>
>>
>>
>>
>> On Sat, Feb 29, 2020 at 10:11 AM Yahav Shasha <yahav.shasha at gmail.com>
>> wrote:
>>
>>> This is a real problem that needs to be addressed.
>>> Anyone has figured a way to mitigate this?
>>>
>>> On Sat, Feb 29, 2020 at 4:29 PM Mikel Sanz | 20 Comunicaci?n <
>>> mikel at 20comunicacion.com> wrote:
>>>
>>>> Yes, I also think that 6 years of Beta is too much and now it's too
>>>> late...
>>>>
>>>> El s?b., 29 feb. 2020 14:25, Alexandru Matei <alexandru.ort at gmail.com>
>>>> escribi?:
>>>>
>>>>> Hi.
>>>>>
>>>>> With its 80th version, Chrome stopped serving non-secure resources on
>>>>> https pages. This affected the icecast server I run also. I enabled SSL,
>>>>> the issue with Chrome not playing audio got fixed, but I noticed a major
>>>>> drop in the number of listeners. As far as I figured out, the listeners
>>>>> that have the http url in a playlist - listening in winamp, vlc etc. -
>>>>> could listen no more. Those using internet radio devices were affected also.
>>>>>
>>>>> Does icecast support streaming both http and https on the same port?
>>>>> Is there such a feature in the version 4.5beta2?
>>>>> Is there a release date planned for the new version of icecast?
>>>>>
>>>>> This will affect many listeners and the administrators of those radios
>>>>> servers. What would you do?
>>>>>
>>>>> Thank you.
>>>>>
>>>>> Alex G.
>>>>> _______________________________________________
>>>>> Icecast mailing list
>>>>> Icecast at xiph.org
>>>>> http://lists.xiph.org/mailman/listinfo/icecast
>>>>>
>>>> _______________________________________________
>>>> Icecast mailing list
>>>> Icecast at xiph.org
>>>> http://lists.xiph.org/mailman/listinfo/icecast
>>>>
>>>
>>> _______________________________________________
>>> Icecast mailing list
>>> Icecast at xiph.org
>>> http://lists.xiph.org/mailman/listinfo/icecast
>>>
>>
>>
>> --
>> Albert Santoni
>> Founder, Lead Developer | Oscillicious
>> Delicious Audio Tools and Plug-ins
>> _______________________________________________
>> Icecast mailing list
>> Icecast at xiph.org
>> http://lists.xiph.org/mailman/listinfo/icecast
>>
> _______________________________________________
> Icecast mailing list
> Icecast at xiph.org
> http://lists.xiph.org/mailman/listinfo/icecast
>


-- 
Yahav Shasha,
Web Developer
+972-(0)549214421
http://www.linkedin.com/in/yahavs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20200229/83398608/attachment.htm>

From mikel at 20comunicacion.com  Sat Feb 29 16:23:33 2020
From: mikel at 20comunicacion.com (=?UTF-8?Q?Mikel_Sanz_=7C_20_Comunicaci=C3=B3n?=)
Date: Sat, 29 Feb 2020 17:23:33 +0100
Subject: [Icecast] Chrome not allowing mixed content anymore
In-Reply-To: <CABuab=Q0RiYQ5GFyEK+MBeqisiayuU4BND2JcPPNEKo8Ps--ZQ@mail.gmail.com>
References: <CACg6BWLz7FE4Vc9rCnqZDARsLFfY002hbOmUGac=RACxqpnPRg@mail.gmail.com>
 <CAOx_OQ8t6rfdfX0ng_6OSuGhnQEvPnJVrmkW-whLh-X2d-PLJA@mail.gmail.com>
 <CABuab=RZmwRoCaKn5gCa6CVJbCZMeMC-g_ndJcHsMpqRpRWUWA@mail.gmail.com>
 <CAEbLzA9WoR+X1WK=z5WrYW6TykpnSMtfmnLpSkGxUYy_ig_OHQ@mail.gmail.com>
 <CAOx_OQ90BXVqoK-qWRgooKuSEqKKUcXfCovtY7wRXM92zhodOA@mail.gmail.com>
 <CABuab=Q0RiYQ5GFyEK+MBeqisiayuU4BND2JcPPNEKo8Ps--ZQ@mail.gmail.com>
Message-ID: <CAOx_OQ87TbALyYi_Tz73dBpGe3f0gM6ouGbN5MJ+MNC9991VEQ@mail.gmail.com>

Yes, but the proxy under port 80 consumes many resources. Besides, it makes
no sense to do it when Icecast2 supports it natively. All that remains is
for the final version 2.5 to be enabled to enable http and https through
the same port and only the certificate should be added to each account
(even if manually), only that would be needed ... Centovacast will update
the panel as soon as it is released the final version, but it all depends
on Icecast doing it ...


El s?b., 29 feb. 2020 a las 17:20, Yahav Shasha (<yahav.shasha at gmail.com>)
escribi?:

> @Mikel
> You could use Centova's port 80 proxy meanwhile couldn't you?
> Also. Centova Cast doesn't have an SSL setting for the servers unless
> you're manually overwriting the server config files.. or is it?
>
>
> On Sat, Feb 29, 2020 at 6:13 PM Mikel Sanz | 20 Comunicaci?n <
> mikel at 20comunicacion.com> wrote:
>
>> For example, in my case, we use several servers with Centovacast, with
>> several Icecast2 services. Version 2.5 of Icecast2, allows to respond to
>> http and https connections from the same port, but takes years in beta.
>> Centovacast does not update its panel, waiting for the final version of
>> Icecast 2.5 to be released.
>>
>> Chrome has been warning for months that this would happen in February,
>> but no one has advanced anything to fix this.
>>
>> Therefore, we have to enable manually service by service a new secondary
>> port that responds via https, and contact client by client to update their
>> Websites, when everyone could be massively enabled by the same port if the
>> new version of Icecast was already available.
>>
>> Why is this improvement not already implemented in Icecast2? In Icecast
>> KH it has been available for months...
>>
>>
>> El s?b., 29 feb. 2020 a las 16:31, Albert Santoni (<
>> albert.santoni at oscillicious.com>) escribi?:
>>
>>> Hi all,
>>>
>>> Can you explain the use case here a bit more? I think I'm missing
>>> something in my understanding.
>>>
>>> If you enable TLS/HTTPS, you should enable it on a different port (eg.
>>> 443) and keep your existing HTTP port for Icecast so that your stations
>>> will continue to work in external players (Winamp, playlists, VLC, etc.).
>>> However, you should update all embedded links to your stream on your
>>> website(s) and point them to the new HTTPS port.
>>>
>>> Is the problem that your streams are embedded on many websites outside
>>> of your control?
>>>
>>> Thanks,
>>> Albert
>>>
>>>
>>>
>>>
>>> On Sat, Feb 29, 2020 at 10:11 AM Yahav Shasha <yahav.shasha at gmail.com>
>>> wrote:
>>>
>>>> This is a real problem that needs to be addressed.
>>>> Anyone has figured a way to mitigate this?
>>>>
>>>> On Sat, Feb 29, 2020 at 4:29 PM Mikel Sanz | 20 Comunicaci?n <
>>>> mikel at 20comunicacion.com> wrote:
>>>>
>>>>> Yes, I also think that 6 years of Beta is too much and now it's too
>>>>> late...
>>>>>
>>>>> El s?b., 29 feb. 2020 14:25, Alexandru Matei <alexandru.ort at gmail.com>
>>>>> escribi?:
>>>>>
>>>>>> Hi.
>>>>>>
>>>>>> With its 80th version, Chrome stopped serving non-secure resources on
>>>>>> https pages. This affected the icecast server I run also. I enabled SSL,
>>>>>> the issue with Chrome not playing audio got fixed, but I noticed a major
>>>>>> drop in the number of listeners. As far as I figured out, the listeners
>>>>>> that have the http url in a playlist - listening in winamp, vlc etc. -
>>>>>> could listen no more. Those using internet radio devices were affected also.
>>>>>>
>>>>>> Does icecast support streaming both http and https on the same port?
>>>>>> Is there such a feature in the version 4.5beta2?
>>>>>> Is there a release date planned for the new version of icecast?
>>>>>>
>>>>>> This will affect many listeners and the administrators of those
>>>>>> radios servers. What would you do?
>>>>>>
>>>>>> Thank you.
>>>>>>
>>>>>> Alex G.
>>>>>> _______________________________________________
>>>>>> Icecast mailing list
>>>>>> Icecast at xiph.org
>>>>>> http://lists.xiph.org/mailman/listinfo/icecast
>>>>>>
>>>>> _______________________________________________
>>>>> Icecast mailing list
>>>>> Icecast at xiph.org
>>>>> http://lists.xiph.org/mailman/listinfo/icecast
>>>>>
>>>>
>>>> _______________________________________________
>>>> Icecast mailing list
>>>> Icecast at xiph.org
>>>> http://lists.xiph.org/mailman/listinfo/icecast
>>>>
>>>
>>>
>>> --
>>> Albert Santoni
>>> Founder, Lead Developer | Oscillicious
>>> Delicious Audio Tools and Plug-ins
>>> _______________________________________________
>>> Icecast mailing list
>>> Icecast at xiph.org
>>> http://lists.xiph.org/mailman/listinfo/icecast
>>>
>> _______________________________________________
>> Icecast mailing list
>> Icecast at xiph.org
>> http://lists.xiph.org/mailman/listinfo/icecast
>>
>
>
> --
> Yahav Shasha,
> Web Developer
> +972-(0)549214421
> http://www.linkedin.com/in/yahavs
> _______________________________________________
> Icecast mailing list
> Icecast at xiph.org
> http://lists.xiph.org/mailman/listinfo/icecast
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20200229/67b498f1/attachment.htm>