Icecast - Nov 2008 - reloading configuration in icecast chroot jail on a redhat system

Hi,

Over the weekend I decided to create an icecast relay for Nicecast. I wanted
this to run in a
chroot jail on a redhat server. There did not seem to be much on the web
about  setting this up;
I'm including some details here. This is my first encounter with icecast;
I'm  hoping to
elicit comments and criticism (e.g., if my post is too long).

First, there did not seem to be a startup script for Red Hat compatible with
chkconfig, much less
such a script with a reload section; I include mine. This handles reloading
the configuration--I'm
wondering if there is a better way to do this.

Also, I have another problem: I want an off the air loop to play exactly
once, after which the
user is disconnected. However, the loop plays indefinitely.

First, here is the startup script (I call this icectl); my configuration
chroots icecast to
/usr/local/share/icecast. The relevant case is reload)

!/bin/sh
#
#
# chkconfig: 2345 70 40
# description: icecast startup script
#
ICECAST=/usr/local/bin/icecast
ICECONFIG=/usr/local/etc/icecast.xml
ICEPIDFILE=/usr/local/share/icecast/icecast.pid

. /etc/rc.d/init.d/functions

RETVAL=0

case "$1" in
   start)
      echo -n "Starting icecast: "
      [ -f $ICECAST ] || exit 1
      [ -f $ICECONFIG ] || exit 1

      daemon --pidfile=$ICEPIDFILE $ICECAST -b -c $ICECONFIG > /dev/null
      RETVAL=$?
      echo
      [ $RETVAL -eq 0 ] && touch /var/lock/subsys/icecast
        ;;

  stop)
      echo -n "Shutting down icecast: "
      killproc -p $ICEPIDFILE $ICECAST
      RETVAL=$?
      echo
      [ $RETVAL -eq 0 ] && rm -f /var/lock/subsys/icecast
        ;;

  restart)
        $0 stop
        $0 start
        RETVAL=$?
        ;;

  reload)
        echo -n "Reloading icecast configuration: "
        killproc -p $ICEPIDFILE $ICECAST -HUP
        RETVAL=$?
        echo
        ;;

  status)
        status -p $ICEPIDFILE icecast
        RETVAL=$?
        ;;
  *)
        echo "Usage: $0 {start|stop|restart|reload|status}"
        exit 1
esac

exit $RETVAL

The first problem I had with the reload function is that the location of
the configuration file, /usr/local/etc/icecast.xml, is inaccessible
once the process is chrooted. I resolved this by moving the configuration
file to /usr/local/share/icecast/usr/local/etc/icecast.xml and setting a
symbolic
link to this in /usr/local/etc/. This enabled the icecast process to read
the
configuation on startup, and subsequently relative to the jail root of
/usr/local/share/icecast.

The next problem was that /etc/mime.types was inaccessible after a reload,
but this was fixed by copying this file to /usr/local/share/icecast/etc.
Before adding the mime.types, the /usr/local/share/icecast/etc directory
contained

[root at myhost etc]# ls -latrs
total 56
8 -rw-r--r-- 1 nobody nogroup  113 Nov  1 21:08 resolv.conf
8 -rw-r--r-- 1 nobody nogroup   38 Nov  1 21:28 passwd
8 -rw-r--r-- 1 nobody nogroup   17 Nov  1 21:28 group
8 -rw-r--r-- 1 nobody nogroup 1693 Nov  1 21:42 nsswitch.conf
8 drwxr-xr-x 9 nobody nogroup 4096 Nov  1 21:50 ..
8 -rw-r--r-- 1 nobody nogroup  607 Nov  1 21:58 hosts
8 drwxr-xr-x 2 nobody nogroup 4096 Nov  1 21:58 .

Where the files were edited to contain (close to) the minimum necessary.
For example, passwd and group were obtained with
  getent passwd nobody > passwd
  getent group  nogroup > group
and nsswitch.conf had all references to ldap removed.

/etc/hosts was copied to /usr/local/share/icecast/etc/hosts, and most
entries were removed; however I added an entry for dir.xiph.org. No doubt
I did not completely populate my chroot jail with all the needed libraries,
since
I seemed to need this hosts file entry for the lookup to succeed.


The lib directory was populated using the ldd command to locate
needed libraries; symbolic links were added as needed

[root at myhost etc]# ldd /usr/local/bin/icecast libcurl.so.2 =>
/opt/grid/prima
/lib/libcurl.so.2 (0x00002b3811c8b000)
        libssl.so.6 => /lib64/libssl.so.6 (0x0000003a01200000)
        libcrypto.so.6 => /lib64/libcrypto.so.6 (0x00000039fc400000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00000039f4400000)
        libvorbis.so.0 => /usr/lib64/libvorbis.so.0 (0x00000039f5800000)
        libxslt.so.1 => /usr/lib64/libxslt.so.1 (0x0000003d14400000)
        libxml2.so.2 => /opt/grid/apache/lib/libxml2.so.2
(0x00002b3811ed4000)
        libz.so.1 => /usr/lib64/libz.so.1 (0x00000039f4c00000)
        libm.so.6 => /lib64/libm.so.6 (0x00000039f4000000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00000039f4800000)
        libc.so.6 => /lib64/libc.so.6 (0x00000039f3c00000)
        libogg.so.0 => /usr/lib64/libogg.so.0 (0x00002b381227e000)
        libgssapi_krb5.so.2 => /usr/lib64/libgssapi_krb5.so.2
(0x00000039ff6000
00)
        libkrb5.so.3 => /usr/lib64/libkrb5.so.3 (0x00000039fc800000)
        libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00000039f9000000)
        libk5crypto.so.3 => /usr/lib64/libk5crypto.so.3 (0x00000039fb000000)
        /lib64/ld-linux-x86-64.so.2 (0x00000039f3800000)
        libkrb5support.so.0 => /usr/lib64/libkrb5support.so.0
(0x00000039ffa000
00)
        libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00000039fee00000)
        libresolv.so.2 => /lib64/libresolv.so.2 (0x00000039fa000000)
        libselinux.so.1 => /lib64/libselinux.so.1 (0x00000039f5400000)
        libsepol.so.1 => /lib64/libsepol.so.1 (0x00002b3812487000)

The libraries were copied with

for file in $(ldd /usr/local/bin/icecast | awk '{print $3}'); do
        cp $file lib;
done


For name resolution, additional libraries were needed in lib

  cp /lib/libnss_files-2.5.so .
  ln -s libnss_files-2.5.so libnss_files.so.2

  cp /lib/libnss_dns-2.5.so .
  ln -s libnss_dns-2.5.so libnss_dns.so.2

I may need to include directories for locales since the time logged is in
UTC.

This whole procedure follows the typical thing one does for jailing apache
or bind.

-----------------------------------------------------------------------

Now with the reload function working in the chroot jail, I was able to
experiment
with changing the icecast.xml configuration without restarting the server
and breaking
connections.

But, the following <mount> sections in my icecast.xml configuration left
me
with
the mount point OffTheAir.mp3 looping indefinitely

<mount>
        <mount-name>/listen</mount-name>
        <!-- Not known how to avoid an infinite loop
             with a short fallback mount. Setting
             max-listener-duration did not work
          -->
        <fallback-mount>OffTheAir.mp3</fallback-mount>
        <fallback-override>1</fallback-override>
        <intro>/intro.mp3</intro>
    </mount>

    <mount>
        <mount-name>/OffTheAir.mp3</mount-name>
        <max-listener-duration>3</max-listener-duration>
        <hidden>1</hidden>
    </mount>


I wanted the fallback mountpoint to play once, and then disconnect the user.
However, the  <max-listener-duration> parameter seems to work only for
connections directly to the OffTheAir.mp3 mountpoint, but not if this is
the fallback mountpoint.

Thanks for bearing with me.

FL
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.xiph.org/pipermail/icecast/attachments/20081102/1a342253/attachment.htm

FL wrote:
> Also, I have another problem: I want an off the air loop to play exactly
> once, after which the
> user is disconnected. However, the loop plays indefinitely.
hmmm.  You could achieve this using aliases I guess.  You could have an 
alias that pointed to the stream when it is up and to your off the air 
message when it isn't, and have on-connect and on-disconnect events be 
scripts to make the appropriate changes and reload the config.

Geoff.

How would that be implemented?  What is the syntax for using an alias in
icecast
to point to a stream? How do you detect when it is up?

The kind of fallback message I would like would be an announcement when
the next scheduled program would run...

In any case, I have noticed that <max-listener-duration> works in a mount
point
that the user connects to directly, and not through the fallback-mount
mechanism.
A <play-once-then-disconnect> tag would be nice (defaulted to 0 for all
mount
points); and unlike <max-listener-duration>, this should work even for a
<fallback-mount>. Perhaps I should consider modifying the source.

Loading alternate config files when the main stream disconnects does not
sound as if it would scale very well...

On Mon, Nov 3, 2008 at 3:46 AM, Geoff Shang <Geoff at quitelikely.com>
wrote:
> FL wrote:
>
> > Also, I have another problem: I want an off the air loop to play
exactly
> > once, after which the
> > user is disconnected. However, the loop plays indefinitely.
>
> hmmm.  You could achieve this using aliases I guess.  You could have an
> alias that pointed to the stream when it is up and to your off the air
> message when it isn't, and have on-connect and on-disconnect events be
> scripts to make the appropriate changes and reload the config.
>
> Geoff.
>
> _______________________________________________
> 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/20081103/47d98e4d/attachment-0001.htm