Tag Archives: linux

Magento Wget Download

If you use Linux servers, are working with Magento, and want to download the latest version or patches then the Magento site is not as friendly as you might want.

The download process is java driven and does not provide a link for the download, just a browser based download to your local computer.

I work mobile a lot and I do not want to download 22Mbyte files to my notebook over 3G and then have to upload from my notebook to the server. It is just a waste of time and bandwidth.

So I went searching for the path that we need to use and for the latest tar.gz file for magento this is what works.


From what I can see, and assuming that they do not change the process, http://www.magentocommerce.com/downloads/assets/ followed by the version number as a directory, and then the file name should provide a full download path.

In this case this combo downloaded the latest release for me to my Linux server.

# wget http://www.magentocommerce.com/downloads/assets/

A word of warning!

When extracting the tar.gz file, Magento do not provide a unique version path for the contents. All versions use the root path of ‘magento’ so assuming you always download to the same path you may have magento- right alongside magento- and extracting the newer version will extract it into the magento directory over the top of existing magento directory. The result of this is that your new version is potentially saddled with artifacts from the earlier version. Delete the magento directory and start again.

A 4 step process could be:

1. Clean up from previous downloads

#rmdir magento   // or //  #rm -Rf magento

2. wget the new version

# wget http://www.magentocommerce.com/downloads/assets/

3. Prepare a directory ready for the extract of the new version

#mkdir magento-

4. and finally extract the file contents from the tar.gz file, into the stated directory, and strip the first directory from the path that is stored within the archive, i.e. /magento/

#tar zxvf magento- -C magento- --strip-components=1

Next, carry on as usual with your backup existing, copy the new files, etc, etc.

Debian Linux openvpn connect to Watchguard VPN

I have a Debian Server that I wanted to connect to a Watchguard VPN.

OpenVPN is the tool that I used and the following is based on JoKi’s excellent blog entry with my own adjustments to address the issues that I found.

To start you do need to install and run a connection using the Watchguard MobileVPN on your Windows box to get the configuration files in

C:Usersyour_user_name_hereAppDataRoamingWatchGuardMobile VPN

It took me a while to work out that I had to run it to get the config files created, installing alone is not enough.

Installation in Debian is straightforward

#apt-get install openvpn

Once that is done go to the newly created /etc/openvpn and copy the files from the abovementioned Watchguard directory to it.


Now it should all be good to go.

#openvpn --config client.ovpn

Except that I was getting all sorts of errors and warnings……

Wed Nov 12 12:16:50 2014 VERIFY X509NAME ERROR: /O=watchguard_technologies/0.0=f ireware/CN=fireware_sslvpn_server, must be /O=watchguard_technologies/ITU-T=fire ware/CN=fireware_sslvpn_server
Wed Nov 12 12:16:50 2014 TLS_ERROR: BIO read tls_read_plaintext error: error:140 90086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
Wed Nov 12 12:16:50 2014 TLS Error: TLS object -> incoming plaintext read error
Wed Nov 12 12:16:50 2014 TLS Error: TLS handshake failed
Wed Nov 12 12:16:50 2014 Fatal TLS error (check_tls_errors_co), restarting
Wed Nov 12 12:16:50 2014 SIGUSR1[soft,tls-error] received, process restarting
Wed Nov 12 12:16:50 2014 Restart pause, 5 second(s)

Everything I read said that the certificate files would be the issue, but that was not logical to me as they were direct from the Watchguard device and not ones I was creating.

But I checked them anyway with

#openssl verify -CAfile ca.crt client.crt

Next I tried addressing the verify X509 Name error by changing the client.ovpn file entry changing




and messed around with that for a while until in disgust I commented the line out to try and confirm that it was triggering the error.

Of course, it worked first time !!!  Argghhhh!!

So the answer to the above is to remove the tls-remote line completely from the configuration file.

tls-remote “/O=watchguard_technologies/ITU-T=fireware/CN=fireware_sslvpn_server”

Either comment it with # at the start of the line or delete it.

Once that was sorted I had a working connection all that remained was to

#mv client.ovpn client.conf

create an auth.txt file with


#chmod to 0600 auth.txt

Edit the client.conf file to have

auth-user-pass auth.txt

and finally start it as a service
#service openvpn start client

and the last bit of the puzzle, to add it as a service to automatically start

#update-rc.d openvpn enable

Thanks to JoKi for getting me started.

Synology installation of ipkg DSM yum or apt-get equivalent

The reference for the first part is at http://swwiki.e-dschungel.de/synology but is in German.

First up we need a package installer, ipkg

Check the Synology device for which cpu it has,

#cat /proc/cpuinfo | grep cpu

Then select the appropriate script

CPU Bootstrap Script
ARM (armv5tejl) http://ipkg.nslu2-linux.org/feeds/optware/syno-x07/cross/unstable/syno-x07-bootstrap_1.2-7_arm.xsh
PowerPC (ppc_6xx) http://ipkg.nslu2-linux.org/feeds/optware/ds101g/cross/unstable/ds101-bootstrap_1.0-4_powerpc.xsh
PowerPC (ppc_85xx, e500v?) http://ipkg.nslu2-linux.org/feeds/optware/syno-e500/cross/unstable/syno-e500-bootstrap_1.2-7_powerpc.xsh
Marvell Kirkwood 88F6281, 88F6282, 88FR131 (ARMv5TE Feroceon) http://ipkg.nslu2-linux.org/feeds/optware/cs08q1armel/cross/stable/syno-mvkw-bootstrap_1.2-7_arm.xsh
Intel Atom http://ipkg.nslu2-linux.org/feeds/optware/syno-i686/cross/unstable/syno-i686-bootstrap_1.2-7_i686.xsh

and get it with

#wget http://your_selected_cpu_bootstrap_script_here

then run it with

#sh http://your_selected_cpu_bootstrap_script_here

This install ipkg, but it is not in the path for the Synology system. To add it to the path:

1. check the path

#cat /etc/profile

and this should be there

PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/syno/sbin:/usr/syno/bin:/usr/local/sbin:/usr/local/bin export PATH

extend the path to include our /opt directories with two command lines

# PATH=/opt/bin:/opt/sbin:$PATH
# export PATH

Then we can test that ipkg is installed and will run from anywhere with

# ipkgv -v

Should respond with something like

# ipkg version 0.99.163

If you now try to install a package, you will get an error

#ipkg install mc
Nothing to be done
An error ocurred, return value: 4.

Which is ok, this is expected because the new install does not yet know where to look for ‘mc’

Note: ‘mc’ is just a favourite package of mine, (midnight commander, with the excellent mcedit editor) but you could try any packge you want like ‘nano’, etc.

The final step for installing ipkg is to update the repositories

# ipkg update

Then try again and as ipkg now has a repository to call on, it should find the install package and install it.

Shellshock BASH Vulnerability: Debian, CentOS, Synology Busybox

Ok, so Heartbleed did as it said, and Shellshock is about to do the same.

I manage some CentOS, some Redhat, some Debian, and other servers. From what I have found so far, and assuming that the patches applied to the latest release of BASH are sufficient, then most servers and devices can be patched / fixed so that they are not vulnerable quite easily.

According to most sources, the test for a vulnerable BASH environment is the following line of code:

env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

So I quickly hit one of each server / Linux flavour I could think of and these are the results:

SME Server / CentOS based

# env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
this is a test

so I ran

# yum update

which updates a number of tools including bash-3.2-33.el5.1.i386.rpm which appears to be the correct update version and re-testing after updating the server (includes other updates as well) gives the ‘not vulnerable’ response.

CPanel on CentOS

# env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x'
this is a test

which appears to tell me that it is not vulnerable.

I also had a similar message but without the warning from a second CPanel / CentOS server which is configured slightly differently:

# env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
this is a test

The lack of a warning in the above appears to indicate that it is not vulnerable.


Some of my Debian servers have not been upgraded from stable Squeeze, which I should be updating to Wheezy. I found different responses depending on which version of Debian existed on the server.

To check the Debian version use:

# cat /etc/debian_version
# 6.0.6

Checking the Debian version just as a confirmation of what patch release the server is using.

Debian Squeeze 6.0.6

# env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
this is a test

Vulnerable, so update BASH

# apt-get update
# apt-get install bash

A second test shows:

# env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x'
this is a test

<h2>Debian Squeeze 6.0.10</h2>

This one is a work in progress......

<h2>Debian Squeeze 7.4</h2>

This version of Debian was straightforward and 

# env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
this is a test


# apt-get update
# apt-get install bash

A second test shows:

# env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
this is a test

<h2>Synology Busybox</h2>

Synology Busybox uses ASH not BASH but testing can still be done

# env x='() { :;}; echo vulnerable' ash -c "echo this is a test" 

Gave an all clear message on my recently updated Synology unit.