Icecast dev - Apr 2011 - source questions & intentions to patch: yp-timing & auth

Good Day,

Looking at the SVN repo: there's 30+ commits since the 2.6.2 release;
the last one from August 2009. Are there any intentions to roll a
release anytime soon? Are there any more recent branches?

I'm currently looking into extending icecast2 (more below) and am
wondering if I should base the patches on 2.6.2+debian-fixes or
work from svn-trunk?


We are using a cluster of icecast servers as decentralized
stream-servers for theartcollider.org project and rely on the
yellow-pages protocol to gather information about available streams/servers.

Basically I'm interested in
  (1) making YP timing configurable (more frequent updates <30sec)
  (2) adding a decentralized authentication mechanism: a user can use
  the same login for a set of mounts on all servers in the cluster

I've tackled (1) already and am pondering (2):

The current per-mounpoint auth requires a pre-defined mountpoint as well
as sharing the config-file among all servers. I do envisage an
authentication mechanism that can can be shared among a group of servers
and allows dynamic allocations of mountpoints/credentials.

It'd be very cool to use OAuth for that but it'd break compatibility
with too many source-clients.. so the current idea is to patch icecast2
to call an external service/executable in order to verify access (most
flexibile) and/or make icecast perform a HTTP request to an auth-server
that returns 200 or 403 (most portable).

Did anyone venture down this road before?

TIA,
robin

Hi Robin,

First, please let me state that I'm not xiph, nor an IceCast maintainer,
all I'm saying here are my views, but, as nobody answered your mail, I
guess it's better than nothing.

Robin Gareus <robin at gareus.org> writes:
> Looking at the SVN repo: there's 30+ commits since the 2.6.2 release;
> the last one from August 2009. Are there any intentions to roll a
> release anytime soon? Are there any more recent branches?
Basically, IceCast is vastly unmaintained, that said, kh[0] maintains
some code, that is supposed to be quite a bit more advanced.

[0] http://www.xiphicecast.webspace.virginmedia.com/
> I'm currently looking into extending icecast2 (more below) and am
> wondering if I should base the patches on 2.6.2+debian-fixes or
> work from svn-trunk?
 I based my patches (see mailing list history) on current SVN (and so
think you should too =D, maybe even on my un-applied patches ?). I've
kept working a bit on IceCast, and am thinking of putting up a git tree
somewhere soon (as soon as I can clean my current state).
> We are using a cluster of icecast servers as decentralized
> stream-servers for theartcollider.org project and rely on the
> yellow-pages protocol to gather information about available
> streams/servers.
nice, btw, neewbie question, is there an OpenSource generic, prefered
implementation of a yp server ? I googled a bit and didn't find anything
too obvious.
> Basically I'm interested in
>   (1) making YP timing configurable (more frequent updates <30sec)
>   (2) adding a decentralized authentication mechanism: a user can use
>   the same login for a set of mounts on all servers in the cluster
>
> I've tackled (1) already and am pondering (2):
Awesome, patches welcome =)
> The current per-mounpoint auth requires a pre-defined mountpoint as well
> as sharing the config-file among all servers. I do envisage an
> authentication mechanism that can can be shared among a group of servers
> and allows dynamic allocations of mountpoints/credentials.
Well, with master/slave mode you can actually get your config pushed to
all servers, doesn't that help you ?
> It'd be very cool to use OAuth for that but it'd break
compatibility
> with too many source-clients.. so the current idea is to patch icecast2
> to call an external service/executable in order to verify access (most
> flexibile) and/or make icecast perform a HTTP request to an auth-server
> that returns 200 or 403 (most portable).
That would be really cool to have, please share patches =)

But I think having it call an outside program is not really elegant nor
eficient.

Implementing new auth methods is quite easy, you can see here for basic
post with no auth (... have that pending in my todolist)

http://thread.gmane.org/gmane.comp.audio.icecast.devel/1692/focus=1705

Hope it helps,
Cheers,
--
Niv Sardi

Hi Niv,

On 04/19/2011 07:07 AM, Niv Sardi wrote:
> 
> Hi Robin,
> 
> First, please let me state that I'm not xiph, nor an IceCast
maintainer,
> all I'm saying here are my views, but, as nobody answered your mail, I
> guess it's better than nothing.
Thanks. Your answer is very much appreciated.
> Robin Gareus <robin at gareus.org> writes:
>> Looking at the SVN repo: there's 30+ commits since the 2.6.2
release;
>> the last one from August 2009. Are there any intentions to roll a
>> release anytime soon? Are there any more recent branches?
> 
> Basically, IceCast is vastly unmaintained, that said, kh[0] maintains
> some code, that is supposed to be quite a bit more advanced.
> 
> [0] http://www.xiphicecast.webspace.virginmedia.com/
thanks for the link; never crossed my mind to look on virginmedia.com :)
>> I'm currently looking into extending icecast2 (more below) and am
>> wondering if I should base the patches on 2.6.2+debian-fixes or
>> work from svn-trunk?
> 
>  I based my patches (see mailing list history) on current SVN (and so
> think you should too =D, maybe even on my un-applied patches ?).
How are your experiences regarding stability (mem-leaks, crackability)
with running svn-trunk?
> I've
> kept working a bit on IceCast, and am thinking of putting up a git tree
> somewhere soon (as soon as I can clean my current state).
BTW. 'git svn' is a bit tricky - because of the svn externals in
icecast2. I've used git://github.com/andrep/git-svn-clone-externals.git
and needed to fix the module/branch regexps in as well as symlink paths.
It's a bit OT. Let me know if you're interested and I'll elaborate.
OTOH
it looks like you already got that part working :)
>> We are using a cluster of icecast servers as decentralized
>> stream-servers for theartcollider.org project and rely on the
>> yellow-pages protocol to gather information about available
>> streams/servers.
> 
> nice, btw, neewbie question, is there an OpenSource generic, prefered
> implementation of a yp server ? I googled a bit and didn't find
anything
> too obvious.
Not that I know. But it's not complicated to write one; take a look at
http://git.citu.info/?p=tacyp.git;a=summary for inspiration.
>> Basically I'm interested in
>>   (1) making YP timing configurable (more frequent updates <30sec)
>>   (2) adding a decentralized authentication mechanism: a user can use
>>   the same login for a set of mounts on all servers in the cluster
>>
>> I've tackled (1) already and am pondering (2):
> 
> Awesome, patches welcome =)
> 
>> The current per-mounpoint auth requires a pre-defined mountpoint as
well
>> as sharing the config-file among all servers. I do envisage an
>> authentication mechanism that can can be shared among a group of
servers
>> and allows dynamic allocations of mountpoints/credentials.
> 
> Well, with master/slave mode you can actually get your config pushed to
> all servers, doesn't that help you ?
No, because I don't know the servers. It's decentralized network.

Each participant just installs his/her icecast server and points the
YP-URL to us. If said participant/artists is an individual, there's no
problem with password, but if it's an institution, they like to delegate
auth.
>> It'd be very cool to use OAuth for that but it'd break
compatibility
>> with too many source-clients.. so the current idea is to patch icecast2
>> to call an external service/executable in order to verify access (most
>> flexibile) and/or make icecast perform a HTTP request to an auth-server
>> that returns 200 or 403 (most portable).
> 
> That would be really cool to have, please share patches =)
> 
> But I think having it call an outside program is not really elegant nor
> efficient.
indeed, just pragmatic and easy for prototyping. Anyway:

icecast2 trunk actually implements auth_url.c which can query some
remote-server for authentication (added Jan 2009 rev.15621).

It requires a minor fix [1] if one only wishes to do source but not
listener authentication. I've also added 'catch-all' mountpoint
option
to delegate all authentication to a remote-server.
> http://thread.gmane.org/gmane.comp.audio.icecast.devel/1692/focus=1705
I'm taking about source auth, not listener auth. Here all streams are
public, in fact I've added a "candid" mode that automatically
publishes
streams :)

The patch for fine-grained YP-timing [2] applies (with a few hunks
offset) to both 2.6.2 and svn-trunk. - however the full patch [3] (incl
fixes for auth_url) is for SVN trunk only. Debian packages (called
icecast2-2.6.3-7~extended) can be found at [4].

Cheers!
robin


[1]
http://rg42.org/gitweb/?p=icecast2;a=commitdiff;h=99f4fd5e6ef902bf50d7d05ec56783219c9b5b1b

[2]
http://rg42.org/gitweb/?p=icecast2;a=commitdiff_plain;hp=master;h=yp-settings

[3] git clone -b tac git://rg42.org/icecast2

[4] http://rg42.org/deb/