Robin Gareus
2011-Apr-15 08:30 UTC
[Icecast-dev] 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
Niv Sardi
2011-Apr-19 05:07 UTC
[Icecast-dev] source questions & intentions to patch: yp-timing & auth
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
Robin Gareus
2011-Apr-19 11:23 UTC
[Icecast-dev] source questions & intentions to patch: yp-timing & auth
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=1705I'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/