[Asterisk-Users] vserver (Debian) - no tty: howto use /usr/sbin/safe_asterisk with "-c" for color CLI?

[Tzafrir Cohen]

On Sat, Jul 08, 2006 at 12:34:42PM +0200, Robert Michel wrote:
> Salve Tzafrir, *!
> 
> Thank you for your kindly (and good) support. :)
> 
> I found a solution for me to get a colored CLI on a
> vserver, but to publish it for other *-users,
> I feel it must be smarter ;)
> 
> On Tue, 04 Jul 2006, Tzafrir Cohen wrote:
> > safe_asterisk has a flawed logic: it assumes that the tty device will
> > always exist. Thus it is not suited for use with screen.
> > 
> > However wouldn't it be better to tell asterisk to have colors even in a
> > remote terminal unless you use -n?
> 
> On the longterm this is interesting, thank you for the patch,
> I will test it in the next time...
> But I do have a more general aim, to find a solution to 
> to cope with the restriction of vserver that root at guest
> can't create new terminals with mknode.
> 
> I personaly could life with an asterisk patch, or manualy
> solution that works only until the next crash - but I'm
> keen to find and promote a solution that would also help
> vserver usersers in other cases and that would be working
> without the support of root at host, the vserver provider.
> 
> root at guest := root of one vserver (guest)
> root at host  := root/admin of the sytem that serve the
>               different vserver instances
> 
> 
> On the vserer mailinglist I do also have a discussion
> with Herbert Poetzl (vsever developer) and I wrote
> to that list:
> 
>  Well I like the "one task, one tool" philosophy,
>  or just the slogan "Devide et impera!" So I'm not
>  happy with the need to modificate asterisk scripts 
>  or binary to run on a vserver.... remember in May
>  someone ask here on the list for the power to
>  create a fix terminal to use with perl.

Right. Don't use safe_asterisk . asterisk daemonises just fine on its
own. asterisk -r gives you a nice console. If you want a complete trace,
you have the logs at your disposal: take a visit at logger.conf.

> 
>  But you are right, there are options for root at guest
>  to work around. My skripting skills are not so high
>  and my try would be better inside the asterisk scripts
>  for shure - but I'm looking for a solution that is
>  indepentend of the task - finaly it should be
>  a skript/demon that request a pseudo terminal
>  and link this to a fix /dev/tty$n ($n choosen by
>  root at guest). 
>  The most perfect solution would be maybe, when
>  this pseudotty process take care that his "device"
>  exist and if not, that it is created again.
> 
>  ############################################
>  Howto creat a /dev/tty9 on a vserver without
>  the right to use mknode,
>  proposed by news at robertmichel.de 2006.07.07
>  ############################################
> 
>  Create two files:
>     /dev/init.d/pseudo-tty9
>     #!/usr/bin/expect -f
>     # Some software likes to have an own terminal
>     # but no function to request a pseudo terminal.
>     # On some vservers exist no or not enough 
>     # tty devices, and root at guest does not have the
>     # power to create some with mknode.
>     # The idea of this script is to run a bash
>     # as the user asterisk and detach it.
>     #
>     # expect "#" and "$" are part of the promt ;)2006
>     # 2006.07.07 by news at RobertMichel.de
> 
>     spawn dtach -A /tmp/pseudoterm.socket.9 -e a bash
>     expect "#" { send "/etc/init.d/pseudo-tty9-ln.sh\r" }
>     expect "#" { send "su - asterisk\r" } 
>     expect "$" { send "a" }
>     #EOF
> 
>  And:
>     /etc/init.d/pseudo-tty9-ln.sh
>     #!/bin/bash
> 
>     ln -sf $(tty) /dev/tty9
>     #EOF
> 
>  and run then:
>      update-rc.d -n pseudotty9 defaults
>  as well as:
>      /dev/init.d/pseudo-tty9
> 
>  ############################################
> 
> 
>  I seems to work, but it is not smart to have
>  2 files, and no automaticaly restory in case
>  something crash.
>  - what would be smarter then run a bash?
> 
> 
>  Maybe some others here on the list does have
>  ideas and tips ;)

You've just added quite a few more points of failure to Asterisk and
complicated thinhgs even further. Why bother using safe_sterisk?

-- 
Tzafrir Cohen      sip:tzafrir at local.xorcom.com
icq#16849755       iax:tzafrir at local.xorcom.com
+972-50-7952406           
tzafrir.cohen at xorcom.com  http://www.xorcom.com