No /etc/init.d script

[Hynek Hanke]

Binary package hint: festival

In Ubuntu 10.10 Maverick there is no /etc/init.d script for Festival. Festival is on of the primary engines for accessibility for blind and visually handicapped. Blind people however can't use it in connection with Speech Dispatcher and Orca unless they have a way to actually start it in the required server mode.

I would expect to have an /etc/init.d/festival launch script and the appropriate rc.d entries after installing the 'festival' package as was the case in earlier versions of the package. This script can perhaps be switched off by default via /etc/defaults/.

This is festival 1:2.0.95~beta-2ubuntu1 from Ubuntu Maverick main repository.

[Charlie Kravetz (cjkgeek)]

Thank you for reporting this issue. However, I am closing this bug because to use festival for accessibility, it is normally run as part of another application. In Orca, for example, when festival is properly installed, there is an option to use either ESD or festival for the speech synthesis. Festival is not required to be started separately for use.

[Hynek Hanke (hanke-brailcom)]

No, this is not correct. The main speech backend for Orca is Speech Dispatcher. Speech Dispatcher currently requires Festival to run separately. That could be changed of course in the future if there is a good reason, but it requires some work as some Festival scheme functions behave differently when called remotely. So the whole chain is definitely broken now on Ubuntu with Festival. I can provide more information if necessary.

[Charlie Kravetz (cjkgeek)]

Thank you for correcting me. You are correct, festival does not start as expected without additional work. I am not sure a file in /etc/init.d is needed, but don't really know what is. It is possible a resolution to bug 209900 or bug 662630 would resolve this issue.

I am going to mark this confirmed, based on further testing in the latest development release, Natty Narwhal.

Again, thanks for helping improve Ubuntu. Please continue to report bugs as you find them.

[Hynek Hanke (hanke-brailcom)]

Hi Charlie, thanks for your work on this!

I don't think bugs 209900 and 662630 are an obstacle for having an /etc/init.d script for the following reasons:

1) It is not a major problem Festivals audio backend does not work in Ubuntu. In fact Festival should not even attempt to have such a backend. TTS system should just generate speech in an audio file or stream and it should be up to the target application to choose a way to play it. I would consider closing bugs 209900 and 662630 by simply deprecating these functionalities.

2) Speech Dispatcher just retrieves audio stream and then plays it using its own audio output subsystem, which is common for all available TTS systems.

3) Users who want to just synthesize and speak some text from command line should use spd-say instead of the synthesizers directly, developers who want to voice their applications should use SSIP (the Speech Dispatcher API) or one of the convenienece libraries, not contact the TTS system directly. This is also important for message coordination etc.

4) The above bugs are present whether festival is launched as a server or directly from commandline.

[Andreas Moog (ampelbein)]

The debian bug I just linked has pointers to discussion as to why the init scripts got removed. I think the reasons for doing so are still very good and the problems would outweigh the benefits. For those users who really need to start a server (and have a clear understanding of the security risk involved), there is a example init-script in the docs. I'm inclined to set this report to "Won't Fix".

[Josep Pujadas-Jubany (jpujades)]

12.04
orca uses speech-dispatcher and festival is not available unless you start it as a service.
After installing festival packages (speed-dispatcher-festival included) many steps must be done to have festival running with orca:

sudo install /usr/share/doc/festival/examples/festival.init /etc/init.d/festival
sudo update-rc.d festival defaults
sudo gedit /etc/default/festival
* Add the line RUN_FESTIVAL=yes
sudo /etc/init.d/festival start
* Or restart the computer

Next time you start orca you could select festival as voice engine.

[Josep Pujadas-Jubany (jpujades)]

NOT A BUG !!! DESIGN SECURITY PROBLEM !!!

Please see at /usr/share/doc/festival/changelog.Debian.gz

festival (1.96~beta-7) unstable; urgency=high

  * Do not start festival server by default.
    (Closes: #466796)
  * Revert use of debconf.
  * debian/festival.preinst:
    + Check for obsolete configuration files.
  * debian/{festival.init,festival.scm}: Now example files,
    documented with warnings about potential security
    issues by their use.
  * debian/README.Debian: Document server start details.

 -- Kumar Appaiah <email address hidden> Thu, 21 Feb 2008 09:40:52 +0530

And at /usr/share/doc/festival/examples/festival.init (Ubuntu 12.04 LTS) says:

# WARNING: It is inherently insecure to run a festival instance as a
# server, mainly because it exposes the whole system to exploits which
# can be easily used by attackers to gain access to your
# computer. This is because of the inherent design of the festival
# server. Please use it only in a situation where you are sure that
# you will not be subjected to such an attack, or have adequate
# security precautions.

I found this, also: http://www.securityfocus.com/bid/25069/discuss

This affects only local users who can escalate to root privileges. So, if you are (alone) using your own desktop, don't worry.

[Josep Pujadas-Jubany (jpujades)]

At job, one user needs to use gnome-orca + speech-dispatcher-festival + festival. He has Lubuntu 16.04 LTS 64 bit.

The solution for having festival in server mode (required for speech-dispatcher) is to go to:

Program Menu - Preferences - Default applications for LXSession - Autostart

and add the following command:

festival --server

Like this, festival starts at user level each time the user logs the graphical session.

[Sergio Oller (zeehio)]

And this "festival --server" is a very unsafe solution due to the design of festival server mode.
Any other local user will only need to use the command:

> telnet localhost 1314
> (system "ls")

Basically you are opening a user shell to anyone with access to localhost. This:

- Gives access to your shell to any other local user (which is dangerous if there are other users in your computer)

- Gives access to your shell to any malicious website you visit that uses a DNS rebinding attack (dangerous, unless you don't visit websites or you disable javascript).See https://security.stackexchange.com/questions/147175/is-http-to-localhost-safe

We need a better alternative to this "festival --server" solution. Festival was designed with speech synthesis research purposes in mind, not as a user robust TTS system.

[Luke Yelavich (themuso)]

Likely the best solution is for Speech Dispatcher to spawn its own instance of Festival, and the festival server to be extended/set up to communicate over a unix socket only accessible to the user who started Speech Dispatcher, as is done now between Speech Dispatcher clients and the Speech Dispatcher server.