I’ve been trialing Magento on and off for a few years and one day I’ll get my butt into gear to migrate my whole store from Zen Cart (which desperately needs to be patched anyway) to Magento, but I’ve been trying to tie it into a new automated pricing script I’ve been developing (also for a year or so).

I’ve also rationalised my count of subdomains on my domain and moved my old magento development environment from dev.domain.com to store.domain.com. Previously migrating domains has been a major PITA for Magento but today I decided to screw around in the database and found it to be rather painless!

The database is in the same location with same username/password so all I needed to do was to update the base_url and here’s all I did:

So a few steps, confirm that the two config_data fields are where you want them:

select * from mag_core_config_data where path like 'web/%/base_url';

+-----------+---------+----------+-----------------------+---------------------------------+
| config_id | scope   | scope_id | path                  | value                           |
+-----------+---------+----------+-----------------------+---------------------------------+
|        19 | default |        0 | web/unsecure/base_url | http://dev.domain.com/ |
|        20 | default |        0 | web/secure/base_url   | http://dev.domain.com/ |
+-----------+---------+----------+-----------------------+---------------------------------+

So it was a simple case of updating these values:

update mag_core_config_data set value = 'http://store.domain.com/' where path like 'web/%/base_url';

BUT unfortunately it still wasn’t rendering properly. I discovered that the pages get cached! OH NOES!

Oh well, let’s just purge the cache and start again:

#rm -Rf /path/to/magento/install/var/cache

And good to go! Now to upgrade to the latest version.

Full credit goes to radoulov, a member of unix.com forums and cursory link to post in thread

perl -MFile::Find -e'
  $d = shift || die "$0 dir\n";
  find { 
    wanted => sub {
      -f and push @{$u{$_}}, $File::Find::name;
      }
    }, $d;
  @{$u{$_}} > 1 and printf "found %s in: \n\n%s\n\n", 
    $_, join $/, @{$u{$_}} for keys %u;    
  ' <dirname>

I am backing up some videos to an external HDD and some are files and some are folders, so I’ve created a rsync script which uses a include.txt file.

rsync script is as follows:
rsync -avr --progress --files-from=include.txt / /media/Ext\ Storage

Then in my include.txt I have the following:
data/videos/dir1/
data/videos/dir2/
data/videos/file1.avi
data/videos/file2.mkv


Which I obtained from doing a find dump into a file find /data/videos/ > include.txt

Except for the includes.txt, it the directories need to have the trailing slash.

I first off tried to create a regex search and replace in vim which found all rows that didn’t have a file extension. I managed to create a expression which DID find them but couldn’t work out how to then wrap that in a NOT.

So I thought screw it, I’ll add a trailing slash / to every row then strip them out and after 45min of screwing around I finally got it.

:1,$ s/\(\.[a-zA-Z]*\)\/$/\1/c

I used /c just to make sure it wasn’t going to go crazy, and it didn’t!

It’s probably not the most elegant or efficient but I have a sense of achievement all the same

Found the tip here

shred -vfz -n 100 /dev/hda

Here /dev/hda is my whole hard disk. And I am asking shred to make (-n) 100 passes by overwriting the entire hard disk with (-z) zeros. And shred program (-f) forces the write by changing the permissions wherever necessary.

There doesn’t seem to be support for TT-RSS on Arch Linux, particularly in creating the /etc/rc.d/ daemon. So I hacked together this:

I edited the init.d files for TT-RSS to run on Arch Linux, which uses rc.d and doesn’t have start-stop-daemon. This is the first time I’ve done anything like this so please feel free to 1. provide constructive feedback and 2. be nice

Basically following the instructions as per UpdatingFeeds but use my attached files and place in rc.d instead of init.d

* Extract tt-rss-rc.tar.gz
cp tt-rss.default /etc/default/tt-rss
cp tt-rss.rc-d /etc/rc.d/tt-rss
/bin/chmod +x /etc/rc.d/tt-rss

* If you want Tiny Tiny RSS update daemon to start when you computer start :
Edit /etc/rc.conf
Add to "DAEMONS=(... tt-rss ...)"

* Once all this done, you can use this command line to start the update daemon :
/etc/rc.d/tt-rss start

* And this command line to stop the update daemon :
/etc/rc.d/tt-rss stop

Been working great for me for a couple weeks.

Background

I’ve run my linux server + Windows VM for a couple years now and the Windows VM does as much as the Linux host does. Coupling this with some issues with VMWare Server 1 on latest kernels and failed attempts to keep VMWare Server 2 stable, I decided to take the plunge into ESXi and virtualise my Linux machine too!

Initial Research

So my initial research indicated my NIC was fine but I can’t use linux software raid, which is how my linux box has been setup! Oh noes, oh well, time to get a hardware RAID controller. The cheapest one on the VMWare HCL is the Adaptec 2405, and found one 2nd hand for around 60% of the cost of a new one.

Problems Problems Problems

1. Virtualising my linux box. The VMWare Standalone Converter can’t convert Linux machines running mdadm/software RAID. BOO. Time to copy my important files off one of my RAID1 array to another single HDD.

2. Can’t initalise the disk. This is the problem and solution: http://ict-freak.nl/2009/03/14/vmware-failed-to-get-disk-partition-information/

3. Accessing the ESXi box via remote SSH:

http://professionalvmware.com/2009/05/26/unsupported-console-and-ssh-on-esxi-4/

4. Can’t access my non-mdadm drive in ESXi. RDM (Raw Device Mapping) is the answer. Here is the solution I used: http://www.daenks.info/2009/07/using-vcb-to-backup-entire-vms/

After solving all these issues though, I have to say, that moving to ESXi was the best thing ever. I’ve only had 1 problem since installing it and that was due to the USB drive becoming corrupted.

That was easily fixed by creating a new USB boot key and copying the local.tar.gz file from the old to new key. Boot up and wallah, good as new! Now I have a backup copy anyway

Everything has been going swimmingly well (and I’ll comment more on this another time) but one of my last ‘issues’ was getting my Samsung SCX-4521F printer working.

The AUR doesn’t explicitly have it, the closest being this.

So I tried using the Samsung driver out of the box and surprise surprise, no support for Arch Linux.

So I got out trusty old vim and added support for Arch Linux. The main issue is that:
1. It doesn’t detect Arch as a distro; and
2. It hardcodes the use of /etc/init.d.

So I just added an extra check for Arch Linux and set that variable then added a IF statement at the end to set a new variable INIT which sets it to rc.d or init.d and then updated all instances of init.d with $INIT. There is still a couple of WARNINGS produced but the driver works

THe last thing I needed to change comes care of this article and thats:

10. Open /etc/cups/printers.conf Under “DefaultPrinter scx4x21″ change the “DeviceURI” so it looks like this:
DeviceURI file:/dev/usb/lp0

Want to use it?

Download the Samsung Unified Linux Driver from the Samsung site and use this install.sh instead (you’ll need to rename it). The current version of the Samsung ULD is 3.00.37.

The ./checksetup.pl kept failing with the error message :

Converting table namedqueries… DBD::mysql::db do failed: Error on rename of ‘./bugzilla/#sql-3967_1c’ to ‘./bugzilla/namedqueries’ (errno: 150) [for Statement "ALTER TABLE namedqueries TYPE = InnoDB"] at Bugzilla/DB/Mysql.pm line 337
Bugzilla::DB::Mysql::bz_setup_database(‘Bugzilla::DB::Mysql=HASH(0x9c766d0)’) called at ./checksetup.pl line 144

Running the SQL command SHOW ENGINE INNODB STATUS; within mysql gave me the following bit of useful info:

————————
LATEST FOREIGN KEY ERROR
————————
090715 8:58:13 Error in foreign key constraint of table bugzilla/namedqueries_link_in_footer:
there is no index in referenced table which would contain
the columns as the first columns, or the data types in the
referenced table do not match to the ones in table. Constraint:
,
CONSTRAINT fk_namedqueries_link_in_footer_namedquery_id_namedqueries_id FOREIGN KEY (namedquery_id) REFERENCES namedqueries (id) ON DELETE CASCADE ON UPDATE CASCADE
The index in the foreign key in table is namedqueries_link_in_footer_id_idx
See http://dev.mysql.com/doc/refman/5.0/en/innodb-foreign-key-constraints.html
for correct foreign key definition.

So after a couple hours of research I’ve discovered the problem is that the table namedqueries doesn’t have the column id.

So in mysql:

use bugzilla;
alter table namedqueries add id mediumint(9) NOT NULL AUTO_INCREMENT UNIQUE FIRST;

Re-ran ./checksetup.pl and all was good

Now for the next upgrade error!

Everything went fairly smoothly (with the exception of ever-changing order of HDD’s, which is now fixed without the Live CD thanks to UUID’s) but I couldn’t figure out how to re-create my RAID1 mdadm array.
Googling away actually didn’t return what I wanted! I was starting to panic, as I didn’t quite think out my backup routine quite as well as I should have (i.e. don’t backup to a software-raid-array!) I sorta needed to get it restored!

Thankfully I figured it out:
mdadm --assemble /dev/md5 /dev/sdc1 /dev/sdd1

Back in business!