Archive for February, 2013

PSU MacAdmins Conference 2013

Wednesday, February 27th, 2013

It's Secret!

For the third year, I’ll be presenting at PSU MacAdmins Conference! This year I’m lucky enough to be able to present two talks, “Backup, Front to Back” and “Enough Networking to be Dangerous”. But I’m really looking forward to what I can learn from those speaking for the first time, like Pepijn Bruienne and Graham Gilbert among others. The setting and venue is top-notch. It’s taking place May 22nd through the 24th, with a Boot Camp for more foundational topics May 21st. Hope you can join us!

Spin passwords using Apple Remote Desktop

Monday, February 18th, 2013

We routinely need to change our administrative passwords on multiple computers as part of our security policy. Since we already have remote access to many of our Mac OS X computers through Apple Remote Desktop (ARD), changing that administrator password is quick and simple.

First, a short shell script:

#!/bin/bash
# Change an account's password

ACCOUNT="ladmin"
PASSWORD="MyNewP@55w0rd"
/usr/bin/dscl . passwd /Users/$ACCOUNT $PASSWORD

if [ $? = 0 ] ; then
echo "Password reset."
else
echo "Password not reset."
fi

In ARD, click the Send UNIX Command button and paste the script into the top field. Choose to run this command as a specific user and specify root.

Send UNIX Command

From the Template drop down menu in the upper right corner select Save as Template… and save these settings with a descriptive name such as Spin ladmin password.

Save as template

To use and reuse this template, select the workstations with the old account password and click the Send UNIX Command button in ARD’s toolbar. Choose the Spin ladmin password template from the Template drop down menu. Adjust the account name and password accordingly in the script and then click the Send button.

ARD can spin dozens or hundreds of account passwords in just a few seconds without having to know the original.

Windows 7: What a difference time makes!

Wednesday, February 6th, 2013

While visiting our Santa Monica office I called on a client having difficulties connecting his Windows 7 computer to his file server. I expected this to be a pretty straight-forward issue since the environment was pretty simple:

  • Only his PC wouldn’t connect—everyone else was connecting without issue
  • Just a handful of users (about five)
  • All wired connections (no wireless)
  • A Windows Server 2003 file server
  • No domain—just a workgroup
  • A small simple router for DHCP and Internet

I went through basic troubleshooting steps and verified that the client could indeed browse devices on the network (including the server), had no unusual ping times or network settings and that his account password for the server was correct. Every attempt to connect prompted for his name and password but the server wouldn’t accept his credentials. He was repeatedly prompted for his credentials.

Likewise, a new server account that I created myself would work on other PCs but not his. I narrowed my focus to his machine and started asking questions:

Q: Was this a new machine?

A: Yes, pretty new.

Q: Had it ever connected to the server?

A: Yes, it had.

Q: Any recent unusual activity in the office?

A: Yes, the office had to be shut down for some recent power maintenance in the building a week ago. When he restarted the server it wouldn’t power up. Hardware technicians had diagnosed a few failed components. Only yesterday afternoon had the server been back online.

Q: Did he have the only Windows 7 PC in the office?

A: Yes.

The last question led me to believe he was having an issue with security negotiations between his PC and the server because the two OS versions were nearly 10 years apart and Windows 7 has considerably stricter security. Nothing in the PC’s local policy nor the server’s local policy for Microsoft Networking looked unusual. I tested a little registry change that seemed logical:

Go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA

Create Dword LmCompatibilityLevel with a value of 1

Restart computer and try to connect again.

No change.

After more research I found another potential solution on Microsoft Answers but was skeptical it would solve my issue since the computers were in a workgroup and not a domain. Check the time.

Just as soon as I was ready to pursue that idea the office manager asked me to check the backups on the server because they were reporting dates from October 2010. That was a smack to the face!

A quick resync to the time.windows.com NTP server corrected the time and the Windows 7 user logged in immediately.

QuickTip: Retrospect

Saturday, February 2nd, 2013

False-positive errors muddy our view, so just as many strive to quiet noisy syslogs, we can easily overcome a common complaint we see Retrospect make when doing differential SQL backups: ‘the master DB can’t be DIFF’d’.

Complicating matters is Retro’s SQL connector doesn’t seem to allow you to exclude that one as a source. Simply make an exclusion for ‘file or folder name matches: master’ and you’ll see it get to the master in the log and decide no files necessary to backup, keeping the result of that script error-free.

A Little About Xen

Friday, February 1st, 2013

Xen is one of those cool open source projects which seems like the kind of thing you’d probably want to run if it weren’t for the fact that everyone forces you to run ESX(i). It’s free, it’s well documented, and no matter how irrational salespeople can be, nobody can say there’s no support or documentation for it. So how does Xen work, and how does it compare with ESXi?

For starters, there’s no need to be overly concerned with what hardware is supported. Instead of being dependent on a specific OS, Xen is a driverless hypervisor which runs in conjunction with a host OS. This host OS might be GNU/Linux, NetBSD, Solaris or others. Since the host OS handles talking with hardware, any hardware which is supported by the host OS can be used with Xen. In a nutshell, Xen can be run on any x86 box, although full virtualization requires Intel’s VT-x or AMD’s AMD-V hardware support.

So let’s say you want to set up Xen. How? In many instances it’s as simple as installing a GNU/Linux distribution or a NetBSD distribution. Straightforward directions can be found here:

http://www.netbsd.org/ports/xen/howto.html

Let’s say you’ve already done all of that and you’re sitting at the command prompt of your Xen dom0. How do we create virtual machines? We’ll make an example using Windows 2012 Server since that just happens to be what I’m installing today.

Just like the how-to for installing a Xen dom0 instance, there are lots of how-tos for installing Windows and other OSes under Xen. We’ll summarize the important points using a minimal VM configuration file:

name = "win2012"
memory = "8192"
builder='hvm'
device_model='/usr/local/libexec/qemu-dm'
disk = [ 'file:/usr/xen/win2012/win2012.img,ioemu:hda,w', 'file:/usr/xen/win2012/winserver2012.iso,ioemu:hdb:cdrom,r' ]
vif = [ 'bridge=bridge0', ]
vcpus = 1
sdl = 0
vnc=1
vncconsole = 1
vnclisten="127.0.0.1"
vfb = [ 'type=vnc,vncdisplay=12,vncpasswd=booboo' ]
on_reboot = 'destroy'
on_crash = 'destroy'

# boot on floppy (a), hard disk (c) or CD-ROM (d)
# default: hard disk, cd-rom, floppy
boot="cd"
usbdevice = 'tablet' # Helps with mouse pointer positioning

Some of the options are pretty self-explanatory such as name, memory, vcpus, on_reboot and on_crash. Others may need a little explanation. Builder identifies the kind of virtualization. For paravirtualization, no builder need be specified, but you must be running a Xen-aware domu. For full virtualization, use hvm. device_model determines the executable run to emulate devices which the virtual machine will use. The default Xen qemu device model appears to work well nowadays with all versions of Windows. The disk line should make sense, but be aware that you’ll need to make the disk image yourself. If you wish to preallocate the entire file, use something like:

dd if=/dev/zero of=/usr/xen/win2012/win2012.img bs=1048576 count=32768

Which would write 32 gigs of zero to the disk image file. If you don’t care about preallocating the space, you can run:

dd if=/dev/zero of=/usr/xen/win2012/win2012.img seek=32767 bs=1048576 count=1

vif is the virtual network interface. A bridge to a real NIC is simplest, although other options are available if desired.

sdl is some other way of presenting the graphics screen, but I don’t know how that works. vnc, on the other hand, can be run on localhost and sent over X11 very easily. My options above create a vnc listener on display 12 (localhost:5912) with a simple password. One can forward X11, with compression if preferred, and run vncviewer on the Xen dom0. If X11 scares you, you can also use ssh to forward port 5912 from localhost of the dom0 to a port on your local machine and run VNC or Screen Sharing on your local machine.

There are great reasons to do something like this, like the ability to talk directly to the ssh daemon on the dom0 instance… But whatever… Blah blah blah. We’re now running Windows in Xen…