All posts by richard

Mitel 5235, FreePBX and PFSense

These phones are popping up cheaply all over the show. For the money these go for you are getting a lot of phone, however thos buying them and expecting them to just work you will have issues.

This guide will get you up and running AND get the BLF working with the above systems. The information eaqually applies to any Asterisk and Any DHCPD.

To be fair the asterisk side of things is easy, make an account and if you want to use BLF make sure the hints you need are setup. This is covered in many articles. Make a SIP account for the phone and note the details down.

Now you’ll need a working TFTP server. This is usually your FreePBX box so we will work with that assumption. In the root you need the phones firmware (Google will find this easilly). And a number of other files which come with the firmware. You will also want to create a file called MN_Generic.cfg. This will contain all the default settings for all your phones, things that wont change from phone to phone. Feel free to use the one at the end of the article. There are a lot of examples kicking about.

Finally, the per phone data. You can do this two ways. Using a file called MN_<MAC>.cfg will tie the final configuration details to THAT phone. This means that when the phones get to their destination the right phone must go in the right place. If you are doing the final setup now this may be your best bet. Remeber that is a phone dies, you’ll need to rename this file.  The alternative is to use MN_<userid>.cfg. In this case the phone will boot and ask for a user ID. When the user enters their ID the matching .cfg is loaded and the phone reboots with these settings. This is handy if you arent doing the final config. You can ship all phones in the basic setup state and the end user puts the phones wherever and THEN sets the config up. You can also use this to allow users to move between phones. The manual for the phone shows how this works.

Either way you need to create one of the above files. You can add as much or as little as you want. Bare boes it should contain:

<Parameter Model=”5235″>
<user_list>
<User State=”1″ ID=”<ID>” DispName=”<USERNAME>” Pwd=”<PASS>” AuthName=”1008″ Realm=”” RegSvr=”<FREEPBXIP>” RegPort=”5060″ RegScheme=”2″ ProxySvr=”<FREEPBXIP>” ProxyPort=”5060″ ProxyScheme=”2″ VMSvr=”<FREEPBXIP>” VMPort=”5060″ VMScheme=”2″ OutSvr=”” OutPort=”5060″ OutCtr=”0″ Ring=”1″ Line=”0″ EventSvr=”” EventPort=”5060″ EventScheme=”2″ NatMode=”0″ NatType=”option” NatIp=”0″ BlfGroup=””></User>
</user_list>
</Parameter>

Set <ID>, <FREEPBXIP>, <USERNAME> and <PASS> accordingly. <USERNAME> Is displayed by the phone on the LCD  and not used elsewhere. Save this with one of the above.

Right, here we go, reboot or power on the phone.

Setting up the phone:
This is a bit different. You’ll need to use a POE injector and know the phone is in SIP mode. Once you have power disconnect the phone and press the * key and power up holding it down till the phone does something. If you see ‘Erasing PIN’ then the phone needs resetting to SIP. Pull the power out and press * and 7, keep them held down. When asked if you want to revert to sip mode press * for yes and reboot.

Once the phone reboots you’ll likeley see it rejecting DHCP offers, you thought this was simple. You have two choices here. Booting with * held now you can manually set the TFTP server under ‘Modify Static Parameters’. To do it via DHCP you need to add some custom options. In PFSense go to the GUI, go to Service-=> DHCP Server and scroll down to ‘Additional Boot/DHCP Options and click the button. Click the add button. Now we need to add a string, for number 128. The string needs to be of type Host or IP Address and point it to your TFTP server. The same needs to be done for 129, although we arent using it the phone will complain and sulk if it’s not given. The same goes for 130 which should be set to MITEL IP PHONE and is a text field.

Reboot the phone it’ll complain, reboot and then download SIP firmware. It may complain and reboot once or twice but it’ll get there. Once its booted it’ll walk you through some setup steps and log in.  If you are working per user at this point it’ll be asking for a user id. This is why you created the MN_xxxx.cfg file. Enter a user id that has a matching file, eg MN_1000.cfg would be 1000. Click the Submit button on the screen. If you went the MAC route it may reboot again and then you should be up and running.

The only real issues hit here with that is if the phone has not been factory reset it can behave a little oddly, normally things like the built in HTTP server fail. Booting the phone with * held down will get you to the boot menu and you can do a factory restore in there. All PINs/Passwords default to 5235 and the web login defaults to admin/5235. These can be overridden in the config file.

<Parameter Model=”5235″>
<dhcpenable>1</dhcpenable>
<tftp_config>1</tftp_config>
<pppoe_enable>0</pppoe_enable>
<tftp_task_enable>1</tftp_task_enable>
<boot_version>02.01.00.05</boot_version>
<image_version>R8.0.08.00.00.04</image_version>
<tftp_upgrade>0</tftp_upgrade>
<http_upgrade>0</http_upgrade>
<outbound_state>0</outbound_state>
<local_sip_port>5060</local_sip_port>
<tls_port>5061</tls_port>
<tos>0</tos>
<e802_priority>-1</e802_priority>
<vlan_id>-1</vlan_id>
<host_name>MN08000F1C071B</host_name>
<domain>-example.com</domain>
<addr_type>0</addr_type>
<hot_line>0</hot_line>
<hot_address>operator@example.com</hot_address>
<hot_addr_type>0</hot_addr_type>
<tls_private_url></tls_private_url>
<tls_certificate_url></tls_certificate_url>
<tls_ca_cert_url></tls_ca_cert_url>
<tls_root_cert_url></tls_root_cert_url>
<tls_certificate></tls_certificate>
<tls_ca_cert></tls_ca_cert>
<tls_root_cert></tls_root_cert>
<poundkeydial>1</poundkeydial>
<dialtonekey>12</dialtonekey>
<htmlpuseraccess>1</htmlpuseraccess>
<remote_reboot>1</remote_reboot>
<checkpeercert>0</checkpeercert>
<sipkeepalive>1</sipkeepalive>
<rss_feed>http://open.live.bbc.co.uk/weather/feeds/en/2637487/3dayforecast.rss</rss_feed>
<blf_pickup>*8</blf_pickup>
<host_ip>135.199.77.12</host_ip>
<video_ip>135.199.77.12</video_ip>
<sntp>pool.ntp.org</sntp>
<time_zone>0</time_zone>
<auth_method>2</auth_method>
<register_expire>7200</register_expire>
<session_timer>1800</session_timer>
<emerg_number></emerg_number>
<emerg_ip>0.0.0.0</emerg_ip>
<emerg_port>5060</emerg_port>
<audio_codec>5</audio_codec>
<audio_pkt_size>20</audio_pkt_size>
<video_codec>0</video_codec>
<dtmf_type>0</dtmf_type>
<dtmf_payload>101</dtmf_payload>
<advisorymsg>0</advisorymsg>
<reasons>0</reasons>
<other_reason></other_reason>
<do_not_disturb>0</do_not_disturb>
<noans_fwd_mode>0</noans_fwd_mode>
<try_ring_nums>10</try_ring_nums>
<noans_fwd_addr></noans_fwd_addr>
<beep_on_hold>1</beep_on_hold>
<on_hold_alert>60</on_hold_alert>
<system_mode>0</system_mode>
<pppoe_login></pppoe_login>
<pppoe_passwd>******</pppoe_passwd>
<callCountIn>0</callCountIn>
<callCountOut>1</callCountOut>
<discovery>0</discovery>
<pbIndex>0</pbIndex>
<adminId>admin</adminId>
<admin_dispname>Administrator</admin_dispname>
<admin_passwd>923e325e16617477e457f6a468a2d6df</admin_passwd>
<busy_fwd_mode>0</busy_fwd_mode>
<busy_fwd_addr></busy_fwd_addr>
<always_fwd_mode>0</always_fwd_mode>
<always_fwd_addr></always_fwd_addr>
<pcport>0</pcport>
<lanport>0</lanport>
<lcd>14</lcd>
<lcd_brightness>9</lcd_brightness>
<rdkw1></rdkw1>
<rdringtype1>0</rdringtype1>
<rdvmail1>0</rdvmail1>
<rdblock1>0</rdblock1>
<rdkw2></rdkw2>
<rdringtype2>0</rdringtype2>
<rdvmail2>0</rdvmail2>
<rdblock2>0</rdblock2>
<rdkw3></rdkw3>
<rdringtype3>0</rdringtype3>
<rdvmail3>0</rdvmail3>
<rdblock3>0</rdblock3>
<rdkw4></rdkw4>
<rdringtype4>0</rdringtype4>
<rdvmail4>0</rdvmail4>
<rdblock4>0</rdblock4>
<rdkw5></rdkw5>
<rdringtype5>0</rdringtype5>
<rdvmail5>0</rdvmail5>
<rdblock5>0</rdblock5>
<dtringtype1>0</dtringtype1>
<dtringtype2>0</dtringtype2>
<dtringtype3>0</dtringtype3>
<dtringtype4>0</dtringtype4>
<dtringtype5>0</dtringtype5>
<dtringtype6>0</dtringtype6>
<dtringtype7>0</dtringtype7>
<dtringtype8>0</dtringtype8>
<dtringtype9>0</dtringtype9>
<dtringtype10>0</dtringtype10>
<dtringtype11>0</dtringtype11>
<dtringtype12>0</dtringtype12>
<http_task_enable>1</http_task_enable>
<https_task_enable>1</https_task_enable>
<httpport>80</httpport>
<httpsport>443</httpsport>
<telnet_task_enable>1</telnet_task_enable>
<voicemail_ringnum>4</voicemail_ringnum>
<gruu_ctl>1</gruu_ctl>
<proxyrequire_ctl>0</proxyrequire_ctl>
<fwEnable>0</fwEnable>
<fwWanurl></fwWanurl>
<sym_udp>0</sym_udp>
<stunip></stunip>
<fwWanDurl></fwWanDurl>
<fwMode>0</fwMode>
<start_port>20000</start_port>
<end_port>20998</end_port>
<multi_user_enable>0</multi_user_enable>
<upgrade>0</upgrade>
<bksrvtm>3</bksrvtm>
<ntfcfg>0</ntfcfg>
<lancode>en_GB</lancode>
<tonecode>GB</tonecode>
<dsmode>1</dsmode>
<dsmonth>3</dsmonth>
<dsweek>2</dsweek>
<dsday>1</dsday>
<dsemonth>11</dsemonth>
<dseweek>1</dseweek>
<dseday>1</dseday>
<ds_transition_time>2</ds_transition_time>
<flashVer>201</flashVer>
<http_download>sipdnld.mitel.com</http_download>
<tftp>192.168.99.7</tftp>
<downloadtype>1</downloadtype>
<dialpl></dialpl>
<gtEnable>0</gtEnable>
<dtimer>3</dtimer>
<autoanswer>0</autoanswer>
<ringPitch>0</ringPitch>
<keysys_enable>0</keysys_enable>
<pbName1>My Number</pbName1>
<pbaddr1>*65</pbaddr1>
<snmp>0</snmp>
<srtp>0</srtp>
<pkDescription>
<Key Line=”25″ Fea=”6″ Des=”Line  1″ Addr=”” Addr2=”” Mode=”1″ Mode2=”1″ UserID=”1005″></Key>
<Key Line=”26″ Fea=”7″ Des=”Line 2″ Addr=”” Addr2=”” Mode=”1″ Mode2=”1″ UserID=”1005″></Key>
<Key Line=”27″ Fea=”2″ Des=”Call Logs” Addr=”” Addr2=”” Mode=”1″ Mode2=”1″ UserID=””></Key>
<Key Line=”28″ Fea=”3″ Des=”Advisory            ” Addr=”” Addr2=”” Mode=”1″ Mode2=”1″ UserID=””></Key>
<Key Line=”29″ Fea=”4″ Des=”Headset             ” Addr=”” Addr2=”” Mode=”1″ Mode2=”1″ UserID=””></Key>
<Key Line=”30″ Fea=”19″ Des=”Weather” Addr=”http://open.live.bbc.co.uk/weather/feeds/en/2637487/3dayforecast.rss” Addr2=”” Mode=”1″ Mode2=”1″ UserID=””></Key>
<Key Line=”31″ Fea=”19″ Des=”Currency” Addr=”http://www.xe.com/rss.xml” Addr2=”” Mode=”0″ Mode2=”1″ UserID=””></Key>
<Key Line=”32″ Fea=”19″ Des=”News” Addr=”http://feeds.bbci.co.uk/news/rss.xml?edition=uk” Addr2=”” Mode=”0″ Mode2=”1″ UserID=””></Key>
</pkDescription>
<webdialurl></webdialurl>
<cw_tone>1</cw_tone>
<missedcallsctl>1</missedcallsctl>
<callforwardctl>1</callforwardctl>
<lcdbacklightctl>1</lcdbacklightctl>
<time_format>1</time_format>
<csta_enable>0</csta_enable>
<csta_passwd>******</csta_passwd>
<cfg_poll_timer>1440</cfg_poll_timer>
<reboot_phone>1</reboot_phone>
<firmware_timer>1440</firmware_timer>
<firmware_abs_timer_hr>23</firmware_abs_timer_hr>
<firmware_abs_timer_min>59</firmware_abs_timer_min>
<firmware_abs_enable>1</firmware_abs_enable>
<installer_passcode>1234</installer_passcode>  <user_passwd>5d41402abc4b2a76b9719d911017c592</user_passwd>
<sip_mode>sip</sip_mode>
<voicemail_key></voicemail_key>
<html_enable>1</html_enable>
<html_filename></html_filename>
<facDef>90</facDef>
<ipadr></ipadr>
<ipgateway></ipgateway>
<ipmask></ipmask>
<dhcpLease>7200</dhcpLease>
<dhcpT1>0</dhcpT1>
<dhcpT2>0</dhcpT2>
<dhcpSrv></dhcpSrv>
<ipdns></ipdns>
<ipscddns>0.0.0.0</ipscddns>
<cfg_version>R8.0</cfg_version>
<answered_calls>******</answered_calls>
<missed_calls>******</missed_calls>
<made_calls>******</made_calls>
</Parameter>

 

Automated VMWare ESXI Backup

Please note, this gives all the apearance of working then fails after 24 hours or so. It seems there are some funnies with the way / is handled and more investigation is needed.

ESXI has a very limited shell, some things are missing, others arent where they should be. It also seems that the SSH implementation is somehow broken. I’m not sure how so we are left with doing this as a two step backups. The ESXI server makes the backup and a remote host sucks it off (fnarr fnarr)

ESXI is a VERY tightly controlled environment, and resource use is critical. We will be keeping it simple for this procedure.

First up you will need to enable SSH, this is covered here

Start up a vSphere session to this server, select the server itself and click the configuration tab. Click security profile. You can also enable the SSH service here. Now click properties on the far right. In the list find SSH client and check the box. OK this and come out. You should now be able to SSH from the ESXI server.

Now to make our key. You wont find ssh-keygen in the path. We also have no home dir so this is a bit awkward too.

/usr/lib/vmware/openssh/bin/ssh-keygen

When prompted save the key to /.ssh/id_rsa.pub and enter for no password on both counts.

The command we used for the other backups will work here, it just needs some modification…

ssh <yourserverip> mkdir -p .ssh && cat /.ssh/id_rsa.pub | ssh <yourserverip> ‘cat >> .ssh/authorized_keys’ && ssh <yourserverip> chmod -R 700 .ssh

Test it, you should now have the ability to login with no password to your server. This only sadly works for root 🙁

Now, backups, this bit sucks. There are varying reports of this being possible/not possible without stopping the host. Turns out its entireley possible but you need the space to do it. It may actually be worth having a backup disk as an empty filestore for this. as we are going to have to essentiall clone the VM to do this.

Grab the script from here and get it onto your ESXI machine, you can SCP it over now. You’ll want to copy the rsync binary over now too which you can find here. Chuck it in /bin and make sure you rename it to rsync and chmod it. Same with the script and call it backupvm.sh

We are going to edit the script a little just to make our life easier. This means we have just one script to run and the CRON job can then take the VM name as an argument.

Edit lines 13 and 16 to fit your host, then change  line 29:

BACKUP_APPEND=$(date +“%Y%m%d-%H%M%S”)

to
BACKUP_APPEND=“”
and line 99:
tar czpf “$BACKUP_ROOT/$MACHINE-$BACKUP_APPEND.tgz” “$BACKUP_PATH”

to
tar czpf “$BACKUP_ROOT/$MACHINE.tgz” “$BACKUP_PATH”
Our backup is no longer a moving target, this makes our job easier. Run it and make sure all is well, you may want to create a small VM to test it. I had a Win98 vme hand and thus
backupvm win98
This is undoubtedly something were a faster server will help. Its definately something to run after hours. A G2030 takes about 2 mins to do a 4Gb VM however as another plus the resultant filesize is smaller than the raw VM.ls As an aside, the original script didnt remove its temporary folder, after the changes it now does.
Now, time to test rsync. I have a tgz file here called win98.tgz and I’ve a folder on my remote server of /backups/vm/win98.
rsync -avz -e “ssh” –progress win98.tgz root@<yourserver>:/backups/vm/win98
Should do the trick. Let it run and make sure the file has indeed gone over. Re-running the command should result in rsync coming back without doing an upload, the files are consistant. Edit the backup script again and add the following at line 32
BACKUPSERVER=”<yourserverip>”
REMOTEPATH=”<yourbackuppath>”
At what is now line 107 under  echo “removed temp files.” add
echo ” Starting server backup “
/bin/rsync -avz -e “ssh” –progress $BACKUP_ROOT/$MACHINE.tgz root@$BACKUPSERVER:$REMOTEPATH/$MACHINE/$MACHINE.tgz
                        if [ “$?” -eq “0” ]
                                then
                                        echo ” Sync done, deleting local file “
                                        rm $BACKUPROOT/$MACHINE.tgz
                                        logger Backup of $MACHINE to $BACKUPSERVER completed sucesfully
                                else
                                        logger Backup of $MACHINE to $BACKUPSERVER failed!
                                        echo ” Sync failed!     “
                                        echo ” local file NOT deleted”
                                fi
And test it again….
What we are doing now is using your new parameters and the existing one to build the rsync command line. So we have added to the end of the script another step that actually does the backup. All you need do is make sure that the server has a folder for the backup to drop in. If the sync fails the backup file will be left locally. Watch this as a failed sync could cause your storage to vanish as the local copies build up. you may want to just drop the file anyway.
Time for CRON, this should be easy…guess what? 🙂 You cant edit the crontab root file. Here is the official method from VMWare but it doesnt work, the file cant be written to no matter what you do, changes are also not persistent anyhow.
To keep things simple we are going to run our backups from a script. Create /backups.sh and pop the following in there
#!/bin/sh
#
# Backup script
#
/bin/logger Backups starting…
now add each vm you’ll be backing up, this will make them run sequentially
/bin/backupvm.sh <vmname>
Save the file and chmod it. test it if you feel the need. We will be calling this from cron. Now there is no need to do it this way, you could create individual cron jobs for each machine, batch them up, whatever you feel. This is justa  simple way to sequentially do it.
Its worth at this point, benchmarking your backups. Some larger VMs can take a LONG time to complete and transfer and you want to schedule things so you dont get overlaps. Using the method below with one cron job then a backup file will avoid this but its still worth doing so you can get an idea when to start them so they actually finish out of hours.
Now dealing with cron. The crontab lives in /var/spool/cron/crontabs however there are two issues. Firstly, this file is trashed on every boot. Secondly, its not even a real file, you cant actually edit it. You can copy it, edit it then copy it back though. So kludgey as it is, thats what we will do here.  Before we go further you need to know about how to schedule cron jobs.  This Link should help you out. We are going to run this job at 1am every other day from the second day of the month (even days). The schedule we need for cron is  0  1  2-30/2  *  * /backups.sh. Create a new script /addbackupjob.sh and pop in
#!/bin/sh
#
# Script to add the backup job
#
cp /var/spool/cron/crontabs/root /var/spool/cron/crontabs/root.tmp
cp /var/spool/cron/crontabs/root /var/spool/cron/crontabs/root.bak
 echo “0  1    2-30/2   *   *   /backups.sh” >> root.tmp
rm /var/spool/cron/crontabs/root
cp /var/spool/cron/crontabs/root.tmp /var/spool/cron/crontabs/root
 kill $(cat /var/run/crond.pid) && crond
rm /var/spool/cron/crontabs/root.temp
run this and cat /var/spool/cron/crontabs/root and make sure this has done as it should/ it’ll leave a backup file behind just in case.  This link details how to run a script an boot. We need to add /addbackup.sh to /etc/rc.local.d/local.sh. open the file and add it just above the last line, exit 0.
That *should* be it. The cron job will be readded on every reboot.
You can use /bin/logger in the script if you’d like to write to the syslog.
*** UPDATE ***
If you have multiple datastores, this isnt going to work for you. However with some changes it can be made to.
Edit your ./backupvm.sh and make the following changes:

Auto Remote Backups PFSense, FreeNAS, FreePBX – DIY Cloudy goodness

Well its been a while but it has been manic here. However after some faffing with getting some backups working I thought I’d pop this up here as it covers a fair bit.

A customer wants to sync their office server to one of our so their engineers can get to CAD drawings. Now the basics of getting everyone up using SCP et all are pretty simple so I wont go into those. However the sync was problematic. The server is a Windows 2012 server and we popped on cwRsync and Syncovery. No way could we get Rsync to play ball however in the end we made SCP play. This isnt ideal but we will come back to it.

Next up was to put this server to good use and backup various other things. We do have a large number of PFSense, freePBX and Freenas boxen about the place and I thought it would be nice to make these work.

Now, key to this is making SSH work without passwords. You’ll find pretty quickly this isnt exactly non trivial in fact its a royal PITA. Most of the gudes arent quite there or dont work quite right. After a lot of digging I got there with a really simple and elegant solution.

So we need to pair up our client (in this example a PF box but this works on FreeNAS too and *should* work on FreePBX).

Create a user for the backup, using root isnt a good idea at all, remeber this box will have direct access to your server and if you use root and your customer decides to tinker they could in theory do a LOT of damage. Set up a user to use for the backup, we are going to create a backup user called ‘companya’ so on your server do:

useradd companya
passwd companya

You can do the same on the system to be backed up. Its much nicer if it all matches. You can assign multiple keys to an account so you dont need to do this again on the server end. Setting up home dirs is covered elsewhere so I wont go into that. I’ve created a structure in the home dir called backups and in t here used hostnames to identify the device. If you are backing up multiple customers you really should make sure they cant get to eachothers files.

On PFSense you need to do this through the user interface. Make sure that the user’s permissions include shell access else the permissions and default shell for that user will get nuked every reboot.

Now this is where it tends to go a bit runny. We are going to use SSH so we need SSH to be able to log in with just an rsa key. This *should* be easy, however getting FreeNAS to play was a pig. Turns out there is a magic command. So, on the system to be backed up we need to become our new user and make a key…

su companya
ssh-keygen -t rsa

*NOTE: DO NOT SET A PASSWORD!* Now this key has to go into the list of authorised keys at the other end. There seem to be billions of ways to do this but they all gave varying amounts of success. Now provided you created a user on the server and accept the defaults for ssh-keygen the following will do the trick…

ssh <yourserver> mkdir -p .ssh && cat ~/.ssh/id_rsa.pub | ssh <yourserver> ‘cat >> .ssh/authorized_keys’ && ssh <yourserver> chmod -R 700 .ssh

You should be asked for the password for companya twice. This will make the .ssh dir, upload they key and make sure its CHMOD’ed correctly. Note I have seen references to chmoding the authorized_keys file to 600 if you see errors on your /var/log/auth or /var/log/security

Now if all has gone well. you can do:

ssh <serverip>

If you get asked for a password you’ll have to go chase down why. The log files above may help but the usual cause is permissions. Type exit to bring you out of the SU and you are done here.

So now, to backups….

FreeNAS

You can now enable Rsync on your server which is explained elsewhere then use the Rsync Tasks under system to create backup jobs. Make sure you use your new user to do this else nothing will work. Its that simple.

To back up the config requires something a little like the PFSense solution below. As we have Rsync already running over SSH we may as well use that.

Make yourself a directory on a visible share for your backup, you could use this to aggregate a number of backups at this point. As we will be using rsync only changes will be backed up so this may be a good point to put router backups etc. For this we have a volume called adminnas and I’ve created a folder called sysbackups.

Now we need to make a file to DO the backup. It seems sensible to drop this in the backup folder too so things are kept neat. This means less work if the main OS partition goes AWOL.
#!/bin/bash
# Freenas backup script by R.Inskip
# This maintains two copies of the FreeNAS backup file
#
# Change to suit your config
#
SOURCE=/data/freenas-v1.db
TARGETDIR=/mnt/adminnas/sysbackups
TARGETFILE=adminnas.db
BACKUPFILE=adminnas.old.db
#
# If there is an old backup, remove it

[ -f $TARGETDIR/$BACKUPFILE ] && rm $TARGETDIR/$BACKUPFILE
#
# if there is a backup here already rename it
#
[ -f $TARGETDIR/$TARGETFILE ] && mv $TARGETDIR/$TARGETFILE $TARGETDIR/$BACKUPFILE
cp $SOURCE $TARGETDIR/$TARGETFILE

make the changes to reflect your setup and save the script. Dont forget to CHMOD it!

And off to cron now.  Add a cron job, the timings are up to you. Your Rsync job should tie up with this however you could have this backup more often so you keep a local copy and then pickup the backups with Rsync less frequently, its totally up to you. Bear in mind that once your setup is stable FreeNAS tends to get left alone, frequent backups may be counter productive and you can always go and manually run your script if you are playing about. Your cron job needs to call the script you just saved. Set it to just ahead of the system clock to make sure all works.

All being well you can now setup your Rsync to drop it into the right place, et voila!

PFSense

First up make your backup script. We will be using SCP so make sure that your backup user can do passwordless logins.

Create a backup script, dropping this in root is just fine. We used:

#!/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
now=$(date +”%T”)
logger Automatic backup running at $now
/usr/bin/su <BACKUPUSER> -c “/usr/bin/scp /conf/config.xml <backupuser>@someserver.domain.com:/home/<backupuser>/backups/pfsense

The script above drops a file in the system log to say when the backup last ran. Make sure you change this to reflect your system and save it as backup.sh, chmod it and them make sure you can run it on the command line and it works.

You need to muck with Cron. The easiest way is to install the Beta CRON module and do it there. The command line you want to do the backup for cron is…

/root/backup.sh

Obviously you’ll need to change <youruser>,<yourserver> and <backupdir>. You can manually add it to /etc/cronttab by adding…

00      01      *       *       *       root    /root/backup.sh

Again make sure you correct to reflect your setup. This job is set to run daily at 01:00.

FreePBX

This one is is a little bit more convoluted. There is a backup UI in FreePBX but it doesnt handle the setup of the SSH side, expecting you to have done this. So assuming you’ve done the steps above on your FreePBX system you should be ok.

If you are going to use root or asterisk as your backup user thats all great and you can use the ui. However in this scenario I dont want that. I want customer backups to go to the right customer folder. This is a little harder than it needs to be but its not difficualt once you know what is going on. All scripts are run as the ‘asterisk’ user. This cant see the key we have made so we need to copy it. To really add to the fun FreePBX mucks with the permissions of asterisk’s .ssh directory on reboot so whil you may get this working first time, it wont after a reboot. Moving the key elsewhere fixes this. You will have to do this as root…

mkdir /home/asterisk
cp /home/backupuser/.ssh/id_rsa /home/asterisk/backup_rsa
chown -R asterisk /home/asterisk
chgrp -R asterisk /home/asterisk
chmod 700 /home/asterisk
chmod 600 /home/asterisk/backup_rsa

You should now be able to setup a backup server in the FreePBX backup/restore dialog. So for our example….

Untitled

again make sure you change paths etc where needed.

 

ATX PSU Testing and troubleshooting

PSUs dont always *just* die and they can cause no end of issues. Just thought I’d pos tthe test procedure we use.

ALWAYS work with your bench/work area protected with RCDs

Learn (if you dont know) how to use a multimeter and or a scope. Cheap but good enough for this, portable scopes abound on ebay for under £100 if not less. You are lookign for the presence of something, not measuring it on the scope. I have a nice Metex portable multimeter with a DMM that goes everywhere.

Until you have tested the first two assume this machine is dangerous, Avoid touching exposed metal.

If you can, PAT test the PSU and its lead. If it fails isolate what fails, lead or PSU and replace. Dont even try and sort a PSU that cant pass a PAT test (There are brands that repeadly fail PAT testing when done with a decent tester even new)

If you cant PAT test check for continuity between the metal PC case and the screws on the socket at the wall. you are looking for nothing more than a few (<10) ohms. If it is significantly higher you need to find out where the earth issue lies before going on. Surge arrestors can be a frequent cause especially if they have been zapped.

WIth your meter on AC voltage plug just the mains in everything on and if fitted turn the PSU power switch on the back on. Meter between bare metal on the case and the screws of the wall socket its plugged into.

Up to a few volts is fine. Over about 10 you may have a minor problem, over 30 you have a serious issue. If you plug the monitor in and the voltage vanishes the PSU is becoming leaky and the monitor (if its earthed) has grounded it out. This can be the cause of frequent monitor failures. It also means you arent using your PAT tester properly if it passed 🙂

With Power off and disconnected from the wall (The PC not everything else, leave anything else plugged in for this)
check that all rails are zero. any voltage on +5V or +%v Standby indicated a faulty USB device, many powered USB devices dont stop their power supplies tryin to power the bus. This isnt really a good idea and can cause boot and power/no post or not power faults. Evo Labs I’m looking at you here. Disconnect things until the voltage goes away, bin the responsible item (or meter pins 1/4 on the devices USB port to check then bin)

Meter all voltages while off with mains on. Check +5V USB/Stby is in tolerance, what you cann in tolerance is down to you but we will reject below 4.7. Make sure everything else is off. more than 200mV on any supply line while off is a reject. It points at control IC issues or a breakdown happening in the transformer. Voltage on the +5V rail may indicate the presence of USB devices that arent playing ball, see above.

Any issues at this point will cause power/no post, intermittant post or a dead machine (often with a faintly glowing power LED)

Check the +5 USB/Standby is clean with the scope. It *should* appear as a flat line. If it doesnt check your earths, expecially the meter earth lead. If you know how to read the display properly artifacts at 50Hz are normally pickup by the meter but could indicate a promary (main side) issue. ANy higher frequeny spikes above a few mV mean the PSU is failing and in particular the filter caps are probobly on the way out or its badly overloaded. Disconnect all but the mains lead and check again. If the spikes have gone work backwards plugging in things till they reappear. USB Novelties are the worst offendores here along with cheap hubs that may be overloaded.

Again any issues at this point will cause power/no post, intermittant post or a dead machine (often with a faintly glowing power LED) but a noisy %V rail can cause the machine to randomly lock up and in some cases turn itself on.

Noisy rails seem to be an issue with Evo Lab and clones, JueJye, earlier Enlight, and Acer’s own. The normal cause is low quality control, removal of filter components to reduce cost or falling victim to capacitor plague.

Power the machine up and work through the rails. Voltage first, then scope. Typical values are available at https://en.wikipedia.org/wiki/ATX but rule of thumb is there is 10% allowable tolerence on all rails. If you start seeing more than one rail badly out then you have an unhapy or overloaded PSU

The spikes on the rails should be as low as possible and they should be regular if at all. Excessive spikes (also called ripple) indcate a rail is way overloaded or its filters are failing. Excesive ripple will cause just about any random fault you can imagine from making ram seem faulty to cooking off grahics cards. High ripple is very very hard on the PC and will cause failures and can cause severe damage especially if the PSU fails.

Irregular spikes can indicate the PSU is close to its limit or something is going into protection somewhere. A few isnt much to worry abou but if these spikes co-incide with a lockup or crash they need to be linvestigated. You may find if you look closeley you’ll see the spikes on the monitor as flickers or faint bars. The latter typically points at filter caps on the board or graphics card having gone bad. A quick visual inspection will normaly find bulged or ruptured caps.

All of these issues can be present on a working PSU, if you dont go looking for them you’ll never find them and you can end up chasing your tail for hours. A simple substitution is always a good way to start a fault finding mission as PSU faults can show up anywhere.

An overloaded PSU will fail, and dont assume that because you are using 450W and you have a 500W PSU you are safe:
1) The PSU may not be capable of 450W, often lower end PSUs quote a peak power fugure that they can only breifly sustain.
2) Your 450W may ot be their 450W. Take all the rails listed on the side with currents and manualy convert them to watts EG 12V*16A = 192W. You will often find on lower end PSUs that the power doesnt add up when you sum them or that all the power is on +3.3V or +5V when its needed on +3.3V AND +12V
3) With the above info and looking at product data work out the power consumption on a PER RAIL basis, you may find quickly you dont have enough power
4) Give yourself headroom. 450W load on a 500W PSU is too close. You dont know how accurate those figures are and as systems age they can draw more power as caps dry out, fans start to stiffen up etc.

When you buy one:
1) Check the figures as per above. Add them up and look at where the power is.
2) If its split rail check continuity between the 12V lines with your meter and the PSU on the bench disconnected. You should fine two or more distinct 12V lines. Normally motherboard and Drive then GFX and ATX12V. If you get 0 ohms on all 12V lines then there is no split rail.
3) Look at the wiring. The wires should be substantial but not too thick. They certainly shouldnt be like bell or phone wire. Thinner wires result in more losses in voltage.

On the wiring you need to watch things here closley. Thinner wires means (as a rule) more resistance and this leads to something called Joule heating. Under a constant load this will reach a fixed point and wont get any worse. However as voltage at the device end drops more current is drawn, this causes a greater voltage drop and more Joule heating and things will either result in the device malfunctioning and shutting down OR catastrophic failure of the wire or device, either fire or a failure at a connector (this is what melts the SATA adaptors). If the device periodicaly and breifly demands high powers then this can cause voltage drop outs and other issues without the burning. Biggest culprit for this is hard drives on the end of a long chain of devices. This will reslut in the drive rebooting, data loss and eventually the drive failing.

Well thats annoying – Pi I2C Woes & HAL

Well thats not quite what I said when I found my bug about 15 mins ago but same sort of general meaning.

We are using the Pi in more and more things and in order to make it easier i’ve been writing our own HAL to make using the GPIO and onboard perhipherals easy to use, wrapping up things that others kinda did, adding new bits and dropping in native support for our hardware. Its been going well hen a few weeks back I hit a reoad block or two.

The first is repeated start, the long answer is that using the IO wrappers for I2c you cant do it. Looking deeper into it the Python lib fudges it too by doing a bulk read so no biggie there. Its no fixable, easilly worked around and in many ways a bulk read is a nicer way to do it.

The second was driving me nuts. I couldnt write a register. I could select it, but the perhiperal always sent 0. After a few hours of head scratching I had to get on with other work and its only today I’ve been able to get back to it.

The long and short of it is that I was trying to be too clever and not thinking about it in a *nix manner. I was opening the bus and then assuming that I could move addresses round as I needed to talk to things, turns out that doesnt work (It may be tied in with the above too). Changing the target address once you’ve set it seems to bugger up the driver and it then sits and sulks. I’m not sure why this should be so but it does. Assigning a new file handle for each device (FPOpen()) and then setting the address works so it looks like thats the way I need to do this. The upshot is that the whole I2C section of the HAL (which to be fair wasnt written) needs redoing. It also points to some issues that were going on with the IMU on the Tezero platform too so its another point in the argument to moving Tezero onto the HAL.

So what does work?
Well GPIO mapping, control and I/O all works a treat. The HAL will map out SPI/UART/I2C pins if the perhipheral is in use. Getting hold of interrupts is hard in Lazarus without scripting bits of Python to do it. The HAL now fudges it by using a thread to monitor the pins. As you assign interrupts to a pin no interrupts = no CPU time used. With all available GPIOs running with interrupts the CPU load doesnt register so thats good. There is a FIFO system in there so a long IRQ handler wont hang the queue.

And to go?
Support ofr specific perhipherals is next. How far I’ll go is uncertain but as the HAL is going down in the Touchdown kits I may go as far as adding specific I2C device support. What is definately going in is support for things like thumbwheels and our TRNet bus system on UART0

Can I have a copy?
Not yet, I’m still testing, but soon 🙂 When its about it’ll be released on http://forum.tswr.co.uk

Torro Conference and moving forward…

Well some of you may know that I volunteered to stand up and talk about Touchdown, the Pod and SOA this afternoon. I never feel comfortable with this sort of thing, generally engineers are best kept as far awa from the public as is possible, putting one in front of a room of people really seems like a bad idea.

No one died, the message went over, I’m pretty sure it was well received and no one has arrested me…yet.

So the interesting thing here is that theres been a development. SOA was always intended to have UK and US versions. the UK version wasnt a priority, turns out this may have been a mistake.

Two messages seemed to come through today. One, that data is being lost. Too much reliance is being put on people’s memories, bits of paper and anecdotes. A large proportion of what Touchdown proposes centres around data retreival, integrity and storage and automating all of this as much as possible.

The other is that there is an apetite for something Like SOA here in the UK. With the move from STM32 to the Raspberry Pi the proposition that you could build your own and just use the Touchdown software is quite feasable. In fact we’ve had a large response to this idea.

SOA as it stands does provide a framework for doing a lot of this and with the move to Pi a lot of the special hardware isnt needed, making it modular is perfectly feasable and with the Pi, if you can use jump wires then its easy enought o get something running.

So where are we…

As the system stands a lot of the applications still need to be ported over, we’ve re-written a lot for Pi already so theres nothing horrid there, it can be done and its not a difficult job.
SOA was never designed to be ‘hackable’ so we need to make things as user friendly as possible, I’m thinking ‘appliance’ here so it can be plugged in and mucked with if needed. Although the Pi can run a monitor theres no need to actually do it if theres another computer to hand.

Sensor wise, its down to the end user. There are a set family of devices we use but adding support for others shouldnt be hard. Keeping it same and sensible is important so we’ll likeley pick just a few limited ones.

Reporting should be automated. With the user getting warnings and them being reported back to a server. Maybe an expansion on the reporting system planned for SOA so people can instantly log weather conditions that are out of the ordinary.

If its possible to maintaie a stable, syncronised time source through GPS or NTP then the possibility of lightning ranging and triangulation is opened up. It also allows for storm trends to be analysed as they happen, a potential powerful tool for tracking major storm systems.

On the back of it I think we will look into building a reporting system to use with this along with a repository for reporting severe weather events and ways of automating certain reports and alerts. On top of this a simple to use website to allow everyone access to the data.

Looking forward the easiest way would be to offer either the pre-built units or instructions, or even both. As all Pi’s are essentially the same a single SD card image can be used with all the necesary software, setup and modifications already done.

Its a very interesting proposition and one I think will be getting looked into over the next few months.

 

 

Pi & Lazarus I2C

I’ve been asked a few times now how we got I2C working without third party code. The reality is that thanks to the way Linux handles drivers it’s pretty easy and I’d expect direct access to 1 wire to be the same (We have bridges with FIFOs, parasitic power etc so we  dont need to try it)

First make sure you can talk to your I2C decvice with I2Ctools. Theres loads of info on this, off you go and hunt it down.

NOTE, BIG GOTCHYA!
latest versions of Raspbian use a new way of handling devices, make sure you use a tutorial that matches the way your system is setup as simply uncmmenting things in the modules blacklist may not be enough.

You shouldnt be running code as root, developing, yes, running as an end product, no. There are arguments against developing too but thats not why this article is here.  By default only root has access to I2C and we need to change that if your apps are going to work in userland. Its easy to do. Say we want pi to be able to do it:

sudo groupadd i2c pi

Now we can use the standard FPOpen(), FPRead(), FPWrite() to do the job.

var
  DEV_IMU : integer;
addr : byte;

This is the handle for the fle we are about to open and addr is the target device address on the bus

procedure openI2c;
var
   count : integer;
   data: byte;
   reg : byte;
begin
  DEV_IMU:= fpopen(‘/dev/i2c’,O_RDWR);
  if DEV_IMU= -1 then begin
             // we couldn’t open the bus
              exit;
              end
else begin
// associate this handle with an address on the bus
fpioCTL(DEV_IMU,1795, pointer(addr));
//success

end;

Now to read:

function readbyte(reg:word):word
var
    count : integer;
   data : byte;
begin
// we have to write before the read to send the register we want
     count := fpwrite(DEV_IMU,reg,1);
     if count <> 1 then begin
              // we couldnt do the write!
              exit;
              end;
// now read
    count := fpread(DEV_IMU,data,1);
     if count =0 then begin
              // nothing came back
              exit;
              end
  else result := data;
end;

And the write is easy enough. The read is write then read as we always nbeed to send the target register out. In the case of a write we can do this ‘back to back’

procedure writebyte(reg,data:byte)
var
    buffer : array [1..2] of byte;
    count : integer;
begin
     buffer[1] := reg;
     buffer[2] := data;
     count := fpwrite(DEV_IMU,buffer,2);
     if count <> 2 then begin
              // write failed
              exit;
              end
     else // write ok
end;

This should have you up and running in no time.

Security Through Obscurity…

Time and time again we are told the above doesnt work and yet it still happens, why and why is it important.

In the process of our big tracker project I’ve been looking at packages that do the job already and also a number of control systems. Bearing in mins what these do, there is no security on most of it and token security on one of them. You may think that this isnt a big thing and in most cases it isnt, but there are good reasons it is. So lets take a look at two culprits…

Veichle control Systems:
I’ve looked at three of these in the last few days and one thing is common with all three. No encryption, no ability to detect errors and no authentication. For the best part this isnt a huge problem, in fact its a boon, I know how all three work and can talk to them. However the bar is set low and any of them can be subverted easilly. In the case of the first two I looked out you wouldnt gain a lot past the ability to turn things on and off but the potential is there. The third is a fully integrated system and is designed to control all aspects of the vehicle including battery management and its also designed to be linked to an onboard computer, now here there is scope for trouble. The system concerned could easilly be subverted by malware and then the fun begins. Further digging on this one turns up no encryption is used on the comms link to the office either, but it gets worse…

Of the dispatch and tracking systems looked at not one uses encryption, for the more basic ones this means simply you can rap the tracking data out of the air and at least one was fooled easilly to connect to a wifi network and forwd the unencrypted traffic over my network, patient details, addresses etc all in the clear. This means that this data can also be modified so this particular system couldbe subverted pretty easilly with a laptop and either data creamed off and used for nefarious means (ask someone how expensive ambulance kit is!) or worse. Tracking data can be falsified, fed back to the base meaning the veichle doesnt show as being where it belongs and uh-oh, the SOS button isnt going to help if someone jumps the ‘bus’

There is no excuse for this. None at all and the scary thing is that the same can be found in Automotive systems from the factory and has recently been found in Avionics systems too!

Serial channels can simply and effectively be secured. Even our most basic bus system, TRNet uses authentication and device tracking mechanisms. If a device doesnt authenticate, its ignored, even if it does it must be recognised on the bus else the system, will lock the bus out. This is done by a few dozen lines of code and although it could be subverted with a moderate amoun of effort you’d need access to a lot of information to get started. This also allows us to give a mechanism for making sure the bus is reliable. Scarilly all but one of the three systems we looked at just kept sending the same data over and over again with no control path back to the master. Although it’ll work it means bit flips can happen in transmission and may be ignored (no CRC/Checksum used) and there is a wealth of data for someone to grab and decode.

Data channels running over a network should also be secured and only links trusted should be used. Again this is basic common sense and doesnt take a lot of code, for this application we are using a pretty hardcore authentication system based on AES but its neither difficult to do or expensive. With the system we have both ends of the chain must be compromised and in such a way that pe-encrypted data is grabbed, key shifts mean that just grabbing the encrypted stream and a session key wont help you, even if you do grab a key you need the previous key to use it so good luck.

There is still a strong sense in the embedded and bespoke software/hardware market that no one is interested in specialist applications, wont try and thus you dont need to bother about security above making it convoluted. This is fallacy, the value of the equipment on an ambulance is truly amazing to those not in the know so gaining the ability to send such a veichle to a false location of your choice, disabling its tracking  and ability to call for help is going to be of interest.

 

A Precautionary Word About Driver Updater Utilities

I see and remove a lot of these and they are almost universally hated by the IT industry and a VERY bad idea for the end user, but why?

First up the Malware side of things. A lot of these updaters are Malware/Foistware. The same trick is used as is pulled with a lot of ‘Heatlh’ checkers. Find lots of problems, tell the mark you can fix them and then charge for doing so, even though the problems likeley didnt exist or wernt problems at all. There are driver programs that do just this.

RansomWare, well not quite but thats what it tries to do. Does the same as above and likley will actually find issues and be able to update drivers but once again, you’ll have to fork out for something you could do yourself and may be harmful.

Next up apps that do actually do something. Most of these still fall into the dangerous category, even those that are free and do seem to work. Why? Because the method they use is fundamentally broken. Almost all hardware provides two bits of information to the PC without being told or needing drivers, this is the PID and VID or Product ID and Vendor ID. These are used by these programs to go and find out who made the hardware and what it is. It’ll then grab a generic driver from the manufacturer or its library  and off it goes. No harm done? Well not really no.

For a large number of devices this is just find and dandy but some developers are a bit lazy and this is where it falls over.  The idea was that each PID/VID combination would be unique, the IDs are provided by the chips used and the idea is that the company making the perhipheral should assign their own values and not use the defaults. In reality very few do.

Two Examples. One, we have a Laptop using an ATI X1300 GPU, Its in a laptop and this GPU provides some secondary functions, in this case, it can take control of the backlight. The Laptop manufacturer hasnt changed the PID or VID and this wasnt something the ATI drivers were written for. Along comes the utility, matches the PID and VID to the default ATI driver, installs and blammo. You have no backlight anymore, the new drivers dont know how to drive the backlight and so dont.

Next we have the RealTek ALC892, fairly common sound chip. However this thing has options out of the wazoo. There are hundreds of combinations of speakers, inputs, outputs, mics etc and these will all be changed by the vendor, however not all of them are there in the default driver, in particulat there are a few general purpose I/O pins used to drive LED’s, power control for amps and more. SO with the driver the manufacturer of the hardware supplies this all works, in comes the default driver and once again, all these features are gone.

Both these scenarios could lead to physical damage to the machine as well as malfunctions in use so it really not worth it.

With time and research you can normally find the right drivers and its also why you should stick to manufacturers drivers, especially on customised hardware such as Laptops or SFF PC’s. Its also why sometimes the right drivers dont really seem to work as planned. Its also the reason the Microsoft drivers arent always that great and why you should always update core drivers on a new install, an example of these were the older VIA based motherboards that would run like a dog with the MS drivers. Only if you’ve tried everything should you think about these programs, and even then, here be dragons!