1
0
Fork 0

Ugly merge of docs for beta1 as generator failed

This commit is contained in:
Thomas B. Ruecker 2014-12-31 17:33:36 +00:00
parent e445065ab1
commit fd23554181
13 changed files with 279 additions and 145 deletions

View File

@ -16,7 +16,7 @@
<div class="section">
<h2>Icecast 2.4.1 Docs &mdash; Admin Interface</h2>
<h2>Icecast 2.4.99.1 Docs &mdash; Admin Interface</h2>
<div class="article">
@ -140,4 +140,4 @@ To see the XML document that is applied to each admin XSLT, just remove the <cod
</div>
</body>
</html>
</html>

View File

@ -16,7 +16,7 @@
<div class="section">
<h2>Icecast 2.4.1 Docs &mdash; Authentication</h2>
<h2>Icecast 2.4.99.1 Docs &mdash; Authentication</h2>
<div class="article">
<h3 id="listener-authentication">Listener Authentication</h3>
@ -356,4 +356,4 @@ stream is active. For these <code>admin</code> is set to <code>1</code> in POST
</div>
</body>
</html>
</html>

View File

@ -16,7 +16,7 @@
<div class="section">
<h2>Icecast 2.4.1 Docs &mdash; Basic Setup</h2>
<h2>Icecast 2.4.99.1 Docs &mdash; Basic Setup</h2>
<div class="article">
<h3 id="basic-requirements">Basic Requirements</h3>
@ -88,4 +88,4 @@ source password - from <code>&lt;source-password&gt;</code> </p>
</div>
</body>
</html>
</html>

View File

@ -16,117 +16,129 @@
<div class="section">
<h2>Icecast 2.4.1 Docs &mdash; Changes</h2>
<h2>Icecast 2.4.99.1 Docs &mdash; Changes</h2>
<div id="v2.4.1" class="article">
<h3 id="version-241">Version 2.4.1</h3>
<h4 id="fixes">Fixes</h4>
<div id="v2.4.99.1" class="article">
<h3 id="version-24991">Version 2.4.99.1</h3>
<!-- FIXME -->
<ul>
<li>Fixed cross-corruption of file descriptors by on-connect/on-disconnect scripts, specifically STDIN, STDOUT and STDERRR vs TCP connections.
<ul>
<li>We actually close not just 0, 1 and 2, but the first 1024 FDs, which seems common trade-off practice, but still not ideal. A more thorough fix will need platform specific logic and significant work.</li>
<li>The STDIN/OUT/ERR problem is fixed reliably, but other problems could occur if both the script and the server use FDs &gt;1024 at the same time</li>
<li>This is now reasonably safe, but care should be exercised nevertheless. </li>
</ul>
</li>
<li>Disabled SSLv3 and SSL compression explicitly to improve security</li>
<li>Updated the default ciphers to be more secure</li>
<li>Fixed JSON status API problems
<ul>
<li>Put the XSLT last item check into every filtered tag.</li>
<li>This way we shouldnt run into problems of this type anymore.</li>
<li>Also it should be easier to customize the XSLT this way, if someone wants to filter differently.</li>
</ul>
</li>
<li>Fixed <code>&lt;auth&gt;</code> in <code>&lt;mount type="default"&gt;</code> to work properly.</li>
<li>Fixed listener connection duration logging in access.log. Regression was introduced for only some platforms by an earlier security fix.</li>
<li>Fixed time zone reporting in _iso8601 fields on Windows.</li>
<li>added warnings on empty and default values of <code>&lt;fileserve&gt;</code>, <code>&lt;hostname&gt;</code>, <code>&lt;location&gt;</code>, <code>&lt;admin&gt;</code> and <code>&lt;server-id&gt;</code></li>
<li>send errorlog (loglevel WARN) to stderr prior to opening logfiles.</li>
<li>Fixed handling of empty strings in config file. Now empty strings are handled in: accesslog, errorlog, logdir, webroot, adminroot and hopefully all kinds of port.</li>
<li>Be more verbose in case of fileserve off. People disable fileserve and then wonder why the web interface CSS breaks.</li>
<li>More details in log messages
<ul>
<li>Add source IP adress to startup and source exit logging</li>
<li>Add mountpoint to some log lines</li>
</ul>
</li>
<li>Updated the config file to avoid common pitfalls and make some things more obvious.</li>
<li>Fixed some compiler warnings</li>
<li>Fixed autogen.sh to work properly on Mac OS</li>
<li>Fixed JSON access by adding support for global and mount specific custom HTTP headers.
<ul>
<li>The purpose is to fix JSON access from browsers, by supporting basic CORS use cases. This is both important for some HTML5 <code>&lt;audio&gt;</code> or <code>&lt;video&gt;</code> use cases and accessing the JSON status API.</li>
<li>The default icecast config contains the very permissive global header: &lt;header name="Access-Control-Allow-Origin" value="*" /&gt;</li>
</ul>
</li>
<li>Roles</li>
<li>Events</li>
<li>Stuff</li>
<li>Read ChangeLog for details</li>
</ul>
<h4 id="known-issues">Known issues</h4>
<div id="v2.4.1" class="article">
<h3 id="version-241">Version 2.4.1</h3>
<ul>
<li>HTTP PUT implementation currently doesnt support chunked encoding yet.</li>
<li>HTTP PUT with “Expect: 100-Continue” receives first a “100” and soon after a “200”, instead of the “200” at the end of transmission.</li>
<li>Caution should be exercised when using <code>&lt;on-connect&gt;</code> or <code>&lt;on-disconnect&gt;</code>, as there is a small chance of stream file descriptors being mixed up with script file descriptors, if the FD numbers go above 1024. This will be further addressed in the next Icecast release.</li>
<li>Dont use comments inside <code>&lt;http-headers&gt;</code> as it will prevent processing of further <code>&lt;header&gt;</code> tags.</li>
</ul>
</div>
<h4 id="fixes">Fixes</h4>
<div id="v2.4.0" class="article">
<h3 id="version-240">Version 2.4.0</h3>
<ul>
<li>Fixed cross-corruption of file descriptors by on-connect/on-disconnect scripts, specifically STDIN, STDOUT and STDERRR vs TCP connections.
<ul>
<li>We actually close not just 0, 1 and 2, but the first 1024 FDs, which seems common trade-off practice, but still not ideal. A more thorough fix will need platform specific logic and significant work.</li>
<li>The STDIN/OUT/ERR problem is fixed reliably, but other problems could occur if both the script and the server use FDs &gt;1024 at the same time</li>
<li>This is now reasonably safe, but care should be exercised nevertheless. </li>
</ul>
</li>
<li>Disabled SSLv3 and SSL compression explicitly to improve security</li>
<li>Updated the default ciphers to be more secure</li>
<li>Fixed JSON status API problems
<ul>
<li>Put the XSLT last item check into every filtered tag.</li>
<li>This way we shouldnt run into problems of this type anymore.</li>
<li>Also it should be easier to customize the XSLT this way, if someone wants to filter differently.</li>
</ul>
</li>
<li>Fixed <code>&lt;auth&gt;</code> in <code>&lt;mount type="default"&gt;</code> to work properly.</li>
<li>Fixed listener connection duration logging in access.log. Regression was introduced for only some platforms by an earlier security fix.</li>
<li>Fixed time zone reporting in _iso8601 fields on Windows.</li>
<li>added warnings on empty and default values of <code>&lt;fileserve&gt;</code>, <code>&lt;hostname&gt;</code>, <code>&lt;location&gt;</code>, <code>&lt;admin&gt;</code> and <code>&lt;server-id&gt;</code></li>
<li>send errorlog (loglevel WARN) to stderr prior to opening logfiles.</li>
<li>Fixed handling of empty strings in config file. Now empty strings are handled in: accesslog, errorlog, logdir, webroot, adminroot and hopefully all kinds of port.</li>
<li>Be more verbose in case of fileserve off. People disable fileserve and then wonder why the web interface CSS breaks.</li>
<li>More details in log messages
<ul>
<li>Add source IP adress to startup and source exit logging</li>
<li>Add mountpoint to some log lines</li>
</ul>
</li>
<li>Updated the config file to avoid common pitfalls and make some things more obvious.</li>
<li>Fixed some compiler warnings</li>
<li>Fixed autogen.sh to work properly on Mac OS</li>
<li>Fixed JSON access by adding support for global and mount specific custom HTTP headers.
<ul>
<li>The purpose is to fix JSON access from browsers, by supporting basic CORS use cases. This is both important for some HTML5 <code>&lt;audio&gt;</code> or <code>&lt;video&gt;</code> use cases and accessing the JSON status API.</li>
<li>The default icecast config contains the very permissive global header: &lt;header name="Access-Control-Allow-Origin" value="*" /&gt;</li>
</ul>
</li>
</ul>
<h4 id="new-features">New Features</h4>
<h4 id="known-issues">Known issues</h4>
<ul>
<li>Support for Ogg Opus streams</li>
<li>Support for WebM streams</li>
<li>HTTP 1.1 PUT support for source connections. Deprecating SOURCE method</li>
<li><em>Default mount</em><br />
<ul>
<li>HTTP PUT implementation currently doesnt support chunked encoding yet.</li>
<li>HTTP PUT with “Expect: 100-Continue” receives first a “100” and soon after a “200”, instead of the “200” at the end of transmission.</li>
<li>Caution should be exercised when using <code>&lt;on-connect&gt;</code> or <code>&lt;on-disconnect&gt;</code>, as there is a small chance of stream file descriptors being mixed up with script file descriptors, if the FD numbers go above 1024. This will be further addressed in the next Icecast release.</li>
<li>Dont use comments inside <code>&lt;http-headers&gt;</code> as it will prevent processing of further <code>&lt;header&gt;</code> tags.</li>
</ul>
</div>
<div id="v2.4.0" class="article">
<h3 id="version-240">Version 2.4.0</h3>
<h4 id="new-features">New Features</h4>
<ul>
<li>Support for Ogg Opus streams</li>
<li>Support for WebM streams</li>
<li>HTTP 1.1 PUT support for source connections. Deprecating SOURCE method</li>
<li><em>Default mount</em><br />
This allows you to define a global set of defaults for ALL mounts. This way you can use e.g. url-auth for sources and or listeners also for dynamically generated mounts.</li>
<li><em>Web interface redone</em>
<ul>
<li>Web output properly redone, credit to ePirat</li>
<li>Added <code>&lt;audio&gt;</code> element for supported audio streams</li>
<li>Now validates completely as XHTML1.0 strict</li>
<li>Also improves rendering on mobile devices</li>
</ul>
</li>
<li>Added basic JSON API (<code>/status-json.xsl</code>) based on a xml2json template by Doeke Zanstra (see <code>xml2json.xslt</code>). Output is roughly limited to data also visible through <code>status.xsl</code></li>
<li>Send charset in HTTP headers for everything, excluding file-serv and streams</li>
<li>Allow (standard strftime(3)) <code>%x</code> codes in <code>&lt;dump-file&gt;</code>. Disabled for Win32</li>
<li>Added <code>stream_start_iso8601</code>, <code>server_start_iso8601</code> to statitics. ISO8601 compliante timestamps for statistics. Should make usage in e.g. JSON much easier. Added as new variables to avoid breaking backwards compatibility</li>
<li>Now compiles for Win32 using mingw</li>
<li>Added options <code>headers</code> and <code>header_prefix</code> to URL based listener auth</li>
<li>Updated <code>listener_remove</code> handler, added <code>ip=</code> and <code>agent=</code></li>
<li>Allow full URLs to be returned by the master server</li>
</ul>
<li><em>Web interface redone</em>
<ul>
<li>Web output properly redone, credit to ePirat</li>
<li>Added <code>&lt;audio&gt;</code> element for supported audio streams</li>
<li>Now validates completely as XHTML1.0 strict</li>
<li>Also improves rendering on mobile devices</li>
</ul>
</li>
<li>Added basic JSON API (<code>/status-json.xsl</code>) based on a xml2json template by Doeke Zanstra (see <code>xml2json.xslt</code>). Output is roughly limited to data also visible through <code>status.xsl</code></li>
<li>Send charset in HTTP headers for everything, excluding file-serv and streams</li>
<li>Allow (standard strftime(3)) <code>%x</code> codes in <code>&lt;dump-file&gt;</code>. Disabled for Win32</li>
<li>Added <code>stream_start_iso8601</code>, <code>server_start_iso8601</code> to statitics. ISO8601 compliante timestamps for statistics. Should make usage in e.g. JSON much easier. Added as new variables to avoid breaking backwards compatibility</li>
<li>Now compiles for Win32 using mingw</li>
<li>Added options <code>headers</code> and <code>header_prefix</code> to URL based listener auth</li>
<li>Updated <code>listener_remove</code> handler, added <code>ip=</code> and <code>agent=</code></li>
<li>Allow full URLs to be returned by the master server</li>
</ul>
<h4 id="fixes-1">Fixes</h4>
<h4 id="fixes-1">Fixes</h4>
<ul>
<li><strong>Security fix</strong>: Override supplementary groups if is used</li>
<li>Fixes for some race conditions</li>
<li>Dropped debian packaging directory as debian use their own.</li>
<li>Send proper HTTP headers in responses to clients.</li>
<li>Corrected Content-Length: header in admin (raw) requests. Thanks to paluh for reporting.</li>
<li>Escape log entries in access log</li>
<li>Fixed a memory leak. Lost headers of stream because of wrong ref counter in associated refbuf objects.</li>
<li>Avoid memory leak in <code>_parse_mount()</code> when <code>type</code>-attribute is set</li>
<li>Updated web interface to be XHTML compliant.</li>
<li>Removed <code>status2.xsl</code> from release. It was only a broken example file anyway.</li>
</ul>
<ul>
<li><strong>Security fix</strong>: Override supplementary groups if is used</li>
<li>Fixes for some race conditions</li>
<li>Dropped debian packaging directory as debian use their own.</li>
<li>Send proper HTTP headers in responses to clients.</li>
<li>Corrected Content-Length: header in admin (raw) requests. Thanks to paluh for reporting.</li>
<li>Escape log entries in access log</li>
<li>Fixed a memory leak. Lost headers of stream because of wrong ref counter in associated refbuf objects.</li>
<li>Avoid memory leak in <code>_parse_mount()</code> when <code>type</code>-attribute is set</li>
<li>Updated web interface to be XHTML compliant.</li>
<li>Removed <code>status2.xsl</code> from release. It was only a broken example file anyway.</li>
</ul>
<h4 id="known-issues-1">Known issues</h4>
<h4 id="known-issues-1">Known issues</h4>
<ul>
<li>Will crash if certain config tags are left empty</li>
</ul>
<ul>
<li>Will crash if certain config tags are left empty</li>
</ul>
</div>
</div>
</div>
<div class="footer">

View File

@ -14,9 +14,11 @@
<h1><a href="#" title="Home page">Icecast</a> <span>documentation</span></h1>
</div>
<div class="section">
<h2>Icecast 2.4.1 Docs &mdash; Config File</h2>
<h2>Icecast 2.4.99.1 Docs &mdash; Config File</h2>
<div class="article">
<h3 id="overview">Overview</h3>
@ -27,6 +29,8 @@
<li><a href="#authentication">Authentication</a></li>
<li><a href="#yp">Stream Directory Settings</a></li>
<li><a href="#misc">Misc Server settings</a></li>
<li><a href="#ports">TCP-Port settings</a></li>
<li><a href="#global-headers">Global HTTP Headers</a></li>
<li><a href="#relay">Relay settings</a></li>
<li><a href="#mountsettings">Mount Specific settings</a></li>
<li><a href="#path">File path settings</a></li>
@ -109,6 +113,7 @@ initial burst leading to the connection already exceeding the queue-size limit.<
<div class="article">
<h3 id="authentication">Authentication</h3>
<!-- FIXME -->
<div class="highlight"><pre><code class="language-xml" data-lang="xml"><span class="nt">&lt;authentication&gt;</span>
<span class="nt">&lt;source-password&gt;</span>hackme<span class="nt">&lt;/source-password&gt;</span>
@ -118,18 +123,38 @@ initial burst leading to the connection already exceeding the queue-size limit.<
<span class="nt">&lt;admin-password&gt;</span>hackme<span class="nt">&lt;/admin-password&gt;</span>
<span class="nt">&lt;/authentication&gt;</span></code></pre></div>
<!-- FIXME -->
<p>This section contains all the usernames and passwords used for administration purposes or to connect sources and relays.</p>
<!-- FIXME -->
<dl>
<dt>role</dt>
<dd>contains role definitions</dd>
</dl>
<!-- FIXME -->
<dl>
<dt>source-password</dt>
<dd>The unencrypted password used by sources to connect to Icecast. The default username for all
source connections is source but this option allows to specify a default password. This and the
username can be changed in the individual mount sections.</dd>
</dl>
<!-- FIXME -->
<dl>
<dt>relay-user</dt>
<dd>Used in the master server as part of the authentication when a slave requests the list of streams
to relay. The default username is <code>relay</code></dd>
</dl>
<!-- FIXME -->
<dl>
<dt>relay-password</dt>
<dd>Used in the master server as part of the authentication when a slave requests the list of streams to relay.</dd>
</dl>
<!-- FIXME -->
<dl>
<dt>admin-user/admin-password</dt>
<dd>The username/password used for all administration functions. This includes retrieving statistics, accessing the web-based
administration screens, etc. A list of these functions can be found in the “Administration” section of the manual.</dd>
@ -168,7 +193,7 @@ The value for this setting is provided by the owner of the Directory server.</dd
<span class="nt">&lt;location&gt;</span>earth<span class="nt">&lt;/location&gt;</span>
<span class="nt">&lt;admin&gt;</span>icemaster@localhost<span class="nt">&lt;/admin&gt;</span>
<span class="nt">&lt;fileserve&gt;</span>1<span class="nt">&lt;/fileserve&gt;</span>
<span class="nt">&lt;server-id&gt;</span>icecast 2.4.1<span class="nt">&lt;/server-id&gt;</span></code></pre></div>
<span class="nt">&lt;server-id&gt;</span>icecast 2.5<span class="nt">&lt;/server-id&gt;</span></code></pre></div>
<dl>
<dt>hostname</dt>
@ -200,7 +225,7 @@ setting, unless you have very good reasons and know what you are doing.</dd>
<p>The following shows how you can specify the listening settings for the server.</p>
<h4 id="generic-port-setup">generic port setup</h4>
<h4 id="generic-port-setup">Generic port setup</h4>
<p>The first shows an example of a common and simple way to define a listening socket:</p>
@ -213,7 +238,7 @@ will listen on. Most will not need to use bind-address and often get confused by
no need. Another possibility is to use an <code>&lt;ssl&gt;</code> boolean setting which informs Icecast that a secured
connection is to be used. A common use for using a secure connection would be for admin page access. </p>
<h4 id="backward-compatibility-with-shoutcast-source-clients">backward compatibility with Shoutcast source clients</h4>
<h4 id="backward-compatibility-with-shoutcast-source-clients">Backward compatibility with Shoutcast source clients</h4>
<p>The following shows how we can extend a single listen-socket to work with Shoutcast style source clients.
There are two issues shoutcast source clients have over icecast source clients, one is the lack of mountpoint
@ -230,7 +255,7 @@ listening socket whose port number is always one higher than the port defined, t
of which mountpoint the shoutcast source client on this socket will be using. Using this approach you can
allow multiple shoutcast source clients to connect at the same time. </p>
<h4 id="old-style-shoutcast-source-client-compatible-setup-deprecated">old style Shoutcast source client compatible setup (deprecated)</h4>
<h4 id="old-style-shoutcast-source-client-compatible-setup-deprecated">Old style Shoutcast source client compatible setup (deprecated)</h4>
<p>The following is just to show the longer approach to defining shoutcast compatability.</p>
@ -257,8 +282,7 @@ be required and often confuses people.</p>
<dd>An optional IP address that can be used to bind to a specific network
card. If not supplied, then it will bind to all interfaces.</dd>
<dt>ssl</dt>
<dd>If set to 1 will enable HTTPS on this listen-socket. Icecast must have been compiled against openSSL to be able
to do so.</dd>
<dd>If set to 1 will enable HTTPS on this listen-socket. Icecast must have been compiled against openSSL to be able to do so.</dd>
<dt>shoutcast-mount</dt>
<dd>An optional mountpoint setting to be used when shoutcast DSP compatible clients connect. The default global setting
is <code>/stream</code> but can be overridden here to use an alternative name which may include an extension that some clients
@ -296,7 +320,7 @@ of <code>8000</code> and it must not also be defined as <code>shoutcast-compat</
<dl>
<dt>http-headers</dt>
<dd>This element is placed anywhere inside the main section of the icecast config. It will contain <code>&lt;header&gt;</code> child elements, that specify the actual headers one by one.</dd>
<dd>This element is placed anywhere inside the main section of the Icecast config. It will contain <code>&lt;header&gt;</code> child elements, that specify the actual headers one by one.</dd>
<dt>header</dt>
<dd>This tag specifies the actual header to be sent to a HTTP client in response to every request.
This tag can contain the following attributes:
@ -310,7 +334,7 @@ This tag can contain the following attributes:
</dl>
<p>At the moment only global headers will be sent in case the HTTP status is not “200”. This is subject to change in the future.
Avoid placing comments inside <code>&lt;http-headers&gt;</code> as, in this release, it will prevent icecast from parsing further <code>&lt;header&gt;</code> tags.</p>
Avoid placing comments inside <code>&lt;http-headers&gt;</code> as, in this release, it will prevent Icecast from parsing further <code>&lt;header&gt;</code> tags.</p>
</div>
@ -421,6 +445,8 @@ limit bandwidth costs when no one is listening.</dd>
<div class="article">
<h3 id="mountsettings">Mount Specific Settings</h3>
<!-- FIXME -->
<div class="highlight"><pre><code class="language-xml" data-lang="xml"><span class="nt">&lt;mount</span> <span class="na">type=</span><span class="s">&quot;normal&quot;</span><span class="nt">&gt;</span>
<span class="nt">&lt;mount-name&gt;</span>/example-complex.ogg<span class="nt">&lt;/mount-name&gt;</span>
<span class="nt">&lt;username&gt;</span>othersource<span class="nt">&lt;/username&gt;</span>
@ -445,7 +471,7 @@ limit bandwidth costs when no one is listening.</dd>
<span class="nt">&lt;burst-size&gt;</span>65536<span class="nt">&lt;/burst-size&gt;</span>
<span class="nt">&lt;mp3-metadata-interval&gt;</span>4096<span class="nt">&lt;/mp3-metadata-interval&gt;</span>
<span class="nt">&lt;authentication</span> <span class="na">type=</span><span class="s">&quot;xxxxxx&quot;</span><span class="nt">&gt;</span>
<span class="c">&lt;!-- See listener authentiaction documentation --&gt;</span>
<span class="c">&lt;!-- See authentication documentation --&gt;</span>
<span class="nt">&lt;/authentication&gt;</span>
<span class="nt">&lt;http-headers&gt;</span>
<span class="nt">&lt;header</span> <span class="na">name=</span><span class="s">&quot;Access-Control-Allow-Origin&quot;</span> <span class="na">value=</span><span class="s">&quot;*&quot;</span> <span class="nt">/&gt;</span>
@ -477,11 +503,19 @@ corresponding to your mountpoint.</dd>
<dt>mount-name</dt>
<dd>The name of the mount point for which these settings apply.
MUST NOT be used in case of mount type “default”.</dd>
</dl>
<!-- FIXME -->
<dl>
<dt>username</dt>
<dd>An optional value which will set the username that a source must use to connect using this mountpoint.
Do not set this value unless you are sure that the source clients connecting to the mount point can be
configured to send a username other than <code>source</code>.<br />
If this value is not present the default username is <code>source</code>.</dd>
</dl>
<!-- FIXME -->
<dl>
<dt>password</dt>
<dd>An optional value which will set the password that a source must use to connect using this mountpoint.
There is also a <a href="auth.html#stream-auth">URL based authentication method</a> for sources that can be used instead.</dd>
@ -568,11 +602,15 @@ default is either the hardcoded server default or the value passed from a relay.
<dt>hidden</dt>
<dd>Enable this to prevent this mount from being shown on the xsl pages. This is mainly for cases where a local relay is configured
and you do not want the source of the local relay to be shown.</dd>
</dl>
<!-- FIXME -->
<dl>
<dt>authentication</dt>
<dd>This specifies that the named mount point will require listener (or source) authentication. Currently, we support a file-based
authentication scheme (<code>type=htpasswd</code>) and URL based authentication request forwarding. A mountpoint configured with an authenticator
will display a red key next to the mount point name on the admin screens.<br />
You can read more about listener authentication and URL based source authentication <a href="auth.html">here</a>.</dd>
You can read more about authentication and URL based source authentication <a href="auth.html">here</a>.</dd>
<dt>http-headers</dt>
<dd>This element is placed anywhere inside the mount section of the icecast config. It will contain <code>&lt;header&gt;</code> child elements, that specify the actual HTTP headers one by one.</dd>
<dt>header</dt>
@ -618,7 +656,7 @@ Caution should be exercised as there is a small chance of stream file descriptor
<dl>
<dt>basedir</dt>
<dd>This path is used in conjunction with the chroot settings, and specified the base directory that is chrooted to when the server is started.<br />
<dd>This path is used in conjunction with the chroot settings, and specifies the base directory that is chrooted to when the server is started.<br />
<em>This feature is not supported on Win32.</em></dd>
<dt>logdir</dt>
<dd>This path specifies the base directory used for logging. Both the <code>error.log</code> and <code>access.log</code> will be created relative to this directory.</dd>
@ -640,6 +678,10 @@ The format of the file is simple, one IP per line.</dd>
<dd>If specified, this points to the location of a file that contains a list of IP addressess that will be dropped immediately.
This is mainly for problem clients when you have no access to any firewall configuration.<br />
The format of the file is simple, one IP per line.</dd>
</dl>
<!-- FIXME -->
<dl>
<dt>alias</dt>
<dd>Aliases are used to provide a way to create multiple mountpoints that refer to the same mountpoint.<br />
For example: <code>&lt;alias source="/foo" dest="/bar"&gt;</code></dd>
@ -680,7 +722,7 @@ STDERR instead of a file.</p>
this file can grow fairly large over time. Currently, there is no log-rotation implemented.</dd>
<dt>playlistlog</dt>
<dd>Into this file, a log of all metadata for each mountpoint will be written. The format of the logfile will most likely change over time
as we narrow in on a standard format for this. Currently, the file is pipe delimited. This option is optional and can be removed entirely
as we narrow in on a standard format for this. Currently, the file is pipe delimited. This is optional and can be removed entirely
from the config file.</dd>
<dt>logsize</dt>
<dd>This value specifies (in Kbytes) the maxmimum size of any of the log files. When the logfile grows beyond this value, icecast will either
@ -738,4 +780,4 @@ These need to be valid users on the system. Icecast must be started as root for
</div>
</body>
</html>
</html>

View File

@ -16,7 +16,7 @@
<div class="section">
<h2>Icecast 2.4.1 Docs &mdash; FAQ</h2>
<h2>Icecast 2.4.99.1 Docs &mdash; FAQ</h2>
<div class="article">
<h3 id="general-questions">General Questions</h3>
@ -53,4 +53,4 @@ it on the fly.</p>
</div>
</body>
</html>
</html>

View File

@ -16,7 +16,7 @@
<div class="section">
<h2>Icecast 2.4.1 Docs &mdash; Glossary</h2>
<h2>Icecast 2.4.99.1 Docs &mdash; Glossary</h2>
<div class="article">
<dl>
@ -48,4 +48,4 @@ Icecast will then move all clients currently connected to the now defunct mountp
</div>
</body>
</html>
</html>

View File

@ -16,7 +16,7 @@
<div class="section">
<h2>Icecast 2.4.1 Docs &mdash; Table of Contents</h2>
<h2>Icecast 2.4.99.1 Docs &mdash; Table of Contents</h2>
<div class="article">
<h3 id="pages">Pages</h3>
@ -39,7 +39,7 @@
</div>
<div class="article">
<h3 id="icecast-241-readme">Icecast 2.4.1 Readme</h3>
<h3 id="icecast-241-readme">Icecast 2.4.99.1 Readme</h3>
<p>Icecast is a streaming media server which currently supports Ogg
Vorbis and MP3 audio streams. It can be used to create an Internet
radio station or a privately running jukebox and many things in
@ -96,4 +96,4 @@ at irc.freenode.net, channel #icecast, if you have any troubles.</p>
</div>
</body>
</html>
</html>

View File

@ -16,11 +16,11 @@
<div class="section">
<h2>Icecast 2.4.1 Docs &mdash; Introduction</h2>
<h2>Icecast 2.4.99.1 Docs &mdash; Introduction</h2>
<div class="article">
<h3 id="what-is-icecast">What is Icecast?</h3>
<p>Icecast is a streaming media server which currently supports Ogg Vorbis and MP3 audio streams. It can be used to create an Internet radio station or a privately running jukebox and many things in between. It is very versatile in that new formats can be added relatively easily and supports open standards for commuincation and interaction.</p>
<p>Icecast is a streaming media server which currently supports Ogg Vorbis, Opus, Theora and WebM streams, MP3 and AAC streams are known to work. It can be used to create an Internet radio station or a privately running jukebox and many things in between. It is very versatile in that new formats can be added relatively easily and supports open standards for commuincation and interaction.</p>
<p>There are two major parts to most streaming media servers: the component providing the content (what we call source clients) and the component which is responsible for serving that content to listeners (this is the function of icecast).</p>
</div>
@ -56,8 +56,8 @@
<p>Best Ways:</p>
<ul>
<li>Icecast mailing list <a href="http://www.xiph.org/archives">http://www.xiph.org/archives</a></li>
<li>Icecast Developers mailing list <a href="http://www.xiph.org/archives">http://www.xiph.org/archives</a></li>
<li>Icecast mailing list <a href="http://lists.xiph.org/mailman/listinfo/icecast">http://lists.xiph.org/mailman/listinfo/icecast</a></li>
<li>Icecast Developers mailing list <a href="http://lists.xiph.org/mailman/listinfo/icecast-dev">http://lists.xiph.org/mailman/listinfo/icecast-dev</a></li>
<li>Icecast IRC chat room - irc.freenode.net : #icecast</li>
</ul>
@ -70,4 +70,4 @@
</div>
</body>
</html>
</html>

View File

@ -16,7 +16,7 @@
<div class="section">
<h2>Icecast 2.4.1 Docs &mdash; Relaying</h2>
<h2>Icecast 2.4.99.1 Docs &mdash; Relaying</h2>
<div class="article">
<h3 id="overview">Overview</h3>
@ -92,4 +92,4 @@ in the stream itself) then the <code>&lt;relay-shoutcast-metadata&gt;</code> nee
</div>
</body>
</html>
</html>

View File

@ -16,7 +16,8 @@
<div class="section">
<h2>Icecast 2.4.1 Docs &mdash; Server Statistics</h2>
<h2>Icecast 2.4.99.1 Docs &mdash; Server Statistics</h2>
<div class="article">
<h3 id="overview">Overview</h3>
@ -36,17 +37,22 @@ API and will change it, even completely, between versions!<br />
<strong>The preferred ways are custom XSLT, JSON and raw XML.</strong></p>
</div>
<!-- FIXME -->
<div class="article">
<h3 id="json">JSON API, machine readable data</h3>
<p>Since version 2.4.0 Icecast includes a basic JSON API (<code>/status-json.xsl</code>) based on a xml2json template by Doeke Zanstra
(see <code>xml2json.xslt</code>). It exposes the same set of server statistics that are available through the web interface and
should fulfil basic user needs. The intention is to not break backwards compatibility of this interface in the future,
still we recommend to design robust software that can deal with possible changes like addition or removal of variables.
Also note that not all variables are available all the time and availability may change at runtime due to stream type, etc.</p>
</div>
<div class="article">
<h3 id="xslt_advanced">Advanced machine readable data, XSLT generated</h3>
<p>Icecast uses the very powerful libXSLT engine to transform its internal raw statistical data into custom tailored interfaces.
Many people have written custom XSLT code that produces e.g. plain text “now playing”, XSPF, VCLT, munin interface data, etc. </p>
<p>Since version 2.4.0 Icecast includes a basic JSON API (<code>/status-json.xsl</code>) based on a xml2json template by Doeke Zanstra
(see <code>xml2json.xslt</code>). It exposes a basic set of server statistics that should fulfil basic user needs. The intention is
to not break backwards compatibility of this interface in the future, still we recommend to design robust software that
can deal with possible changes like addition or removal of variables.</p>
</div>
<div class="article">
@ -55,6 +61,8 @@ can deal with possible changes like addition or removal of variables.</p>
<p>This section contains information about the raw XML server statistics data available inside Icecast. An example
stats XML tree will be shown and each element will be described. The following example stats tree will be used: </p>
<!-- FIXME -->
<div class="highlight"><pre><code class="language-xml" data-lang="xml"><span class="nt">&lt;icestats&gt;</span>
<span class="nt">&lt;admin&gt;</span>icemaster@localhost<span class="nt">&lt;/admin&gt;</span>
<span class="nt">&lt;client_connections&gt;</span>649<span class="nt">&lt;/client_connections&gt;</span>
@ -65,7 +73,7 @@ stats XML tree will be shown and each element will be described. The following e
<span class="nt">&lt;listener_connections&gt;</span>90<span class="nt">&lt;/listener_connections&gt;</span>
<span class="nt">&lt;listeners&gt;</span>0<span class="nt">&lt;/listeners&gt;</span>
<span class="nt">&lt;location&gt;</span>Earth<span class="nt">&lt;/location&gt;</span>
<span class="nt">&lt;server_id&gt;</span>Icecast 2.4.0<span class="nt">&lt;/server_id&gt;</span>
<span class="nt">&lt;server_id&gt;</span>Icecast 2.5<span class="nt">&lt;/server_id&gt;</span>
<span class="nt">&lt;source_client_connections&gt;</span>164<span class="nt">&lt;/source_client_connections&gt;</span>
<span class="nt">&lt;source_relay_connections&gt;</span>0<span class="nt">&lt;/source_relay_connections&gt;</span>
<span class="nt">&lt;source_total_connections&gt;</span>164<span class="nt">&lt;/source_total_connections&gt;</span>

View File

@ -16,17 +16,21 @@
<div class="section">
<h2>Icecast 2.4.1 Docs &mdash; Win32 Specifics</h2>
<h2>Icecast 2.4.99.1 Docs &mdash; Win32 Specifics</h2>
<div class="article">
<p>The Win32 port of Icecast 2 is a simple command line application,
it used to be a UI framework around the core Icecast 2 server. </p>
<p>The GUI is no longer necessary as Icecast has achieved all of its
functionality in its web interface.</p>
<p>Most of the features of Icecast 2 are available in the Win32 port.<br />
<strong>A notable absence is IPv6 support.</strong></p>
<p>If there is sufficient user interest we may reintroduce the Icecast GUI
and capability to start Icecast as a Windows Service.</p>
<p>We are planning to reintroduce the capability to start Icecast
as a Windows Service in the 2.5.0 release.</p>
</div>

View File

@ -16,16 +16,18 @@
<div class="section">
<h2>Icecast 2.4.1 Docs &mdash; YP Directories</h2>
<h2>Icecast 2.4.99.1 Docs &mdash; YP Directories</h2>
<div class="article">
<h3 id="overview">Overview</h3>
<p>A YP (Yellow Pages) directory is a listing of broadcast streams. Icecast 2 has it own YP directory located at
<p>A YP directory is a listing of broadcast streams. Icecast has it own YP directory located at
<a href="http://dir.xiph.org">http://dir.xiph.org</a>. Currently Icecast can only be listed in an Icecast-supported YP directory.<br />
This means that you cannot list your stream in the Shoutcast YP directory.</p>
This means that you cannot list your stream in the Shoutcast YP directory, due to their terms of service.</p>
<p>In the Icecast configuration file are all the currently available YP directory servers. Listing your stream in a YP is
a combination of settings in the Icecast configuration file and also in your source client.</p>
a combination of settings in the Icecast configuration file and also in your source client. It is of great importance
to configure Icecast correctly, as even one wrong setting can prevent listings to be accepted by a YP directory.</p>
</div>
@ -42,22 +44,88 @@ If Icecast has been built with YP support, then the following configuration opti
<p>Multiple directory XML chunks can be specified in order to be listed in multiple directories.</p>
<h4 id="further-options-that-play-a-significant-role-in-yp-listings">Further options that play a significant role in YP listings</h4>
<h5 id="hostname"><code>&lt;hostname&gt;</code></h5>
<p>The hostname option <strong>MUST</strong> be set to a name that resolves to the machine this Icecast server runs on.</p>
<h5 id="listener-socketport"><code>&lt;listener-socket&gt;&lt;port&gt;</code></h5>
<p>The <strong>first</strong> <code>listener-socke</code>+<code>port</code> entry is used to build the URL advertized to the YP server.</p>
<h5 id="listener-socketbind-address"><code>&lt;listener-socket&gt;&lt;bind-address&gt;</code></h5>
<p>If you dont specify an explicit <code>bind-address</code>, including <code>::</code> and <code>0.0.0.0</code>, then the default
bind behaviour of your operating system will apply, this may have unexpected consequences for dual-stack
(IPv6 and IPv4) setups.</p>
<p>If your hostname resolves to both an AAAA and an A record (IPv6 and IPv4), then you <strong>MUST</strong> verify,
that Icecast listens to both. If in doubt create two listener-socket entries and use <code>::</code> and <code>0.0.0.0</code>
as the respective <code>bind-address</code>.</p>
<h5 id="admin-contact"><code>&lt;admin&gt;</code> contact</h5>
<p>If you are listing on a YP, then this field <strong>MUST</strong> contain a valid email address of a technical contact
on your side. YP admins will use this to reach you in case your server is misconfigured and causes problems
for the YP directory. An invalid or unreachable address is likely to get your radio/server/network banned from YP.</p>
<h5 id="verifying-the-advertized-url">Verifying the advertized URL</h5>
<p>After adjusting the settings and configuring your source client, you should verify setup: <br />
Go to the Icecast web interface, specifically the admin part <code>/admin/</code> and look for the <code>listenurl</code> values
of your streams. These URLs <strong>MUST</strong> work from the public internet, or your listings will fail.</p>
<p>This is also one of the checks performed by a YP server. Common misconfigurations are:<br />
* <code>&lt;hostname&gt;</code> set to <code>localhost</code>
* <code>&lt;hostname&gt;</code> set to some address that does <strong>NOT</strong> point to the Icecast server
* hostname has AAAA record but Icecast not bound to <code>::</code>
* multiple <code>&lt;listener-socket&gt;</code> entries, but the first one is not publicly reachable</p>
</div>
<div class="article">
<h3 id="configuring-your-source-client-for-yp-support">Configuring Your Source Client for YP Support</h3>
<p>This is usually covered in the source client documentation. More specifically, the source client needs to provide
the HTTP header <code>Ice-Public: 1</code> on connect in order to enable YP listing of the stream.<br />
This can however be overridden in mount point settings, refer to “<a href="config-file.html#mountsettings">Icecast Config File</a>
This can however be overridden in the server side mount point settings, refer to “<a href="config-file.html#mountsettings">Icecast Config File</a>
for further details.<br />
If a mountpoint is being listed on a YP, then you will see some additional statistics relating to the YP such as
<code>last-touch</code>, <code>currently-playing</code>, etc.</p>
</div>
<div class="article">
<h3 id="troubleshooting">Troubleshooting</h3>
<p>As with all Icecast problems, the error log is the goto place to start. If necessary temporary increase the log level to
<code>4</code> (debug) and reload the Icecast config. All relevant messages will contain <code>YP</code>. Especially those messages that tell
you that something <code>failed</code> will contain important hints and or messages from the YP server. If your entry submission
is directly rejected the server will tell why, if your entry gets delisted after submission, then you will see
updates/touches fail. Depending on the YP server the stream reachability check will be deferred, so you will see
a successfull initial submission, but if your stream is found to be unreachable it will be delisted and updates will fail.
Please note that YP directories will check both IPv6 and IPv4 availability of streams. See the list of common misconfigurations
for further hints.</p>
<p>Should you still have problems listing on <a href="dir.xiph.org">http://dir.xiph.org</a>, then please:
* set your logging to <code>4</code> (debug)
* reload/restart Icecast
* make sure your streams are running and marked public (either by source setting or mountpoint override)
* wait for <strong>one hour</strong>
* filter the error log for messages from the last hour, that are beginning with <code>yp/</code>
* join the <a href="Icecast users mailing list">http://lists.xiph.org/mailman/listinfo/icecast</a> (else the following step will fail!)
* send a mail to <a href="icecast@xiph.org">mailto:icecast@xiph.org</a> containing:
1. The public URL of your Icecast server - e.g. <code>http://icecast.example.org:8000/</code> (Even if you have removed the status pages! This does <strong>NOT</strong> mean your homepage.)
2. The <code>&lt;hostname&gt;</code>, <code>&lt;listen-socket&gt;</code> and <code>&lt;directory&gt;</code> sections of your <code>icecast.xml</code>
3. The <em>filtered</em> error.log prepared previously (as an attachment)
* wait for replies from the mailing list</p>
</div>
</div>
<div class="footer">
<p><a href="https://plus.google.com/100957455777699991449/about">
<img alt="Google+" title="Find uns on Google+" src="/assets/img/google-plus.svg" style="width: 20px;">
</a>
</p>
<p>&copy; 2004-2014 Xiph.Org. All rights reserved.</p>
<p>Support icecast development at <a href="http://icecast.org">icecast.org</a></p>
</div>