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

[Robert Michel]

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.

 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 ;)


This workaround is running on my vserver and I
personal did not need any help - but again, I'm
keen to find a smart solution in general for
this topic and I think my solution is not 
smart engough to give it away for others how
to cope with the restriction of vserers. ;)

I will go on playing with expect, how to merge it 
into one script and how to insert it into safe_asterisk.
And if I don't find the trick will ask other mailinglists
e.g. debian-users - BUT when someone of you like this 
topic and find a smart solution - I would be happy
about feedback :)


BTW: vserver - when you have the power to be root at host
     than linux-vserver.org worse IMHO look for you, too:

Herbert gave the hint on vserver mailinglist that 
there is a "project which uses Linux-VServer to isolate 
several asterisk instances on a single host":
"Virtual Private Asterisk (VPA"):
http://www.telephreak.org/papers/vpa/


And beside the interesst of security or to have more
instances on a single host, I think vserver could help 
you to move one asterisk installation to another machine,
or testing on the same machine - one extension could
become the gateway to the test system ;)

--8<--
[2]Linux-VServer-Paper-08
08. Field of Application

   The primary goal of this project is to create virtual servers sharing
   the same machine. A virtual server operates like a normal Linux
   server. It runs normal services such as telnet, mail servers, web
   servers, and SQL servers.
08.0. Administrative Separation [...]
08.1. Service Separation [...]
08.2. Enhancing Security [...]
08.3. Easy Maintenance

   One key feature of a virtual server is the independence from the
   actual hardware. Most hardware issues are irrelevant for a virtual
   server installation.

   The main server acts as a host and takes care of all the details. The
   virtual server is just a client and ignores all the details. As such,
   the client can be moved to another physical server with very few
   manipulations.

   For example, to move the virtual server from one physical computer to
   another, it sufficient to do the following:
     * shutdown the running server
     * copy it over to the other machine
     * copy the configuration
     * start the virtual server on the new machine

   No adjustments to user setup, password database or hardware
   configuration are required, as long as both machines are binary
   compatible.

08.4. Fail-over Scenarios

   Pushing the limit a little further, replication technology could be
   used to keep an up-to-the-minute copy of the filesystem of a running
   Virtual Server. This would permit a very fast fail-over if the running
   server goes offline for whatever reason.

   All the known methods to accomplish this, starting with network
   replication via rsync, or drbd, via network devices, or shared disk
   arrays, to distributed filesystems, can be utilized to reduce the
   down-time and improve overall efficiency.

08.5. For Testing [...]
-->8--
   2. http://linux-vserver.org/?action=find&find=Linux-VServer-Paper-08
And of course: http://linux-vserver.org/ 


Have a nice weekend,
rob





PS: Thanks to the guy who had run his autorespond
    "I'm out of the office" against this mailinglist.
    I think this is the reason why I missed some mails
    and had to ask my friend to forward me some, to get 
    the right sender ID for answering...