this is actually not an error when mysql_intall_db is run as the mysql user, but if that is run as root when building the initial tables, it makes the directory /var/lib/mysql unwritable to the mysql user. quick fix even when the install is run as root:
# chown -R mysql.mysql /var/lib/mysql
ok so ran into a situation where we had to run a serial printer from a good 40 feet so we layed down a cat 5 wire and decided to map the pinouts of the factory cable to see if we could get it to run on the cat 5. we succeeded and the pinouts are below:
DB25 Signal Name DB9 Signal Name
12 CD 4 DTR
3 RD 3 TD
2 TD 2 RD
20 DTR 6 DSR
7 Ground 5 Ground
this works when hardware handshakes are set to DSR only
host file entries made for:
127.0.0.1 www.google-analytics.com google-analytics.com ssl.google-analytics.com analytics.google.com googleanalytics.com
how can it be tracking at this point?
alright so netfirms blocks rsync, right? well even if you didn’t know, it’s true. So my backup methods have been less than desireable while i spend time brainstorming the real answer.
today i found it.
I’ve played around with sshfs before and the solution was inherent in this new toolset.
netfirms gives ssh access (to accounts that pay for it)
all things being what they are heres what i did:
1. install sshfs on backup server
2. sshfs mount my www root on netfirms to my backup server to a local mountpoint
# sshfs email@example.com:/path/to/www/ /mnt/sshfs
3. begin the rsync to a local folder
# rsync -azevvv /mnt/sshfs /local/backup/
4. fire it off and go get a 12 pack and maybe more if your hosting dir is large with lots of domains
5. once it has done, unmount the appropriate shit and find a way to script it.
# umount /mnt/sshfs
6. Yay! now you have an active rsync method for netfirms…why did they have to make it so difficult!