How to Set Up DNS Blacklisting in a Lab Environment for Test

This is a very simple setup for those who have a lab environment where they do not want to be connected to the public Internet while doing the testing.

Some background:

The way dnsbl works is that when a connection is made to your mail server, it will take the client’s IP address, reverse it, append a domain onto it, and do a dns A or TXT record lookup for that name.

For example, if a spammer’s IP is 10.4.17.108, and you are using spam.list.com as your dnsbl site, your MTA will do a query for 108.17.4.10.spam.list.com. If the query returns positive, it means that the IP address is listed in the blackhole list and that mail should be rejected.

So the first thing you will need to do is set up a simple dns server. You can find out how to do that by consulting the DNS & Bind book or http://docs.sun.com/db/doc/816-7511 or various other sources.

Then, you need to set up a zone. Here's a sample:
 
# cat /var/named/spam.list.com
 
$TTL 86400 
@ 1D IN SOA @ root (
  42 ; serial
 3H ; refresh
 15M ; retry
 1W ; expiry
 1D ) ; minimum
NS localhost.
 A 10.4.16.11
108.17.4.10 IN A 127.0.0.2
108.17.4.10 IN TXT "10.4.17.108 is listed in spam.list.com"

With this in tact, all you need to do is set up your MTA to use spam.list.com for dnsbl calls.

ESX3 – remote console not coming thru – everything else ok

Problem: From the Virtual Infrastructure Client, I log in and can do whatever I want except see a VM’s console. The VM can power up, I can modify the VMs, but when I go to the console, it just gives me a black blank screen. When I use open console, I get a timeout. I set up the vmx file so that I could use vnc to connect to the console and it works fine. When using the webAccess, I can see the console just fine too. What gives?

In the VI3 server, connections are handled a little differently. Incoming RC connection go to port 902 in the COS: vmware-authd service Then, the MKS (mouse, keyboard, screen) connection happens on port 903 – vmware-vmkauthd listens on port 903. Since connections to port 903 are forwarded to COSShadow, COS would not see those packets. The client actually makes a request on port 902, but then, the server gives a redirect to the client to connect on port 903. If there’s any type of NAT in between or some other network tweak, it could cause this to fail.

Here’s the workaround:

1) Open up the /etc/vmware/config file and append to the bottom:

vmauthd.server.alwaysProxy = “TRUE”

2) Restart the management agents by running:

/etc/init.d/mgmt-vmware restart

3) Disconnect and reconnect the Virtual Infrastructure Client or VirtualCenter from the ESX server.

This will avoid the authd redirection and it should allow your remote console to function properly.

How to allow ssh into a machine w/o a password

First thing you need to do is give your public key to the server that you’ll be allowed into:

To generate the keys I run (on the client):

ssh-keygen -t dsa

Here’s the output:

Generating public/private dsa key pair.

Enter file in which to save the key (/home/alton/.ssh/id_dsa):

Created directory ‘/home/alton/.ssh’.

Enter passphrase (empty for no passphrase):

Enter same passphrase again:

Your identification has been saved in /home/alton/.ssh/id_dsa.

Your public key has been saved in /home/alton/.ssh/id_dsa.pub.

The key fingerprint is:

9b:e8:24:89:34:78:ab:fd:85:93:97:df:10:9c:c8:16 alton@streetfighter

Now you’ve got to move your public key to the other machine (the server). I just take a look at the contents of the file:

[alton@streetfighter ~]$ cat /home/alton/.ssh/id_dsa.pub

ssh-dss AAAAB3NzaC1kc3MAAACBASC1tnxqkSqdGswZkp1P0o6Xn93N9XB5VpenK4k/bV2g7ojywh83CAhjhM5gKlCJ2XI+gM+XD12t+M3+Gxlre79ltiH+L86A33trW6PmUR9cQOp9cLHEzC5bjfs3esqWuuFxC4ObpHbJXakNmSQlSsNzE8ZnGG6emHJUVkNyTcjXAAAAFQD1+ZD6LG2PlwPRHLYmVxGWOm3woQAAAIAHR88SB2dnnjE2a9fQAydR2pbMOrh4X7CISuCnGtPp0lFwAIm5WAMS2oQ8Mh9HG8ou9wjhPgGSlCe4jvZEZyqlOADTZLX8hzno8LMHMTBbNxKji3qGOzJZJBbdhwg9GwitWbrHrXfZS7p2+HAIvDKINleapgrXwrInEJ6zWPYDewAAAIAo4Nud2c06/3A9LqIGeB64Nvecb2MOBOaBSeiXHqOSE/c1a9gmTCb5im3qIcrWs+cgUXbCxyHWaYQYTWUWsLh79TaLIe/rXOMr58aXQ34k1rcXaOgw3nb45YxcEIbAcqO85zc+clpfhTVzM8Aqkh5hv1b9/1pBkz75oC5KsYYkrPQ== alton@streetfighter

Then I go to the other machine and copy the contents into ~/ssh/authorizedkeys

So in the file, I add a new line if it exists and:

ssh-dss AAAAB3NzaC1kc3MAAACBASC1tnxqkSqdGswZkp1P0o6Xn93N9XB5VpenK4k/bV2g7ojywh83CAhjhM5gKlCJ2XI+gM+XD12t+M3+Gxlre79ltiH+L86A33trW6PmUR9cQOp9cLHEzC5bjfs3esqWuuFxC4ObpHbJXakNmSQlSsNzE8ZnGG6emHJUVkNyTcjXAAAAFQD1+ZD6LG2PlwPRHLYmVxGWOm3woQAAAIAHR88SB2dnnjE2a9fQAydR2pbMOrh4X7CISuCnGtPp0lFwAIm5WAMS2oQ8Mh9HG8ou9wjhPgGSlCe4jvZEZyqlOADTZLX8hzno8LMHMTBbNxKji3qGOzJZJBbdhwg9GwitWbrHrXfZS7p2+HAIvDKINleapgrXwrInEJ6zWPYDewAAAIAo4Nud2c06/3A9LqIGeB64Nvecb2MOBOaBSeiXHqOSE/c1a9gmTCb5im3qIcrWs+cgUXbCxyHWaYQYTWUWsLh79TaLIe/rXOMr58aXQ34k1rcXaOgw3nb45YxcEIbAcqO85zc+clpfhTVzM8Aqkh5hv1b9/1pBkz75oC5KsYYkrPQ== alton@streetfighter

That’s all.

license problem…not enough licenses, but 0 of 6 are used

LMtools seems to check out the licenses according to their logs, but they check back in immediately. Interesting huh? We tried changing the file different ways – it was so weird. Finally, we had someone in support use the license checker tool that they have and they found that we mixed up the hosted licenses w/ the server based licenses – doh! … so we just separated them and created new files and it was all set.

It turns out that the website when generating licenses can generate host based licenses instead of server based licenses. You can tell the difference by seeing:

VENDOR_STRING=licenseType=Host

opposed to:

VENDOR_STRING=licenseType=Server

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.

NTP notes

http://www.cisl.ucar.edu/nets/intro/sta … s/ntp.html NTP (Pete’s notes) To get ntpd working, get a version that’s at or later than
ntp-stable-4.2.0a-20040617. Gunzip it, untar it, run ./configure,
make and make install. I couldn’t RPM-delete the ntp that’s
installed, so I hand-deleted all the ntp* binaries in
/usr/sbin. I know this isn’t optimal. Then I
hand-edited the /etc/init.d/ntpd, deleted the
/etc/sysconfig/ntpd, and made
/etc/sysconfig/iptables allow ntp packets. Then
I edited /etc/ntp/conf to camment out all the
lines except restrict 128.117.0.0 mask 255.255.0.0
disable auth
broadcastclient
I did
/etc/init.d/ntpd stop
/etc/init.d/ntpd start
,,,and waited a few minutes for the router’s broadcast packets to
be heard. Then I did ntpq and “peers” and saw the router listed.
One other possible problem: if your machine’s time is too far
out of sync with the router’s, ntpd won’t correct it. To force
synchronization, do “ntpdate mlra”.
The ntp.conf file has a section that configures
a fake driver. If you leave that on, you’ll see the “LOCAL”
peer. When you comment it out, ntpq “peers” will give
“No

How to build redhat kernel for VMware for time issue

Anyways, here’s how you do it:
1) download kernel source. I got mine from:
ftp://ftp.redhat.com/pub/redhat/linux/u … EL.src.rpm 2) install source:
rpm -i kernel-2.6.9-34.0.2.EL.src.rpm
(You may need to run “mkdir -p /usr/src/redhat/SOURCES”. If that’s the case, then I’d run “mkdir -p /usr/src/redhat/SOURCES /usr/src/redhat/SPEC /usr/src/redhat/RPMS /usr/src/redhat/SRPMS /usr/src/redhat/BUILD” just in case. ) 3) edit files to include BusLogic driver:
cd /usr/src/redhat/SOURCES edit the following files:
kernel-2.6.9-i686.config
kernel-2.6.9-i686-hugemem.config
kernel-2.6.9-i686-smp.config replace all instances of:
# CONFIG_SCSI_BUSLOGIC is not set
with:
CONFIG_SCSI_BUSLOGIC=m 4) make a patch change the Internal kernel timer frequency.
cd /usr/src/redhat/SOURCES
tar jxvf linux-2.6.9.tar.bz2
mkdir -p linux-2.6.9-vmware/include/asm-i386
cp -pr linux-2.6.9/include/asm-i386/param.h linux-2.6.9-vmware/include/asm-i386/param.h
open linux-2.6.9-vmware/include/asm-i386/param.h
change
# define HZ 1000 /* Internal kernel timer frequency */
to
# define HZ 100 /* Internal kernel timer frequency */ diff -urN linux-2.6.9/include/asm-i386/param.h linux-2.6.9-vmware/include/asm-i386/param.h > vmware.patch add the patch to the spec file list
open /usr/src/redhat/SPECS/kernel-2.6.spec
added to where it lists the patches (your numbers may vary):
I just made it Patch 5 since it doesn’t exist:
so after the line: Patch4: linux-2.6.9-selected-ac-bits.patch
Patch5: vmware.patch and where it does the prep after the line: %patch4 -p1
%patch5 -p1 5) change the release of your kernel to differentiate:
cd /usr/src/redhat/SPECS
open the file: kernel-2.6.spec and change:
%define release 34.0.2.EL
to
%define release 34.0.2.EL.vmware 6) build the rpm.
rpmbuild -ba –target=i686 /usr/src/redhat/SPECS/kernel-2.6.spec You could use
rpmbuild -bb –target=i686 /usr/src/redhat/SPECS/kernel-2.6.spec
if you only need the binary rpms, but since we modified the source, I like to use ba, so I can reuse the source rpm should I need to compile again.]]>

Buslogic driver for RHEL4 update4 (2.6.9-39 kernel)

For the update4 (20060605) distro, the kernel version is 2.6.9-39, so the buslogic driver on VMware’s site doesn’t work anymore. You can use the one attached, but it’s not supported by VMware. Install Linux by following the instructions on their site.

This is obviously not supported by VMware, Inc. There’s also no guarantee that your VM will be stable, but I’d bet that it would be.

ESX 3.0 cdrom problem – won’t mount / won’t work for Guest

[root@wesx3 root]# mount /dev/cdrom /mnt/cdrom/
mount: /dev/cdrom: can’t read superblock from /var.log/messages
Apr 27 09:40:06 wesx3 modprobe: modprobe: Can’t locate module ide-cd Fix with the following:
1) remove the line from /etc/vmware/esx.conf by running:
nano /boot/kernelAppend = “hda=ide-scsi”
2) remove hda=ide-scsi from /etc/grub.conf using nano again:
nano /etc/grub.conf
3) reboot the machine. That’s it!]]>

Web access doesn’t work on new install or upgrade of ESX 3

You can run these commands:

esxcfg-vswitch -A serviceconsole vSwitch0

esxcfg-vswif -a -i 192.168.0.2 -n 255.255.255.0 -p serviceconsole vswif0

That should be it. The new interface is vswif0 rather than eth0.

This problem is common among upgrades that have 2 nics shared between the service console / vmkernel.