Icecast-Server issueshttps://gitlab.xiph.org/xiph/icecast-server/-/issues2018-06-15T21:17:45Zhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2147Split up Icecast certificate handling into private and public key files2018-06-15T21:17:45ZThomas B. RückerSplit up Icecast certificate handling into private and public key filesThis would make it easier for people who are used to most software requiring two files, also it would make it easier to share certificate files with other server software like e.g. Apache httpd or dovecot imapd.This would make it easier for people who are used to most software requiring two files, also it would make it easier to share certificate files with other server software like e.g. Apache httpd or dovecot imapd.Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2146Icecast should send the "admin" field from config to YP2018-03-06T12:49:47ZThomas B. RückerIcecast should send the "admin" field from config to YPThis would allow the YP admins to contact the server administrator in case of problems with the listing/streams.
It would address a very common problem, finding out the contact details for a server admin.This would allow the YP admins to contact the server administrator in case of problems with the listing/streams.
It would address a very common problem, finding out the contact details for a server admin.Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2145Adding <outro> file for mountpoints2018-03-06T12:49:38ZJordan EricksonAdding <outro> file for mountpointsHello, I thought of the idea of adding an <outro> file for mountpoints. This would operate like <intro>, but the file would be played immediately after a source disconnects and before the <intro> of any fallback mounts that listeners are...Hello, I thought of the idea of adding an <outro> file for mountpoints. This would operate like <intro>, but the file would be played immediately after a source disconnects and before the <intro> of any fallback mounts that listeners are moved to. Thank you for your consideration =)Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2144Icecast might hang with 100% cpu use upon failed startup2018-10-27T11:17:45ZThomas B. RückerIcecast might hang with 100% cpu use upon failed startupI just ran into it again. It looks like it gets caught up in waiting for something.
Example output when trying to bind to inexistent IPv4 address:
```
$ /usr/bin/icecast -c /etc/icecast.xml
[2015-01-08 05:21:48] EROR connection/connec...I just ran into it again. It looks like it gets caught up in waiting for something.
Example output when trying to bind to inexistent IPv4 address:
```
$ /usr/bin/icecast -c /etc/icecast.xml
[2015-01-08 05:21:48] EROR connection/connection_setup_sockets Could not create listener socket on port 8000 bind 203.0.113.23
[2015-01-08 05:21:48] EROR connection/connection_setup_sockets No listening sockets established
Server startup failed. Exiting
```
"strace -f" doesn't produce any output after writing that last message.Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2143Regresion: reloadconfig* got de-linked on redesign of admin intrerface2018-03-06T12:49:47ZPhilipp SchafftRegresion: reloadconfig* got de-linked on redesign of admin intrerfaceLinks to the reloadconfig-admin command got lost on update of the design. Those should be re-linked.Links to the reloadconfig-admin command got lost on update of the design. Those should be re-linked.Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2138VCLT support in current icecast is useless2018-03-06T12:49:38ZPhilipp SchafftVCLT support in current icecast is uselessIn current state VCLT support is in codebase but not exposed anywhere beside the admin interface. As of current state it is of no use as it is not exposed to the listeners in any way.
I request to
1. enable support by making it as visib...In current state VCLT support is in codebase but not exposed anywhere beside the admin interface. As of current state it is of no use as it is not exposed to the listeners in any way.
I request to
1. enable support by making it as visible as the other formats OR
1. disable it by removing the code to avoid any maintenance need in future releases.
dm8tbr acknowledged to take a decision on this before final release of 2.5.Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2135Return "return" code for command_manageauth iceresponse2018-07-16T09:12:54ZMarvin ScholzReturn "return" code for command_manageauth iceresponseReturn "return" code in iceresponse for command_manageauth, to indicate if it failed or succeeded.Return "return" code in iceresponse for command_manageauth, to indicate if it failed or succeeded.Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2134Please add SSL support for Master -> Slave relay connections2021-11-10T08:58:41ZJordan EricksonPlease add SSL support for Master -> Slave relay connectionsIn considering a secure end-to-end Icecast communication chain, it would be wonderful to have the ability for SSL enabled master -> slave relay connections.In considering a secure end-to-end Icecast communication chain, it would be wonderful to have the ability for SSL enabled master -> slave relay connections.Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2133Regression: Role management not possible via admin interface2018-03-06T12:49:47ZPhilipp SchafftRegression: Role management not possible via admin interfaceRole management via admin/ interface is currently not possible as there is no lists of roles displayed. listings of roles must be implemented so user can find the right link to the management page.Role management via admin/ interface is currently not possible as there is no lists of roles displayed. listings of roles must be implemented so user can find the right link to the management page.Icecast 2.5.0Marvin ScholzMarvin Scholzhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2130Add POST support to admin requests2018-10-04T10:42:35ZMarvin ScholzAdd POST support to admin requestsDue to how web stuff works and the web interface handles things (auth managements for instance) it is mandatory that we support POST, for properly sending data to the server.
(Just one downside of GET that already should be enough is th...Due to how web stuff works and the web interface handles things (auth managements for instance) it is mandatory that we support POST, for properly sending data to the server.
(Just one downside of GET that already should be enough is that the password would be in cleartext in the browser history)Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2127Icecast needs a web-UI for configuration2018-03-06T12:49:38ZThomas B. RückerIcecast needs a web-UI for configurationThere are various existing projects, open and proprietary, but none really make full use of the potential, while being usable.
The Icecast project should have its own reference configuration UI. Either from scratch or by adopting an exis...There are various existing projects, open and proprietary, but none really make full use of the potential, while being usable.
The Icecast project should have its own reference configuration UI. Either from scratch or by adopting an existing open source project.
There are two possible approaches:
* Internal (somehow as part of /admin)
* External (running on a proper web server)
The former would make it self-contained, while the latter would enable us to leverage an existing framework.
Both approaches need to be explored before a decision is made.
PS: Being fairly self-contained this would be potentially a very good GSoC or similar project. I am also sufficiently familiar with the config file and live config mechanics to mentor such a task.Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2126listener_remove is not triggered when kicking users2018-10-04T11:08:04ZMarius Flagelistener_remove is not triggered when kicking usersWhen kicking users, listener_remove isn't triggered. This has been tested on Icecast 2.3.3.
I haven't tested if this works if you remove a mount point, but one would like the same functionality here, that listener_remove is triggered as...When kicking users, listener_remove isn't triggered. This has been tested on Icecast 2.3.3.
I haven't tested if this works if you remove a mount point, but one would like the same functionality here, that listener_remove is triggered as well. I use these triggers to update a database with listeners and to make sure I have consistency, it would be nice if both triggers (listener_add and listener_remove) were triggered whatever causes a listener to be added and removed.Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2125Kicking a source disconnects listeners even if fallback defined2018-03-06T12:49:47ZThomas B. RückerKicking a source disconnects listeners even if fallback definedAs mentioned by ph3-der-loewe, this seems to happen. One would expect that if a source is forcefully disconnected, that the listeners are sent to defined fallbacks.As mentioned by ph3-der-loewe, this seems to happen. One would expect that if a source is forcefully disconnected, that the listeners are sent to defined fallbacks.Icecast 2.5.0Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2124With <role> every client needs to go thru the stack of auth_ts. This will del...2018-03-06T12:49:47ZPhilipp SchafftWith <role> every client needs to go thru the stack of auth_ts. This will delay client connectionsEvery client is now forced to auth. As currently each <role> is implemented with a independent thread and queue this may take extra time. also some modules such as the static type can tell with like no delay if a user matches and does no...Every client is now forced to auth. As currently each <role> is implemented with a independent thread and queue this may take extra time. also some modules such as the static type can tell with like no delay if a user matches and does not need the asynchronous handling of a thread.
I suggest to build an interface so the type cann tell if they need the asynchronous interface or if a synchronous interface will do.
This would reduce the number of threads by at least one per process plus one per password (non-htpasswd) auth. If htpasswd auth can be converted is to be checked.
I suspect a massive performance improvement by this.Icecast 2.5.0Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2123Support management of multiple <role>s2018-03-06T12:49:47ZPhilipp SchafftSupport management of multiple <role>sAs with <role> support there can be multiple per <mount> and global <role>s management support in the admin/ interface needs update.
there are 3 most major parts of this:
1. defining format and outputting information about those <role>s...As with <role> support there can be multiple per <mount> and global <role>s management support in the admin/ interface needs update.
there are 3 most major parts of this:
1. defining format and outputting information about those <role>s on a given (mount or global) object.
1. update the admin/*.xsl files to reflect the new interface.
1. update command_manageauth() to reflect the changes.
Please define a format for the output and reassign to me after that.
Examples:
```
<authentication>
<role id="xxx" name="yyy" />
<role id="xxx" name="yyy" />
<role id="xxx" name="yyy" />
</authentication>
```
```
<authentication>
<role>
<id>yyy</id>
<name>xxx</name>
</role>
<role>
<id>yyy</id>
<name>xxx</name>
</role>
<role>
<id>yyy</id>
<name>xxx</name>
</role>
</authentication>
```
The first example mimics the config file format. The second is more to how stuff in admin/* has been.Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2122README.md needs minor fixes2018-03-06T12:49:47ZThomas B. RückerREADME.md needs minor fixese.g. webm and opus missing
Also this ticket will serve for testing git to trac hooks.e.g. webm and opus missing
Also this ticket will serve for testing git to trac hooks.Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2121doc subdirectories don't work if packaging overrides "docdir"2018-03-06T12:49:47ZThomas B. Rückerdoc subdirectories don't work if packaging overrides "docdir"Case in point: debian
Patch is in the works as I need it also for my deb/RPM packaging on OBS.Case in point: debian
Patch is in the works as I need it also for my deb/RPM packaging on OBS.Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2119Filter based on User Agent2018-11-10T13:31:06ZPhilipp SchafftFilter based on User AgentThere is `<allow-ip>` and `<deny-ip>` already. Someone was asking me for a way to filter clients based on User Agents.
I would suggest to implement this as a role-type. This should allow matching on all headers and maybe on other kinds ...There is `<allow-ip>` and `<deny-ip>` already. Someone was asking me for a way to filter clients based on User Agents.
I would suggest to implement this as a role-type. This should allow matching on all headers and maybe on other kinds of client data as well.
The module would return `NOMATCH` on no match or `FAILED` on match on deny list. Behaviour on pass should maybe be documented. Defaulting to `NOMATCH` to continue with the processing of other `<role>`s.
Some technical background:
In contrast to the `<allow-ip>` and `<deny-ip>` this check can only happen after the client request has been parsed as it depends on data of exactly this client request. This makes it less suitable for (D)DoS protection in general. It should be considered to use some kind of firewalling of fail2ban to protect against such attacks.
Pros of implementing it the way described above:
- It would match the internal schemata and wouldn't be another alien.
- It could be extended to universally match any configured attributes of the client object.
- Integrates well into usage together with other `<role>`s. E.g. to allow some role access but deny others access depending on this module (admin can always go, listeners only if user agent matches).
- Rejects the client with a `401` according to the standard.
Contra:
- Is much slower than implementing it in a specific and specific way as it happens in the authentication engine and not in before on rejected clients. Slowdown for passing clients will not be significant.
- Rejects clients with a standard conforming `401`. Does not just drop them.Icecast 2.5.0Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2117Creating a policy for removing support for obsoleted features/interfaces2018-06-16T22:40:11ZPhilipp SchafftCreating a policy for removing support for obsoleted features/interfacesThere needs to be a policy that tells when and how to remove a feature or interface that has been obsoleted for some reason. This policy will become very important when moving forward. Icecast recently had some major changes that move th...There needs to be a policy that tells when and how to remove a feature or interface that has been obsoleted for some reason. This policy will become very important when moving forward. Icecast recently had some major changes that move the internals away from how 2.3.2 was. Such a policy will help much to avoid keeping workarounds for older ways of doing stuff in the codebase and will be a major improvement to the code quality and maintainability.Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2116Write FAQ on how to set <hostname> correctly2022-03-21T09:35:20ZPhilipp SchafftWrite FAQ on how to set <hostname> correctlyAs we introduced checks for <hostname> and may going to be more strict with this over time documentation needs to be updated.
- Check if documentation tells about setting this to an IP address anywhere. If so correct this.
- Write a sma...As we introduced checks for <hostname> and may going to be more strict with this over time documentation needs to be updated.
- Check if documentation tells about setting this to an IP address anywhere. If so correct this.
- Write a small FAQ on setting <hostname> correctly. This should be mostly for those who aren't familiar with the concept of hostnames.
Some ideas for the FAQ:
- Tell what a hostname, a FQDN is and how it is related and more importantly not related to IP addresses.
- Include a hint to use same domain as webpage.
- Include hint for falling back to whatever server hoster use a default hostname.Icecast 2.5.0Thomas B. RückerThomas B. Rücker