Did you know the natural keyboard 4000 has a "F-Lock" key?
http://www.ehow.com/how_6777639_enable-function-keys-microsoft-keyboard.html
Open a program that uses the function keys such as Microsoft Word or Microsoft Excel. Check your keyboard for an "F-Lock" or "Function Lock" key. This key is used to toggle function-key support; when it is toggled on, the function keys will not work.
A place for John to record his techy notes, both to refer back to when needed, and as a help for others...
Tuesday, June 14, 2011
Monday, June 13, 2011
Windows hosts file ignored
If you have already tried all of these things:
http://mihaiu.name/2005/windows-hosts-file-ignored/
If you've copied the file from somewhere else rather than opening it and pasting in entries, check the permissions on the file.
The file permissions could be wrong meaning Windows will not read it.
More reading:
http://www.bleepingcomputer.com/tutorials/tutorial52.html
http://mihaiu.name/2005/windows-hosts-file-ignored/
If you've copied the file from somewhere else rather than opening it and pasting in entries, check the permissions on the file.
The file permissions could be wrong meaning Windows will not read it.
More reading:
http://www.bleepingcomputer.com/tutorials/tutorial52.html
Wednesday, June 01, 2011
Why does ifup eth1 make eth0 stop working?
and this was a gotcha that stole a couple of hours...
Answer... it didn't stop working, I just couldn't see it...
bringing up eth1 when I'd cloned eth0's config:
and neglected to remove this line:
When eth1 came up after eth0, it would over-write the default route.
I realised what the problem was when I noticed that a terminal logged in from another host on the same subnet was still working, the one I'd been using from my desktop was being disconnected - the default gateway was obviously missing or wrong.
Before (bad):
suddenly it starts working again...
But really we want:
Answer... it didn't stop working, I just couldn't see it...
bringing up eth1 when I'd cloned eth0's config:
/etc/sysconfig/network-scripts/ifcfg-eth0
/etc/sysconfig/network-scripts/ifcfg-eth1
and neglected to remove this line:
GATEWAY=AA.BB.CC.DD
When eth1 came up after eth0, it would over-write the default route.
I realised what the problem was when I noticed that a terminal logged in from another host on the same subnet was still working, the one I'd been using from my desktop was being disconnected - the default gateway was obviously missing or wrong.
Before (bad):
# netstat -nr
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
192.168.98.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
172.16.98.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth1
0.0.0.0 192.168.98.98 0.0.0.0 UG 0 0 0 eth1
# route add default gw 172.16.98.1
suddenly it starts working again...
# netstat -nr
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
192.168.98.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
172.16.98.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth1
0.0.0.0 172.16.98.1 0.0.0.0 UG 0 0 0 eth0
0.0.0.0 192.168.98.98 0.0.0.0 UG 0 0 0 eth1
But really we want:
# netstat -nr
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
192.168.98.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
172.16.98.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth1
0.0.0.0 172.16.98.1 0.0.0.0 UG 0 0 0 eth0
Two things I learned today...
One, was (by fluke) that ^Y suspends a process like ^Z does... although it waits until the process wants to read input from the terminal before it suspends it... I guess that could be a useful criteria in some situations... I can probably think of other more useful things that could be implemented as built-in features though :-)
http://www.gnu.org/software/bash/manual/bashref.html#Job-Control-Basics
and the second was...
http://www.gnu.org/software/bash/manual/bashref.html#Job-Control-Basics
and the second was...
Subscribe to:
Posts (Atom)