Sage Accounts crashing when emailing invoices

We've had an issue with Sage Accounts crashing for a user and see this from time to time, mostly with the same customer. This spans multiple years and multiple versions of Sage Accounts, yes they do upgrade every year.

The environment is a normal network with active directory, Sage data hosted on a server and mapped via the UNC path. The printers on each accounts persons desk is an HP P2035 LaserJet, connected via USB.

They rarely change accounts staff so we rarely see this issue they have with Sage Accounts crashing when selecting multiple invoices and hitting the email button. Everything else with their setup is well documented from many years ago since they last changed PC's and had a few issues with Sage. I guess this one thing got overlooked in a rush trying to get everything fixed for them.

Having contacted Sage and being fobbed off with their usual line of 'This is a known issue, please follow the steps in this KB to resolve the issue you are experiencing" and being sent an email with a link to a KB. Suffice to say following the steps in this KB did NOT fix the issue!

How I fixed it was comparing another PC which is able to send multiple invoices without issue, the only difference was that the new accounts person HP P2035 had the "Enable advanced printing features" ticked under the Advanced tab of the printer properties page. I unticked this, hit ok and asked her to try again. Lo and behold, it worked! I asked her to try several more times to make sure it wasn't a fluke and we rejoiced as she kept trying and it kept working!


Now whether this is a Microsoft issue as its a tick box in a Windows dialog box (unlikely their fault as no other customer with Sage has this issue), an HP issue being its their driver and we don't see this with other customers with different printers or a Sage issue as its their software crashing I can't say...

OpenBSD L2TP/IPSec VPN for Android

Since posting the L2TP/IPSec VPN configuration for Windows devices I have had a lot of comments asking for me to test this with Android. I wasn't able to follow up on those  requests as I had lent my old Samsung S3 to a friend whose iPhone 5S has been playing up and eventually died while he waited for his new phone, he got an iPhone 6S .. how disappointing ?

Anyway, Once I got the phone back it took me less than 5 minutes to find the correct settings for an Android device - please to bear in mind that if your Android device does not work please check the /var/log/messages file for what was sent by the device and what was expected by the router and make the adjustments in your /etc/ipsec.conf file.

I've decided to make a completely new blog about it so there is no confusion and its just simpler in my mind, I've also just copied and pasted the text and modified the few parts that needed to be for an Android running 4.4.4 (this is an OLD phone and it's running Cyanogen 11).

In OpenBSD to use L2TP / IPSEC you can use the native NPPPD (8) as I have done. I'm a big fan of using the out of the box features, afterall OpenBSD is built for security from the ground up, so using a 3rd party L2TP/IPSEC port wasn't an option, I literally didn't even give it a thought.

With NPPPD there are a bunch of files you'll need to configure in order to make it work.
/etc/npppd/npppd.conf
/etc/npppd/npppd-users
/etc/ipsec.conf
/etc/pf.conf
/etc/sysctl.conf
/etc/rc.conf.local

My npppd.conf file looks something like this, note the reference to the npppd-users file, you can configure multiple VPN's here with different users in different files. You'll see I'm using tun instead of pppx

authentication LOCAL type local {
        users-file "/etc/npppd/npppd-users"
}

tunnel L2TP protocol l2tp {
        listen on 0.0.0.0
        listen on ::
}

ipcp IPCP {
        pool-address 10.0.0.2-10.0.0.254
        dns-servers 8.8.8.8
}

interface tun0 address 10.0.0.1 ipcp IPCP
bind tunnel from L2TP authenticated by LOCAL to tun0

and list of users in the npppd-users file, add as many users you require, you can set them a static IP here too, check the man page for npppd for additional options:

Username:\

        :password=S3cureP4s5vvordz:

and ipsec.conf file should look something like this, the first two lines set macros as you can in pf.conf, this helps as I have a dynamic IP, although I still have some issues if the IP changes and need to run pf.conf, possibly also reloading ipsec.conf rules, you may need to change aes to 3des or something else your device requires, same applies to modp2048 and hmac-sha1, check /var/log/messages after trying to connect your device:

IF_WAN=pppoe0

key="B1gPH4tKEYWITHlotsOfRANDOMstuff"

ike passive esp transport \

        proto udp from $IF_WAN to any port 1701 \

        main auth "hmac-sha1" enc "3des" group modp1024 \

        quick auth "hmac-sha1" enc "3des" \

        psk $key

If you've got a working OpenBSD router using pf.conf as your firewall, you'll need to modify this too, adding tun to your skip statement, NAT rule allowing VPN clients LAN and WAN access, and the last two lines allow the VPN traffic in otherwise the VPN's wouldn't establish:

set skip on { lo, enc, tun }      #Added tun here

match out on $IF_WAN from {$IF_LAN:network, 10.0.0.0/24} nat-to ($IF_WAN:0) \

scrub (no-df max-mss 1440) #Added the network range for the VPN clients

pass quick proto { esp, ah }

pass in proto udp to $IF_WAN:0 port {isakmp, ipsec-nat-t}

You also need to add in some sysctl.conf options:

net.pipex.enable=1            

net.inet.ipcomp.enable=1  

and in rc.conf.local

isakmpd_flags="-K"

ipsec=YES

npppd_flags=""

There are not many changes, you can either reboot the router or reload the firewall, load the modules in sysctl and start the services. If you already have a VPN configuration then restarting the services should be enough.

Windows 7 updates taking ages? Here's a fix!

As of about 6 months ago I've been deploying PC's for customers who aren't comfortable with Windows 10 after all the nonsensical press about it spying on users, and they don't want Windows 8/8.1 either because of the UI, some just have software that the vendor hasn't tested on anything newer than Windows 7.

Each customer needs a different build of Windows with different preinstalled programs, so require different images to be installed from a WDS. While making the first of the base images, which I would then fork into different images for the different customers once updated, I noticed Windows 7 would just sit at trying to check for updates, seemingly never ending.

Now I knew Microsoft had  released an update to Windows 7 update around the time of the Windows 10 launch so I checked my suspicions and yes, this update does resolve the never ending search for updates.

Once installed within a few minutes Windows 7 will find updates, you can grab the update below for x86, x64 Windows 7 and Server 2008 R2... and IA-64 if anyone actually still uses them:
https://support.microsoft.com/en-gb/kb/3050265

Update:
Microsoft have now released a convenience rollup update for Windows 7 and Server 2008 R2 which can be found here and will allow you to get the latest updates up through to April 2016 patch Tuesday.

Raspberry Pi 3: Reasons for a Heatsink and fan

I've had Pi's since the original Pi Model B and always instantly put a heatsink on them to "keep them cool" as I'm sure most other Pi users have and on my Pi2 I bought a cheap acrylic case I could cut up and modify, I actually ended up buying 3 in the end until I made my build exactly how I want it, with a big red power button and fan on top (pic later).


Upon arrival of my Pi3 the day after launch I decided NOT to put a heatsink on and test the temps on a stock Raspbian image, no overclocking, everything as default in the Pi3 Black case from RS where I'd ordered my Pi3.

The temps looked pretty bad straight off the bat, with just the Raspbian GUI up and a watch command checking the speed and temps. Put the below text into a file with your favourite text editor and save it with a .sh extension, chmod +x filename.sh  and run watch ./filename.sh I called mine cputemp.sh

cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
/opt/vc/bin/vcgencmd measure_temp

The other script you'll want is  the fullload.sh which reads /dev/zero into /dev/null - essentially taking as many 0's as it can get and dumping them into a blackhole, but we run this 4 times, once for each core, to generate the load needed, there are other ways of doing this, but this is one of the simplist. The below script is all one line. remember to run chmod +x fullload.sh so its easier to run with just ./fullload.sh

fulload() { dd if=/dev/zero of=/dev/null | dd if=/dev/zero of=/dev/null | dd if=/dev/zero of=/dev/null | dd if=/dev/zero of=/dev/null & }; fulload

Now watch the temps, my Pi3 was hovering at idle 49C - 51C in the Black case (there's not much ventilation with these cases, the cpu speed kept flickering between 600Mhz and 1.2Ghz.

With fullload.sh running, the temps sky rocketed up to 85.3C pretty quickly ! Using killall dd to stop the processes and the temps eventually came back down to about 53C after 5 minutes.

Adding the copper heatsinks, brought the idle temps down a few Celsius to a max of 49.2C, not a huge difference!

 Running fullload.sh with the copper heatsinks on brought about similar high temps as without heatsinks, so the heatsinks alone do not do a whole lot!

I decided to whip my Pi2 out the clear acrylic case and put my Pi3 in it, since that case has a fan and retest the temps with the heatsinks on, I really didn't want to reorder the heatsinks to do a test with a fan and no heatsinks, I'll probably end up buying another Pi3 in the next few months so I'll test again then without heatsinks but with a fan.

So the Pi3 idle temp with heatsink and fan is 27.2C ! Much better than a Pi3 without a fan.

Running fullload.sh brings the max temp to a decent 49.8C, which is the idle temp without a fan!

So in conclusion, add a fan to your Raspberry Pi setup if you don't want it running hot, especially if its doing a high work load.

Now this is the slightly dangerous part ... overclocking to a whopping 1.5Ghz! config.txt mods below:

arm_freq=1500
core_freq=500
sdram_freq=500
over_voltage=6

The temps hover between 29.3C and a max of 31.5C, the small load of watch tempcpu.sh is what probably makes it jump to 30.9C and less often 31.5C

So after It'd been running like that for 15 minutes or so it was time to run fullload.sh on the beast, I watch it for about 5 minutes as it slowly climbed to about 44C then went to make a coffee ... when I got back I was greeted with the below in my ssh client and the Pi3 was unresponsive to, not even to pings so it had crashed :(

pi@raspberrypi:~$ ./fullload.sh
pi@raspberrypi:~$ dd: error reading ‘/dev/zero’: Bad address
3379135+0 records in
3379135+0 records out
1730117120 bytes (1.7 GB) copied, 5.55431 s, 311 MB/s
dd: error reading ‘/dev/zero’: Bad file descriptor
7702196+0 records in
7702196+0 records out
3943524352 bytes (3.9 GB) copied, 12.4847 s, 316 MB/s

Upon reboot it booted up fine and I could find no ill effects from being overclocked to 1.5Ghz and fully loaded. I decided to run another load on it and it crashed a lot quicker this time, before I could open another ssh connection and type the watch command ... so I think 1.5Ghz might be a bit much, I stepped it down to 1.45Ghz and it was much more stable with no adverse effects and the temp is a stable 61.6C which I'm happy with.... for a while then it hung a while later :(

So I stepped it down to 1.4Ghz and so far so good, no crash yet after over an hour and a max temp of 65.4C, not what I was hoping for but better than the stock 1.2Ghz.

I'd like to get another Pi3 and run the last test with just a fan and no heatsink so see if there any differences between having a heatsink or not, since there's no real difference before adding the fan.

*Note: I left the Pi3 to run the tests for at least 10 minutes each time, often more, even running at 85.3C as this it was stock Raspbian with no modifications, so if it blew up, they would have to replace it, right?

I found the basic scripts on another blog, its only right to mention it here: http://www.jackenhack.com/raspberry-pi-3-overclocking/

Let's Encrypt! with FreeBSD 10.2 & nginx

So with the announcement that Letsencrypt.org has gone into a public beta this last week I decided to give it a go and here are my results.

If you don't know what this is, visit their website and find out https://letsencrypt.org

I have a FreeBSD 10.2 dev VM running on my Windows Server 2012 R2 Hyper-V box, it has some internal websites I use but nothing significant.

This is assuming the following, it'll be easy to get a LetsEncrypt cert in a few minutes.

Port 80 is open to the world on your webserver (or Port forwarding/PAT is configured).

Your DNS is correct for the www.mydomainname.com and points to the web server.

and lastly that your document root is /usr/local/www/nginx/

Before  asking for help check all of those are correct.

To install Letsencrypt its  a fairly straight forward "pkg install py27-letsencrypt" or cd /usr/ports/security/py-letsencrypt && make install clean. Which as of writing is py27-letsencrypt-0.1.0 on FreeBSD 10.2.

Once installed you'll need to run a command like:

letsencrypt certonly --webroot -w /usr/local/www/nginx/ -d www.mydomainname.com

Note: you can add additional arguments like "-d www.myotherdomains.com" to do multiple certs at the same time

If you get a successful message then all you need to do is edit your nginx.conf for your sites(s), I'll include a basic sample below which works for me. If you edit your nginx.conf before getting your cert and try to reload it, it won't reload because the cert and key will be missing!

server {

    listen 80;

    listen 443 ssl;

      server_name www.myotherdomains.com;

        ssl_certificate /usr/local/etc/letsencrypt/live/www.myotherdomains.com/fullchain.pem;

        ssl_certificate_key /usr/local/etc/letsencrypt/live/www.myotherdomains.com/privkey.pem;

  access_log /var/log/www/access-www.myotherdomains.com.log;

  error_log /var/log/www/error-www.myotherdomains.com.log;

 location / {

  root /usr/local/www/nginx/;

  index index.html;

}

}

Now that you have py-letsencrypt installed, your cert and nginx config sorted, all you need to do is restart nginx with:

service nginx restart

You should now have a working LetsEncyrpt cert!!!

Please note that FreeBSD does not yet have the letsencrypt-auto client as of 9th December 2015, so in 89 days you better renew your certs with the same command as you used above!