Difference between revisions of "Trixbox"

From TD-er's Wiki
Jump to navigationJump to search
 
(10 intermediate revisions by 4 users not shown)
Line 1: Line 1:
 
[http://www.trixbox.org/ Tribox homepage]
 
[http://www.trixbox.org/ Tribox homepage]
  
 +
[[Links#Trixbox_links|Trixbox related links]]
 +
 +
==The Limitations of TrixBox==
 +
([http://www.packtpub.com/trixbox/book Source, sample chapters, p.34])
 +
 +
Die-hard Asterisk purists will insist that by using TrixBox we are seriously crippling the abilities of the system. The reality is that we can do almost anything with a TrixBox installation just as we can with a bare Asterisk installation. The main limitation we have is that FreePBX requires a specific layout of configuration files, and any hand editing could be overwritten or could break the FreePBX interface.
 +
 +
TrixBox also locks us down to one machine. When it comes to having multiple machines handling our telephony, it can be difficult to migrate from TrixBox to multiple Asterisk boxes as the TrixBox interface only allows for single machine architecture. This can be manageable as long as the administrators configuring the telephone system are aware of the need to log in to multiple interfaces in order to make changes. As the telephony infrastructure and required capacity grows, it can become quite difficult to manage. It's worth considering moving directly to multiple Asterisk systems rather than trying to run concurrent TrixBox systems.
 +
 +
Basically, as our needs grow towards those of a large business TrixBox becomes less useful to us. However, for small and medium businesses it can perform well and meet most needs, from small shops to busy call centres.
  
 
== Running Trixbox in VMware on Windows ==
 
== Running Trixbox in VMware on Windows ==
Line 11: Line 21:
  
 
=== Things to know ===
 
=== Things to know ===
−
 
−
*** document the startup of VMware ***
 
  
 
Once the Trixbox Linux is up and running, the following things hold:
 
Once the Trixbox Linux is up and running, the following things hold:
Line 22: Line 30:
 
* Each instance of VMware player running this version of Trixbox will take on average about 250 MB of RAM.
 
* Each instance of VMware player running this version of Trixbox will take on average about 250 MB of RAM.
 
* Each VMware image of this version of Trixbox needs about 1.66 GiB of hard disk space. This can increase up to a max. of 7.3 GiB (max size of virtual filesystem + 256 MiB VMEM-file) The VMware-images can be compressed for transport to about 570 - 600 MB
 
* Each VMware image of this version of Trixbox needs about 1.66 GiB of hard disk space. This can increase up to a max. of 7.3 GiB (max size of virtual filesystem + 256 MiB VMEM-file) The VMware-images can be compressed for transport to about 570 - 600 MB
−
 
+
* The GUI can be used to configure TrixBox. Remember to enable the necessary modules (at least '''core'''). This can be done through '''FreePBX -> Tools -> Module Administration'''.
−
 
+
* Extensions can now be added under '''FreePBX -> Setup'''
  
 
=== Editors ===
 
=== Editors ===
Line 29: Line 37:
 
The config files of Asterisk are located in /etc/asterisk/
 
The config files of Asterisk are located in /etc/asterisk/
  
 +
These can be edited through the GUI (in administrator mode) under '''Asterisk -> ConfigEdit'''.
 +
 +
If you don't want or can't do it online:
 
Editing those files with the installed editor vi, is rather tedious. Therefore we installed Emacs to do the editing.
 
Editing those files with the installed editor vi, is rather tedious. Therefore we installed Emacs to do the editing.
 
Since Trixbox is based on CentOS, it is possible to use the CentOS RPM's to install Emacs.
 
Since Trixbox is based on CentOS, it is possible to use the CentOS RPM's to install Emacs.
Line 139: Line 150:
 
As far as we know, such NAT configuration does '''not''' ''forward'' any connection to the TrixBox running within VMware, therefore at this moment this solution doesn't allow any incoming connection.
 
As far as we know, such NAT configuration does '''not''' ''forward'' any connection to the TrixBox running within VMware, therefore at this moment this solution doesn't allow any incoming connection.
  
−
=== Update (29/01/2007) ===
+
=== NAT - Update (29/01/2007) ===
  
 
Further investigation made us discover a quite complex situation.
 
Further investigation made us discover a quite complex situation.
Line 243: Line 254:
 
In this case the virtual machine has the ip 192.168.5.128 and a series op network port are mapped to it; unfortunately it doesn't seem to work:
 
In this case the virtual machine has the ip 192.168.5.128 and a series op network port are mapped to it; unfortunately it doesn't seem to work:
 
* from the outside world it is not possible to open any connection towards the TrixBox, i.e. not by usig the real machine's ip and port 8888 nor using the "VMware router" at adress 192.168.5.2 and port 8888
 
* from the outside world it is not possible to open any connection towards the TrixBox, i.e. not by usig the real machine's ip and port 8888 nor using the "VMware router" at adress 192.168.5.2 and port 8888
−
* from the local Linux OS it is possible to connect to the TrixBox through it's ip; this is not sufficient as it's not possible to connect from ''another'' machine.
+
* from the local Linux OS it is possible to connect to the TrixBox through its ip; this is not sufficient as it's not possible to connect from ''another'' machine.
  
−
== Network Bridging ==
+
=== Network Bridging ===
  
 
The other main way to provide network connectivity to the virtual TrixBox is to set up VMware using ''Bridging''.
 
The other main way to provide network connectivity to the virtual TrixBox is to set up VMware using ''Bridging''.
Line 253: Line 264:
 
A solution is to assign a new free ip address to the virtual TrixBox (ofcourse, this needs to be done in ''agreement'' with the network administrator/policy ('''!''') ). In this case, the virtual TrixBox can also play as ''gateway'' for itself.
 
A solution is to assign a new free ip address to the virtual TrixBox (ofcourse, this needs to be done in ''agreement'' with the network administrator/policy ('''!''') ). In this case, the virtual TrixBox can also play as ''gateway'' for itself.
 
This enables full communication to the Virtual TrixBox from and to the host machine '''and''' the outside world.
 
This enables full communication to the Virtual TrixBox from and to the host machine '''and''' the outside world.
 +
 +
This is the used network configuration file:
 +
 +
[root@asterisk1 ~]# cat /etc/sysconfig/network-scripts/ifcfg-eth0
 +
DEVICE=eth0
 +
ONBOOT=yes
 +
BOOTPROTO=static
 +
IPADDR=129.125.21.240
 +
NETMASK=255.255.0.0
 +
GATEWAY=129.125.21.240

Latest revision as of 12:16, 6 March 2007

Tribox homepage

Trixbox related links

The Limitations of TrixBox

(Source, sample chapters, p.34)

Die-hard Asterisk purists will insist that by using TrixBox we are seriously crippling the abilities of the system. The reality is that we can do almost anything with a TrixBox installation just as we can with a bare Asterisk installation. The main limitation we have is that FreePBX requires a specific layout of configuration files, and any hand editing could be overwritten or could break the FreePBX interface.

TrixBox also locks us down to one machine. When it comes to having multiple machines handling our telephony, it can be difficult to migrate from TrixBox to multiple Asterisk boxes as the TrixBox interface only allows for single machine architecture. This can be manageable as long as the administrators configuring the telephone system are aware of the need to log in to multiple interfaces in order to make changes. As the telephony infrastructure and required capacity grows, it can become quite difficult to manage. It's worth considering moving directly to multiple Asterisk systems rather than trying to run concurrent TrixBox systems.

Basically, as our needs grow towards those of a large business TrixBox becomes less useful to us. However, for small and medium businesses it can perform well and meet most needs, from small shops to busy call centres.

Running Trixbox in VMware on Windows

Screenshot VMware Trixbox.png

Download:

VMware player (free)

Things to know

Once the Trixbox Linux is up and running, the following things hold:

  • The default root-password is "password".
  • Entering the VMware console is done by clicking on it. Leaving is done by pressing CTRL + Alt at the same time.
  • When opening the VMware configuration-file in VMware player, you probably get some warnings about the location of your CDrom drive. This can be ignored. (no CDrom is needed)
  • Using the latest version of VMware player, the hardware-detection will detect a change of network card. Please select "Keep configuration" and in the next screen enter the right IP-configuration (needed only once)
  • Each instance of VMware player running this version of Trixbox will take on average about 250 MB of RAM.
  • Each VMware image of this version of Trixbox needs about 1.66 GiB of hard disk space. This can increase up to a max. of 7.3 GiB (max size of virtual filesystem + 256 MiB VMEM-file) The VMware-images can be compressed for transport to about 570 - 600 MB
  • The GUI can be used to configure TrixBox. Remember to enable the necessary modules (at least core). This can be done through FreePBX -> Tools -> Module Administration.
  • Extensions can now be added under FreePBX -> Setup

Editors

The config files of Asterisk are located in /etc/asterisk/

These can be edited through the GUI (in administrator mode) under Asterisk -> ConfigEdit.

If you don't want or can't do it online: Editing those files with the installed editor vi, is rather tedious. Therefore we installed Emacs to do the editing. Since Trixbox is based on CentOS, it is possible to use the CentOS RPM's to install Emacs.

The 2 RPM's needed for Emacs are located at the following URL's: 

ftp://ftp.nluug.nl/pub/os/Linux/distr/CentOS/4.4/os/i386/CentOS/RPMS/emacs-common-21.3-19.EL.4.i386.rpm
ftp://ftp.nluug.nl/pub/os/Linux/distr/CentOS/4.4/os/i386/CentOS/RPMS/emacs-nox-21.3-19.EL.4.i386.rpm

Using the program wget, it is possible to download these. After downloading, the RPM's can be installed with "rpm -i". We also created some smaller URL's, which is easier to type ;) 

mkdir install
cd install
wget http://turl.nl/99
wget http://turl.nl/100
rpm -i emacs-common-21.3-19.EL.4.i386.rpm
rpm -i emacs-nox-21.3-19.EL.4.i386.rpm

The name of the emacs-executable is "emacs-nox"

Another possibility is simply to use the YUM package manager: 

[root@asterisk1 ~]# yum install emacs-nox

Connecting with the Trixbox-shell

It is possible to use the Trixbox shell via VMware (player), but this has one mayor disadvantage. You can't use cut 'n paste. However, it is also possible to interface over a SSH connection, using e.g. Putty. The IP-adress of the Trixbox installation is given at the login (using VMware).

To log in, the standard root-password is "password".

Running Trixbox in VMware on Linux

In the following we assume that the VMware image of TrixBox has already been downloaded to some directory, for instance 

/home/scratch

First of all, VMware needs to be launched from the command-line 

csg9101@wingtip114 [~/bin] : vmware &

After a while VMware will be up and running. Then the next step is to select open an existing Virtual Machine:

VMware-VM selection.png

At this point, the CentOS TrixBox system will boot. Eventually a Linux login shell will appear.

Networking - NAT

TrixBox starts up with a default network configuration based on IPv6; this won't work in most cases. To remedy this it is necessary to log in on the TrixBox as root and to configure the network subsystem.

This configuration is two-fold: on the VMware side it is necessary to set up network routing, as documented at network_configure_ws.

In our case, the present network is tightly configured by DHCP in such a way that using an IP in the same range as the machine's IP is not an option and other IP's are ignored. Therefore Network bridging isn't an option; we use NAT instead.

Hereby we have to set up NAT conforming to the parameters which are set up in the following VMware config file (/etc/vmware/vmnet8/nat/nat.conf.) 

# Linux NAT configuration file
[host]
# NAT gateway address 
ip = 192.168.5.2
netmask = 255.255.255.0
# or ip = 192.168.5.2/24

# enable configuration; disabled by default for security reasons
#configport = 33445

# VMnet device if not specified on command line
device = /dev/vmnet8

# Allow PORT/EPRT FTP commands (they need incoming TCP stream...)
activeFTP = 1

# Allows the source to have any OUI.  Turn this one if you change the OUI
# in the MAC address of your virtual machines.
#allowAnyOUI = 1

[udp]
# Timeout in seconds, 0 = no timeout, default = 60; real value might
# be up to 100% longer
timeout = 60

[incomingtcp]
# Use these with care - anyone can enter into your VM through these...

# FTP (both active and passive FTP is always enabled)
#      ftp localhost 8887
#8887 = 192.168.5.128:21

# WEB (make sure that if you are using named webhosting, names point to
#     your host, not to guest... And if you are forwarding port other
#     than 80 make sure that your server copes with mismatched port 
#     number in Host: header)
#      lynx http://localhost:8888
#8888 = 192.168.5.128:80

# SSH
#      ssh -p 8889 root@localhost
#8889 = 192.168.5.128:22

[incomingudp]
# UDP port forwarding example
#6000 = 192.168.5.128:6001

On the TrixBox side the networking infrastructure should happen according to network_nat_advanced_gsx; the new network parameters can be applied through the command 

netconfig

For further details see TrixBox Network configuration.

As far as we know, such NAT configuration does not forward any connection to the TrixBox running within VMware, therefore at this moment this solution doesn't allow any incoming connection.

NAT - Update (29/01/2007)

Further investigation made us discover a quite complex situation.

First of all, in the Linux installation VMware creates a couple of devices, namely 

eth0      Link encap:Ethernet  HWaddr 00:0E:7F:FB:0A:25
          inet addr:129.125.21.161  Bcast:129.125.21.255  Mask:255.255.255.0
          inet6 addr: fe80::20e:7fff:fefb:a25/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:219478 errors:0 dropped:0 overruns:0 frame:0
          TX packets:172723 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:94422484 (90.0 MiB)  TX bytes:54367351 (51.8 MiB)
          Interrupt:16

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:465 errors:0 dropped:0 overruns:0 frame:0
          TX packets:465 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:47236 (46.1 KiB)  TX bytes:47236 (46.1 KiB)

vmnet1    Link encap:Ethernet  HWaddr 00:50:56:C0:00:01
          inet addr:192.168.7.1  Bcast:192.168.7.255  Mask:255.255.255.0
          inet6 addr: fe80::250:56ff:fec0:1/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

vmnet8    Link encap:Ethernet  HWaddr 00:50:56:C0:00:08
          inet addr:192.168.5.1  Bcast:192.168.5.255  Mask:255.255.255.0
          inet6 addr: fe80::250:56ff:fec0:8/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)


NAT translation is merely performed on the ip address where interface vmnet8 is listening to. For some reason even a manipulated VMware configuration file (/etc/vmware/vmnet8/nat/nat.conf) doesn't realize the port-forwards which are needed to reach the TrixBox virtual machine; the used configuration is 

csg9101@wingtip114 [~] : cat /home/scratch/trixbox\ 2.0/nat.conf
# Linux NAT configuration file
[host]
# NAT gateway address
ip = 192.168.5.2
netmask = 255.255.255.0
# or ip = 192.168.5.2/24

# enable configuration; disabled by default for security reasons
#configport = 33445

# VMnet device if not specified on command line
device = /dev/vmnet8

# Allow PORT/EPRT FTP commands (they need incoming TCP stream...)
activeFTP = 1

# Allows the source to have any OUI.  Turn this one if you change the OUI
# in the MAC address of your virtual machines.
#allowAnyOUI = 1

[udp]
# Timeout in seconds, 0 = no timeout, default = 60; real value might
# be up to 100% longer
timeout = 60

[incomingtcp]
# Use these with care - anyone can enter into your VM through these...

# FTP (both active and passive FTP is always enabled)
#      ftp localhost 8887
8887 = 192.168.5.128:21

# WEB (make sure that if you are using named webhosting, names point to
#     your host, not to guest... And if you are forwarding port other
#     than 80 make sure that your server copes with mismatched port
#     number in Host: header)
#      lynx http://localhost:8888
8888 = 192.168.5.128:80

# SSH
#      ssh -p 8889 root@localhost
8889 = 192.168.5.128:22

[incomingudp]
# UDP port forwarding example
#6000 = 192.168.5.128:6001

# IAX1 - port forward for the obsolete IAX ver 1 protocol
#        essential for trixbox/asterisk
4569 = 192.168.5.128:4569

# IAX2 - port forward for the IAX ver 2 protocol
#        essential for trixbox/asterisk
5036 = 192.168.5.128:5036

In this case the virtual machine has the ip 192.168.5.128 and a series op network port are mapped to it; unfortunately it doesn't seem to work:

  • from the outside world it is not possible to open any connection towards the TrixBox, i.e. not by usig the real machine's ip and port 8888 nor using the "VMware router" at adress 192.168.5.2 and port 8888
  • from the local Linux OS it is possible to connect to the TrixBox through its ip; this is not sufficient as it's not possible to connect from another machine.

Network Bridging

The other main way to provide network connectivity to the virtual TrixBox is to set up VMware using Bridging. According to the VMware documentation, this should happen by selecting Bridging among the network interface properties in the VMware System Console. Moreover, the virtual OS should copy the host OS's ip. This of course generates a ip address conflict, hampering the virtual system's connectivity. The official workaround is to allow duplicate ip's, but unfortunately the documentation doesn't provide a clear way to configure this and no particular option is provided by the VMware System Console's UI.

A solution is to assign a new free ip address to the virtual TrixBox (ofcourse, this needs to be done in agreement with the network administrator/policy (!) ). In this case, the virtual TrixBox can also play as gateway for itself. This enables full communication to the Virtual TrixBox from and to the host machine and the outside world.

This is the used network configuration file: 

[root@asterisk1 ~]# cat /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0
ONBOOT=yes
BOOTPROTO=static
IPADDR=129.125.21.240
NETMASK=255.255.0.0
GATEWAY=129.125.21.240
Retrieved from "https://wiki.td-er.nl/index.php?title=Trixbox&oldid=2210"