Sunday, February 22, 2009
I ended up installing everything in yast2 that even tangentically mentioned samba or netbios. I then opened up my firewall to the fullest extent possible, sacrificed two virgins, restarted netbios and samba a couple of times and lo and behold it worked. I then switched the firewall back on with samba and netbios selected as allowed services for the external zone and it seems happy enough with that. No real lesson learned here, just black magic. This is really just a note for other to let them know that it could in theory work.
Saturday, February 14, 2009
There are lots of good guides on the interwebs on how to do this but I wanted to get a few notes down so I remember my preferred/installed method. These instructions are for Debian/Ubuntu and assume the target server doesn't have an existing mediawiki or mysql installation. All this needs to be done as root.
1. Install mediawiki on the target server, install the same version.
2. Delete /var/lib/mediawiki1.7 on the target server.
3. Dump the mysql permissions database on the source server:
mysqldump -u root -pYOURPASSWORD --opt mysql > ~/mysql.sql
4. Copy that file over to the target file. Import it using the following command.
mysql -pYOURPASSWORD -h 127.0.0.1 mysql < ~/mysql.sql
5. Setup a cron job on the source host to dump the mediawiki sql database every night. Type crontab -e to edit the crontab and add the following line:
0 0 * * * mysqldump -u root -pYOURPASSWORD --opt wikidb > ~/wikidb.sql
6. On the target host, add cron jobs to copy across the database dump, the mediawiki config/uploaded files and to import the mediawiki database. Again do crontab -e and add the following:
0 5 * * * rsync -oglpvtr root@SOURCEHOST:/var/lib/mediawiki1.7 /var/lib > ~/backups/SOURCEHOST_mediawiki.log
0 5 * * * rsync -vtr root@SOURCEHOST:/root/wikidb.sql ~/wikidb.sql
0 6 * * * mysql -pYOURPASSWORD -h 127.0.0.1 wikidb < ~/wikidb.sql
Protip: you'll need your ssh keys setup so you can do passwordless authentication.
Wednesday, February 4, 2009
Tuesday, February 3, 2009
tsocks wget -r -l1 -t1 -N -A.pdf -erobots=off http://www.springerlink.com/content/x49g43t85772/
Does the job.
Anyways, for the last while, it has been impossible for me to enter the backslash character in a session. This is regardless of the keyboard layout on the client computer, the OS and was a seemingly random error. Today I erased the .silc/silc.conf file and restarted the silc client. Success - I am now able to connect to the server once again. The most infuriating aspect of this is that the error occured during a running session. When I copied urls into that session none of the slash characters would be displayed on the screen. Which was funny at first but very annoying once I restarted silc only to discover that I couldn't now type /connect. Which was funny for about 30 seconds. So there you go. If you are ever in the situation where you can't enter the slash key in a silc client just remove the configuration file.
Autocad doesn't like this file... I have no idea what created it. After much screwing around I've discovered that it doesn't like the "."s in the entity (or whatever they're called) names. Load the file in vim and use the following regexp to get rid of the dots.
Fixed file looks like this:
FYI, the \( \) are delimiters in the search sequence. \1 and \2 reference back to these.
Addition: The file in question was produced by a program called "Camera 3D" or "3D Camera" or something... Just in case anyone else has the same problem with this code.