Month: January 2018

Printers, scanners, and internal applications often need to send email through Exchange without authenticating. In Exchange 2010 you can allow this safely by creating a dedicated receive connector that accepts anonymous mail only from your internal network.

1. Create a New Receive Connector

Open the Exchange Management Console, go to Server Configuration → Hub Transport, and click New Receive Connector. Fill in a descriptive name and the network settings.

2. Allow Anonymous Users

On the connector’s Permission Groups, make sure Anonymous users is checked.

3. Restrict It to Your Local Network

Limit the remote IP ranges so only your internal network can use this connector. This keeps your Exchange server from becoming an open relay.

After deploying a Windows Server 2008 R2 x64 VM from a template in vSphere 5, you may see the “VMware image customization is in progress” message every time it reboots, long after customization should have finished. The cause is a leftover entry in the BootExecute registry value.

What You’ll See

First the loading screen:

Followed by:

The Fix: Edit the BootExecute Registry Value

1. Open regedit and browse to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager:

2. Open the BootExecute value:

3. Change it from this:

To this:

4. Reboot. The customization message should no longer appear.

If your PuTTY or SSH session to a Linux server logs you out after a period of inactivity, the shell’s TMOUT environment variable is a likely cause. It tells bash to close an idle session after a set number of seconds.

Check Whether TMOUT Is Set

env | grep TMOUT
# or
echo $TMOUT

Change or Disable the Idle Timeout

Set a longer timeout, in seconds (here, one hour):

export TMOUT=3600

Or turn the feature off for your session:

unset TMOUT

Note: your system administrator may have set TMOUT for security reasons. If you’re not the admin, check with them before changing it.

When monitoring Windows servers with Nagios through NSClient, the agent may reject checks until its password is set. In the NSC.ini file, set the password parameter. In my setup it needed to match the SNMP community string.

NSC.ini Excerpt

;# PASSWORD
;  This is the password (-s) that is required to access NSClient remotely.
;  If you leave this blank everyone will be able to access the daemon remotely.
password=public

Restart the NSClient service after saving, and use the same value with -s in your Nagios check_nt command definitions.

Another round of HBA trouble, this time with an older QLogic QLE2462 Fibre Channel host bus adapter connected to a set of 12 TB Promise storage arrays on VMware ESXi.

The Fix

Save yourself some trouble: download the QLogic driver from VMware and import it into VMware Update Manager, then remediate and reboot the hosts.

qla2xxx-934.5.4.0

I had an ESXi host with dead storage paths causing All Paths Down (APD) issues. The cause was old LUNs that had been detached but were still listed on the host. Removing them from the detached device list cleared it up.

1. List the VMFS Datastores in Use

First confirm which devices back your live datastores, so you don’t remove one by mistake:

~ # esxcli storage vmfs extent list
Volume Name  VMFS UUID                            Extent Number  Device Name                           Partition
-----------  -----------------------------------  -------------  ------------------------------------  ---------
BackupSAN    50eb10a0-4f1a9256-5434-90e2ba22c340  0              naa.6842b2b000687ee500002a4850ea9934  1
Operations   5053a326-370b5095-739a-00137234e92a  0              naa.68b7b2acf4b8d12b3a051502000020ca  1
Templates    506204f5-fe667464-c1b1-90e2ba22c340  0              naa.68b7b2acf4b80148200615353227e7f3  1
CorpStor01   5053a1e4-e68f6227-0e8a-001ec9fd0643  0              naa.68b7b2acf4b8b1163a05e5010000c0a2  1

2. List Detached Devices

~ # esxcli storage core device detached list
Device UID                                                  State
----------------------------------------------------------  -----
naa.6090a058e015725f990965020000a09e                        off
naa.68b7b2acf4b8f10e0d0585010000004c                        off
t10.FreeBSD_iSCSI_Disk______100000010_______________________  off

3. Remove the Stale Detached Devices

esxcli storage core device detached remove -d naa.6090a058e015725f990965020000a09e
esxcli storage core device detached remove -d naa.68b7b2acf4b8f10e0d0585010000004c
esxcli storage core device detached remove -d t10.FreeBSD_iSCSI_Disk______100000010_______________________

Then rescan your storage adapters. The dead paths should be gone.

SSH key authentication lets you log in from one Linux server to another without typing a password, which is essential for scripts, backups, and automation. Here’s how to set it up between server1 and server2.

1. Generate a Key Pair on server1

ssh myusername@server1
ssh-keygen -t rsa

Press Enter at each prompt to accept the defaults (leave the passphrase empty for fully passwordless logins). You’ll see output like this:

Generating public/private rsa key pair.
Enter file in which to save the key (/home/local/myusername/.ssh/id_rsa):
Created directory '/home/local/myusername/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/local/myusername/.ssh/id_rsa.
Your public key has been saved in /home/local/myusername/.ssh/id_rsa.pub.
The key fingerprint is:
15:68:47:67:0d:40:e1:7c:9a:1c:25:18:be:ab:f1:3a myusername@server1

Display the public key and copy it. Make sure it stays on one line when you copy it; line breaks will stop the key from working.

cd .ssh
cat id_rsa.pub
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAyFS7Ykakcjdy...== myusername@server1

2. Add the Public Key on server2

ssh myusername@server2
mkdir .ssh
cd .ssh
vi authorized_keys
# paste the public key, then save
chmod 600 authorized_keys

3. Test It

ssh myusername@server1
ssh myusername@server2
# you should not be prompted for a password!

Tip: on most modern systems, ssh-copy-id myusername@server2 does step 2 for you in one command.

Windows Server can log a user on automatically at startup, which is useful for kiosks, lab machines, or servers that must run an app in an interactive session. This follows Microsoft’s registry method for turning on AutoAdminLogon.

Security note: this stores the password in plain text in the registry. Use it only where that risk is acceptable.

Steps to Turn On Automatic Logon

1. Click Start → Run, type Regedt32.exe, and press Enter.
2. Go to this key:
   HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon
3. Double-click DefaultUserName, enter the user name, and click OK.
4. Double-click DefaultPassword, enter the password, and click OK. If DefaultPassword doesn’t exist, create it: Edit → New → String Value, name it DefaultPassword, then set the password. Without a DefaultPassword value, Windows automatically switches AutoAdminLogon from 1 back to 0, disabling it.
5. Create another string value with Edit → New → String Value, name it AutoAdminLogon, and set it to 1.
6. Close Registry Editor and restart the computer. It will now log on automatically.

Notes and Troubleshooting

• Log on as someone else: hold down Shift after you log off or while Windows restarts to bypass automatic logon.
• Logon banners break it: automatic logon won’t work if a logon banner (legal notice) is set by Group Policy or local policy. Exclude the server from that policy and it works as expected.
• DefaultUserName gets overwritten: when a different user logs on at the console, Windows saves them as DefaultUserName, and AutoAdminLogon can then fail because the user and password no longer match. A shutdown script that resets DefaultUserName fixes this. See Microsoft KB 119364, “AutoAdminLogon loses DefaultUserName”.