OS X 10.9 Epson Printer – Enable Duplex Printing

Epson recently released a driver update for OS X 10.9 Mavericks which automatically shows up within the Apps/Software update menu. Like most users my wife dutifully added the update which then removed her duplex printing settings.  Screen Shot 2014-01-26 at 1.50.30 PM
Notice the “Two-Sided” printing option is off and grayed out.
While I’m sure this was unintended it did pose a real problem. After reinstalling drivers and the printer itself several times I found the following fix.

1. Select “Printer Features” from the pull down menu (Hint: Click Layout)
2. From the “Feature Set” pull down menu select “General 6″

Screen Shot 2014-01-26 at 1.53.13 PM

You’ll notice that buried within this sub menu is the option we’re looking for.

3. Select 2-Sided Printing ON
4. In order to ensure you never have to set this option again save your new settings.
Screen Shot 2014-01-26 at 1.58.41 PM

You can see in this screen capture I’ve already saved mine as “Duplex!”

Fix OS X Mavericks Continuously Prompting for KeyChain Password

Symptom: Upon login OS X Mavericks continuously prompts you for a Key chain password which does not match either your iCloud/iTunes credentials or your local login credentials.

Fix:

* Go to Finder.
* On the Finder menu, click on “Go”, then on “Go to Folder”. A box should come up.
* On the box, type in “~/Library/Keychains/” and click on “Go”. It should lead you to the Keychains folder where you will find three items: (1) a folder with a name mixed with letters and numbers, (2) login.keychain, and (3) metadata.keychain.

* Delete the folder with a name mixed with letters and numbers.
* Restart your computer. Check to see if the problem has been solved.

Solution Source: http://forums.macrumors.com/showthread.php?t=1652089

Fix: Youtube buffering issue

Over the past two weeks I’ve noticed a continuous issue with loading youtube videos and having them endlessly buffer. Tonight I did some digging and found a quick fix!
The solution is pretty simple, and involves blocking a specific IP range associated with Verizon FIOS servers which are buffering Youtube traffic.  Since the IP may be different depending on your location I’ll go through the simple steps to identify the IP to block and the associated OS X command to run to block it.

1. Open a terminal window and type “traceroute youtube.com”
2. Note the first IP address which shows up outside of your network.  It should be the one which doesn’t start with 192.x.x.x
On my network the offending IP is:
l100.<your area>-vfttp-<some number>.verizon-gni.net (1.1.1.1)  19.260 ms  20.116 ms  18.862 ms
Also, note any entries which end in “alter.net” as these are Verizon FIOS servers.
3. Test loading a highdef youtube video.  Make sure to switch its resolution up to 1080p, and watch it buffer.
4. From the terminal window block the offending IP by running the following command
sudo ipfw add reject src-ip 1.1.0.0/16 in
5. Confirm the IP is now blocked by running sudo ipfw list
Example output:
00100 reject ip from 1.1.0.0/16 to any in
6. Refresh your browser by hitting F5 and reload the high def YouTube video.
Note, if this doesn’t work the blocked IP subnet can be removed using the following command:
sudo delete 00100 reject ip from 1.1.0.0/16 to any in
If this doesn’t work you can also try blocking the IPs found within this post.

NetApp – Calculate Maximum Number of inodes per Volume

NetApp volumes allow for inodes to be dynamically allocated/increased on volumes which are provisioned on an array.  This begs the question, what is the maximum inode count supported by a volume and how is the maximum number calculated?

inodes = files

“The maximum number of inodes is limited to one inode per one block in the filesystem. (which is 1 inode per every 4KB).  It is generally recommended to NOT go that low.”

TB (Volume) GB MB KB
1.2 1,228.8 1,258,291 1,288,490,189

1,288,490,189KB / 4KB Blocks = 322,122,547 supported files / inodes per 1.2TB volume.

Credit where credit is due… https://communities.netapp.com/thread/2176

NetApp vFiler – Change IPSpace

NetApp virtual filers are handy for implementing multiple isolated environments which can have their own domain authentication and network isolation.  In order to completely isolate a vFiler from a physical filers interfaces separate dedicated interfaces must be assigned.  In the NetApp world interfaces are grouped based on IPSpaces.  For each IPSpace there can only be one default gateway.  By creating multiple IPSpaces you can isolate a vFilers storage traffic and also allow for multiple default gateways.  The use of multiple default gateways removes the need for adding static routes to the physical filer and also precludes asymmetric routing issues from occurring.

Goal: Change the IPSpace of an existing vfiler without losing any of the existing configuration settings.

Note: You will need to recreate any local accounts previously created using the useradmin command.

Prep:

Make a copy of the following files prior to attempting to change your vfilers IPSpace.

  • \etc\rc
  • \etc\passwd
  • \etc\quotas
  • \etc\registry
  • \etc\hosts
  • \etc\exports (only if the filer serves NFS shares)
  • \etc\cifsconfig_share.cfg (only if the filer serves CIFS shares)
  • \etc\cifs_homedir.cfg (only if you use home directory mapping capability)

Active Directory Filer Association

  • \etc\cifssec.cfg
  • \etc\krb5.keytab
  • \etc\krb5auto.conf
  • \etc\lclgroups.cfg

Create the new VIF & IPSpace. Note that vifs which use LACP will initially come up but show as broken until an IP address is bound to it.

brain dump in progress…

Netapp – Rename Filer in SnapMirror Relationship

As organizations change so do the standards which guide them.  As part of these changes pre-existing filers names may need to be updated and changed.  Before attempting to update a filers name you must first perform a number of confirmation steps.  This will ensure that you do not lose connectivity to your filer and that existing snapmirror relationships can be re-established after the change.

Prep

  • Create a new DNS entry for the new filer name
  • Prep the /etc/hosts file on the filer with the new name and IP (comment it out) on both source and destination filers.
  • Add the VLAN to the filers VIF or new VIF depending on how you’d like routing configured.
  • Prep the /etc/rc file with the new filer name and default gateway details.
  • Prep the NTP server details (only if a new server will be used on the new network…)
  • Confirm all management stations and NetApp monitoring utilities have access to filers new IP address. ie. add any necessary firewall rules.
  • Confirm network connectivity between the old and new network. This is critical if the filers name and IP address will only be changed on one site.

Execution (Note: during these steps all existing snapmirror relationships will disappear)

  1. Take note of the existing snapmirror relationships & their associated volume names
  2. Break the relationship (From the destination)
  3. Update the filers IP address, hostname, and default gateway
  4. Update the /etc/hosts file on the source and destination filer. It should reflect the new hostname and associated IP.
  5. Use ping to confirm both source and destination filer can see each other.
  6. BEFORE re-establishing the mirror relationship double check that the hosts file has been correctly updated on both the source and destination filer.
  7. Update your snapmirror options to allow the new filer names to establish relationships with each other.
  8. Re-Establish the mirror from the destination by using snapmirror resync.

Example:

nap003> snapmirror status
Snapmirror is on.
Source Destination State Lag Status
nap003:source_new nap004:dest_new Source 00:05:25 Idle

nap004> snapmirror status
Snapmirror is on.
Source Destination State Lag Status
nap003:source_new nap004:dest_new Snapmirrored 00:06:25 Idle

nap004> snapmirror break dest_new

Update both filers associated configuration files
nap003>rdfile /etc/rc
nap003>rdfile /etc/hosts
nap004>rdfile /etc/rc
nap004>rdfile /etc/hosts

nap004 /etc/hosts updates to make it nap006
192.168.0.201 nap006 nap006-e0a
192.168.0.200 nap005

nap004 /etc/rc updates to make it nap006
hostname nap006

nap004> hostname nap006
nap006>

Perform the same steps on the second filer. Once completed you can now re-establish the relationship from the destination filer. Do not be alarmed that the snapmirror status shows no relationships exist.

nap005> options snapmirror.access host=nap006
nap006> options snapmirror.access host=nap005

nap006> snapmirror resync -S nap005:source_new nap006:dest_new
The resync base snapshot will be: nap004(4055372815)_dest_new.4
These older snapshots have already been deleted from the source
and will be deleted from the destination:
nap004(4055372815)_dest_new.3
Are you sure you want to resync the volume? yes
Volume dest_new will be briefly unavailable before coming back online.
Wed Feb 13 22:43:13 EST [nap006:snapmirror.dst.resync.info:notice]: SnapMirror resync of dest_new to nap005:source_new is using nap004(4055372815)_dest_new.4 as the base snapshot.
Wed Feb 13 22:43:16 EST [nap006:wafl.snaprestore.revert:notice]: Reverting volume dest_new to a previous snapshot.
Revert to resync base snapshot was successful.
Wed Feb 13 22:43:17 EST [nap006:replication.dst.resync.success:notice]: SnapMirror resync of dest_new to nap005:source_new was successful.
Transfer started.
Monitor progress with ‘snapmirror status’ or the snapmirror log.

nap006> snapmirror status
Snapmirror is on.
Source Destination State Lag Status
nap005:source_new nap006:dest_new Snapmirrored 00:08:06 Idle