SaruWiki - User contributions [en]

IMP - the Internet Messaging Program

2010-05-06T21:23:07Z

Insomnia:

== IMP ==
With Debian Lenny come standard, stable applications. The [http://www.horde.org/imp/ IMP webmail application] that is packaged for Debian is version 4.2. The quickest way to install IMP is
apt-get install imp4
With both ''horde3'' and a mailserver (e.g. [[E-mail_server_section|Postfix]]) completely installed and configured, no extra packages will get installed.

Before you configure IMP, you need to prepare file permissions for web configuration (this is a recurring theme for any horde3 application):
touch /etc/horde/imp4/conf.bak.php
chmod 777 /etc/horde/imp4/conf*.php
[[Image:Horde3-imp-setup-1.PNG|thumb|300px|Horde IPM4 configuration screen 1]]Now you can log in to horde3 web interface as a user with administrative rights. In the Horde3 tree view, choose Administration -> Setup -> '' Mail (imp) H3 (4.2)''' (see picture). This results in a configuration generation screen with something like 8 tabs; you could safely go with the defaults, but for lots of interesting special features you'll have to actively make a selection. Funny enough you do NOT select your mailserver(s) in this menu; that's left to manually editing another file (see further down).

Now generate your configuration. When you're done, you can change the permissions back for safety:
chmod 644 /etc/horde/imp4/conf.php
chmod 600 /etc/horde/imp4/conf.bak.php
Note that this also prevents you from changing the configuration with the web interface in the future. When you want to do that, you'll have to reset the permissions for the ''conf*.php'' files to 777, generate a new configuration, and then set the permissions back.

Note that if you DO NOT change the permissions to 644/600, then your IMP client will still run flawlessly. However, you now run a serious risk of a malicious web client altering your web mail configuration.

Time to specify your mail server(s) in ''/etc/horde/imp4/servers.php'' file. Depending on your mail server setup, your settings can be something like
$servers['imap'] = array(
'name' => 'IMAP Server',
'server' => 'localhost',
'hordeauth' => 'full',
'protocol' => 'imap/notls',
'port' => 143,
'maildomain' => 'saruman.biz',
'smtphost' => 'localhost',
'smtpport' => 25,
'realm' => 'sample.com',
'preferred' => '',
);

When you are ready, enable IMP in the file ''/etc/horde/horde3/registry.php'' and verify if all is right. Yes, you read well, you MUST enable manually module in registry.php file after configuration!

$this->applications['imp'] = array(
'fileroot' => '/usr/share/horde3/lib' . '/../imp',
'webroot' => $this->applications['horde']['webroot'] . '/imp',
'name' => _("Mail"),
'status' => 'active',
'provides' => array('mail', 'contacts/favouriteRecipients')
);

Change the status from inactive to active
== Ingo ==

#apt-get install ingo1

Register the application by editing /etc/horde/horde3/registry.php

Find the ingo stanza and change inactive to active
$this->applications['ingo'] = array(
'fileroot' => '/usr/share/horde3/lib' . '/../ingo',
'webroot' => $this->applications['horde']['webroot'] . '/ingo',
'name' => _("Filters"),
'status' => 'active',

Creating the database table

Login to the mysql database
mysql> source /usr/share/doc/ingo1/examples/scripts/sql/ingo.sql

change the group so apache can change the files
#chmod 774 /etc/horde/ingo1

Now login as a admin user in you're horde website. Goto administration - setup and klik on "Filters (ingo)"
Change the database to MYsql. Save the configuration and make you're rules

Mythtv

2010-04-30T19:58:44Z

Insomnia: /* VLC */

== lirc ==
LIRC CVS is hosted at SourceForge. You can get a copy of the current CVS tree using anonymous CVS login. First log in to the cvs server (press <enter> for password):
cvs -d:pserver:anonymous@lirc.cvs.sourceforge.net:/cvsroot/lirc login
Get the sources:
cvs -z8 -d:pserver:anonymous@lirc.cvs.sourceforge.net:/cvsroot/lirc co lirc
After initial checkout, you can change into this directory and execute cvs commands without the -d option. For example:
cvs update
Compile:
cd lirc
./autogen.sh
./setup.sh
make

Lirc will initiate the hardware with the below config file. In this case a mce usb receiver with a ir blaster and also a volume knob (Antec fusion)

# /etc/lirc/hardware.conf
#
#Chosen Remote Control
REMOTE="Windows Media Center Transceivers/Remotes (all)"
REMOTE_MODULES="lirc_dev lirc_mceusb2"
REMOTE_DRIVER=""
REMOTE_DEVICE="/dev/lirc1"
REMOTE_LIRCD_CONF="mceusb/lircd.conf.mceusb"
REMOTE_LIRCD_ARGS=""
#Chosen Remote Control
REMOTE="Windows Media Center Transceivers/Remotes (all)"
REMOTE_MODULES="lirc_dev lirc_imon"
REMOTE_DRIVER=""
REMOTE_DEVICE="/dev/lirc0"
REMOTE_LIRCD_CONF=""
REMOTE_LIRCD_ARGS=""
#Chosen IR Transmitter
TRANSMITTER="Microsoft Windows Media Center V2 (usb) : Direct TV Receiver"
TRANSMITTER_MODULES="lirc_dev lirc_mceusb2"
TRANSMITTER_DRIVER=""
TRANSMITTER_DEVICE="/dev/lirc1"
TRANSMITTER_SOCKET=""
TRANSMITTER_LIRCD_CONF=""
TRANSMITTER_LIRCD_ARGS=""
#Enable lircd
START_LIRCD="true"
#Don't start lircmd even if there seems to be a good config file
#START_LIRCMD="false"
#Try to load appropriate kernel modules
LOAD_MODULES="true"
# Default configuration files for your hardware if any
LIRCMD_CONF=""
FORCE_NONINTERACTIVE_RECONFIGURATION="false"
START_LIRCMD=""
REMOTE_SOCKET=""

/etc/lirc/lircd.conf

################################################################################
# lircd.conf file for the new Microsoft Media Center remote using a new
# Microsoft Media Center receiver.
################################################################################
begin remote

name mceusb
bits 16
flags RC6|CONST_LENGTH
eps 30
aeps 100

header 2667 889
one 444 444
zero 444 444
pre_data_bits 21
pre_data 0x37FF0
gap 105000
toggle_bit 22
rc6_mask 0x100000000

begin codes

# starts at A1
BLUE 0x00007BA1
YELLOW 0x00007BA2
GREEN 0x00007BA3
RED 0x00007BA4
TELETEXT 0x00007BA5
RADIO 0x00007BAF
PRINT 0x00007BB1
VIDEO 0x00007BB5 # VIDEOS button
IMAGE 0x00007BB6 # PICTURES button
PVR 0x00007BB7 # RECORDED TV button
AUDIO 0x00007BB8 # MUSIC button
TV 0x00007BB9
# no BA - D8
Guide 0x00007BD9
TV 0x00007BDA # LIVE TV button
Dvd 0x00007BDB
Back 0x00007BDC
OK 0x00007BDD
Right 0x00007BDE
Left 0x00007BDF
Down 0x00007BE0
Up 0x00007BE1
STAR 0x00007BE2
Hash 0x00007BE3
PREVIOUS 0x00007BE4 # REPLAY button
Next 0x00007BE5 # SKIP button
Stop 0x00007BE6
Pause 0x00007BE7
Record 0x00007BE8
Play 0x00007BE9
Rewind 0x00007BEA
Forward 0x00007BEB
CHANNELDOWN 0x00007BEC
CHANNELUP 0x00007BED
Volumedown 0x00007BEE
Volumeup 0x00007BEF
INFO 0x00007BF0 # MORE (i) button
Mute 0x00007BF1
MENU 0x00007BF2 # START (Windows) button
POWER 0x00007BF3
ENTER 0x00007BF4
CLEAR 0x00007BF5
9 0x00007BF6
8 0x00007BF7
7 0x00007BF8
6 0x00007BF9
5 0x00007BFA
4 0x00007BFB
3 0x00007BFC
2 0x00007BFD
1 0x00007BFE
0 0x00007BFF
end codes

end remote

Whit this config file lirc will listen on the devices and will translate the input. It will give a hardware name for the device and the button pressed.
irw wil give you a xample on the commandline
#irw
Now press some buttons

To feed the command to the appropiate program (if this program supports lirc) make a config in the home dir of the user.

~/.lirc/mythtv

begin
remote = ClickWheel
prog = mythtv
button = KEY_VOLUMEUP
config = ]
repeat = 0
delay = 0
end

begin
remote = ClickWheel
prog = mythtv
button = KEY_VOLUMEDOWN
config = [
repeat = 0
delay = 0
end

And the final piece of the puzzle and this was the hardest to find but the most simple thing to do. It seems that Lirc has it all figured out for the newest version on how to run multiple devices without major manual configuration EXCEPT the Lirc init.d script.

With my devices plugged in and issuing an ls -l /dev/lirc* I had all the devices I needed with manual configuration so

Code:

crw-rw---- 1 root root 61, 0 2010-02-21 11:44 /dev/lirc0
crw-rw---- 1 root root 61, 1 2010-02-21 11:44 /dev/lirc1
lrwxrwxrwx 1 root root 19 2010-02-21 11:44 /dev/lircd -> /var/run/lirc/lircd
lrwxrwxrwx 1 root root 20 2010-02-21 11:44 /dev/lircd1 -> /var/run/lirc/lircd

SEE the problem - /dev/lircd1 was pointing to /var/run/lirc/lircd so when issuing an irsend command from a script or a command line I was getting the hardware cannot send error. The actual fix I finally found in another post - THANK YOU TO cyber_source - YOU ARE A LIFE SAVER.

You need to edit your /etc/init.d/lirc startup script and change a couple lines

First Line 83 Needs to be changed from

"${TRANSMITTER_SOCKET}1" to this - "${TRANSMITTER_SOCKET}"

and then line 131 Needs to be changed from

TRANSMITTER_SOCKET="/var/run/lirc/lircd" to this TRANSMITTER_SOCKET="/var/run/lirc/lircd1"

save and exit the file reboot your system and run another
ls -l /dev/lirc* and you should see

Code:

crw-rw---- 1 root root 61, 0 2010-02-21 11:44 /dev/lirc0
crw-rw---- 1 root root 61, 1 2010-02-21 11:44 /dev/lirc1
lrwxrwxrwx 1 root root 19 2010-02-21 11:44 /dev/lircd -> /var/run/lirc/lircd
lrwxrwxrwx 1 root root 20 2010-02-21 11:44 /dev/lircd1 -> /var/run/lirc/lircd1

== IRblaster ==

To get the right codes from youre remote you can record it with irrecord. This will provide a configuration file which you can use in lirc
#irrecord /tmp/remote.conf
Now follow the instructions
To get the raw codes
#irrecord -f /tmp/remoteraw.conf

You wil get this file for a topfield tf6000cok remote
# Please make this file available to others
# by sending it to <lirc@bartelmus.de>
#
# this config file was automatically generated
# using lirc-0.8.6(default) on Wed Mar 24 20:58:54 2010
#
# contributed by
#
# brand:Topfield
# model no. of remote control: TP-014
# devices being controlled by this remote: Topfield TF6000COK
#

begin remote

name topfield
flags RAW_CODES|CONST_LENGTH
eps 30
aeps 100

gap 107620

begin raw_codes

name KEY_1
9000 4450 600 500 650 450
650 1650 600 500 600 500
650 500 600 500 600 500
650 1600 650 1600 600 1650
600 1650 600 1650 600 1650
600 1600 650 1600 600 1650
600 550 600 500 600 500
600 1650 600 550 550 550
600 500 650 500 600 1650
600 1650 600 1600 600 550
600 1650 550 1650 650 1650
550

name KEY_2
9050 4400 600 500 650 500
600 1650 600 500 600 500
650 500 600 500 600 500
650 1650 600 1600 600 1650
600 1650 600 1650 600 1650
600 1650 600 1600 600 550
600 1650 600 500 600 500
650 1600 600 550 600 500
600 550 600 1600 600 550
600 1650 550 1650 650 500
600 1650 600 1650 600 1600
600

name KEY_3
9000 4450 600 500 650 500
600 1600 650 500 600 500
600 550 600 500 600 550
600 1600 600 1650 650 1600
600 1650 600 1650 600 1650
600 1600 600 1650 600 1650
600 1650 600 500 600 550
600 1650 600 500 600 500
600 550 600 500 600 550
600 1600 650 1650 550 550
600 1650 600 1600 600 1650
600

name KEY_4
9050 4450 600 500 600 500
650 1600 600 500 650 500
600 500 650 500 600 500
600 1650 600 1650 600 1650
600 1600 650 1600 650 1600
600 1650 600 1650 600 500
600 550 600 1650 550 550
600 1650 600 500 600 500
650 500 600 1650 600 1650
600 500 600 1650 600 500
650 1600 600 1650 600 1650
600

name KEY_5
9050 4400 650 450 650 500
600 1650 600 500 650 500
600 500 600 500 650 500
600 1650 600 1600 650 1650
600 1600 600 1650 600 1650
600 1650 600 1650 600 1650
600 500 600 1650 600 500
600 1650 600 500 650 500
600 500 600 550 600 1650
600 500 600 1650 600 500
600 1650 600 1650 600 1650
600

name KEY_6
9050 4400 650 500 600 500
600 1650 600 500 650 500
600 500 600 500 650 500
600 1650 600 1650 600 1600
600 1650 600 1650 600 1650
600 1650 600 1650 600 500
600 1650 600 1650 600 500
600 1650 600 550 550 550
600 500 600 1650 600 500
600 550 600 1650 600 500
600 1650 600 1650 600 1650
600

name KEY_7
9000 4450 600 500 600 500
650 1600 650 450 650 500
600 500 650 500 600 500
600 1650 600 1650 600 1650
600 1650 600 1600 650 1600
600 1650 600 1650 600 1650
600 1650 550 1650 650 500
600 1650 600 500 600 550
600 500 600 500 600 550
600 500 600 1650 600 500
650 1600 600 1650 600 1650
600

name KEY_8
9050 4400 650 450 650 500
600 1650 600 500 650 500
600 500 600 500 650 500
600 1650 600 1600 650 1650
550 1650 600 1650 600 1650
600 1650 600 1600 650 500
600 550 550 550 600 1650
600 1650 550 550 600 500
650 500 600 1600 650 1650
550 1650 600 550 600 500
600 1650 600 1650 600 1650
600

name KEY_9
9050 4400 650 500 600 500
600 1650 600 500 650 500
600 500 600 500 650 500
600 1650 600 1650 600 1600
600 1650 650 1600 600 1650
600 1650 600 1650 600 1600
600 550 600 500 600 1650
600 1650 600 550 550 550
600 500 600 550 600 1600
600 1650 600 550 600 500
600 1650 600 1650 600 1650
600

name KEY_0
9000 4450 600 500 650 450
650 1600 650 500 600 500
600 500 650 500 600 550
600 1600 600 1650 600 1650
600 1650 600 1650 600 1650
600 1600 600 1650 600 550
600 500 600 500 650 500
600 1650 600 500 600 550
600 500 600 1650 600 1650
600 1600 650 1650 550 550
600 1650 600 1600 600 1650
600

name KEY_CHANNELUP
9050 4400 650 500 600 500
650 1600 650 500 600 500
600 500 650 500 600 500
650 1600 600 1650 600 1650
600 1650 600 1600 600 1650
650 1600 600 1650 600 1650
600 500 600 1650 600 500
600 1650 650 500 600 1600
650 500 600 550 550 1650
600 550 600 1650 550 550
600 1650 600 500 600 1650
600

name KEY_CHANNELDOWN
9050 4400 650 500 600 500
650 1600 600 500 650 500
600 550 600 500 600 500
600 1650 600 1650 600 1650
600 1600 650 1650 600 1600
600 1650 600 1650 600 500
650 1600 600 1650 600 550
600 1600 600 550 600 1650
550 550 600 1650 600 500
600 550 600 1650 550 550
600 1650 600 500 600 1650
600

name KEY_VOLUMEUP
9050 4400 650 500 600 500
600 1650 600 500 650 500
600 500 600 500 650 500
600 1650 600 1650 600 1600
600 1650 650 1600 600 1650
600 1650 600 1650 600 1600
600 1650 650 1600 600 500
650 1650 550 550 600 1650
600 500 600 500 600 550
600 500 650 1600 600 500
650 1650 550 550 600 1650
600

name KEY_VOLUMEDOWN
9050 4400 650 500 600 550
600 1600 650 500 600 500
600 500 650 500 600 500
650 1600 600 1650 600 1650
600 1650 600 1650 600 1600
650 1600 600 1650 600 550
600 500 600 500 600 1650
600 1650 600 500 650 1600
600 550 600 1650 600 1600
600 1650 600 550 550 550
600 1650 600 500 600 1650
600

end raw_codes

end remote

Now save this file in /etc/lirc and edit /etc/lirc/lircd.conf
include "/etc/lirc/remote.conf"

Now we can test irblaster
#irsend SEND_ONCE remote KEY_1
The channel on the topfield DVB must jump to channel 1

== EPG ==

To use the epg we want to grad the data from a source. In this case we use tv_grab_nl_py. This script will grab all data from www.tvgids.nl

XMLTV-configuratiebestand aanmaken

* Start MythTV Setup
* Choose for Video Sources.
* Choose for existing or a new video source
* Listings grabber: The Netherlands (tv_grab_nl_py...)
* Klick Finish

On the prompt
# tv_grab_nl_py --configure
This will create a config file in /homedir/.xmltv/tv_grab_nl_py.conf
Edit this config file and clear out all channels you don want (or edit them out)
To see is something is happening
#mythfilldatabase -v all --refresh-today
To see what's in the database
*mysql -u mythtv -p mythconverg -e "select chanid, callsign, name, xmltvid from channel;"

== Metadata ==

Make sure you have set the filepaths right. Go to Mythtv setup - 6. Storage Directories
Choose (create Fanart group) and choose the right directory

Now go to the mythfrontend and choose to watch a video. Select the video and press W. Based on the filename [http://www.mythtv.org/wiki/MythVideo_File_Parsing] the right data will be searched.

To configure the metadata yourself you can select the video and press I. Now configure the metadata.

== VLC ==

To make VLC player the default player. Goto Utilities/Setup -> SetUp -> Media Settings -> Video Settings -> Player Settings
vlc file://%s vlc://quit

nd change the extensions goto Utilities/Setup -> SetUp -> Media Settings -> Video Settings -> File Types

== TV card ==

* See if the card is working in a MS windows pc with technotrends own software
* Try installing w_scan to do a channel scan the use the configuration file created by importing it into mythtv.
* Recompile the drivers with new source files
* http://mythportal.be/TTBudgetS1500

Mythtv

2010-04-23T08:14:14Z

Insomnia: /* Metadata */ vlc

Mythtv

2010-04-05T20:29:25Z

Insomnia: /* lirc */ lirc init

Mythtv

2010-04-05T20:24:00Z

Insomnia: /* lirc */

== lirc ==
LIRC CVS is hosted at SourceForge. You can get a copy of the current CVS tree using anonymous CVS login. First log in to the cvs server (press <enter> for password):
cvs -d:pserver:anonymous@lirc.cvs.sourceforge.net:/cvsroot/lirc login
Get the sources:
cvs -z8 -d:pserver:anonymous@lirc.cvs.sourceforge.net:/cvsroot/lirc co lirc
After initial checkout, you can change into this directory and execute cvs commands without the -d option. For example:
cvs update
Compile:
cd lirc
./autogen.sh
./setup.sh
make

Lirc will initiate the hardware with the below config file. In this case a mce usb receiver with a ir blaster and also a volume knob (Antec fusion)

# /etc/lirc/hardware.conf
#
#Chosen Remote Control
REMOTE="Windows Media Center Transceivers/Remotes (all)"
REMOTE_MODULES="lirc_dev lirc_mceusb2"
REMOTE_DRIVER=""
REMOTE_DEVICE="/dev/lirc1"
REMOTE_LIRCD_CONF="mceusb/lircd.conf.mceusb"
REMOTE_LIRCD_ARGS=""
#Chosen Remote Control
REMOTE="Windows Media Center Transceivers/Remotes (all)"
REMOTE_MODULES="lirc_dev lirc_imon"
REMOTE_DRIVER=""
REMOTE_DEVICE="/dev/lirc0"
REMOTE_LIRCD_CONF=""
REMOTE_LIRCD_ARGS=""
#Chosen IR Transmitter
TRANSMITTER="Microsoft Windows Media Center V2 (usb) : Direct TV Receiver"
TRANSMITTER_MODULES="lirc_dev lirc_mceusb2"
TRANSMITTER_DRIVER=""
TRANSMITTER_DEVICE="/dev/lirc1"
TRANSMITTER_SOCKET=""
TRANSMITTER_LIRCD_CONF=""
TRANSMITTER_LIRCD_ARGS=""
#Enable lircd
START_LIRCD="true"
#Don't start lircmd even if there seems to be a good config file
#START_LIRCMD="false"
#Try to load appropriate kernel modules
LOAD_MODULES="true"
# Default configuration files for your hardware if any
LIRCMD_CONF=""
FORCE_NONINTERACTIVE_RECONFIGURATION="false"
START_LIRCMD=""
REMOTE_SOCKET=""

/etc/lirc/lircd.conf

################################################################################
# lircd.conf file for the new Microsoft Media Center remote using a new
# Microsoft Media Center receiver.
################################################################################
begin remote

name mceusb
bits 16
flags RC6|CONST_LENGTH
eps 30
aeps 100

header 2667 889
one 444 444
zero 444 444
pre_data_bits 21
pre_data 0x37FF0
gap 105000
toggle_bit 22
rc6_mask 0x100000000

begin codes

# starts at A1
BLUE 0x00007BA1
YELLOW 0x00007BA2
GREEN 0x00007BA3
RED 0x00007BA4
TELETEXT 0x00007BA5
RADIO 0x00007BAF
PRINT 0x00007BB1
VIDEO 0x00007BB5 # VIDEOS button
IMAGE 0x00007BB6 # PICTURES button
PVR 0x00007BB7 # RECORDED TV button
AUDIO 0x00007BB8 # MUSIC button
TV 0x00007BB9
# no BA - D8
Guide 0x00007BD9
TV 0x00007BDA # LIVE TV button
Dvd 0x00007BDB
Back 0x00007BDC
OK 0x00007BDD
Right 0x00007BDE
Left 0x00007BDF
Down 0x00007BE0
Up 0x00007BE1
STAR 0x00007BE2
Hash 0x00007BE3
PREVIOUS 0x00007BE4 # REPLAY button
Next 0x00007BE5 # SKIP button
Stop 0x00007BE6
Pause 0x00007BE7
Record 0x00007BE8
Play 0x00007BE9
Rewind 0x00007BEA
Forward 0x00007BEB
CHANNELDOWN 0x00007BEC
CHANNELUP 0x00007BED
Volumedown 0x00007BEE
Volumeup 0x00007BEF
INFO 0x00007BF0 # MORE (i) button
Mute 0x00007BF1
MENU 0x00007BF2 # START (Windows) button
POWER 0x00007BF3
ENTER 0x00007BF4
CLEAR 0x00007BF5
9 0x00007BF6
8 0x00007BF7
7 0x00007BF8
6 0x00007BF9
5 0x00007BFA
4 0x00007BFB
3 0x00007BFC
2 0x00007BFD
1 0x00007BFE
0 0x00007BFF
end codes

end remote

Whit this config file lirc will listen on the devices and will translate the input. It will give a hardware name for the device and the button pressed.
irw wil give you a xample on the commandline
#irw
Now press some buttons

To feed the command to the appropiate program (if this program supports lirc) make a config in the home dir of the user.

~/.lirc/mythtv

begin
remote = ClickWheel
prog = mythtv
button = KEY_VOLUMEUP
config = ]
repeat = 0
delay = 0
end

begin
remote = ClickWheel
prog = mythtv
button = KEY_VOLUMEDOWN
config = [
repeat = 0
delay = 0
end

== IRblaster ==

To get the right codes from youre remote you can record it with irrecord. This will provide a configuration file which you can use in lirc
#irrecord /tmp/remote.conf
Now follow the instructions
To get the raw codes
#irrecord -f /tmp/remoteraw.conf

You wil get this file for a topfield tf6000cok remote
# Please make this file available to others
# by sending it to <lirc@bartelmus.de>
#
# this config file was automatically generated
# using lirc-0.8.6(default) on Wed Mar 24 20:58:54 2010
#
# contributed by
#
# brand:Topfield
# model no. of remote control: TP-014
# devices being controlled by this remote: Topfield TF6000COK
#

begin remote

name topfield
flags RAW_CODES|CONST_LENGTH
eps 30
aeps 100

gap 107620

begin raw_codes

name KEY_1
9000 4450 600 500 650 450
650 1650 600 500 600 500
650 500 600 500 600 500
650 1600 650 1600 600 1650
600 1650 600 1650 600 1650
600 1600 650 1600 600 1650
600 550 600 500 600 500
600 1650 600 550 550 550
600 500 650 500 600 1650
600 1650 600 1600 600 550
600 1650 550 1650 650 1650
550

name KEY_2
9050 4400 600 500 650 500
600 1650 600 500 600 500
650 500 600 500 600 500
650 1650 600 1600 600 1650
600 1650 600 1650 600 1650
600 1650 600 1600 600 550
600 1650 600 500 600 500
650 1600 600 550 600 500
600 550 600 1600 600 550
600 1650 550 1650 650 500
600 1650 600 1650 600 1600
600

name KEY_3
9000 4450 600 500 650 500
600 1600 650 500 600 500
600 550 600 500 600 550
600 1600 600 1650 650 1600
600 1650 600 1650 600 1650
600 1600 600 1650 600 1650
600 1650 600 500 600 550
600 1650 600 500 600 500
600 550 600 500 600 550
600 1600 650 1650 550 550
600 1650 600 1600 600 1650
600

name KEY_4
9050 4450 600 500 600 500
650 1600 600 500 650 500
600 500 650 500 600 500
600 1650 600 1650 600 1650
600 1600 650 1600 650 1600
600 1650 600 1650 600 500
600 550 600 1650 550 550
600 1650 600 500 600 500
650 500 600 1650 600 1650
600 500 600 1650 600 500
650 1600 600 1650 600 1650
600

name KEY_5
9050 4400 650 450 650 500
600 1650 600 500 650 500
600 500 600 500 650 500
600 1650 600 1600 650 1650
600 1600 600 1650 600 1650
600 1650 600 1650 600 1650
600 500 600 1650 600 500
600 1650 600 500 650 500
600 500 600 550 600 1650
600 500 600 1650 600 500
600 1650 600 1650 600 1650
600

name KEY_6
9050 4400 650 500 600 500
600 1650 600 500 650 500
600 500 600 500 650 500
600 1650 600 1650 600 1600
600 1650 600 1650 600 1650
600 1650 600 1650 600 500
600 1650 600 1650 600 500
600 1650 600 550 550 550
600 500 600 1650 600 500
600 550 600 1650 600 500
600 1650 600 1650 600 1650
600

name KEY_7
9000 4450 600 500 600 500
650 1600 650 450 650 500
600 500 650 500 600 500
600 1650 600 1650 600 1650
600 1650 600 1600 650 1600
600 1650 600 1650 600 1650
600 1650 550 1650 650 500
600 1650 600 500 600 550
600 500 600 500 600 550
600 500 600 1650 600 500
650 1600 600 1650 600 1650
600

name KEY_8
9050 4400 650 450 650 500
600 1650 600 500 650 500
600 500 600 500 650 500
600 1650 600 1600 650 1650
550 1650 600 1650 600 1650
600 1650 600 1600 650 500
600 550 550 550 600 1650
600 1650 550 550 600 500
650 500 600 1600 650 1650
550 1650 600 550 600 500
600 1650 600 1650 600 1650
600

name KEY_9
9050 4400 650 500 600 500
600 1650 600 500 650 500
600 500 600 500 650 500
600 1650 600 1650 600 1600
600 1650 650 1600 600 1650
600 1650 600 1650 600 1600
600 550 600 500 600 1650
600 1650 600 550 550 550
600 500 600 550 600 1600
600 1650 600 550 600 500
600 1650 600 1650 600 1650
600

name KEY_0
9000 4450 600 500 650 450
650 1600 650 500 600 500
600 500 650 500 600 550
600 1600 600 1650 600 1650
600 1650 600 1650 600 1650
600 1600 600 1650 600 550
600 500 600 500 650 500
600 1650 600 500 600 550
600 500 600 1650 600 1650
600 1600 650 1650 550 550
600 1650 600 1600 600 1650
600

name KEY_CHANNELUP
9050 4400 650 500 600 500
650 1600 650 500 600 500
600 500 650 500 600 500
650 1600 600 1650 600 1650
600 1650 600 1600 600 1650
650 1600 600 1650 600 1650
600 500 600 1650 600 500
600 1650 650 500 600 1600
650 500 600 550 550 1650
600 550 600 1650 550 550
600 1650 600 500 600 1650
600

name KEY_CHANNELDOWN
9050 4400 650 500 600 500
650 1600 600 500 650 500
600 550 600 500 600 500
600 1650 600 1650 600 1650
600 1600 650 1650 600 1600
600 1650 600 1650 600 500
650 1600 600 1650 600 550
600 1600 600 550 600 1650
550 550 600 1650 600 500
600 550 600 1650 550 550
600 1650 600 500 600 1650
600

name KEY_VOLUMEUP
9050 4400 650 500 600 500
600 1650 600 500 650 500
600 500 600 500 650 500
600 1650 600 1650 600 1600
600 1650 650 1600 600 1650
600 1650 600 1650 600 1600
600 1650 650 1600 600 500
650 1650 550 550 600 1650
600 500 600 500 600 550
600 500 650 1600 600 500
650 1650 550 550 600 1650
600

name KEY_VOLUMEDOWN
9050 4400 650 500 600 550
600 1600 650 500 600 500
600 500 650 500 600 500
650 1600 600 1650 600 1650
600 1650 600 1650 600 1600
650 1600 600 1650 600 550
600 500 600 500 600 1650
600 1650 600 500 650 1600
600 550 600 1650 600 1600
600 1650 600 550 550 550
600 1650 600 500 600 1650
600

end raw_codes

end remote

Now save this file in /etc/lirc and edit /etc/lirc/lircd.conf
include "/etc/lirc/remote.conf"

Now we can test irblaster
#irsend SEND_ONCE remote KEY_1
The channel on the topfield DVB must jump to channel 1

== EPG ==

To use the epg we want to grad the data from a source. In this case we use tv_grab_nl_py. This script will grab all data from www.tvgids.nl

XMLTV-configuratiebestand aanmaken

* Start MythTV Setup
* Choose for Video Sources.
* Choose for existing or a new video source
* Listings grabber: The Netherlands (tv_grab_nl_py...)
* Klick Finish

On the prompt
# tv_grab_nl_py --configure
This will create a config file in /homedir/.xmltv/tv_grab_nl_py.conf
Edit this config file and clear out all channels you don want (or edit them out)
To see is something is happening
#mythfilldatabase -v all --refresh-today
To see what's in the database
*mysql -u mythtv -p mythconverg -e "select chanid, callsign, name, xmltvid from channel;"

== Metadata ==

Make sure you have set the filepaths right. Go to Mythtv setup - 6. Storage Directories
Choose (create Fanart group) and choose the right directory

Now go to the mythfrontend and choose to watch a video. Select the video and press W. Based on the filename [http://www.mythtv.org/wiki/MythVideo_File_Parsing] the right data will be searched.

To configure the metadata yourself you can select the video and press I. Now configure the metadata.

Mythtv

2010-04-05T20:18:41Z

Insomnia: /* lirc */

== lirc ==
LIRC CVS is hosted at SourceForge. You can get a copy of the current CVS tree using anonymous CVS login. First log in to the cvs server (press <enter> for password):
cvs -d:pserver:anonymous@lirc.cvs.sourceforge.net:/cvsroot/lirc login
Get the sources:
cvs -z8 -d:pserver:anonymous@lirc.cvs.sourceforge.net:/cvsroot/lirc co lirc
After initial checkout, you can change into this directory and execute cvs commands without the -d option. For example:
cvs update
Compile:
cd lirc
./autogen.sh
./setup.sh
make

Lirc will initiate the hardware with the below config file. In this case a mce usb receiver with a ir blaster and also a volume knob (Antec fusion)

# /etc/lirc/hardware.conf
#
#Chosen Remote Control
REMOTE="Windows Media Center Transceivers/Remotes (all)"
REMOTE_MODULES="lirc_dev lirc_mceusb2"
REMOTE_DRIVER=""
REMOTE_DEVICE="/dev/lirc1"
REMOTE_LIRCD_CONF="mceusb/lircd.conf.mceusb"
REMOTE_LIRCD_ARGS=""
#Chosen Remote Control
REMOTE="Windows Media Center Transceivers/Remotes (all)"
REMOTE_MODULES="lirc_dev lirc_imon"
REMOTE_DRIVER=""
REMOTE_DEVICE="/dev/lirc0"
REMOTE_LIRCD_CONF=""
REMOTE_LIRCD_ARGS=""
#Chosen IR Transmitter
TRANSMITTER="Microsoft Windows Media Center V2 (usb) : Direct TV Receiver"
TRANSMITTER_MODULES="lirc_dev lirc_mceusb2"
TRANSMITTER_DRIVER=""
TRANSMITTER_DEVICE="/dev/lirc1"
TRANSMITTER_SOCKET=""
TRANSMITTER_LIRCD_CONF=""
TRANSMITTER_LIRCD_ARGS=""

#Enable lircd
START_LIRCD="true"

#Don't start lircmd even if there seems to be a good config file
#START_LIRCMD="false"

#Try to load appropriate kernel modules
LOAD_MODULES="true"

# Default configuration files for your hardware if any
LIRCMD_CONF=""
FORCE_NONINTERACTIVE_RECONFIGURATION="false"
START_LIRCMD=""
REMOTE_SOCKET=""

/etc/lirc/lircd.conf

################################################################################
# lircd.conf file for the new Microsoft Media Center remote using a new
# Microsoft Media Center receiver.
################################################################################
begin remote

name mceusb
bits 16
flags RC6|CONST_LENGTH
eps 30
aeps 100

header 2667 889
one 444 444
zero 444 444
pre_data_bits 21
pre_data 0x37FF0
gap 105000
toggle_bit 22
rc6_mask 0x100000000

begin codes

# starts at A1
BLUE 0x00007BA1
YELLOW 0x00007BA2
GREEN 0x00007BA3
RED 0x00007BA4
TELETEXT 0x00007BA5
RADIO 0x00007BAF
PRINT 0x00007BB1
VIDEO 0x00007BB5 # VIDEOS button
IMAGE 0x00007BB6 # PICTURES button
PVR 0x00007BB7 # RECORDED TV button
AUDIO 0x00007BB8 # MUSIC button
TV 0x00007BB9
# no BA - D8
Guide 0x00007BD9
TV 0x00007BDA # LIVE TV button
Dvd 0x00007BDB
Back 0x00007BDC
OK 0x00007BDD
Right 0x00007BDE
Left 0x00007BDF
Down 0x00007BE0
Up 0x00007BE1
STAR 0x00007BE2
Hash 0x00007BE3
PREVIOUS 0x00007BE4 # REPLAY button
Next 0x00007BE5 # SKIP button
Stop 0x00007BE6
Pause 0x00007BE7
Record 0x00007BE8
Play 0x00007BE9
Rewind 0x00007BEA
Forward 0x00007BEB
CHANNELDOWN 0x00007BEC
CHANNELUP 0x00007BED
Volumedown 0x00007BEE
Volumeup 0x00007BEF
INFO 0x00007BF0 # MORE (i) button
Mute 0x00007BF1
MENU 0x00007BF2 # START (Windows) button
POWER 0x00007BF3
ENTER 0x00007BF4
CLEAR 0x00007BF5
9 0x00007BF6
8 0x00007BF7
7 0x00007BF8
6 0x00007BF9
5 0x00007BFA
4 0x00007BFB
3 0x00007BFC
2 0x00007BFD
1 0x00007BFE
0 0x00007BFF
end codes

end remote

Whit this config file lirc will listen on the devices and will translate the input. It will give a hardware name for the device and the button pressed.
irw wil give you a xample on the commandline
#irw
Now press some buttons

To feed the command to the appropiate program (if this program supports lirc) make a config in the home dir of the user.

~/.lircrc
begin
prog = mythtv
button = Two
config = 2
end

begin
prog = mythtv
button = Three
config = 3
end

begin
prog = mythtv
button = Four
config = 4
end

begin
prog = mythtv
button = Five
config = 5
end

begin
prog = mythtv
button = Six
config = 6
end

begin
prog = mythtv
button = Seven
config = 7
end

begin
prog = mythtv
button = Eight
config = 8
end

begin
prog = mythtv
button = Nine
config = 9
end

== IRblaster ==

To get the right codes from youre remote you can record it with irrecord. This will provide a configuration file which you can use in lirc
#irrecord /tmp/remote.conf
Now follow the instructions
To get the raw codes
#irrecord -f /tmp/remoteraw.conf

You wil get this file for a topfield tf6000cok remote
# Please make this file available to others
# by sending it to <lirc@bartelmus.de>
#
# this config file was automatically generated
# using lirc-0.8.6(default) on Wed Mar 24 20:58:54 2010
#
# contributed by
#
# brand:Topfield
# model no. of remote control: TP-014
# devices being controlled by this remote: Topfield TF6000COK
#

begin remote

name topfield
flags RAW_CODES|CONST_LENGTH
eps 30
aeps 100

gap 107620

begin raw_codes

name KEY_1
9000 4450 600 500 650 450
650 1650 600 500 600 500
650 500 600 500 600 500
650 1600 650 1600 600 1650
600 1650 600 1650 600 1650
600 1600 650 1600 600 1650
600 550 600 500 600 500
600 1650 600 550 550 550
600 500 650 500 600 1650
600 1650 600 1600 600 550
600 1650 550 1650 650 1650
550

name KEY_2
9050 4400 600 500 650 500
600 1650 600 500 600 500
650 500 600 500 600 500
650 1650 600 1600 600 1650
600 1650 600 1650 600 1650
600 1650 600 1600 600 550
600 1650 600 500 600 500
650 1600 600 550 600 500
600 550 600 1600 600 550
600 1650 550 1650 650 500
600 1650 600 1650 600 1600
600

name KEY_3
9000 4450 600 500 650 500
600 1600 650 500 600 500
600 550 600 500 600 550
600 1600 600 1650 650 1600
600 1650 600 1650 600 1650
600 1600 600 1650 600 1650
600 1650 600 500 600 550
600 1650 600 500 600 500
600 550 600 500 600 550
600 1600 650 1650 550 550
600 1650 600 1600 600 1650
600

name KEY_4
9050 4450 600 500 600 500
650 1600 600 500 650 500
600 500 650 500 600 500
600 1650 600 1650 600 1650
600 1600 650 1600 650 1600
600 1650 600 1650 600 500
600 550 600 1650 550 550
600 1650 600 500 600 500
650 500 600 1650 600 1650
600 500 600 1650 600 500
650 1600 600 1650 600 1650
600

name KEY_5
9050 4400 650 450 650 500
600 1650 600 500 650 500
600 500 600 500 650 500
600 1650 600 1600 650 1650
600 1600 600 1650 600 1650
600 1650 600 1650 600 1650
600 500 600 1650 600 500
600 1650 600 500 650 500
600 500 600 550 600 1650
600 500 600 1650 600 500
600 1650 600 1650 600 1650
600

name KEY_6
9050 4400 650 500 600 500
600 1650 600 500 650 500
600 500 600 500 650 500
600 1650 600 1650 600 1600
600 1650 600 1650 600 1650
600 1650 600 1650 600 500
600 1650 600 1650 600 500
600 1650 600 550 550 550
600 500 600 1650 600 500
600 550 600 1650 600 500
600 1650 600 1650 600 1650
600

name KEY_7
9000 4450 600 500 600 500
650 1600 650 450 650 500
600 500 650 500 600 500
600 1650 600 1650 600 1650
600 1650 600 1600 650 1600
600 1650 600 1650 600 1650
600 1650 550 1650 650 500
600 1650 600 500 600 550
600 500 600 500 600 550
600 500 600 1650 600 500
650 1600 600 1650 600 1650
600

name KEY_8
9050 4400 650 450 650 500
600 1650 600 500 650 500
600 500 600 500 650 500
600 1650 600 1600 650 1650
550 1650 600 1650 600 1650
600 1650 600 1600 650 500
600 550 550 550 600 1650
600 1650 550 550 600 500
650 500 600 1600 650 1650
550 1650 600 550 600 500
600 1650 600 1650 600 1650
600

name KEY_9
9050 4400 650 500 600 500
600 1650 600 500 650 500
600 500 600 500 650 500
600 1650 600 1650 600 1600
600 1650 650 1600 600 1650
600 1650 600 1650 600 1600
600 550 600 500 600 1650
600 1650 600 550 550 550
600 500 600 550 600 1600
600 1650 600 550 600 500
600 1650 600 1650 600 1650
600

name KEY_0
9000 4450 600 500 650 450
650 1600 650 500 600 500
600 500 650 500 600 550
600 1600 600 1650 600 1650
600 1650 600 1650 600 1650
600 1600 600 1650 600 550
600 500 600 500 650 500
600 1650 600 500 600 550
600 500 600 1650 600 1650
600 1600 650 1650 550 550
600 1650 600 1600 600 1650
600

name KEY_CHANNELUP
9050 4400 650 500 600 500
650 1600 650 500 600 500
600 500 650 500 600 500
650 1600 600 1650 600 1650
600 1650 600 1600 600 1650
650 1600 600 1650 600 1650
600 500 600 1650 600 500
600 1650 650 500 600 1600
650 500 600 550 550 1650
600 550 600 1650 550 550
600 1650 600 500 600 1650
600

name KEY_CHANNELDOWN
9050 4400 650 500 600 500
650 1600 600 500 650 500
600 550 600 500 600 500
600 1650 600 1650 600 1650
600 1600 650 1650 600 1600
600 1650 600 1650 600 500
650 1600 600 1650 600 550
600 1600 600 550 600 1650
550 550 600 1650 600 500
600 550 600 1650 550 550
600 1650 600 500 600 1650
600

name KEY_VOLUMEUP
9050 4400 650 500 600 500
600 1650 600 500 650 500
600 500 600 500 650 500
600 1650 600 1650 600 1600
600 1650 650 1600 600 1650
600 1650 600 1650 600 1600
600 1650 650 1600 600 500
650 1650 550 550 600 1650
600 500 600 500 600 550
600 500 650 1600 600 500
650 1650 550 550 600 1650
600

name KEY_VOLUMEDOWN
9050 4400 650 500 600 550
600 1600 650 500 600 500
600 500 650 500 600 500
650 1600 600 1650 600 1650
600 1650 600 1650 600 1600
650 1600 600 1650 600 550
600 500 600 500 600 1650
600 1650 600 500 650 1600
600 550 600 1650 600 1600
600 1650 600 550 550 550
600 1650 600 500 600 1650
600

end raw_codes

end remote

Now save this file in /etc/lirc and edit /etc/lirc/lircd.conf
include "/etc/lirc/remote.conf"

Now we can test irblaster
#irsend SEND_ONCE remote KEY_1
The channel on the topfield DVB must jump to channel 1

== EPG ==

To use the epg we want to grad the data from a source. In this case we use tv_grab_nl_py. This script will grab all data from www.tvgids.nl

XMLTV-configuratiebestand aanmaken

* Start MythTV Setup
* Choose for Video Sources.
* Choose for existing or a new video source
* Listings grabber: The Netherlands (tv_grab_nl_py...)
* Klick Finish

On the prompt
# tv_grab_nl_py --configure
This will create a config file in /homedir/.xmltv/tv_grab_nl_py.conf
Edit this config file and clear out all channels you don want (or edit them out)
To see is something is happening
#mythfilldatabase -v all --refresh-today
To see what's in the database
*mysql -u mythtv -p mythconverg -e "select chanid, callsign, name, xmltvid from channel;"

== Metadata ==

Make sure you have set the filepaths right. Go to Mythtv setup - 6. Storage Directories
Choose (create Fanart group) and choose the right directory

Now go to the mythfrontend and choose to watch a video. Select the video and press W. Based on the filename [http://www.mythtv.org/wiki/MythVideo_File_Parsing] the right data will be searched.

To configure the metadata yourself you can select the video and press I. Now configure the metadata.

Mythtv

2010-03-24T20:27:04Z

Insomnia: /* IRblaster */

== lirc ==
LIRC CVS is hosted at SourceForge. You can get a copy of the current CVS tree using anonymous CVS login. First log in to the cvs server (press <enter> for password):
cvs -d:pserver:anonymous@lirc.cvs.sourceforge.net:/cvsroot/lirc login
Get the sources:
cvs -z8 -d:pserver:anonymous@lirc.cvs.sourceforge.net:/cvsroot/lirc co lirc
After initial checkout, you can change into this directory and execute cvs commands without the -d option. For example:
cvs update
Compile:
cd lirc
./autogen.sh
./setup.sh
make

/etc/lirc/hardware.conf

# /etc/lirc/hardware.conf
#
# Arguments which will be used when launching lircd
LIRCD_ARGS=""

#Don't start lircmd even if there seems to be a good config file
START_LIRCMD=false

#Try to load appropriate kernel modules
LOAD_MODULES=true

# Run "lircd --driver=help" for a list of supported drivers.
#DRIVER="pinsys"
# If DEVICE is set to /dev/lirc and devfs is in use /dev/lirc/0 will be
# automatically used instead
DEVICE="/dev/lirc0"
MODULES="lirc_mceusb"
TRANSMITTER_DEVICE="/dev/lirc0"

# Default configuration files for your hardware if any
LIRCD_CONF=""
LIRCMD_CONF=""

/etc/lirc/lircd.conf

################################################################################
# lircd.conf file for the new Microsoft Media Center remote using a new
# Microsoft Media Center receiver.
################################################################################
begin remote

name mceusb
bits 16
flags RC6|CONST_LENGTH
eps 30
aeps 100

header 2667 889
one 444 444
zero 444 444
pre_data_bits 21
pre_data 0x37FF0
gap 105000
toggle_bit 22
rc6_mask 0x100000000

begin codes

# starts at A1
BLUE 0x00007BA1
YELLOW 0x00007BA2
GREEN 0x00007BA3
RED 0x00007BA4
TELETEXT 0x00007BA5
RADIO 0x00007BAF
PRINT 0x00007BB1
VIDEO 0x00007BB5 # VIDEOS button
IMAGE 0x00007BB6 # PICTURES button
PVR 0x00007BB7 # RECORDED TV button
AUDIO 0x00007BB8 # MUSIC button
TV 0x00007BB9
# no BA - D8
Guide 0x00007BD9
TV 0x00007BDA # LIVE TV button
Dvd 0x00007BDB
Back 0x00007BDC
OK 0x00007BDD
Right 0x00007BDE
Left 0x00007BDF
Down 0x00007BE0
Up 0x00007BE1
STAR 0x00007BE2
Hash 0x00007BE3
PREVIOUS 0x00007BE4 # REPLAY button
Next 0x00007BE5 # SKIP button
Stop 0x00007BE6
Pause 0x00007BE7
Record 0x00007BE8
Play 0x00007BE9
Rewind 0x00007BEA
Forward 0x00007BEB
CHANNELDOWN 0x00007BEC
CHANNELUP 0x00007BED
Volumedown 0x00007BEE
Volumeup 0x00007BEF
INFO 0x00007BF0 # MORE (i) button
Mute 0x00007BF1
MENU 0x00007BF2 # START (Windows) button
POWER 0x00007BF3
ENTER 0x00007BF4
CLEAR 0x00007BF5
9 0x00007BF6
8 0x00007BF7
7 0x00007BF8
6 0x00007BF9
5 0x00007BFA
4 0x00007BFB
3 0x00007BFC
2 0x00007BFD
1 0x00007BFE
0 0x00007BFF
end codes

end remote

~/.lircrc
begin
prog = mythtv
button = Two
config = 2
end

begin
prog = mythtv
button = Three
config = 3
end

begin
prog = mythtv
button = Four
config = 4
end

begin
prog = mythtv
button = Five
config = 5
end

begin
prog = mythtv
button = Six
config = 6
end

begin
prog = mythtv
button = Seven
config = 7
end

begin
prog = mythtv
button = Eight
config = 8
end

begin
prog = mythtv
button = Nine
config = 9
end

== IRblaster ==

To get the right codes from youre remote you can record it with irrecord. This will provide a configuration file which you can use in lirc
#irrecord /tmp/remote.conf
Now follow the instructions
To get the raw codes
#irrecord -f /tmp/remoteraw.conf

You wil get this file for a topfield tf6000cok remote
# Please make this file available to others
# by sending it to <lirc@bartelmus.de>
#
# this config file was automatically generated
# using lirc-0.8.6(default) on Wed Mar 24 20:58:54 2010
#
# contributed by
#
# brand:Topfield
# model no. of remote control: TP-014
# devices being controlled by this remote: Topfield TF6000COK
#

begin remote

name topfield
flags RAW_CODES|CONST_LENGTH
eps 30
aeps 100

gap 107620

begin raw_codes

name KEY_1
9000 4450 600 500 650 450
650 1650 600 500 600 500
650 500 600 500 600 500
650 1600 650 1600 600 1650
600 1650 600 1650 600 1650
600 1600 650 1600 600 1650
600 550 600 500 600 500
600 1650 600 550 550 550
600 500 650 500 600 1650
600 1650 600 1600 600 550
600 1650 550 1650 650 1650
550

name KEY_2
9050 4400 600 500 650 500
600 1650 600 500 600 500
650 500 600 500 600 500
650 1650 600 1600 600 1650
600 1650 600 1650 600 1650
600 1650 600 1600 600 550
600 1650 600 500 600 500
650 1600 600 550 600 500
600 550 600 1600 600 550
600 1650 550 1650 650 500
600 1650 600 1650 600 1600
600

name KEY_3
9000 4450 600 500 650 500
600 1600 650 500 600 500
600 550 600 500 600 550
600 1600 600 1650 650 1600
600 1650 600 1650 600 1650
600 1600 600 1650 600 1650
600 1650 600 500 600 550
600 1650 600 500 600 500
600 550 600 500 600 550
600 1600 650 1650 550 550
600 1650 600 1600 600 1650
600

name KEY_4
9050 4450 600 500 600 500
650 1600 600 500 650 500
600 500 650 500 600 500
600 1650 600 1650 600 1650
600 1600 650 1600 650 1600
600 1650 600 1650 600 500
600 550 600 1650 550 550
600 1650 600 500 600 500
650 500 600 1650 600 1650
600 500 600 1650 600 500
650 1600 600 1650 600 1650
600

name KEY_5
9050 4400 650 450 650 500
600 1650 600 500 650 500
600 500 600 500 650 500
600 1650 600 1600 650 1650
600 1600 600 1650 600 1650
600 1650 600 1650 600 1650
600 500 600 1650 600 500
600 1650 600 500 650 500
600 500 600 550 600 1650
600 500 600 1650 600 500
600 1650 600 1650 600 1650
600

name KEY_6
9050 4400 650 500 600 500
600 1650 600 500 650 500
600 500 600 500 650 500
600 1650 600 1650 600 1600
600 1650 600 1650 600 1650
600 1650 600 1650 600 500
600 1650 600 1650 600 500
600 1650 600 550 550 550
600 500 600 1650 600 500
600 550 600 1650 600 500
600 1650 600 1650 600 1650
600

name KEY_7
9000 4450 600 500 600 500
650 1600 650 450 650 500
600 500 650 500 600 500
600 1650 600 1650 600 1650
600 1650 600 1600 650 1600
600 1650 600 1650 600 1650
600 1650 550 1650 650 500
600 1650 600 500 600 550
600 500 600 500 600 550
600 500 600 1650 600 500
650 1600 600 1650 600 1650
600

name KEY_8
9050 4400 650 450 650 500
600 1650 600 500 650 500
600 500 600 500 650 500
600 1650 600 1600 650 1650
550 1650 600 1650 600 1650
600 1650 600 1600 650 500
600 550 550 550 600 1650
600 1650 550 550 600 500
650 500 600 1600 650 1650
550 1650 600 550 600 500
600 1650 600 1650 600 1650
600

name KEY_9
9050 4400 650 500 600 500
600 1650 600 500 650 500
600 500 600 500 650 500
600 1650 600 1650 600 1600
600 1650 650 1600 600 1650
600 1650 600 1650 600 1600
600 550 600 500 600 1650
600 1650 600 550 550 550
600 500 600 550 600 1600
600 1650 600 550 600 500
600 1650 600 1650 600 1650
600

name KEY_0
9000 4450 600 500 650 450
650 1600 650 500 600 500
600 500 650 500 600 550
600 1600 600 1650 600 1650
600 1650 600 1650 600 1650
600 1600 600 1650 600 550
600 500 600 500 650 500
600 1650 600 500 600 550
600 500 600 1650 600 1650
600 1600 650 1650 550 550
600 1650 600 1600 600 1650
600

name KEY_CHANNELUP
9050 4400 650 500 600 500
650 1600 650 500 600 500
600 500 650 500 600 500
650 1600 600 1650 600 1650
600 1650 600 1600 600 1650
650 1600 600 1650 600 1650
600 500 600 1650 600 500
600 1650 650 500 600 1600
650 500 600 550 550 1650
600 550 600 1650 550 550
600 1650 600 500 600 1650
600

name KEY_CHANNELDOWN
9050 4400 650 500 600 500
650 1600 600 500 650 500
600 550 600 500 600 500
600 1650 600 1650 600 1650
600 1600 650 1650 600 1600
600 1650 600 1650 600 500
650 1600 600 1650 600 550
600 1600 600 550 600 1650
550 550 600 1650 600 500
600 550 600 1650 550 550
600 1650 600 500 600 1650
600

name KEY_VOLUMEUP
9050 4400 650 500 600 500
600 1650 600 500 650 500
600 500 600 500 650 500
600 1650 600 1650 600 1600
600 1650 650 1600 600 1650
600 1650 600 1650 600 1600
600 1650 650 1600 600 500
650 1650 550 550 600 1650
600 500 600 500 600 550
600 500 650 1600 600 500
650 1650 550 550 600 1650
600

name KEY_VOLUMEDOWN
9050 4400 650 500 600 550
600 1600 650 500 600 500
600 500 650 500 600 500
650 1600 600 1650 600 1650
600 1650 600 1650 600 1600
650 1600 600 1650 600 550
600 500 600 500 600 1650
600 1650 600 500 650 1600
600 550 600 1650 600 1600
600 1650 600 550 550 550
600 1650 600 500 600 1650
600

end raw_codes

end remote

Now save this file in /etc/lirc and edit /etc/lirc/lircd.conf
include "/etc/lirc/remote.conf"

Now we can test irblaster
#irsend SEND_ONCE remote KEY_1
The channel on the topfield DVB must jump to channel 1

== Metadata ==

Make sure you have set the filepaths right. Go to Mythtv setup - 6. Storage Directories
Choose (create Fanart group) and choose the right directory

Now go to the mythfrontend and choose to watch a video. Select the video and press W. Based on the filename [http://www.mythtv.org/wiki/MythVideo_File_Parsing] the right data will be searched.

To configure the metadata yourself you can select the video and press I. Now configure the metadata.

Mythtv

2010-03-24T20:26:09Z

Insomnia: /* IRblaster */

Mythtv

2010-03-24T20:21:52Z

Insomnia: /* Metadata */

Mythtv

2010-01-06T21:30:54Z

Insomnia: /* lirc */

Mythtv

2009-12-30T15:12:46Z

Insomnia:

Ubuntu

2009-10-05T11:17:37Z

Insomnia: /* Citrix Ica client */

== NDISwrapper ==

NDISwrapper is a free software driver wrapper that enables the use of Microsoft Windows drivers for wireless network devices.

Download the windows driver wich contains the .inf file 
Install with ndiswrapper -i drivername.inf 
check the device id with lsusb or lspci -n 
Now execute with ndiswrapper -a deviceid driver
ndiswrapper -a 0bda:8197 net8187b
check the installed drivers
ndiswrapper -l
Write the configuration for modprobe
ndiswrapper -m
And use the module
modprobe ndiswrapper

== Compiz ==

To enable compiz install the Nvidia drivers and install CompizConfig Settings Manager
sudo apt-get install simple-ccsm
Now navigate to system > preferences > Appereance And go to the Visual effects tab. Choose custum there

On Kubuntu change the default windows manager

System Settings -> Default Applications -> Windows manager

{| class="wikitable" style="text-align:center" border="1" cellspacing="0" cellpadding="5"
!style="background:#ffdead;"|Desktop Effects
!style="background:#ffdead;"|Keyboard Shortcuts
|-
|Rotate Cube Manually
|Ctrl + Alt + Left Mouse Button
|-
|Expo
|Super + E (toggle)
|-
|Rotate Cube
|Mousewheel on Desktop
|-
|Film Effect
|Ctrl + Alt + Down Arrow
|-
|Scale Windows
|Alt + Shift + Up Arrow
|-
|Ring Switcher
|Super + Tab - overrides Shift Switcher
|}
Super key is the windows key :-)

== Mount Network Share ==

First install smbfs
apt-get install smbfs
Then create a folder inside of the /media directory to mount the share on or choose you're own directory
sudo mkdir /media/Storage
Create a credentials file in /root so that you can save your password and have it protected by the root account:
sudo gedit /root/.cifscredentials
Add this to the file
username=Guest
password=

sudo vi /etc/fstab
Add the following line
//192.168.0.10/SHARENAME /media/Storage cifs auto,iocharset=utf8,uid=USER,gid=users,credentials=/root/.cifscredentials,file_mode=0775,dir_mode=0775 0 0

To check if the file works
sudo mount -a
And you should see you're drives on the desktop

Ik you get error when you shut down the pc ''CIFS VFS: server not responding'' then you have to unmount first. Do this with the following

ln -s /etc/init.d/umountnfs.sh /etc/rc0.d/K15umountnfs.sh
ln -s /etc/init.d/umountnfs.sh /etc/rc6.d/K15umountnfs.sh

== Citrix Ica client ==

Download the Linux citrix ica client from Citrix
http://citrix.com/English/SS/downloads/details.asp?downloadID=3323&productID=-1

Install the 32bits libraries if youŕe working on a 64bits platform

apt-get install ia32-libs

Install the Open-motif libraries

apt-get install libmotif3

citrix 11 requires openmotif 2.3.1 Download the rpm package for openmotif 2.3.1, I used:

ftp://ftp.ics.com/openmotif/2.3/2.3.1/openmotif-2.3.1-1.RHEL3.0.i386.rpm

To convert a rpm package to a debian package. Use alien to convert the rpm to a deb package

alien -d openmotif-2.3.1-1.RHEL3.0.i386.rpm

Then install the package in the usual way. Note, before installing the alien'ed package it is best to uninstall the previous version of motif, as this will not update the existing motif package.

dpkg -i openmotif_2.3.1-2_i386.deb

Unpack the package and execute the installation script
./setupwfc
Find the plugin directory of firefox. Probably is /usr/lib/firefox/plugins/ otherwise use
find / -name plugins | grep -i "netscape\|firefox\|mozilla"
Create a symlink to the citrix ica library
ln –s /usr/lib/ICAClient/npica.so npica.so

If you open a connection to your citrix server. The browser will ask you if you want to open or save the session. Browse to the ica client
/usr/lib/ICAClient/wfica
and tell it to use it for all applications.

When you get a ssl error "you have not chosen to thrust....." Then copy the certificate in this location.
/usr/lib/ICAClient/keystore/cacerts/

For 64Bits OS

Install Needed 32-bit Open Motif libraries to /usr/lib32

Setup a temporary environment

mkdir -p ~/tmp/Citrix
cd ~/tmp/Citrix

Download a recent i386 libmotif3 .deb package to the above folder

wget http://mirrors.kernel.org/ubuntu/pool/multiverse/o/openmotif/libmotif3_2.2.3-1.4_i386.deb

Use dpkg to extract the package

dpkg -x libmotif3*i386.deb libmotif

Copy the libraries to /usr/lib32

sudo cp libmotif/usr/lib/*.so.* /usr/lib32/
sudo cp -r libmotif/usr/lib/X11/bindings /usr/lib32/X11/

== Make DVD ==

To make a video DVD you can burn you're image on the dvd. If you just have the VIDEO_TS files then the easiest way is to convert these into a iso.

mkisofs -dvd-video -o ~/moviename.iso /path/to/the/VIDEO_TS

/path/to/the/VIDEO_TS path is for example /moviename not /moviename/VIDEO_TS

Horde3

2009-08-30T09:24:21Z

Insomnia: /* Configure */

A standard howto can be found at [http://wiki.debian.org/Horde]. Our notes on Horde3 installation are the following:

apt-get install horde3

Now make the site available
In etc/apache2-sites-available there is already a file horde3
Alias /horde3 /usr/share/horde3
<Directory /usr/share/horde3>
Options FollowSymLinks
AllowOverride Limit
deny from all
allow from all 192.168 127.0.0
</Directory>
<Location /horde3>
SSLCipherSuite HIGH:MEDIUM
</Location>

And make the site enabled
ln -s /etc/apache2/sites-available/horde3 00X-horde3

== Database ==

To make the database there are several scripts in /usr/share/doc/horde3/examples/scripts/. We use MYsql:
gunzip /usr/share/doc/horde3/examples/scripts/sql/create.mysql.sql.gz

and change the password in the script for the user horde
Run the script
mysql -u root -p
source /usr/share/doc/horde3/examples/scripts/sql/create.mysql.sql

== Configure ==

To use the web configuration wizard we need to change the following
chgrp -R www-data /etc/horde/horde3/
chmod -R 750 /etc/horde/horde3
chmod 777 /etc/horde/horde3/conf.php
cp /etc/horde/horde3/conf.php /etc/horde/horde3/conf.php.bak
chmod 777 /etc/horde/horde3/conf.php.bak

Prepare log file:
touch /var/log/horde/horde3.log
chown root.www-data /var/log/horde/horde3.log
chmod 770 /var/log/horde/horde3.log

Now we can browse to the site
http://192.168.70.9/horde3/

This will give us the following
Horde3 configuration disabled by default because the administration/install wizard gives the whole world too much access to the system. Read /usr/share /doc/horde3/README.Debian.gz on how to allow access.

Change /var/log/horde/horde3/conf.php and comment line 2 and 3 leave the first line as is.

Choose setup from the menu 'horde setup'
- edit database -> username en WW - connect to database = tcp/ip - localhost - naam database
- edit preference system -> SQL database
- edit authentication -> Administrator,user@sample.com - SQL authentication
Choose Users from the menu
- add users -> user@sample.com

klik generate Horde Configurtion
Could not save the backup configuration file /usr/share/horde3/config/conf.bak.php
I had to change permissions on the /etc/horde/horde3 folder

== IMP ==
apt-get install imp4
Now prepare file permissions for web configuration:

chmod 777 /etc/horde/imp4/conf.php
touch /etc/horde/imp4/conf.bak.php
chmod 777 /etc/horde/imp4/conf.bak.php

Choose setup from the menu 'mail(imp)'
Generate your configuration (GPG/PGP, user constraints, enable spam/ham report, hooks...).

And when you're done change the permissions back

chmod 644 /etc/horde/imp4/conf.php
chmod 700 /etc/horde/imp4/conf.bak.php

And specify your mail server(s) in /etc/horde/imp4/servers.php file
$servers['imap'] = array(
'name' => 'IMAP Server',
'server' => 'localhost',
'hordeauth' => 'full',
'protocol' => 'imap/notls',
'port' => 143,
'maildomain' => 'sample.com',
'smtphost' => 'localhost',
'smtpport' => 25,
'realm' => 'sample.com',
'preferred' => '',
);

When you are ready, enable IMP in /etc/horde/horde3/registry.php file and verify if all is right. Yes, you read well, you MUST enable manually module in registry.php file after configuration!

$this->applications['imp'] = array(
'fileroot' => '/usr/share/horde3/lib' . '/../imp',
'webroot' => $this->applications['horde']['webroot'] . '/imp',
'name' => _("Mail"),
'status' => 'active',
'provides' => array('mail', 'contacts/favouriteRecipients')
);

Change the status from inactive to active

Horde3

2009-08-29T09:07:03Z

Insomnia: Horde3

apt-get install horde3

Now make the site available
In etc/apache2-sites-available there is already a file horde3
Alias /horde3 /usr/share/horde3
<Directory /usr/share/horde3>
Options FollowSymLinks
AllowOverride Limit
deny from all
allow from all 192.168 127.0.0
</Directory>
<Location /horde3>
SSLCipherSuite HIGH:MEDIUM
</Location>

And make the site enabled
ln -s /etc/apache2/sites-available/horde3 00X-horde3

== Database ==

To make the database there are several scripts. We use MYsql:
gunzip /usr/share/doc/horde3/examples/scripts/sql/create.mysql.sql.gz

and change the password in the script for the user horde
Run the script
mysql -u root -p
source /usr/share/doc/horde3/examples/scripts/sql/create.mysql.sql

Now we can browse to the site
http://192.168.70.9/horde3/

This will give us the following
Horde3 configuration disabled by default because the administration/install wizard gives the whole world too much access to the system. Read /usr/share /doc/horde3/README.Debian.gz on how to allow access.

To use the web configuration wizard we need to change the following
chgrp www-data /etc/horde/horde3/

Database 101

2009-08-29T08:14:38Z

Insomnia: /* Moving the MySQL databases */

== MySQL installation ==
As with any package to be installed: use aptitude, update your APT, then make sure all your (other) software is up-to-date. Then find package ''mysql-server'' - under Debian 5.0 "Lenny" it'll be version 5.0.51a-something. Installing it will also automatically install some dependent packages, like mysql-common, mysql-client etcetera. So after downloading some 40MiB of files, MySQL is installed. The installation script under Debian Lenny asks you for a password for the MySQL root user. Think up a strong password for the MySQL root user; something like ''waYacUbaT2uW''. DON'T use this example password, [http://www.pctools.com/guides/password/ generate your own one!]. DO NOT use the password of the Linux ''root'' user.

Should you consult [http://dev.mysql.com/doc/refman/5.0/en/unix-post-installation.html the official MySQL documentation], you might see mention of the ''mysql_install_db'' script - do not worry about that, since Debian has run it for you when it was setting up the database.

The standard user accounts that have been created by the installation script are:
* 'root'@'localhost'
* 'root'@'<hostname>'
* 'root'@'127.0.0.1'
All three root accounts are secured with the same password, the one you specified when installing the package ''mysql-server''.
----
'''NOTE for Debian 4.0 "Etch"'''
When you install MySQL under Etch, there are two root accounts with empty passwords, and two anonymous accounts. NOT safe! You'll want to rectify this in order to secure your MySQL server. Please take the following steps. Start the MySQL client from the command line:
mysql -u root
Then, from the mysql client prompt, set the password for the MySQL root users. They can be treated as two different accounts, but we don't recommend that. We thus give both accounts the same password:
mysql> SET PASSWORD FOR 'root'@'localhost' = PASSWORD('waYacUbaT2uW');
mysql> SET PASSWORD FOR 'root'@'<hostname>' = PASSWORD('waYacUbaT2uW');
Furthermore, there are two anonymous accounts created. These also have no password, and get full permission on the ''test'' database, as well as on any database who's name begins with ''test_''. These accounts can be fitted with a password (like we did for root - just use two quotes with nothing in between them, instead of two quotes with ''root'' in between), or they can be removed - which we recommend. The (single) command for this is:
<pre>mysql> DROP USER '';</pre>
'''End of NOTE'''
----

To verify the installation you might want to take some of the following steps:
* run ''mysqlshow -u root -p'', and see if that command outputs at least two databases (''information_schema'' and ''mysql'');
* check out the settings of your MySQL server by running ''mysqladmin -u root -p variables'' (piping the output to ''less'' or a file, if necessary);
* have a peek in ''/var/lib/mysql''; the database data files should be there;
* check ''/var/log'' for two logfiles ''mysql.err'' and ''mysql.log''.

==Moving the MySQL databases==
By default the location of your Debian MySQL databases is ''/var/lib/mysql/<database>''. However, sometimes you wish your databases to be in a different location. E.g. ''/data/mysql'', where ''/data'' is a mounted dedicated RAID array. Or perhaps even ''/data/mysql'' is its own array.

Whatever the reason, to move ''all'' MySQL databases from ''/var/lib/mysql'' to another location, you can follow these steps:
* Create the new directory, e.g. ''/data/mysql''
* Make this directory owned by user/group ''mysql''
cd /data
mkdir mysql
chown mysql:mysql mysql
* Shut down the database server with one of the following commands:
mysqladmin -u root -p shutdown
invoke-rc.d mysql stop
* Make a backup copy of ''/etc/mysql/my.cnf'', then edit this file. Find the section ''[mysqld]'' and change the line ''datadir = /var/lib/mysql'' to
datadir = /data/mysql
* As root, move (or better yet: copy) ''all'' of the content of ''/var/lib/mysql'' over to ''/data/mysql''. Make sure you don't accidentally change the ownership or permissions of the files and folders in the ''/var/lib/mysql'' folder. We expect each and every file and folder to be owned by ''mysql:mysql''. Copy command would be (as root):
cp -p -r /var/lib/mysql/* /data/mysql
* Check and doublecheck your ''my.cnf'' settings and your database file owners, attributes and size. After the next step, there ''may'' be no way back!
* Start up your database server:
invoke-rc.d mysql start
* Check the working of your MySQL server:
** issue the following command to get status information (to see if MySQL is running after your start command):
invoke-rc.d mysql status
** look under ''/var/log'' for the default MySQL log files ''mysql.log'' and ''mysql.err''
** check your SysLog (standard: ''/var/log/syslog'') for MySQL error messages, since the default Debian configuration is to log MySQL errors there, rather than in the previously mentioned MySQL logfiles.

== MYsql commands ==

DELETE FROM "table name" WHERE "colomn name"='VALUE'
UPDATE "table name" set "colomn name" = 'VALUE' where "colomn name" = 'VALUE';

E-mail server section

2009-08-29T08:02:46Z

Insomnia: /* Dovecot default configuration */

==E-mail server setup==
What we want to accomplish here is the setup of a mail server with the following properties:
* can serve multiple mail domains
* can relay mail for other domains to other mail servers
* can have one or more mailboxes per domain
* users of these mailboxes can be virtual (do not need to have a Linux user account)
* can have multiple aliases per mailbox
* can forward mail for certain aliases to multiple mailboxes
For this type of mail server setup, we owe a great thankyou to [http://workaround.org/articles/ispmail-etch/ Christoph Haas], whose advise has helped us create flexible and reliable mail servers since 2003.

==Preparation==
We'll assume that the server currently has no mailserver installed, at least no other than the default ''exim'' mailserver. Furthermore, the server is already fitted with MySQL, and this database is running without problems.

The hostname of the server must be set correctly, so that ''hostname -f'' returns a valid DNS name, like ''lighthouse.saruman.biz.''. It might also be an internal name like ''lighthouse.saruman.lan.'' but that will require us to give extra attention to the name under which Postfix will contact its collegues on the Internet. Also, the server can correctly [Networking_section#DNS_resolution_under_Debian | resolve DNS names] like [http://www.debian.org www.debian.org], preferably by running it's own caching DNS server.

The server is kept on the correct date and time using NTP, TCP port 25 is open on the server, the ISP will allow connections from Internet to this port, and if there's a firewall running on this server, then it has port 25 open so as to not block incoming e-mail.

==Software installation==
As a first step, we use [[APT and aptitude|apt or aptitude]] to make sure that our server is up-to-date. Then we can install the necessary software packages. Under Debian 5.0 "Lenny", the (single) packages is:
* ''postfix'', the mail server itself - this includes the "virtual package" postfix-tls, that we want to use to secure connections to Postfix with the TLS protocol
At the same time we can - and must - purge the following packages:
* exim4
* exim4-base
* exim4-daemon-light
* exim4-config
In ''aptitude'', only press "go" when you've marked all four of these packages "purge", or you cannot install postfix.

When installing the postfix package, the Debian installer script will ask you several questions, which you can answer like this:
* General type of mail configuration: Internet site
* System mail name: the FQDN of the mail server that you've verified in the previous section. Note that the script will try to guess the DNS name, but that might yield a DNS name with a trailing dot. That is technically correct, but the installation script will barf. Remove the trailing dot before hitting <enter>!
* Postmaster mail address: the address that all mail should go to that is addressed to "root" and "postmaster".
* Domain list: give the list of all domains that the machine can consider itself the FINAL destination for. This should at a minimum include an empty value, "localhost" and the FQDN of the machine itself (no trailing dots!); however, if you're running your own mail domain, you can also add that (e.g. "saruman.biz"). Thus, the list could look like this:
saruman.biz, lighthouse.saruman.lan, localhost.saruman.lan, , localhost
* Force synchronous updates? We think that's not necessary, but please read the question and decide for yourself
* Local networks: something like ''127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128 192.168.67.0/24'' (the default, augmented with your local IP range)
* Mailbox size limits: you can give postfix a limit in bytes, but we're going to use one single big mailbox for all users, so we cannot let Postfix guard it. Leave it at 0 (zero) so we don't have a size limit.
* Character for local address extension: we leave it at ''+''
* Internet protocols to use: currently we don't have IPv6 support, so there's no sense in letting Postfix try to serve IPv6. We choose ''ipv4'' only.
With the above data, the Debian install script for Postfix can do its job and configure Postfix with some basic settings.

Now that Postfix is installed, we can install some dependent packages (we could install them in the same run, but if anything goes amiss with the postfix installation, then these packages are going to remain unconfigured as well):
* ''postfix-doc'', the accompanying documentation;
* ''postfix-mysql'', necessary to have Postfix talk to our MySQL server;
* ''postfix-pcre'' to be able to parse regular expressions, which which we can combat spam;
* ''dovecot-imapd'' is a daemon that will provide your users with IMAP access to their mail;
* ''dovecot-pop3d'' is another daemon, but for the POP3 protocol.

==Virtual Mailman creation==
When we're done, we'll need a "system user", a sort of virtual mailman that is the owner of all mailboxes that we're serving. We suggest the name "vmail" for this user. Note: this user does not get his own mailbox (i.e. there's no mailbox at vmail@saruman.biz).

To create this user, and his home directory, we can run the following commands:
groupadd -g 120 vmail
useradd -g vmail -u 120 vmail -d /data/vmail -m -s /bin/false
As you see, we've chosen a group ID and user ID of 120 (after confirming that this ID was not taken by another group or user, by checking ''/etc/passwd'' and ''/etc/group''. Furthermore, we've decided to keep the ''vmail'' user's home directory not under ''/home/vmail'', but in a special place where we're going to expect server data to reside - in our server, the ''/data'' directory (which is a RAID-5 array mounted under root). By adding ''-m'', we've actually created the home directory, and adding ''-s /bin/false'' makes totally sure that the user ''vmail'' can never ever log in - even if we've not created a password for this user, so ''vmail'' shouldn't be able to log in anyway. Better safe than sorry.

To tell Postfix that this ''vmail'' user is someone special, we run
postconf -e virtual_uid_maps=static:120
postconf -e virtual_gid_maps=static:120
That makes postfix understand that all mail for the virtual mail domains must be written to disk with these specified user and group ID's.

==MySQL configuration==

===Database preparation===
We will use the MySQL database to record data on our mail system, and then give our Postfix access to this database so that it can read its configuration from there. For starters, we'll create a MySQL database named "vmail", and a MySQL user named "vmail_admin" that can read all necessary data from that "vmail" database. Then, we create the necessary tables, and a view that links these tables. We do this with the MySQL client ''mysql''. However, we're quite lazy, so we don't create this database by hand (that's error-prone), but by use of a script [[create.vmail.sql]]. To this end, feed the [[create.vmail.sql]] script into the ''mysql'' client like this:
mysql -u root -p < create.vmail.sql
(This of course assumes you have ''create.vmail.sql'' in your current working directory; if not you can include the path to the file.) Simply give the MySQL root user password, and the script creates the database, the user, the necessary tables, and the view. 
A note of caution: it is never a good idea to just run scripts without a proper understanding of what it does. Especially with MySQL, it will be advantageous if you understand the SQL commands. Open the script in a text editor, open the [http://dev.mysql.com/doc/refman/5.0/en/ MySQL command reference], and trace back what the script does exactly.

===Inserting data===
Next up, we fill the database with the first sets of values (either test data or the first of our production data). We'll start off with the virtual domains that we're hosting, by running the mysql client and feeding it information like this:
mysql -u root -p vmail
mysql> INSERT INTO virtual_domains (id, vdomain) VALUES (1, 'saruman.biz');
mysql> INSERT INTO virtual_domains (vdomain) VALUES ('wiki.saruman.biz');
mysql> INSERT INTO virtual_domains (vdomain) VALUES ('shop.saruman.biz');
This has the effect of creating three entries. You can check that everything worked as planned by executing
mysql> select * from virtual_domains;
Note: only the first entry needs an ''id'' value, because in MySQL we've defined that field as AUTO_INCREMENT. After creating your first virtual domain in the table, you never have to use a statement like the first INSERT again, only statements like the other two.

Now the MySQL database has the information needed by Postfix to recognise that you have three virtual mail domains (namely the three domains in the VALUES section) for which it hosts virtual mailboxes. Postfix cannot read this information yet, but that'll be taken care of in the next section.

Whle still within the mysql client, we can now create users:
mysql> INSERT INTO virtual_users (id, domain_id, user, passwd) VALUES (1, 1, 'jan', MD5('JanSecret'));
mysql> INSERT INTO virtual_users (domain_id, user, passwd) VALUES (1, 'mike', MD5('MikeSecret'));
mysql> INSERT INTO virtual_users (domain_id, user, passwd) VALUES (3, 'shopkeeper', MD5('ShopSecret'));
This has the effect of creating three users "jan" (in domain saruman.biz), "mike" (in domain saruman.biz) and "shopkeeper" (in domain shop.saruman.biz). Again, the ''id'' value is only ever needed in the first statement, because from now on every user addition will auto-increment ''id''.

The passwords shown are encrypted with MD5, and put in the ''passwd'' field. Later on, the users will be able to access their mailboxes using this password; we won't tell Postfix anything about them, because it doesn't need the passwords. You can check the content of the ''virtual_users'' table with the right "select" statement, and you can now also see that the view ''view-users'' works:
mysql> select * from virtual_users;
mysql> select * from view_users;

Next up, we're going to add some aliases, which are alternative e-mail addresses for the users; their primary e-mail address can already be seen in the ''view_users'' view, but perhaps you also want mail to "webmaster@shop.saruman.biz" to arrive at one or more mailboxes, e.g. in the mailbox for user "shopkeeper" (within domain "shop.saruman.biz") and this guy's home address ("j.doe@example.com"). Furthermore, we'll define catchall-addresses for all domains, that'll send all mail for which no mailbox can be found to the mailbox of user Mike (for the first two domains) and Webmaster (for shop.saruman.biz; Webmaster himself is an alias yet again, that points to shopkeeper@shop.saruman.biz). To create the catchall, leave out a value for the source address. This creates the empty value for source that will be expanded (using source@domain) to "@domain".
mysql> INSERT INTO virtual_aliases (id, domain_id, source, destination)
VALUES (1, 2, 'webmaster', 'shopkeeper@shop.saruman.biz');
mysql> INSERT INTO virtual_aliases (domain_id, source, destination)
VALUES (2, 'webmaster', 'j.doe@example.com');
mysql> INSERT INTO virtual_aliases (domain_id, destination)
VALUES (1, 'mike@saruman.biz');
mysql> INSERT INTO virtual_aliases (domain_id, destination)
VALUES (2, 'mike@saruman.biz');
mysql> INSERT INTO virtual_aliases (domain_id, destination)
VALUES (3, 'webmaster@saruman.biz');

Again, we don't need to add the ''id'' value any more after the first ever insertion into this table.

We can check the result by running a select statement against the ''virtual_aliases'' table and ''view_aliases'' view:
mysql> select * from virtual_aliases;
mysql> select * from view_aliases;

== Postfix configuration for MySQL lookups==
Next, we're going to tell Postfix to use the ''vmail'' database, and also how to read the database (Postfix never writes the MySQL database). To this end, we're going to create three configuration files in directory ''/etc/postfix''. We'll start off with one configuration file, with which Postfix can determine if a domain name is among the domain(s) that it's actually hosting mailboxes for. Then we'll create the config file that checks the table that contains all the users that have a virtual mailbox, and finally we create the lookup for the table with all the aliases.

===Virtual mail domains lookup===

Create file ''/etc/postfix/mysql-virtual-domains.cf'' with the following content:
user = vmail_admin
password = SuperSecret
hosts = 127.0.0.1
dbname = vmail
query = SELECT 1 FROM virtual_domains WHERE vdomain='%s'
Next, we tell postfix to check this configuration file when it needs to check "virtual_mailbox_domains":
postconf -e virtual_mailbox_domains=mysql:/etc/postfix/mysql-virtual-domains.cf
Use of this configuration file in postfix has the effect of returning "yes" when checking our database for the domain part of an email address. Naturally, this configuration file has to be fitted with the actual ''vmail_admin'' password rather than our example "SuperSecret".

=== Virtual mail user lookup===
Create the file ''/etc/postfix/mysql-virtual-mailbox-maps.cf'' with the following content:
user = vmail_admin
password = SuperSecret
hosts = 127.0.0.1
dbname = vmail
query = SELECT 1 FROM view_users WHERE email='%s'
Next, we tell Postfix that this mapping file is supposed to be used for the ''virtual_mailbox_maps'' mapping:
postconf -e virtual_mailbox_maps=mysql:/etc/postfix/mysql-virtual-mailbox-maps.cf
The lookup of virtual mailboxes should work with the data we've put into the database previously. i.e.
postmap -q jan@saruman.biz mysql:/etc/postfix/mysql-virtual-mailbox-maps.cf
should return a '''1''' to acknowledge that "jan@saruman.biz" is indeed a virtual mailbox in our Postfix configuration.

=== Virtual alias lookup===
Create another cf file at ''/etc/postfix/mysql-virtual-alias-maps.cf'':
user = vmail_admin
password = SuperSecret
hosts = 127.0.0.1
dbname = vmail
query = SELECT destination FROM view_aliases WHERE email='%s'
And create yet another cf file at ''/etc/postfix/mysql-email2email.cf'':
user = vmail_admin
password = SuperSecret
hosts = 127.0.0.1
dbname = vmail
query = SELECT email FROM view_users WHERE email='%s'

Again, we tell Postfix that this mapping file is supposed to be used for the ''virtual_alias_maps'' mapping:
postconf -e virtual_alias_maps=mysql:/etc/postfix/mysql-virtual-alias-maps.cf,mysql:/etc/postfix/mysql-email2email.cf
The lookup of virtual aliases should now work as designed:
postmap -q shopkeeper@shop.saruman.biz mysql:/etc/postfix/mysql-virtual-alias-maps.cf
postmap -q webmaster@shop.saruman.biz mysql:/etc/postfix/mysql-virtual-alias-maps.cf
If you've put in the data from the previous section, then both commands should return the same result: ''shopkeeper@saruman.biz''. This shows that Postfix will deliver mail to shopkeeper or to webmaster to the mailbox of shopkeeper.

===Finishing up configuration files===
When everything works as planned, then we secure the configuration files against prying eyes. Remember, the configuration files contain the user/password combination which which to access the ''vmail'' SQL database. The ''vmail_admin'' user has only read rights, and passwords in there are encrypted, but nevertheless, this is information we need to protect. Thus:
chown root:postfix /etc/postfix/mysql-*.cf
chmod u=rw,g=r,o= /etc/postfix/mysql-*.cf
This protects all four configuration files since only root can write them, members of group ''postfix'' can read them, and the rest of the world cannot access them at all.

==Configuring mail delivery through Dovecot LDA==
E-mails get delivered to the virtual mailboxes by means of a Mail Delivery Agent (MDA). With Postfix, the standard MDA for delivery to virtual mailboxes is called ''virtual'', but we're not going to use that; we're going to use ''[http://wiki.dovecot.org/LDA Dovecot LDA]'', which is a program called ''deliver''. By the way, the abbreviation LDA stands for Local Delivery Agent, which of course means more or less the same as MDA.
===Enabling the Dovecot daemon===
To make Postfix use Dovecot LDA, we add the following line to ''/etc/postfix/master.cf'':
dovecot unix - n n - - pipe
flags=DRhu user=vmail:vmail argv=/usr/lib/dovecot/deliver -d ${recipient}
This declares the service "dovecot" to mean using the program ''/usr/lib/dovecot/deliver'' with the right parameters. If we now let Postfix reload its files, it'll learn about this new service. Subsequently we can instruct Postfix to start using it, by declaring service "dovecot" to be the virtual transport of choice, and specifying one Dovecot-specific variable:
postfix reload
postconf -e virtual_transport=dovecot
postconf -e dovecot_destination_recipient_limit=1
===Dovecot default configuration===
Now to configure Dovecot itself: open ''/etc/dovecot/dovecot.conf'' with your favourite editor [[vim]]; first make sure the ''protocols ='' line reads
protocols = imap imaps pop3 pop3s
(which it should by default). The second setting is quite crucial. By default, the location of the mail directories is found automatically by Dovecot, but here that won't work. Find the line that reads ''#mail_location ='', and change it to
mail_location = maildir:/data/vmail/%d/%n/Maildir
This will look for mail in directory ''/data/vmail/'''DOMAIN'''/'''USER'''/Maildir'', and expect this directory to be in "maildir" format.
Next look for a section called "auth default". First define the allowed authentication mechanisms:
mechanisms = plain login
Then inside that same section you need to uncomment:
passdb sql {
args = /etc/dovecot/dovecot-sql.conf
}
which tells Dovecot that the passwords are stored in an SQL database (it's obvious that we'll now have to create this conf-file) and:
userdb static {
args = uid=120 gid=120 home=/data/vmail/%d/%n allow_all_users=yes
}
to tell Dovecot where the mailboxes are located. This is similar to the ''mail_location'' setting. Next task: comment out the section ''passdb pam'', so that Dovecot doesn't accidentally try to service local users as well.

Next up: tell Dovecot to handle IMAP the same as previous versions of this virtual mailserver have - this can prove to be quite tricky if you already have mailboxes full of mail, put there by e.g. Courier-IMAP. What works for us, is
namespace private {
separator = .
prefix =
inbox = yes
}
However, your mileage may vary.

You'll also want to comment out the ''passdb pam'' sections, since we're not hosting mail for local users.

Next up, we'll edit the section ''socket listen'' so that Dovecot can access the user database (master section), and our Postfix mailserver can access Dovecot (client section):
socket listen {
master {
path = /var/run/dovecot/auth-master
mode = 0600
user = vmail
}
client {
path = /var/spool/postfix/private/auth
mode = 0660
user = postfix
group = postfix
}
}

Finally, the protocol section, where we specify log files, an address to put in mails when we send out nondelivery reports, and a place to store scripts:
protocol lda {
log_path = /var/log/appslog/mail/dovecot-deliver.log
auth_socket_path = /var/run/dovecot/auth-master
postmaster_address = postmaster@saruman.biz
mail_plugins = cmusieve
global_script_path = /data/vmail/globalsieverc
}

You could change the log path to "log_path =" With a empty logpath syslog will log the events.

Now that we've finished the Dovecot configuration file, we need to create a fitting MySQL configuration file for Dovecot. The file is ''/etc/dovecot/dovecot-sql.conf'', and its contents are
driver = mysql
connect = host=127.0.0.1 dbname=vmail user=vmail_admin password=SuperSecret
default_pass_scheme = PLAIN-MD5
password_query = SELECT email as user, passwd as password FROM view_users WHERE email='%u';
When you've created this file (as root), change the attributes of ''dovecot-sql.conf'' and ''dovecot.conf'', and then restart Dovecot to start using the new configuration. Note: ''dovecot.conf'' needs to be read by Postfix, hence the group ownership for the file.
chmod u=rw,g=,o= /etc/dovecot/dovecot-sql.conf
chgrp vmail /etc/dovecot/dovecot.conf
chmod u=rw,g=r,o= /etc/dovecot/dovecot.conf
/etc/init.d/dovecot restart

To get some more logging in the case something goes wrong. Uncomment the folling and change to yes.
auth_verbose = yes
auth_debug = yes
auth_debug_passwords = yes

===Dovecot SSL configuration===
Out of the (Debian) box, Dovecot is SSL-enabled. We'll now replace the generic SSL-certificate, generated for the host by the Dovecot installation script, by our own certificate. To ths end, we first [[Creating_digital_certificates_with_our_root_certificate | generate an appropriate certificate]], e.g. an SSL wildcard certificate: "*.saruman.biz". This results in a public and a private certificate, both of which must be placed somewhere where Dovecot expects them and can read them.

By default, Dovecot expects the following locations/filenames/owner/attributes:
/etc/ssl/certs/dovecot.pem -rw-r--r-- root:dovecot 4624 bytes
/etc/ssl/private/dovecot.pem -rw------- root:dovecot 1743 bytes
If we may make a suggestion: rename the generated certificates in both locations to dovecot.pem.bak, place your generated certificates in their place, and set the owner/permissions like displayed here.

However, if you've generated your own keys, you might have used a passphrase on the private key. You'll have to tell dovecot about it in its configuration file /etc/dovecot/dovecot.conf. To this end, edit the corresponding section by uncommenting the "ssl_" lines, and using your private key password (e.g. "zM7Ertq12") in the appropriate line:
ssl_cert_file = /etc/ssl/certs/dovecot.pem
ssl_key_file = /etc/ssl/private/dovecot.pem

# If key file is password protected, give the password here. Alternatively
# give it when starting dovecot with -p parameter.
ssl_key_password = zM7Ertq12
Naturally you are free to place the keys in a different location, and/or use a different name...

==Finishing up==

This is a good moment to test your configuration, if you haven't been able to test your work inbetween. If everything works as expected, you can add bells and whistles to your configuration.

===''smtpd'' TLS encryption===
The first addition we'd like to present covers the way Postfix handles incoming connections. Since authentication works, we can have Postfix distrust every (unauthenticated) connection:
postconf -e mynetworks=
Furthermore, since a default SSL certificate is installed by the Debian Postfix installation routine, we can encrypt all our connections using TLS; we enforce this using
postconf -e smtpd_use_tls=yes
postconf -e smtpd_tls_auth_only=yes
Of course, you need to adjust the settings of your IMAP client so that it properly uses TLS and properly authenticates itself.

If TLS works, you'll probably want to change the certificate as you have for Dovecot in the previous section. This is again pretty easy. If you haven't yet, now is the time to [[Creating_digital_certificates_with_our_root_certificate | creating that custom SSL certificate]] for our mail server - but you have to make sure that you DON'T use a password on the private key. Unlike Dovecot, Postfix cannot be told the password to the private key somewhere.

For starters, look at the TLS-section of your ''main.cf'' that you currently have. Chances are a big chunk of it looks like this:
# TLS parameters
smtpd_tls_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem
smtpd_tls_key_file=/etc/ssl/private/ssl-cert-snakeoil.key
smtpd_use_tls=yes
Now all you need to do is replace the name of the snakeoil-keys with those of appropriate ssl-certificates, the private key of which needs to be NOT passphrase-protected. For this you could copy the Dovecot certificates, if you strip that passphrase in the manner described in the [[Creating_digital_certificates_with_our_root_certificate#Creating_an_SSL_certificate | SSL certificate section]]. The ''main.cf'' then would become:
# TLS parameters
smtpd_tls_cert_file=/etc/ssl/certs/postfix.pem
smtpd_tls_key_file=/etc/ssl/private/postfix.key
smtpd_use_tls=yes
Restart Postfix, and presto.

=== Other additions ===
If everything ''still'' works after these changes, then congratulations, you now have a powerful, flexible and pretty secure mail setup. Of course, there are always points for improvements. We'll cover these in separate pages. One page that we want to direct you to now, is
* [[Antispam measures]] for our Postfix mailserver

Creating digital certificates with our root certificate

2009-08-28T07:48:18Z

Insomnia: /* Preparing for certificate creation */

==Preparing for certificate creation==
When we're going to create certificates, we're going to use the ''openssl'' command twice:
* once to create a "certificate signing request", in which we define all information to be included in the certificate, and actually generate the public and private key parts of the key pair, and
* once to instruct the OpenSSL package to sign the certificate with our CA root certificate.
The first step thus '''creates''' the actual keypair, and the second step '''signs''' the public key.

However, we're going to need to input a lot of parameters on the ''openssl'' command line. We can make things a bit easier for us by specifying these in the ''openssl.cnf'' file, just as we have added some values when creating the CA itself. To be precise, we're going to add '''X.509 V3 extensions'''

By default OpenSSL generates V1 certificates, but if we're not extremely worried about offending certain ancient web browsers, we can add V3 extensions, and even make ''openssl'' do that by default. To do this, we find in ''/etc/ssl/openssl.cnf'' the following line in the section ''[ req ]'', which is likely present but commented out:
req_extensions = v3_req # The extensions to add to a certificate request
Simply remove the # sign in front of it, so that it appears as given above. This by default enables V3 extensions.

Furthermore, check the section ''[ v3_req ]''. It should look like this:
[ v3_req ]

# Extensions to add to a certificate request

basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
subjectKeyIdentifier = hash
What is added is the last line, with ''subjectKeyIdentifier''; this line specifies how to identify the public key being certified, so that distinct keys used by the same subject can be differentiated (e.g. as key updating occurs, for example). Four values are possible, but the IETF Public Key Infrastructure (PKIX) working group recommends the setting ''subjectKeyIdentifier=hash''

==Creating an SSL certificate==
Now we can create an SSL certificate for a web server. For the Common Name of the certificate, we need the '''exact''' name of the web server that'll offer the SSL connections. However, some servers run different websites as Virtual Hosts, so they could be running, for example, www.saruman.biz, as well as shop.saruman.biz. That might present a problem, because if the certificate is issued for www.saruman.biz, then each visitor of shop.saruman.biz will get a warning along the lines of "Warning: The website you're trying to visit is shop.saruman.biz, but the certificate offered is for www.saruman.biz". To prevent that, we could use the wildcard character in the name of the certificate, so as to generate a certificate for *.saruman.biz.

=== CA.sh - certificate creation made easy===
Since we have the ''openssl.cnf'' set up just right, and the ''CA.sh'' script primed, generating an SSL certificate is not very hard. From any old directory, run as root
/usr/lib/ssl/misc/CA.sh -newreq
This will create the signing request. The questions it'll ask, are
* a PEM passphrase, with which to protect the private key of the key pair. Note: you cannot generate a signing request without passphrase, so the private key you'll generate will ''always'' have a passphrase. If this is not what you want, do not despair: you can easily remove the passphrase from the private key after it's been generated (see further down). So just use a passphrase, even if you don't need one.
* Country/State/Locality/Organization/Organizational Unit; just as with the CA root certificate creation, these have your preprogrammed defaults that you may or may not change.
* Common Name; here we MUST give the DNS name of the host that is going to use the certificate, e.g. ''shop.saruman.biz'', or ''*.saruman.biz''.
* Challenge password; leave it blank, it's just to protect your signing request while en-route to the CA - but that's you anyway :-)
* Optional company name; leave that blank too, it's also extra information for the CA.

Now your private key and your certificate signing request (CSR) are ready; they're called ''newkey.pem'' and ''newreq.pem'' by default, and are located in your working directory. Time to do some signing! From that same working directory, run
/usr/lib/ssl/misc/CA.sh -sign
The script will show that it's using the config file ''/usr/lib/ssl/openssl.cnf'' (as we indeed wish), and then ask for the super-duper-secret passphrase to the CA private key (provided you've left that in directory ''/etc/ssl/ca/private''). Feed the script the passphrase, and it'll get to work. It'll check the request, then show you the details of the certificate you're about to sign. An example would be
Certificate Details:
Serial Number: 1 (0x1)
Validity
Not Before: Oct 27 09:34:00 2008 GMT
Not After : Nov 1 09:34:00 2009 GMT
Subject:
countryName = NL
stateOrProvinceName = Utrecht
organizationName = Saruman.biz
organizationalUnitName = Internet Dept.
commonName = shop.saruman.biz
emailAddress = webmaster@saruman.biz
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
Netscape Comment:
OpenSSL Generated Certificate
X509v3 Subject Key Identifier:
30:F2:61:80:AA:CF:1B:F0:3E:44:41:D6:38:CC:31:F0:94:28:BD:2B
X509v3 Authority Key Identifier:
keyid:80:41:F8:A5:1F:C2:27:6E:CF:A9:28:8E:8A:EF:83:E7:FD:8A:D5:26

Certificate is to be certified until Nov 1 09:34:00 2009 GMT (370 days)
Sign the certificate? [y/n]:
After doing your CA duty and diligently checking all the data, just press ''y''. The script certifies the request, and asks if it is to commit the request. This means it'll update it's own database, by saving a copy of the signed certificate in ''/etc/ssl/ca/newcerts'' named after its serial number (''01.pem'' for this example). Furthermore the script will record the serial and ID's of the generated certificate so that the next certificate will have a new serial number. And now: hey presto! We have a ''newcert.pem'' in our working directory!

For good measure:
* delete ''newreq.pem''
* rename the generated private key ''newkey.pem'' to ''shop.saruman.biz.seckey.pem''
* rename the generated public certificate ''newcert.pem'' to ''shop.saruman.biz.pem''

To remove the passphrase from the private key, use a command like this:
openssl rsa -in shop.saruman.biz.seckey.key -out shop.saruman.biz.key.key
This will make ''openssl'' ask for your passphrase, and then create the unsecured ''shop.saruman.biz.key.pem'' key file. Best practice: ALWAYS use a passphrase-protected key, unless the application cannot support it (e.g. Postfix).

Save the secure private key and its PEM passphrase in a safe place (e.g. Keepass database). And if you removed the passphrase from the private key, then store it in an even safer place!

Now you can deploy your certificate. (more on that in another section).

=== openssl - the hard way to certificate creation===
We don't actually need to use the ''CA.sh'' script, because we can do manually what the ''CA.sh'' script does. That gives us more control, but also more work. Let's see what we've got to do.

We will now perform the first step in our "manual" certificate generation: we create a signing request with all the information that we want in our SSL certificate. We run the magic incantation - note how we already
openssl req -new -nodes -keyout webmail.saruman.biz.key.pem -out webmail.saruman.biz.req.pem
This generates a new private key (named ''webmail.saruman.biz.key.pem''), and a new, non-encrypted (because of ''-nodes''), key signing request named ''webmail.saruman.biz.req.pem''. We can leave out terms like ''-newkey rsa:2048'' and ''-days 370'' since we've put that in the configuration file. And naturally you're free to choose your own names for the keys.

FIXME - need the full process here

=== Validating the generated certificates===
Again, we can use the ''openssl'' command to validate the keys we've generated. For instance, the ''CA.sh'' generated certificate, after renaming, is verified with
openssl x509 -in shop.saruman.biz.pem -noout -purpose
Certificate purposes:
SSL client : Yes
SSL client CA : No
SSL server : Yes
SSL server CA : No
Netscape SSL server : Yes
Netscape SSL server CA : No
S/MIME signing : Yes
S/MIME signing CA : No
S/MIME encryption : Yes
S/MIME encryption CA : No
CRL signing : Yes
CRL signing CA : No
Any Purpose : Yes
Any Purpose CA : Yes
OCSP helper : Yes
OCSP helper CA : No
Notice that the certificate is valid for everything except CA tasks.

Likewise, using ''-dates'' instead of ''-purpose'' lets you see the validity time period, and ''-text'' gives the whole text of the certificate. Note the line marked "issuer", and see how your own CA is referenced there.

E-mail server section

2009-08-28T07:13:22Z

Insomnia: /* Dovecot default configuration */

==E-mail server setup==
What we want to accomplish here is the setup of a mail server with the following properties:
* can serve multiple mail domains
* can relay mail for other domains to other mail servers
* can have one or more mailboxes per domain
* users of these mailboxes can be virtual (do not need to have a Linux user account)
* can have multiple aliases per mailbox
* can forward mail for certain aliases to multiple mailboxes
For this type of mail server setup, we owe a great thankyou to [http://workaround.org/articles/ispmail-etch/ Christoph Haas], whose advise has helped us create flexible and reliable mail servers since 2003.

==Preparation==
We'll assume that the server currently has no mailserver installed, at least no other than the default ''exim'' mailserver. Furthermore, the server is already fitted with MySQL, and this database is running without problems.

The hostname of the server must be set correctly, so that ''hostname -f'' returns a valid DNS name, like ''lighthouse.saruman.biz.''. It might also be an internal name like ''lighthouse.saruman.lan.'' but that will require us to give extra attention to the name under which Postfix will contact its collegues on the Internet. Also, the server can correctly [Networking_section#DNS_resolution_under_Debian | resolve DNS names] like [http://www.debian.org www.debian.org], preferably by running it's own caching DNS server.

The server is kept on the correct date and time using NTP, TCP port 25 is open on the server, the ISP will allow connections from Internet to this port, and if there's a firewall running on this server, then it has port 25 open so as to not block incoming e-mail.

==Software installation==
As a first step, we use [[APT and aptitude|apt or aptitude]] to make sure that our server is up-to-date. Then we can install the necessary software packages. Under Debian 5.0 "Lenny", the (single) packages is:
* ''postfix'', the mail server itself - this includes the "virtual package" postfix-tls, that we want to use to secure connections to Postfix with the TLS protocol
At the same time we can - and must - purge the following packages:
* exim4
* exim4-base
* exim4-daemon-light
* exim4-config
In ''aptitude'', only press "go" when you've marked all four of these packages "purge", or you cannot install postfix.

When installing the postfix package, the Debian installer script will ask you several questions, which you can answer like this:
* General type of mail configuration: Internet site
* System mail name: the FQDN of the mail server that you've verified in the previous section. Note that the script will try to guess the DNS name, but that might yield a DNS name with a trailing dot. That is technically correct, but the installation script will barf. Remove the trailing dot before hitting <enter>!
* Postmaster mail address: the address that all mail should go to that is addressed to "root" and "postmaster".
* Domain list: give the list of all domains that the machine can consider itself the FINAL destination for. This should at a minimum include an empty value, "localhost" and the FQDN of the machine itself (no trailing dots!); however, if you're running your own mail domain, you can also add that (e.g. "saruman.biz"). Thus, the list could look like this:
saruman.biz, lighthouse.saruman.lan, localhost.saruman.lan, , localhost
* Force synchronous updates? We think that's not necessary, but please read the question and decide for yourself
* Local networks: something like ''127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128 192.168.67.0/24'' (the default, augmented with your local IP range)
* Mailbox size limits: you can give postfix a limit in bytes, but we're going to use one single big mailbox for all users, so we cannot let Postfix guard it. Leave it at 0 (zero) so we don't have a size limit.
* Character for local address extension: we leave it at ''+''
* Internet protocols to use: currently we don't have IPv6 support, so there's no sense in letting Postfix try to serve IPv6. We choose ''ipv4'' only.
With the above data, the Debian install script for Postfix can do its job and configure Postfix with some basic settings.

Now that Postfix is installed, we can install some dependent packages (we could install them in the same run, but if anything goes amiss with the postfix installation, then these packages are going to remain unconfigured as well):
* ''postfix-doc'', the accompanying documentation;
* ''postfix-mysql'', necessary to have Postfix talk to our MySQL server;
* ''postfix-pcre'' to be able to parse regular expressions, which which we can combat spam;
* ''dovecot-imapd'' is a daemon that will provide your users with IMAP access to their mail;
* ''dovecot-pop3d'' is another daemon, but for the POP3 protocol.

==Virtual Mailman creation==
When we're done, we'll need a "system user", a sort of virtual mailman that is the owner of all mailboxes that we're serving. We suggest the name "vmail" for this user. Note: this user does not get his own mailbox (i.e. there's no mailbox at vmail@saruman.biz).

To create this user, and his home directory, we can run the following commands:
groupadd -g 120 vmail
useradd -g vmail -u 120 vmail -d /data/vmail -m -s /bin/false
As you see, we've chosen a group ID and user ID of 120 (after confirming that this ID was not taken by another group or user, by checking ''/etc/passwd'' and ''/etc/group''. Furthermore, we've decided to keep the ''vmail'' user's home directory not under ''/home/vmail'', but in a special place where we're going to expect server data to reside - in our server, the ''/data'' directory (which is a RAID-5 array mounted under root). By adding ''-m'', we've actually created the home directory, and adding ''-s /bin/false'' makes totally sure that the user ''vmail'' can never ever log in - even if we've not created a password for this user, so ''vmail'' shouldn't be able to log in anyway. Better safe than sorry.

To tell Postfix that this ''vmail'' user is someone special, we run
postconf -e virtual_uid_maps=static:120
postconf -e virtual_gid_maps=static:120
That makes postfix understand that all mail for the virtual mail domains must be written to disk with these specified user and group ID's.

==MySQL configuration==

===Database preparation===
We will use the MySQL database to record data on our mail system, and then give our Postfix access to this database so that it can read its configuration from there. For starters, we'll create a MySQL database named "vmail", and a MySQL user named "vmail_admin" that can read all necessary data from that "vmail" database. Then, we create the necessary tables, and a view that links these tables. We do this with the MySQL client ''mysql''. However, we're quite lazy, so we don't create this database by hand (that's error-prone), but by use of a script [[create.vmail.sql]]. To this end, feed the [[create.vmail.sql]] script into the ''mysql'' client like this:
mysql -u root -p < create.vmail.sql
(This of course assumes you have ''create.vmail.sql'' in your current working directory; if not you can include the path to the file.) Simply give the MySQL root user password, and the script creates the database, the user, the necessary tables, and the view. 
A note of caution: it is never a good idea to just run scripts without a proper understanding of what it does. Especially with MySQL, it will be advantageous if you understand the SQL commands. Open the script in a text editor, open the [http://dev.mysql.com/doc/refman/5.0/en/ MySQL command reference], and trace back what the script does exactly.

===Inserting data===
Next up, we fill the database with the first sets of values (either test data or the first of our production data). We'll start off with the virtual domains that we're hosting, by running the mysql client and feeding it information like this:
mysql -u root -p vmail
mysql> INSERT INTO virtual_domains (id, vdomain) VALUES (1, 'saruman.biz');
mysql> INSERT INTO virtual_domains (vdomain) VALUES ('wiki.saruman.biz');
mysql> INSERT INTO virtual_domains (vdomain) VALUES ('shop.saruman.biz');
This has the effect of creating three entries. You can check that everything worked as planned by executing
mysql> select * from virtual_domains;
Note: only the first entry needs an ''id'' value, because in MySQL we've defined that field as AUTO_INCREMENT. After creating your first virtual domain in the table, you never have to use a statement like the first INSERT again, only statements like the other two.

Now the MySQL database has the information needed by Postfix to recognise that you have three virtual mail domains (namely the three domains in the VALUES section) for which it hosts virtual mailboxes. Postfix cannot read this information yet, but that'll be taken care of in the next section.

Whle still within the mysql client, we can now create users:
mysql> INSERT INTO virtual_users (id, domain_id, user, passwd) VALUES (1, 1, 'jan', MD5('JanSecret'));
mysql> INSERT INTO virtual_users (domain_id, user, passwd) VALUES (1, 'mike', MD5('MikeSecret'));
mysql> INSERT INTO virtual_users (domain_id, user, passwd) VALUES (3, 'shopkeeper', MD5('ShopSecret'));
This has the effect of creating three users "jan" (in domain saruman.biz), "mike" (in domain saruman.biz) and "shopkeeper" (in domain shop.saruman.biz). Again, the ''id'' value is only ever needed in the first statement, because from now on every user addition will auto-increment ''id''.

The passwords shown are encrypted with MD5, and put in the ''passwd'' field. Later on, the users will be able to access their mailboxes using this password; we won't tell Postfix anything about them, because it doesn't need the passwords. You can check the content of the ''virtual_users'' table with the right "select" statement, and you can now also see that the view ''view-users'' works:
mysql> select * from virtual_users;
mysql> select * from view_users;

Next up, we're going to add some aliases, which are alternative e-mail addresses for the users; their primary e-mail address can already be seen in the ''view_users'' view, but perhaps you also want mail to "webmaster@shop.saruman.biz" to arrive at one or more mailboxes, e.g. in the mailbox for user "shopkeeper" (within domain "shop.saruman.biz") and this guy's home address ("j.doe@example.com"). Furthermore, we'll define catchall-addresses for all domains, that'll send all mail for which no mailbox can be found to the mailbox of user Mike (for the first two domains) and Webmaster (for shop.saruman.biz; Webmaster himself is an alias yet again, that points to shopkeeper@shop.saruman.biz). To create the catchall, leave out a value for the source address. This creates the empty value for source that will be expanded (using source@domain) to "@domain".
mysql> INSERT INTO virtual_aliases (id, domain_id, source, destination)
VALUES (1, 2, 'webmaster', 'shopkeeper@shop.saruman.biz');
mysql> INSERT INTO virtual_aliases (domain_id, source, destination)
VALUES (2, 'webmaster', 'j.doe@example.com');
mysql> INSERT INTO virtual_aliases (domain_id, destination)
VALUES (1, 'mike@saruman.biz');
mysql> INSERT INTO virtual_aliases (domain_id, destination)
VALUES (2, 'mike@saruman.biz');
mysql> INSERT INTO virtual_aliases (domain_id, destination)
VALUES (3, 'webmaster@saruman.biz');

Again, we don't need to add the ''id'' value any more after the first ever insertion into this table.

We can check the result by running a select statement against the ''virtual_aliases'' table and ''view_aliases'' view:
mysql> select * from virtual_aliases;
mysql> select * from view_aliases;

== Postfix configuration for MySQL lookups==
Next, we're going to tell Postfix to use the ''vmail'' database, and also how to read the database (Postfix never writes the MySQL database). To this end, we're going to create three configuration files in directory ''/etc/postfix''. We'll start off with one configuration file, with which Postfix can determine if a domain name is among the domain(s) that it's actually hosting mailboxes for. Then we'll create the config file that checks the table that contains all the users that have a virtual mailbox, and finally we create the lookup for the table with all the aliases.

===Virtual mail domains lookup===

Create file ''/etc/postfix/mysql-virtual-domains.cf'' with the following content:
user = vmail_admin
password = SuperSecret
hosts = 127.0.0.1
dbname = vmail
query = SELECT 1 FROM virtual_domains WHERE vdomain='%s'
Next, we tell postfix to check this configuration file when it needs to check "virtual_mailbox_domains":
postconf -e virtual_mailbox_domains=mysql:/etc/postfix/mysql-virtual-domains.cf
Use of this configuration file in postfix has the effect of returning "yes" when checking our database for the domain part of an email address. Naturally, this configuration file has to be fitted with the actual ''vmail_admin'' password rather than our example "SuperSecret".

=== Virtual mail user lookup===
Create the file ''/etc/postfix/mysql-virtual-mailbox-maps.cf'' with the following content:
user = vmail_admin
password = SuperSecret
hosts = 127.0.0.1
dbname = vmail
query = SELECT 1 FROM view_users WHERE email='%s'
Next, we tell Postfix that this mapping file is supposed to be used for the ''virtual_mailbox_maps'' mapping:
postconf -e virtual_mailbox_maps=mysql:/etc/postfix/mysql-virtual-mailbox-maps.cf
The lookup of virtual mailboxes should work with the data we've put into the database previously. i.e.
postmap -q jan@saruman.biz mysql:/etc/postfix/mysql-virtual-mailbox-maps.cf
should return a '''1''' to acknowledge that "jan@saruman.biz" is indeed a virtual mailbox in our Postfix configuration.

=== Virtual alias lookup===
Create another cf file at ''/etc/postfix/mysql-virtual-alias-maps.cf'':
user = vmail_admin
password = SuperSecret
hosts = 127.0.0.1
dbname = vmail
query = SELECT destination FROM view_aliases WHERE email='%s'
And create yet another cf file at ''/etc/postfix/mysql-email2email.cf'':
user = vmail_admin
password = SuperSecret
hosts = 127.0.0.1
dbname = vmail
query = SELECT email FROM view_users WHERE email='%s'

Again, we tell Postfix that this mapping file is supposed to be used for the ''virtual_alias_maps'' mapping:
postconf -e virtual_alias_maps=mysql:/etc/postfix/mysql-virtual-alias-maps.cf,mysql:/etc/postfix/mysql-email2email.cf
The lookup of virtual aliases should now work as designed:
postmap -q shopkeeper@shop.saruman.biz mysql:/etc/postfix/mysql-virtual-alias-maps.cf
postmap -q webmaster@shop.saruman.biz mysql:/etc/postfix/mysql-virtual-alias-maps.cf
If you've put in the data from the previous section, then both commands should return the same result: ''shopkeeper@saruman.biz''. This shows that Postfix will deliver mail to shopkeeper or to webmaster to the mailbox of shopkeeper.

===Finishing up configuration files===
When everything works as planned, then we secure the configuration files against prying eyes. Remember, the configuration files contain the user/password combination which which to access the ''vmail'' SQL database. The ''vmail_admin'' user has only read rights, and passwords in there are encrypted, but nevertheless, this is information we need to protect. Thus:
chown root:postfix /etc/postfix/mysql-*.cf
chmod u=rw,g=r,o= /etc/postfix/mysql-*.cf
This protects all four configuration files since only root can write them, members of group ''postfix'' can read them, and the rest of the world cannot access them at all.

==Configuring mail delivery through Dovecot LDA==
E-mails get delivered to the virtual mailboxes by means of a Mail Delivery Agent (MDA). With Postfix, the standard MDA for delivery to virtual mailboxes is called ''virtual'', but we're not going to use that; we're going to use ''[http://wiki.dovecot.org/LDA Dovecot LDA]'', which is a program called ''deliver''. By the way, the abbreviation LDA stands for Local Delivery Agent, which of course means more or less the same as MDA.
===Enabling the Dovecot daemon===
To make Postfix use Dovecot LDA, we add the following line to ''/etc/postfix/master.cf'':
dovecot unix - n n - - pipe
flags=DRhu user=vmail:vmail argv=/usr/lib/dovecot/deliver -d ${recipient}
This declares the service "dovecot" to mean using the program ''/usr/lib/dovecot/deliver'' with the right parameters. If we now let Postfix reload its files, it'll learn about this new service. Subsequently we can instruct Postfix to start using it, by declaring service "dovecot" to be the virtual transport of choice, and specifying one Dovecot-specific variable:
postfix reload
postconf -e virtual_transport=dovecot
postconf -e dovecot_destination_recipient_limit=1
===Dovecot default configuration===
Now to configure Dovecot itself: open ''/etc/dovecot/dovecot.conf'' with your favourite editor [[vim]]; first make sure the ''protocols ='' line reads
protocols = imap imaps pop3 pop3s
(which it should by default). The second setting is quite crucial. By default, the location of the mail directories is found automatically by Dovecot, but here that won't work. Find the line that reads ''#mail_location ='', and change it to
mail_location = maildir:/data/vmail/%d/%n/Maildir
This will look for mail in directory ''/data/vmail/'''DOMAIN'''/'''USER'''/Maildir'', and expect this directory to be in "maildir" format.
Next look for a section called "auth default". First define the allowed authentication mechanisms:
mechanisms = plain login
Then inside that same section you need to uncomment:
passdb sql {
args = /etc/dovecot/dovecot-sql.conf
}
which tells Dovecot that the passwords are stored in an SQL database (it's obvious that we'll now have to create this conf-file) and:
userdb static {
args = uid=120 gid=120 home=/data/vmail/%d/%n allow_all_users=yes
}
to tell Dovecot where the mailboxes are located. This is similar to the ''mail_location'' setting. Next task: comment out the section ''passdb pam'', so that Dovecot doesn't accidentally try to service local users as well.

Next up: tell Dovecot to handle IMAP the same as previous versions of this virtual mailserver have - this can prove to be quite tricky if you already have mailboxes full of mail, put there by e.g. Courier-IMAP. What works for us, is
namespace private {
separator = .
prefix =
inbox = yes
}
However, your mileage may vary.

You'll also want to comment out the ''passdb pam'' sections, since we're not hosting mail for local users.

Next up, we'll edit the section ''socket listen'' so that Dovecot can access the user database (master section), and our Postfix mailserver can access Dovecot (client section):
socket listen {
master {
path = /var/run/dovecot/auth-master
mode = 0600
user = vmail
}
client {
path = /var/spool/postfix/private/auth
mode = 0660
user = postfix
group = postfix
}
}

Finally, the protocol section, where we specify log files, an address to put in mails when we send out nondelivery reports, and a place to store scripts:
protocol lda {
log_path = /var/log/appslog/mail/dovecot-deliver.log
auth_socket_path = /var/run/dovecot/auth-master
postmaster_address = postmaster@saruman.biz
mail_plugins = cmusieve
global_script_path = /data/vmail/globalsieverc
}

Now that we've finished the Dovecot configuration file, we need to create a fitting MySQL configuration file for Dovecot. The file is ''/etc/dovecot/dovecot-sql.conf'', and its contents are
driver = mysql
connect = host=127.0.0.1 dbname=vmail user=vmail_admin password=SuperSecret
default_pass_scheme = PLAIN-MD5
password_query = SELECT email as user, passwd as password FROM view_users WHERE email='%u';
When you've created this file (as root), change the attributes of ''dovecot-sql.conf'' and ''dovecot.conf'', and then restart Dovecot to start using the new configuration. Note: ''dovecot.conf'' needs to be read by Postfix, hence the group ownership for the file.
chmod u=rw,g=,o= /etc/dovecot/dovecot-sql.conf
chgrp vmail /etc/dovecot/dovecot.conf
chmod u=rw,g=r,o= /etc/dovecot/dovecot.conf
/etc/init.d/dovecot restart

===Dovecot SSL configuration===
Out of the (Debian) box, Dovecot is SSL-enabled. We'll now replace the generic SSL-certificate, generated for the host by the Dovecot installation script, by our own certificate. To ths end, we first [[Creating_digital_certificates_with_our_root_certificate | generate an appropriate certificate]], e.g. an SSL wildcard certificate: "*.saruman.biz". This results in a public and a private certificate, both of which must be placed somewhere where Dovecot expects them and can read them.

By default, Dovecot expects the following locations/filenames/owner/attributes:
/etc/ssl/certs/dovecot.pem -rw-r--r-- root:dovecot 4624 bytes
/etc/ssl/private/dovecot.pem -rw------- root:dovecot 1743 bytes
If we may make a suggestion: rename the generated certificates in both locations to dovecot.pem.bak, place your generated certificates in their place, and set the owner/permissions like displayed here.

However, if you've generated your own keys, you might have used a passphrase on the private key. You'll have to tell dovecot about it in its configuration file /etc/dovecot/dovecot.conf. To this end, edit the corresponding section by uncommenting the "ssl_" lines, and using your private key password (e.g. "zM7Ertq12") in the appropriate line:
ssl_cert_file = /etc/ssl/certs/dovecot.pem
ssl_key_file = /etc/ssl/private/dovecot.pem

# If key file is password protected, give the password here. Alternatively
# give it when starting dovecot with -p parameter.
ssl_key_password = zM7Ertq12
Naturally you are free to place the keys in a different location, and/or use a different name...

==Finishing up==

This is a good moment to test your configuration, if you haven't been able to test your work inbetween. If everything works as expected, you can add bells and whistles to your configuration.

===''smtpd'' TLS encryption===
The first addition we'd like to present covers the way Postfix handles incoming connections. Since authentication works, we can have Postfix distrust every (unauthenticated) connection:
postconf -e mynetworks=
Furthermore, since a default SSL certificate is installed by the Debian Postfix installation routine, we can encrypt all our connections using TLS; we enforce this using
postconf -e smtpd_use_tls=yes
postconf -e smtpd_tls_auth_only=yes
Of course, you need to adjust the settings of your IMAP client so that it properly uses TLS and properly authenticates itself.

If TLS works, you'll probably want to change the certificate as you have for Dovecot in the previous section. This is again pretty easy. If you haven't yet, now is the time to [[Creating_digital_certificates_with_our_root_certificate | creating that custom SSL certificate]] for our mail server - but you have to make sure that you DON'T use a password on the private key. Unlike Dovecot, Postfix cannot be told the password to the private key somewhere.

For starters, look at the TLS-section of your ''main.cf'' that you currently have. Chances are a big chunk of it looks like this:
# TLS parameters
smtpd_tls_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem
smtpd_tls_key_file=/etc/ssl/private/ssl-cert-snakeoil.key
smtpd_use_tls=yes
Now all you need to do is replace the name of the snakeoil-keys with those of appropriate ssl-certificates, the private key of which needs to be NOT passphrase-protected. For this you could copy the Dovecot certificates, if you strip that passphrase in the manner described in the [[Creating_digital_certificates_with_our_root_certificate#Creating_an_SSL_certificate | SSL certificate section]]. The ''main.cf'' then would become:
# TLS parameters
smtpd_tls_cert_file=/etc/ssl/certs/postfix.pem
smtpd_tls_key_file=/etc/ssl/private/postfix.key
smtpd_use_tls=yes
Restart Postfix, and presto.

=== Other additions ===
If everything ''still'' works after these changes, then congratulations, you now have a powerful, flexible and pretty secure mail setup. Of course, there are always points for improvements. We'll cover these in separate pages. One page that we want to direct you to now, is
* [[Antispam measures]] for our Postfix mailserver

Asterisk basic configuration

2009-08-25T21:25:06Z

Insomnia: /* DAHDI */

= Asterisk basic configuration principles =
In this section we'll have a look at the basic configuration of an Asterisk PBX. Contrary to the TFOT-book, we'll be looking at it from the theory side, and from there go to an example configuration. For this example configuration, we'll start from a server with on the "outside" a POTS line and a SIP account with an Internet provider, and on the "inside" two analogue telephones and a SIP softphone. Our goal is to let the PBX behave as if we don't even have a PBX, but a standard home situation: for an incoming call, all phones ring; and every internal phone can make calls to the outside.

= Asterisk channel configuration basics =
The first thing to realise is that Asterisk sees each connected telephony device as a "channel". But what is a Channel? To Asterisk, a channel is a connection which brings in a call to the Asterisk PBX. A channel could be a connection to an ordinary telephone handset or an ordinary telephone line, or to a logical call (like an Internet phone call). Asterisk makes no distinction between "FXO" and "FXS" style channels (that is, it doesn't distinguish between telephone lines and telephones). Every call is placed or received on a distinct channel.

The second thing to realise, is that every type of device attached to the Asterisk PBX have their own specific configuration files. Correctly setting up each (set of) telephony devices makes them available in our Asterisk PBX as channels. Thus, the device configuration files serve as a kind of abstraction layer, and simplify our final Asterisk configuration by putting "channel-specific" information in separate files.

If you've followed the previous Asterisk sections in this Wiki, or followed the first four chapters of the TFOT-book, then you've encountered the following configuration files:
* ''zaptel.conf'' - in this file, you can set up the most basic parameters for your Zap-type hardware channels, most notably Digium telephony cards. You're configuring the hardware itself, via its driver. You could think of this file as belonging to the hardware, not Asterisk. If you'd have other software on your machine besides Asterisk that could make use of your telephony hardware, then that'd be influenced as well when you change ''zaptel.conf''.
* ''zapata.conf'' (and possibly ''zapata-channels.conf'' if you're on Debian) - this file handles the Asterisk-specific configuration of the hardware telephony channels. It thus "sets up the Zap channels" that Asterisk sees - for incoming and outgoing calls. All parameters that set up the channel are specified here.
* ''vpb.conf'' - this file is used to configure [http://www.voicetronix.com/ Voicetronix] cards with Asterisk. If you've a Voicetronix card in use, then you've also installed the Voicetronix drivers. This makes the card(s) useable under Linux. But to have Asterisk use the card(s), you need this ''vpb.conf'' file. It thus serves the same purpose as ''zapata.conf''.
* ''sip.conf'' - this file contains all information on all SIP devices that we want to connect to our Asterisk server; be it one or more SIP accounts with Internet providers, or SIP capable telephones (hardware or software). When ''sip.conf'' has been set up correctly, we can refer to a SIP device by a friendly name like [1000] or [Jane].
* ''iax.conf'' - this file is just the same as the ''sip.conf'' file, only it handles devices that talk IAX2 protocol instead of the SIP protocol.
These five files define all channels that our basic Asterisk PBX might handle (well, it won't even handle the last one, since we're not connecting any other Asterisk boxes or IAX-(soft)phones to our PBX, and it won't handle the third one if you don't have a Voicetronix card).

As a reference, we're going to list the contents of four example files, and explain what they do in the way of preparing channels for our simple Asterisk server.:
==zaptel.conf==
# Autogenerated by ./genzaptelconf -- do not hand edit
# Zaptel Configuration File
#
# This file is parsed by the Zaptel Configurator, ztcfg
#

# It must be in the module loading order

# Span 1: WCTDM/0 "Wildcard TDM410P Board 1" (MASTER)
fxoks=1
fxoks=2
fxsks=3
# channel 4, WCTDM, no module.

# Global data

loadzone = nl
defaultzone = nl
This is a relatively simple file, configuring three Digium modules. As you can see, the ''genzaptelconf'' command has generated it for us. It belongs with a Digium TDM410P card, which has two FXS modules in positions 1 and 2, and one FXO module in position 3. The first two non-commented lines define the protocol that the FXS modules must "talk" with the attached devices, which "naturally" is the FXO protocol (yes, FXS talks FXO, and FXO talks FXS... a bit like electric current flowing from negative to positive. It's just a matter of definitions). 
The third line defines that the FXO module talks FXS protocol. 
The fourth line configures a set of indications to use for the defined channels. Since we're loading "nl", we're configuring Dutch dialtones etcetera for the channels. 
Finally, the last line tell the server that any channel that does not have a zone assigned to it, should have the specified default zone configured - Dutch as well in this example. 
With this simple file, the driver for our example card (''wctdm24xxp'', by the way) can set up the hardware just as we want it. Now to tell Asterisk how to use it...
==zapata-channels.conf==
; Autogenerated by ./genzaptelconf -- do not hand edit
; Zaptel Channels Configurations (zapata.conf)
;
; This is not intended to be a complete zapata.conf. Rather, it is intended
; to be #include-d by /etc/zapata.conf that will include the global settings
;

; Span 1: WCTDM/0 "Wildcard TDM410P Board 1" (MASTER)
;;; line="1 WCTDM/0/0"
signalling=fxo_ks
callerid="Channel 1" <6001>
mailbox=6001
group=5
context=from-internal
channel => 1
callerid=
mailbox=
group=
context=default

;;; line="2 WCTDM/0/1"
signalling=fxo_ks
callerid="Channel 2" <6002>
mailbox=6002
group=5
context=from-internal
channel => 2
callerid=
mailbox=
group=
context=default

;;; line="3 WCTDM/0/2"
signalling=fxs_ks
callerid=asreceived
group=0
context=from-pstn
channel => 3
context=default
This second file is also auto-generated. It sets up three channels, associated with the three Digium hardware modules that we've configured with ''zaptel.conf''. Here, we also see how the channel numbers get assigned to the physical ports. The first module gets to be Zap channel 1 ('''Zap/1'''), the second '''Zap/2''' and so on. So if we would like our FXO module to be channel 1, and our FXS modules 2 and three, we could rotate the three channel numbers in this file. Probably we'd then also want to rotate the ''callerid''`s though... Furthermore, we don't think it's a good idea to assign channels to Zap devices in a different order than the devices are found in the system - meaning "stick with the default numbering as much as possible".

Note that the way ''zapata-channels.conf'' is interpreted, means that any statement like ''signalling=fxs_ks'' actually ''sets'' the ''signalling'' parameter; when the ''channel => 1'' line is reached, then all preceding parameter assignments are applied to that particular channel. This also means that if you somewhere have set a channel to belong to context "foo", and then never set a context again, then every next channel also gets assigned to "foo". So remember: if you don't see a parameter being set with a specific channel, you CANNOT assume that it then has it's default value; if a preceding channel has set that parameter to value "bar", then for your specific channel, it is "bar" also.

An interesting thing to see here is how ''genzaptelconf'' deals with the above concept. After defining each channel, it resets the most important parameters (a.o. the ones that should be unique with a channel) to empty or "default". This means that if you yourself are very meticulous, you could do without that safety net, and rewrite the above configuration file as:
signalling=fxo_ks
callerid="Channel 1" <6001>
mailbox=6001
group=5
context=from-internal
channel => 1

signalling=fxo_ks
callerid="Channel 2" <6002>
mailbox=6002
group=5
context=from-internal
channel => 2

signalling=fxs_ks
callerid=asreceived
group=0
context=from-pstn
channel => 3
Note: we like the thoroughnes of the ''genzaptelconf'' configuration, but we like the readability of the second file more.

==zapata.conf==
[trunkgroups]

[channels]
switchtype=national
rxwink=300 ; Atlas seems to use long (250ms) winks
usecallerid=yes
hidecallerid=no
callwaiting=yes
usecallingpres=yes
callwaitingcallerid=yes
threewaycalling=yes
transfer=yes
canpark=yes
cancallforward=yes
callreturn=yes
echocancel=yes
echocancelwhenbridged=yes
rxgain=0.0
txgain=0.0
callgroup=1
pickupgroup=1
immediate=no
#include zapata-channels.conf
Under Debian,

==sip.conf==

This is a sample configuration for VOIP with XS4ALL

;;/etc/asterisk/sip.conf;;
[general]
context=default
externip=setyoureiphere
dtfmmode=inband
localnet=192.168.70.0/24
port=5060
bindaddr=0.0.0.0
disallow=all
allow=alaw
allow=ulaw
registerattempts=0
defaultexpiry=7200
register => 08787XXXXX:PASSWORD@sip.xs4all.nl/08787XXXXX

[xs4all]
type=friend
username=08787XXXXX
fromuser=08787XXXXX
fromdomain=sip.xs4all.nl
secret=PASSWORD
host=sip.xs4all.nl
insecure=invite
context=fromxs4all
canreinvite=no
dtmfmode=inband
disallow=all
allow=alaw
allow=ulaw

== DAHDI ==

From asterisk version 1.4 zaptel is renamed in DAHDI witch stands for Digium Asterisk Hardware Device Interface.
If you installed the dahdi-tools (highly recommended) then you can configure you're hardware

Conversion from zaptel
/etc/zaptel.conf Becomes /etc/dahdi/system.conf
/etc/asterisk/zapata.conf Becomes /etc/asterisk/chan_dahdi.conf

Lets look at what we have
#dahdi_tool
This will give a overview of the hardware and if it is configured or not. It will all so show alarms on the hardware.

Now lets configure the card. First edit /etc/dadi/genconf_parameters. This file is used with dahdi_genconf and will produce /etc/dahdi-system.conf
*lc_country nl
You can also set the echo cancelation here MG2 is default
#dahdi_genconf

#dahdi_cfg -vv

DAHDI Tools Version - 2.2.0
DAHDI Version: 2.2.0.1
Echo Canceller(s): MG2
Configuration
======================
Channel map:

Channel 01: FXO Kewlstart (Default) (Echo Canceler: mg2) (Slaves: 01)
Channel 02: FXO Kewlstart (Default) (Echo Canceler: mg2) (Slaves: 02)

2 channels to configure.

Setting echocan for channel 1 to mg2
Setting echocan for channel 2 to mg2

Check if the right module is loaded.
#cat /etc/dahdi/modules

You can configure the options of dahdi in /etc/asterisk/chan_dahdi.conf
for example turn off the echo cancelation
Also include this line #include dahdi-channels.conf in your chan_dahdi.conf (yes with the #) Otherwise you're asterisk will not see the channels.

You can also check the channels in asterisk
#asterisk -r
#server*CLI> dahdi show channels
Or set the verbose level on asterisk to see more output
#server*CLI> core set verbose 10

I had some trouble with the sounds. When asterisk plays hello-world.gsm it sounded stutterd.
I did a
#dahdi_test
This gives a readout from the timinsettings in asterisk. Mine was -133% and it should give a reading close to 100%.I did a
#dahdi destroy channel 1
#dahdi destroy channel 2
#dahdi restart
Now i have 2 channels and no Pseudo channel (not shure were it's for)
Dahdi_test gives me 99,6% and the spound is good

= Asterisk dialplans - contexts =

A dial plan consists of a number of extensions. Each extensions consists of a number of priorities. Extensions are grouped in contexts. For each priority, an application is called.
[context]
exten => id, priority, command

When Asterisk receives an incoming connection on a channel, Asterisk looks at the context defined for that channel for commands telling Asterisk what it should do. The context defines different sets of commands depending on what extension the user has dialed. For example, a context might provide one set of commands for what to do if the user dials "123", and another set of commands for what to do if the user dials "9", and another set of commands for what to do if the user dials any number beginning with "555".

For some kinds of connections — such incoming calls from an outside telephone line — the user has not dialed an extension. In that case, Asterisk behaves as if the user had dialed a special extension named "s" (for Start). Asterisk will look for an extension "number" s in the definition of the context for that channel for instructions about what it should do to handle the call.

Let's say, for example, that you have a channel "Zap/1" which is a connection to a telephone handset in your building. And let's say that in the configuration file for Zap channels (zapata.conf), you have defined context=john for Zap channel 1. So when you use that handset to dial a number, Asterisk looks for a context with the name "john" in extensions.conf to find out what it should do. You begin the definition of a context in extensions.conf by putting the name of the context in square brackets on a line by itself, like this:
[john]

== extensions.conf ==

[globals]

[general]
autofallthrough=yes

[default]
include => fromxs4all

[fromxs4all]
exten => 08787XXXXX,1,Dial(DAHDI/2)
exten => 08787XXXXX,n,Hangup()

[outgoing]
exten => _X.,1,Dial(sip/xs4all/${EXTEN},60,r)

[internal]
exten => 6004,1,Dial(sip/6004)
exten => 6003,1,Dial(sip/6003)
exten => 6005,1,Dial(DAHDI/2)
exten => 6006,1,Answer()
exten => 6006,n,Playback(hello-world)
exten => 6006,n,Hangup()

[phones]
include => internal
include => fromxs4all
include => outgoing

Installing SaMBa with OpenLDAP support

2009-08-23T15:09:39Z

Insomnia: /* WINS configuration */

== The Samba Section==

== Preparations ==
First off, get yourself [http://oreilly.com/catalog/9780596007690/index.html this wonderful book] - and READ IT. Next, make sure our user backend of choice, OpenLDAP, is properly installed and can be used to authenticate users. If you haven't yet installed OpenLDAP, go to [[OpenLDAP | the relevant section]] of this wiki, and get going. Make sure your OpenLDAP is running well.

=== Software installation ===
This is easy: using ''aptitude'', install the following packages:
* ''samba'', the actual server.
* ''samba-tools'', a set of utilities.
* ''samba-doc'' - note that we NEED ''samba-doc'', as this package contains a configuration file that we need (the LDAP schema file).
* ''smbclient'', that can make your Linux server work with a Windows or SaMBa server; we need this to test our own server.

As usual, Debian is asking us for the configuration details. For SaMBa 3.2, there are only two simple questions:
* What do you want to be your Windows workgroup name? (we provide the name "AMBER")
* Do you want to modify ''smb.conf'' to use WINS setting from DHCP? (we provide "no")
Now we have our SaMBa configuration file as ''/etc/samba/smb.conf'', but we're going to follow two time-honoured tradions: we're going to save the original configuration file for future reference, and we're going to rename our configuration file to ''smb.conf.master'', while providing SaMBa with a comment-stripped version of it:
cd /etc/samba
cp smb.conf smb.conf.sample
mv smb.conf smb.conf.master
testparm smb.conf.master
testparm -s smb.conf.master > smb.conf
Now remember: when we want to change our SaMBa configuration, we edit ''smb.conf.master''. Once we're ready with that, we ALWAYS need to run those last two lines; the first of those will check our updated configuration, to see if we haven't made some silly typo that renders the configuration wholly or partially crippled, and the second one creates a comment-stripped version of it that SaMBa will actually be using.

=== WINS configuration ===
To enable WINS, we add the following lines to ''smb.conf.master'':
## Browsing/Identification ###
workgroup = AMBER
netbios name = DWORKIN

# Windows Internet Name Serving Support Section:
# WINS Support - Tells the NMBD component of Samba to enable its WINS Server
wins support = yes
os level = 33
domain master = yes
local master = yes
preferred master = yes
name resolve order = wins lmhosts hosts bcast
dns proxy = yes
Now this does a whole lot of things with the SaMBa ''nmbd'' daemon - at least when you remember to save the master config file, test it with ''testparm'' and write the actual ''smb.conf'' as desribed previously, AND then restart your ''nmbd'' daemon:
/etc/init.d/samba restart
OK so what do the configuration lines mean?
* ''workgroup = AMBER'' - this line makes the SaMBa server a member of workgroup AMBER.
* ''netbios name = DWORKIN'' - here we define the server NetBIOS name to be "dworkin".
* ''wins support = yes'' - this line actually turns on the WINS support, so it instructs the ''nmbd'' daemon to start acting as a WINS server.
* ''os level = 33'' - this gives our WINS server a "rank" of 33, meaning that it will be sure to become the WINS master browser, even if there are Windows servers on the network tat act as domain controllers.
* ''domain master = yes'' - this will tell our server that it will not be just any master browser, but a '''domain''' master browser, so that our server will be the master browser on each and every subnet that it is connected to.
* ''local master = yes'' - this setting is vital to being a domain master browser, as it ensures that our WINS server is also the local master browser.
* ''preferred master = yes'' - adding this line makes the ''nmbd'' daemon initiate a browser election as soon as it starts up, so that it essentially gets the master browser role as fast as possible.
* ''name resolve order = wins lmhosts hosts bcast'' - this ensures that for a WINS request, the ''nmbd'' daemon not only checks its WINS database, but also the local ''lmhosts'' file (if it exists), the Linux ''/etc/hosts'' file, and finally, to revert to a broadcast to see if it can locate the requested name by shouting out for it.
* ''dns proxy = yes'' - this makes ''nmbd'' to check a requested name with the DNS server, if it cannot be found in the WINS database itself.
After restarting, we can see if our Linux server is now a WINS master browser by inspecting the SaMBa log file, by default ''/var/log/samba/nmbd.log''. It should show something like
[2008/11/21 16:18:03, 0] nmbd/nmbd.c:main(849)
nmbd version 3.2.4 started.
Copyright Andrew Tridgell and the Samba Team 1992-2008
[2008/11/21 16:18:03, 0] nmbd/asyncdns.c:start_async_dns(155)
started asyncdns process 25707
[2008/11/21 16:18:03, 0] nmbd/nmbd_become_dmb.c:become_domain_master_browser_wins(336)
become_domain_master_browser_wins:
Attempting to become domain master browser on workgroup AMBER, subnet UNICAST_SUBNET.
[2008/11/21 16:18:03, 0] nmbd/nmbd_become_dmb.c:become_domain_master_browser_wins(350)
become_domain_master_browser_wins: querying WINS server from IP 192.168.67.10 for domain master browser name AMBER<1b> on workgroup AMBER
[2008/11/21 16:18:03, 0] nmbd/nmbd_become_dmb.c:become_domain_master_stage2(110)
*****

Samba server DWORKIN is now a domain master browser for workgroup AMBER on subnet UNICAST_SUBNET

*****
[2008/11/21 16:18:03, 0] nmbd/nmbd_become_dmb.c:become_domain_master_browser_bcast(291)
become_domain_master_browser_bcast:
Attempting to become domain master browser on workgroup AMBER on subnet 192.168.67.10
[2008/11/21 16:18:03, 0] nmbd/nmbd_become_dmb.c:become_domain_master_browser_bcast(304)
become_domain_master_browser_bcast: querying subnet 192.168.67.9 for domain master browser on workgroup AMBER
[2008/11/21 16:18:11, 0] nmbd/nmbd_become_dmb.c:become_domain_master_stage2(110)
*****

Samba server DWORKIN is now a domain master browser for workgroup AMBER on subnet 192.168.67.10

*****
[2008/11/21 16:18:26, 0] nmbd/nmbd_become_lmb.c:become_local_master_stage2(395)
*****

Samba name server DWORKIN is now a local master browser for workgroup AMBER on subnet 192.168.67.10

*****

Furthermore, we can test on the server itself if a WINS lookup succeeds:
dworkin:# nmblookup -M amber
querying amber on 127.255.255.255
192.168.67.10 amber<1d>

Finally, we tell our DHCP server to provide clients with the IP address of our WINS server. We do this by adding the following line to ''/etc/dhcp3-server/dhcpd.conf'':
option netbios-name-servers 192.168.67.10;
This line can either be added to the global section, or within the ''subnet'' declaration for each individual subnet that you want to inform of this WINS server.

=== OpenLDAP adaptation ===
In order for our OpenLDAP server to recognise the SaMBa-specific attributes that we're going to use, we need to add the "samba" schema to the OpenLDAP server. After installation of ''samba-doc'', we can find this schema in ''/usr/share/doc/samba-doc/examples/LDAP'', where it sits gzipped between some other schema files; as the README explains, what we need is ''samba.schema.gz'', so we unzip it and copy it to our OpenLDAP schema directory
cd /usr/share/doc/samba-doc/examples/LDAP
gunzip samba.schema.gz
cp samba.schema /etc/ldap/schema
Next up, we include this schema into our LDAP configuration, by adding the following line to ''/etc/ldap/slapd.conf'':
include /etc/ldap/schema/samba.schema
Not only do we need schema updates, we could also do with some more indices. Thus, we change the relevant section of ''/etc/ldap/slapd.conf'' to read:
# Indexing options for database #1
index objectClass,uidNumber,gidNumber eq
index cn,sn,uid,displayName pres,sub,eq
index memberUid,mail,givenname eq,subinitial
index sambaSID,sambaPrimaryGroupSID,sambaDomainName eq
Ofcourse, it's not just enough to add these parameters, we also need to generate the indices, and restart our LDAP server:
sudo invoke-rc.d slapd stop
sudo -u openldap slapindex
sudo invoke-rc.d slapd start
Check to see if the Samba objects are now usable in your LDAP server, e.g. by opening your LDAP Account Manager, and go to tools > schema browser; you should have objects like "sambaConfig" and "sambaDomain".

=== Feed OpenLDAP with Samba information===
Now we can add the Samba3 account information to our LDAP server. There are two ways of doing that: create an LDAP ldif file with the necessary information, or use the graphic LDAP manager to add it. For small amounts of users, the last way is quickest. What you need is to take two steps:

'''Add the SaMBa domain to the LDAP tree''' 
For this step, as root you perform the following command
net getlocalsid
This will a string like "SID for domain DWORKIN is: S-1-5-21-2406862431-3150385097-213705319". With this SID, we can create the LDAP object that represents the SaMBa domain. To that end we log into our LDAP account manager, go to "Samba domains", and create our domain. There are only three pieces of information that are mandatory:
* the domain name, in our example "amber"
* the forementioned SID, in our example "S-1-5-21-2406862431-3150385097-213705319".
* the RID base; this has a default of 1000, which you should not change unless you know exactly what you're doing.
However, there are other options that you might find it worth setting, like the minimal password length, password history length, if users should be disconnected "outside logon hours" etcetera. We would advise you to not set too many options until you've finished testing all basic functionality of your SaMBa server.

In case you're curious, the LDAP ldif file for such an account could look like this:
dn: sambaDomainName=amber,ou=domains,dc=saruman,dc=biz
objectClass: sambaDomain
sambaDomainName: amber
sambaSID: S-1-5-21-2476862421-3150885297-210706319
sambaAlgorithmicRidBase: 1000
sambaMinPwdLength: 7
sambaPwdHistoryLength: 5
sambaLogonToChgPwd: 0
sambaForceLogoff: -1
sambaRefuseMachinePwdChange: 1

dn: sambaDomainName=DWORKIN,dc=saruman,dc=biz
objectClass: sambaDomain
sambaDomainName: DWORKIN
sambaSID: S-1-5-21-2476862421-3150885297-210706319
sambaAlgorithmicRidBase: 1000
sambaNextUserRid: 1000
sambaMinPwdLength: 5
sambaPwdHistoryLength: 0
sambaLogonToChgPwd: 0
sambaMaxPwdAge: -1
sambaMinPwdAge: 0
sambaLockoutDuration: 30
sambaLockoutObservationWindow: 30
sambaLockoutThreshold: 0
sambaForceLogoff: -1
sambaRefuseMachinePwdChange: 0

'''Add the SaMBa account information to LDAP user accounts''' 
Again we use our LDAP account manager, and we now go to a user that we want to provide access to SaMBa. When you choose to edit the user, there should be a tab "Samba 3". In this tab, you can click the button "Add Samba 3 account"; until you've done that, this user has no access at all to the Samba server. 
When adding (or changing) a users Samba account information, there is actually only one mandatory field:
* "Domain": from this pulldown list you can choose the SaMBa/Windows domain that the user will belong to. When you have only your one SaMBa domain entered in your LDAP, this field will show the name of that domain.
Furthermore, there are a few more fields that you might want to fill. They are:
* "Display name": the name that Windows shows for a user
* "Samba password": this may be a different password from a Unix account that the user may have
* Windows group: this is the primary group that the user belongs to, from a SaMBa perspective instead of a Unix perspective.
Having added the necessary information, the user should be able from a Windows machine to browse the SaMBa server, and see all non-hidden shares that are available to him. Furthermore, from a Linux prompt, you could use ''smbclient'' to verify that SaMBa honours the users name and password:
smbclient //192.168.67.10/Data -U jan
If the Data share has been made (for that: see further down), and if user "jan" has a Samba account in LDAP, and if you type the correct password, then you're greeted with an SMB client prompt:
smb: \>
Here you can type commands like "dir", "del" and "mkdir"; type "help" to see all available commands.

== Samba configuration for LDAP authentication==
To get SaMBA to use OpenLDAP as a backend is actually quite straightforward. The main work is done in ''smb.conf.master'', where we add the following section:
passdb backend = ldapsam:ldap://127.0.0.1
ldap suffix = dc=saruman,dc=biz
ldap machine suffix = ou=hosts
ldap user suffix = ou=people
ldap group suffix = ou=groups
ldap admin dn = cn=admin,dc=saruman,dc=biz
ldap delete dn = no
# allow user privileges
enable privileges = yes
One note: if you use ''testparm -s'' to test and convert ''smb.conf.master'', then it's possible that your ''ldap suffix'' statement gets lower than one or more than the other ''ldap'' statements; you should rectify that before starting SaMBa, because otherwise SaMBa gets mighty confused, and cannot find the right LDAP OU's.

Now the above declares the LDAP account ''admin,saruman,biz'' to be the LDAP admin account - but SaMBa hasn't got the admin password yet, so it can't do much. To this end, we let SaMBa store the password for this admin account in its own little secret file ''/etc/samba/secrets.tdb''. We do this by running
smbpasswd -W
Setting stored password for "cn=admin,dc=saruman,dc=biz" in secrets.tdb
New SMB password:
Retype new SMB password:
If we used a lowercase ''-w'', then we could have specified the password on the command line (''smbpasswd -w SuperSecret'').

= Samba share configuration =
With the above configuration, we should now be able to create a share, and make it available to our LDAP accounts. To this end, we create a directory that we're going to share, and give it a workable set of permissions. Suppose we have an LDAP user "jan" and an LDAP group "networkusers". We could then, as root, do this:
cd /data/samba
mkdir Data
chown jan:networkusers Data
chmod g+rwxs,o-rwx Data
This ensures that user "jan", as well as every user that's a member of "networkusers", is allowed to read and write in this share. However, thanks to the "sticky bit" set for the group with the ''chmod'' command, files that are written to this directory are automatically owned by the group "networkusers", who have read & write rights.

Next step would be to share this directory, by adding the following section to ''smb.conf.master'':
[Data]
comment = Data directory for us all
browseable = yes
path = /data/samba/Data
guest ok = no
read only = no
create mask = 0770
create directory mask = 0770
This makes the directory usable via the share "Data". Notice that we do not allow unauthenticated users ("guest ok = no"), that we allow writing in this share ("read only = no", although we could also have used "writeable = yes", which is the same), and that we mask every create operation (for both files and directories) so that they can set any right under "user" and "group", but cannot set any rights under "other". This prevents anyone other than the "networkusers" to read (let alone write) the files in this share.

Asterisk Installation on Lenny

2009-08-19T14:29:28Z

Insomnia: /* Compile Asterisk */

Asterisk installation on Lenny can be performed with ease using Aptitude. This brings you Asterisk version 1.4.20. Since this has a graphical GUI manager, it might be wise to add X to your server.

= Compile Asterisk =

If you have a previous version of asterik first Backup config files /ets/asterisk and then uninstall it. From the original source files
#make uninstall-all

Get the latest version from http://www.asterisk.org/downloads
#cd /usr/src
Get asterisk version 1.6.1.1
wget http://downloads.asterisk.org/pub/telephony/asterisk/releases/asterisk-1.6.1.1.tar.gz
Get the DAHDI linux drivers
wget http://downloads.asterisk.org/pub/telephony/dahdi-linux/releases/dahdi-linux-2.2.0.1.tar.gz
Get the DAHDI linux tools
wget http://downloads.asterisk.org/pub/telephony/dahdi-tools/releases/dahdi-tools-2.2.0.tar.gz
Get the ISDN drivers (not sure if its still needed even if you don't have ISDN)
wget http://downloads.asterisk.org/pub/telephony/libpri/releases/libpri-1.4.10.1.tar.gz
Get the Addon
wget http://downloads.asterisk.org/pub/telephony/asterisk/releases/asterisk-addons-1.6.1.0.tar.gz

Unpack all the tarballs

Go to the asterisk 1.6.1.1 folder and launch the install script
# ./configure
I had a C++ preprocessor "/lib/cpp" fails sanity check and needed to install g++
#apt-get install g++

#make menuselect (OPTIONAL)
#make
#make install
#make samples
#make config

+---- Asterisk Installation Complete -------+
+ +
+ YOU MUST READ THE SECURITY DOCUMENT +
+ +
+ Asterisk has successfully been installed. +
+ If you would like to install the sample +
+ configuration files (overwriting any +
+ existing config files), run: +
+ +
+ make samples +
+ +
+----------------- or ---------------------+
+ +
+ You can go ahead and install the asterisk +
+ program documentation now or later run: +
+ +
+ make progdocs +
+ +
+ **Note** This requires that you have +
+ doxygen installed on your local system +

== Compile DAHDI ==

Go to the dahdi folder
# make

# make install

###################################################
###
### DAHDI installed successfully.
### If you have not done so before, install the package
### dahdi-tools.
###

Go to dahdi-tools
First run the configure script or you get a error "no rule to make target 'makeopts'"
#./configure
# make
# make install

###################################################
###
### DAHDI tools installed successfully.
### If you have not done so before, install init scripts with:
###
### make config
###
###################################################

Go to the DAHDI tools folder
# make config

install -D dahdi.init /etc/init.d/dahdi
/usr/bin/install -c -D -m 644 init.conf.sample /etc/dahdi/init.conf
/usr/bin/install -c -D -m 644 modules.sample /etc/dahdi/modules
/usr/bin/install -c -D -m 644 xpp/genconf_parameters /etc/dahdi/genconf_parameters
/usr/bin/install -c -D -m 644 modprobe.conf.sample /etc/modprobe.d/dahdi
/usr/bin/install -c -D -m 644 blacklist.sample /etc/modprobe.d/dahdi.blacklist
/usr/sbin/update-rc.d dahdi defaults 15 30
Adding system startup for /etc/init.d/dahdi ...
/etc/rc0.d/K30dahdi -> ../init.d/dahdi
/etc/rc1.d/K30dahdi -> ../init.d/dahdi
/etc/rc6.d/K30dahdi -> ../init.d/dahdi
/etc/rc2.d/S15dahdi -> ../init.d/dahdi
/etc/rc3.d/S15dahdi -> ../init.d/dahdi
/etc/rc4.d/S15dahdi -> ../init.d/dahdi
/etc/rc5.d/S15dahdi -> ../init.d/dahdi
DAHDI has been configured.

List of detected DAHDI devices:

pci:0000:04:05.0 wctdm24xxp+ d161:8005 Wildcard TDM410P

run 'dahdi_genconf modules' to load support for only
the DAHDI hardware installed in this system. By
default support for all DAHDI hardware is loaded at
DAHDI start.
darktower:/usr/src/dahdi-tools-2.2.0#

Asterisk Installation on Lenny

2009-08-19T13:46:22Z

Insomnia: /* Compile Asterisk */

Asterisk installation on Lenny can be performed with ease using Aptitude. This brings you Asterisk version 1.4.20. Since this has a graphical GUI manager, it might be wise to add X to your server.

= Compile Asterisk =

If you have a previous version of asterik first Backup config files /ets/asterisk and then uninstall it. From the original source files
#make uninstall-all

Get the latest version from http://www.asterisk.org/downloads
#cd /usr/src
Get asterisk version 1.6.1.1
wget http://downloads.asterisk.org/pub/telephony/asterisk/releases/asterisk-1.6.1.1.tar.gz
Get the DAHDI linux drivers
wget http://downloads.asterisk.org/pub/telephony/dahdi-linux/releases/dahdi-linux-2.2.0.1.tar.gz
Get the DAHDI linux tools
wget http://downloads.asterisk.org/pub/telephony/dahdi-tools/releases/dahdi-tools-2.2.0.tar.gz
Get the ISDN drivers (not sure if its still needed even if you don't have ISDN)
wget http://downloads.asterisk.org/pub/telephony/libpri/releases/libpri-1.4.10.1.tar.gz
Get the Addon
wget http://downloads.asterisk.org/pub/telephony/asterisk/releases/asterisk-addons-1.6.1.0.tar.gz

Unpack all the tarballs

Go to the asterisk 1.6.1.1 folder and launch the install script
#./install.pl
# ./configure
#make menuselect
#make install
#make
#make install
#make samples
#make config

+---- Asterisk Installation Complete -------+
+ +
+ YOU MUST READ THE SECURITY DOCUMENT +
+ +
+ Asterisk has successfully been installed. +
+ If you would like to install the sample +
+ configuration files (overwriting any +
+ existing config files), run: +
+ +
+ make samples +
+ +
+----------------- or ---------------------+
+ +
+ You can go ahead and install the asterisk +
+ program documentation now or later run: +
+ +
+ make progdocs +
+ +
+ **Note** This requires that you have +
+ doxygen installed on your local system +

== Compile DAHDI ==

Go to the dahdi folder
# make

# make install

###################################################
###
### DAHDI installed successfully.
### If you have not done so before, install the package
### dahdi-tools.
###

Go to dahdi-tools
First run the configure script or you get a error "no rule to make target 'makeopts'"
#./configure
# make
# make install

###################################################
###
### DAHDI tools installed successfully.
### If you have not done so before, install init scripts with:
###
### make config
###
###################################################

Go to the DAHDI tools folder
# make config

install -D dahdi.init /etc/init.d/dahdi
/usr/bin/install -c -D -m 644 init.conf.sample /etc/dahdi/init.conf
/usr/bin/install -c -D -m 644 modules.sample /etc/dahdi/modules
/usr/bin/install -c -D -m 644 xpp/genconf_parameters /etc/dahdi/genconf_parameters
/usr/bin/install -c -D -m 644 modprobe.conf.sample /etc/modprobe.d/dahdi
/usr/bin/install -c -D -m 644 blacklist.sample /etc/modprobe.d/dahdi.blacklist
/usr/sbin/update-rc.d dahdi defaults 15 30
Adding system startup for /etc/init.d/dahdi ...
/etc/rc0.d/K30dahdi -> ../init.d/dahdi
/etc/rc1.d/K30dahdi -> ../init.d/dahdi
/etc/rc6.d/K30dahdi -> ../init.d/dahdi
/etc/rc2.d/S15dahdi -> ../init.d/dahdi
/etc/rc3.d/S15dahdi -> ../init.d/dahdi
/etc/rc4.d/S15dahdi -> ../init.d/dahdi
/etc/rc5.d/S15dahdi -> ../init.d/dahdi
DAHDI has been configured.

List of detected DAHDI devices:

pci:0000:04:05.0 wctdm24xxp+ d161:8005 Wildcard TDM410P

run 'dahdi_genconf modules' to load support for only
the DAHDI hardware installed in this system. By
default support for all DAHDI hardware is loaded at
DAHDI start.
darktower:/usr/src/dahdi-tools-2.2.0#

Asterisk Installation on Lenny

2009-07-14T20:47:56Z

Insomnia: /* Compile Asterisk */

Asterisk installation on Lenny can be performed with ease using Aptitude. This brings you Asterisk version 1.4.20. Since this has a graphical GUI manager, it might be wise to add X to your server.

= Compile Asterisk =

If you have a previous version of asterik first Backup config files /ets/asterisk and then uninstall it. From the original source files
#make uninstall-all

Get the latest version from http://www.asterisk.org/downloads
#cd /usr/src
Get asterisk version 1.6.1.1
wget http://downloads.asterisk.org/pub/telephony/asterisk/releases/asterisk-1.6.1.1.tar.gz
Get the DAHDI linux drivers
wget http://downloads.asterisk.org/pub/telephony/dahdi-linux/releases/dahdi-linux-2.2.0.1.tar.gz
Get the DAHDI linux tools
wget http://downloads.asterisk.org/pub/telephony/dahdi-tools/releases/dahdi-tools-2.2.0.tar.gz
Get the ISDN drivers (not sure if its still needed even if you don't have ISDN)
wget http://downloads.asterisk.org/pub/telephony/libpri/releases/libpri-1.4.10.1.tar.gz
Get the Addon
wget http://downloads.asterisk.org/pub/telephony/asterisk/releases/asterisk-addons-1.6.1.0.tar.gz

Unpack all the tarballs

Go to the asterisk 1.6.1.1 folder and launch the install script
#./install.pl
# ./configure
#make menuselect
#make install
#make
#make install
#make samples
#make config

+---- Asterisk Installation Complete -------+
+ +
+ YOU MUST READ THE SECURITY DOCUMENT +
+ +
+ Asterisk has successfully been installed. +
+ If you would like to install the sample +
+ configuration files (overwriting any +
+ existing config files), run: +
+ +
+ make samples +
+ +
+----------------- or ---------------------+
+ +
+ You can go ahead and install the asterisk +
+ program documentation now or later run: +
+ +
+ make progdocs +
+ +
+ **Note** This requires that you have +
+ doxygen installed on your local system +

Go to the dahdi folder
# make install

###################################################
###
### DAHDI installed successfully.
### If you have not done so before, install the package
### dahdi-tools.
###

Go to dahdi-tools
First run the configure script or you get a error "no rule to make target 'makeopts'"
#./configure
# make install

###################################################
###
### DAHDI tools installed successfully.
### If you have not done so before, install init scripts with:
###
### make config
###
###################################################

Go to the DAHDI tools folder
# make config

install -D dahdi.init /etc/init.d/dahdi
/usr/bin/install -c -D -m 644 init.conf.sample /etc/dahdi/init.conf
/usr/bin/install -c -D -m 644 modules.sample /etc/dahdi/modules
/usr/bin/install -c -D -m 644 xpp/genconf_parameters /etc/dahdi/genconf_parameters
/usr/bin/install -c -D -m 644 modprobe.conf.sample /etc/modprobe.d/dahdi
/usr/bin/install -c -D -m 644 blacklist.sample /etc/modprobe.d/dahdi.blacklist
/usr/sbin/update-rc.d dahdi defaults 15 30
Adding system startup for /etc/init.d/dahdi ...
/etc/rc0.d/K30dahdi -> ../init.d/dahdi
/etc/rc1.d/K30dahdi -> ../init.d/dahdi
/etc/rc6.d/K30dahdi -> ../init.d/dahdi
/etc/rc2.d/S15dahdi -> ../init.d/dahdi
/etc/rc3.d/S15dahdi -> ../init.d/dahdi
/etc/rc4.d/S15dahdi -> ../init.d/dahdi
/etc/rc5.d/S15dahdi -> ../init.d/dahdi
DAHDI has been configured.

List of detected DAHDI devices:

pci:0000:04:05.0 wctdm24xxp+ d161:8005 Wildcard TDM410P

run 'dahdi_genconf modules' to load support for only
the DAHDI hardware installed in this system. By
default support for all DAHDI hardware is loaded at
DAHDI start.
darktower:/usr/src/dahdi-tools-2.2.0#

Asterisk basic configuration

2009-07-13T09:46:31Z

Insomnia: /* DAHDI */

= Asterisk basic configuration principles =
In this section we'll have a look at the basic configuration of an Asterisk PBX. Contrary to the TFOT-book, we'll be looking at it from the theory side, and from there go to an example configuration. For this example configuration, we'll start from a server with on the "outside" a POTS line and a SIP account with an Internet provider, and on the "inside" two analogue telephones and a SIP softphone. Our goal is to let the PBX behave as if we don't even have a PBX, but a standard home situation: for an incoming call, all phones ring; and every internal phone can make calls to the outside.

= Asterisk channel configuration basics =
The first thing to realise is that Asterisk sees each connected telephony device as a "channel". But what is a Channel? To Asterisk, a channel is a connection which brings in a call to the Asterisk PBX. A channel could be a connection to an ordinary telephone handset or an ordinary telephone line, or to a logical call (like an Internet phone call). Asterisk makes no distinction between "FXO" and "FXS" style channels (that is, it doesn't distinguish between telephone lines and telephones). Every call is placed or received on a distinct channel.

The second thing to realise, is that every type of device attached to the Asterisk PBX have their own specific configuration files. Correctly setting up each (set of) telephony devices makes them available in our Asterisk PBX as channels. Thus, the device configuration files serve as a kind of abstraction layer, and simplify our final Asterisk configuration by putting "channel-specific" information in separate files.

If you've followed the previous Asterisk sections in this Wiki, or followed the first four chapters of the TFOT-book, then you've encountered the following configuration files:
* ''zaptel.conf'' - in this file, you can set up the most basic parameters for your Zap-type hardware channels, most notably Digium telephony cards. You're configuring the hardware itself, via its driver. You could think of this file as belonging to the hardware, not Asterisk. If you'd have other software on your machine besides Asterisk that could make use of your telephony hardware, then that'd be influenced as well when you change ''zaptel.conf''.
* ''zapata.conf'' (and possibly ''zapata-channels.conf'' if you're on Debian) - this file handles the Asterisk-specific configuration of the hardware telephony channels. It thus "sets up the Zap channels" that Asterisk sees - for incoming and outgoing calls. All parameters that set up the channel are specified here.
* ''vpb.conf'' - this file is used to configure [http://www.voicetronix.com/ Voicetronix] cards with Asterisk. If you've a Voicetronix card in use, then you've also installed the Voicetronix drivers. This makes the card(s) useable under Linux. But to have Asterisk use the card(s), you need this ''vpb.conf'' file. It thus serves the same purpose as ''zapata.conf''.
* ''sip.conf'' - this file contains all information on all SIP devices that we want to connect to our Asterisk server; be it one or more SIP accounts with Internet providers, or SIP capable telephones (hardware or software). When ''sip.conf'' has been set up correctly, we can refer to a SIP device by a friendly name like [1000] or [Jane].
* ''iax.conf'' - this file is just the same as the ''sip.conf'' file, only it handles devices that talk IAX2 protocol instead of the SIP protocol.
These five files define all channels that our basic Asterisk PBX might handle (well, it won't even handle the last one, since we're not connecting any other Asterisk boxes or IAX-(soft)phones to our PBX, and it won't handle the third one if you don't have a Voicetronix card).

As a reference, we're going to list the contents of four example files, and explain what they do in the way of preparing channels for our simple Asterisk server.:
==zaptel.conf==
# Autogenerated by ./genzaptelconf -- do not hand edit
# Zaptel Configuration File
#
# This file is parsed by the Zaptel Configurator, ztcfg
#

# It must be in the module loading order

# Span 1: WCTDM/0 "Wildcard TDM410P Board 1" (MASTER)
fxoks=1
fxoks=2
fxsks=3
# channel 4, WCTDM, no module.

# Global data

loadzone = nl
defaultzone = nl
This is a relatively simple file, configuring three Digium modules. As you can see, the ''genzaptelconf'' command has generated it for us. It belongs with a Digium TDM410P card, which has two FXS modules in positions 1 and 2, and one FXO module in position 3. The first two non-commented lines define the protocol that the FXS modules must "talk" with the attached devices, which "naturally" is the FXO protocol (yes, FXS talks FXO, and FXO talks FXS... a bit like electric current flowing from negative to positive. It's just a matter of definitions). 
The third line defines that the FXO module talks FXS protocol. 
The fourth line configures a set of indications to use for the defined channels. Since we're loading "nl", we're configuring Dutch dialtones etcetera for the channels. 
Finally, the last line tell the server that any channel that does not have a zone assigned to it, should have the specified default zone configured - Dutch as well in this example. 
With this simple file, the driver for our example card (''wctdm24xxp'', by the way) can set up the hardware just as we want it. Now to tell Asterisk how to use it...
==zapata-channels.conf==
; Autogenerated by ./genzaptelconf -- do not hand edit
; Zaptel Channels Configurations (zapata.conf)
;
; This is not intended to be a complete zapata.conf. Rather, it is intended
; to be #include-d by /etc/zapata.conf that will include the global settings
;

; Span 1: WCTDM/0 "Wildcard TDM410P Board 1" (MASTER)
;;; line="1 WCTDM/0/0"
signalling=fxo_ks
callerid="Channel 1" <6001>
mailbox=6001
group=5
context=from-internal
channel => 1
callerid=
mailbox=
group=
context=default

;;; line="2 WCTDM/0/1"
signalling=fxo_ks
callerid="Channel 2" <6002>
mailbox=6002
group=5
context=from-internal
channel => 2
callerid=
mailbox=
group=
context=default

;;; line="3 WCTDM/0/2"
signalling=fxs_ks
callerid=asreceived
group=0
context=from-pstn
channel => 3
context=default
This second file is also auto-generated. It sets up three channels, associated with the three Digium hardware modules that we've configured with ''zaptel.conf''. Here, we also see how the channel numbers get assigned to the physical ports. The first module gets to be Zap channel 1 ('''Zap/1'''), the second '''Zap/2''' and so on. So if we would like our FXO module to be channel 1, and our FXS modules 2 and three, we could rotate the three channel numbers in this file. Probably we'd then also want to rotate the ''callerid''`s though... Furthermore, we don't think it's a good idea to assign channels to Zap devices in a different order than the devices are found in the system - meaning "stick with the default numbering as much as possible".

Note that the way ''zapata-channels.conf'' is interpreted, means that any statement like ''signalling=fxs_ks'' actually ''sets'' the ''signalling'' parameter; when the ''channel => 1'' line is reached, then all preceding parameter assignments are applied to that particular channel. This also means that if you somewhere have set a channel to belong to context "foo", and then never set a context again, then every next channel also gets assigned to "foo". So remember: if you don't see a parameter being set with a specific channel, you CANNOT assume that it then has it's default value; if a preceding channel has set that parameter to value "bar", then for your specific channel, it is "bar" also.

An interesting thing to see here is how ''genzaptelconf'' deals with the above concept. After defining each channel, it resets the most important parameters (a.o. the ones that should be unique with a channel) to empty or "default". This means that if you yourself are very meticulous, you could do without that safety net, and rewrite the above configuration file as:
signalling=fxo_ks
callerid="Channel 1" <6001>
mailbox=6001
group=5
context=from-internal
channel => 1

signalling=fxo_ks
callerid="Channel 2" <6002>
mailbox=6002
group=5
context=from-internal
channel => 2

signalling=fxs_ks
callerid=asreceived
group=0
context=from-pstn
channel => 3
Note: we like the thoroughnes of the ''genzaptelconf'' configuration, but we like the readability of the second file more.

==zapata.conf==
[trunkgroups]

[channels]
switchtype=national
rxwink=300 ; Atlas seems to use long (250ms) winks
usecallerid=yes
hidecallerid=no
callwaiting=yes
usecallingpres=yes
callwaitingcallerid=yes
threewaycalling=yes
transfer=yes
canpark=yes
cancallforward=yes
callreturn=yes
echocancel=yes
echocancelwhenbridged=yes
rxgain=0.0
txgain=0.0
callgroup=1
pickupgroup=1
immediate=no
#include zapata-channels.conf
Under Debian,

==sip.conf==

This is a sample configuration for VOIP with XS4ALL

;;/etc/asterisk/sip.conf;;
[general]
context=default
externip=setyoureiphere
dtfmmode=inband
localnet=192.168.70.0/24
port=5060
bindaddr=0.0.0.0
disallow=all
allow=alaw
allow=ulaw
registerattempts=0
defaultexpiry=7200
register => 08787XXXXX:PASSWORD@sip.xs4all.nl/08787XXXXX

[xs4all]
type=friend
username=08787XXXXX
fromuser=08787XXXXX
fromdomain=sip.xs4all.nl
secret=PASSWORD
host=sip.xs4all.nl
insecure=invite
context=fromxs4all
canreinvite=no
dtmfmode=inband
disallow=all
allow=alaw
allow=ulaw

== DAHDI ==

From asterisk version 1.4 zaptel is renamed in DAHDI witch stands for Digium Asterisk Hardware Device Interface.
If you installed the dahdi-tools (highly recommended) then you can configure you're hardware

Conversion from zaptel
/etc/zaptel.conf Becomes /etc/dahdi/system.conf
/etc/asterisk/zapata.conf Becomes /etc/asterisk/chan_dahdi.conf

Lets look at what we have
#dahdi_tool
This will give a overview of the hardware and if it is configured or not. It will all so show alarms on the hardware.

Now lets configure the card. First edit /etc/dadi/genconf_parameters. This file is used with dahdi_genconf and will produce /etc/dahdi-system.conf
*lc_country nl
You can also set the echo cancelation here MG2 is default
#dahdi_genconf

#dahdi_cfg -vv

DAHDI Tools Version - 2.2.0
DAHDI Version: 2.2.0.1
Echo Canceller(s): MG2
Configuration
======================
Channel map:

Channel 01: FXO Kewlstart (Default) (Echo Canceler: mg2) (Slaves: 01)
Channel 02: FXO Kewlstart (Default) (Echo Canceler: mg2) (Slaves: 02)

2 channels to configure.

Setting echocan for channel 1 to mg2
Setting echocan for channel 2 to mg2

Check if the right module is loaded.
#cat /etc/dahdi/modules

You can configure the options of dahdi in /etc/asterisk/chan_dahdi.conf
for example turn off the echo cancelation

You can also check teh channels in asterisk
#asterisk -r
#server*CLI> dahdi show channels
Or set the verbose level on asterisk to see more output
#server*CLI> core set verbose 10

= Asterisk dialplans - contexts =

A dial plan consists of a number of extensions. Each extensions consists of a number of priorities. Extensions are grouped in contexts. For each priority, an application is called.
[context]
exten => id, priority, command

When Asterisk receives an incoming connection on a channel, Asterisk looks at the context defined for that channel for commands telling Asterisk what it should do. The context defines different sets of commands depending on what extension the user has dialed. For example, a context might provide one set of commands for what to do if the user dials "123", and another set of commands for what to do if the user dials "9", and another set of commands for what to do if the user dials any number beginning with "555".

For some kinds of connections — such incoming calls from an outside telephone line — the user has not dialed an extension. In that case, Asterisk behaves as if the user had dialed a special extension named "s" (for Start). Asterisk will look for an extension "number" s in the definition of the context for that channel for instructions about what it should do to handle the call.

Let's say, for example, that you have a channel "Zap/1" which is a connection to a telephone handset in your building. And let's say that in the configuration file for Zap channels (zapata.conf), you have defined context=john for Zap channel 1. So when you use that handset to dial a number, Asterisk looks for a context with the name "john" in extensions.conf to find out what it should do. You begin the definition of a context in extensions.conf by putting the name of the context in square brackets on a line by itself, like this:
[john]

== extensions.conf ==

[globals]

[general]
autofallthrough=yes

[default]
include => fromxs4all

[fromxs4all]
exten => 08787XXXXX,1,Dial(DAHDI/2)
exten => 08787XXXXX,n,Hangup()

[outgoing]
exten => _X.,1,Dial(sip/xs4all/${EXTEN},60,r)

[internal]
exten => 6004,1,Dial(sip/6004)
exten => 6003,1,Dial(sip/6003)
exten => 6005,1,Dial(DAHDI/2)
exten => 6006,1,Answer()
exten => 6006,n,Playback(hello-world)
exten => 6006,n,Hangup()

[phones]
include => internal
include => fromxs4all
include => outgoing

Asterisk basic configuration

2009-07-13T09:42:01Z

Insomnia: /* sip.conf */

= Asterisk basic configuration principles =
In this section we'll have a look at the basic configuration of an Asterisk PBX. Contrary to the TFOT-book, we'll be looking at it from the theory side, and from there go to an example configuration. For this example configuration, we'll start from a server with on the "outside" a POTS line and a SIP account with an Internet provider, and on the "inside" two analogue telephones and a SIP softphone. Our goal is to let the PBX behave as if we don't even have a PBX, but a standard home situation: for an incoming call, all phones ring; and every internal phone can make calls to the outside.

= Asterisk channel configuration basics =
The first thing to realise is that Asterisk sees each connected telephony device as a "channel". But what is a Channel? To Asterisk, a channel is a connection which brings in a call to the Asterisk PBX. A channel could be a connection to an ordinary telephone handset or an ordinary telephone line, or to a logical call (like an Internet phone call). Asterisk makes no distinction between "FXO" and "FXS" style channels (that is, it doesn't distinguish between telephone lines and telephones). Every call is placed or received on a distinct channel.

The second thing to realise, is that every type of device attached to the Asterisk PBX have their own specific configuration files. Correctly setting up each (set of) telephony devices makes them available in our Asterisk PBX as channels. Thus, the device configuration files serve as a kind of abstraction layer, and simplify our final Asterisk configuration by putting "channel-specific" information in separate files.

If you've followed the previous Asterisk sections in this Wiki, or followed the first four chapters of the TFOT-book, then you've encountered the following configuration files:
* ''zaptel.conf'' - in this file, you can set up the most basic parameters for your Zap-type hardware channels, most notably Digium telephony cards. You're configuring the hardware itself, via its driver. You could think of this file as belonging to the hardware, not Asterisk. If you'd have other software on your machine besides Asterisk that could make use of your telephony hardware, then that'd be influenced as well when you change ''zaptel.conf''.
* ''zapata.conf'' (and possibly ''zapata-channels.conf'' if you're on Debian) - this file handles the Asterisk-specific configuration of the hardware telephony channels. It thus "sets up the Zap channels" that Asterisk sees - for incoming and outgoing calls. All parameters that set up the channel are specified here.
* ''vpb.conf'' - this file is used to configure [http://www.voicetronix.com/ Voicetronix] cards with Asterisk. If you've a Voicetronix card in use, then you've also installed the Voicetronix drivers. This makes the card(s) useable under Linux. But to have Asterisk use the card(s), you need this ''vpb.conf'' file. It thus serves the same purpose as ''zapata.conf''.
* ''sip.conf'' - this file contains all information on all SIP devices that we want to connect to our Asterisk server; be it one or more SIP accounts with Internet providers, or SIP capable telephones (hardware or software). When ''sip.conf'' has been set up correctly, we can refer to a SIP device by a friendly name like [1000] or [Jane].
* ''iax.conf'' - this file is just the same as the ''sip.conf'' file, only it handles devices that talk IAX2 protocol instead of the SIP protocol.
These five files define all channels that our basic Asterisk PBX might handle (well, it won't even handle the last one, since we're not connecting any other Asterisk boxes or IAX-(soft)phones to our PBX, and it won't handle the third one if you don't have a Voicetronix card).

As a reference, we're going to list the contents of four example files, and explain what they do in the way of preparing channels for our simple Asterisk server.:
==zaptel.conf==
# Autogenerated by ./genzaptelconf -- do not hand edit
# Zaptel Configuration File
#
# This file is parsed by the Zaptel Configurator, ztcfg
#

# It must be in the module loading order

# Span 1: WCTDM/0 "Wildcard TDM410P Board 1" (MASTER)
fxoks=1
fxoks=2
fxsks=3
# channel 4, WCTDM, no module.

# Global data

loadzone = nl
defaultzone = nl
This is a relatively simple file, configuring three Digium modules. As you can see, the ''genzaptelconf'' command has generated it for us. It belongs with a Digium TDM410P card, which has two FXS modules in positions 1 and 2, and one FXO module in position 3. The first two non-commented lines define the protocol that the FXS modules must "talk" with the attached devices, which "naturally" is the FXO protocol (yes, FXS talks FXO, and FXO talks FXS... a bit like electric current flowing from negative to positive. It's just a matter of definitions). 
The third line defines that the FXO module talks FXS protocol. 
The fourth line configures a set of indications to use for the defined channels. Since we're loading "nl", we're configuring Dutch dialtones etcetera for the channels. 
Finally, the last line tell the server that any channel that does not have a zone assigned to it, should have the specified default zone configured - Dutch as well in this example. 
With this simple file, the driver for our example card (''wctdm24xxp'', by the way) can set up the hardware just as we want it. Now to tell Asterisk how to use it...
==zapata-channels.conf==
; Autogenerated by ./genzaptelconf -- do not hand edit
; Zaptel Channels Configurations (zapata.conf)
;
; This is not intended to be a complete zapata.conf. Rather, it is intended
; to be #include-d by /etc/zapata.conf that will include the global settings
;

; Span 1: WCTDM/0 "Wildcard TDM410P Board 1" (MASTER)
;;; line="1 WCTDM/0/0"
signalling=fxo_ks
callerid="Channel 1" <6001>
mailbox=6001
group=5
context=from-internal
channel => 1
callerid=
mailbox=
group=
context=default

;;; line="2 WCTDM/0/1"
signalling=fxo_ks
callerid="Channel 2" <6002>
mailbox=6002
group=5
context=from-internal
channel => 2
callerid=
mailbox=
group=
context=default

;;; line="3 WCTDM/0/2"
signalling=fxs_ks
callerid=asreceived
group=0
context=from-pstn
channel => 3
context=default
This second file is also auto-generated. It sets up three channels, associated with the three Digium hardware modules that we've configured with ''zaptel.conf''. Here, we also see how the channel numbers get assigned to the physical ports. The first module gets to be Zap channel 1 ('''Zap/1'''), the second '''Zap/2''' and so on. So if we would like our FXO module to be channel 1, and our FXS modules 2 and three, we could rotate the three channel numbers in this file. Probably we'd then also want to rotate the ''callerid''`s though... Furthermore, we don't think it's a good idea to assign channels to Zap devices in a different order than the devices are found in the system - meaning "stick with the default numbering as much as possible".

Note that the way ''zapata-channels.conf'' is interpreted, means that any statement like ''signalling=fxs_ks'' actually ''sets'' the ''signalling'' parameter; when the ''channel => 1'' line is reached, then all preceding parameter assignments are applied to that particular channel. This also means that if you somewhere have set a channel to belong to context "foo", and then never set a context again, then every next channel also gets assigned to "foo". So remember: if you don't see a parameter being set with a specific channel, you CANNOT assume that it then has it's default value; if a preceding channel has set that parameter to value "bar", then for your specific channel, it is "bar" also.

An interesting thing to see here is how ''genzaptelconf'' deals with the above concept. After defining each channel, it resets the most important parameters (a.o. the ones that should be unique with a channel) to empty or "default". This means that if you yourself are very meticulous, you could do without that safety net, and rewrite the above configuration file as:
signalling=fxo_ks
callerid="Channel 1" <6001>
mailbox=6001
group=5
context=from-internal
channel => 1

signalling=fxo_ks
callerid="Channel 2" <6002>
mailbox=6002
group=5
context=from-internal
channel => 2

signalling=fxs_ks
callerid=asreceived
group=0
context=from-pstn
channel => 3
Note: we like the thoroughnes of the ''genzaptelconf'' configuration, but we like the readability of the second file more.

==zapata.conf==
[trunkgroups]

[channels]
switchtype=national
rxwink=300 ; Atlas seems to use long (250ms) winks
usecallerid=yes
hidecallerid=no
callwaiting=yes
usecallingpres=yes
callwaitingcallerid=yes
threewaycalling=yes
transfer=yes
canpark=yes
cancallforward=yes
callreturn=yes
echocancel=yes
echocancelwhenbridged=yes
rxgain=0.0
txgain=0.0
callgroup=1
pickupgroup=1
immediate=no
#include zapata-channels.conf
Under Debian,

==sip.conf==

This is a sample configuration for VOIP with XS4ALL

;;/etc/asterisk/sip.conf;;
[general]
context=default
externip=setyoureiphere
dtfmmode=inband
localnet=192.168.70.0/24
port=5060
bindaddr=0.0.0.0
disallow=all
allow=alaw
allow=ulaw
registerattempts=0
defaultexpiry=7200
register => 08787XXXXX:PASSWORD@sip.xs4all.nl/08787XXXXX

[xs4all]
type=friend
username=08787XXXXX
fromuser=08787XXXXX
fromdomain=sip.xs4all.nl
secret=PASSWORD
host=sip.xs4all.nl
insecure=invite
context=fromxs4all
canreinvite=no
dtmfmode=inband
disallow=all
allow=alaw
allow=ulaw

== DAHDI ==

From asterisk version 1.4 zaptel is renamed in DAHDI witch stands for Digium Asterisk Hardware Device Interface.
If you installed the dahdi-tools (highly recommended) then you can configure you're hardware

Conversion from zaptel
/etc/zaptel.conf Becomes /etc/dahdi/system.conf
/etc/asterisk/zapata.conf Becomes /etc/asterisk/chan_dahdi.conf

Lets look at what we have
#dahdi_tool
This will give a overview of the hardware and if it is configured or not. It will all so show alarms on the hardware.

Now lets configure the card. First edit /etc/dadi/genconf_parameters. This file is used with dahdi_genconf and will produce /etc/dahdi-system.conf
*lc_country nl
You can also set the echo cancelation here MG2 is default
#dahdi_genconf

#dahdi_cfg -vv

DAHDI Tools Version - 2.2.0
DAHDI Version: 2.2.0.1
Echo Canceller(s): MG2
Configuration
======================
Channel map:

Channel 01: FXO Kewlstart (Default) (Echo Canceler: mg2) (Slaves: 01)
Channel 02: FXO Kewlstart (Default) (Echo Canceler: mg2) (Slaves: 02)

2 channels to configure.

Setting echocan for channel 1 to mg2
Setting echocan for channel 2 to mg2

Check if the right module is loaded.
#cat /etc/dahdi/modules

You can configure the options of dahdi in /etc/asterisk/chan_dahdi.conf
for example turn off the echo cancelation

= Asterisk dialplans - contexts =

A dial plan consists of a number of extensions. Each extensions consists of a number of priorities. Extensions are grouped in contexts. For each priority, an application is called.
[context]
exten => id, priority, command

When Asterisk receives an incoming connection on a channel, Asterisk looks at the context defined for that channel for commands telling Asterisk what it should do. The context defines different sets of commands depending on what extension the user has dialed. For example, a context might provide one set of commands for what to do if the user dials "123", and another set of commands for what to do if the user dials "9", and another set of commands for what to do if the user dials any number beginning with "555".

For some kinds of connections — such incoming calls from an outside telephone line — the user has not dialed an extension. In that case, Asterisk behaves as if the user had dialed a special extension named "s" (for Start). Asterisk will look for an extension "number" s in the definition of the context for that channel for instructions about what it should do to handle the call.

Let's say, for example, that you have a channel "Zap/1" which is a connection to a telephone handset in your building. And let's say that in the configuration file for Zap channels (zapata.conf), you have defined context=john for Zap channel 1. So when you use that handset to dial a number, Asterisk looks for a context with the name "john" in extensions.conf to find out what it should do. You begin the definition of a context in extensions.conf by putting the name of the context in square brackets on a line by itself, like this:
[john]

== extensions.conf ==

[globals]

[general]
autofallthrough=yes

[default]
include => fromxs4all

[fromxs4all]
exten => 08787XXXXX,1,Dial(DAHDI/2)
exten => 08787XXXXX,n,Hangup()

[outgoing]
exten => _X.,1,Dial(sip/xs4all/${EXTEN},60,r)

[internal]
exten => 6004,1,Dial(sip/6004)
exten => 6003,1,Dial(sip/6003)
exten => 6005,1,Dial(DAHDI/2)
exten => 6006,1,Answer()
exten => 6006,n,Playback(hello-world)
exten => 6006,n,Hangup()

[phones]
include => internal
include => fromxs4all
include => outgoing

Asterisk basic configuration

2009-07-13T09:40:47Z

Insomnia: /* extensions.conf */

= Asterisk basic configuration principles =
In this section we'll have a look at the basic configuration of an Asterisk PBX. Contrary to the TFOT-book, we'll be looking at it from the theory side, and from there go to an example configuration. For this example configuration, we'll start from a server with on the "outside" a POTS line and a SIP account with an Internet provider, and on the "inside" two analogue telephones and a SIP softphone. Our goal is to let the PBX behave as if we don't even have a PBX, but a standard home situation: for an incoming call, all phones ring; and every internal phone can make calls to the outside.

= Asterisk channel configuration basics =
The first thing to realise is that Asterisk sees each connected telephony device as a "channel". But what is a Channel? To Asterisk, a channel is a connection which brings in a call to the Asterisk PBX. A channel could be a connection to an ordinary telephone handset or an ordinary telephone line, or to a logical call (like an Internet phone call). Asterisk makes no distinction between "FXO" and "FXS" style channels (that is, it doesn't distinguish between telephone lines and telephones). Every call is placed or received on a distinct channel.

The second thing to realise, is that every type of device attached to the Asterisk PBX have their own specific configuration files. Correctly setting up each (set of) telephony devices makes them available in our Asterisk PBX as channels. Thus, the device configuration files serve as a kind of abstraction layer, and simplify our final Asterisk configuration by putting "channel-specific" information in separate files.

If you've followed the previous Asterisk sections in this Wiki, or followed the first four chapters of the TFOT-book, then you've encountered the following configuration files:
* ''zaptel.conf'' - in this file, you can set up the most basic parameters for your Zap-type hardware channels, most notably Digium telephony cards. You're configuring the hardware itself, via its driver. You could think of this file as belonging to the hardware, not Asterisk. If you'd have other software on your machine besides Asterisk that could make use of your telephony hardware, then that'd be influenced as well when you change ''zaptel.conf''.
* ''zapata.conf'' (and possibly ''zapata-channels.conf'' if you're on Debian) - this file handles the Asterisk-specific configuration of the hardware telephony channels. It thus "sets up the Zap channels" that Asterisk sees - for incoming and outgoing calls. All parameters that set up the channel are specified here.
* ''vpb.conf'' - this file is used to configure [http://www.voicetronix.com/ Voicetronix] cards with Asterisk. If you've a Voicetronix card in use, then you've also installed the Voicetronix drivers. This makes the card(s) useable under Linux. But to have Asterisk use the card(s), you need this ''vpb.conf'' file. It thus serves the same purpose as ''zapata.conf''.
* ''sip.conf'' - this file contains all information on all SIP devices that we want to connect to our Asterisk server; be it one or more SIP accounts with Internet providers, or SIP capable telephones (hardware or software). When ''sip.conf'' has been set up correctly, we can refer to a SIP device by a friendly name like [1000] or [Jane].
* ''iax.conf'' - this file is just the same as the ''sip.conf'' file, only it handles devices that talk IAX2 protocol instead of the SIP protocol.
These five files define all channels that our basic Asterisk PBX might handle (well, it won't even handle the last one, since we're not connecting any other Asterisk boxes or IAX-(soft)phones to our PBX, and it won't handle the third one if you don't have a Voicetronix card).

As a reference, we're going to list the contents of four example files, and explain what they do in the way of preparing channels for our simple Asterisk server.:
==zaptel.conf==
# Autogenerated by ./genzaptelconf -- do not hand edit
# Zaptel Configuration File
#
# This file is parsed by the Zaptel Configurator, ztcfg
#

# It must be in the module loading order

# Span 1: WCTDM/0 "Wildcard TDM410P Board 1" (MASTER)
fxoks=1
fxoks=2
fxsks=3
# channel 4, WCTDM, no module.

# Global data

loadzone = nl
defaultzone = nl
This is a relatively simple file, configuring three Digium modules. As you can see, the ''genzaptelconf'' command has generated it for us. It belongs with a Digium TDM410P card, which has two FXS modules in positions 1 and 2, and one FXO module in position 3. The first two non-commented lines define the protocol that the FXS modules must "talk" with the attached devices, which "naturally" is the FXO protocol (yes, FXS talks FXO, and FXO talks FXS... a bit like electric current flowing from negative to positive. It's just a matter of definitions). 
The third line defines that the FXO module talks FXS protocol. 
The fourth line configures a set of indications to use for the defined channels. Since we're loading "nl", we're configuring Dutch dialtones etcetera for the channels. 
Finally, the last line tell the server that any channel that does not have a zone assigned to it, should have the specified default zone configured - Dutch as well in this example. 
With this simple file, the driver for our example card (''wctdm24xxp'', by the way) can set up the hardware just as we want it. Now to tell Asterisk how to use it...
==zapata-channels.conf==
; Autogenerated by ./genzaptelconf -- do not hand edit
; Zaptel Channels Configurations (zapata.conf)
;
; This is not intended to be a complete zapata.conf. Rather, it is intended
; to be #include-d by /etc/zapata.conf that will include the global settings
;

; Span 1: WCTDM/0 "Wildcard TDM410P Board 1" (MASTER)
;;; line="1 WCTDM/0/0"
signalling=fxo_ks
callerid="Channel 1" <6001>
mailbox=6001
group=5
context=from-internal
channel => 1
callerid=
mailbox=
group=
context=default

;;; line="2 WCTDM/0/1"
signalling=fxo_ks
callerid="Channel 2" <6002>
mailbox=6002
group=5
context=from-internal
channel => 2
callerid=
mailbox=
group=
context=default

;;; line="3 WCTDM/0/2"
signalling=fxs_ks
callerid=asreceived
group=0
context=from-pstn
channel => 3
context=default
This second file is also auto-generated. It sets up three channels, associated with the three Digium hardware modules that we've configured with ''zaptel.conf''. Here, we also see how the channel numbers get assigned to the physical ports. The first module gets to be Zap channel 1 ('''Zap/1'''), the second '''Zap/2''' and so on. So if we would like our FXO module to be channel 1, and our FXS modules 2 and three, we could rotate the three channel numbers in this file. Probably we'd then also want to rotate the ''callerid''`s though... Furthermore, we don't think it's a good idea to assign channels to Zap devices in a different order than the devices are found in the system - meaning "stick with the default numbering as much as possible".

Note that the way ''zapata-channels.conf'' is interpreted, means that any statement like ''signalling=fxs_ks'' actually ''sets'' the ''signalling'' parameter; when the ''channel => 1'' line is reached, then all preceding parameter assignments are applied to that particular channel. This also means that if you somewhere have set a channel to belong to context "foo", and then never set a context again, then every next channel also gets assigned to "foo". So remember: if you don't see a parameter being set with a specific channel, you CANNOT assume that it then has it's default value; if a preceding channel has set that parameter to value "bar", then for your specific channel, it is "bar" also.

An interesting thing to see here is how ''genzaptelconf'' deals with the above concept. After defining each channel, it resets the most important parameters (a.o. the ones that should be unique with a channel) to empty or "default". This means that if you yourself are very meticulous, you could do without that safety net, and rewrite the above configuration file as:
signalling=fxo_ks
callerid="Channel 1" <6001>
mailbox=6001
group=5
context=from-internal
channel => 1

signalling=fxo_ks
callerid="Channel 2" <6002>
mailbox=6002
group=5
context=from-internal
channel => 2

signalling=fxs_ks
callerid=asreceived
group=0
context=from-pstn
channel => 3
Note: we like the thoroughnes of the ''genzaptelconf'' configuration, but we like the readability of the second file more.

==zapata.conf==
[trunkgroups]

[channels]
switchtype=national
rxwink=300 ; Atlas seems to use long (250ms) winks
usecallerid=yes
hidecallerid=no
callwaiting=yes
usecallingpres=yes
callwaitingcallerid=yes
threewaycalling=yes
transfer=yes
canpark=yes
cancallforward=yes
callreturn=yes
echocancel=yes
echocancelwhenbridged=yes
rxgain=0.0
txgain=0.0
callgroup=1
pickupgroup=1
immediate=no
#include zapata-channels.conf
Under Debian,

==sip.conf==

This is a sample configuration for VOIP with XS4ALL

;;/etc/asterisk/sip.conf;;
[general]
context=default
externip=82.161.20.132
dtfmmode=inband
localnet=192.168.70.0/24
port=5060
bindaddr=0.0.0.0
disallow=all
allow=alaw
allow=ulaw
registerattempts=0
defaultexpiry=7200
register => 08787XXXXX:PASSWORD@sip.xs4all.nl/08787XXXXX

[xs4all]
type=friend
username=08787XXXXX
fromuser=08787XXXXX
fromdomain=sip.xs4all.nl
secret=PASSWORD
host=sip.xs4all.nl
insecure=invite
context=fromxs4all
canreinvite=no
dtmfmode=inband
disallow=all
allow=alaw
allow=ulaw

== DAHDI ==

From asterisk version 1.4 zaptel is renamed in DAHDI witch stands for Digium Asterisk Hardware Device Interface.
If you installed the dahdi-tools (highly recommended) then you can configure you're hardware

Conversion from zaptel
/etc/zaptel.conf Becomes /etc/dahdi/system.conf
/etc/asterisk/zapata.conf Becomes /etc/asterisk/chan_dahdi.conf

Lets look at what we have
#dahdi_tool
This will give a overview of the hardware and if it is configured or not. It will all so show alarms on the hardware.

Now lets configure the card. First edit /etc/dadi/genconf_parameters. This file is used with dahdi_genconf and will produce /etc/dahdi-system.conf
*lc_country nl
You can also set the echo cancelation here MG2 is default
#dahdi_genconf

#dahdi_cfg -vv

DAHDI Tools Version - 2.2.0
DAHDI Version: 2.2.0.1
Echo Canceller(s): MG2
Configuration
======================
Channel map:

Channel 01: FXO Kewlstart (Default) (Echo Canceler: mg2) (Slaves: 01)
Channel 02: FXO Kewlstart (Default) (Echo Canceler: mg2) (Slaves: 02)

2 channels to configure.

Setting echocan for channel 1 to mg2
Setting echocan for channel 2 to mg2

Check if the right module is loaded.
#cat /etc/dahdi/modules

You can configure the options of dahdi in /etc/asterisk/chan_dahdi.conf
for example turn off the echo cancelation

= Asterisk dialplans - contexts =

A dial plan consists of a number of extensions. Each extensions consists of a number of priorities. Extensions are grouped in contexts. For each priority, an application is called.
[context]
exten => id, priority, command

When Asterisk receives an incoming connection on a channel, Asterisk looks at the context defined for that channel for commands telling Asterisk what it should do. The context defines different sets of commands depending on what extension the user has dialed. For example, a context might provide one set of commands for what to do if the user dials "123", and another set of commands for what to do if the user dials "9", and another set of commands for what to do if the user dials any number beginning with "555".

For some kinds of connections — such incoming calls from an outside telephone line — the user has not dialed an extension. In that case, Asterisk behaves as if the user had dialed a special extension named "s" (for Start). Asterisk will look for an extension "number" s in the definition of the context for that channel for instructions about what it should do to handle the call.

Let's say, for example, that you have a channel "Zap/1" which is a connection to a telephone handset in your building. And let's say that in the configuration file for Zap channels (zapata.conf), you have defined context=john for Zap channel 1. So when you use that handset to dial a number, Asterisk looks for a context with the name "john" in extensions.conf to find out what it should do. You begin the definition of a context in extensions.conf by putting the name of the context in square brackets on a line by itself, like this:
[john]

== extensions.conf ==

[globals]

[general]
autofallthrough=yes

[default]
include => fromxs4all

[fromxs4all]
exten => 08787XXXXX,1,Dial(DAHDI/2)
exten => 08787XXXXX,n,Hangup()

[outgoing]
exten => _X.,1,Dial(sip/xs4all/${EXTEN},60,r)

[internal]
exten => 6004,1,Dial(sip/6004)
exten => 6003,1,Dial(sip/6003)
exten => 6005,1,Dial(DAHDI/2)
exten => 6006,1,Answer()
exten => 6006,n,Playback(hello-world)
exten => 6006,n,Hangup()

[phones]
include => internal
include => fromxs4all
include => outgoing

Asterisk basic configuration

2009-07-13T09:32:13Z

Insomnia: /* Asterisk channel configuration basics */

= Asterisk basic configuration principles =
In this section we'll have a look at the basic configuration of an Asterisk PBX. Contrary to the TFOT-book, we'll be looking at it from the theory side, and from there go to an example configuration. For this example configuration, we'll start from a server with on the "outside" a POTS line and a SIP account with an Internet provider, and on the "inside" two analogue telephones and a SIP softphone. Our goal is to let the PBX behave as if we don't even have a PBX, but a standard home situation: for an incoming call, all phones ring; and every internal phone can make calls to the outside.

= Asterisk channel configuration basics =
The first thing to realise is that Asterisk sees each connected telephony device as a "channel". But what is a Channel? To Asterisk, a channel is a connection which brings in a call to the Asterisk PBX. A channel could be a connection to an ordinary telephone handset or an ordinary telephone line, or to a logical call (like an Internet phone call). Asterisk makes no distinction between "FXO" and "FXS" style channels (that is, it doesn't distinguish between telephone lines and telephones). Every call is placed or received on a distinct channel.

The second thing to realise, is that every type of device attached to the Asterisk PBX have their own specific configuration files. Correctly setting up each (set of) telephony devices makes them available in our Asterisk PBX as channels. Thus, the device configuration files serve as a kind of abstraction layer, and simplify our final Asterisk configuration by putting "channel-specific" information in separate files.

If you've followed the previous Asterisk sections in this Wiki, or followed the first four chapters of the TFOT-book, then you've encountered the following configuration files:
* ''zaptel.conf'' - in this file, you can set up the most basic parameters for your Zap-type hardware channels, most notably Digium telephony cards. You're configuring the hardware itself, via its driver. You could think of this file as belonging to the hardware, not Asterisk. If you'd have other software on your machine besides Asterisk that could make use of your telephony hardware, then that'd be influenced as well when you change ''zaptel.conf''.
* ''zapata.conf'' (and possibly ''zapata-channels.conf'' if you're on Debian) - this file handles the Asterisk-specific configuration of the hardware telephony channels. It thus "sets up the Zap channels" that Asterisk sees - for incoming and outgoing calls. All parameters that set up the channel are specified here.
* ''vpb.conf'' - this file is used to configure [http://www.voicetronix.com/ Voicetronix] cards with Asterisk. If you've a Voicetronix card in use, then you've also installed the Voicetronix drivers. This makes the card(s) useable under Linux. But to have Asterisk use the card(s), you need this ''vpb.conf'' file. It thus serves the same purpose as ''zapata.conf''.
* ''sip.conf'' - this file contains all information on all SIP devices that we want to connect to our Asterisk server; be it one or more SIP accounts with Internet providers, or SIP capable telephones (hardware or software). When ''sip.conf'' has been set up correctly, we can refer to a SIP device by a friendly name like [1000] or [Jane].
* ''iax.conf'' - this file is just the same as the ''sip.conf'' file, only it handles devices that talk IAX2 protocol instead of the SIP protocol.
These five files define all channels that our basic Asterisk PBX might handle (well, it won't even handle the last one, since we're not connecting any other Asterisk boxes or IAX-(soft)phones to our PBX, and it won't handle the third one if you don't have a Voicetronix card).

As a reference, we're going to list the contents of four example files, and explain what they do in the way of preparing channels for our simple Asterisk server.:
==zaptel.conf==
# Autogenerated by ./genzaptelconf -- do not hand edit
# Zaptel Configuration File
#
# This file is parsed by the Zaptel Configurator, ztcfg
#

# It must be in the module loading order

# Span 1: WCTDM/0 "Wildcard TDM410P Board 1" (MASTER)
fxoks=1
fxoks=2
fxsks=3
# channel 4, WCTDM, no module.

# Global data

loadzone = nl
defaultzone = nl
This is a relatively simple file, configuring three Digium modules. As you can see, the ''genzaptelconf'' command has generated it for us. It belongs with a Digium TDM410P card, which has two FXS modules in positions 1 and 2, and one FXO module in position 3. The first two non-commented lines define the protocol that the FXS modules must "talk" with the attached devices, which "naturally" is the FXO protocol (yes, FXS talks FXO, and FXO talks FXS... a bit like electric current flowing from negative to positive. It's just a matter of definitions). 
The third line defines that the FXO module talks FXS protocol. 
The fourth line configures a set of indications to use for the defined channels. Since we're loading "nl", we're configuring Dutch dialtones etcetera for the channels. 
Finally, the last line tell the server that any channel that does not have a zone assigned to it, should have the specified default zone configured - Dutch as well in this example. 
With this simple file, the driver for our example card (''wctdm24xxp'', by the way) can set up the hardware just as we want it. Now to tell Asterisk how to use it...
==zapata-channels.conf==
; Autogenerated by ./genzaptelconf -- do not hand edit
; Zaptel Channels Configurations (zapata.conf)
;
; This is not intended to be a complete zapata.conf. Rather, it is intended
; to be #include-d by /etc/zapata.conf that will include the global settings
;

; Span 1: WCTDM/0 "Wildcard TDM410P Board 1" (MASTER)
;;; line="1 WCTDM/0/0"
signalling=fxo_ks
callerid="Channel 1" <6001>
mailbox=6001
group=5
context=from-internal
channel => 1
callerid=
mailbox=
group=
context=default

;;; line="2 WCTDM/0/1"
signalling=fxo_ks
callerid="Channel 2" <6002>
mailbox=6002
group=5
context=from-internal
channel => 2
callerid=
mailbox=
group=
context=default

;;; line="3 WCTDM/0/2"
signalling=fxs_ks
callerid=asreceived
group=0
context=from-pstn
channel => 3
context=default
This second file is also auto-generated. It sets up three channels, associated with the three Digium hardware modules that we've configured with ''zaptel.conf''. Here, we also see how the channel numbers get assigned to the physical ports. The first module gets to be Zap channel 1 ('''Zap/1'''), the second '''Zap/2''' and so on. So if we would like our FXO module to be channel 1, and our FXS modules 2 and three, we could rotate the three channel numbers in this file. Probably we'd then also want to rotate the ''callerid''`s though... Furthermore, we don't think it's a good idea to assign channels to Zap devices in a different order than the devices are found in the system - meaning "stick with the default numbering as much as possible".

Note that the way ''zapata-channels.conf'' is interpreted, means that any statement like ''signalling=fxs_ks'' actually ''sets'' the ''signalling'' parameter; when the ''channel => 1'' line is reached, then all preceding parameter assignments are applied to that particular channel. This also means that if you somewhere have set a channel to belong to context "foo", and then never set a context again, then every next channel also gets assigned to "foo". So remember: if you don't see a parameter being set with a specific channel, you CANNOT assume that it then has it's default value; if a preceding channel has set that parameter to value "bar", then for your specific channel, it is "bar" also.

An interesting thing to see here is how ''genzaptelconf'' deals with the above concept. After defining each channel, it resets the most important parameters (a.o. the ones that should be unique with a channel) to empty or "default". This means that if you yourself are very meticulous, you could do without that safety net, and rewrite the above configuration file as:
signalling=fxo_ks
callerid="Channel 1" <6001>
mailbox=6001
group=5
context=from-internal
channel => 1

signalling=fxo_ks
callerid="Channel 2" <6002>
mailbox=6002
group=5
context=from-internal
channel => 2

signalling=fxs_ks
callerid=asreceived
group=0
context=from-pstn
channel => 3
Note: we like the thoroughnes of the ''genzaptelconf'' configuration, but we like the readability of the second file more.

==zapata.conf==
[trunkgroups]

[channels]
switchtype=national
rxwink=300 ; Atlas seems to use long (250ms) winks
usecallerid=yes
hidecallerid=no
callwaiting=yes
usecallingpres=yes
callwaitingcallerid=yes
threewaycalling=yes
transfer=yes
canpark=yes
cancallforward=yes
callreturn=yes
echocancel=yes
echocancelwhenbridged=yes
rxgain=0.0
txgain=0.0
callgroup=1
pickupgroup=1
immediate=no
#include zapata-channels.conf
Under Debian,

==sip.conf==

This is a sample configuration for VOIP with XS4ALL

;;/etc/asterisk/sip.conf;;
[general]
context=default
externip=82.161.20.132
dtfmmode=inband
localnet=192.168.70.0/24
port=5060
bindaddr=0.0.0.0
disallow=all
allow=alaw
allow=ulaw
registerattempts=0
defaultexpiry=7200
register => 08787XXXXX:PASSWORD@sip.xs4all.nl/08787XXXXX

[xs4all]
type=friend
username=08787XXXXX
fromuser=08787XXXXX
fromdomain=sip.xs4all.nl
secret=PASSWORD
host=sip.xs4all.nl
insecure=invite
context=fromxs4all
canreinvite=no
dtmfmode=inband
disallow=all
allow=alaw
allow=ulaw

== DAHDI ==

From asterisk version 1.4 zaptel is renamed in DAHDI witch stands for Digium Asterisk Hardware Device Interface.
If you installed the dahdi-tools (highly recommended) then you can configure you're hardware

Conversion from zaptel
/etc/zaptel.conf Becomes /etc/dahdi/system.conf
/etc/asterisk/zapata.conf Becomes /etc/asterisk/chan_dahdi.conf

Lets look at what we have
#dahdi_tool
This will give a overview of the hardware and if it is configured or not. It will all so show alarms on the hardware.

Now lets configure the card. First edit /etc/dadi/genconf_parameters. This file is used with dahdi_genconf and will produce /etc/dahdi-system.conf
*lc_country nl
You can also set the echo cancelation here MG2 is default
#dahdi_genconf

#dahdi_cfg -vv

DAHDI Tools Version - 2.2.0
DAHDI Version: 2.2.0.1
Echo Canceller(s): MG2
Configuration
======================
Channel map:

Channel 01: FXO Kewlstart (Default) (Echo Canceler: mg2) (Slaves: 01)
Channel 02: FXO Kewlstart (Default) (Echo Canceler: mg2) (Slaves: 02)

2 channels to configure.

Setting echocan for channel 1 to mg2
Setting echocan for channel 2 to mg2

Check if the right module is loaded.
#cat /etc/dahdi/modules

You can configure the options of dahdi in /etc/asterisk/chan_dahdi.conf
for example turn off the echo cancelation

= Asterisk dialplans - contexts =

A dial plan consists of a number of extensions. Each extensions consists of a number of priorities. Extensions are grouped in contexts. For each priority, an application is called.
[context]
exten => id, priority, command

When Asterisk receives an incoming connection on a channel, Asterisk looks at the context defined for that channel for commands telling Asterisk what it should do. The context defines different sets of commands depending on what extension the user has dialed. For example, a context might provide one set of commands for what to do if the user dials "123", and another set of commands for what to do if the user dials "9", and another set of commands for what to do if the user dials any number beginning with "555".

For some kinds of connections — such incoming calls from an outside telephone line — the user has not dialed an extension. In that case, Asterisk behaves as if the user had dialed a special extension named "s" (for Start). Asterisk will look for an extension "number" s in the definition of the context for that channel for instructions about what it should do to handle the call.

Let's say, for example, that you have a channel "Zap/1" which is a connection to a telephone handset in your building. And let's say that in the configuration file for Zap channels (zapata.conf), you have defined context=john for Zap channel 1. So when you use that handset to dial a number, Asterisk looks for a context with the name "john" in extensions.conf to find out what it should do. You begin the definition of a context in extensions.conf by putting the name of the context in square brackets on a line by itself, like this:
[john]

== extensions.conf ==

[globals]

[general]
autofallthrough=yes

[default]
include => fromxs4all

[fromxs4all]
exten => 0878767430,1,Dial(DAHDI/2)
exten => 0878767430,n,Hangup()

[outgoing]
exten => _X.,1,Dial(sip/xs4all/${EXTEN},60,r)

[internal]
exten => 6004,1,Dial(sip/6004)
exten => 6003,1,Dial(sip/6003)
exten => 6005,1,Dial(DAHDI/2)
exten => 6006,1,Answer()
exten => 6006,n,Playback(hello-world)
exten => 6006,n,Hangup()

[phones]
include => internal
include => fromxs4all
include => outgoing

Asterisk Installation on Lenny

2009-07-13T08:30:07Z

Insomnia: Compile asterisk

Asterisk installation on Lenny can be performed with ease using Aptitude. This brings you Asterisk version 1.4.20. Since this has a graphical GUI manager, it might be wise to add X to your server.

= Compile Asterisk =

You can also compile asterisk and use the latest version.

Get the latest version from http://www.asterisk.org/downloads
#cd /usr/src
Get asterisk version 1.6.1.1
wget http://downloads.asterisk.org/pub/telephony/asterisk/releases/asterisk-1.6.1.1.tar.gz
Get the DAHDI linux drivers
wget http://downloads.asterisk.org/pub/telephony/dahdi-linux/releases/dahdi-linux-2.2.0.1.tar.gz
Get the DAHDI linux tools
wget http://downloads.asterisk.org/pub/telephony/dahdi-tools/releases/dahdi-tools-2.2.0.tar.gz
Get the ISDN drivers (not sure if its still needed even if you don't have ISDN)
wget http://downloads.asterisk.org/pub/telephony/libpri/releases/libpri-1.4.10.1.tar.gz
Get the Addon
wget http://downloads.asterisk.org/pub/telephony/asterisk/releases/asterisk-addons-1.6.1.0.tar.gz

Unpack all the tarballs

Go to the asterisk 1.6.1.1 folder and launch the install script
#./install.pl

Go to the asterisk 1.6.1.1 folder and launch the install script
#./install.pl

Asterisk basic configuration

2009-07-13T08:15:16Z

Insomnia: /* Asterisk dialplans - contexts */

= Asterisk basic configuration principles =
In this section we'll have a look at the basic configuration of an Asterisk PBX. Contrary to the TFOT-book, we'll be looking at it from the theory side, and from there go to an example configuration. For this example configuration, we'll start from a server with on the "outside" a POTS line and a SIP account with an Internet provider, and on the "inside" two analogue telephones and a SIP softphone. Our goal is to let the PBX behave as if we don't even have a PBX, but a standard home situation: for an incoming call, all phones ring; and every internal phone can make calls to the outside.

= Asterisk channel configuration basics =
The first thing to realise is that Asterisk sees each connected telephony device as a "channel". But what is a Channel? To Asterisk, a channel is a connection which brings in a call to the Asterisk PBX. A channel could be a connection to an ordinary telephone handset or an ordinary telephone line, or to a logical call (like an Internet phone call). Asterisk makes no distinction between "FXO" and "FXS" style channels (that is, it doesn't distinguish between telephone lines and telephones). Every call is placed or received on a distinct channel.

The second thing to realise, is that every type of device attached to the Asterisk PBX have their own specific configuration files. Correctly setting up each (set of) telephony devices makes them available in our Asterisk PBX as channels. Thus, the device configuration files serve as a kind of abstraction layer, and simplify our final Asterisk configuration by putting "channel-specific" information in separate files.

If you've followed the previous Asterisk sections in this Wiki, or followed the first four chapters of the TFOT-book, then you've encountered the following configuration files:
* ''zaptel.conf'' - in this file, you can set up the most basic parameters for your Zap-type hardware channels, most notably Digium telephony cards. You're configuring the hardware itself, via its driver. You could think of this file as belonging to the hardware, not Asterisk. If you'd have other software on your machine besides Asterisk that could make use of your telephony hardware, then that'd be influenced as well when you change ''zaptel.conf''.
* ''zapata.conf'' (and possibly ''zapata-channels.conf'' if you're on Debian) - this file handles the Asterisk-specific configuration of the hardware telephony channels. It thus "sets up the Zap channels" that Asterisk sees - for incoming and outgoing calls. All parameters that set up the channel are specified here.
* ''vpb.conf'' - this file is used to configure [http://www.voicetronix.com/ Voicetronix] cards with Asterisk. If you've a Voicetronix card in use, then you've also installed the Voicetronix drivers. This makes the card(s) useable under Linux. But to have Asterisk use the card(s), you need this ''vpb.conf'' file. It thus serves the same purpose as ''zapata.conf''.
* ''sip.conf'' - this file contains all information on all SIP devices that we want to connect to our Asterisk server; be it one or more SIP accounts with Internet providers, or SIP capable telephones (hardware or software). When ''sip.conf'' has been set up correctly, we can refer to a SIP device by a friendly name like [1000] or [Jane].
* ''iax.conf'' - this file is just the same as the ''sip.conf'' file, only it handles devices that talk IAX2 protocol instead of the SIP protocol.
These five files define all channels that our basic Asterisk PBX might handle (well, it won't even handle the last one, since we're not connecting any other Asterisk boxes or IAX-(soft)phones to our PBX, and it won't handle the third one if you don't have a Voicetronix card).

As a reference, we're going to list the contents of four example files, and explain what they do in the way of preparing channels for our simple Asterisk server.:
==zaptel.conf==
# Autogenerated by ./genzaptelconf -- do not hand edit
# Zaptel Configuration File
#
# This file is parsed by the Zaptel Configurator, ztcfg
#

# It must be in the module loading order

# Span 1: WCTDM/0 "Wildcard TDM410P Board 1" (MASTER)
fxoks=1
fxoks=2
fxsks=3
# channel 4, WCTDM, no module.

# Global data

loadzone = nl
defaultzone = nl
This is a relatively simple file, configuring three Digium modules. As you can see, the ''genzaptelconf'' command has generated it for us. It belongs with a Digium TDM410P card, which has two FXS modules in positions 1 and 2, and one FXO module in position 3. The first two non-commented lines define the protocol that the FXS modules must "talk" with the attached devices, which "naturally" is the FXO protocol (yes, FXS talks FXO, and FXO talks FXS... a bit like electric current flowing from negative to positive. It's just a matter of definitions). 
The third line defines that the FXO module talks FXS protocol. 
The fourth line configures a set of indications to use for the defined channels. Since we're loading "nl", we're configuring Dutch dialtones etcetera for the channels. 
Finally, the last line tell the server that any channel that does not have a zone assigned to it, should have the specified default zone configured - Dutch as well in this example. 
With this simple file, the driver for our example card (''wctdm24xxp'', by the way) can set up the hardware just as we want it. Now to tell Asterisk how to use it...
==zapata-channels.conf==
; Autogenerated by ./genzaptelconf -- do not hand edit
; Zaptel Channels Configurations (zapata.conf)
;
; This is not intended to be a complete zapata.conf. Rather, it is intended
; to be #include-d by /etc/zapata.conf that will include the global settings
;

; Span 1: WCTDM/0 "Wildcard TDM410P Board 1" (MASTER)
;;; line="1 WCTDM/0/0"
signalling=fxo_ks
callerid="Channel 1" <6001>
mailbox=6001
group=5
context=from-internal
channel => 1
callerid=
mailbox=
group=
context=default

;;; line="2 WCTDM/0/1"
signalling=fxo_ks
callerid="Channel 2" <6002>
mailbox=6002
group=5
context=from-internal
channel => 2
callerid=
mailbox=
group=
context=default

;;; line="3 WCTDM/0/2"
signalling=fxs_ks
callerid=asreceived
group=0
context=from-pstn
channel => 3
context=default
This second file is also auto-generated. It sets up three channels, associated with the three Digium hardware modules that we've configured with ''zaptel.conf''. Here, we also see how the channel numbers get assigned to the physical ports. The first module gets to be Zap channel 1 ('''Zap/1'''), the second '''Zap/2''' and so on. So if we would like our FXO module to be channel 1, and our FXS modules 2 and three, we could rotate the three channel numbers in this file. Probably we'd then also want to rotate the ''callerid''`s though... Furthermore, we don't think it's a good idea to assign channels to Zap devices in a different order than the devices are found in the system - meaning "stick with the default numbering as much as possible".

Note that the way ''zapata-channels.conf'' is interpreted, means that any statement like ''signalling=fxs_ks'' actually ''sets'' the ''signalling'' parameter; when the ''channel => 1'' line is reached, then all preceding parameter assignments are applied to that particular channel. This also means that if you somewhere have set a channel to belong to context "foo", and then never set a context again, then every next channel also gets assigned to "foo". So remember: if you don't see a parameter being set with a specific channel, you CANNOT assume that it then has it's default value; if a preceding channel has set that parameter to value "bar", then for your specific channel, it is "bar" also.

An interesting thing to see here is how ''genzaptelconf'' deals with the above concept. After defining each channel, it resets the most important parameters (a.o. the ones that should be unique with a channel) to empty or "default". This means that if you yourself are very meticulous, you could do without that safety net, and rewrite the above configuration file as:
signalling=fxo_ks
callerid="Channel 1" <6001>
mailbox=6001
group=5
context=from-internal
channel => 1

signalling=fxo_ks
callerid="Channel 2" <6002>
mailbox=6002
group=5
context=from-internal
channel => 2

signalling=fxs_ks
callerid=asreceived
group=0
context=from-pstn
channel => 3
Note: we like the thoroughnes of the ''genzaptelconf'' configuration, but we like the readability of the second file more.

==zapata.conf==
[trunkgroups]

[channels]
switchtype=national
rxwink=300 ; Atlas seems to use long (250ms) winks
usecallerid=yes
hidecallerid=no
callwaiting=yes
usecallingpres=yes
callwaitingcallerid=yes
threewaycalling=yes
transfer=yes
canpark=yes
cancallforward=yes
callreturn=yes
echocancel=yes
echocancelwhenbridged=yes
rxgain=0.0
txgain=0.0
callgroup=1
pickupgroup=1
immediate=no
#include zapata-channels.conf
Under Debian,

==sip.conf==

This is a sample configuration for VOIP with XS4ALL

;;/etc/asterisk/sip.conf;;
[general]
context=default
externip=82.161.20.132
dtfmmode=inband
localnet=192.168.70.0/24
port=5060
bindaddr=0.0.0.0
disallow=all
allow=alaw
allow=ulaw
registerattempts=0
defaultexpiry=7200
register => 08787XXXXX:PASSWORD@sip.xs4all.nl/08787XXXXX

[xs4all]
type=friend
username=08787XXXXX
fromuser=08787XXXXX
fromdomain=sip.xs4all.nl
secret=PASSWORD
host=sip.xs4all.nl
insecure=invite
context=fromxs4all
canreinvite=no
dtmfmode=inband
disallow=all
allow=alaw
allow=ulaw

= Asterisk dialplans - contexts =

A dial plan consists of a number of extensions. Each extensions consists of a number of priorities. Extensions are grouped in contexts. For each priority, an application is called.
[context]
exten => id, priority, command

When Asterisk receives an incoming connection on a channel, Asterisk looks at the context defined for that channel for commands telling Asterisk what it should do. The context defines different sets of commands depending on what extension the user has dialed. For example, a context might provide one set of commands for what to do if the user dials "123", and another set of commands for what to do if the user dials "9", and another set of commands for what to do if the user dials any number beginning with "555".

For some kinds of connections — such incoming calls from an outside telephone line — the user has not dialed an extension. In that case, Asterisk behaves as if the user had dialed a special extension named "s" (for Start). Asterisk will look for an extension "number" s in the definition of the context for that channel for instructions about what it should do to handle the call.

Let's say, for example, that you have a channel "Zap/1" which is a connection to a telephone handset in your building. And let's say that in the configuration file for Zap channels (zapata.conf), you have defined context=john for Zap channel 1. So when you use that handset to dial a number, Asterisk looks for a context with the name "john" in extensions.conf to find out what it should do. You begin the definition of a context in extensions.conf by putting the name of the context in square brackets on a line by itself, like this:
[john]

== extensions.conf ==

[globals]

[general]
autofallthrough=yes

[default]
include => fromxs4all

[fromxs4all]
exten => 0878767430,1,Dial(DAHDI/2)
exten => 0878767430,n,Hangup()

[outgoing]
exten => _X.,1,Dial(sip/xs4all/${EXTEN},60,r)

[internal]
exten => 6004,1,Dial(sip/6004)
exten => 6003,1,Dial(sip/6003)
exten => 6005,1,Dial(DAHDI/2)
exten => 6006,1,Answer()
exten => 6006,n,Playback(hello-world)
exten => 6006,n,Hangup()

[phones]
include => internal
include => fromxs4all
include => outgoing

Asterisk basic configuration

2009-07-13T08:10:55Z

Insomnia: /* sip.conf */

= Asterisk basic configuration principles =
In this section we'll have a look at the basic configuration of an Asterisk PBX. Contrary to the TFOT-book, we'll be looking at it from the theory side, and from there go to an example configuration. For this example configuration, we'll start from a server with on the "outside" a POTS line and a SIP account with an Internet provider, and on the "inside" two analogue telephones and a SIP softphone. Our goal is to let the PBX behave as if we don't even have a PBX, but a standard home situation: for an incoming call, all phones ring; and every internal phone can make calls to the outside.

= Asterisk channel configuration basics =
The first thing to realise is that Asterisk sees each connected telephony device as a "channel". But what is a Channel? To Asterisk, a channel is a connection which brings in a call to the Asterisk PBX. A channel could be a connection to an ordinary telephone handset or an ordinary telephone line, or to a logical call (like an Internet phone call). Asterisk makes no distinction between "FXO" and "FXS" style channels (that is, it doesn't distinguish between telephone lines and telephones). Every call is placed or received on a distinct channel.

The second thing to realise, is that every type of device attached to the Asterisk PBX have their own specific configuration files. Correctly setting up each (set of) telephony devices makes them available in our Asterisk PBX as channels. Thus, the device configuration files serve as a kind of abstraction layer, and simplify our final Asterisk configuration by putting "channel-specific" information in separate files.

If you've followed the previous Asterisk sections in this Wiki, or followed the first four chapters of the TFOT-book, then you've encountered the following configuration files:
* ''zaptel.conf'' - in this file, you can set up the most basic parameters for your Zap-type hardware channels, most notably Digium telephony cards. You're configuring the hardware itself, via its driver. You could think of this file as belonging to the hardware, not Asterisk. If you'd have other software on your machine besides Asterisk that could make use of your telephony hardware, then that'd be influenced as well when you change ''zaptel.conf''.
* ''zapata.conf'' (and possibly ''zapata-channels.conf'' if you're on Debian) - this file handles the Asterisk-specific configuration of the hardware telephony channels. It thus "sets up the Zap channels" that Asterisk sees - for incoming and outgoing calls. All parameters that set up the channel are specified here.
* ''vpb.conf'' - this file is used to configure [http://www.voicetronix.com/ Voicetronix] cards with Asterisk. If you've a Voicetronix card in use, then you've also installed the Voicetronix drivers. This makes the card(s) useable under Linux. But to have Asterisk use the card(s), you need this ''vpb.conf'' file. It thus serves the same purpose as ''zapata.conf''.
* ''sip.conf'' - this file contains all information on all SIP devices that we want to connect to our Asterisk server; be it one or more SIP accounts with Internet providers, or SIP capable telephones (hardware or software). When ''sip.conf'' has been set up correctly, we can refer to a SIP device by a friendly name like [1000] or [Jane].
* ''iax.conf'' - this file is just the same as the ''sip.conf'' file, only it handles devices that talk IAX2 protocol instead of the SIP protocol.
These five files define all channels that our basic Asterisk PBX might handle (well, it won't even handle the last one, since we're not connecting any other Asterisk boxes or IAX-(soft)phones to our PBX, and it won't handle the third one if you don't have a Voicetronix card).

As a reference, we're going to list the contents of four example files, and explain what they do in the way of preparing channels for our simple Asterisk server.:
==zaptel.conf==
# Autogenerated by ./genzaptelconf -- do not hand edit
# Zaptel Configuration File
#
# This file is parsed by the Zaptel Configurator, ztcfg
#

# It must be in the module loading order

# Span 1: WCTDM/0 "Wildcard TDM410P Board 1" (MASTER)
fxoks=1
fxoks=2
fxsks=3
# channel 4, WCTDM, no module.

# Global data

loadzone = nl
defaultzone = nl
This is a relatively simple file, configuring three Digium modules. As you can see, the ''genzaptelconf'' command has generated it for us. It belongs with a Digium TDM410P card, which has two FXS modules in positions 1 and 2, and one FXO module in position 3. The first two non-commented lines define the protocol that the FXS modules must "talk" with the attached devices, which "naturally" is the FXO protocol (yes, FXS talks FXO, and FXO talks FXS... a bit like electric current flowing from negative to positive. It's just a matter of definitions). 
The third line defines that the FXO module talks FXS protocol. 
The fourth line configures a set of indications to use for the defined channels. Since we're loading "nl", we're configuring Dutch dialtones etcetera for the channels. 
Finally, the last line tell the server that any channel that does not have a zone assigned to it, should have the specified default zone configured - Dutch as well in this example. 
With this simple file, the driver for our example card (''wctdm24xxp'', by the way) can set up the hardware just as we want it. Now to tell Asterisk how to use it...
==zapata-channels.conf==
; Autogenerated by ./genzaptelconf -- do not hand edit
; Zaptel Channels Configurations (zapata.conf)
;
; This is not intended to be a complete zapata.conf. Rather, it is intended
; to be #include-d by /etc/zapata.conf that will include the global settings
;

; Span 1: WCTDM/0 "Wildcard TDM410P Board 1" (MASTER)
;;; line="1 WCTDM/0/0"
signalling=fxo_ks
callerid="Channel 1" <6001>
mailbox=6001
group=5
context=from-internal
channel => 1
callerid=
mailbox=
group=
context=default

;;; line="2 WCTDM/0/1"
signalling=fxo_ks
callerid="Channel 2" <6002>
mailbox=6002
group=5
context=from-internal
channel => 2
callerid=
mailbox=
group=
context=default

;;; line="3 WCTDM/0/2"
signalling=fxs_ks
callerid=asreceived
group=0
context=from-pstn
channel => 3
context=default
This second file is also auto-generated. It sets up three channels, associated with the three Digium hardware modules that we've configured with ''zaptel.conf''. Here, we also see how the channel numbers get assigned to the physical ports. The first module gets to be Zap channel 1 ('''Zap/1'''), the second '''Zap/2''' and so on. So if we would like our FXO module to be channel 1, and our FXS modules 2 and three, we could rotate the three channel numbers in this file. Probably we'd then also want to rotate the ''callerid''`s though... Furthermore, we don't think it's a good idea to assign channels to Zap devices in a different order than the devices are found in the system - meaning "stick with the default numbering as much as possible".

Note that the way ''zapata-channels.conf'' is interpreted, means that any statement like ''signalling=fxs_ks'' actually ''sets'' the ''signalling'' parameter; when the ''channel => 1'' line is reached, then all preceding parameter assignments are applied to that particular channel. This also means that if you somewhere have set a channel to belong to context "foo", and then never set a context again, then every next channel also gets assigned to "foo". So remember: if you don't see a parameter being set with a specific channel, you CANNOT assume that it then has it's default value; if a preceding channel has set that parameter to value "bar", then for your specific channel, it is "bar" also.

An interesting thing to see here is how ''genzaptelconf'' deals with the above concept. After defining each channel, it resets the most important parameters (a.o. the ones that should be unique with a channel) to empty or "default". This means that if you yourself are very meticulous, you could do without that safety net, and rewrite the above configuration file as:
signalling=fxo_ks
callerid="Channel 1" <6001>
mailbox=6001
group=5
context=from-internal
channel => 1

signalling=fxo_ks
callerid="Channel 2" <6002>
mailbox=6002
group=5
context=from-internal
channel => 2

signalling=fxs_ks
callerid=asreceived
group=0
context=from-pstn
channel => 3
Note: we like the thoroughnes of the ''genzaptelconf'' configuration, but we like the readability of the second file more.

==zapata.conf==
[trunkgroups]

[channels]
switchtype=national
rxwink=300 ; Atlas seems to use long (250ms) winks
usecallerid=yes
hidecallerid=no
callwaiting=yes
usecallingpres=yes
callwaitingcallerid=yes
threewaycalling=yes
transfer=yes
canpark=yes
cancallforward=yes
callreturn=yes
echocancel=yes
echocancelwhenbridged=yes
rxgain=0.0
txgain=0.0
callgroup=1
pickupgroup=1
immediate=no
#include zapata-channels.conf
Under Debian,

==sip.conf==

This is a sample configuration for VOIP with XS4ALL

;;/etc/asterisk/sip.conf;;
[general]
context=default
externip=82.161.20.132
dtfmmode=inband
localnet=192.168.70.0/24
port=5060
bindaddr=0.0.0.0
disallow=all
allow=alaw
allow=ulaw
registerattempts=0
defaultexpiry=7200
register => 08787XXXXX:PASSWORD@sip.xs4all.nl/08787XXXXX

[xs4all]
type=friend
username=08787XXXXX
fromuser=08787XXXXX
fromdomain=sip.xs4all.nl
secret=PASSWORD
host=sip.xs4all.nl
insecure=invite
context=fromxs4all
canreinvite=no
dtmfmode=inband
disallow=all
allow=alaw
allow=ulaw

= Asterisk dialplans - contexts =

A dial plan consists of a number of extensions. Each extensions consists of a number of priorities. Extensions are grouped in contexts. For each priority, an application is called.
[context]
exten => id, priority, command

When Asterisk receives an incoming connection on a channel, Asterisk looks at the context defined for that channel for commands telling Asterisk what it should do. The context defines different sets of commands depending on what extension the user has dialed. For example, a context might provide one set of commands for what to do if the user dials "123", and another set of commands for what to do if the user dials "9", and another set of commands for what to do if the user dials any number beginning with "555".

For some kinds of connections — such incoming calls from an outside telephone line — the user has not dialed an extension. In that case, Asterisk behaves as if the user had dialed a special extension named "s" (for Start). Asterisk will look for an extension "number" s in the definition of the context for that channel for instructions about what it should do to handle the call.

Let's say, for example, that you have a channel "Zap/1" which is a connection to a telephone handset in your building. And let's say that in the configuration file for Zap channels (zapata.conf), you have defined context=john for Zap channel 1. So when you use that handset to dial a number, Asterisk looks for a context with the name "john" in extensions.conf to find out what it should do. You begin the definition of a context in extensions.conf by putting the name of the context in square brackets on a line by itself, like this:
[john]

Asterisk basic configuration

2009-07-13T08:09:54Z

Insomnia: /* sip.conf */ xs4all sip.conf

= Asterisk basic configuration principles =
In this section we'll have a look at the basic configuration of an Asterisk PBX. Contrary to the TFOT-book, we'll be looking at it from the theory side, and from there go to an example configuration. For this example configuration, we'll start from a server with on the "outside" a POTS line and a SIP account with an Internet provider, and on the "inside" two analogue telephones and a SIP softphone. Our goal is to let the PBX behave as if we don't even have a PBX, but a standard home situation: for an incoming call, all phones ring; and every internal phone can make calls to the outside.

= Asterisk channel configuration basics =
The first thing to realise is that Asterisk sees each connected telephony device as a "channel". But what is a Channel? To Asterisk, a channel is a connection which brings in a call to the Asterisk PBX. A channel could be a connection to an ordinary telephone handset or an ordinary telephone line, or to a logical call (like an Internet phone call). Asterisk makes no distinction between "FXO" and "FXS" style channels (that is, it doesn't distinguish between telephone lines and telephones). Every call is placed or received on a distinct channel.

The second thing to realise, is that every type of device attached to the Asterisk PBX have their own specific configuration files. Correctly setting up each (set of) telephony devices makes them available in our Asterisk PBX as channels. Thus, the device configuration files serve as a kind of abstraction layer, and simplify our final Asterisk configuration by putting "channel-specific" information in separate files.

If you've followed the previous Asterisk sections in this Wiki, or followed the first four chapters of the TFOT-book, then you've encountered the following configuration files:
* ''zaptel.conf'' - in this file, you can set up the most basic parameters for your Zap-type hardware channels, most notably Digium telephony cards. You're configuring the hardware itself, via its driver. You could think of this file as belonging to the hardware, not Asterisk. If you'd have other software on your machine besides Asterisk that could make use of your telephony hardware, then that'd be influenced as well when you change ''zaptel.conf''.
* ''zapata.conf'' (and possibly ''zapata-channels.conf'' if you're on Debian) - this file handles the Asterisk-specific configuration of the hardware telephony channels. It thus "sets up the Zap channels" that Asterisk sees - for incoming and outgoing calls. All parameters that set up the channel are specified here.
* ''vpb.conf'' - this file is used to configure [http://www.voicetronix.com/ Voicetronix] cards with Asterisk. If you've a Voicetronix card in use, then you've also installed the Voicetronix drivers. This makes the card(s) useable under Linux. But to have Asterisk use the card(s), you need this ''vpb.conf'' file. It thus serves the same purpose as ''zapata.conf''.
* ''sip.conf'' - this file contains all information on all SIP devices that we want to connect to our Asterisk server; be it one or more SIP accounts with Internet providers, or SIP capable telephones (hardware or software). When ''sip.conf'' has been set up correctly, we can refer to a SIP device by a friendly name like [1000] or [Jane].
* ''iax.conf'' - this file is just the same as the ''sip.conf'' file, only it handles devices that talk IAX2 protocol instead of the SIP protocol.
These five files define all channels that our basic Asterisk PBX might handle (well, it won't even handle the last one, since we're not connecting any other Asterisk boxes or IAX-(soft)phones to our PBX, and it won't handle the third one if you don't have a Voicetronix card).

As a reference, we're going to list the contents of four example files, and explain what they do in the way of preparing channels for our simple Asterisk server.:
==zaptel.conf==
# Autogenerated by ./genzaptelconf -- do not hand edit
# Zaptel Configuration File
#
# This file is parsed by the Zaptel Configurator, ztcfg
#

# It must be in the module loading order

# Span 1: WCTDM/0 "Wildcard TDM410P Board 1" (MASTER)
fxoks=1
fxoks=2
fxsks=3
# channel 4, WCTDM, no module.

# Global data

loadzone = nl
defaultzone = nl
This is a relatively simple file, configuring three Digium modules. As you can see, the ''genzaptelconf'' command has generated it for us. It belongs with a Digium TDM410P card, which has two FXS modules in positions 1 and 2, and one FXO module in position 3. The first two non-commented lines define the protocol that the FXS modules must "talk" with the attached devices, which "naturally" is the FXO protocol (yes, FXS talks FXO, and FXO talks FXS... a bit like electric current flowing from negative to positive. It's just a matter of definitions). 
The third line defines that the FXO module talks FXS protocol. 
The fourth line configures a set of indications to use for the defined channels. Since we're loading "nl", we're configuring Dutch dialtones etcetera for the channels. 
Finally, the last line tell the server that any channel that does not have a zone assigned to it, should have the specified default zone configured - Dutch as well in this example. 
With this simple file, the driver for our example card (''wctdm24xxp'', by the way) can set up the hardware just as we want it. Now to tell Asterisk how to use it...
==zapata-channels.conf==
; Autogenerated by ./genzaptelconf -- do not hand edit
; Zaptel Channels Configurations (zapata.conf)
;
; This is not intended to be a complete zapata.conf. Rather, it is intended
; to be #include-d by /etc/zapata.conf that will include the global settings
;

; Span 1: WCTDM/0 "Wildcard TDM410P Board 1" (MASTER)
;;; line="1 WCTDM/0/0"
signalling=fxo_ks
callerid="Channel 1" <6001>
mailbox=6001
group=5
context=from-internal
channel => 1
callerid=
mailbox=
group=
context=default

;;; line="2 WCTDM/0/1"
signalling=fxo_ks
callerid="Channel 2" <6002>
mailbox=6002
group=5
context=from-internal
channel => 2
callerid=
mailbox=
group=
context=default

;;; line="3 WCTDM/0/2"
signalling=fxs_ks
callerid=asreceived
group=0
context=from-pstn
channel => 3
context=default
This second file is also auto-generated. It sets up three channels, associated with the three Digium hardware modules that we've configured with ''zaptel.conf''. Here, we also see how the channel numbers get assigned to the physical ports. The first module gets to be Zap channel 1 ('''Zap/1'''), the second '''Zap/2''' and so on. So if we would like our FXO module to be channel 1, and our FXS modules 2 and three, we could rotate the three channel numbers in this file. Probably we'd then also want to rotate the ''callerid''`s though... Furthermore, we don't think it's a good idea to assign channels to Zap devices in a different order than the devices are found in the system - meaning "stick with the default numbering as much as possible".

Note that the way ''zapata-channels.conf'' is interpreted, means that any statement like ''signalling=fxs_ks'' actually ''sets'' the ''signalling'' parameter; when the ''channel => 1'' line is reached, then all preceding parameter assignments are applied to that particular channel. This also means that if you somewhere have set a channel to belong to context "foo", and then never set a context again, then every next channel also gets assigned to "foo". So remember: if you don't see a parameter being set with a specific channel, you CANNOT assume that it then has it's default value; if a preceding channel has set that parameter to value "bar", then for your specific channel, it is "bar" also.

An interesting thing to see here is how ''genzaptelconf'' deals with the above concept. After defining each channel, it resets the most important parameters (a.o. the ones that should be unique with a channel) to empty or "default". This means that if you yourself are very meticulous, you could do without that safety net, and rewrite the above configuration file as:
signalling=fxo_ks
callerid="Channel 1" <6001>
mailbox=6001
group=5
context=from-internal
channel => 1

signalling=fxo_ks
callerid="Channel 2" <6002>
mailbox=6002
group=5
context=from-internal
channel => 2

signalling=fxs_ks
callerid=asreceived
group=0
context=from-pstn
channel => 3
Note: we like the thoroughnes of the ''genzaptelconf'' configuration, but we like the readability of the second file more.

==zapata.conf==
[trunkgroups]

[channels]
switchtype=national
rxwink=300 ; Atlas seems to use long (250ms) winks
usecallerid=yes
hidecallerid=no
callwaiting=yes
usecallingpres=yes
callwaitingcallerid=yes
threewaycalling=yes
transfer=yes
canpark=yes
cancallforward=yes
callreturn=yes
echocancel=yes
echocancelwhenbridged=yes
rxgain=0.0
txgain=0.0
callgroup=1
pickupgroup=1
immediate=no
#include zapata-channels.conf
Under Debian,

==sip.conf==

This is a sample configuration for VOIP with XS4ALL

;;/etc/asterisk/sip.conf;;
[general]
context=default
externip=82.161.20.132
dtfmmode=inband
localnet=192.168.70.0/24
port=5060
bindaddr=0.0.0.0
disallow=all
allow=alaw
allow=ulaw
registerattempts=0
defaultexpiry=7200
register => 08787XXXXX:PASSWORD@sip.xs4all.nl/08787XXXXX

[xs4all]
type=friend
username=08787XXXXX
fromuser=08787XXXXX
fromdomain=sip.xs4all.nl
secret=PASSWORD
host=sip.xs4all.nl
insecure=invite
context=fromxs4all
canreinvite=no
dtmfmode=inband
disallow=all
allow=alaw
allow=ulaw

= Asterisk dialplans - contexts =

A dial plan consists of a number of extensions. Each extensions consists of a number of priorities. Extensions are grouped in contexts. For each priority, an application is called.
[context]
exten => id, priority, command

When Asterisk receives an incoming connection on a channel, Asterisk looks at the context defined for that channel for commands telling Asterisk what it should do. The context defines different sets of commands depending on what extension the user has dialed. For example, a context might provide one set of commands for what to do if the user dials "123", and another set of commands for what to do if the user dials "9", and another set of commands for what to do if the user dials any number beginning with "555".

For some kinds of connections — such incoming calls from an outside telephone line — the user has not dialed an extension. In that case, Asterisk behaves as if the user had dialed a special extension named "s" (for Start). Asterisk will look for an extension "number" s in the definition of the context for that channel for instructions about what it should do to handle the call.

Let's say, for example, that you have a channel "Zap/1" which is a connection to a telephone handset in your building. And let's say that in the configuration file for Zap channels (zapata.conf), you have defined context=john for Zap channel 1. So when you use that handset to dial a number, Asterisk looks for a context with the name "john" in extensions.conf to find out what it should do. You begin the definition of a context in extensions.conf by putting the name of the context in square brackets on a line by itself, like this:
[john]

Ubuntu

2009-07-01T06:29:08Z

Insomnia: /* Compiz */

== NDISwrapper ==

NDISwrapper is a free software driver wrapper that enables the use of Microsoft Windows drivers for wireless network devices.

Download the windows driver wich contains the .inf file 
Install with ndiswrapper -i drivername.inf 
check the device id with lsusb or lspci -n 
Now execute with ndiswrapper -a deviceid driver
ndiswrapper -a 0bda:8197 net8187b
check the installed drivers
ndiswrapper -l
Write the configuration for modprobe
ndiswrapper -m
And use the module
modprobe ndiswrapper

== Compiz ==

To enable compiz install the Nvidia drivers and install CompizConfig Settings Manager
sudo apt-get install simple-ccsm
Now navigate to system > preferences > Appereance And go to the Visual effects tab. Choose custum there

On Kubuntu change the default windows manager

System Settings -> Default Applications -> Windows manager

{| class="wikitable" style="text-align:center" border="1" cellspacing="0" cellpadding="5"
!style="background:#ffdead;"|Desktop Effects
!style="background:#ffdead;"|Keyboard Shortcuts
|-
|Rotate Cube Manually
|Ctrl + Alt + Left Mouse Button
|-
|Expo
|Super + E (toggle)
|-
|Rotate Cube
|Mousewheel on Desktop
|-
|Film Effect
|Ctrl + Alt + Down Arrow
|-
|Scale Windows
|Alt + Shift + Up Arrow
|-
|Ring Switcher
|Super + Tab - overrides Shift Switcher
|}
Super key is the windows key :-)

== Mount Network Share ==

First install smbfs
apt-get install smbfs
Then create a folder inside of the /media directory to mount the share on or choose you're own directory
sudo mkdir /media/Storage
Create a credentials file in /root so that you can save your password and have it protected by the root account:
sudo gedit /root/.cifscredentials
Add this to the file
username=Guest
password=

sudo vi /etc/fstab
Add the following line
//192.168.0.10/SHARENAME /media/Storage cifs auto,iocharset=utf8,uid=USER,gid=users,credentials=/root/.cifscredentials,file_mode=0775,dir_mode=0775 0 0

To check if the file works
sudo mount -a
And you should see you're drives on the desktop

Ik you get error when you shut down the pc ''CIFS VFS: server not responding'' then you have to unmount first. Do this with the following

ln -s /etc/init.d/umountnfs.sh /etc/rc0.d/K15umountnfs.sh
ln -s /etc/init.d/umountnfs.sh /etc/rc6.d/K15umountnfs.sh

== Citrix Ica client ==

Download the Linux citrix ica client from Citrix
http://citrix.com/English/SS/downloads/details.asp?downloadID=3323&productID=-1

Install the 32bits libraries if youŕe working on a 64bits platform

apt-get install ia32-libs

Install the Open-motif libraries

apt-get install libmotif3

Unpack the package and execute the installation script
./setupwfc
Find the plugin directory of firefox. Probably is /usr/lib/firefox/plugins/ otherwise use
find / -name plugins | grep -i "netscape\|firefox\|mozilla"
Create a symlink to the citrix ica library
ln –s /usr/lib/ICAClient/npica.so npica.so

If you open a connection to your citrix server. The browser will ask you if you want to open or save the session. Browse to the ica client
/usr/lib/ICAClient/wfica
and tell it to use it for all applications.

When you get a ssl error "you have not chosen to thrust....." Then copy the certificate in this location.
/usr/lib/ICAClient/keystore/cacerts/

For 64Bits OS

Install Needed 32-bit Open Motif libraries to /usr/lib32

Setup a temporary environment

mkdir -p ~/tmp/Citrix
cd ~/tmp/Citrix

Download a recent i386 libmotif3 .deb package to the above folder

wget http://mirrors.kernel.org/ubuntu/pool/multiverse/o/openmotif/libmotif3_2.2.3-1.4_i386.deb

Use dpkg to extract the package

dpkg -x libmotif3*i386.deb libmotif

Copy the libraries to /usr/lib32

sudo cp libmotif/usr/lib/*.so.* /usr/lib32/
sudo cp -r libmotif/usr/lib/X11/bindings /usr/lib32/X11/

== Make DVD ==

To make a video DVD you can burn you're image on the dvd. If you just have the VIDEO_TS files then the easiest way is to convert these into a iso.

mkisofs -dvd-video -o ~/moviename.iso /path/to/the/VIDEO_TS

/path/to/the/VIDEO_TS path is for example /moviename not /moviename/VIDEO_TS

Ubuntu

2009-06-29T10:21:01Z

Insomnia: /* Citrix Ica client */

== NDISwrapper ==

NDISwrapper is a free software driver wrapper that enables the use of Microsoft Windows drivers for wireless network devices.

Download the windows driver wich contains the .inf file 
Install with ndiswrapper -i drivername.inf 
check the device id with lsusb or lspci -n 
Now execute with ndiswrapper -a deviceid driver
ndiswrapper -a 0bda:8197 net8187b
check the installed drivers
ndiswrapper -l
Write the configuration for modprobe
ndiswrapper -m
And use the module
modprobe ndiswrapper

== Compiz ==

To enable compiz install the Nvidia drivers and install CompizConfig Settings Manager
sudo apt-get install simple-ccsm
Now navigate to system > preferences > Appereance And go to the Visual effects tab. Choose custum there

{| class="wikitable" style="text-align:center" border="1" cellspacing="0" cellpadding="5"
!style="background:#ffdead;"|Desktop Effects
!style="background:#ffdead;"|Keyboard Shortcuts
|-
|Rotate Cube Manually
|Ctrl + Alt + Left Mouse Button
|-
|Expo
|Super + E (toggle)
|-
|Rotate Cube
|Mousewheel on Desktop
|-
|Film Effect
|Ctrl + Alt + Down Arrow
|-
|Scale Windows
|Alt + Shift + Up Arrow
|-
|Ring Switcher
|Super + Tab - overrides Shift Switcher
|}
Super key is the windows key :-)

== Mount Network Share ==

First install smbfs
apt-get install smbfs
Then create a folder inside of the /media directory to mount the share on or choose you're own directory
sudo mkdir /media/Storage
Create a credentials file in /root so that you can save your password and have it protected by the root account:
sudo gedit /root/.cifscredentials
Add this to the file
username=Guest
password=

sudo vi /etc/fstab
Add the following line
//192.168.0.10/SHARENAME /media/Storage cifs auto,iocharset=utf8,uid=USER,gid=users,credentials=/root/.cifscredentials,file_mode=0775,dir_mode=0775 0 0

To check if the file works
sudo mount -a
And you should see you're drives on the desktop

Ik you get error when you shut down the pc ''CIFS VFS: server not responding'' then you have to unmount first. Do this with the following

ln -s /etc/init.d/umountnfs.sh /etc/rc0.d/K15umountnfs.sh
ln -s /etc/init.d/umountnfs.sh /etc/rc6.d/K15umountnfs.sh

== Citrix Ica client ==

Download the Linux citrix ica client from Citrix
http://citrix.com/English/SS/downloads/details.asp?downloadID=3323&productID=-1

Install the 32bits libraries if youŕe working on a 64bits platform

apt-get install ia32-libs

Install the Open-motif libraries

apt-get install libmotif3

Unpack the package and execute the installation script
./setupwfc
Find the plugin directory of firefox. Probably is /usr/lib/firefox/plugins/ otherwise use
find / -name plugins | grep -i "netscape\|firefox\|mozilla"
Create a symlink to the citrix ica library
ln –s /usr/lib/ICAClient/npica.so npica.so

If you open a connection to your citrix server. The browser will ask you if you want to open or save the session. Browse to the ica client
/usr/lib/ICAClient/wfica
and tell it to use it for all applications.

When you get a ssl error "you have not chosen to thrust....." Then copy the certificate in this location.
/usr/lib/ICAClient/keystore/cacerts/

== Make DVD ==

To make a video DVD you can burn you're image on the dvd. If you just have the VIDEO_TS files then the easiest way is to convert these into a iso.

mkisofs -dvd-video -o ~/moviename.iso /path/to/the/VIDEO_TS

/path/to/the/VIDEO_TS path is for example /moviename not /moviename/VIDEO_TS

Hostap

2009-06-27T19:17:05Z

Insomnia: /* Firmware update */

We want to build a wireless access point (AP) on a debian based server. You can use any wireless pci adapter as long as it supports ''iwconfig ath0 mode master'' If you get a error try another driver. I use the madwifi driver for my atheros based card.

== Hardware ==

Requirements
wireless-tools (for iwconfig)
Bridge-utils
Hostapd
Hostap-utils ??

I used an old netgear wireless pci card. To see wich chipset it has type
lspci
00:0e.0 Ethernet controller: Atheros Communications Inc. AR5212/AR5213 Multiprotocol MAC/baseband processor (rev 01)

The atheros chip uses the madwifi driver http://sourceforge.net
Download the driver and compile the module. Or use the 2.6.27.2 kernel where the atheros chip is supported as a module. Use modprobe ath9k
make install
modprobe ath_pci

To enable ath9k, you must first enable mac80211:

Networking --->
Wireless --->
<M> Improved wireless configuration API
<M> Generic IEEE 802.11 Networking Stack (mac80211)

You can then enable ath9k in the kernel configuration under

Device Drivers --->
[*] Network device support --->
Wireless LAN --->
<M> Atheros 802.11n wireless cards support

Now you should see the card
thinner:/# iwconfig
lo no wireless extensions.

eth0 no wireless extensions.

eth1 no wireless extensions.

wifi0 no wireless extensions.

ath0 IEEE 802.11g ESSID:"" Nickname:""
Mode:Managed Frequency:2.437 GHz Access Point: Not-Associated
Bit Rate:0 kb/s Tx-Power:14 dBm Sensitivity=1/1
Retry:off RTS thr:off Fragment thr:off
Encryption key:off
Power Management:off
Link Quality=0/70 Signal level=-96 dBm Noise level=-96 dBm
Rx invalid nwid:4378 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0

To bring the card up
#ifconfig ath0 up
And to scan for networks
#wlanconfig ath0 list scan
And for more info
#iwlist ath0 scan

#wlanconfig ath0 destroy

#wlanconfig ath0 create wlandev wifi0 wlanmode ap
ath0 IEEE 802.11g ESSID:"" Nickname:""
Mode:Master Frequency:2.412 GHz Access Point: 00:09:5B:C3:97:3E

Now create a new text file named /etc/hostapd/wpa_psk and paste your pass phrase as:
00:00:00:00:00:00 PASSPHRASE

Turn on the routing engine
echo 1 > /proc/sys/net/ipv4/ip_forward

Create the routing rule
route add -net 192.168.70.0 netmask 255.255.255.0 gateway 192.168.70.7 dev eth0

== Firmware update ==

Prism2/2.5/3 cards and Host AP driver support two different mechanism
of upgrading the card firmware. Firmware images (primary and station)
can be downloaded either into volatile memory (RAM download) or
non-volatile memory (flash upgrade). Firmware images downloaded into
volatile memory are lost when the card is resetted, so they are quite
safe. Flash upgrade with incorrect images may cause permanent problems
(i.e., render the card useless), so certain amount of caution is
always recommended for this.

Check your existing firmware
hostap_diag wlan0

I downloaded the softmac firmware and placed it in

mv 2.13.12.0.arm /usr/lib/hotplug/firmware/isl3890

Ubuntu

2009-06-25T07:09:14Z

Insomnia: /* Make DVD */

== NDISwrapper ==

NDISwrapper is a free software driver wrapper that enables the use of Microsoft Windows drivers for wireless network devices.

Download the windows driver wich contains the .inf file 
Install with ndiswrapper -i drivername.inf 
check the device id with lsusb or lspci -n 
Now execute with ndiswrapper -a deviceid driver
ndiswrapper -a 0bda:8197 net8187b
check the installed drivers
ndiswrapper -l
Write the configuration for modprobe
ndiswrapper -m
And use the module
modprobe ndiswrapper

== Compiz ==

To enable compiz install the Nvidia drivers and install CompizConfig Settings Manager
sudo apt-get install simple-ccsm
Now navigate to system > preferences > Appereance And go to the Visual effects tab. Choose custum there

{| class="wikitable" style="text-align:center" border="1" cellspacing="0" cellpadding="5"
!style="background:#ffdead;"|Desktop Effects
!style="background:#ffdead;"|Keyboard Shortcuts
|-
|Rotate Cube Manually
|Ctrl + Alt + Left Mouse Button
|-
|Expo
|Super + E (toggle)
|-
|Rotate Cube
|Mousewheel on Desktop
|-
|Film Effect
|Ctrl + Alt + Down Arrow
|-
|Scale Windows
|Alt + Shift + Up Arrow
|-
|Ring Switcher
|Super + Tab - overrides Shift Switcher
|}
Super key is the windows key :-)

== Mount Network Share ==

First install smbfs
apt-get install smbfs
Then create a folder inside of the /media directory to mount the share on or choose you're own directory
sudo mkdir /media/Storage
Create a credentials file in /root so that you can save your password and have it protected by the root account:
sudo gedit /root/.cifscredentials
Add this to the file
username=Guest
password=

sudo vi /etc/fstab
Add the following line
//192.168.0.10/SHARENAME /media/Storage cifs auto,iocharset=utf8,uid=USER,gid=users,credentials=/root/.cifscredentials,file_mode=0775,dir_mode=0775 0 0

To check if the file works
sudo mount -a
And you should see you're drives on the desktop

Ik you get error when you shut down the pc ''CIFS VFS: server not responding'' then you have to unmount first. Do this with the following

ln -s /etc/init.d/umountnfs.sh /etc/rc0.d/K15umountnfs.sh
ln -s /etc/init.d/umountnfs.sh /etc/rc6.d/K15umountnfs.sh

== Citrix Ica client ==

Download the Linux citrix ica client from Citrix
http://citrix.com/English/SS/downloads/details.asp?downloadID=3323&productID=-1

Unpack the package and execute the installation script
./setupwfc
Find the plugin directory of firefox. Probably is /usr/lib/firefox/plugins/ otherwise use
find / -name plugins | grep -i "netscape\|firefox\|mozilla"
Create a symlink to the citrix ica library
ln –s /usr/lib/ICAClient/npica.so npica.so

If you open a connection to your citrix server. The browser will ask you if you want to open or save the session. Browse to the ica client
/usr/lib/ICAClient/wfica
and tell it to use it for all applications.

When you get a ssl error "you have not chosen to thrust....." Then copy the certificate in this location.
/usr/lib/ICAClient/keystore/cacerts/

== Make DVD ==

To make a video DVD you can burn you're image on the dvd. If you just have the VIDEO_TS files then the easiest way is to convert these into a iso.

mkisofs -dvd-video -o ~/moviename.iso /path/to/the/VIDEO_TS

/path/to/the/VIDEO_TS path is for example /moviename not /moviename/VIDEO_TS

Hostap

2009-06-14T21:04:09Z

Insomnia: /* Hardware */

Debian Lenny base server

2009-04-18T19:22:35Z

Insomnia: /* Partitioning */ added varlog LV

<big>'''Debian Lenny Base Server setup'''</big>

==Getting the hardware==
{| class="wikitable" border="1" |-
|Note: in the following we're assuming you'll be assembling an x86 or x64 type of machine, as it has about the best price/performance ratio you could wish. Hardware costs for other platforms, e.g. IBM's Series p or HP 9000, can be much higher, while platforms like ARM are just not very powerful. Also, the availability of components and of help can be less than with the ubiquietous x86/x64 platforms.
|}
Naturally, before we can begin to install the operating system, we need to obtain the necessary hardware. Which hardware you require depends on what you want the server for; a testserver on which you will test only a single feature for a short while does not need the same quality of hardware as does a server that's supposed to act as a homeserver for many tasks for a long time. We'll assume your server will be like ours: a home server that must perform many tasks with sufficient performance for a few users, that's reliable and will last for a couple of years.
So build or obtain a server with at least the following hardware:
* a spacious casing with big, quiet cooling fans, like the [http://www.coolermaster.com/products/product.php?act=detail&id=317 one we have];
* an efficient, heavy-duty power supply that's rated high enough for your devices, and has a decent efficiency. For example, a [http://www.corsair.com/products/power_supplies.aspx Corsair HX520] power supply;
* a server class motherboard, e.g. an [http://www.intel.com/products/server/index.htm?iid=home+hdr_nav2_server Intel] or [http://uk.asus.com/products.aspx?l1=9&l2=39&l3=263 AMD] based single-processor motherboard. DO NOT go for the cheapest motherboard you can find: if you pay peanuts, that's what you get. Server class motherboards have the quality, stability and durability you'll need from it, and usually also most of the needed peripherals, like multiple ethernet network cards on-board. Usually a Linux server doesn not require much in the way of video performance (and the screen will be used rarely, if ever), so any old integrated graphics will do.
* a matching CPU - or multiple, if you think you need the power and the selected motherboard has the sockets. Furthermore, it pays to think about the energy use of your server CPU. For instance, you could choose an AMD Athlon X2 5600+, running at 2,8 Ghz and 89W maximum, but you can also go for an AMD Athlon X2 4850E, which is dualcore at 2,5GHz, but uses only 45W maximum - almost half of the former! And over a one year period, this choice can save up to 385 kWH. With electricity costing close to €0,20 per kWH (at least for some of us), that could save you €77,- a year. All I'm saying is: think about power use.
* a CD-ROM- or DVD-player - although you might not need it any more after installation.
* ''multiple'' harddisks - you'll want redundancy, because every harddisk fails at some time. The drive with your data on it will fail fatally when it is most inconvenient to you, and any data on it that you consider valuable will likely be lost forever. To make Murphy's work somewhat harder for him, we're going to store our data redundantly, so that if any drive in the server fails, we'll not lose our data or our server. Thus, get yourself at least two harddisks for your operating system, at least 40GiB in size (don't think you'll be able to buy smaller ones nowadays), and spanking new (NEVER use old harddisks for your production server, new ones are just too cheap to run that risk!).
* (multipe) network card(s) (NICs) if your motherboard does not have enough NICs integrated on-board. You'll want a NIC for your network, and another one for your Internet connection; and possible a third one for the wireless segment of your network.
Now build a machine out of the above, or have someone build it for you.

==Preparation of the hardware==

(Note: in the following we're again assuming you're running an x86/x64 type of machine. Hardware requirements and preparation for other platforms, e.g. IBM's Series p or HP 9000, can differ significantly)

Next, check the assembled hardware:
* is the configuration complete? If it does not have a CD/DVDplayer from which it can boot, then installing the software gets more difficult - at least get an USB external DVDdrive or something like that.
* are all components connected properly (memory DIMMs seated correctly in their sockets, AGP card inserted correctly into the AGP slot, et cetera) and are all cable connections made (multiple power cables to the motherboard, one power cable plus one data cable to each hard disk, etcetera)?
Following this, you may hook up the machine. It's going to need power, and you will need at least a keyboard and a monitor attached. And if you want to use a Graphic User Interface to install, a mouse is required also. When you've ensured that everything is safe, you can turn on the machine, and continue to check it:
* do all fans start to run when you turn on the machine? (if not, then '''quickly''' turn off your machine and correct the problem!)
* does/do the hard disk(s) spin up?
* do the power button and reset button operate correctly?
* are the power led, HDD led and other display gadgetry functional?
* when you let the machine power up, does it emit a single beep? And does it then show a Power-On Self Test screen (POST)?
* Does it show the correct amount of memory in the POST screen? The correct number & speed of the CPU(s)?
* Does the machine recognise all controller cards (SCSI, S-ATA etc)? And all attached DVD-drives and hard disks?
* are all BIOSes/firmwares up to date?
* If you have a hardware RAID controller, are your RAID arrays built already?
* does the machine attempt to boot from at least the hard disk?
...et cetera. If there is any problem, or you want to update the BIOS or firmwares, it's best to do it before the operating system is installed. This Wiki, however, is not the place (yet) to get the information on how to accomplish these type of tasks.

The last steps in the preparation of the hardware, are
* to ensure that the machine can boot from CD/DVD, so that you can start installing Debian from it. It is possible to install Debian over the network, but that requires setting up a [http://www.debian-administration.org/articles/478 PXE Boot server] which is (currently) outside the scope of this wiki.
* to connect the hardware to the Internet, so that it can get all required updates etcetera; please do ''not'' connect the box ''straight'' to the Internet, but make sure that it's safely behind a firewall, or failing that, a NAT router.

By now the system should be almost ready to receive it's Operating System. But first we have an issue to tackle: that of redundancy.

==Software or hardware RAID==
Your hard disks will fail. They absolutely will. It is never a question of "if", only of "when". So what will you do when the hard disk containing your complete operating system fails (besides pulling your hair out, that is)?
What we propose is this: hard disks are pretty cheap nowadays, so let's use [http://en.wikipedia.org/wiki/Redundant_array_of_independent_disks RAID technology] to make our hard drive space resilient against failure of a whole drive. So first make sure that you have ''two'' disks of equal size instead of only one. Had you already been planning to use multiple disks already, then make sure you have at least ''one'' disk more than your space requirements prescribe; the space on that extra drive will provide the needed redundancy.
Next, [[RAID fundamentals under Linux | click here]] to learn a bit more about RAID, to make the decision to use hardware-based and/or software-based RAID, and to plan your RAID arrays.
In this example, we'll assume you're using hardware RAID on a RAID controller that's supported by the Debian installation software. This means that the installation software will "see" your RAID array(s) and present them as usable drives.

==Planning your network names==
If your machine must become a part of an existing network, then it's almost certain that you already have a DNS domain in place; in that case: obtain the DNS suffix your machine will get (the DNS domain your machine will "belong" to). However, it's also possible that this machine is going to be the first machine in your new network, in which case the whole issue of DNS suffixes is wide open. If you need more information on DNS, go [[http://www.isc.org/sw/bind/arm95/Bv9ARM-all.html#id2564824 here]]. For now we'll assume you have (or will quickly obtain) a working knowledge of the DNS system.
Here is our tip on choosing a DNS domain for your home network:
* do '''not''' use a publicly registered domain name (e.g. "cocacola.com") for any machine that's not primarily intended to serve the public on the Internet;
* for machines serving a private network, we urge you to use Top Level Domain name "lan" (to signify your machine is on a Local Area Network or LAN)
* for the Domain Name itself, we suggest you use a level 2 name, like "saruman.lan", and not a level 3 name, like "mister.saruman.lan".
This is only a short section on DNS, but remember that once a proper DNS system is in place, it's pretty much work to change it. At any rate, this section has most likely showed you that you need to put some thought into the DNS Domain Name design of your home network.
OK, with this out of the way, we can get to installing the OS.

==Operating System installation==
To install an Operating System (OS), it's kinda instrumental that you have one. Here, we're going to use [http://www.debian.org/intro/about Debian], the biggest [http://www.debian.org/intro/about#free Free] OS that we know of. Free stands for Freedom, but incidentally that Freedom also means it's gratis, an appealing aspect of Free. To get your own copy of Debian, go to their [http://www.debian.org/distrib/ download site] and obtain the latest [http://www.debian.org/releases/ Stable] image - in this wiki it's Debian 5.0, or "Lenny" as it's also known (although it wasn't stable at the time of writing this).

Besides the choice which release of Debian you want to run, you also have to know for which platform you're downloading (in our case: either ''amd64'' or ''i386'' depending on your hardware platform) and what kind of install you wish - if you have a working, fast Internet connection available at the time of install, then we recommend getting the [[http://www.debian.org/CD/netinst/ netinst] CD image; it's a relatively small CD, that'll be able to get you going, but gets most of the software you'll need straight from the 'net at install time.

In the example at hand we're installing on an AMD Athlon x2-based server, on which we wish to install 64-bits software. We'll download [http://cdimage.debian.org/cdimage/weekly-builds/amd64/iso-cd/debian-testing-amd64-CD-1.iso debian-testing-amd64-CD-1.iso], which is Lenny, not yet stable at the time of writing. Burn this to a CD-recordable and boot your prepared hardware platform from this CD.

After booting from the CD, a friendly prompt invites you to indicate how you want to start installing (image 1). Your choices are listed under <F3>; we're going to use the standard Command Line installation, so we choose "install" and hit <enter>.
{| class="wikitable" border="1" |-
|We could easily use "Graphic install", in which case we'd have a nice fresh Graphical User Interface for our installation. ''We're'' not going to, because we're real men, and [http://isg.ee.ethz.ch/tools/realmen/ Real Men Don't Click]. Also, we've found that from the GUI it's hard to switch to a second console and then back.
We could also go to the Advanced options (image 2), and opt for "Expert install" or "Graphical expert install" as installation method, because it gives a much finer grain of control; however we usually don't need that control, and can do without the barrage of extra questions that the "expert" installation method pose.
|}

After the Linux kernel finishes initializing the machine, a simple text-based installer appears (image 3) that immediately starts asking questions. Answer them according to your needs. Our example system uses the following choices:
* Language: english
* country: other > Netherlands
* keymap: American English (since we have a keyboard with US layout)
Some installation software loads, and we get to the next phase: if you have multiple NICs in your machine (which we believe you ''should'' have!!), and if they're detected properly, then you're required to indicate which of the detected network interface cards (NIC) is going to be the "primary" NIC.
{| class="wikitable" border="1" |-
|Here, trouble could begin. If your machine has only network cards that are '''not''' supported, then you'll see '''no''' cards here - but then how are you going to do a NetInstall? A solution would be to (temporarily) install a NIC that ''is'' supported, like a cheap Realtek card, or an old 3Com 905 card. Then, when the whole system is installed, up and running, you could compile a new kernel that contains support for your actual NICs, and when these work, remove the temporary NIC. For now, we'll assume that at least one of your NICs is recognised properly by the Debian installation routine.
|}
Select the card that's connected and has (indirect) access to Internet (again: it should ''not'' be connected straight to the wild wild web, but sit safely behind a firewall, at least until we've installed our own firewall); if at all possible, let it be the NIC that'll be connected to your home network itself, on the ''inside'' of your server. Let's assume that this NIC is designated ''eth0'' by the Debian installation. This card will now be configured using DHCP, so if you're on a network with a DHCP-server, the network will work straight away. If it's not, you can either configure the network manually or fix your DHCP-server and connection between it and ''eth0''.

Next is one of the hardest questions that any OS installation is going to ask you: what will be the host name of the system? You could change it at any time in the future, but with lots of hassle, so you better choose wisely. Here are our tips:
* do '''not''' name your machine after the user that's going to use it, e.g. "bernie-pc" (at some time in the future, Bernie's machine will be moved to Alice, so then Alice is working on "bernie-pc" which makes the situation quite unclear);
* do '''not''' name your machine after the department or workgroup that's using it most, e.g. "accounting-srv" (same reasoning);
* do '''not''' name your machine after it's main function, e.g. "printserver" (at some time in the future, the main function is moved to another machine, and/or an alternative function will become the main function of the machine);
* do '''not''' name your machine after it's location, e.g. "srv-boston" (at some time in the future, the box will be moved to another location);
* do '''not''' name your machine after it's hardware configuration, e.g. "ibmx346" (at some time in the future, either another xSeries x346 will be wheeled in, or the machine will be upgraded to accomodate increased use or overcome hardware problems - your "ibmx346" could suddenly be running on an xSeries x3650).
What we feel are safe names for ''any'' machine in your network are true names, perhaps linked to a common theme: names of European cities, names of movie characters, names of countries or holiday destinations et cetera.

Immediately following comes the question of the Domain Name. This is about a DNS domain, so effectively the installation program is asking which DNS suffix the host name should have; if the DHCP-server already provided something it'll be suggested, but you can override it if need be. In the preparatory phase, you'll have decided on continuation of your current DNS schema, or starting a new one. Either way, put the chosen DNS suffix in and press <enter>.

==Partitioning==
Next comes the question of partitioning, or how to divide the available disk space into chunks for the server to use. This is a tricky subject, because if you put all storage space into one partition, then some day a runaway process will fill up the entire disk with useless logs, and the system will crash. On the other hand, if you divvy up all space into little chunks, then some application is going to need space in one of those partitions where there is none, even though there may be plenty in other partitions.
To prevent both problems from occuring, we're going to use [http://tldp.org/HOWTO/LVM-HOWTO/whatisvolman.html Logical Volume Management (LVM)] so that we can provision enough space to start our server, but keep some space in reserve to apply when needed, where it'll be needed.

So, we at Saruman.biz have put together a recommended standard partitioning scheme. The basis is this:
{| class="wikitable" style="text-align:center" border="1" cellspacing="0" cellpadding="5"
!style="background:#ffdead;"|Partition
!style="background:#ffdead;"|MD
!style="background:#ffdead;"|LVG
!style="background:#ffdead;"|LV-name
!style="background:#ffdead;"|Size (physical machine)
!style="background:#ffdead;"|Size (VM)
!style="background:#ffdead;"|File System
!style="background:#ffdead;"|Mount point
|-
| 1
| /dev/md0
|  
|  
| 100MiB
| 100MiB
| ext3
| /boot
|-
| 2
| /dev/md1
|  
|  
| 3GiB
| 1GiB
| ext3
| /
|-
| rowspan="8" valign="top" | 3
| rowspan="8" valign="top" | /dev/md2
| rowspan="8" valign="top" style="background:lightgrey"| system
| style="background:lightgrey" | swap
| 1GiB<ref name="swap">Rule of thumb: twice the size of the machine's RAM, but no less than 256MiB and no more than 2GiB</ref>
| 256MiB<ref name="swap"/>
| swap
|  
|-
| style="background:lightgrey" | var
| 1GiB
| 512MiB
| ext3
| /var
|-
| style="background:lightgrey" | varlog
| 1GiB
| 512MiB
| ext3
| /var/log
|-
| style="background:lightgrey" | appslog
| 3GiB
| -<ref>Yes, we think a separate ''appslog'' is a very good idea, but when creating a minimal VM, we have to save disk space ''somewhere''...</ref>
| ext3
| /var/appslog
|-
| style="background:lightgrey" | home
| 1GiB<ref name="home">Note that this heavily depends on the purpose of the machine; if it is not to house any users, then (almost) no space is needed for /home. But on the other hand if e.g. a virtual user is to be used for keeping mailstores, or other service users need home space, then /home needs to be big enough for that.</ref>
| 512MiB<ref name="home"/>
| ext3
| /home
|-
| style="background:lightgrey" | usr
| 3GiB
| 3GiB
| ext3
| /usr
|-
| style="background:lightgrey" | tmp
| 1GiB
| 512MiB
| ext3
| /tmp
|-
| style="background:lightgrey" | opt
| 1GiB
| -
| ext3
| /opt
|-
! colspan="4" style="text-align:right"| Total
! 18.1GiB
! 6.9GiB
! colspan="2" |
|-
|}

As you can see, the partition table works as follows: we assume that we wind up with 3 partitions, either on three separate software RAID arrays (''md0'' through ''md2'') or on one single hardware RAID array (in which case the 2nd column ''MD'' does not apply). The size of the partitions depends on your machine's make: for standard physical machines the 5th column does sensible suggestions, even though you could choose to have different sizes and of course different divisions altogether. If your machine happens to be a virtual one, running inside a [http://www.vmware.com/products/server/ VMware Server] or [http://www.vmware.com/products/vi/esx/ VMware ESX host], or the like, then you might want to start out with more modest partitions. The same holds for small servers that must run off Flash drives.

Anyways, we're now at the Debian installation screen that lets us partition our disks. We're ''not'' going to use any of the "guided" partitionings, we go for "manual". Choosing that brings us to a screen showing all drives that the installation routine has detected, and all partitions on those drives that the installer can "see". We're going to do some assuming here once more: let's assume the drive(s) on which you want to install are visible, and are empty (containing no other partitions).

<references/>

===Software RAID partitioning===
If you're to use software RAID, you now have to select the free space on the first drive, press <enter>, and then tell what you want to do with the free space: create a new partition, tell which size you want it to be (see table above), give the type of partition (primary), and give where on the disk it'll sit (the beginning). Next, a screen comes up that details how the partition you're requesting will be created. Here we make some changes: under "use as" we're going to select "physical volume for RAID". This clears all the other options in this screen, except for the "bootable" flag, which must be "on" for the first partition that we'll mount as ''/boot''. Now select "Done setting up the partition".

Next, go to the free space on the second disk, and do ''exactly'' the same, to create an identical physical volume for RAID - if it's the first partition, select the "bootable" flag as well (we'll want to be able to boot from this second disk if the first disk fails, right?).

Then go back to the rest of the free space on the first disk, make the second physical volume for RAID, duplicate it on the second disk. Then, go back to the rest of the free space on the first disk, make the third physical volume for RAID, and again duplicate it on the second disk.

If you now go back to the "partition disks" overview, you'll see all the partitions you've specified listed on their respective disks. But at the top an extra option has appeared, called "configure software RAID". When you now select this option, the installer will ask if it may write the changes you've made to disk. This actually creates the partition tables on the disks.

Note that at the end of configuring your partitions, an extra screen may appear (image 4): this asks if you care to identify which MD RAID devices must be started in order to be able to mount the root filesystem. Answering this question with a list of MD's like "md0 md1 md2" or simply "all" will let your server start the listed MD's very early in the boot sequence.

===Hardware RAID partitioning===
Now, if you have hardware RAID, then on your first (boot) disk just make 3 partitions, in the following manner:

Select the free space on the intended boot disk, press <enter>, select "create a new partition", and fill out the desired size (100MB). Type is primary, location is beginning of the disk, and in the details of the partition, we only need to change the Mount point to "/boot", and set the Bootable flag to "On". Then we're "Done setting up this partition".

The second partition is made the same way, but the desired size is 3GB, the Mount point is "/", and the Bootable flag remains off. Again, we're "Done setting up this partition".

The third partition is again a primary partition, it takes up the entire rest of the disk, but the type is not ext3, but "physical volume for LVM". Again, we're "Done setting up this partition". But now from the main partitioner screen, we can access "Configure the Logical Volume Manager". The installer asks if it can write out the choices made to the disk, and then enters the LVM setup screen, which begins with a summary explaining that you have one Free Physical Volume, and nothing more.

We now create a Volume Group (VG), which (in accordance to our partitioning standard) we'll call "system". In this VG, we'll add all Physical Volumes (being the one partition we've designated so in the previous step) using the space bar. Now we repeat the following process seven times:
* select "Create Logical Volume"
* select Volume Group "System"
* give the LV Name (from the table, e.g. swap, var etc)
* give the LV size (from the table, e.g. 1GB for swap etc)
After this, we can select "Finish", the partitioner creates the seven LVs, and we're back at the partitioner screen, where there are now 7 extra "disks", with names such as ''LVM VG system, LV appslog - 3.2GB Linux device mapper''. Each of these "disks" has one block of empty space, which we now assign: seven times we repeat the following process:
* select the unassigned chunk of empty space of an LV (e.g. appslog) and press <enter>;
* Change "Use as: do not use" into the desired filesystem (ext3 - only the LV "swap" gets as filesystem type "swap area")
* Change the mount point from "none" to the one corresponding with the name of the LV (note: the swap LV has no mountpoint; the appslog mountpoint must be entered manually as "/var/appslog")
* If so desired, a label can be assigned to the partition (we usually don't)
* select "Done setting up the partition"

Once all this is done, we can look over the configuration once more, and then select "Finish partitioning and write changes to disk". A summary configuration screen will show, and we'll affirm with "yes" that these partitions can indeed be formatted. After some formatting screens flashing by (unless your partitions are particularly big, your system is particularly slow, or something goes wrong) the installation procedure continues.

==Final installer steps==
Next comes one '''VERY''' important question: what to use as root password? We cannot stress this enough: choose a SAFE password! Do NOT go for an easy-to-remember one, go for STRONG and SAFE. There are tools to help you generate strong passwords, like [http://www.pctools.com/guides/password/ this page]: use them! We strongly suggest 10 characters or more, including letters, mixed case, and numbers, so something like ''SuCRe4hecH'' (do NOT use this, generate your own!).

Next, give the full name of the principal user of this server (your own, we assume), give the login-name (your given name, we assume), and a corresponding password. Again, use a SAFE password. As long as you don't make your principal user equivalent to root, you might go for a slightly weaker password (8 characters instead of 10), but we rather suggest you make the password just as strong (and different from!) the root password.

After entering the details of these two users "root" and "you", the Debian installer will ask you how it can contact the Debian archives, in the dialoge "configure the package manager". For the NetInstall version of Debian, this is as good as mandatory. So here, we say "yes, use a Network Mirror", and in the following list select the country in which we are (in our case: the Netherlands), so the installer can present us with a number of network mirrors "close by". We select ftp.nl.debian.org. Next screen: should you be behind a proxy server, then it's possible to specify that here. And then the test: the system will say "scanning the mirror..." and try to contact the specified mirror. If it does not succeed, then there is either a network problem, a problem with this box's network card, or you've not specified the mirror or proxy correctly - so fix it. You'll know the network mirror has succesfully been contacted when the next dialogue appears - currently "configuring popularity-contest". Answer this question as you please.

And then one of the last "big" questions: Software Selection. In this dialogue, you can easily select bundles of software to be installed. The choices are currently:
* Desktop environment
* Web server
* Print server
* DNS server
* File server
* Mail server
* SQL database
* Laptop
* Standard system (selected by default)
We have to make a little confession here: we've never before used this option in the installer. In fact, we even deselect the Standard System, so as to minimize the number of software packages that the base installation of our server contains. This makes it more work to manually add packages later, but we feel it gives us more control and understanding of our systems. So if you are like us: deselect the Standard System entry, and select Continue.

The next dialogue handles the installation of the [http://www.gnu.org/software/grub/ ''grub'' bootloader]. Unless your disks weren't empty and you're attempting to make this system multiboot, you'll most likely get a question if you'll allow the installer to install ''grub'' into the boot sector of the first hard disk. We'll confirm with "Yes".

After the installation of grub is completed, the CD-ROM is ejected, and the system is ready to reboot into Debian Etch. Remove the CD and select "Continue"

==Finishing up the installation==
The system should reboot into Debian. This means you should see the following boot sequence:
* your machine's standard POST messages
* then, a blue grub menu on a black screen, with two entries:
** Debian GNU/Linux, kernel 2.6.<something>
** Debian GNU/Linux, kernel 2.6.<something&gt (single-user mode);
* then, after a default time-out, the first grub option will go into effect, and the Linux kernel is started. Lots of cryptic messages in grey-on-black will scroll by, until the last few lines read: "Debian GNU/Linux 4.0 <hostname> tty1" and "<hostname> login:"
If your system does not reach this login, and/or some horrible error messages appear anywhere in this boot sequence, then you've got some extra work ahead. For now we'll assume you've reached the login prompt without problem.

Log in as the principal user (try to avoid logging in as root! That's BAD practice!). Once logged in, save a copy of the boot messages using ''sudo dmesg > boot.txt'' or whatever you like. Then look through the boot messages, e.g. with ''vi -R boot.txt''. Furthermore, [[APT_and_aptitude | use Aptitude]] to make sure ''all'' your software is updated to the latest version.

Done! Your base system is ready. You probably now want to [[essential system software | install essential software]], [[roll your own kernel]] and [[connect your server to the Internet]].

Ubuntu

2008-11-07T19:17:41Z

Insomnia: /* Mount Network Share */

Ubuntu

2008-11-07T17:58:12Z

Insomnia: mount a share

Ubuntu

2008-11-06T19:29:35Z

Insomnia: Citrix client

Ubuntu

2008-11-05T20:03:16Z

Insomnia: Compiz

Ramdrive

2008-11-04T20:59:21Z

Insomnia: Make a initrd ramdrive

Most kernels use a ramdrive to load the modules the need to boot. This is called a initrd image. To make such a ramdrive

mkinitramfs -k -o /boot/initrd.img-2.6.27.4 2.6.27.4

And to update grub and use the ramdrive
update-grub

Hostap

2008-11-02T00:15:03Z

Insomnia: Firmware update

We want to build a wireless access point (AP) on a debian based server. You can use any wireless pci adapter as long as it supports ''iwconfig ath0 mode master'' If you get a error try another driver. I use the madwifi driver for my atheros based card.

== Hardware ==

Requirements
wireless-tools (for iwconfig)
Bridge-utils
Hostapd
Hostap-utils ??

I used an old netgear wireless pci card. To see wich chipset it has type
lspci
00:0e.0 Ethernet controller: Atheros Communications Inc. AR5212/AR5213 Multiprotocol MAC/baseband processor (rev 01)

The atheros chip uses the madwifi driver http://sourceforge.net
Download the driver and compile the module. Or use the 2.6.27.2 kernel where the atheros chip is supported as a module. Use modprobe ath9k
make install
modprobe ath_pci

Now you should see the card
thinner:/# iwconfig
lo no wireless extensions.

eth0 no wireless extensions.

eth1 no wireless extensions.

wifi0 no wireless extensions.

ath0 IEEE 802.11g ESSID:"" Nickname:""
Mode:Managed Frequency:2.437 GHz Access Point: Not-Associated
Bit Rate:0 kb/s Tx-Power:14 dBm Sensitivity=1/1
Retry:off RTS thr:off Fragment thr:off
Encryption key:off
Power Management:off
Link Quality=0/70 Signal level=-96 dBm Noise level=-96 dBm
Rx invalid nwid:4378 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0

To bring the card up
#ifconfig ath0 up
And to scan for networks
#wlanconfig ath0 list scan
And for more info
#iwlist ath0 scan

#wlanconfig ath0 destroy

#wlanconfig ath0 create wlandev wifi0 wlanmode ap
ath0 IEEE 802.11g ESSID:"" Nickname:""
Mode:Master Frequency:2.412 GHz Access Point: 00:09:5B:C3:97:3E

Now create a new text file named /etc/hostapd/wpa_psk and paste your pass phrase as:
00:00:00:00:00:00 PASSPHRASE

Turn on the routing engine
echo 1 > /proc/sys/net/ipv4/ip_forward

Create the routing rule
route add -net 192.168.70.0 netmask 255.255.255.0 gateway 192.168.70.7 dev eth0

== Firmware update ==

Prism2/2.5/3 cards and Host AP driver support two different mechanism
of upgrading the card firmware. Firmware images (primary and station)
can be downloaded either into volatile memory (RAM download) or
non-volatile memory (flash upgrade). Firmware images downloaded into
volatile memory are lost when the card is resetted, so they are quite
safe. Flash upgrade with incorrect images may cause permanent problems
(i.e., render the card useless), so certain amount of caution is
always recommended for this.

Check your existing firmware
hostap_diag wlan0

Hostap

2008-10-26T21:30:32Z

Insomnia:

Hostap

2008-10-26T20:38:03Z

Insomnia: routing

== Hardware ==

Requirements
wireless-tools (for iwconfig)
Bridge-utils
Hostapd
Hostap-utils ??

I used an old netgear wireless pci card. To see wich chipset it has type
lspci
00:0e.0 Ethernet controller: Atheros Communications Inc. AR5212/AR5213 Multiprotocol MAC/baseband processor (rev 01)

The atheros chip uses the madwifi driver http://sourceforge.net
Download the driver and compile the module. Or use the 2.6.27.2 kernel where the atheros chip is supported as a module. Use modprobe ath9k
make install
modprobe ath_pci

Now you should see the card
thinner:/# iwconfig
lo no wireless extensions.

eth0 no wireless extensions.

eth1 no wireless extensions.

wifi0 no wireless extensions.

ath0 IEEE 802.11g ESSID:"" Nickname:""
Mode:Managed Frequency:2.437 GHz Access Point: Not-Associated
Bit Rate:0 kb/s Tx-Power:14 dBm Sensitivity=1/1
Retry:off RTS thr:off Fragment thr:off
Encryption key:off
Power Management:off
Link Quality=0/70 Signal level=-96 dBm Noise level=-96 dBm
Rx invalid nwid:4378 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0

To bring the card up
#ifconfig ath0 up
And to scan for networks
#wlanconfig ath0 list scan
And for more info
#iwlist ath0 scan

#wlanconfig ath0 destroy

#wlanconfig ath0 create wlandev wifi0 wlanmode ap
ath0 IEEE 802.11g ESSID:"" Nickname:""
Mode:Master Frequency:2.412 GHz Access Point: 00:09:5B:C3:97:3E

Now create a new text file named /etc/hostapd/wpa_psk and paste your pass phrase as:
00:00:00:00:00:00 PASSPHRASE

Turn on the routing engine
echo 1 > /proc/sys/net/ipv4/ip_forward

Create the routing rule
route add -net 192.168.70.0 netmask 255.255.255.0 gateway 192.168.70.7 dev eth0

Hostap

2008-10-19T22:27:59Z

Insomnia: kernel support atheros

Hostap

2008-10-19T19:49:55Z

Insomnia:

== Hardware ==

Requirements
wireless-tools (for iwconfig)
Bridge-utils
Hostapd
Hostap-utils ??

I used an old netgear wireless pci card. To see wich chipset it has type
lspci
00:0e.0 Ethernet controller: Atheros Communications Inc. AR5212/AR5213 Multiprotocol MAC/baseband processor (rev 01)

The atheros chip uses the madwifi driver http://sourceforge.net
Download the driver and compile the module.
make install
modprobe ath_pci

Now you should see the card
thinner:/# iwconfig
lo no wireless extensions.

eth0 no wireless extensions.

eth1 no wireless extensions.

wifi0 no wireless extensions.

ath0 IEEE 802.11g ESSID:"" Nickname:""
Mode:Managed Frequency:2.437 GHz Access Point: Not-Associated
Bit Rate:0 kb/s Tx-Power:14 dBm Sensitivity=1/1
Retry:off RTS thr:off Fragment thr:off
Encryption key:off
Power Management:off
Link Quality=0/70 Signal level=-96 dBm Noise level=-96 dBm
Rx invalid nwid:4378 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0

To bring the card up
#ifconfig ath0 up
And to scan for networks
#wlanconfig ath0 list scan
And for more info
#iwlist ath0 scan

#wlanconfig ath0 destroy

#wlanconfig ath0 create wlandev wifi0 wlanmode ap
ath0 IEEE 802.11g ESSID:"" Nickname:""
Mode:Master Frequency:2.412 GHz Access Point: 00:09:5B:C3:97:3E

Now create a new text file named /etc/hostapd/wpa_psk and paste your pass phrase as:
00:00:00:00:00:00 PASSPHRASE

Hostap

2008-10-19T18:31:38Z

Insomnia: Hostap

== Hardware ==

Requirements
wireless-tools (for iwconfig)
Bridge-utils
Hostapd
Hostap-utils ??

I used an old netgear wireless pci card. To see wich chipset it has type
lspci
00:0e.0 Ethernet controller: Atheros Communications Inc. AR5212/AR5213 Multiprotocol MAC/baseband processor (rev 01)

The atheros chip uses the madwifi driver http://sourceforge.net
Download the driver and compile the module.
make install
modprobe ath_pci

Now you should see the card
thinner:/# iwconfig
lo no wireless extensions.

eth0 no wireless extensions.

eth1 no wireless extensions.

wifi0 no wireless extensions.

ath0 IEEE 802.11g ESSID:"" Nickname:""
Mode:Managed Frequency:2.437 GHz Access Point: Not-Associated
Bit Rate:0 kb/s Tx-Power:14 dBm Sensitivity=1/1
Retry:off RTS thr:off Fragment thr:off
Encryption key:off
Power Management:off
Link Quality=0/70 Signal level=-96 dBm Noise level=-96 dBm
Rx invalid nwid:4378 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0

To bring the card up
#ifconfig ath0 up
And to scan for networks
#wlanconfig ath0 list scan
And for more info
#iwlist ath0 scan

#wlanconfig ath0 destroy

#wlanconfig ath0 create wlandev wifi0 wlanmode ap
ath0 IEEE 802.11g ESSID:"" Nickname:""
Mode:Master Frequency:2.412 GHz Access Point: 00:09:5B:C3:97:3E

Ubuntu

2008-10-19T14:20:35Z

Insomnia: /* NDISwrapper */ layout

Ubuntu

2008-10-19T14:18:32Z

Insomnia: