Unflappings

For anyone who is trying to access file shares inside local VM’s running windows Vista or Windows 7, the following article does a great job explaining what needs to be done in order to change the “Location” of the VMware NICs. Apparently by default Windows cannot figure out what or where they are, so it shoves them off in the Public location and disables most of their abilities. I tried the registry key fix and it worked flawlessly (albeit after a reboot).

This issue also arises if your virtual environment has a different domain than your physical host workstation, which was the case for me. This will prompt you to authenticate, but no matter what credentials you enter, the share login will be unsuccessful. Anyway, give this a shot.

http://aspoc.net/archives/2008/10/30/unidentified-network-issue-with-vmwares-virtual-nics-in-vista/

Bold indicates a button clicked or key pressed.
“quotes” indicates a value which has been entered.

Grey block quote is a command typed directly into the console.

If you happen to come across the following error:

Joined ‘LOCALHOST’ to realm ‘test.lcl’
[2010/03/04 14:39:39,     0] utils/net_ads.c:1080(net_update_dns_internal)   net_update_dns_internal: Failed to connect to our DC!
DNS update failed!

This simply means that your FQDN entry for the Linux system you are trying to join is incorrect as far as AD is concerned. In this case the box LOCALHOST.LOCAL.LCL was trying to join the domain TEST.LCL and there was an obvious mismatch. However not quite as obvious of an error message. Update this information in your /etc/hosts file and you should be set!

If you are using pfSense (and possibly FreeBSD for that matter) you may have run into the problem of VLAN interfaces not responding after a reboot or interface creation. This leads to serious problems when this is your main router platform, as independent network segments are unable to communication.

Symptoms of this include:

• Systems can ARP the MAC address of the network card, but are unable to ping it.
• pfSense with Realtek RTL8110SC NIC responds to DHCP or any other layer 2 system but does not respond on layer 3.
• Realtek RTL8110SC instability issues and inconsistent VLAN state.

The fix  for this is much less than ideal, but it works in a pinch and in most situations where absolute performance is not the key, but rather making things stable till another workaround (or suggested hardware replacement) comes up.

#ifconfig rex promisc

Where “reX” is reO, re1, etc… or whatever the name of your parent interface. Doing this on a per-vlan level will not help. Please be aware there are performance hits to this tactic, as each packet seen on the interface will be passed to the CPU, not just the ones destined for it.  It may be quick and dirty, but it works. If anyone has an alternate suggestion on why this happens, please chime in.

Came across the issue of having to install Server 2008 R2 (Windows 7 kernel, NOT Windows Server 2008 SP2) on a Dell PoweEdge 2950.  Server 2008 R2 wouldn’t proceed with the installation and was asking for a nonspecific driver.  After a large amount of trial and error, I finally decided to go about upgrading the firmware of the Dell Remote Administration Controller (DRAC)  to the latest revision. This then allowed the installation to continue without a problem, and all other drivers were found flawlessly.

So if you have a Dell PowerEdge 2950 with a DRAC version 5 controller card, give this a try when installing Windows Server 2008 R2.

Bold indicates a button clicked or key pressed.
“quotes” indicates a value which has been entered.

Grey block quote is a command typed directly into the console.

1. Edit /etc/inetd.conf and ensure that the following lines are commented out:

telnet stream tcp nowait root /usr/libexec/telnetd telnetd

telnet stream tcp6 nowait root /usr/libexec/telnetd telnetd

Bold indicates a button clicked or key pressed.
“quotes” indicates a value which has been entered.

Grey block quote is a command typed directly into the console.

Purpose

If you have ever installed the snmpd package for Debian or Ubuntu and wondered why it did not bind to all active interfaces no matter what configuration you have, here is the solution.

Procedures

1. You need to modify the “/etc/defaults/snmpd” file and remove the reference to 127.0.0.1 in the startup command to allow it to fall back to defaults. This was put in as a security measure, but there are very valid reasons to remove it.
2. Change the following in the “/etc/defaults/snmpd” file.

SNMPDOPTS=’-Lsd -Lf /dev/null -u snmp -I -smux -p /var/run/snmpd.pid 127.0.0.1′

SNMPDOPTS=’-Lsd -Lf /dev/null -u snmp -I -smux -p /var/run/snmpd.pid’