Posts for the month of May 2005

Secret Firefox settings

Shamelessly stolen from: http://www.windowssecrets.com/comp/041202/

Go check it out!

Settings for me to remember:

browser.cache.memory.capacity 32000
layout.frames.force_resizability true
config.trim_on_minimize false 

Today was proxy fixing day!

Well, spent half of today fixing computers for the woman's family.

They insist on using AOL DSL, so to share the connection they have to use AnalogX Proxy instead of a "normal" wireless router. I got that up and running a year or so ago. But there have been glitches that I wasn't aware of until today.

Problem 1: Firefox don't work. On either client machine. Weird DNS issue too that I had once before with other reasons (look around on this blog). Basically any site you went to would be the same site as the first. Example - home page is google.com, then I try to go to windowsupdate.microsoft.com and it is google again. Type microsoft.com/cgi-bin/whatever and you get a 404 from google.com saying "I don't have /cgi-bin/whatever "

OK, so the fix. AnalogX proxy cannot handle HTTP/1.1 - you need to do HTTP/1.0 only.

about:config
Find "network.http.proxy.version" and make it "1.0"

Problem 2: Apparently, Microsoft in their infinite wisdom f'd up WindowsUpdate with SP2. The one machine worked fine. The other machine (brand new Dell laptop) didn't. So I update the other machine to SP2 and now it doesn't get WindowsUpdate either! Turns out that post-SP2 WindowsUpdate IGNORES THE PROXY SETTINGS YOU PUT INTERNET EXPLORER!!! What's the POINT?!?!

The fix: I'm not sure. There is a program "proxycfg" that sets up the proxy settings. I'm not sure which worked, one of these two (from the command line):

proxycfg -u

Supposedly updates the settings based on your IE ones. I'm not sure if that worked. Other possible:

proxycfg -p "http://10.70.70.70:6588"

(Obviously, put your proxy server/port in there)

As always, if this helped solve your problems, please drop me a 'thanx' note.

Shutting down VMWare clients

In /etc/services on CLIENT:

# Local services
shutdown 6666/tcp

In /etc/inetd.conf on CLIENT:

shutdown stream tcp nowait root /sbin/shutnow

In /sbin/shutnow of CLIENT: (you can prolly get rid of this and move this all into inetd.conf above, but I used to do other things too...)

#!/bin/bash
/sbin/shutdown -h now

On the CLIENT's iptables rules, I have:

0 0 DROP tcp -- eth1 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:6666

So nobody can reach that port from eth1 (internet). The host will be hitting the port on eth2 which is the host-only virtual network.

Then on the HOST in /etc/init.d/kill_vms (new file):

#!/bin/sh
#
# chkconfig: 4 90 08
# description: Kills VMs on shutdown/reboot
/usr/bin/telnet 192.168.90.201 6666 < /dev/zero
PIDS=fake
while [ "foo$PIDS" != "foo" ]
do {
echo "Delaying shutdown... VMWare still on $PIDS"
sleep 10
PIDS=`pidof vmware-vmx`
};
done

So then on the server you install the "kill_vms" with chkconfig (fix the IP from 192.168.90.201 to your virtual client IP of course!).

It won't work the first time you reboot, sorry. If you 'touch' the file /var/lock/subsys/kill_vms (at least on my ancient RH based system) then it should. Also, it will hang forever if you don't have the virtual machine set to 'Close on shutdown' and I think maybe another option in VMWare about closing if all clients close.

GPart - Guess partitions

Friend has his partition table hosed. He's starting with this, and it seems to be working very well. Looks awesome, figured I would virtually jot it down...

http://www.stud.uni-hannover.de/user/76201/gpart/

http://www.stud.uni-hannover.de/user/76201/gpart/gpart-man.html

Follow-up: He was able to get back his data. He actually ended up using this: http://www.cgsecurity.org/index.html?testdisk.html