For some reason, on my home LAN, I have trouble playing Age of Empires. I know, it’s an old game, but I still like to play it. I’m connected at home via a Linksys WRT54G-L. I’ve also connected up a Netgear MR814 used as a hub, but I don’t think that’s the issue. I’m not using dhcp on either of those boxes – I have a separate machine as a dhcp server. Anyways, clicking “Show games” would never work! I thought initially it was some software issue, so I reinstalled Windows and it still didn’t work. I swapped out the WRT54G-L for a switch and then it worked! After some googling, I found that it might be the UPnP. Hopefully, this fixes it. It works now, but then again, it used to work before too. We’ll see.
Tag: networking
DHCP server with DDNS
authoritative;
include “/etc/bind/rndc.key”;
server-identifier chunli.shocknetwork.com.;
ddns-domainname “shocknetwork.com.”;
ddns-rev-domainname “in-addr.arpa.”;
ddns-update-style interim;
ddns-updates on;
ignore client-updates;
zone shocknetwork.com. {
primary 127.0.0.1;
key rndc-key;
}
default-lease-time 21600; # 6 hours
max-lease-time 43200; # 12 hours
option domain-name “shocknetwork.com”;
option domain-name-servers chunli.shocknetwork.com, resolver1.opendns.com;
default-lease-time 600;
max-lease-time 7200;
log-facility local7;
subnet 192.168.0.0 netmask 255.255.255.0 {
range 192.168.0.100 192.168.0.200;
option domain-name-servers chunli.shocknetwork.com, resolver1.opendns.com;
option domain-name “shocknetwork.com”;
option routers 192.168.0.1;
option broadcast-address 192.168.0.3;
default-lease-time 600;
max-lease-time 7200;
zone 0.168.192.in-addr.arpa. {
primary 192.168.0.3;
key rndc-key;
}
zone localdomain. {
primary 192.168.0.3;
key rndc-key;
}
}
/etc/named.conf –> I’m using Ubuntu 6, so it’s actually /etc/bind/named.conf and named.options, etc, but for the sake of simplicity, I’ll put them all together.
options {
directory “/var/cache/bind”;
auth-nxdomain no; # conform to RFC1035
};
zone “.” {
type hint;
file “/etc/bind/db.root”;
};
zone “localhost” {
type master;
file “/etc/bind/db.local”;
};
zone “127.in-addr.arpa” {
type master;
file “/etc/bind/db.127”;
};
zone “0.in-addr.arpa” {
type master;
file “/etc/bind/db.0”;
};
zone “255.in-addr.arpa” {
type master;
file “/etc/bind/db.255”;
};
controls {
inet 127.0.0.1 allow {localhost; } keys { “rndc-key”; };
};
// Add local zone definitions here.
zone “shocknetwork.com” {
type master;
file “/etc/bind/shocknetwork.com.zone”;
allow-update { key “rndc-key”; };
notify yes;
};
zone “0.168.192.in-addr.arpa” {
type master;
file “/etc/bind/0.168.192.in-addr.arpa.zone”;
allow-update { key “rndc-key”; };
notify yes;
};
include “/etc/bind/rndc.key”;
Some troubleshooting tips:
1) turn on logging for DNS:
logging {
category “default” { “debug”; };
file “/tmp/nameddbg” versions 2 size 50m;
print-time yes;
print-category yes;
};
That’s about it – it should give you all you need.]]>
VMotion failed … everything looks right … why?
Obviously, if everything’s right, it won’t fail, but here, it’s more a bug than anything else. In this case, if you use dedicated NICs just for VMotion and you’ve just a crossover cable between the 2 nics, you may have a problem if you’re using the same network IP addresses for the Vmotion IPs. It seems to want to look for the router or something. You’ll see that it logs in both boxes, so you may want to rule out the networking issue, but you can’t in this case. The logs on both sides will indicate timeout. In this case, both of the servers are on the 10.x.x.x/24 network and the VMotion and iSCSI networks have ip addresses that were both 10.x.x.x/24, but the VMotion nics can’t access the router. The fix is easy. Just change the IPs to something that the server doesn’t know about … something like 192.168.0.1/24 or something.
Apache SSL Self-Signed Certificates Without Passphrase
taken from: http://www.rpatrick.com/tech/makecert/
Following is a quick listing of the commands you need to use when setting up an SSL key for Apache that doesn’t require a passphrase to be entered during normal operations, and includes a self-signed certificate so you needn’t bother with cert requests and CAs. The sequence of events is to create a 3DES key, remove the passphrase, and then generate a self-signed certificate.
The following commands are to be entered via the command line, with each openssl statement requiring interactive input. Performed on Red Hat Linux, these instructions ought to also work on other flavors of Unix with OpenSSL and Apache installed.
openssl genrsa -des3 -out pass.key 1024
openssl rsa -in pass.key -out server.key
openssl req -new -key server.key -x509 -out server.crt -days 999
cp server.key /etc/httpd/conf/ssl.key/
cp server.crt /etc/httpd/conf/ssl.crt/
apachectl restart
Verifying that Apache has the correct SSL directives and is using the correct key and certificate created above is left as an exercise for the webmaster.
If your system has a Makefile or symlink in the Apache conf directory, you can opt to pursue an earlier method to this madness using the below steps (provided here only for completeness):
cd /etc/httpd/conf
/usr/bin/openssl genrsa 1024 > /etc/httpd/conf/ssl.key/server.key
chmod go-rwx /etc/httpd/conf/ssl.key/server.key
make testcert
Optionally, if you need a server.pem file for a given application, such as courier-imapd, use the following to create the .pem file from the previously created certificate and key:
cat server.key server.crt >server.pem
Using the above method you can enjoy the encryption protection provided by SSL without having to pay a commercial vendor to sign your server keys. If you don’t like the popup presented by some applications (e.g. web browsers) about an untrusted certificate, simply follow the process provided by your application to import or install the certificate, at which point you will no longer have to deal with future dialog boxes regarding an untrusted site.