Shutdown a Windows machine from the UNIX command line

Picked up this nifty trick from command-line-fu

$ net rpc shutdown -I ipAddressOfWindowsPC -U username%password

This will issue a shutdown command to the Windows machine. username must be an administrator on the Windows machine. Requires samba-common package installed. Other relevant commands are:

net rpc shutdown -r : reboot the Windows machine

net rpc abortshutdown : abort shutdown of the Windows machine


net rpc

to show all relevant commands

The “net rpc service” command looks spiffy.

(michael)> net rpc

net rpc info             show basic info about a domain
net rpc join             to join a domain
net rpc oldjoin             to join a domain created in server manager
net rpc testjoin         tests that a join is valid
net rpc user             to add, delete and list users
net rpc password <username> [<password>] -Uadmin_username%admin_pass
net rpc group         to list groups
net rpc share         to add, delete, list and migrate shares
net rpc printer         to list and migrate printers
net rpc file             to list open files
net rpc changetrustpw     to change the trust account password
net rpc getsid         fetch the domain sid into the local secrets.tdb
net rpc vampire         syncronise an NT PDC’s users and groups into the local passdb
net rpc samdump         diplay an NT PDC’s users, groups and other data
net rpc trustdom         to create trusting domain’s account or establish trust
net rpc abortshutdown     to abort the shutdown of a remote server
net rpc shutdown         to shutdown a remote server
net rpc rights        to manage privileges assigned to SIDs
net rpc registry        to manage registry hives
net rpc service        to start, stop and query services
net rpc audit            to modify global auditing settings
net rpc shell            to open an interactive shell for remote server/account management

‘net rpc shutdown’ also accepts the following miscellaneous options:
-r or –reboot    request remote server reboot on shutdown
-f or –force    request the remote server force its shutdown
-t or –timeout=<timeout>    number of seconds before shutdown
-C or –comment=<message>    text message to display on impending shutdown

Zoning Brocade switches: creating zones

I previously talked about creating aliases on Brocade switches, and am going to use this post to discuss zone creation. Zones allow you to control initiators and targets can see each other, which enhances security by limiting access to devices connected to the SAN fabric. As previously discussed, we can assign an alias to each initiator and target. Once an alias is assigned, we can create a zone and add these aliases to it. Brocade managed zones with the zone* commands, which are listed below for reference:

zoneadd – Add a member to an existing zone
zoneCopy – Copy an existing zone
zonecreate – Create a new zone
zoneDelete – Delete a zone
zoneRemove – Remove a one from the configuration
zoneRename – Rename a zone
zoneShow – Show the list of zones

To create a new zone, we can run the zonecreate command with the name of the zone to create, and the list of aliases to add to the zone:

Fabric1Switch1:admin> zonecreate “CentOSNode2Zone1”, “NevadaPort1; CentosNode2Port1”

Once the zone is created, we can view it with the zoneshow command:

Fabric1Switch1:admin> zoneshow “CentOSNode2Zone1”

 zone:	CentOSNode2Zone1	
		NevadaPort1; CentosNode2Port1

Now that we have a zone, we need to add it to the switch configuration and then enable that configuration. I will discuss that in more detail when I discuss managing Brocade configurations.

Zoning Brocade switches: creating aliases

In my previous Brocade post, I talked about Brocade zoning, and mentioned at a high level what is required to implement zoning. Prior to jumping in and creating one or more zones in your fabric, you should add aliases to describe the devices that are going to be zoned together. An alias is a descriptive name for a WWN or port number, which makes your zone configuration much easier to read (if you are the kinda person who can spout off the WWNs of all of the devices in your fabric, you can kindly ignore this post). Brocade switches come with a number of commands to manage aliases, and these commands start with the string “ali”:

aliCreate – Creates a new alias
aliDelete – Deletes an alias
aliRemove – Removes an entry from an alias
aliRename – Renames an existing alias
aliShow – Shows the aliases

To create a new alias, you will first need to locate the WWN(s) or port(s) you want to assign to the alias. The easiest way to do this is by running switchshow on the switch (you can also use the Emulex or QLogic host utilities to gather WWN information):

Fabric1Switch1:admin> switchshow

switchName:	Fabric1Switch1
switchType:	16.2
switchState:	Online   
switchMode:	Native
switchRole:	Principal
switchDomain:	1
switchId:	fffc01
switchWwn:	10:00:00:60:69:c0:32:a4
switchBeacon:	OFF
Zoning:      	ON (Brocade3200)
port  0: id N2 Online         F-Port 10:00:00:00:c9:3e:4c:eb
port  1: id N2 Online         F-Port 10:00:00:00:c9:3e:4c:ea
port  2: id N2 No_Light       
port  3: id N2 No_Light       
port  4: id N2 Online         F-Port 21:00:00:e0:8b:1d:f9:03
port  5: id N2 Online         F-Port 21:01:00:e0:8b:3d:f9:03
port  6: id N2 No_Light       
port  7: id N2 No_Light       

Once you know the port numbers or WWNs, you can run the alicreate command, passing it the name of the alias to create, as well as the port or WWN to associate with the alias (if you assign more than one port or WWN to the alias, they need to be separated with a semi-colon):

Fabric1Switch1:admin> alicreate “CentosNode2Port1”, “21:00:00:e0:8b:1d:f9:03”

After an alias is created, you can view it with the alishow command:

Fabric1Switch1:admin> alishow “CentosNode2Port1”
alias: CentosNode2Port1

If you make a typo while adding a WWN or port to an alias, you can run aliadd to add the correct WWN or port to the alias, and then execute aliremove to remove the entry that was incorrectly added. If you make a typo in the alias name, you can run alirename to rename the entry. That is all for today. In my next blog post, I will talk about how to create zones.

Indenting bourne shell here documents

The Bourne shell provides here documents to allow block of data to be passed to a process through STDIN. The typical format for a here document is something similar to this:

data to pass 1
data to pass 2

This will send the data between the ARBITRARY_TAG statements to the standard input of the process. In order for this to work, you need to make sure that the data is not indented. If you indent it for readability, you will get a syntax error similar to the following:

./test: line 12: syntax error: unexpected end of file

To allow your here documents to be indented, you can append a “-” to the end of the redirection strings like so:

if [ "${STRING}" = "SOMETHING" ]
        somecommand <<-EOF
        this is a string1
        this is a string2
        this is a string3

You will need to use tabs to indent the data, but that is a small price to pay for added readability. Nice!

Zoning Brocade switches: zoning overview

Storage area networks (SANs) are deployed at most larger organizations, and provide centralized administration for storage devices and management functions. When multiple clients are accessing storage resources through a SAN, you need a way to limit which targets and logical units each initiator can see. Typically LUN masking is used on the storage array to limit which initiators can see which logical units, and zoning is used on the SAN switches to limit which initiators can see which targets. In the next five blog posts, I plan to provide a step-by-step guide to zoning Brocade switches.

Brocade zoning comes in two main flavors. There is hard zoning (port-based zoning), which allows you to create a zone with a collection of switch ports. The second zoning method is soft zoning (WWN-based zoning), which allows you to create a zone with one or more WWNs. There are tons of documents that describe why you would want to use each form of zoning. I typically use the following two rules to determine which zoning method I will use:

1. Will I ever need to move the host to a different switch or port? If so, I will implement soft zoning.

2. Are there any policies that require me to lock an initiator to a specific port? If so, I will use hard zoning.

I prefer soft zoning, since it provides tons of flexibility when dealing with switch upgrades, faulty SFPs, and defective hardware. But each location has different policies, so it’s best to to take that into account each time you design or implement your zone layout.

To implement zoning on a Brocade switch, the following tasks need to be performed:

1. Add aliases for each port / WWN

2. Add the aliases to a zone

3. Add the zone to a configuration

4. Save and enable the new configuration

Brocade provides awesome zoning documentation, which you can access though the help and zonehelp commands:

Fabric1Switch1:admin> zonehelp

aliAdd			Add a member to a zone alias
aliCopy			Copy a zone alias
aliCreate		Create a zone alias
aliDelete		Delete a zone alias
aliRemove		Remove a member from a zone alias
aliRename		Rename a zone alias
aliShow			Print zone alias information

cfgAdd			Add a member to a configuration
cfgCopy			Copy a zone configuration
cfgCreate		Create a zone configuration
cfgDelete		Delete a zone configuration
cfgRemove		Remove a member from a configuration
cfgRename		Rename a zone configuration
cfgShow			Print zone configuration information

zoneAdd			Add a member to a zone
zoneCopy		Copy a zone
zoneCreate		Create a zone
zoneDelete		Delete a zone
zoneRemove		Remove a member from a zone
zoneRename		Rename a zone
zoneShow		Print zone information

cfgClear		Clear all zone configurations
cfgDisable		Disable a zone configuration
cfgEnable		Enable a zone configuration
cfgSave			Save zone configurations in flash
cfgSize			Print size details of zone database
cfgActvShow		Print effective zone configuration
cfgTransAbort		Abort zone configuration transaction

Reading through (i.e., running help <command>) the help sections prior to implementing your zone layout will save you a lot of hassle, especially when you start to ask yourself questions like “Does cfgremove or cfgdelete remove an entry from a configuration?”. Well, that is all for today. Tomorrow I will discuss aliases, and how to use the ali* commands to create and manage them.

Cleaning up old Ruby gems

I was doing some experiments with a number of Ruby gems, and installed several gem versions as part of my testing. The gem utility has a slew of useful built-in options, one being “cleanup”. When gem cleanup runs, it will remove all gems that are older than the the latest gem version. So given a gem that has two versions:

$ gem list httplib

*** LOCAL GEMS ***

httplib (2.5.1, 2.5)

We can first run gem cleanup in dry-run mode to see what would be removed:

$ gem cleanup -d
Cleaning up installed gems…
Dry Run Mode: Would uninstall httplib-2.5
Clean Up Complete

Once we are happy with the results, we can run gem cleanup to actually remove the old gems:

$ gem cleanup -v
Cleaning up installed gems…
Attempting uninstall on httplib-2.5
Successfully uninstalled httplib version 2.5
Clean Up Complete

Ruby is an amazing language, and the more I read about it the more I like it.